SAP Community - Cloud Connector

[Antonio] Hola, SAP developers. There is a new feature in the latest release of SAP Cloud Integration that I'm sure you'll be very excited about. It is now possible to easily update the version of an integration flow component. Previously, updating the version of a component was done manually. For example, you wanted to update the version of an adapter, meant reconfiguring it from scratch. This was quite painful and error-prone. The new feature enables a one-click update to update a component which is backward-compatible to the latest version without any loss of the existing properties, configurations, or externalized parameters. Cool, right? Check out Kamlesh's blog post to learn more about the new feature. In the event-driven space, have you heard about SAP's new event add-on for ERP? You can leverage the add-on to event-enable your SAP on-premise backends, for example, SAP S/4HANA or SAP ERP, and expose consume events to and from SAP Integration Suite Advanced Event Mesh. Check out Carsten's blog post series to learn more about it. Also, there is a new feature in the event mesh capability of SAP Integration Suite. It is called Queue Browser, and it will allow you to inspect and visualize messages in a queue via the web UI without consuming the messages from the queue. It is quite powerful as you can examine the message metadata, for example, headers, statuses, and errors, and troubleshoot maybe a more-formed payload in the message. Check out Arley's blog posts for more information. Ciao!

[DJ] You've probably heard of the Terraform Provider for SAP BTP, which allows you to create and manage your resources on BTP declaratively using an open standard. Well, the Terraform team have just released the beta of the Terraform Provider for SAP Cloud Connector. This essential piece of connectivity software in your SAP landscapes is now able to be managed declaratively, just like your assets on BTP. What's not to like? Check it out. It's a beta, and the team would love you to try it out, kick the tires, and send them thoughts on what you think. Links in the description.

[Kevin] So if you were wondering what kind of awesome tools libraries and sources for CAP are out there look no further Mauricio Lauffer got you he has this brand new repository on github which is a list of all of those things and that list is awesome and the repository is called awesome cap so check it out right now and maybe also contribute your awesome links to the repository today.

[DJ] remember the SAP community voice online email based newsletter well it's back online but this time in the form of blog posts on the SAP community platform in case you don't know this newsletter highlights interesting blog posts community news events and lots more check it out the first edition in blog post form is from our Jerry, Jerry Jander link in the description.

Build A Web App and Connect to S/4HANA with SAP Integration Suite

2025-08-13T12:45:21.973000+02:00

A big part of the magic behind AI, advanced analytics, and {insert tech buzzword here} is the humble API!

I remember the excitement about service-oriented architecture in the late 1990s and early 2000s. Back when most organisations had 'fat' ERPs with extensive customisation, the idea that we could split things up into different apps and connect in a standardised way was refreshing.

I recently noticed a SAP CodeJam on the SAP community events calendar that involved connecting systems to S/4HANA using SAP Integration Suite.

I thought it might be fun to build a web app and see if I could successfully connect it to S/4HANA.

A basic understanding of frontend to enterprise backend via cloud architecture is useful for everyone; business experts, technology experts, and people experts

The article is broken into three parts: an introduction, a step-by-step explanation for generalists, and my build/test notes for anyone working on something similar. The third section includes details on all the test tools, and configuration settings.

A couple of quick disclaimers:

I'm not an integration expert:
- I don't look at integration suite vs. other solutions
- I don't cover best practices, typical challenges, good use cases
My solution here is likely not optimal:
- It's just a vanilla HTML, CSS, JS frontend

---

Part 1: introduction

From web app to S/4HANA

The plan:

The frontend is a web page to search for data from within S/4HANA
The web server handles communication between the frontend and SAP Cloud
SAP Integration Suite will route and format the message for S/4HANA
S/4HANA is the source of data.

Tools/technology:

Utilise the free trial account for SAP BTP and Integration Suite
Build the frontend and web app ourselves
We can't access S/4HANA. However, the CodeJam provides a S/4HANA mock server that mimics the behaviour of an API within S/4HANA.
If we use a mock system, we will need to run it locally. So, adjusting the architecture.

This adds SAP Cloud Connector which allows an "on-premise" application to connect with SAP Cloud.

The front end

The completed app offers a summary view and a detailed view. Here's a short screen recording

Summary view

This is a screenshot from the web browser (firefox).

The top part of the page has a search form that allows you to search for a business partner. The bottom part of the page shows the results with a selection of key fields in a card style layout.

The mock system we are using allows for four different search possibilities:

Search for a single business partner by number
Search for all business partners
Search for a single business partner by number, including address details
Search for all business partners, including address details.

Detail view

The detail view shows the results in a table. This table has a horizontal scroll bar, which can be adjusted to view all the fields. The table includes 'raw' results, so there are some 'technical' entries like `[object Object]` and some blanks, which I think is fine for this mock up stage.

Responsive view

For tablets and mobile, the card view resizes with the browser window.

![the front end - summary view on mobile](/assets/images/blog/integration/integration-5.png)

I'll come back to how this front end was built after running through the integration flow.

S/4HANA

The value of this flow is being able to design and build a frontend to access real-time, trusted business data from S/4HANA in a standardised way. In a real-world example, our frontend could be an employee portal or supplier portal.

S/4HANA is:

SAP's enterprise software for large organisations. It handles processes such as purchasing, manufacturing, sales, shipping, finance, etc.
An evolution from their earlier ERP products (R/1, R/2, R/3, ECC).
A complex platform comprising thousands of programs, tables, and customisations used by many large enterprises.

S/4HANA already comes with a web frontend called Fiori, which includes thousands of apps. However, in this example imagine we are building something for a casual user that does not require the full capability of Fiori. Or, just consider it's for fun.

Business partner

The mock server simulates one of the business partner APIs for S/4HANA.

A business partner is a reference or master data record that represents a third party that an organisation works with. This includes customers, suppliers, and employees.

Business partner master data is organised by key fields such as "category" and "role".

All business partners have general data such as name, address, etc., then they have role-specific data, which may include, but are not limited to:

Purchasing data
Sales data
Accounting data
And so on.

To understand how business partner data is used, consider a typical ERP process like order-to-cash:

This is a summary of the order to cash process. During sales, deliveries, and billing, information from the business partner master record is utilised.

The business partner master stores long-term stable information about the customer. It's used for both reference and validation during transaction entry.

This ensures there is consistency across transactions over time in terms of how they reference business partners. This is critical for reporting. Consider comparability, aggregation, etc.

S/4HANA Architecture

The mock server simulates an S/4HANA API. Let's look inside S/4HANA.

Starting from the top right, S/4HANA has two primary ways for users to interact. The traditional SAP graphical user interface (GUI) and the modern Fiori web-based user interface.

I've drawn APIs to the left of these. The APIs allow applications to interact with S/4HANA.

Consider the data model in S/4HANA in two separate parts. The first is the traditional HANA database. This is where master data and transactional data are stored. On top of this is the virtual data model. This consists of core data services views. This is a way to define different sets of data to meet the needs of APIs and Fiori Apps.

In this example, we are using a business partner data API. Behind the scenes, the API sources data from CDS views, which in turn connect to the HANA DB tables.

---

Part 2: step by step walkthrough (for everyone)

In this section, I'll summarise the process and technology involved at each step.

Point 1: Web communication

Building an integration flow between web connected applications relies on protocols and standards for web communication. Let's run through the main concepts.

Client/server

The terms client and server are used to describe the requester and receiver. For example, the web browser on a computer is a client, and google search is a server.

Internet communications use the HTTP protocol.

![HTTP communication](/assets/images/blog/integration/integration-10.png)

Hypertext Transfer Protocol (HTTP) is a standard protocol for communication between clients and web servers. Web pages are written in Hypertext Markup Language (HTML).

The term Uniform Resource Locator (URL) is used to describe an address.

The structure of a URL

URLs have five key parts:

Protocol: `http://`
Domain: `www.example.com`
Path: `/pages/`
Query string: `?id=1&cat=test`
Fragment: `#article` (an internal page reference, often not present)

When it comes to APIs, the query string provides the ability to specify parameters for search and filter. In this case, the query string could include a business partner number.

HTTPS

HTTPS uses the HTTP protocol, but it adds a secure transport layer. HTTPS means the HTTP message is encrypted before transmission.

The only part that isn't encrypted is the domain name.

Internet protocol (IP) address

While URLs are designed to be human-readable. An IP is a numerical label like "192.0.2.1" that identifies a computer or network.

URLs are used for navigation. IPs are used for routing and communication. They identify a specific device on a network (laptop, server, etc.).

An IP address can be used in place of a domain name with HTTP and HTTPS

"http://192.0.2.1"

While an IP address represents a computer. The term "port" is used to specific a specific input/output location.

Ports are identified using 4 digits.

"http://{server}:{port}"
"http://192.0.2.1:1000"

A server is often referred to by 'host'

"http://{host}:{port}"

You can access ports on your own computer by using its IP or "localhost"

"http://localhost:1000"

From domain to IP

The web browser uses a domain lookup service to translate a URL into an IP address.

"http://www.example.com" becomes "http://192.0.2.1"

This is called the Domain Name System (DNS). Popular look up services include: Cloudflare, Google DNS, and OpenDNS.

Messages

The communications themselves can be thought of as messages. They contain a header and a body.

The header includes:

The URL
The method, most commonly GET and POST
GET sends a request without a body
POST sends a request with a body
Additional information on the content type and authorisation

The body includes detailed content. For example:

If you fill in a form on a web page, it would include the form data
If a server returns a web page, it would include the web page.

Server Responses

When a server receives a request, it responds with a status code and a body. Status codes include '200' representing "ok" and '404' representing 'Not Found'.

(404 has definitely reached meme levels of fame!).

The body that's returned depends on the status and the server's purpose.

Real life examples

Consider visiting the BBC website from a web browser, a simple GET request would return the home page.

On the other hand, consider logging into the BBC website. In this case, the browser sends the login name and password. Therefore, a POST request is used, and the request includes a body.

Web connectivity and SAP

Most SAP applications can use HTTPS communication. This is possibly one of the simplest ways we could define "Cloud" strategy.

S/4HANA Cloud Public and S/4HANA Cloud Private can both utilise HTTPS
SAP BTP which includes SAP Integration Suite can utilise HTTPS

Outside the SAP Cloud, we have systems like S/4HANA On-Premise. This is usually at an SAP customer's data centre or their 3rd party hosting service provider's data centre. On premise systems are usually not directly connected to the public internet. This is where SAP provide Cloud Connector to create a secure tunnel between on-premise and SAP Cloud.

HTTP data transfer standards

There are further standards as to how data is transferred using HTTP.

There are multiple standards for data transfer with HTTP. One of the earlier and more common standards is REST (Representational State Transfer).

Many SAP APIs utilise OData (Open data transfer protocol).

Point 2: S/4HANA business partner API mock server

Purpose: Mimic the business partner API of an S/4HANA system.

What is it: A simple JavaScript server that can be run locally.

The mock server provided by the SAP community provides a simple way to simulate the design and test of an S/4HANA API.

The mock server mimics the business partner (A2X) API
This is one of the S/4HANA APIs (programmed inside S/4HANA)
In the case of the mock server, it's a JavaScript server
The mock server has limited functionality, it supports:
- Sample data for a few business partners
- Retrieve all business partners
- Retrieve a single business partner
- Include additional address data in the response.

Installing and running the mock server is simple. The instructions are in part 3. When we run it our computer a local address is returned.

On my computer, it runs on "http://localhost:3005/"

This is the address for the Business Partner API. Entering this address in the web browser gives the following response:

The first item refers to the business partner API. This is the first point in the exercise where we can see the path for the Business Partner API:

"/sap/opu/odata/sap/API_BUSINESS_PARTNER"

The API path is just appended to the host, so:

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER"

Clicking on the link in the browser shows additional information about the API. Note that the only services listed are A_BusinessPartner and A_BusinessPartnerAddress.

When building an integration flow, the mix of host names, port names, and paths can quickly become confusing. It's useful to track these as we go.

Point 3: Application programming interface (API

Purpose: Provide a standard way to define and operate services for an application that can be consumed by other applications.

What is it: SAP have a large catalogue of standard APIs that come with S/4HANA.

The Business partner API

The API that was introduced under the S/4HANA business partner mock server is called 'business partner (A2X)'. It is a SAP standard API that uses the OData V2 standard.

While HTTP is the communication protocol. OData is an open standard related to the data.

When viewing the API details in the web browser, the display was JSON. This is JavaScript Object Notation, which is used in Odata. Point 5. in the flow will show more detail on this API.

Point 4: Business technology platform (BTP)

Skipping Cloud Connector for now, brings us to BTP. Details from BTP are needed to set up Cloud Connector.

Purpose: Enable customers to manage and build on SAP applications.

What is it: A set of tools encompassing various capabilities and environments.

SAP offer a free trial for BTP, which can be used to build and test integration flows. Instructions on how to register and set up BTP are included in part 3.

The BTP cockpit is where we can search for and set up different services.

It supports multiple infrastructures and runtimes so you can manage/build various types of applications from traditional SAP ABAP to web apps.

Supports multiple infrastructures/runtimes & languages, including:
- Cloud Foundry: develop new apps/services, multiple languages, runtimes
- ABAP: extend ABAP based products (S/4HANA)
- Kyma: Kubernetes to develop/run cloud-native apps
- Neo: HTML5, Java, and HANA extended apps

BTP has multiple regions and infrastructure providers

Regional deployment
- Provided by SAP or Infrastructure-as-a-Provider (IaaS)
- AWS, Azure, Google Cloud, Alibaba Cloud
The key features of BTP include managing and building:
- Compose business processes
- Application development and automation
- Build and extend SAP applications
- Integrate data
- Analytics
- Intelligent technologies

SAP Integration Suite utilises the Cloud Foundry environment. After we set up Business Technology Suite and SAP Intelligent Suite, a Cloud Foundry API endpoint will be provided in BTP.

In my case, this is "https://api.cf.ap21.hana.ondemand.com"

Point 5. Business Accelerator Hub

Purpose: Provides a central source of information on SAP's APIs

What is it: A web page with API details. Highly integrated with BTP.

Business Accelerator hub is a web resource from SAP. I've drawn it inside BTP as it closely relates to BTP content. It's a central repository for APIs from SAP & selected partners.

api.sap.com

Main features

Discover, explore, and test APIs
Consume integration and workflow content

The Business Partner (A2X) API that is tested here can be viewed on Business Accelerator Hub.

Login to business accelerator hub
Search 'business partner (A2X)'
Click on the entry in the results

Some features of business accelerator hub:

Try out the APIs (sandbox environment)
- Useful to view a sample of the response
View the API capabilities:
- 'API Reference' tab, scroll down to 'Business Partner' and click on it
- This shows the list of capabilities of the API
View the API specification
- 'Overview' tab, scroll down to 'API Specification' and click on it
- Download OpenAPI JSON
- View in web browser, text editor to see extensive details

The API hub is a useful resource in terms of discovering and designing potential API use.

From the mock server specification, we know it's limited to only a few capabilities. We can find the path names for each of these on API hub:

This confirms the mock server only has a small fraction of the full business partner (A2X) capabilities. This makes sense given how extensive business partner data is in SAP. It's noteworthy that the mock server only supports 'read' activities. We can't test creating or changing a business partner.

The details of each of these requests can be viewed by clicking into them.

While there are three request paths. The address path can be added to the "all business partners" or "single business partner", so there are four possibilities:

All business partners
- "/A_BusinessPartner"
All business partners with address
- "/A_BusinessPartner/to_BusinessPartnerAddress"
Single business partner
- "/A_BusinessPartner('{BusinessPartner}')"
Single business partner with address
- "/A_BusinessPartner('{BusinessPartner}')/to_BusinessPartnerAddress"

These paths describe services of the API and are appended to the base URL.For example:

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('{BusinessPartner}')/to_BusinessPartnerAddress"

The correct terminology for these URLs:

Base URL/host: http://localhost:3005
Base path: /sap/opu/odata/sap/API_BUSINESS_PARTNER
Entity set: /A_BusinessPartner
Key Access: ('1234567')
Navigation property: /to_BusinessPartnerAddress

"('{business partner}')" in the example is a placeholder for a business partner number.

Updating the flow diagram with these details:

Point 6: SAP Integration Suite

Purpose: Design and manage communications between applications.

What is it: A service of SAP BTP.

SAP Integration Suite is one of the services available in Business Technology Platform. Therefore, a prerequisite is to register for the BTP free trial.

SAP Integration Suite can then be found under 'Services Marketplace'.

SAP Intelligent suite can be used for Cloud, on-premise, and hybrid scenarios. It includes pre-built, best-practice integration packs

Technically, it's a Java based app, and utilises the Apache Camel framework.

The steps to install and set up are covered in part 3. After the initial set up you can navigate to the application.

For this demo/test, the two key menus within Integration Suite are:

Design > Integrations and APIs
Monitor > Integrations and APIs

The design area allows us to create an integration flow which involves:

Specifying source or 'sender' system
Specifying target or 'receiver' system
Adding flow steps
Modify message header
Modify message contents
Route steps between sender and receiver.

Within design, there is a graphical editor to build the integration flow.

Business Partner Integration Flow

Creating the integration flow involves setting the sender details and designing the required transformations to meet the receiver (API) requirements.

As we work through this keep in mind the API expects one of four paths depending on the search scenario:

The sender

The sender represents the address that SAP Integration Suite will listen on. This is the address we send a message to from our upstream app. In this case a web app.

This address is built up in three parts:

A base which is provided when we deploy the integration flow
An 'Address' that we specify in the integration flow
Further path details from the web app.

The base of the endpoint is something along the lines of:

https://{trial-account-specific-details}-rt.cfapps.ap21.hana.ondemand.com/http/

For the address name, this demo/test uses the path `/request-business-partners/*` The "`*`" at the end allow us to send requests with additional details that can be utilised in the flow logic.

The web app will send four different types of message to match the four API scenarios, for the demo/test I will use:

"/api/bp/single"
"/api/bp/all"
"/api/bp/single/add"
"/api/bp/single/all"

The web app will also include the BP number in the message body.

We don't need to specify these in the Integration Flow as the `*` will allow them all to pass as long as they are preceded by "request-business-partners/"

Adding this information to the mapping table.

Routing and Transformations

The integration flow routes and transforms the received messages to meet the API requirements at the receiver. This involves:

Routing of messages from receiver to sender based on their content
1:1 relationship for each of the four scenarios
Transform the URLs
A part of the transformation is extraction of the business partner number from the received message and the placement of it into the API format URL.

The receiver

The receiver is set up to match the S/4HANA business partner mock server.

More detail on the settings of each step are in part 3.

At this point, the integration flow is:

As an alternative, the web app could have been programmed to send messages that already fit the API requirements. However, in some scenarios sender systems may be inflexible or difficult to develop on, making these transformation capabilities in Integration Suite important.

Further reading on SAP Integration Suite:

- Help - What is integration suite
- Apache Camel

Point 7. Cloud Connector

Purpose: Allow SAP BTP to communicate to On-Premise SAP.

What is it: An application that can provide a secure connection between SAP Cloud and On-Premise applications.

In the previous part, we defined the address details of the S/4HANA business partner mock server as:

Base URL/host: http://localhost:3005
Base path: /sap/opu/odata/sap/API_BUSINESS_PARTNER
Entity set: /A_BusinessPartner
Key Access: ('1234567')
Navigation property: /to_BusinessPartnerAddress

If you paid attention to the screenshot of the receiver configuration in Intelligent Suite, you will note that it was set to

`http://s4-mock:3006/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('${property.employee_id}')`

The domain was "s4-mock:3006" not "localhost:3005".

This is because we can't connect SAP Cloud directly to an on-premise system. The S/4HANA business partner mock server is a JavaScript server that runs locally on desktop/laptop and is hence considered 'on-premise' or outside the SAP Cloud.

SAP provides "SAP Cloud Connector" to connect on-premise applications to the SAP Cloud.

It's a JavaScript application that can be installed and run locally. Part of the set-up involves entering authentication details from BTP.

After it's set-up, Cloud Connector will accept messages from Integration Suite and forward them to the S/4HANA business partner mock server.

The detailed set-up is covered in part 3.

The screenshot above shows the "Cloud to On-Premise" mapping. A virtual host "s4-mock:3006" is mapped to the S4/HANA business partner mock server running locally on "localhost:3005".

Updating the integration flow:

Point 8: Web app

The web app is an application that uses JavaScript as a programming language. Web browsers have JavaScript engines and can run JavaScript code.

There are two parts to the web app. The frontend and the backend.

Think of JavaScript in two categories. frontend JavaScript and server (backend) JavaScript.

Frontend JavaScript

Runs in the web browser, utilising the browsers JavaScript engine
Is oriented towards manipulating web documents (HTML documents), for example:
Retrieve fields from HTML (e.g. sign up form)
Update HTML (e.g. show results, dynamically add a new page)
The JavaScript engine in the browser has limitations.

Server JavaScript

Installed on a server (can also be run on a desktop/laptop)
A popular engine is Node.js
Is oriented towards messaging, connectivity, security, authentication
Has a lot less limitations than the web browser.

We could try to send a request from the frontend to SAP Integration Suite, but because it comes from a browser, it will likely result in errors.

I did try sending a message to Integration Suite from the browser, but received various CORS errors. CORS, or Cross-Origin Resource Sharing, is a browser security feature that controls whether a web page on one domain can access resources from a different domain.

Therefore, the frontend will send a request to the backend, which will then prepare the message and send it as a request to SAP Integration Suite.

Let's look at the frontend first, then the backend.

Point 8.1 Web app: frontend

Purpose: Search for and display business partner details on a web page.

What is it: A simple web app based on HTML, CSS and JavaScript.

The frontend can be built with plain HTML, CSS and JavaScript.

HTML: Used to define the content of the web page
CSS: Used to apply styles to the web page (layout, colours, font, etc.)
Javascript&colon; Use for programming logic, for example:
- Get input field values from HTML
- Fetch data from the server
- Restructure data for display

HTML, CSS, and JavaScript are written in their own files. They are typically in the same folder.

```
frontend/
├── index.html
├── styles.css
└── script.js
```

The HTML file includes references to the 'styles.css' and 'script.js' documents. These can all be written in simple text editors, but applications like 'visual studio code' help with syntax highlighting and formatting.

For demo/test these files can simply be kept on a computers hard drive. Or they could be hosted on a static web server like Netlify or GitHub pages.

Point 8.2: Web app - HTML

Web pages are written with HTML, they are hierarchically structured documents where 'tags' are used to denote different types of element which contain content.

As a simple illustration, the following would create a web page with a title, a text input field, a submit button and a space for results.

<header>
<p>This is the page title</p>
<body>
<article>
  <form>
    <label>Enter business partner number
      <input type="text" />
    </label>
    <button type="submit">Submit</button>
  </form>
  <div id="js-results">
    // Results go here
  </div>
</body>

This would display:

A simple element such as paragraph is denoted by
- `<p>enter paragraph</p>`
A more complex element, an input field is denoted by
- `<input type="text" />`
- In this case, `type` is an attribute set to `text` for text field

Getting HTML to talk to CSS and JavaScript**

There are two attributes that allow them to work together:

"id": for example id="bp-input" (where bp-input is a variable name)
"class": for example class="bp-input" (where bp-input is a variable name)

These attributes can be added to HTML elements to allow us to access those elements with CSS and JavaScript. The difference between the two is a single "id" value is unique and should only be used once in an HTML document, while a class can be applied to multiple HTML elements.

The body of the web app frontend is:

<body>
<header class="header">
<div class="header-title">
<img class="logo" src="assets/team.png">
<p class="title">Employee portal: business partner search</p>
</div>
<nav class="nav">
<a href="/index.html">Home</a>
</nav>
</header>
<article class="bp-article flow">
<h2>Search</h2>
<div class="divider"></div>
<form id="bp-form" class="bp-search">
<label for="bp-inp-number">Business partner number:</label>
<p class="text-small">(Enter 7 digit number or leave blank to return all)</p>
<input id="bp-inp-number" class="bp-inp-number" name="bp" type="text" />
<p id="bp-error" class="bp-error"></p>
<p class="options">Options:</p>
<div>
<input id="bp-inp-address" value="add" type="checkbox" />
<label class="text-small" for="bp-inp-address" name="bp-input-address">Include address details</label>
</div>
<div>
<input id="bp-inp-tab" value="tab" type="checkbox" />
<label class="text-small" for="bp-inp-tabulate" name="bp-inp-tabulate">Show results in table</label>
</div>
<button id="js-inp-sub" type="submit">Submit</button>
</form>
<h2>Results</h2>
<div class="divider"></div>
<div id="js-bp-results" class="bp-results">
</div>
</article>
</body>

It's not very complex. Most of the complexity is in the CSS styling and the JavaScript programming to return the results.

This segregation of content (HTML), styles (CSS), and programming logic (JS) makes working with frontend well structured.

The web app initial HTML includes:

A header bar with the logo, page name and home link
A search section with search field options
- BP number
- Checkbox to get address
- Checkbox to show results in detail view

This is how this looks without styling.

The version with styling was shown at the start of the article.

Here is the HTML file

Point 8.3: Web app - CSS

Cascading style sheets (CSS) are used to apply styles to HTML documents. Consider an HTML document with three lines of text:

<p id="line-one">This is text line one</p>
<p class="other-lines">This is text line two</p>
<p class="other-lines">This is text line three</p>

These can be styled with CSS as follows:

#line-one {
color: red;
font-size: 1.2rem;
}

.other-lines {
color: blue;
text-decoration: underline;
}

This would show:

The complete CSS for the demo/test web app is lengthy. Around 200 lines. Here is a snippet to get an idea of what it looks like:

CSS is easy to pick up, but challenging to master!

Looking at the class "bp-search". This applies to the area of the HTML document where the search fields are collected. The CSS here does things like orient those search fields in a column "flex-direction:column" and apply a border and a shadow.

This is how our page looks with styling.

Here is the full CSS file

Point 8.4: Web app - JavaScript

Frontend JavaScript is able to retrieve, edit and add elements to the HTML document. Writing the JavaScript is possibly the most challenging part of this demo/test, so I'll just summarise what the code does:

Listen for a click of the 'submit' button
Get the value of the form input elements
- The Business partner number
- The status of the 'include address details' checkbox
- The status of the 'show results in table' checkbox
Check the business partner value is valid
- It has to be blank or a 7-digit number
Create a variable object called 'request' to track the request type
The variable includes:
- request URL
- request method
- request body
- (The ability to track multiple values in an Object is a key JS feature)
Based on the input fields, identify the request type & update the 'request' object.
- The combinations are:
  - If bp number is blank and get address isn't checked
  - If bp number is blank and get address is checked
  - If bp number is entered and get address isn't checked
  - If bp number is entered and get address is checked.

At this point, the request object will store a set of values based on the input selections. The values will be one of the four options listed in the earlier tables.

The JavaScript now has what it needs to send a request to SAP Integration Suite. The rest of the JavaScript handles various things:

Use the JavaScript method 'fetch()' to send requests to the server
Handle security and authorisation
Getting a token if needed
Sending a token with requests
Handling errors
If successful, capturing the returned data
Working through the returned data and updating the HTML
Creating cards for the summary view
Creating a table for the detailed view

Here is the JavaScript.

Point 9. Web app: backend server

Purpose: Allow a web frontend to communicate with SAP BTP.

What is it: A JavaScript web backend server for message formatting and routing.

The backend server is locally hosted on our computer for this test/demo, but in reality would be on a web server somewhere.

It's written in express, which is a framework on Node.js. It's quite different from frontend JavaScript.

The logic of the backend is:

Listen for communication from the frontend
If a message is received:
- Do some manipulation of the message related to authorisations
- Using fetch() try sending a request to SAP Integration Suite
- More authorisation/security handling
- If successful, return the response back to the browser
- If unsuccessful, log and return the error.

Here is the backend JavaScript code. This needs to be set up as part of a Node.js server.

The JavaScript server is a bit more complex than the frontend. The server folder contains:

```
web-app-server/
├── node_modules/ # created by npm install
├── package-lock.json # created/updated by npm install
├── package.json # you write this (or generate with `npm init`)
└── server.js # your server code
```

server.js contains the actual JavaScript code for the server.
package.json defines project settings, dependencies, and scripts.
node_modules/ and package-lock.json are automatically generated when dependencies are installed using npm install.

The port can be specified in 'server.js'. I choose port 5000.

This means the server will run on 'http://localhost:5000'.

After writing package.json and server.js, the following steps are required in terminal to initialise the server, install express, and then start the server.

cd web-app-server
npm init -y
npm install express
node server.js

We can now update the flow diagram with the details for the frontend.

One flow, many messages

Looking at the diagram, a click on the search button triggers a message that passes through four stages:

From the frontend (browser) to the backend web server
From the web server to SAP Integration Suite
From Integration Suite to Cloud Connector
From Cloud Connector to the S/4HANA system

JavaScript doesn’t normally “wait” for things to happen — it’s designed to keep running while other operations (like network requests) complete in the background.

However, the fetch() function is asynchronous, which means it starts a request and immediately returns a kind of “promise” — a placeholder that will eventually be resolved when the response comes back (or if it fails).

When testing this flow, there are multiple layers where errors can occur:

The browser console (frontend logs)
The backend server console (Node.js logs)
Integration Suite’s monitoring tools

The message can fail at any step, and it sometimes takes a bit of detective work to figure out where it failed and why.

If everything works, and S/4HANA returns a successful response (status code 200), that response flows automatically back through the same chain — each layer staying in a “waiting” state until the result is passed back to the frontend and displayed to the user.

Don't worry if it's not 100% clear, it took me a while to figure this out.

Conclusions to the walkthrough

It's really fun to build your own frontend and connect it to a real enterprise grade system.

A few important considerations:

Precision is needed with the integration configuration:
- Host names, types, routing, transformation are all sensitive to mistakes
The JavaScript is a little complex, but it is all well established
A JavaScript and Node.js course and some googling could enable anyone to create this.
Using the S/4HANA business partner mock server is a quick and fun way to test out a potential integration with S/4HANA. However, it is just a mock server with limited features and a build and test with a real S/4HANA system would be required.

However, it's easily achievable with a little study and practice and it opens the possibility to develop a wide range of things.

The APIs brings together:

Real-time fast access to a wide range of business data thanks to S/4HANA.
Extreme flexibility on the frontend side thanks to modern HTML, CSS and JS.

This integration could have been much simpler by just having the frontend deliver a URL in the format required for the API. We don't really need the complexity of Integration Suite for this.

---

Part 3: building the integration flow (for IT people)

In this section I'll share my rough notes from the process of building this front end and integration flow. This is a copy and paste of my original notes in markdown so I apologise for the lack of formatting. I do list all the required tools which may be helpful for people trying this out.

Before starting, I'd recommend working through the CodeJam:

SAP CodeJam
The instructions are on a GitHub repository.

Information sources & tools

SAP Accounts: BTP and Integration Suite

A trial account for business technology platform is required.

[BTP trial](https://developers.sap.com/tutorials/hcp-create-trial-account.html)

And a a trial for Integration Suite

[Integration Suite trial](https://developers.sap.com/tutorials/cp-starter-isuite-onboard-subscribe.html#f55ec71c-2853-4b83-8092-4e3031f8d6e6)

See the pre-requisites [pre-requisites](https://github.com/SAP-samples/connecting-systems-services-integration-suite-codejam/blob/main/prerequisites.md) document in the CodeJam repository.

Containerisation & Docker

When running the S/4HANA business partner mock server locally, one option is to install the necessary JavaScript runtime environment and run it manually. Another option is to run it inside a container.

Containers are a key concept in Cloud architecture.

A container packages an app and all it's dependencies together so that it can run independently of the underlying computer (server, laptop, etc.).

This is a key concept for Cloud as it allows applications to run on different hardware and operating systems with minimal set up effort.

Docker is a platform to build and manage containers.

Docker and container features:

- Package an app and all it's dependencies
- A container is like a lightweight virtual machine
- Key terms
- image: blueprint (.zip) containing app, dependencies, and OS
- container: running instance of an image
- dockerfile: instructions to build image
- volume: how to persist data outside the container
- port mapping: expose internal port to machine (e.g. 8080 to 3001).

I'll come back to this in the section on running the BP mock server.

Data basics

The following data standards/formats are used in this exercise:

JSON (JavaScript Object Notation)

- A lightweight, human-readable format for storing and sharing structured data
- Looks like nested key-value pairs (like a shopping list with categories)
- Commonly used in web apps and APIs for sending data between systems.

For example:

```JSON
{
"employee_id": "1234567",
"employee_name": "Alexander"
}
```

XPATH

- A query language used to navigate and extract data from XML or HTML documents
- Lets you point to specific elements using a path-like syntax
- Example: find the third paragraph inside a section
- Used in tools like web scrapers and automation scripts.

For example:

```XPATH
//title[contains(text(), 'Programming')]
```

XML (eXtensible Markup Language)

- A flexible, tag-based format for representing structured data
- Similar to HTML in appearance
- But used for data storage and exchange, not page display.

For example:

```XML
<book id="bk01">
<author>Roan, Alexander</author>
<title>Front end to S/4HANA</title>
```

HTML (HyperText Markup Language)

- The standard language for building web pages and displaying content in browsers
- Uses tags to define elements like headings, paragraphs, links, and images
- Focused on structure and layout, not data exchange.

Terminal

I worked through this demo/test on Mac so I used Terminal, which is the Mac default command line interface (CLI).

The CLI is necessary for activities such as setting up and starting servers or working with docker containers.

Terminal basics

- Open a folder `cd <folder name>` (change directory)
- `cd` on it's own will go to the home directory
- (Note that `~` represents home directory in terminal)
- `cd ..` will go up a folder
- List folders `ls` (list files in the current directory)
- Open a file `open <file name>` (open a file)
- Quit sub-screen and return to terminal `q`
- Stop a running process hold control and c
- Clear terminal `clear`

To run JavaScript servers, JavaScript runtime is required. It's easier to install and manage things like this using a package manager in Terminal. Homebrew is a popular package manager for Mac.

Homebrew

- A package manager for Mac
- To install homebrew homebrew:
- Launch terminal (launchpad > other > terminal)
- Visit [Homebrew](https://brew.sh/) in your web browser
- Copy the installation command
- Paste it into terminal press enter.

Java/JavaScript

To complete the demo/test a few different JavaScript things are needed.

Node.js

- This is a JavaScript that can be installed locally to create and run web-servers and web applications
- Install using Homebrew
- In terminal, enter: `brew install node`
- Test the installation of Node.js
- In terminal, enter: `node -v`, it should return the node version number.

NPM

- NPM is the node package manager
- It's installed with Node.js
- It's used to run a server
- Install it in any directory a Node.js server sits in
- To check the installation of NPM
- In terminal, enter: `npm -v`, it should return the npm version number

Java development kit (JDK)

- Cloud Connector is a more complex application and requires JDK
- More notes in the Cloud Connector section.

API client (Bruno/Postman)

The CodeJam utilised [Bruno](https://www.usebruno.com/) for API testing.

For the CodeJam a folder of pre-configured settings for Bruno is provided. However I'd suggest to start experimenting without the pre-configuration to build a solid understanding of the basics.

I'll include more notes in later sections.

Building and testing an integration flow

Set up the S/4HANA business partner mock server

Start by setting up the S/4HANA business partner mock server

- Download the mock server from [GitHub](https://github.com/SAP-archive/cloud-s4-sdk-book/tree/mock-server)
- Scroll down to the readme
- Either download the archive linked under 'How to run this server'
- Or if using GitHub clone the repository and checked the branch 'mock-server'
- Move it to a convenient folder of your choice
- I set it a `users/<username>/projects/integration/cloud-s4-sdk-book`

Run the server: option 1: use NPM

Node.js and the node package manager (NPM) can be used to run the server directly on a computer.

- Open terminal
- Navigate to `users/<username>/projects/integration/cloud-s4-sdk-book`
- (or wherever you saved the folder)
- Enter: `npm install` (install node package manager in the folder)
- Enter: `npm start` (start the server)
- This should return something like:

```shell
> bupa-mock-odata@1.0.0 start
> node server.js
Mock server started on port 3000 after 1 ms, running - stop with CTRL+C (or CMD+C)...
```

Terminal tells us which port the server is running on. Port "3000" is accesible in the browser or an API client via "http://localhost:3000".

To stop the server in terminal use `ctrl+c`.

For the curious, you can look at the files that make up the mock server in the above folder. Check out:

- server.js
- This includes the JavaScript code for the server
- The code references other files such as app.js
- package.json
- This is like a configuration file for a node.js server
- business partner > business-partner-data.json
- This contains the demo test business partner data.

Theoretically you could use this Node.js server as a template to simulate other SAP Odata APIs with some adjustments to these files.

Run the server: option 2: use Docker

The mock server can also be run as a Docker container. This is a little more convenient as after the first run we can stop and start it from the Docker desktop app.

Note the server already has a Dockerfile, so it's already set up to run as a container.

If we run something inside a docker container we need to interact with it via ports on the container. The application is really running contained inside a container. When we run a docker container we provide a mapping between a local port on the computer and the container port. We can then access the docker application via this mapping.

To run as a Docker container:

- Launch the docker app
- Open terminal
- Enter `docker run -p 3005:8080 bp-mock-server`
- 3005 is the local port
- 8080 is the docker container port
- Local port can be any free port on your computer. I choose 3005
- The container port is 8080
- View the status of the container in the Docker app
- Use the browser to check `http//localhost:3005`

Note if there wasn't already a dockerfile we would need to create one and build the app before running it.

**A simple docker demo**

This was my first time using docker, so I experimented by creating a simple "Hello, World!" style server from scratch. Here it is if you want to try:

- Create a JS file "index.js"
- Add `console.log("hello from docker");`
- This just prints text to the console (Terminal)
- Create a package file "package.json"
- Add the following JSON to "package.json"

```json
{
"name": "hello-docker",
"version": "1.0.0",
"main": "index.js",
"scripts": {
"start": "node index.js"
}
```

- Create a dockerfile "dockerfile"
- Add the following to "dockerfile"

```Dockerfile
FROM node:18

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["npm", "start"]
```

You can see Docker uses NPM, in the same way we would with a manual run, but it's installing and running NPM inside the container, not on the computer.

To build and run:

- Build docker container `docker build -t hello-docker .`
- Run docker container `docker run hello-docker`

Testing with the web browser

The simplest way to test the API is running locally is to put the local address in the web browser.

- For NPM it was "http//localhost:3000"
- For docker image it was "http//localhost:3005"

The main domain should return the API details including the links such as:

"http://localhost:3000/sap/opu/odata/sap/API_BUSINESS_PARTNER"
"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER"

To access the service to return the general data of all business partners we add A_BusinessPartner

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner"

In the browser, this should return a JSON document containing the list of business partners.

We can pick a business partner number from the list and use it with the path to select a specific business partner:

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1003764')"

Testing with an API client (Bruno)

Rather than just using the web browser to check the API an API client can be used, this has a few benefits:

- We can build the URLs through a selection of 'input fields'
- We can save different requests for easy and quick re-testing
- We can pass data in the request body

To test with Bruno:

- Launch Bruno
- Use the '...' menu to create a collection
- Name it 'bp-mock'
- Specify a location. I used "users/{username}/projects/integration"

Create a request for all business partners

- Use the '...' menu next to bp-mock and select 'new request'
- Enter request name 'All business partners'
- Under URL select 'GET' and enter the URL that returns all business partners
- `http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner`

Run a request

- Look to the right of the 'GET' line on the main page and click the '->' to run
- The right panel will show the JSON response
- The same response as shown earlier in the web browser.

Create a request for a single business partner (1003765)

- Use the '...' menu next to bp-mock and select 'new request'
- Enter request name 'Specific business partners'
- Enter the same URL details as above.
- In the 'params' tab click '+ param' and enter
- Name: `&filter`
- Path: 'BusinessPartner eq '1003766'
- Run the request. A single business partner should be returned.

Note as the params are entered the URL dynamically updates.

Basics on OData API URLs

- The base for the API is "/API_Business_Partner"
- A service of the API is then appended "/A_BusinessPartner"
- Queries can then by added, OData queries include:
- Filtering: `/A_BusinessPartner?$filter=Name eq 'Max'`
- Selecting fields: `/A_BusinessPartner?$select=Name,City`
- Pagination: `/A_BusinessPartner?$top=5&$skip=10`
- Accessing nested data: `/A_BusinessPartner?$expand=Address`
- When working with OData:
- Field names are case sensitive
- String values in single quotes

Keep in mind the S/4HANA mock business partner server only includes limited functionality. The above filters and selects won't work.

Java SDK for SAP Cloud Connector

The next step is to set up SAP Cloud Connector

Recall Cloud Connector will provide a secure tunnel allowing SAP Cloud to talk to the S/4HANA business partner mock server.

Cloud Connector requires a full Java Development Kit (JDK).

- You can use "javac -version" in terminal to check if you already have JDK
- There is a SAP Help page for [Cloud Connector](https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/cloud-connector?locale=en-US)
- Check the [prerequisites](https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/prerequisites?locale=en-US#jdks) section, it lists the JDK options
- I choose SAP machine 21 JDK
- You can download this from [GitHub](https://sap.github.io/SapMachine/)
- I have a dev folder for items like this in my home folder
- "Users/{username}/dev"
- Use Homebrew to install
- Open terminal and enter "brew install openjdk@21"

It's likely you may run into version, compatibility, authorisation issues. These are all very common and a web search should help.

Install Cloud Connect

Next install Cloud Connector.

Cloud connector is listed under the SAP development tools page under [Cloud](https://tools.hana.ondemand.com/#cloud).

- Download the cloud connector file for your OS
- My Mac is Apple Silicon so I chose 'sapcc-2.18.1.2-macosx-aarch64.tar.gz'
- Unzip and move it to a folder of your choice
- Navigate inside the downloaded folder in terminal
- Check contents with 'ls', you should see a 'go.sh' file
- Enter: './go.sh' this will run Cloud Connector
- Cloud connector should now be running, note the address in the terminal log
- Login with default account: 'Administrator' and password: 'manage'
- Change password
- Keep a note of the account and password.

I received authorisation issues on the first attempt to run it:

- Click through them, then goto apple > settings > privacy&security
- Scroll down to security and click 'allow anyway'
- Try: './go.sh' again.

Install and set up SAP Integration Suite

To continue from here SAP Integration has to be installed and active as per the earlier instructions.

Connect SAP Cloud Connector to SAP Integration Suite

As Cloud Connector bridges between SAP Cloud and the S/4HANA business partner mock server we need to set it up to connect to SAP Cloud. We get the security/authentication data to do this from our SAP BTP trial account.

- After logging into Cloud Connector click '+Add Subaccount'
- Hit 'next' to skip the HTTPS settings
- Select 'Configure using authentication data'
- Select 'Add subaccount authentication data from file '
- In your browser got to your SAP BTP trial homepage
- Click on your subaccount
- On the left menu expand Connectivity and select Cloud Connectors
- Click on 'download authentication data'
- Return to Cloud Connector
- Click browse and select the downloaded file 'authentication.data'
- Click next
- Leave location ID blank
- (This would be relevant if there were multiple Cloud Connectors)
- Click finish.

Double check the settings in the subaccount overview:

- BTP trial region = Cloud Connector region
- BTP Subaccount ID = Cloud Connector Subaccount
- The region host in Cloud Connector = Cloud Foundry API Endpoint in BTP.

Cloud Connector to Mock BP Server

There's no security on S/4HANA business partner mock server so it is simply a matter of adding the address.

- In Cloud Connector, on the left sidebar click 'Cloud to On-Premise'
- To the right of 'Mapping Virtual to Internal Systems' click `+`
- Select back-end, enter: "Non-SAP system", click 'next'
- Select protocol: "HTTP", click 'next'
- For internal host enter "localhost"
- For internal port enter: "3005"
- For virtual host: "s4-mock"
- For virtual Port: "3006"
- Uncheck allow principal propagation
- Click through to finish.

Replace the internal port name with the one your mock server is running on locally. You are free to choose the virtual host and port.

It's critical to select "Non-SAP system" and HTTP, not HTTPS.

A new entry will appear under 'Mapping Virtual to Internal Systems'

- Make sure your mock bp server is still running on the host and IP you entered
- From the icons on the right, click on 'check availability..'
- You should see status 'reachable'

At this stage `https://localhost:3005` is now mapped to `https://s4-mock:3005` in the SAP Cloud.

You can also check in integration suite to see if Cloud Connector is connected.

- In the left hand menu select connectivity > cloud connectors.

Errors at this stage are likely related to

- Mistakes in the host name, port name, or system type
- The mock server or cloud connector is not running.

Design integration flow

Create an integration flow

- Login to BTP trial home
- From the left hand menu expand Services and select Instances and subscriptions
- Under 'Subscriptions' click on 'Integration Suite'
- On the left menu select expand 'Design' and select 'Integrations and APIs'
- Choose 'Create' on the top right to create a new package.
- Give it a name
- Shift to the 'Artifacts' tab
- Select 'Add' and choose 'Integration Flow' from the list
- Give it a name
- Click add
- Click on the newly created integration flow

The integration flow screen is read-only by default, click edit.

Set up the sender

Define an 'address' for the SAP Integration Suite endpoint.

- Click on sender
- Click connector arrow
- Drag to start event
- In adapter type pop-up select HTTPS
- To configure the adapter click on the drawn line (if not selected)
- The settings are in the bottom panel, drag it up to expand it
- Navigate to 'connection' tab, enter the following:
- Address: `/request-business-partners`
- Authorisation: `User Role`
- User Role: `ESBMessaging.send`
- CSRF Protected: `Unchecked` (Cross-site request forgery).

Add flow elements

The CodeJam has excellent instructions for walking through different flow steps as per their exercises.

I will summarise a few elements I used in my design.

Router

![Router](/assets/images/blog/integration/Integration-23-A.png)

- The router allows you to split the flow based on a condition.
- This example splits the flow into 4 based on the incoming URL
- For example where the incoming URL ends in "single/add"
- Re-call our integration flow address was "request-business-partners"
- In this case a message arrives to "request-business-partners/single/add"
- Intelligent Suite assigns the last part to the variable CamelHttpPath
- Which is part of the message header hence: header.CamelHttpPath.

The route path we are looking at in this example is the one that returns a single business partner with address data.

Content modifier - case 1

Case 1:

- The content modifier allows us to modify the message header or body.
- In the above screenshot a content modifier is added directly after the routing.
- This deletes the CamelHttpPath, in this case "single/add"
- After routing we no longer need this part of the URL in the message header.

JSON to XML converter

- This converts the JSON in the message body to XML.
- In the case of searching for a single BP the message body includes JSON:

```JSON
{
"employee_id": "1234567"
}
```

- This will be converted to XML

```XML
<root>
<employee_id>1234567</employee_id>
</root>
```

Content modifier - case 2

![Content modifier](/assets/images/blog/integration/Integration-23-B.png)

- In this case the content modifier gets "employee_id" from the message body
- And assigns it to a new variable
- XPath can be used to access the XML value
- "/root/employee_id"
- The variable name is set as employee_id
- The data type is set as a Java string.

Request Reply

Request reply let's us send a request to a server.

- Click on the Set employee_id
- Click add flow step on the canvas
- Select 'Request Reply' under call > external call
- Click on 'Request Reply'
- Click on 'connector' and drag to the receiver
- Select adapter type 'HTTP'
- Under 'HTTP' in the connector properties, select 'Connection'
- Enter the address of the cloud connector:
- The path for a single business partner with address data involves updating:
- Address: "http://s4-mock:3006/sap/opu/odata/sap/API_Business_Partner/A_BusinessPartner('${property.employee_id}')"
- Query: "$expand=to_BusinessPartnerAddress"
- Proxy Type: `On-premise`
- Method: `GET`
- Authentication: `None`
- Save
- Deploy

To check deployment status go to Monitor > Integration and APIs. On this page the endpoint to access the service is shown:

"https://{your trial}-cpitrial03-rt.cfapps.ap21.hana.ondemand.com/http/request-business-partners"

Test Cloud Integration with API client

At this point we can test consuming the API through SAP Integration Suite.

Unlike testing the local mock server, we need to deal with authentication and security. The way this works is:

- We pass a "client id" and "secret" to a "token URL"
- BTP passes back a "token" which is valid for a certain period of time
- This "token" has to be attached to any requests to the API in Intelligent Suite.

Accessing security details

- Navigate to your BTP trial account
- Expand services and click on 'instances and subscriptions'
- Scroll down to instances and look for your integration flow instance
- Integration Suite uses Cloud Foundry so the runtime will be cloud foundry
- It will likely be named 'default_it-rt_integration-flow'
- Scroll down to service keys and click on the service key, note the values for:
- "clientid"
- "clientsecret"
- "url"
- "tokenurl"

For local testing we can hardcode these values in our test tools, but be careful not to upload or share these anywhere.

In production, never hardcode secrets or tokens. Use environment variables or a secure credential store.

**Request a token with Bruno**

In Bruno create a new request:

- Name: `TOKEN`
- Method: `POST`
- URL: enter the "tokenurl" from above
- Navigate to the Params tab:
- Select 'Add Param'
- Enter name: `grant_type` path: `client_credentials`
- Navigate to Auth
- Switch 'Inherit' to 'Basic Auth' and enter:
- Username: `client_id`
- Password: `client_secret`
- Save

Send the request. This should return a JSON document with a long value in "access_token". There should also be a expiry time e.g. 4199 seconds.

When sending a request, if the token is not valid Integration Suite will return a 401 error code. This means we need to request a new token.

Within Bruno we can save this token value to a variable. This saves us from copying and pasting it into other requests.

- Goto Environments > Configure > Create Environment
- Name: 'integration-flow'
- Click '+ Add Variable'
- Enter name: 'access_token'
- For value, leave it blank
- Save and close

Navigate to 'scripts' under the TOKEN request. Under Post Request enter:

```JS
if (res.status == 200) {
const token = res.body.access_token;
bru.setEnvVar("access_token",token);
}
```

- If the request receives a response (status 200)
- Get the access_token value from the response
- Assign to environment variable "access_token".

Save and run the TOKEN request.
Goto the environment and click 'configure'. You should see the access_token variable updated with the value from the response.

**Test the API with a request with for a single BP**

- In Bruno create a new request
- Name: "BP via integration suite"
- URL: "https://{your-trial}.it-cpitrial03-rt.cfapps.ap21.hana.ondemand.com/http/request-business-partners"
- Replace the above with your actual endpoint from Intelligent Suite.
- Navigate to the 'Auth' tab
- Click on 'Inherit' and change to 'Bearer Token'
- In Token enter: `{{access_token}}`
- This eferences an environment variable in Bruno
- Add the request body
- The JSON with our employee ID

```JSON
{
"employee_id": "1003764"
}
```

Building and testing a frontend

At this point a request to SAP Integration Suite should be successfully routed and transformed to the S/4HANA business partner mock server.

The next part would be building and testing the web app. However, there is too much to cover in building and testing the frontend to cover in this post. I may produce a video on this if anyone is interested.

Final thoughts

This technology stack is definitely a bit overkill for a simple 'search' portal, but it is fairly easy to put together as long as you are careful when specifying paths, hosts and port names.

If you'd like to discuss further please feel free to connect on LinkedIn - Alexander Roan

🔐 Strengthening SAP BTP Security: SSO with Cloud Connector Using Token-Based Auth (Replacing SUSER)

2025-08-22T11:13:39.813000+02:00

About Me

Hare Krishna 🙏 I am an SAP BTP Cloud Architect sharing practical insights, solutions, and real-world experiences from the SAP ecosystem.

🌍Introduction

Security is at the heart of SAP BTP (Business Technology Platform) administration. Traditionally, basic authentication with SUSER credentials was required when connecting SAP Cloud Connector (SCC) with a BTP subaccount. While functional, this approach has critical drawbacks:

⚠️Static credentials stored in config
⚠️Weak auditability
⚠️Complex user/password management

With the adoption of token-based authentication and Single Sign-On (SSO) using a Custom Identity Provider (IdP), SAP now offers a smarter and more secure way of handling access. This blog explains how the shift strengthens security, simplifies user management, and eliminates the dependency on SUSER credentials.

🚀What’s New: Token-Based Authentication for the SCC ↔ Subaccount Link

Instead of sending an S-user + password when adding/maintaining the subaccount in SCC, you trigger an SSO flow: the subaccount’s trust configuration redirects to your Custom IdP, issues a short-lived token, and BTP validates it to complete the SCC connection.

Why it matters

❌No static S-user secrets in SCC
✅Short-lived tokens + centralized IdP policies/MFA
✅Clean audit trail and easy revocation

⚙️Step-by-Step Configuration (Corrected)

Step 1 — Configure Custom IdP in the BTP Subaccount

BTP Cockpit → Subaccount → Security → Trust Configuration
Add/enable your Custom IdP (SAP IAS / Azure AD / Okta, etc.) for user logon
Ensure metadata/trust is correct (SAML/OIDC per your org standard)

Step 2 — Provision the Admin & Map Roles (in Subaccount)

Ensure the admin user exists in the subaccount and is mapped to the Custom IdP
Assign the Cloud Connector Administrator role collection (name may vary by tenant)
⚠️Without this mapping, the token flow will fail when SCC tries to connect

Step 3 — Connect SCC to the Subaccount via Token-Based SSO

In SCC Admin UI → Subaccounts → Add / Maintain Subaccount
Choose token-based/SSO (not username/password)
The flow opens the BTP subaccount trust → redirects to your Custom IdP
Authenticate as the mapped admin; on success, BTP validates the token and SCC shows the subaccount as connected

Step 4 — Validate the Connection

Confirm SCC shows Connected (region, Subaccount ID, location ID as applicable)
Optionally verify in BTP cockpit (Connectivity / Cloud Connector view) that the subaccount link is healthy

Step 5 — Existing Subaccounts (Legacy) – Do It at Certificate Renewal

🔄For old subaccounts already connected with S-user: switch to token-based SSO during the certificate renewal window.
Keep the same subaccount; update trust to Custom IdP (if not already)
Re-establish the SCC ↔ subaccount link using token-based SSO (no S-user)
This upgrades security without spinning up a new subaccount

🛡️ Key Benefits

No S-user secrets stored in SCC
MFA & policies enforced centrally at your IdP
Auditable (IdP + BTP logs)
Lower ops overhead (no password rotations, fewer incidents)

🏗️ Architecture Flow — SCC ↔ Subaccount Token-Based SSO

[Cloud Connector]
│ (1. Connect/renew request to subaccount)
▼
[SAP BTP Subaccount – Trust Configuration]
│ (2. Redirects to Custom IdP for auth)
▼
[Custom Identity Provider (IdP)]
│ (3. User/admin authenticates → token issued)
▼
[SAP BTP Subaccount]
│ (4. Validates token & completes trust)
▼
[Secure Connection Established: SCC ↔ Subaccount]

Step notes

SCC initiates the subaccount connection (add/renew).
Subaccount trust hands off to your IdP.
IdP authenticates the mapped admin and issues a token.
BTP validates token; the SCC ↔ subaccount link is finalized—no S-user.

📸Real-Life Example (With Screenshots)

Here’s how this setup looks in actual environment( BTP trial account is used for performing this setup)

Create user in SAP BTP Subaccount, Provide Cloud Connector administrator privileges.

We will. be using IAS as custom identity provider. Create User in IAS as shown below:

Make sure Subaccount is connected to IAS using OIDC or SAML Protocols In trust configuration.

Now Create URL like shown below: The URL pattern is https://<subdomain>.authentication.<btp-XSUAA-host>/passcode.

When you access the URl, It will redirect to IAS for authentication

Post successful User authentication, Temporary authentication code is generated. Use it in Cloud connector

Update the token in cloud connector configurations shown below:

Cloud connector is successfully connected to Subaccount.

Now for Legacy systems, where users are already using SUSERID and password, while cert renewal, we can use the SSO mechanism to generate token and renew the certificate.

click on enter user and password

Enter Username , and generate the token using URL pattern is https://<subdomain>.authentication.<btp-XSUAA-host>/passcode.

Token is successfully generated

Certificate is renewed successfully

Cloud connector is successfully connected in Subaccount:

📌Lessons Learned

The security move is about the SCC ↔ subaccount link, not just SCC UI logon
Provisioning & role mapping in the subaccount is critical for the token flow
Use the certificate renewal window to modernize legacy S-user connections with minimal disruption

❓FAQs

Q1. Do we still need S-user anywhere for this connection?
👉No. After token-based SSO is configured, the SCC ↔ subaccount link does not use S-user.

Q2. Which IdPs are supported?
👉SAP IAS, Azure AD, Okta, Ping, etc., via SAML/OIDC per enterprise policy.

Q3. Extra cost?
👉No new SAP license; enterprise IdP subscriptions/policies apply as usual.

Q4. Is this mandatory for all subaccounts now?
👉Not mandated, but it’s the recommended security posture going forward.

Q5. Must the admin user exist in the subaccount?
👉✅Yes. The user must be provisioned in the subaccount, mapped to the Custom IdP, and assigned Cloud Connector Administrator. Otherwise, the SSO/token step fails.

Q6. How do old subaccounts switch from S-user to token-based SSO?
👉✅Use the certificate renewal process to re-establish the link with token-based SSO—no new subaccount needed.

🎯Key Takeaway

Modernize the SCC ↔ subaccount connection with token-based SSO. You’ll remove S-user secrets, enforce corporate IdP controls (MFA, policies), gain clean auditability, and cut down operational toil. For legacy links, plan the switch at the next certificate renewal.

🔹Bonus Update – What’s New in Cloud Connector

Although this blog is about SSO in Cloud Connector, here’s a quick surprise update:

SAP introduced a new option to upload authentication data starting with Cloud Connector 2.17.0 (released in May 2024).

Instead of manually entering region, subaccount ID, and other details, you can now simply upload the authentication.data file.
This file is generated using the credentials of the user you log in with to the BTP cockpit.
⚠️That user must have the necessary authorizations to perform Cloud Connector administrator tasks in order for the upload to succeed.
This makes subaccount onboarding and certificate renewal much easier and less error-prone.

So if you’re running Cloud Connector 2.17.0 or newer, you can take advantage of this simplified workflow.

Below are the steps with screenshots:

In Cloud connector when we add Subaccount, Select option "Configure using authentication data from File"

It will successfully connect the Cloud connector with Subaccount using the UserID of user which you used to login to BTP cockpit.

Same process can be followed for renewal of certificates as well !

How-to Guide: Provisioning Users from LDAP (Docker-based) into SAP Cloud Identity Services (IPS)

2025-08-28T18:44:06.372000+02:00

Setting up user provisioning from a corporate LDAP into SAP Cloud Identity Service (CIS) — Identity Provisioning (IPS) is not the most common task — most customers today rely on Microsoft Entra ID (in sync with AD FS, for example).

But sometimes LDAP is still needed. I decided to reproduce this scenario and, at the same time, get my first hands-on with Docker: run OpenLDAP, connect User Interface, wire it through SAP Cloud Connector, and test provisioning into CIS → Identity Directory (IdDS).

Goal

Spin up OpenLDAP in Docker with a GUI (phpLDAPadmin).
Configure Docker networking and port mapping.
Connect LDAP to SAP Cloud Connector (SCC).
Set up Identity Provisioning (IPS) to write into CIS.

The beauty of containers is their lightweight nature and the ability to spin up everything with a single script.

For this setup I used:

bitnami/openldap → the LDAP server holding user entries.
osixia/phpldapadmin → the GUI for user administration, so I don’t have to manage everything via CLI.

By exposing ports from the internal Docker network (via docker-compose), you can:

access phpLDAPadmin locally in the browser to create test users,
connect a local SAP Cloud Connector instance to the same LDAP through the mapped port, and then expose it into your BTP Subaccount.

Next step: solving a few practical issues.

Step 1. Running OpenLDAP in a container

Problem: OpenLDAP by default only listens inside the container (389) and is not accessible from the host.
Solution: map a host port, e.g. 13890:389.

Step 2. Docker Networking (docker-compose)

Problem: containers may not see each other by hostname if not attached to the same user-defined network. Basic networking tools (nc, telnet) are also missing inside the images.
Solution: create a custom Docker network in docker-compose and connect both openldap and phpldapadmin to it. Inside the network use port 389; for external access, use the mapped port.

Step 3. phpLDAPadmin Integration

Problem: phpLDAPadmin expects to connect to localhost:389 by default.
Solution: configure environment variables in docker-compose.

Intermediate Result

OpenLDAP and phpLDAPadmin are up and running in Docker.
Internal networking and port mapping are configured.
You can now add test users via GUI and prepare LDAP for SCC → IPS integration.

Connecting SAP Cloud Connector (SCC)

In SCC, create a new connection for your BTP Subaccount using LDAP protocol, pointing to localhost:13890.

Back-end Type	Protocol	Internal Host	Virtual Host	Principal Type
Non-ABAP System	LDAP	localhost:13890	ldap:389	None

Important: your Subaccount must have the Connectivity service plan enabled in SAP Cloud Identity Services. This allows IPS to reach on-prem systems via SCC.

After successful setup, BTP Cockpit shows something like:

Exposed Back-End Systems (SCC Location ID)

ldap:389

LDAP

Non-SAP System

Available

Configuring Identity Provisioning (IPS)

In IPS, create an LDAP source according to the usual SAP Help documentation. You can use default Transformations here. Key detail: the LDAP user object must contain the mail attribute. If not present, IPS will skip the entry. Even the two default users shipped with the OpenLDAP container are enough to test the provisioning chain.

End-to-end check:

LDAP → SCC → BTP → IPS → Identity Directory

Conclusion

Using containers makes it extremely fast to spin up a fully working LDAP provisioning scenario for SAP BTP. This approach is safe and easily reproducible also for testing transformations and mapping without touching a production corporate directory.

P.S. Below you can find my docker-compose.yml file as a reference for your own setup:

services:
  openldap:
    image: bitnami/openldap:latest
    container_name: openldap
    environment:
      LDAP_ADMIN_USERNAME: admin
      LDAP_ADMIN_PASSWORD: password
      LDAP_PORT_NUMBER: 389
    networks:
      ldap-net:
        aliases:
          - openldap 
    ports:
      - "13890:389"
      - "16360:1636"

  phpldapadmin:
    image: osixia/phpldapadmin:latest
    container_name: phpldapadmin
    environment:
      PHPLDAPADMIN_LDAP_HOSTS: openldap
      PHPLDAPADMIN_HTTPS: "false"   # deactivate HTTPS
    networks:
      - ldap-net
    ports:
      - "8080:80"
    depends_on:
      - openldap
      
networks:
  ldap-net:

SAP Build Work Zone Security

2025-09-02T08:56:52.779000+02:00

I've been spending quite some time recently diving deep into SAP Build Work Zone security, and let me tell you, it's a journey. Terms like #IAS, #BTP Subaccount #trusts, and #ShadowUsers can sometimes feel like a maze.

But then, an analogy clicked for me - the #DigitalMall and suddenly, the whole complex architecture started making perfect sense. I wanted to share this breakdown with all of you, hoping it helps.

Let's imagine SAP Build Work Zone as a bustling, modern Digital Mall, where users (you, the #shoppers) come to access various #stores (business applications) and "services" (collaboration features). Every security layer has a purpose, just like every part of a well run mall

#TheGrandOpening: Understanding this Digital Mall's Foundation

Before anyone even walks in, the mall has a master plan and a way to organize its offerings:

>>> SAP BTP Subaccount: Think of this as the Mall's Main Entrance & Security Gate. It's the primary gateway, controlling who can even step foot inside your digital space. It's where core permissions are managed.

>>> SAP Build Work Zone Tenant: This is your specific, unique instance of the Mall itself - your personalized shopping experience!

>>> #ContentManager: This acts like the Mall's Central Directory or Information Kiosk. It lists all the "stores" (your business applications) available within the mall, helping shoppers find what they need

>>> Content Providers: These are the "Department Stores" (like SAP S/4HANA
SuccessFactors) or even smaller "Boutiques" (your custom applications). They reside outside your immediate mall structure but integrate seamlessly, making their offerings available inside your Work Zone.

>>>>Stepping Inside: Your Identity & Basic Mall Access<<<<

Now, for the really crucial part: how does a "shopper" (your user) actually get into the Digital Mall, and how is their identity validated at the main entrance?

>>> #SAPCloudIdentityServices - Identity Authentication (IAS): The Mall's Central Security System / ID Proxy

This is the mandatory first stop for any user trying to enter your Work Zone mall. #IAS is your primary #IdentityProvider [IDP]

>>> #Proxy Mode: If your organization uses its own Corporate IdP (like Azure AD, Okta), IAS acts as a clever proxy. You authenticate against your corporate system, and IAS then receives that verified identity, federating it onward in a way Work Zone understands. It's seamless, you just show your corporate ID.

>>> #TheDigitalIdCard (SAML Assertion / OIDC Token): Once authenticated, IAS issues a secure token. This token is packed with vital information, essentially your digital "ID Card" that gets you past the main gate:

>>> #SubjectNameIdentifier (SNI): This is your main identifier (e.g., your Login Name or Employee ID). It's what the BTP Subaccount primarily uses.

#Assertion Attribute (often IAS UUID): This is a unique, stable, and persistent ID assigned by IAS. It's super important for internal Work Zone component communication later on, especially with the DWS (our "Community Center," which I'll cover in Part 2!)

---> Other standard user attributes like email, first name, last name.

SAP BTP Subaccount Trust Configuration: The Main Gate's Agreement with IAS

Your BTP Subaccount (the main gate) has a "trust agreement" with IAS. This allows it to confidently accept those digital ID cards (tokens) from IAS.

>>> #The XSUAA Shadow User: Your Mall Access Card. This is one of the most critical concepts

When a user successfully authenticates via IAS for the first time, a "Shadow User" record is either created or identified in the BTP Subaccount's internal user list. Think of this as your personal "Mall Access Card" record.

Why is it needed? Even if IAS knows who you are, the BTP Subaccount needs its own local record (the shadow user) to attach BTP Role Collections to it. These role collections are your "Mall-wide Privileges" (e.g., WorkZone_User, WorkZone_Admin) that determine what you can do across the whole Work Zone platform.

>>>> Crucial Point: If a shadow user doesn't exist (and automatic creation isn't enabled), login to Work Zone will fail because there is no local identity to attach permissions to.

Principal Propagation: Seamless Access to Department Stores!

Once you're in the mall and launch an app from an On-Premise Backend System (like an S/4HANA Fiori app via SAP Cloud Connector), you don't want to log in again, right?

This is where ##Principal Propagation comes in! Your identity (using the IAS SNI from the BTP trust) is seamlessly passed through the BTP Destination Service and SAP Cloud Connector directly to the backend system. The S/ 4HANA system then recognizes you and authorizes your access based on your roles within S/4HANA. It's like your Mall Access Card automatically opening the staff-only doors in a department store.

This is just the exciting first step of understanding Work Zone security. In Part 2, coming next.

The Digital Workplace Service (DWS) (the Mall's Community Center).

User and User List Provisioning (how the Community Center gets its member lists).

The critical differences between Internal vs. External Users (different types of Community Center members).

And how SCIM APIs are the "automated delivery trucks" for all this data!

Stay tuned for more insights, and in the meantime, I'd love to hear your thoughts or questions on this first part in the comments below!

Happy Work Zone-ing!

Lets connect and learn together ✌️

SAP Business Data Cloud Series – Part 3: Customer-Managed or Custom Data Products

2025-09-10T04:27:11.039000+02:00

Introduction:

In Part 1(SAP Business Data Cloud Series – Part 1: Introduction to Data Products) of this blog series, we explored the fundamentals of Data Products in SAP Business Data Cloud (BDC). In Part 2(SAP Business Data Cloud Series – Part 2: Extend SAP S/4HANA Managed Data Products) we explored on how to extend SAP S/4HANA Data Products. Now, in Part 3, we dive into the practical aspect of creating custom data products for the source SAP S/4HANA Cloud Private Edition and Share it with SAP databricks.

In this article, we’ll explore a common scenario where a customer has a custom CDS entity in SAP S/4HANA and wants to harmonize its data with SAP-managed data products. We’ll demonstrate how to create a custom data product based on that custom CDS entity, for example, ZCDS_CAMPAIGN and how to delta-share with SAP databricks.

High-level Workflow for the SAP S/4HANA, Customer Managed Data Product:

Steps to create a SAP S/4HANA Customer Managed Data Product.

1. Identify, create, or extend a CDS entity: To build a customer-managed data product in an SAP S/4HANA system, the recommended approach is to leverage CDS views/entities. In this example, we’ll create a custom CDS entity as shown below.

Note: As a best practice, customers should leverage SAP-released CDS views first, extend them where needed, and only create custom CDS views when business requirements demand it. This is fully permissible under the clean core paradigm, as business requirements ultimately take priority.

@ObjectModel.usageType.dataClass: #TRANSACTIONAL
@ObjectModel.usageType.serviceQuality: #A
@ObjectModel.usageType.sizeCategory: #XL
@ObjectModel.representativeKey: 'CampaignID'
@ObjectModel.modelingPattern:         #ANALYTICAL_DIMENSION
@ObjectModel.supportedCapabilities: [ #ANALYTICAL_DIMENSION,
                                      #CDS_MODELING_DATA_SOURCE,
                                      #CDS_MODELING_ASSOCIATION_TARGET,
                                      #SQL_DATA_SOURCE,
                                      #EXTRACTION_DATA_SOURCE ]

@ObjectModel.sapObjectNodeType.name: 'CampaignID'
@EndUserText.label: 'CDS View for Campaigning Data'
@Analytics.dataCategory: #DIMENSION
@Analytics.internalName: #LOCAL
@Analytics: {
    dataExtraction: {
        enabled: true,
        delta.changeDataCapture: {
            mapping:[
                {
                    table: 'zcampaign', role: #MAIN,
                    viewElement: ['CampaignID'],
                    tableElement: ['campaign_id']
                }
            ]
        }
    }
 }

@VDM.viewType: #BASIC
@Metadata.allowExtensions: true
@Metadata.ignorePropagatedAnnotations: true

define view entity ZCDS_campaign as select from zcampaign
{
 @EndUserText.label: 'Campaign_ID'
    key zcampaign.campaign_id as CampaignId,
    @EndUserText.label: 'Campaign_Name'
    zcampaign.campaign_name as CampaignName,
     @EndUserText.label: 'Channel'
    zcampaign.channel as Channel,
    zcampaign.type as Type,
    zcampaign.start_date as StartDate,
    zcampaign.end_date as EndDate,
    zcampaign.status as Status,
     @Semantics.amount.currencyCode: 'BudgetCurrency'
    zcampaign.budget as Budget,
    zcampaign.budget_currency as BudgetCurrency,
     @Semantics.amount.currencyCode: 'ActualSpendCurrency'
    zcampaign.actual_spend as ActualSpend,
    zcampaign.actual_spend_currency as ActualSpendCurrency,
    zcampaign.created_by as CreatedBy,
    zcampaign.created_on as CreatedOn
    
}

2. SAP S/4HANA Private Cloud or On-Premise Edition requires a Cloud Connector: Configure the Cloud Connector to enable communication between your on-premise/private cloud system and SAP Datasphere (public cloud). This setup is a prerequisite for creating an SAP S/4HANA or ABAP connection in SAP Datasphere for using the replication flow feature.

SAP Datasphere Integration with SAP S/4HANA: SAP Cloud Connector Setup Guide

3. Create a Datasphere Space of Type HANA Data Lake Files: An administrator can create a space backed by SAP HANA Data Lake Files in the object store. File spaces are designed for cost-efficient staging, loading, and preparing large volumes of data.

For detailed instructions, refer to the help guide: Create a File Space in the Object Store.

Additional configuration is required while configuring the SAP Datasphere tenant. e.g. Memory must be 128GB or more. Check via SAP BDC Estimator.

If you have configured correctly then you should also see the same under the SAP Datasphere, Tenant configuration. Please note this view is only available to the SAP Datasphere system owner.

SAP Datasphere object store: Storage type will be SAP HANA Data Lake Files. In our scenario we have created a space with a name Workshop: OBJECT STORE.

4. Create a SAP S/4HANA Connection in the SAP Datasphere Object Store Space, Workshop: OBJECT STORE :

4.1 Create a new connection or use the existing connection of type SAP S/4HANA on-premise or ABAP:

4.2 Fill in the connection configuration details as show below and important step is select the cloud connector which was setup and configured in the step 2.

4.3 Provide the connection name and description:

4.4 Validate and test the connection making sure replication flows are enabled:

You can also use or create the SAP ABAP connection type for this use case.

5. Create a Replication Flow to Load Data from CDS Entity into SAP Datasphere Object Store (HDLF):
Set up a replication flow with the source system SAP_S4H_RI4 and CDS entity ZCDS_CAMPAIGN. Define the target as a Datasphere local table ZCDS_CAMPAIGN_BRONZE. This table, serving as the Bronze layer, will store source records and structures in their original form.

5.1 Create a new replication flow

5.2 Select the Source SAP_S4H_RI4 and Container (Source Objects) ZCDS_CAMPAIGN

5.3 Select the target as connection as a SAP Datasphere

5.4 Provide the target object local table name ZCDS_CAMPAIGN_BRONZE and Deploy the replication flow.

5.5 Execute the replication flow and check the run details.

5.6 Perform the merge table activity:

5.7 Post merge table activity, data will be available to preview and Test it.

6. Bronze to Silver layer medallion transformation using a Transformation Flow: In many cases, data from the Bronze layer needs to be refined into a Silver layer through transformations such as splitting, merging, adding/removing columns, joins, or unions.

In our scenario, we will split the values in the Channel column into two columns Channel, Allocated Percentage (multiple rows) and apply necessary calculations.

6.1 Create a new Transformation Flow

6.2 Define the transformation steps:

Source table:HDLFT_CAMPAIGN_BRONZE and Target table: HDLFT_CAMPAIGN_SILVER . Python script operator for performing the transformation logic.

def transform(data):
    """
    This function body should contain all the desired transformations on incoming data of Pandas DataFrame.
    Permitted builtin functions as well as permitted NumPy and Pandas objects and functions are available inside this function.
    Permitted NumPy and Pandas objects and functions can be used with aliases 'np' and 'pd' respectively.
    Python standard libraries like 'time', 'datetime', 're', 'random', 'math', 'calendar' and 'dateutil.parser' can be used without any alias.
    This function executes in a sandbox mode. Please refer the documentation for permitted objects and functions.
    Using any restricted functions or objects would cause an internal exception and result in a run failure.
    Any code outside this function body will not be executed and inclusion of such code is discouraged.
    :param data: Pandas DataFrame
    :return: Pandas DataFrame
    """
    #####################################################
    # Provide the function body for data transformation #
    #####################################################
    rows = []

    for _, row in data.iterrows():
        channel_str = row['Channel']

        if pd.isnull(channel_str) or not str(channel_str).strip():
            continue

        entries = str(channel_str).split(';')
        channel_map = {}  # To store channel_name -> summed Decimal %

        for entry in entries:
            entry = entry.strip()
            if not entry:
                continue

            if '(' in entry and '%' in entry:
                channel_name = entry.split('(')[0].strip()
                percent_str = entry.split('(')[1].replace(')', '').replace('%', '').strip()

                try:
                    percent_val = Decimal(percent_str)
                except:
                    percent_val = Decimal('0')

                if channel_name in channel_map:
                    channel_map[channel_name] += percent_val
                else:
                    channel_map[channel_name] = percent_val

        for channel_name, total_percent in channel_map.items():
            new_row = row.copy()
            new_row['Channel'] = channel_name
            new_row['AllocatedPercentage'] = total_percent
            
            if total_percent > 0:
                new_row['ActualSpend'] = (new_row['ActualSpend'] * (total_percent/100) )
            
            rows.append(new_row)

    data = pd.DataFrame(rows)
    return data

6.3 Execute the transformation flow and test the output from the local table HDLFT_CAMPAIGN_SILVER:

Wonderful our silver layer of the data is ready and transformed as per the business requirement. Now let us create the customer managed data product and share with the SAP databricks. You can also share the local table from HANA Data Lake File space to HANA cloud DB space and build the models on top of it, e.g. Building a report that provides access to 5 years of worth where most recent 2 years are persisted on the storage type in-memory/disk while rest 3 years are persisted on the storage type file and union model is build to combine this data.

7. Creating Custom Delta Share Data Products: Create a Formations Profile with Data Product visibility option as Formations.

8. Context is automatically created.

9. After creating your Unified Customer Landscape Formations profile, you can proceed to create a Delta Share data product:

10. List the Custom Data Product, so that It will be discoverable in the SAP BDC Catalog & Marketplace:

11. Search and Discover the Data Product "Sales Campaign Gold Data" in SAP BDC Catalog & Marketplace:

12. Share the Data Product "Sales Campaign Gold Data" with supported BDC target systems in our scenario it is SAP databricks: We are sharing the data product with SAP databricks workspace WS_IT.

Note: SAP databricks is part of our SAP BDC formation, hence it is available under the target system options.

13. Validate the sharing is enabled and correct target system:

14. Validate the Delta-Shared Sales Campaign Gold Data product in SAP Databricks by checking the WS_IT workspace with verifying its presence and data preview in the Unity Catalog.

Summary:

In this part of the SAP Business Data Cloud (BDC) series focusing on the data products, we explored how to build a custom data product in SAP S/4HANA Cloud Private Edition using a custom CDS entity (e.g., ZCDS_CAMPAIGN). We walked through setting up prerequisites like the Cloud Connector, creating a Datasphere file space, and configuring connections. Using the bronze–silver transformation approach, we replicated and refined campaign data for harmonization. Finally, we created and published a custom Delta Share data product, making it discoverable in the BDC Catalog and consumable in SAP Databricks for advanced analytics and ML scenarios.

SAP Datasphere Integration with SAP S/4HANA: SAP Cloud Connector Setup Guide

2025-09-23T23:36:19.259000+02:00

Introduction:

In this article, we will explore SAP Cloud Connector what it is, its purpose, and the scenarios where it becomes essential. Whether you are working with SAP S/4HANA Private Cloud or connecting SAP S/4HANA on-premise systems to the cloud, the SAP Cloud Connector plays a critical role. We will also provide a step-by-step guide on its configuration and setup, helping you seamlessly bridge your on-premise and SAP Datasphere cloud environments.

What is SAP Cloud Connector?

The SAP Cloud Connector acts as a secure link between SAP Datasphere and on-premises systems, enabling seamless integration without exposing your entire internal network (behind the firewall). It runs as an on-premises agent or middleware in a secured environment and functions as a reverse invoke proxy, providing controlled access to selected systems and resources.

Key benefits include fine-grained control over which on-premises systems cloud applications can access, automatic recovery of broken connections, and audit logging of inbound traffic and configuration changes. It also supports high-availability setups for enterprise scenarios.

Compared to opening firewall ports or using DMZ reverse proxies, the Cloud Connector is easier and safer to deploy. It supports multiple protocols, including HTTP and RFC for native ABAP system access, and allows secure propagation of cloud user identities to on-premises systems. With simple installation, low TCO, and standard SAP support, it’s an efficient solution for connecting cloud and on-premises landscapes.

Does it support data encryption ?

Yes, TLS encryption is used for the tunnel

What are the SAP Datasphere data integration features, and in which scenarios is the SAP Cloud Connector required?

Replication Flows – For example, connecting to SAP ABAP CDS views and replicating data to the cloud.
Data Flows – For scenarios like extracting, transforming, and loading data from on-premises sources, including SAP ABAP CDS views.
Model Import – Importing existing ABAP CDS data models from on-premises systems into SAP Datasphere for further analytics and integration.

SAP Cloud Connector FAQs

Where can I find information about SAP Cloud Connector licensing, downloading, and installation ?

2827108 - SAP Cloud Connector licensing, download and installation information.
It does not required separate license and it is free to use.
Download: SAP Cloud Connector.
Installation and Setup.

What are the Sizing Recommendations?

What are the best practices and recommendations for setting up SAP Cloud Connector?

Always Use the Latest Version: Install or update to the latest Cloud Connector release to take advantage of new features and security improvements.
Dedicated Server Setup: Install on a dedicated server within your corporate network that has direct, unblocked access to the source system. Ideally, this server should be physically close to the source systems it connects to.
High Availability Setup:
- Master (Primary Installation): Main Cloud Connector instance for normal or HA setups.
- Shadow (Backup Installation): Secondary instance for HA, providing failover support.
Environment-Specific Installations: recommended to have a separate Cloud Connector for each environment (development, testing, production) to ensure stability and isolation.
User Configuration: Use an email ID linked to the subaccount or global account instead of an S-User for easier management.
Proper Sizing: Ensure the server has sufficient resources (CPU, memory, network bandwidth) to handle the expected load.
Regular Log Review: Continuously monitor logs and metrics to detect performance issues or connectivity problems and resolve them promptly.

SAP Cloud Connector Troubleshooting Guides:

Steps to Install, Configure and Setup the SAP Cloud Connector:

Step 1: Download, Prerequisites, and Install the Cloud Connector

Before you begin configuration, make sure the following prerequisites are in place:

Download: SAP Cloud Connector.
The Cloud Connector is installed in your on-premise network. (See Cloud Connector Installation in the SAP BTP Connectivity documentation.)
If you’re using egress firewalling, add these domains to the firewall/proxy allowlist:
- *.hanacloud.ondemand.com
- *.k8s-hana.ondemand.com
You need an SAP BTP account. If you don’t already have one, create it by registering in the SAP BTP cockpit.

Step 2: Launch and Login

After installation, an user:Administrator account is created with the initial password: manage (case-sensitive). You’ll be prompted to change it on first login. Default/Initial login details Administrator / manage
Access the Cloud Connector Administration at:
https://<hostname>:8443 (replace <hostname> with the machine name, or use localhost if installed locally).
2388242 - KBA: How to reset SAP Cloud Connector built-in user's password

Step 3: Add Your SAP BTP Subaccount

You’ll need details from your SAP Datasphere subaccount:

Subaccount
Region Host ( Data Center - Providers and Regions)
Sub Account User (usually the email ID tied to your BTP account)

If account info is missing, enter your SAP BTP user ID manually. For troubleshooting, see KBA: 2397165.

2571763 - Authorization problem in SAP Cloud Connector when adding Cloud Foundry subaccount

For auth errors refer Log and Trace Files: scc_core.trc

Note: Initially SAP BTP Core account details in SAP Datasphere will not be available, you must provide the SAP BTP account email and save. SAP Datasphere tenant owner can perform this.

Step 4: Verify Connection

Once the subaccount is added, the status should display Connected.

Step 5: Configure the Cloud Connector

For this guide, we’ll focus on Replication Flow scenarios using RFC and HTTPS protocols.

Step 6: Add the SAP S/4HANA (ABAP) System

Select Cloud to On-Premise scenario and Back-end Type: ABAP System.
Choose HTTPS protocol.
Use without load balancing (application server + instance number).
Enter your SAP S/4HANA internal host and port.
How to find internal host and port from SAP S/4HANA ? (Run T-Code SMICM → Services).
Leaving defaults for principal propagation and system certificate. (check your requirement and change)
Define a virtual host name (recommended: different from the internal name).
Provide a System ID (e.g., RI4) and description, then finish setup.
Test connectivity – status should show Reachable.
Add resources – in this scenario, we added all resources under /.

Step 7: Add RFC Protocol Resources

Select RFC protocol.
Enter system mapping details (System ID + description).
Finish setup and test connectivity.
Map required resources:
- With Prefix (e.g., DHAMB_)
- With Exact Name (e.g., RFC_FUNCTION_SEARCH)
Ensure the status turns Green for all resources.

Step 8: Maintain IP Allow list in SAP Datasphere

Identify the public IP address of the host where Cloud Connector is installed (e.g., via whatismyip.com or ip.me or whatever way you are aware of).
Add this IP under Trusted Cloud Connector IPs in SAP Datasphere:
System → Configuration → IP Allowlist.

Step 9: Maintain the Cloud Connector Location ID in SAP Datasphere

Go to:
SAP Datasphere →System → Administration → Data Source Configuration and maintain the Cloud Connector Location ID.

With these steps completed, your SAP Cloud Connector is successfully installed, connected, and configured to integrate and create a native connection type of SAP S/4HANA on-premise with SAP Datasphere.

Summary:

In this blog, we saw how the SAP Cloud Connector helps connect SAP Datasphere with on-premise systems in a secure and easy way. It supports features like Replication Flows, Data Flows, and Model Import for smooth data integration. We also looked at the benefits such as simple setup, better security, high availability, and low cost. With best practices like keeping it updated, using a dedicated server, and regular monitoring, you can ensure reliable performance. Finally, we walked through the step-by-step setup to successfully link SAP S/4HANA with SAP Datasphere.

Identity and Access Management with Microsoft Entra, Part III: SuccessFactors and Role Provisioning

2025-10-20T10:05:47.788000+02:00

Part II of this blog series took a technical deep-dive into a hybrid scenario for managing identities and their access across SAP Business Technology Platform (BTP) and S/4HANA on-premise. Part III enhances the scenario by introducing SAP SuccessFactors (SF) as the source for employee and user data, and leverages the new capabilities in Entra for SCIM-based provisioning to SAP Cloud Identity Service (CIS) supporting groups to streamline end-to-end role assignments in the connected SAP ABAP backend.

Scenario Overview

Part III introduces substantial changes and enhancements to the scenario in part II:

Microsoft Entra and Active Directory (AD) were the primary and authoritative systems (aka "source of authority", SOA) for identity data in part II. For many organizations, however, the trusted SOA for identities is a Human Resource Information System (HRIS) such as SAP SuccessFactors (SF), which will be added to the scenario in this part, and where new employees are now onboarded.
Identity creation, updates, and deprovisioning are now driven by HR events (e.g., hiring, role changes, terminations) from SF. AD and Entra become downstream provisioning targets in this scenario. Because users require access to SAP from SAP GUI on their corporate AD domain-joined workstation using Kerberos/SNC-based single sign-on (SSO, see part II), the solution architecture in this scenario integrates SF with the SAP SuccessFactors to Active Directory user provisioning connector from the Microsoft Entra App Gallery. This pre-built, cloud-based solution supports inbound- or HR-driven provisioning of new employees from SF to AD through Entra. New users provisioned to AD by this connector will be synchronized to Entra with the existing setup of the Microsoft Entra Cloud Sync Provisioning Agent from part II of this blog series that runs on the Domain Controller (DC) in our fictitious company BestRun's corporate network.
Part II focused on the automation of provisioning the user's identity data. The user's authorization in the SAP backend (we used role SAP_BC_ABAP_DEVELOPER_5 as an example) was still managed manually by assigning the user to the equally named group "SAP_BC_ABAP_DEVELOPER_5" in the CIS tenant (see step 10.20 in part II). Also the group in CIS had to be created manually in the previous part of the scenario (see steps 9.17-9.19). This approach may work for a few backend authorizations, but won't scale for a larger number of connected systems and applications with complex authorization models. A key objective in this scenario is to fully automate end-to-end provisioning and deprovisioning of the user's authorizations, which includes the synchronization of backend roles and their corresponding groups in CIS and Entra, as well as the memberships of users to these groups, that ultimately assigns them to the backend roles. The updated version of the SAP CIS connector from the Microsoft Entra App Galley now enables automated provisioning of groups and their entitlements as memberships from Entra to CIS. This new feature in the SCIM (System for Cross-domain Identity Management, IETF RFCs 7642, 7643 and 7644)-compliant outbound provisioning connector in Entra streamlines the end-to-end lifecycle management for authorizations in the scenario. By assigning the new user to a group representing the PFCG role in the SAP ABAP system, this group and the user's membership are now also automatically provisioned to CIS, and from there to the backend system. Similar to part II, the group in Entra and CIS is mapped to the PFCG role by using the same name.

Figure 1 illustrates the SOA for the IAM entities in the scenario:

Figure 1

Although SOA for identity data moves to SF, the connected SAP system remains the authority for the definition of the roles that can be assigned in the scenario. Managing the actual assignment of users to these roles through access packages and approval workflows remains the responsibility of Entra ID Governance. With no single SOA for users, groups and roles centralized at one place in the system landscape, figure 2 shows the updated and newly introduced system components based on the existing setup from part II, and illustrates the steps of the provisioning flow for a new onboarded employee requesting access to a role in the corporate SAP system:

Figure 2

CIS is responsible to integrate the connected SAP systems following this reference architecture. It synchronizes the role from the backend (SAP_BC_EPM_DEMO in this scenario) with the SAP Application Server ABAP connector configured as a Source System in BestRun's CIS tenant Identity Provisioning Service (IPS) which results in creating a group with the same name in the tenant's local directory. Connectivity from CIS to the SAP system on-premises remains unchanged from part II and is established via the connectivity service in BTP and the SAP Cloud Connector deployed in the corporate network.
CIS also takes care for creating the group in Entra by provisioning it with the Entra ID connector configured as a target system in the CIS tenant. This connector uses the Microsoft Graph API to manage groups in Entra.
The HR admin adds a new employee record in SF for the user in the sceanrio, Linda Larson.
The SAP SuccessFactors to Active Directory user provisioning connector picks up the new employee record by calling the SF Employee Central OData API endpoints to query for new or updated data.
The connector then provisions a user account for the new employee Linda in BestRun's corporate AD via Entra Cloud Sync and the Entra Provisioning Agent on the DC.
With Entra Cloud Sync configured in part II to synchronize AD with the Entra tenant, the new account in the corporate AD is also provisioned to BestRun's Entra ID tenant.
Linda starts a request for the SAP EPM access package with the MyAccess portal. For this initial login to Entra, Linda can use the self-service password reset (SSPR) feature in Entra to set her new Entra user account's password. With password writeback enabled in Entra Cloud Sync and SSPR to use password writeback, Linda's initial password reset or any future changes of her password are synchronized back to BestRun's on-premises AD as well. By completing the request, Linda is assigned to the access package resources, and becomes a member in the SAP_BC_EPM_DEMO group in Entra. To keep things simple, the access package policy requires no approval steps in this scenario.
The SAP CIS connector enterprise app is configured to perform all operations (create/update/delete) on new or existing user objects, but to skip creation on groups. Otherwise, Entra would try to create the same group again in CIS that has already been created in step 1, which would result in a naming conflict. Instead, it creates a new user account for Linda in CIS, but only updates her membership to the SAP_BC_EPM_DEMO group in BestRun's CIS tenant.
In addition to the new support for groups in the new version of the SAP CIS connector, authentication to CIS no longer uses basic authentication that sends static credentials with every request. Instead, short‑lived tokens with scoped, limited privileges using the OAuth 2.0 client credentials grant flow enhance security over basic authentication.
Provisioning to the SAP backend with the already existing SAP Application Server ABAP connector configured as a Target System in IPS starts by reading the new user and her group membership from the CIS tenant's local directory, and creating the new user in SAP as well as assigning this user to the corresponding SAP_BC_EPM_DEMO role.
Finally, Linda can login to BestRun's corporate AD from her workstation, obtains a Kerberos token from the DC, and uses it to securely single sign-on to the backend from SAP GUI and the SAP Secure Login Client. This requires mapping of her user principal name (UPN) in AD to her SAP user, which has already been configured in the mappings of the SAP CIS connector in Entra (see step 6.18 in part II) and the transformation of the SAP Application Server ABAP target system in IPS (see step 9.12 in part II).

If you want to see the scenario in action, tune into the recording from our latest online session (in german language) with the DSAG TG "SAP IAM Strategie mit Microsoft" from October 7th, or check out episode 263 from @Holger-Bruchelt SAP on Azure video podcast.

Prerequisites and lab setup

You can continue to use all subscriptions, systems and tenants from your lab in part II, because all prerequisites also apply for this scenario. In addition, make sure that you meet the following prerequisites to successfully implement the enhanced scope of this scenario:

Administrative access to an SF instance with permissions to setup provisioning credentials and onboard new employees.
An SCI tenant in a matching region of your BTP subaccount for on-premise connectivity that has Microsoft Entra ID as a target system enabled.
An Entra ID tenant with self-service password reset (SSPR) enabled and Entra Connect cloud sync configured for SSPR writeback to the AD in the scenario.
Re-run steps 9.1 to 9.10 of part II in your CIS tenatn with the updated file LocalDirectory.json for the LocalDirectory source system, and the updated file SAPA4H_IPS.json for the SAPA4H target system. The updated files apply minor changes to the transformations of both systems based on valuable feedback in the comments to part II. The customAttributes are no longer used to carry over the values for the SAP user name and SNC mapping from Entra to CIS. Instead, the extension attribute sapUserName is used, and construction of the SNC mapping has moved from Entra to the transformation of the SAPA4H target systems (lines 13 to 28).

Note 📢📢📢

This tutorial extends and updates the scenario from part II. Any components and their configurations that are not added or changed in this scenario, such as the SAP Cloud Connector or Active Directory, are not covered in this tutorial. If you arrived here and have not completed part II, please do so first, and then come back again.

As before, supporting files for this tutorial can be found in the blog series GitHub repository. Now let's get started with setting up the provisioning of new employees from SAP SuccessFactors to Entra.

Create API User in SuccessFactors for provisioning to Entra

Calling the SF OData APIs from both SF connector apps (Entra & AD) requires an API User in your SF instance who has the appropriate permissions to retrieve the required entities and their attributes.

Step	Description	Screenshot
1.1	Login to your SF instance as a system administrator who has access to the Admin Center.
1.2	Enter Import Employee Data in the search bar and select the action from the search results.
1.3	Select Basic Import from the entity drop-down list. Click Browse...
1.4	Open the CSV file to import the API user from the GitHub repo.
1.5	Click Validate Import File Data.
1.6	Check for the Validation Successful message. Click Import.
1.7	Wait for the confirmation message that the file has been uploaded and is being processed.
1.8	Enter Manage Permission Roles in the search bar and select the action from the search results.
1.9	Click Create.
1.10	Enter Entra Provisioning Role as the Name for the new Permission Role that will be assigned to the imported API user. Keep the default value Employee for User Type, and click Next.
1.11	On the Add Permissions step in the Create Role wizard, enter Manage Integration Tools in the search bar and click the lens icon. Activate the checkbox for Allow Admin to Access OData API throuch Basic Authentication.
1.12	Enter Employee Central API in the search bar and click the lens icon. Activate the following checkboxes: Employee Central Foundation OData API (read-only) Employee Central HRIS OData API (read-only) Employee Central Foundation OData API (editable) Employee Central HRIS OData API (editable)
1.13	Enter Employee Data in the search bar and click the lens icon. Scroll to the User Information section and activate the View checkbox for all attributes.
1.14	Scroll down to the HR Information section and active the View checkbox for all attributes.
1.15	Scroll down to the Employment Details section and activate the View checkbox for all attributes. Click Next.
1.16	Click Save.
1.17	Click Not Now.
1.18	In the search bar, enter Manage Permission Groups and select the action from the search results.
1.19	Click Create New.
1.20	Enter Entra Provisioning Group for the Group Name of the new permission group. Add the imported API user to the new group by selecting User Type Employee. Select User from the People Pool drop down list. Select = (equal to) as the search operation, and enter Entra as the value. Select the imported API user record entra entra provisioning from the value help. Click Done.
1.21	Click Done.
1.22	In the search bar, enter Manage Permission Roles and select the action from the search results.
1.23	From the list of permission roles, click on the Add Role Assignment action for the new Entra Permission Role.
1.24	Keep the default values on the Basic information tab. Click Next.
1.25	Select the From groups option. Click Select Groups.
1.26	Activate the checkbox for the new Entra Provisioning Group. Click Select.
1.27	Click Next.
1.28	Keep the default values on the Define a Target Population step and click Next. Keep the default values on the Define Data Blocking step and click Next. On the Preview step, click Save.
1.29	Enter Reset User Passwords in the search bar and select the action from the results list.
1.30	In the Username field, enter entra_provisioning_user. Select the imported API user entra_provisioning_user (entra entra provisioning) from the value help.
1.31	Select the user in the result list. Enter the same value for the password in the New Password and Confirm Password field. Click Reset User Password.
1.32	The confirmation that the password has been resetted is shown.

Setup provisioning from SuccessFactors to Active Directory

The new API user's credentials are now being used to setup the SAP SuccessFactors connector for provisioning new employees to BestRun's corporate AD. This ensures that every employee managed in SF also gets a user account in AD which is required for SSO via SNC and Kerberos when accessing BestRun's SAP system(s) from a corporate AD domain-joined workstation.

Step	Description	Screenshot
2.1	Login with your Microsoft Entra tenant administrator to the Entra admin center with an additional URL query parameter Microsoft_AAD_Connect_Provisioning_ forceSchemaEditorEnabled set to true: https://entra.microsoft.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true. Select Enterprise apps from the Entra tenant's main navigation menu. Click New application.
2.2	Enter SuccessFactors to in the search bar. Click the tile with label SuccessFactors to Active Directory User Provisioning.
2.3	Enter a name for the new enteprise app (for example SuccessFactors to Active Directory User Provisioning <your SF instance company ID>). Click Create.
2.4	Select Provisioning from the navigation menu of the newly created enterprise app.
2.5	For the configuration settings in the next step, the distinguished name (DN) of the path in AD where new users should be created is required. You can either create a new container in AD for the onboarded employees from SF, or use an existing one. The screenshot shows the Active Directory Users and Computers tool with the default Users container selected and its properties dialog opened. From the tab Attribute Editor, the attribute distinguishedName is selected, and its value CN=Users,DC=corp,DC=bestrun,DC=com copied for the configuration of the following step (note that the DC (domain) components in your lab setup may be different.).
2.6	Select Provisioning from the navigation menu and expand the Admin Credentials section. Enter the following values: Tenant URL: Provide the tenant URL of your SF instance's API server which can be looked-up here. Note: Do not add the URL scheme (https://) to the value, but only the hostname. Default OU for New Users: Paste the value from the previous step, or enter any path in your corporate AD where you want new users to be created. Active Directory Domain: Select the domain from the drop-down box that your Entra Connect Sync agent is configured for. Admin Password: The vlaue you entered when resetting the new API user's password in step 1.31 Admin Username: The name of the imported user in step 1.4 (entra_provisioning_user), followed by the @-sign and the company ID of your SF instance. Click Test Connection.
2.7	Wait for the confirmation that the values could be successfully verified. Testing the connection also checks that the permissions of the provided API user are correctly set in the SF instance. Click Save.
2.8	Expand the Mappings section. Click Provision SuccessFactors Users.
2.9	By default, all employee records in the connected SF instance will be synchronized to Entra once provisioning is started. For testing purposes of this scenario you will restrict provisioning to the test user only. Click All records.
2.10	Click Add new filter group.
2.11	Enter the following value for the new filter group: Source attribute: personIdExternal Operator: EQUALS Clause value: llarson For the new Scoping Filter Title, enter Filter for llarson. Click Apply.
2.12	Click Apply.
2.13	For the userPrincipalName attribute mapping, click Edit.
2.14	Change the expression from [personIdExternal] to Join("@", [personIdExternal], "corp.bestrun.com") Replace "corp.bestrun.com" with your AD domain name. Click Ok.
2.15	Click Save and confirm with Yes.
2.16	Close the Attribute Mapping dialog box.

Setup users and groups provisioning to SAP CIS in Entra

To use the new features for groups provisioning and OAuth-based authentication in the SCIM-based SAP CIS provisioning connector, a new enterprise application will be created. You may want to remove the CIS enterprise app created in steps 6.1 to 6.23 of part II.

Step	Description	Screenshot
3.1	Select Enterprise apps from the Entra tenant's main navigation menu. Click New application.
3.2	Enter SAP Cloud Identity in the search bar. Click on the tile with the label SAP Cloud Identity Services.
3.3	Provide name for the new instance, for example SAP Cloud Identity Service (<your CIS tenant id>). Click Create.
3.4	Back on the Overview page, click the Provision User Accounts tile.
3.5	Switch the Provisioning Mode from Manual to Automatic. Expand the Admin Credentials section and enter the following values: Authentication Method: OAuth2 Client Credentials Grant Tenant URL: Provide the SCIM endpoint URL of your CIS tenant, for example https://<your tenant id>.accounts.ondemand.com/scim Token Endpoint: The OAuth token endpoint URL of your CIS tenant (for example https://<your tenant id>.accounts.ondemand.com/oauth2/token). You can lookup the token endpoint in your CIS tenant's admin console by navigating to Applications and Resource -> Tenant settings -> Single Sign-On -> OpenID Connect Configuration. Client Credentials: Enter the value for Client ID captured in step 4.7 of part II. Client Secret: Enter the value for Client secret captured in step 4.7 of part II. Click Test Connection.
3.6	Wait for the confirmation that the configuration has been tested successfully. Click Save.
3.7	Next, adjust the mappings to add the user's on-premise principal name as the SAP user name. Expand the Mappings section. Click Provision Microsoft Entra ID Users.
3.8	Activate the checkbox Show advanced options. By accessing the Microsoft Entra Admin Center with the addition URL query parameter in step 2.1, the additional option to edit the attributes for Entra appears in the Supported Attributes section. Click Edit attribute list for Microsoft Entra ID.
3.9	Scroll down to the last row in the table and enter onPremisesUserPrincipalName in the attribute name field. Click Save, and confirm with Yes.
3.10	Click Edit attribute list for SAP Cloud Identity Services.
3.11	Scroll down to the last row in the table and enter urn:ietf:params:scim:schemas:extension:sap: 2.0:User:sapUserName in the attribute name field. Click Save, and confirm with Yes.
3.12	Click Add New Mapping.
3.13	Select "Expression" for Mapping type. The Entra attribute "onPremisesUserPrincipalName" added in step 3.9 has the format "<Windows user name>@<Kerberos realm name>". The SAP login name should be equal to the Windows user name that can be considered unique across all users in the organization. The following expression extracts the Windows user name from the "onPremisesUserPrincipalName" and converts it to upper case for the SAP login name: Item(Split([onPremisesUserPrincipalName], "@"), 1) Enter this string for the Expression. As the Target attribute, select "urn:ietf:params:scim:schemas:extension:sap: 2.0:User:sapUserName" from the list. Click Ok.
3.14	Click Save.

Configure permissions in Entra for provisioning of groups from CIS

CIS provisions the groups (representing the PFCG roles in the SAP backend) with the Graph API to Entra. The required permissions to do so are configured in this step in the application registration created as part of the enterprise app for CIS.

Step	Description	Screenshot
4.1	From the navigation menu, select App registrations. On the All applications tab, search for the name of your enterprise app chosen in step 3.3, for example SAP Cloud Identity Services (<tenant id>). Select the application registration for the CIS enterprise app from the search results.
4.2	Select Certificates & Secrets from the navigation menu. Switch to the Client secrets tab. Click New client secret.
4.3	Enter a description for the new secret, for example Entra Provisioning and select an expiration period. Click Add.
4.4	Copy the value of the new secret to the clipboard and paste it to a temporary text file. It will be used in a later step.
4.5	Select API permissions from the navigation menu. Click Add a permission.
4.6	From the Microsoft APIs, click on the Microsoft Graph tile.
4.7	CIS calls the Graph APIs on its own behalf, and not on-behalf-of a signed-in user. Therefore, select Application permissions. In the search bar, start typing Group.ReadWrite. From the result list, activate the checkbox for the permission Group.ReadWrite.All. Click Add permissions. 📢Note: To follow the least privilege principle, only the permissions required for this scenario are added. Although CIS can also provision users to Entra, which would require an additional Graph API permission, we do not use this feature, and therefore only add the permission to manage groups.
4.8	To approve the new permission, provide the required admin consent by clicking Grant admin consent for <your tenant domain>.
4.9	Select Overview from the navigation menu. Copy the Application (client) ID to the clipboard, and paste it to the temporary text file where you've already kept the secret value.
4.10	Click Endpoints.
4.11	Copy the OAuth 2.0 token endpoint (v1) to the clipboard and paste it to the temporary text file where you've already kept the other configuration values.

Add SAP as source system in IPS

Now it is time to configure the additional source system in IPS for reading roles from the backend and create the groups from them in the tenant's local directory.

Step	Description	Screenshot
5.1	Login as the CIS administrator to your CIS tenant's admin console at https://<tenantID>.accounts.ondemand.com/admin. From the Identity Provisioning menu, select Source Systems.
5.2	Click Add.
5.3	You will create the new source system from a file, which can be found in the tutorial series GitHub repository. Click Browse... and open the file SAP A4H Source System.json from the file dialog. Click Save.
5.4	Switch to the Transformations tab to review the configuration. Only roles are read from the SAP Application Server ABAP and created as groups in CIS. Reading users from ABAP has been removed from the transformation settings, because Entra is the SOA for them in this scenario.
5.5	Switch to the Properties tab. For testing purposes, the abap.role.name.filter property is set on the source system to only read roles starting with the string SAP_BC_EPM.

Add Entra tenant as target system in IPS

Step	Description	Screenshot
6.1	Select Target Systems from the Identity Provisioning menu.
6.2	Click Add.
6.3	Click Browse... and select the file Entra ID Target System.json from the GitHub repository. Switch to the Properties tab.
6.4	Paste the values from your temporary text file into the following properties: OAuth2TokenServiceURL: Value for the OAuth 2.0 token endpoint (v1) copied in step 4.11 Password: Value for the secret copied in step 4.4 User: Value for the Application (client) ID copied in step 4.9 Click Save.
6.5	Switch to the Transformations tab to review the imported configuration. Similar to the new source system, the target systems also only provisions groups to Entra. Users have been removed from the default transformation.

Provision the PFCG roles as groups to Entra

To continue with the configuration in Entra ID Governance for the SAP EPM access package which includes the SAP_BC_EPM_DEMO, this group must be provisioned first from the SAP system via CIS to Entra. With the configuration of the new source and target system in CIS, you can start this initial provisioning.

Step	Description	Screenshot
7.1	Select Source Systems from the Identity Provisioning menu. From the list of Customer Managed source systems, select the SAP A4H source system. Switch to the Jobs tab.
7.2	Click Run Now for the Read Job type.
7.3	Select Provisioning Logs from the Identity Provisioning menu.
7.4	Select the first job for the SAP A4H source system from the list to view the execution logs.
7.5	After the job has finished, check the job log statistics. You can see the number of roles read from the source system SAP A4H and the same number of groups written to (created in) Entra ID.

Create the SAP EPM Access Package

The following steps guide you through the process of creating the SAP EPM access package that will contain the previously provisioned SAP_BC_EPM_DEMO group.

Step	Description	Screenshot
8.1	Go back to the Entra admin center. Expand the ID Governance section and select Entitlement management from the navigation menu. Select Access packages from the submenu.
8.2	Click New access package.
8.3	Enter SAP EPM for the name, and provide a description, for example Access to SAP Enterprise Procurement Model demo app. Click Next: Resource roles.
8.4	Click Groups and Teams.
8.5	Activate the checkbox See all Group and Team(s) not in the 'General' catalog. Enter SAP_BC_EPM in the search field and activate the checkbox for the SAP_BC_EPM_DEMO group. Click Select.
8.6	From the Role drop-down box, select Member. Click Next: Requests
8.7	Select For users in your directory from the Users who can request access options. Select All members (excluding guests). Set Require approval to No. Click Next: Requestor information.
8.8	Click Next: Lifecycle. Choose Never from the Access package assignments expire options. Set User can request specific timeline to No. Click Next: Rules.
8.9	Click Next: Review + Create. Click Create.
8.10	Copy from the newly created access package the link to the My Access portal and paste it to a temporary text file.

Onboard the new employee in SuccessFactors

As the HR admin, go back to SuccessFactors and onboard the new employee Linda Larson.

Step	Description	Screenshot
9.1	In the search bar, start typing Add new employee and select the action from the search results.
9.2	In the Identity section, leave the default Hire Date (today), select a Company and Event Reason (for example New Hire) from the list. Enter the following Name information: First Name: Linda Last Name: Larson Display Name: Linda Larson In Employee Information, enter llarson for the Person Id. Click Continue.
9.3	Keep the default settings in Personal information and click Continue.
9.4	In Job information, select a Job Classification from the list. Click Continue.
9.5	Click Submit.
9.6	Click View Profile of Linda Larson.
9.7	The profile of the new onboarded employee is shown.

Provision the new employee to AD and Entra

Next, you will provision the new employee to AD with the enterprise app configured for SuccessFactors in steps 1 ff. From there, an account in Entra gets created with Cloud Sync, and an alternative e-mail address is set by the administrator. This is required for the self-service password reset when the new onboarded user logs-in for the first time in the next section. We'll explore more sophisticated mechanisms for the employee onboarding process and initial login experience with Entra ID Governance lifecycle workflows in one of the next parts of this blog series.

Step	Description	Screenshot
10.1	Select Enterprise apps from the navigation menu. In the search field, enter the name of your SuccessFactors app created in step 2.3. Select the app from the search results list.
10.2	Select Provisioning from the app's menu.
10.3	Select Provisioning on demand from the menu. Enter the new employees personId from step 9.2 in the Select a user field. Click Provision.
10.4	The new employee's user account gets created in AD and the results are shown. Click Close.
10.5	On your DC, open the Active Directory Users and Computers (ADUC) tool. Navigate to the path where you provision new users from SF to (as configured in step 2.6). Search for the new user and open the Properties for it.
10.6	Switch to the Attribute Editor tab. Search for the distinguishedName attribute. Click View.
10.7	Copy the value of the attribute to the clipboard.
10.8	Go back to the Entra admin center and select Entra Connect from the top navigation menu.
10.9	Select Cloud Sync.
10.10	Click on your AD to Microsoft Entra ID configuration from the list.
10.11	Select Provision on demand from the menu. Paste the new AD user's distinguished name attribute value from the clipboard into the Enter a user field. Click Provison.
10.12	Entra will search for the user in AD, create the new account, and display the results. Click Close.
10.13	From the top navigation menu, select Users. Search for the new user by entering its user name. Select the new user from the list.
10.14	Click Edit properties.
10.15	Switch to the Contact Information tab. Click Add or edit other emails.
10.16	Enter an email address in the field that you have access to for testing purposes. This must not be the new users primary email address. Click Save.
10.17	Click Save.

Request the SAP EPM access package

Before making the request for the SAP EPM access package, the new employee Linda Larson has to (re)set her password in Entra using the self-service password reset in Entra ID. and subsequentely also for her user account in AD with the SSPR password writeback option enabled as listed in the prerequisites section of this tutorial.

Step	Description	Screenshot
11.1	Open a new private browser window. Open the URL to the My Access portal copied in step 8.10. On the login page, enter your new employees login name or primary email address. Click Next. Select the Forgot my password link.
11.2	Enter the character and numbers as shown in CAPTCHA. Click Next.
11.3	Select the I forgot my password option. Click Next.
11.4	Click Email to send a verification code to your alternative email address provided in step 10.16.
11.5	Open the inbox of your alternative email address. You should have received an email with the verification code. Copy the code to the clipboard.
11.6	Paste the code in the entry field. Click Next.
11.7	Enter your new (initial) password. Click Finish.
11.8	Wait for the password reset confirmation. Select the click here link.
11.9	Enter your username and click Next.
11.10	Enter your new password. Click Sign in.
11.11	Click Next.
11.12	For testing purposes, click Skip setup for now.
11.13	The request for the SAP EPM access package is started. Click Continue.
11.14	Optionally provide a business justification for the new request. Click Submit request.
11.15	In the Entra admin center, select Groups from the top navigation menu. On the Overview page, enter the test group's name SAP_BC_EPM_DEMO in the search field. Select the group from the search results list.
11.16	Select Members from the group navigation menu. By requesting the access package and auto-approving it, Linda Larson became now a member of this group.

Provision the group membership to CIS

Let's see the updated SCIM connector with support for groups in action, and provision Linda's new user account and her membership to the SAP_BC_EPM_DEMO to your CIS tenant's local directory. Since the group hasn't been created in CIS when your ran the initial load of the PFCG roles to Entra in steps 7.1 ff, the group will be provisioned as well.

Step	Description	Screenshot
12.1	Select Enterprise apps from the top navigation menu. Search for your CIS tenant's enterprise app and select if from the search results.
12.2	Select Provisioning from the app's menu.
12.3	Before provisioning the group and its members to CIS, it must be assigned to the app. Select Users and groups.
12.4	Click None Selected.
12.5	In the Search field, enter the group's name SAP_BC_EPM_DEMO. Activate the checkbox for the group in the search results and click Select.
12.6	Click Assign.
12.7	Select Provision on demand from the menu. In the Selected group field, enter the group's name SAP_BC_EPM_DEMO. Keep the default choice View members only, select the user from the members drop-down list by activating the checkbox for Linda Larson. Click Provision.
12.8	The results of the provisioning action are shown. On the Group details tab, you can see that the group SAP_BC_EPM_DEMO was created in your CIS tenant. Switch to the Group membership operations tab.
12.9	Linda's membership was also added successfully to the new group in CIS. Switch to the User operations tab.
12.10	A new user account for Linda was also created in the CIS tenant. Click View details.
12.11	Linda's new user account in CIS has been created with the attribute values according to the mapping configuration customized in steps 3.7 to 3.13. The last line shows the new sapUserName attribute set with Linda's on-premise user name in AD.

Provision the role assignment to SAP

Final step: Let's provision Linda's new user and her group membership in CIS to the SAP backend system.

Step	Description	Screenshot
13.1	Go back to your CIS tenant's administration console. Select Groups from the Users & Authorizations menu. Select the newly created group SAP_BC_EPM_DEMO from the list and check that Linda's user has been added successfully as a member. Next, select Source Systems from the Identity Provisioning menu.
13.2	Select the LocalDirectory source system from the list. Make sure that you've recreated this source system with the new import file from this tutorials GitHub repository path as mentioned in the prerequisites section. Switch to the Jobs tab. Click Run Now.
13.3	Select Provisioning Logs from the Identity Provisioning menu. Wait for the Status to Finish Successfully and then select the top log entry for your LocalDirectory source system.
13-4	In the Statistics of the provisioning action you can see that a new user was created in the SAP system, and that the equally named role for the group has been updated with Linda's membership.
13.5	Check the new role assignment in the SAP system and Linda's correct SNC mapping for Kerberos-based SSO by logging into the domain-joined workstation. To login, use the password that you've (re)set in step 11.7 and that has been written back to AD.
13.6	Start SAP GUI. You may need to add the connection to the SAP backend as described in step 10.29 and 10.30 in part II. Right-click on the connection and select SNC Login with Single Sign-On.
13.7	Because this is the first login for the new user you are prompted to either reset the initial password, or deactivate it. Click on Delete to use SNC and Kerberos-based SSO.
13.8	You are single signed-on to the SAP system using SNC and Kerberos SSO, and Linda's user menu shows the entries for the EPM Demo Applications as a result of the successful assignment to the SAP_BC_EPM_DEMO role.
13.9	As an administrator in the SAP system, start transaction PFCG. In the Role field, enter SAP_BC_EPM_DEMO. Click Display.
13.10	Swith to the User tab. You can see Linda's SAP user account LLARSON assinged to the role.

Done! Once again, thank you for following this tutorial and the blog series, and looking forward to your comments & feedback.

Accessing On-Premises HTTP APIs with SAP Joule Studio and SAP Cloud Connector

2025-10-28T08:19:03.590000+01:00

SAP Joule Studio enables you to design and build intelligent AI agents and skills that automate and optimize your business processes. To ensure these agents can operate effectively, it is essential to allow them to read from and write data to third-party systems using APIs. In a typical SAP landscape, some of these systems may reside on-premises. To securely access such on-premises systems, the SAP Cloud Connector is the recommended approach. This blog post will guide you through the process of setting up and connecting a Joule skill or agent project in SAP Joule Studio to integrate securely through the Cloud Connector.

The scenario is as follows: We have SAP Joule Studio running on the SAP Business Technology Platform (BTP), while the On-Premises systems exposes its endpoints. To establish a secure connection, we will configure the Cloud Connector, create a destination, set up a SAP Build Actions Project and use that Action in a Joule skill.

Let's dive into the steps required to set up this integration and leverage the power of SAP Joule Studio in conjunction with the SAP Cloud Connector.

Prerequisite

Before proceeding with the steps outlined in this guide, it is essential to have an instance of the SAP Cloud Connector installed. While it is possible to install the Cloud Connector on a server, for the purposes of this demonstration, we will be using a Windows machine. We recommend following the instructions provided in this blog (https://blogs.sap.com/2021/09/05/installation-and-configuration-of-sap-cloud-connector/) to install and configure the Cloud Connector until the Subaccount is connected.

Second requirement is a BTP subaccount with a SAP Build Process Automation (Joule Studio) instance. To this subaccount we will connect the Cloud Connector.

1. Cloud Connector Configuration

The first step is to create a configuration in the Cloud Connector that connects to our subaccount and exposes the HTTP resource. For the purpose of this demonstration, I ran a small Node.js server on my Windows machine that outputs “Hello World”.

To create the configuration, navigate to the admin interface of the Cloud Connector. In here you need to select your registered Subaccount where your SAP Build Process Automation instance resides. Then create a “Cloud to On-Premise” configuration.

In the provided screenshot, you will notice that I have exposed the internal host "localhost" with port 3333 using a virtual host named "virtualhost". This virtual host will be used for making requests from the BTP side. Currently, I have configured an unrestricted access policy, allowing access to all paths. However, in production scenarios, it is recommended to define access policies with more granular control.

Please note that it is crucial to ensure that you have exposed the necessary resources in your configuration. This ensures that the required endpoints are accessible and allows for successful communication between the cloud and on-premises environments.

In this example, the system type is a Non-SAP System using the HTTP protocol. To confirm that the connection works, you can use the “Check availability of internal host” button. This step is essential, as it verifies the accuracy of your configuration and ensures successful connectivity between the cloud and your on-premises environment.

Note: It’s important to understand the difference between the internal and virtual host. The internal host refers to the hostname accessible within your on-premises network — in this case, it’s the localhost on my laptop. Later, within SAP BTP, we’ll reference the virtual host instead.

On the BTP Cockpit end, we can check the connected Cloud Connectors in the respective menu tab. If you cannot see this tab, you may be missing some roles. In the image, you see my registered Cloud Connector and the backend system with its virtualhost available.

2. Create Destination

After successfully registering the Cloud Connector, the next step is to create a destination. A destination serves as a means for services to access an API by handling the authentication and networking aspects.

By configuring a destination, you can simplify the process of accessing APIs by abstracting the underlying technical details. The destination takes care of handling authentication, network communication, and other necessary configurations, allowing services to focus on consuming the API and performing business logic without worrying about the underlying implementation.

Creating a destination provides a convenient way to encapsulate the necessary information, such as the API endpoint URL, authentication credentials, and other relevant settings. This abstraction helps streamline the integration process and facilitates secure and reliable communication between your services and the targeted API.

When creating the destination, there are several important details to specify. These include the name of the destination, the URL you want to access, and the type of destination. In this case, we will specify the URL as the virtual host "http://virtualhost:3333". To utilize the Cloud Connector, we set the Proxy Type to On-Premise.

Optionally one can also maintain the Authentication detail - my service does not require these.

Once the destination configuration is complete, it is crucial to use the "Check Connection" button to verify that everything is configured correctly and the connection can be established successfully. This step ensures that the destination is functioning as expected and is ready to be utilized in your automation processes.

Note: Did you know? The Destination Service’s “Check Connection” behaves slightly differently when the destination is configured with the proxy type “OnPremise.”

For public APIs on the internet, the connection check typically validates both the authentication credentials and the specific path — in other words, it performs a real GET request on that endpoint.

In contrast, for on-premise HTTP destinations, the check is much simpler. It only performs an HTTP “ping” on the host to verify that some response is received. Even if the target system returns a 5xx error, the check will still show as successful as long as the Cloud Connector tunnel is reachable and the HTTP server responds.

Be aware that this behavior can have downstream effects when troubleshooting connectivity issues.

In the ideal case you get the green checkmark! But there are some common errors we need to discuss:

The "Backend not available" error occurs when the connectivity service is unable to locate the host you are trying to access. This could be due to the host not being exposed in the Cloud Connector configuration or a potential misspelling in the URL. To resolve this issue, it is important to revisit the URL and ensure that you are using the correct virtual host specified in the Cloud Connector configuration. Verify that the URL is accurate and matches the virtual host configuration to establish the necessary connectivity.

The second common issue that may arise is the "Resource not accessible" error. This occurs when the connectivity service successfully locates the backend you intend to connect to, but the specific resource (such as the subpath "/hello") either does not exist or is not allowed to be accessed based on the rules defined in the configuration. To resolve this, ensure that you have included the correct path in the Cloud Connector's resource configuration.

For the usage in SAP Build - there is one additional step to make the Destination available to be used inside the Build tool. We need to register the Destination in the Control Tower of SAP Build:

We can do so by navigating to SAP Build Control Tower > Destinations and then choose Add to add the Destination to our environments.

3. Create Actions Project

Now, let's dive into SAP Build Process Automation and create an Actions project. In this case, since my API is not a standard one, I will create a custom API Specification. However, if you are working with a target system like S/4HANA, you can leverage the pre-defined API Specifications available in the SAP Business Accelerator Hub.

Let's give the Project a name of our choice and choose the option to "Upload API Specification".

SAP Build Actions allow us to upload OpenAPI Specifications in JSON format.

{
  "openapi": "3.0.0",
  "info": {
    "description": "Demonstration Hello World",
    "title": "helloworld",
    "version": "1.0.0"
  },
  "servers": [
    {
      "url": "empty"
    }
  ],
  "paths": {
    "/hello": {
      "get": {
        "summary": "get hello",
        "description": "get a hello world message",
        "operationId": "get.hello",
        "responses": {
          "200": {
            "description": "Successful response",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "title": "Message Object",
                  "properties": {
                    "message": {
                      "type": "string"
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

The provided code snippet represents the API Specification, where I define the necessary details. In this case, the servers section is left empty as the URL will be retrieved from the destination configuration at a later stage. Additionally, I specify the available path as "/hello".

It's important to note that the path mentioned in the API specification will be preceded by the destination's URL. Therefore, in our scenario, the complete URL for the request will be "http://virtualhost:3333/hello".

Another crucial aspect for the functionality within the low-code environment is defining the expected response structure. In this case, the response payload will consist of a plain object with the key "message". To build and test specifications, you can utilize the website https://editor.swagger.io/. Be aware, that the response structure must match the specification; if, for example, fields are missing, you will be prompted with a schema error.

Once you have finalized the specification, save the file as a .json format and proceed to upload it to the Actions project.

Within the Actions Project, you will be prompted to add the desired actions, which you can proceed to do. Now, let's move on to testing:

Within the selected Action, navigate to the "Test" tab. Here, you have the option to select the destination that serves as the basis for the request. For this demonstration, I will choose the "sap-sample-api-via-cloud-connector" destination that I created earlier. Once the test is executed, you will find the response payload displayed at the bottom. In this particular case, the test is successful, and I receive the expected message from my On-Premises server.

If you encounter an error during the process, make sure to check the "View API" Section for any response body that might provide insights into the cause of the issue.

In the final step, we need to release and publish the Action to ensure its availability for consumption in an Project. To accomplish this, locate the buttons located at the top right-hand side of the Actions editor. Click on these buttons and ensure that the status indicates "released" and then "published."

4. Add Action to Joule Skill

Lets create a Project and include the Action in a Joule Skill. Do so by adding a step in the Skill with the + symbol.

First we need to add the Action Project in our dependencies:

We add a Action to the Skill, configure its Destination field by creating a new Destination Variable we give an arbitrary name.

We can see that the Action has the message variable in its output.

To prove that we can now also use the data from the API, I added an additional step to Send a Message with the API's result "message" variable in its content.

With the message editor - we can send a custom message to the user. In this case I keep it simple and just output the response from the message field of the API response.

After going through the standard deployment process in SAP Build Joule Studio - we can test our newly deployed skill directly in Joule.

And in this case we are successful and can retrieve the actual answer from the On-Premises HTTP System.

In the following posts we aim to provide further guidance on how to connect to a SAP On-Premises System - as this is the most common scenario for the extension of Joule. Take this blog post as the basis for understanding the concept and flow.

Hope you find this blog insightful, if you have any questions feel free to leave a comment.

IBP file-based integration with SFTP server via Integration Suite - Cloud Integration (part 1)

2025-11-10T10:33:26.034000+01:00

Hello Community

The following blog entry will detail how to

Configure Integration Suite to use a Secure File Transfer Protocol (SFTP) server in CI’s SFTP adapter,
Build an integration flow extracting data from IBP, transforming it within CI and storing it into a file on a server.

Unlike when using CI-DS and especially its on-premise agent for file-based integration, the Cloud Connect cannot store data. Hence the SFTP server is the way to go for an IBP to file (and file to IBP) integration.

Prerequisites

An SFTP server was created and made available,
The BTP/IBP Technical setup was executed,
As well as the Integration Suite Initial Configuration to start building your integration flows.

Configure the usage of an SFTP server via CI’s SFTP adapter

There are multiple steps that needs to be done in order to use an SFTP server for file-based integration using CI.

Required steps at a glance:

Get an SFTP server

Gather your Host, Port, User and Password

Configure the SAP Cloud Connector (SCC)

To reach the SFTP server you will most likely need to use SAP Cloud Connector if the server is located on your internal network and not exposed to the internet.

On Cloud Connector you have to create a new Cloud to On-Premise connection. When creating a new connection, you need to provide the host and port data. Optionally, you can specify a virtual host to use in CI - it is advised to use this option to keep a short, easy to use host name. E.g. settings:

Once the SCC is configured, the SFTP server must be reachable, which can be checked using the button.

If the check is successful, you can continue with the CI side settings. To do so, you first need to get the hostkey data. Navigate to Monitor -» Integrations and APIs -» Manage Security -» Connectivity tests.

On the connectivity test screen select SSH and provide the required information:

Host = Virtual Host configured on SCC
Port = Virtual Port configured on SCC
Proxy-Type = On-Premise
Location ID = location ID of the SCC

As there are no credentials yet, select no authentication and Send the request. If successful, the hostkey information will be shown on the same screen:

Use the Copy Host Key button to copy the data to your clipboard, and create a new text file by pasting it in. Name the file as knownhost for practical reasons.

The next step is to provide the security material, navigate to Monitor -» Integrations and APIs -» Manage Security -» Security Material.

In this step we have to trust the host key just copied, and we have to provide the authentication data.

First, choose Upload -» Known Hosts, and upload the file that have just been created with the host key information.

Next, create new user credentials:

After completing these steps, the SFTP server can be used in SFTP adapters.

Configuring the iFlow for an IBP to SFTP server integration

The idea of this flow will be to read Product master data from IBP, transform the data by populating an IBP attribute based on the values of multiple input attributes and save this in a file stored on your SFTP server.

You can start by creating your iflow from scratch (1) within your own working package or by copying/uploading from the “IBP Read – Example” iflow delivered by SAP from you “SAP IBP – Reusable Integration Flows Example” package (2).

Other option is to copy the reusable iflow delivered by SAP for IBP Read (limitation: you will not be able to change its ID) or download it and upload it in your own package.

------------------------------------------------------------------------------------

These are the steps that you need to keep in your iflow to extract data from IBP and write it in a csv file format that will be stored on your SFTP server:

Content Modifier function to set your iflow’s IBP data extraction related parameters,
External Call of type Request Reply to call the IBP destination by invoking SAP reusable iflow “SAP_IBP_Read_-_Initialize” via ProcessDirect,
Content Modifier function to fetch the initialization call to IBP output for the iflow log,
External Call of type Request Reply to extract the data from the IBP destination by invoking SAP reusable iflow “SAP_IBP_Read_-_Fetch_Data” via ProcessDirect,
Message Mapping function to detail how field mappings and data transformations should happen based on IBP xml format output,
Converter function of type XML to CSV Converter in order to save your output file in a csv format with separators as IBP output will be in XML,
External Call of type Send to push extracted and transformed data into a file on the identified SFTP server via the ad hoc SFTP receiving adapter,
Content Modifier function to set your iflow’s IBP closing parameters,
External Call of type Request Reply to close the IBP destination connection by invoking SAP reusable iflow “SAP_IBP_Read_-_Close” via ProcessDirect.

This example will focus on extracting and storing Product master data type data from IBP.

Content Modifier to pass IBP parameters

Set all relevant parameters needed to connect to IBP and extract the right data in the message Body section (check my previous blog entry with the list of mandatory parameters).

Process Direct to SAP_IBP_Read_-_Initialize

This step initializes the call to the IBP system.

Content Modifier Save Initialize Parameter

This step saves initialization parameters for IBP in order to feed them for the closing step.

See details in “IBP Read – Example” iflow delivered by SAP from you “SAP IBP – Reusable Integration Flows Example” package.

Process Direct to SAP_IBP_Read_-_Fetch_Data

This step extracts the required data from the IBP system.

Message Mapping function

Once you’ve added this function to your flow, you need to click on it and select Create. Then, set a name for the mapping step.

Next, you need to specify your data structure for the source and target message.

You need to specify the XSD schema here for you output IBP XML data. There are multiple ways to build this including by running an example IBP data read iflow and fetching the payloads from logs. In this example the data read is the Product master data and it should look like this:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<xsd:element name="IBPReadMasterDataPRODUCT">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="item" maxOccurs="unbounded" minOccurs="0">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="PRDID" type="xsd:string"/>

<xsd:element name="ABCID" type="xsd:string"/>

<xsd:element name="PRDDESCR" type="xsd:string"/>

<xsd:element name="MATTYPEID" type="xsd:string"/>

<xsd:element name="UOMID" type="xsd:string"/>

<xsd:element name="PRDFAMILY" type="xsd:string"/>

<xsd:element name="PRDSERIES" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Note that the XSD schema can be easily built using LLM.

You can save this and adjust the elements to your needs, as a .xsd file. The source and target don’t necessarily have to be the same, in my example I have more attributes in the output (file as target) rather than input (IBP extracted data) because I will use transformation logics to fill out the extra attributes.

Message Mapping is a graphical tool that lets you create mappings without any coding. Unlike the other mapping options, it is natively integrated into the CI interface. You can build a message mapping by simply dragging and dropping connections between source and target fields, and optionally adding functions between them to transform the data.

Note : You MUST link not only the individual attributes but also the structure headers like in our case “IBPReadMasterDataPRODUCT” and “item”.

Next for any data transformation or more complex mappings, you can leverage the standard CI functions.

In this example, I wanted to set a Product Family value as file output only based on the values of two input attribute values for ABC ID and Material Type ID.

If Material Type ID = FERT and ABC ID = A, then Product Family = Valuable. Else Product Family = Standard.

Another example set here is to use another extra target attribute to set a counter for the output file.

Once you are satisfied with your mapping configuration, you can simulate its execution without having to run the entire iflow.

For this you’ll need an input file with testing data, in XML format which you can build from scratch, LLM or fetch from the iflow payloads (only available if you activate the trace for the logs).

If your simulation runs smoothly, you can proceed with the rest of your iflow steps.

Converter function of type XML to CSV

If your goal is to store the data in a csv file, you need to convert the extracted IBP data (XML format) using this ad hoc function.

In the processing tab of the function’s properties, identify the XML element that must be read to fill the file’s fields, the one that holds the IBP attribute values in other words, in this case : “/IBPReadMasterDataPRODUCT/item”. This was already visible in your XSD structure and XML testing file previously in the mapping step.

Send to server via SFTP adapter

This step will connect to the SFTP server via the previously configured information. At this stage, provide the following information in the Target tab

Directory = SFTP server folder name
File Name = the file name with extension (.csv) to be created, you can also use the append timestamp to add automatically a suffix with date/time
Address = Virtual Host : Port, as configured on SCC
Proxy-Type = On-Premise
Location ID = location ID of the SCC
Credential Name = Name from the user credentials created earlier in CI.

Content Modifier Set Close Parameters

This step leverages the previously saved initialization parameters for IBP for the closing step.

See details in “IBP Read – Example” iflow delivered by SAP from you “SAP IBP – Reusable Integration Flows Example” package.

Process Direct to SAP_IBP_Read_-_Close

This step closes the IBP connection.

------------------------------------------------------------------------------------

Once this is full iflow is configured, you can deploy it and follow the execution in the Monitor section.

With a successful execution, you should be able to find your output file in the SFTP directory and verify the content: Product master data extracted attribute values (Product Id, Description, ABC code, Material Type and UoM) and extra attributes that I only added in the target mapping structure like the Product Family string (Valuable / Standard) and Product Series counter.

Next blog entry

Next blog entry will cover the back integration: from file-based csv to IBP.

Sources

Simplifying AWS EC2 with Cloud Connector installation & SAP DP Agent Integration with BTP

2025-11-14T17:00:31.213000+01:00

Hi Folks,

This blog demonstrates how to create an AWS EC2 instance, configure storage using LVM, install SAP Cloud Connector and Data Provisioning (DP) Agent, and integrate DP agent with SAP Business Technology Platform (BTP) trial account. This setup is ideal for learning and proof-of-concept scenarios.

1. Overview

We are planning to show you end to end AWS server creation along with mount point creation, and installation of SAP DP & Cloud connector installation, and after that we have configured these systems with BTP free trial account.

Aws trial account -- https://aws.amazon.com/free/

BTP trial account -- SAP BTP Cockpit

2. AWS EC2 instance creation

As per SAP standard we can only choose SUSE & RHEL image.

Key pair is necessary to generate if you want to access EC2 instance via public ip, other wise server will not authenticate you.

Either you can select existing security group or create new SG

Attach disk as per your requirements

EC2 instance created

To download media and upload into the server we have configure S3 bucket.

3. S3 bucket Creation

Simply goto S3 and create by selecting create button and enter bucket name and leave all the filled as it is.

4. Attach IAM role to EC2 instance

To connect S3 bucket with EC2 instance we must attached IAM role to EC2 instance.

Role:

Via Attaching this role we are enabling Connection of S3 bucket with EC2 instance.

5. Creation of file system

We have used LVM for file system creation, LVM (Logical Volume Manager) is a disk management system in Linux that provides a flexible way to manage storage compared to traditional partitions.

5.1 validate that separate disk is attach or not via lsblk cmd

PV = Bricks

VG = A big wall built with those bricks

LV = Windows or doors cut out of the wall

5.2 created physical volume pvcreate

5.3 Create Volume group VG

Now we created vg (volume group) from the above pv and validated from vgs command.

5.4 Create LV, Logical Volume

Now we have created lv volume as per our filesystem need
Usrsap - /usr/sap – sap filesystem
Optsapscc - /opt/sap/scc – cloud connector installation

5.5 Disk Formating by mkfs command

Run mkfs command as per below screenshots for all the logical volumes that we need to create

Blkid – to check disk formatting

5.6 Maintain entry in Fstab to get the mount permanent

Now maintain fstab entry as per blkid

5.6 Creation folder creation and mount point creation

Mkidr -p /foldername

Mount -a

6. Cloud Connector installation

6.1 Download media from S3:

We have already downloaded media and uploaded in S3 that we have created earlier.

6.2 Installation of jvm

(before installing cloud connector we have to install jvm)

6.3 Installation of Cloud connector

7. Installation of DP agent

Creating logical volume and disk formatting

Maintaing in fstab

7.1 Creating filesystem for DP agent

7.2 Copying media from S3 to local mount point

7.3 Creating os user for the installation

7.4 Installing libraries

Once required libraries are installed you can start DP agent installation.

8. BTP trial account

https://account.hanatrial.ondemand.com/trial/#/home/trial

8.1 Assign role in your BTP user

This is the first thing we have to complete when we are trying to configure CC or DP agent from BTP.

Cloud Connector Admin role for CC configuration with BTP subaccount.

To install SAP hana cloud admin we need SAP HANA Cloud Admin.

8.2 Create hana cloud instance service

Click on the hana cloud

From there you can create an instance

8.3 Enable DP agent & cloud connector

To configure DP agent, you should enable DP agent, you can do this either during the instance creation or you can also enable after instance creation as well by manage configuration.

And all IP addresses for better connectivity

BTP hana instance created

8.4 Create Technical user for DP agent registration

HANA User Name for Agent Messaging - Technical user as per your requirements, refer to SAP help guide for user creation, roles, and privileges.

https://help.sap.com/docs/HANA_SMART_DATA_INTEGRATION/018757bb7f5c4700a8840976c8730f34/1e648c93d82f4...

8.5 Allow all inbound ips from DP agent server.

8.6 DP agent configuration with BTP Hana cloud instance

Purpose of DP agent:

Setting Up and Configuring the Data Provisioning Agent to Connect

Start agent cli tool from DP agent server.

Agent cli tool connected with the HANA cloud instance as per above screenshot, now try to register agent.

Check agent status, if everything is correct you will see green status as per below screenshot.

Check agent info from hana cloud instance as well.

So till this part we have configured DP agent with hana cloud instance, now if you wants to replicate data from backend abap systems then you have to configure by creating remote source, for better understanding check this blog.

Transferring data from On-Premise SAP HANA to SAP ... - SAP Community

9. Cloud connector configuration with BTP subaccounts.

SAP Cloud Connector is an optional on-premise component that establishes a secure communication link between customer's on-premise network and SAP Business Technology Platform or SAP S/4HANA Cloud.

Conclusion

You now have a fully functional setup integrating AWS infrastructure with SAP BTP trial using DP Agent. This foundation enables secure connectivity and data provisioning for SAP HANA Cloud.

Deploying SAP Cloud Connector on AWS Free Tier Using Terraform and SUSE Linux Enterprise Server

2025-11-21T08:30:19.392000+01:00

Setting up the SAP Cloud Connector traditionally involves several manual steps: preparing a virtual machine, installing the required runtime components, configuring system services, and opening the correct network paths. In this guide, the entire process is streamlined by using Terraform and a lightweight SUSE Linux instance on AWS. With a fully automated installer script and a small set of IaC templates, you can deploy a Cloud Connector in just a few minutes. This approach is ideal for sandboxes, learning environments, and rapid prototyping on the AWS Free Tier.

1. Prerequisites

AWS account with permissions to create EC2 instances, S3 buckets, and security groups
Basic Linux shell usage skills (SSH, simple commands, log inspection)
Terraform installed locally
SSH client (OpenSSH, PuTTY, etc.)
A free-tier compatible SUSE Linux Enterprise Server AMI (x86_64) in your chosen region
An existing EC2 key pair (placeholder: <YOUR_KEY_PAIR_NAME>)
An S3 bucket containing the SCC ZIP file, for example:

<YOUR_S3_BUCKET_NAME>/sapcc-2.16.2-linux-x64.zip

Note: Direct downloads of the SCC installer from tools.hana.ondemand.com do not work with wget or curl. These commands will return an HTML page instead of the actual ZIP file, even though the filename looks correct.

file sapcc-2.16.2-linux-x64.zip

If the output shows HTML document instead of Zip archive, the download has been redirected and is unusable. Hosting the installer in your own S3 bucket ensures the Terraform automation can download it reliably.

2. Terraform Configuration

The following main.tf provisions:

A SUSE Linux Enterprise Server EC2 instance on AWS Free Tier
A security group exposing ports 22 (SSH) and 8443 (SCC UI)
A startup script (install-scc.sh) that installs and configures SAP Cloud Connector

Project Directory Structure

A working directory named terraform_scc was created to hold the Terraform configuration and installation script:

terraform_scc/
├── main.tf                 # Terraform infrastructure definition
├── install-scc.sh          # SCC installation and tuning script
├── outputs.tf              # Terraform output definitions (optional)
├── variables.tf            # Variable declarations (optional)
└── README.md               # Optional notes or setup instructions

Only main.tf and install-scc.sh are required. The remaining files are optional but commonly included for structure and clarity.

2.1 main.tf

terraform {
  required_version = ">= 1.5"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-2"
}

resource "aws_security_group" "sap_scc_sg" {
  name        = "sap-scc-sg"
  description = "Allow SCC UI and SSH"
  vpc_id      = "<YOUR_VPC_ID>"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 8443
    to_port     = 8443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "sap_scc" {
  ami           = "ami-xxxxxxxxxxxxxxxxx"   # SLES x86_64 AMI in your region
  instance_type = "t2.micro"                # Free tier compatible
  key_name      = "<YOUR_KEY_PAIR_NAME>"

  subnet_id                   = "<YOUR_SUBNET_ID>"
  associate_public_ip_address = true

  vpc_security_group_ids = [
    aws_security_group.sap_scc_sg.id
  ]

  user_data = file("${path.module}/install-scc.sh")

  tags = {
    Name = "SAP-Cloud-Connector-SLES"
  }
}

output "public_ip" {
  value = aws_instance.sap_scc.public_ip
}

2.2 Running Terraform

# Initialize Terraform
terraform init

# Optional: preview infrastructure changes
terraform plan

# Deploy SCC VM and networking
terraform apply -auto-approve

# Retrieve public IP for SCC access
terraform output -raw public_ip

# Destroy when finished
terraform destroy -auto-approve

3. Installation Script (install-scc.sh)

This script installs SAP Cloud Connector on SUSE Linux Enterprise Server, tunes the JVM for t2.micro memory limits, enables the systemd daemon, and waits for SCC to start listening on port 8443.

Note: Replace <YOUR_S3_BUCKET_NAME> with your own bucket name.

#!/bin/bash
set -euxo pipefail

SCC_VERSION="2.16.2"
SCC_FILE="sapcc-${SCC_VERSION}-linux-x64.zip"

S3_BUCKET="<YOUR_S3_BUCKET_NAME>"
SCC_URL="https://${S3_BUCKET}.s3.amazonaws.com/${SCC_FILE}"

LOG_FILE="/var/log/scc-install.log"

exec > >(tee -a "${LOG_FILE}") 2>&1

echo "=== SAP Cloud Connector install on SLES ==="
echo "Version: ${SCC_VERSION}"
echo "Source:  ${SCC_URL}"

echo "=== Installing prerequisites ==="
zypper -n refresh
zypper -n install curl unzip java-11-openjdk-headless || zypper -n install java-17-openjdk-headless

cd /tmp

echo "=== Downloading SCC ==="
curl -L -o "${SCC_FILE}" "${SCC_URL}"

echo "=== Verifying ==="
file "${SCC_FILE}" | grep -qi "Zip" || exit 1

echo "=== Extracting ==="
rm -rf /tmp/scc-installer
mkdir /tmp/scc-installer
unzip -o "${SCC_FILE}" -d /tmp/scc-installer

cd /tmp/scc-installer

RPM=$(ls com.sap.scc-ui-*.rpm | head -n 1)

echo "=== Installing SCC RPM ==="
zypper -n --no-gpg-checks install "./${RPM}"

echo "=== Tuning heap for t2.micro ==="
if [ -f /opt/sap/scc/props.ini ]; then
  cp /opt/sap/scc/props.ini /opt/sap/scc/props.ini.bak || true
  sed -i 's/-Xms1024m/-Xms256m/g; s/-Xmx1024m/-Xmx512m/g; \
          s/-XX:MaxNewSize=512m/-XX:MaxNewSize=256m/g; \
          s/-XX:NewSize=512m/-XX:NewSize=256m/g' /opt/sap/scc/props.ini
fi

echo "=== Starting SCC service ==="
systemctl enable scc_daemon.service
systemctl restart scc_daemon.service

echo "=== Waiting for port 8443 ==="
for i in {1..12}; do
  if ss -tulpn | grep -q 8443; then
    echo "SCC is up"
    break
  fi
  echo "Attempt $i/12: 8443 not listening yet, sleeping 10s..."
  sleep 10
done

echo "=== Done ==="

4. Verifying the Deployment

SSH Access

ssh -i <YOUR_KEY_PAIR_NAME> ec2-user@<public-ip>

Check SCC Status

sudo systemctl status scc_daemon.service
ss -tulpn | grep 8443

5. Accessing the SCC UI

Once the SAP Cloud Connector service has started on your SUSE instance, open the administration UI in your browser.

https://<YOUR_PUBLIC_IP>:8443

You will be redirected to the login page:

The default credentials on first login are:

User: Administrator
Password: manage

After logging in, you will be prompted to set a new password.

6. Connect the SCC to BTP

Once authenticated, the landing screen indicates that no subaccount is currently configured.

Navigate to Connector → Define Subaccount and enter the following details:

Region Code (example: us10)
Subaccount ID (GUID from BTP Cockpit)
Display Name (any label of your choice)
Subaccount User (your BTP email)
Password (IAS/BTP password)

Save the configuration. The connector will establish a secure tunnel within a few seconds.

7. Successful Connection

Once connected, the overview section will update and display the Connection Status, Subaccount Certificate, and Tunnel ID:

Your Cloud Connector is now fully operational and ready for use. You can proceed with exposing your on-premise resources to SAP BTP via Cloud To On-Premise → Access Control.

8. Observations and Considerations

SCC’s default heap settings exceed the memory available on t2.micro instances; tuning is required for reliable startup.
In production environments, restrict SSH and SCC UI access to trusted IP ranges.
The installation process is ideal for training, PoCs, and labs where lightweight automation is needed.
Using Terraform ensures fast, repeatable provisioning and clean teardown.
While t2.micro instances and standard gp3 storage sit within AWS’s Free Tier, using SUSE or other licensed AMIs can incur hourly charges under certain circumstances, even on t2.micro. Double-check your AMI selection to avoid unexpected billing.

New Security Optimization Service for Cloud Connector

2025-12-03T05:56:43.092000+01:00

Security and the protection of your systems have become more important than ever and play a crucial role in today’s business environment.

The SAP Security Optimization Service (SOS) is designed to analyze, verify, and improve the security of your SAP system by identifying potential security risks and providing recommendations to mitigate these risks within the assessed systems.

There are many different SAP systems that can be analyzed with an SOS and can be referred from the CQC SOS Infosheet

🌟New in CQC SOS: Cloud Connector!

What is the Cloud Connector?

Serves as a link between SAP BTP applications and on-premises systems.

Runs as on-premises agent in a secured network.

Provides fine-grained control over On-premises systems and resources that can be accessed by cloud applications and Cloud applications using the Cloud Connector.

Besides the CQC SOS for SAP BTP , which provides a security assessment of those security-relevant configurations and authorization assignments which are in the responsibility of the customer and focuses on reviewing the platform aspects, a new CQC SOS in the BTP realm is now available: CQC SOS for Cloud Connector.

The CQC SOS for Cloud Connector provides a security assessment structured in the following sections:

General Security Status for Master Instance: security aspects related to the versions of Cloud Connector and underlying JDK, certificates, enabled encryption ciphers for HTTPS connections to the administration UI, trust configurations etc.
General Security Status for Shadow Instance: contains a subset of the “General Security Status for Master Instance” section which is applicable for the connected shadow instance.
Subaccount-Specific Security Status: settings for connected subaccounts like encrypted communication with backend systems, access policies for HTTP and RFC connections as well as audit log and log/trace configurations.

📥How to request a CQC service?

Create an incident under component SV-BO-REQ (SAP Note 1296527) or

Contact the SAP Enterprise Support Advisory team via our Customer Interaction Center (C I C )

☁️As an SAP Enterprise Support or cloud customer:

Make use of the security and the enablement offerings provided by the SAP Enterprise Support Academy.

For more information on the Cloud Connector discussed in this blog visit the corresponding SAP BTP Security Recommendations and the SAP Help Portal

🔗Stay connected

Want to stay up to date on our services? Join our SAP Cloud ALM & Cross-Solution Topics Value Map community!

A Complete Guide to SAP Cloud Connector: Concepts, System Requirements, and Deployment Approaches

2025-12-03T14:12:23.347000+01:00

What is SAP Cloud Connector?

SAP Cloud Connector (SCC) is a lightweight, on-premise component that acts as a secure tunnel between SAP BTP (Business Technology Platform) and an organization’s on-premise systems. It enables controlled and secure access to internal backend services—such as SAP ERP, S/4HANA, BW, Gateway, RFC modules, or HTTP/S services—without exposing the entire network to the internet.
SCC works as a reverse invoke proxy, meaning that the connection is always initiated from the on-premise side toward SAP BTP. Due to this architecture, no inbound traffic or port opening is required in the company’s firewall, making the integration both secure and easy to maintain. With fine-grained control over resources, administrators can expose only specific APIs, paths, or RFC destinations to BTP applications.

Why SAP Cloud Connector is Important

As organizations adopt SAP BTP for application development, extensions, integrations, and automation, secure connectivity becomes essential. SCC ensures encrypted communication using TLS, provides high-availability options, and allows audit-level monitoring. It plays a key role in hybrid landscapes where on-premises systems coexist with cloud solutions.
Whether building CAP applications, integrating with SAP Build Apps, using SAP Integration Suite, or enabling BTP extensions for S/4HANA, the Cloud Connector acts as the central foundation for secure and reliable connectivity.

Prerequisites

Hardware

Memory: 1 GB RAM (min.), 4 GB recommended
Hard disk space: 1 GB (min.), recommended 20 GB
CPU: Single core 3 GHz (min.), dual core 2 GHz
recommended, x86-64 architecture compatible

Software

64-bit operating systems: Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2, Windows Server 2019, Linux Servers (SUSE)
Cloud connector installation archive from SAP Development Tools for Eclipse.
Microsoft Visual Studio C++ 2010 runtime libraries.
Supported JDKs

How to Implement SAP Cloud Connector

Implementing SAP Cloud Connector is straightforward and does not require complex infrastructure changes. The tool can be installed on Windows or Linux servers, and SAP recommends placing it close to the backend system for optimal performance.

Implementing Cloud Connector can be divided into two parts. 1 is Green Field, and the another is Brown Field.

Green Field Implementation Approach:

Install SAP Cloud Connector

Download the installer from tools.hana.ondemand.com. (Figure 1) https://tools.hana.ondemand.com/#cloud
Choose the OS-specific version (Windows MSI or Linux RPM).
Follow the basic installation steps; SCC runs as a local service.
After installation, access the UI using:
https://localhost:8443
Default admin user: Administrator (you will set the password on first login).

Figure 1:

Launching the Administration UI

Objectives

After completing this lesson, you will be able to:

Logon to the Cloud Connector
Exchange the UI certificates

Cloud Connector Logon

Initial Logon

The Cloud Connector is primarily configured and administered using a web interface. To access the Cloud Connector user interface, enter the following URL in a supported web browser:

https://<hostname>:<port>

<hostname> refers to the machine on which the Cloud Connector is installed. If installed on your machine, you can simply enter localhost.
<port> is the Cloud Connector port (the default port is 8443).

Figure: 2

On the logon screen, enter the following credentials:

Username: Administrator
Password: manage

When you first log in, you must change the password before you continue. The Cloud Connector does not check the strength of your new password. Select a strong password that can’t be guessed easily.

Figure: 3

In the Right side of the above figure 3 you can find the Installation Type (Master/Shadow) for the 1st time implementation use the option called Master (Primary Installation), and to configure it to as HA then chose Shadow (Backup Installation).

Exchanging the UI Certificate

By default, the Cloud Connector uses a self-signed UI certificate. It’s used to encrypt the communication between the Administration UI in the browser and the Cloud Connector. For security reasons, you should replace this certificate with your own one to let the browser accept the certificate without security warnings.

The figure describes how to exchange the UI certificate.

Figure: 4

To exchange the UI certificate of a master instance, perform the following steps:

Within the Administration UI, navigate to Configuration, and then to USER INTERFACE.
In the UI Certificate section, start a procedure to request certificate signing by choosing the icon Generate a certificate signing request.
In the Generate CSR window, specify a key size and a Common Name fitting to the Cloud Connector host name. In the Subject Alternative Names section, you can add other values by pressing the Add button. You can, for example, use the DNS option to specify a virtual hostname or a wildcard name (such as *.sap.com).
Choose Generate.
You’re prompted to save the certificate signing request (CSR) in a file. The content of the file is the signing request in PEM format.
The certificate signing request must be provided to a Certificate Authority (CA) - either one within your company or another one you trust. The CA signs the request and the returned response should be stored in a file using the PEM format.
Select Browse to locate that file and then choose the Import button.

Restart the Cloud Connector to activate the new certificate

Connect SCC to SAP BTP Subaccount

Once SCC is up and running:

Login to the UI.
Go to Cloud To On-Premises → Subaccount.
Enter your SAP BTP Subaccount ID, Region, and Authentication details.
Save and establish the connection.
If successful, the Subaccount will show as Connected.

c. Add On-Premise Backend Systems

Now expose on-prem services to BTP:

Navigate to Cloud To On-Premise → Add System.
Choose the system type (ABAP, HTTP, RFC, etc.).
Provide host, port, and protocol details of the backend system.
Map virtual host/port to internal host/port.
Select resources (paths, RFC functions, services) you want to expose.

d. Assign Access Control

For each system:

Enable Access Control.
Specify the resources BTP apps are allowed to consume.
Set principal type (none, principal propagation, or basic auth).

e.Verify the Connection from SAP BTP

Finally:

Go to your SAP BTP Cockpit → Connectivity → Cloud Connectors.
Verify status, system availability, and reachable endpoints.

Configuring Access Control

Objective

After completing this lesson, you will be able to expose an AS ABAP-based SAP System (HTTP)

Supported Protocols

To allow your cloud applications to access a certain on-premise system on the intranet, you must specify this system in the Cloud Connector. The procedure is specific to the protocol that you're using for communication. The following protocols are supported:

HTTP

RFC

LDAP

TCP

Configuring Access Control (HTTP)

In the following, the widely used HTTP protocol is covered as an example in more details. The figure shows the overall workflow to securely use the HTTP protocol.

Initial Configuration: Import or Generate a System Certificate

To set up a mutual authentication between the Cloud Connector and any back-end system it connects to, you can import an X.509 client certificate into the Cloud Connector. The Cloud Connector then uses the so-called system certificate for all HTTPS requests to back ends that request or require a client certificate. The CA that signed the Cloud Connector’s client certificate must be trusted by all back-end systems to which the Cloud Connector is supposed to connect.

There are three options on how to provide the system certificate:

Upload an existing X.509 certificate
Upload the signed UI certificate
Generate a self-signed system certificate (for example: for a demo scenario)

All options are offered in the Cloud Connector Administration UI at Configuration → ON PREMISE → System Certificate.

Initial Configuration: Maintain the Trust Store Using an Allowlist

By default, the Cloud Connector does not trust any on-premise system when connecting to it via HTTPS. To enable secured communication, you must add trusted certificate authorities (CAs) to the allowlist. Any server certificate that has been issued by one of those CAs will be considered trusted.

To maintain the trust store, in the Cloud Connector Administration UI navigate to Configuration → ON PREMISE → Trust Store

Caution

If you do not want to specify explicit CAs you’re going to trust, but rather trust all back ends, you can switch off the handle. In this case, the allowlist is ignored. This option is considered less secure, since all back ends are trusted now.

Exposing an AS ABAP-Based On-Premise SAP System

To allow your cloud applications to access a certain back end system on the intranet via HTTP, you must specify this system in the Cloud Connector.

To do so, start the wizard offered in the Cloud Connector Administration UI at Cloud To On-Premise → ACCESS CONTROL.

To expose an AS ABAP-Based on-premise SAP system, provide the following:

Back-end Type: ABAP System.
Protocol: HTTP or HTTPS.
Internal Host and Internal Port: the actual host and port under which the on-premise SAP system can be reached within your intranet.
Virtual Host and Virtual Port: enter the host name exactly as specified in the <URL> property of the HTTP destination configuration in SAP BTP. The virtual host can be a fake name and does not need to exist. The Virtual Port allows you to distinguish between different entry points of your back end system, for example, HTTP/80 and HTTPS/443, and to have different sets of access control settings for them.
Allow Principal Propagation: defines if any kind of principal propagation should be allowed over this mapping. If selected, also define what kind of Principal Type is sent to the on-premise SAP system within the HTTP request.
System Certificate for Logon: select if the Cloud Connector's system certificate should be used for authentication at the back end.
Host In Request Header lets you define which host is used in the host header that is sent to the target server. By choosing Use Internal Host, the actual host name is used. When choosing Use Virtual Host, the virtual host is used.
Description: optional description text
Check Internal Host: this allows you to make sure the Cloud Connector can indeed access the on-premise SAP system.

Brown Field Implementation Approach:

Back Up and Restore Your Cloud Connector Configuration

This method is very help full for those who doesn’t want to perform all the above-mentioned steps again and again. Specifically in the RISE migration projects this method is very effective. So many of you probably wonder that Cloud Connector doesn't store any data, then how to Backup and Restore it.

Well, it holds all the configuration and customizations, which is performed to its desired state. you should take a backup of its configuration.

To back up or restore your Cloud Connector configuration:

Step 1:

Choose Connector in the Cloud Connector Administration UI main menu.
Use the buttons on the upper right to back up or restore the configuration.
Specify a password for the backup archive.

Set the password and click on the ‘Backup‘ it will create a zip file.

Step 2: Take a screenshot of the existing Proxy

Step 3: Take a backup of the OS level path:

/opt/sap/scc

Step 4: Follow all the above mentioned 3 steps and transfer the Backup Zip file to the target. Restore the backup zip file in the target.

It will ask the path for the zip file, and ask the password which was set while creating the zip file. And it will ask the Source Cloud Connector Console login password.

Step 5: It will automatically restart and configure the LDAP. And then after login the Cloud Connector with the Source Console login password and set the proxy accordingly.

Monitoring Cloud Connector

Monitoring Tools

By monitoring key metrics, such as response times, resource utilization, and throughput, you can optimize your application's performance and troubleshoot problems. Alerts and thresholds for various metrics help you detect issues before they become critical problems. By continuously monitoring key components such as servers, databases, network connectivity, and application services, you can identify any failures or outages and take immediate steps to address them.

Monitoring the Cloud Connector is crucial for maintaining its performance, availability, security, and user experience. It allows you to proactively address issues, optimize resources, and ensure that your application meets the expectations of your users.

In this lesson, you will find the available monitoring tools and you will check the operational state of Cloud Connector. Also, you will learn how to work with hardware metrics, monitor cloud to on-premise connections and vice versa. Finally, you will do alerting and audit logging.

There are three primary tools for monitoring the Cloud Connector:

OS Command Line: From the host where the Cloud Connector is running, you can verify the operational state.
SAP BTP Cockpit:

The SAP BTP Cockpit contains a Connectivity section, where users can check the status of the Cloud Connector(s) attached to the current subaccount.
This section lists the Cloud Connector ID, version, used Java runtime, high availability setup, and the exposed back-end system(s).

The Cloud Connector UI

The primary tool for monitoring the Cloud Connector is the Cloud Connector Administration UI. This is available in a web browser interface.

There are also Cloud Connector monitoring APIs if you wish to include performance information in your own monitoring tool.

Checking the Operational State

The first thing to monitor is whether the Cloud Connector is actually running. You can do it in three ways:

From the OS Command Line

In Windows, the Cloud Connector is registered as a Windows service. It’s configured to start after installation, and restart upon host reboot. To check the state of the Cloud Connector, run the command:

sc query "SAP Cloud Connector"

The output would be:

In Linux, the Cloud Connector is set up as a daemon process. It’s configured to start after installation, and restart automatically upon host reboot. To check the state of the Cloud Connector, run one of the following commands (depending on your Linux distribution):

service scc_daemon status
systemctl status scc_daemon

The output would be:

From the SAP BTP Cockpit

In the Connectivity Section, choose Cloud Connectors. If the Cloud Connector is running, its information is displayed:

If the Cloud Connector isn’t running, the SAP BTP Cockpit displays the message:

From the Cloud Connector Administration UI

If the Cloud Connector isn't running, the Cloud Connector Administration UI isn’t accessible and can't be started.

Hardware Metrics

The second aspect to monitor is hardware. To check the current state of critical system resources, use the Cloud Connector Administration UI. Select Hardware Metrics Monitor from the main menu.

The monitor displays key hardware resource usage. The monitor also displays history graphs for various metrics.

CPU Usage:

Physical Memory Usage:

Java Heap Usage:

Disk Usage:

SAP User Access Management in a Hybrid Landscape – Architecture and Key Concepts (Part 1)

2025-12-22T18:05:01.288000+01:00

This blog is Part 1 of a 3-part series on SAP User Access Management in a Hybrid Landscape.

• Part 1 – Architecture and Key Concepts (this post)
• Part 2 – Business Roles and Provisioning Models
• Part 3 – SAP IAG Two-Tenant Model: Challenges and Mitigation Strategies

Purpose

As organizations continue to adopt SAP cloud solutions, hybrid SAP landscapes—combining SAP S/4HANA in on-premise or private cloud environments with SAP SaaS applications and SAP BTP—have become increasingly common. While this model enables flexibility and innovation, it also introduces new challenges in managing user access consistently across systems.

This blog focuses on the architecture and key concepts behind managing user access in a hybrid SAP landscape using SAP GRC Access Control and SAP Identity and Access Governance (IAG) via the IAG Access Control Bridge. It outlines how these components work together with SAP Cloud Identity Services to provide centralized governance, controlled provisioning, and audit-ready access management across both on-premise and cloud applications.

Rather than providing step-by-step configuration instructions, this blog shares practical architectural guidance and implementation insights based on real-world project experience, complementing SAP’s official documentation and helping practitioners understand how to design an effective hybrid access management framework.

Scope and Landscape Overview

The scope of this blog is to outline an integrated user access management approach for a hybrid SAP landscape, covering both on-premise/private cloud ERP systems and SAP public cloud and SaaS applications.

In-Scope Systems

SAP S/4HANA (On-Premise or RISE Private Cloud)
SAP GRC Access Control 12
SAP Cloud Identity Access Governance – Integration Edition (IAG AC Bridge)
SAP Cloud Identity Services (IAS & IPS)
SAP Cloud Connector
SAP SaaS Applications
SAP BTP Applications

Target Architecture

High-Level Architecture Overview

The target architecture defines the end-to-end user access governance and provisioning model for a hybrid SAP landscape. This model integrates on-premise and private cloud SAP systems with SAP Public Cloud and SaaS applications, ensuring cohesive and centralized oversight. The solution leverages several key SAP technologies—SAP GRC Access Control, SAP Identity and Access Governance (IAG – Integration Edition), SAP Cloud Identity Services, and SAP Cloud Connector—to deliver consistent approval workflows, centralized governance, and automated provisioning across the entire SAP environment.

The following diagram illustrates the reference architecture for SAP user access management in a hybrid landscape, highlighting the interaction between SAP GRC Access Control, SAP IAG AC Bridge, SAP Cloud Identity Services, and SAP SaaS applications.

SAP GRC Access Control: Central Governance for Hybrid SAP Landscapes

Overview

SAP GRC Access Control operates as the primary governance and control layer for user access management across the hybrid SAP landscape. It provides a unified framework supporting both on-premise/private cloud and public cloud SAP applications, enabling organizations to maintain comprehensive oversight and streamlined processes for provisioning and managing user access.

Key Functional Capabilities

Access Request Management (ARM): Provides a centralized platform for intake and processing of access requests. Structured approval workflows ensure that every request is systematically reviewed and authorized according to organizational policies.
Access Risk Analysis: Performs real-time Segregation of Duties (SoD) analysis for on-premise systems and supported cloud environments, enabling proactive identification and mitigation of user access risks.
Business Role Management: Facilitates the design, maintenance, and lifecycle management of business roles, supporting the evolving access requirements of the organization.

Integration with On-Premise and Private Cloud SAP Systems

SAP GRC Access Control is directly integrated with core on-premise and private cloud SAP systems, such as SAP S/4HANA, SAP MDG, and SAP BW/4HANA. This integration is achieved through RFC-based communication, enabling essential functions including user provisioning and management, risk analysis and reporting, and business role management. All provisioning and governance activities for these systems are managed from SAP GRC Access Control, ensuring thorough audit traceability and alignment with internal control requirements.

Cloud Integration via SAP Cloud Connector and SAP IAG

The SAP Cloud Connector establishes a secure communication channel between the SAP cloud environment and the on-premise SAP landscape. Within the architecture, the SAP IAG subaccount on the Cloud Connector serves as an integration bridge, connecting SAP GRC Access Control with SAP Cloud Identity and Access Governance (IAG). This configuration enables cloud-to-on-premise RFC communication with GRC Access Control, supports SoD authorization checks, and allows approved access requests in GRC to be extended to SAP SaaS applications. This approach ensures organizations can apply their established GRC processes consistently across both on-premise and cloud environments.

SAP Cloud Identity and Access Governance (IAG) Integration for SAP SaaS Applications

Integration with SAP SaaS applications is facilitated through SAP Cloud Identity and Access Governance (IAG), which operates on the SAP Business Technology Platform (BTP). For clarity and security, IAG is deployed in a dedicated BTP subaccount, using the integration edition known as the IAG AC Bridge. Within this subaccount, a destination is configured to connect SAP GRC Access Control to the SAP Cloud environment via the Cloud Connector, ensuring secure and efficient access management. The IAG application is accessed through a dedicated URL, allowing administrators to manage configurations as required.

During the initial setup of IAG, administrators create an application entry for each SAP SaaS application that will be managed. This ensures that every application is properly integrated and governed within the overall access management framework. IAG utilizes SAP Cloud Identity Services for user provisioning, leveraging the Identity Provisioning Service to automate and monitor user access. For SaaS applications supporting direct provisioning through SCIM, a proxy system is configured for each application in Identity Provisioning, enabling secure and seamless user provisioning across the SAP SaaS ecosystem.

Summary and Next Steps

This first part of the series establishes the architectural foundation for SAP user access management in a hybrid landscape. By combining SAP GRC Access Control with SAP IAG AC Bridge and SAP Cloud Identity Services, organizations can extend centralized governance into SAP cloud applications while maintaining strong security and compliance controls.

In Part 2, we will focus on GRC Business Roles and provisioning models, including direct and federated access patterns across SAP S/4HANA and SAP SaaS applications.

SAP User Access Management in a Hybrid Landscape – Business Roles and Provisioning Models (Part 2)

2025-12-22T18:06:45.115000+01:00

Introduction

In Part 1 of this series, we explored the reference architecture for managing user access in a hybrid SAP landscape using SAP GRC Access Control, SAP Identity and Access Governance (IAG) via the IAG AC Bridge, and SAP Cloud Identity Services.

With the architectural foundation in place, this second part shifts focus to how access is actually designed and provisioned across on-premise and SAP cloud applications. In particular, it highlights the role of GRC Business Roles and explains the different provisioning models used for SAP S/4HANA and SAP SaaS applications.

Understanding these concepts is essential for building scalable, auditable, and maintainable access management processes in hybrid SAP environments.

Access Control: Business Role Management

Overview of GRC Business Roles

In SAP GRC, a Business Role comprises a set of access rights, permissions, and authorizations that can be assigned to multiple users who perform similar functions. Unlike traditional technical roles, Business Roles are designed to be system-independent, allowing organizations to streamline access management across various SAP applications. In a typical SAP Greenfield implementation, these Business Roles are crafted to reflect users' job functions or positions, ensuring both consistency and security for access to on-premise and cloud-based SAP solutions such as SAP S/4HANA, SAP Ariba, and SAP Sales Cloud.

Significance of GRC Business Roles in a Hybrid Landscape

The adoption of GRC Business Roles is especially crucial in a hybrid SAP landscape that encompasses both on-premise and cloud applications. By centralizing access provisioning and abstracting user permissions from the underlying technical roles, GRC Business Roles provide a unified structure for user access management. This approach ensures that users have consistent and appropriate access regardless of whether their work takes place in S/4HANA, Ariba, Sales Cloud, or a combination of these platforms. As organizations transition toward hybrid and cloud-centric architectures, GRC Business Roles facilitate secure, scalable, and efficient user access management—reducing complexity for administrators and minimizing risk by aligning permissions with business needs. This unified approach directly supports the document’s objectives of robust SAP User Access Management and governance across disparate systems.

Structure of GRC Business Roles

A GRC Business Role aggregates one or more technical roles from different systems into a single logical unit, simplifying the assignment process and ensuring users have access to the necessary tools and applications for their roles. Each Business Role consists of Technical Roles specific to individual applications or systems. These Technical Roles grant permissions for distinct modules or applications (e.g., "Accounts Payable Manager" in S/4HANA or "Requestor" in Ariba). GRC Business Roles are mapped to Technical Roles spanning multiple systems, such as:

SAP S/4HANA: Business process roles (e.g., Accounts Payable Manager, Maintenance Technician).
SAP Ariba: Groups or functional roles (e.g., Procurement Manager, Requestor).
SAP Sales Cloud: Sales-related roles (e.g., Sales Manager, Operations

Key Benefits of GRC Business Roles in Project Implementation

Unified access provisioning across SAP S/4HANA and SAP SaaS applications, reducing complexity.
Consistent access mapping aligned with Segregation of Duties (SoD) requirements and regulatory compliance.
Centralized role definition and assignment in GRC simplifies access management for administrators.
Automatic updates to technical roles when business roles change, ensuring accuracy.
Comprehensive access provisioning for users' job functions across multiple systems via a single Business Role.

Business Role Design Approach

The design of GRC Business Roles follows a structured process to ensure alignment with organizational job roles and access requirements:

Technical Role Design

The Security Team develops Technical Roles for each application, guided by detailed access requirements from:
- Process Design Documents: Identify transactions, applications, and authorizations required for each business process.
- User Stories: Outline access needs based on end-user roles and responsibilities.
- Workshops and Discussions: Collaborate with process teams to specify operational transactions and applications for each role.

Alignment with Organizational Job Roles

GRC Business Roles are structured according to users’ jobs and responsibilities as defined by the Organizational Change Management (OCM) Team.
User job roles are defined based on L3 Processes, representing detailed activities within each business process.
L3 Processes linked to each job role are reviewed to determine the necessary technical roles and access rights.
The Security Team creates GRC Business Roles based on these definitions, consolidating required technical roles across applications to ensure consistent and accurate access provisioning.

Detailed Provisioning Flows by Application Type

This section will provide an overview of the provisioning workflows for various applications within a hybrid environment.

SAP S/4HANA (On-Premise / Private Cloud)

Provisioning for SAP S/4HANA, whether deployed on-premise or in a private cloud environment, is facilitated through SAP GRC Access Control. The process is initiated when a user submits an access request using the GRC Access Request Management (ARM) module. Once the access request is submitted, it progresses through an approval workflow. This workflow typically involves the user's manager, the role owner, or the security team, depending on the organization's structure and policies.

During the approval process, a Segregation of Duties (SoD) risk analysis is conducted within GRC. This analysis ensures compliance with internal control requirements and helps minimize potential risks associated with conflicting access privileges. Upon successful approval, SAP GRC automatically assigns the designated roles directly to the S/4HANA system. The user's master record is subsequently updated through standard SAP connectors, enabling seamless integration and ensuring the accuracy of user data.

All audit logs generated during these provisioning activities are maintained within GRC. This comprehensive logging supports compliance requirements and enhances traceability. Notable characteristics of this provisioning flow include real-time SoD checks and immediate role assignment.

Direct Provisioning to SAP SaaS Applications (Ariba, SuccessFactors, SAC) via SCIM API

Provisioning for SAP SaaS applications that support the SCIM API, including Ariba, SuccessFactors, and SAP Analytics Cloud (SAC), is managed through SAP IAG leveraging the Identity Provisioning Service (IPS). The access request process is initiated using GRC Access Request, and the subsequent approval workflow follows a structure similar to the S/4HANA scenario. Once the access request is approved, GRC communicates the request to IAG using the Access Control Bridge (AC Bridge).

A scheduled provisioning job then runs at regular intervals to grant the requested access directly within the relevant SaaS applications. This automated process helps streamline user access management for cloud-based SAP solutions and ensures timely provisioning of roles.

Indirect Provisioning to SAP SaaS Applications (FSM, BTP)

For applications such as SAP Business Technology Platform (BTP) or Field Service Management (FSM), provisioning is managed by SAP IAG through the assignment of IAS Groups associated with these applications. Users submit access requests for specific IAS Groups, and these requests are routed through the required approval workflow. Upon approval, SAP IAG provisions the relevant IAS groups to the users.

For BTP, the IAS groups that are set up are linked to BTP role collections. When users next log in, they receive access to these specific collections. For applications such as FSM, which can interpret the assigned FSM IAS groups and map them to user policy groups within a company’s FSM environment, a scheduled read job on IPS will assign the appropriate user policy group and company automatically.

Please note: While Field Service Management (FSM) may not be explicitly included under an integration scenario for IAG, it is identified as both a source and target system within Identity Provisioning. Consequently, it is appropriate to utilize a combination of provisioning processes in order to provision end user access to FSM in such circumstances.

Summary and What’s Next

In this part of the series, we explored how GRC Business Roles and provisioning models enable scalable and controlled user access across hybrid SAP landscapes. By abstracting technical roles into business-aligned constructs and leveraging both direct and federated provisioning models, organizations can maintain strong governance while supporting diverse SAP applications.

In Part 3, we will focus on the SAP IAG two-tenant model, examining why it presents challenges in real-world implementations and how project teams can mitigate associated risks.

SAP Cloud Connector Subaccount Certificate Automated Renewal has arrived!!

2026-01-11T23:00:00.036000+01:00

I wrote a Blog post some time ago (back in 2020!) in the #SAPCommunity about SAP BTP Cloud Connectivity issues due to expired certificates. The BTP Subaccount certificates needed to be regularly renewed - every 12 months in fact and it could only be carried out manually. While SAP provided information to customers about upcoming renewals (in later releases of the SAP Cloud Connector) with messages and Alerts within the SAP Cloud Connector - certificates that expired caused no end of trouble. This still causes a lot of issues for customers today.

The previous blog post has reached over 60K views so you can see a fair number of customers experienced this issue. https://community.sap.com/t5/technology-blog-posts-by-members/sap-cloud-connectivity-issues-due-to-expired-certificate/ba-p/13431648

The goods news is - SAP released an update to the SAP Cloud Connector application to automate these renewals. Yes - you have read this correctly! The update 2.18.0 was released in March 2025 and I only recently found out that this was possible. So if you have a previous version of the SAP Cloud Connector running then schedule an upgrade ASAP. I also wrote instructions for upgrading the Cloud Connector for Linux and Windows here -> https://community.sap.com/t5/technology-blog-posts-by-members/upgrading-the-sap-cloud-connector-for-linux-os/ba-p/13338502 and https://community.sap.com/t5/technology-blog-posts-by-members/upgrading-the-sap-cloud-connector-for-windows-os/ba-p/13314729

To automate the Subaccount certificate renewal process multiple steps are required. This involves the SAP Cloud Connector as well as the relevant BTP subaccount. SAP note 3632133 covers the steps required to automate the Subaccount certificate renewal but I will cover this now. Here are the steps to automate renewal of Subaccount certificates so you don't have to worry about this again!

To enable automatic renewal in the SAP Cloud Connector.
Make sure when setting up Subaccount connectivity within the SAP Cloud Connector to toggle the [Auto Renewal] and set to ON. For subaccounts that are already set up just Edit the connection.

2. To enable Auto Renewal in SAP BTP Cockpit:

Log in to the SAP BTP Cockpit;
Go to the respective Subaccount > Connectivity > "Cloud Connectors";
Enable the "Allow Automatic Subaccount Certificate Refresh" toggle.

As per the note, this is how the renewal works.

How Renewal Works
- The renewal is triggered n + 7 days before certificate expiry, where n is the alert threshold (configurable in Observation Configuration -> Alerting);
- If the renewal attempt fails, it is retried every 12 hours; If not successful within 7 days, the automatic renewal is cancelled.
- No user credentials are involved in the automatic renewal of a BTP subaccount certificate. The authentication is handled by the currently valid subaccount certificate, provided that an administrator has enabled the auto-renewal feature for the subaccount on the BTP side too.

So, if the above instructions are followed you should not experience issues with Cloud connectivity again!

The other good news is that this was submitted as an improvement request via the Customer influence engagement portal. In retrospect I wrote a blog post about it but did not submit a customer engagement initiative request to make an improvement but good to see others did. 54 others also voted for it. 5 years is also too long for this to be delivered given the amount of issues this caused for a lot of the customers I work with on a daily basis but glad that SAP has delivered this now.

https://influence.sap.com/sap/ino/#/idea/251489/?section=sectionDetails

Overall, I am really happy that SAP has delivered this functionality and I really hope customers plan to do upgrades to the SAP Cloud Connector to take advantage of this update ASAP.

As always, thanks for reading and hopefully this helps!

Systems not able to process messages via SAP Cloud Connector as of Q1/2026

2026-01-21T06:56:22.658000+01:00

Nowadays SAP Cloud Connector is a critical system for customers to process their integrations for their core business processes.

SAP has communicated some months ago about switching to the "DigiCert TLS RSA4096 Root G5" and “DigiCert Global Root G3” Public Key Infrastructures (PKI). This is only one of the many KBAs created around this topic KBA "3566727 - Root Certificate Replacement in the SAP BTP, Cloud Foundry Environment"

Recently we have seen many customers reporting issues regarding Cloud Connector not processing messages.

In Cloud Integration this may be presented as an HTTP response '503: Service Unavailable.' The accompanying error message states: 'org.apache.cxf.interceptor.Fault: Could not send Message., cause: org.apache.cxf.transport.http.HTTPException: HTTP response '503: Service Unavailable. There is no SAP Cloud Connector (SCC) connected to your subaccount matching the requested tunnel for subaccount.'"

Customers get confused, because the Cloud Connector displays that the subaccount is connected.

On BTP Cockpit, they also see the Cloud Connector.

However, the messages sent to be processed via this Cloud Connector still fail.

How to find the cause?

Set the traces as per the following:

Reproduce the issue and download the "scc_core.trc" trace file. Then revert the trace settings as before.

Inside the file "scc_core.trc", look for string "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target."

For example:

Your issue is likely caused because of a missing certificate. Check this KBA "3583377 - Cloud Connector will fail to connect to subaccount"

The certificates come with the JVM, review and ensure you have at least the versions below:

SAP JVM 8.1.097
SapMachine 11.0.22 (SapMachine 11 is out of maintenance, though)
SapMachine 17.0.10
SapMachine 21.0.2
Oracle JDK 8u401

If your version is under the ones mentioned above, update as per this documentation https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/update-java-vm.

In case you have previously imported an own CA root certificate into the JVM keystore (for example a special certificate needed by their local LDAP system). Then review this approach mentioned by @Ulrich_Schmidt1.

"What is interesting to know: there are even further problems, complicating this issue. If a user had previously imported an own CA root certificate into the JVM keystore (for example a special certificate needed by their local LDAP system), then the installer of the JVM apparently notices that the keystore has been modified and will not update it!

This means, even after the required version of the JVM has been installed, it can happen that the new DigiCert G5 certificate is still not available!

Fixing this can then get quite tricky: e.g.

Make a fresh install of the JVM into a separate directory
Reimport the "special" certificate into its keystore
Change JAVA_HOME in the SCC's daemon to the new directory"

This should resolve your issue, if not, you may open an incident with BC-MID-SCC.

Best Regards,
Victor

Connecting SAP S/4HANA On-Prem Directly to Advanced Event Mesh using Cloud Connector - finally!

2026-01-23T14:43:25.992000+01:00

With Package Integration 1.4.0 (December 2025), the Advanced Event Mesh Adapter for SAP Integration Suite delivers several noteworthy updates.

One of these has been requested repeatedly by customers, partners, and SAP architects working in hybrid landscapes:
official support for on-premise connectivity via the SAP Cloud Connector.

In addition to this key enhancement, the release also includes other technical changes, such as an update to the default acknowledgment mode.

What’s New in Package Integration 1.4.0?

1️⃣On-Premise Connectivity via SAP Cloud Connector

The AEM Adapter can now officially route traffic to on-premise systems through the SAP Cloud Connector.

This enables a supported hybrid architecture where:

S/4HANA on-prem produces events
SAP AEM distributes them
Network security remains intact

Important note from the official release notes:

Avoid mixing proxy configurations within the same tenant to prevent unexpected routing behavior.

This is especially critical in complex hybrid tenants.

2️⃣Change of Default Acknowledgment Mode

The default acknowledgment mode has changed from:
Automatic Immediate
to Automatic On Exchange Complete

Technical implications:

Clearer delivery semantics
improved error handling
Better alignment with enterprise-grade integration scenarios

Package Integration 1.4.0 introduces multiple technical improvements.
The Cloud Connector support for the Advanced Event Mesh Adapter is a long-requested and architecturally significant enhancement.

It enables a clean, supported reference architecture to connect SAP S/4HANA on-premise directly to SAP Advanced Event Mesh, using SAP Cloud Connector as the secure hybrid backbone.

For SAP architects, this removes a major blocker when designing modern, event-driven hybrid landscapes.

https://api.sap.com/package/AdvancedEventMeshAdapterforSAPIntegrationSuite/documents

🤔 Is This the Right Way to Build Talent Intelligent Hub Integration with SAP Gene AI Hub-Extension

2026-02-15T18:36:04.178000+01:00

****Please check design at the bottom of this article (available for download)***

I've been sketching out an architecture for extending SAP SuccessFactors with AI-powered skills matching and requisition management. But before going down this path, I want to challenge my own assumptions. Is this the best approach, or am I overengineering?

THE PROPOSED ARCHITECTURE:

Here's what I'm considering:

🏗️ Multi-Cloud Foundation (SAP BTP)

- Cloud Foundry runtime for microservices

- HANA DB for data persistence

- Integration Suite for SuccessFactors connectivity

- Identity services for authentication

🤖AI & Analytics Layer

- SAP Generative AI Hub (GPT-4, Claude, Llama)

- Document intelligence and entity extraction

- Vector embeddings for semantic search

- Resume parsing and skills extraction

⚙️Microservices Architecture

- Requisition Analysis Service

- Skills Management Service

- Matching Service

- Custom build services for each capability

📊Advanced Data Layer

- Vector engine for embeddings

- Object store for documents

- HANA DB for structured data

- Build Process Automation for workflows

THE CRITICAL QUESTIONS I'M WRESTLING WITH:

1️⃣DO WE REALLY NEED MULTI-CLOUD COMPLEXITY?

The Good:

✅Flexibility to choose best-of-breed services

✅Avoid vendor lock-in

✅Leverage SAP BTP's enterprise capabilities

The Concerns:

⚠️Operational complexity across multiple clouds

⚠️Higher costs for integration and management

⚠️Steeper learning curve for teams

⚠️More points of failure

Alternative: Could we start with pure SuccessFactors extensions and only move to BTP if we hit limitations?

2️⃣IS MICROSERVICES THE RIGHT PATTERN HERE?

The Good:

✅Independent scaling of services

✅Team autonomy and faster deployment

✅Technology flexibility per service

The Concerns:

⚠️Distributed system complexity

⚠️Network latency between services

⚠️Harder to debug and monitor

⚠️Overkill for a small team or MVP?

Alternative: What if we started with a modular monolith and decomposed later based on actual bottlenecks?

3️⃣ARE WE READY FOR GENERATIVE AI IN PRODUCTION HR?

The Good:

✅Intelligent resume parsing and skills extraction

✅Natural language requisition analysis

✅Semantic matching beyond keyword search

✅Document generation and summarization

The Concerns:

⚠️Hallucination risks in HR decisions

⚠️Bias and fairness implications

⚠️Explainability requirements for hiring

⚠️Cost per API call at scale

⚠️Data privacy and compliance (GDPR, EEOC)

Alternative: Should we start with rule-based matching and traditional NLP, then layer in GenAI for non-critical features?

4️⃣DO WE NEED VECTOR EMBEDDINGS AND SEMANTIC SEARCH?

The Good:

✅Find similar skills even with different terminology

✅Semantic matching beyond exact keywords

✅Better candidate-requisition alignment

The Concerns:

⚠️Added infrastructure complexity (vector DB)

⚠️Embedding model maintenance and updates

⚠️Explainability: "Why was this candidate matched?"

⚠️Cost of generating and storing embeddings

Alternative: Could traditional search with synonyms and taxonomies get us 80% of the value with 20% of the complexity?

5️⃣IS THE INTEGRATION LAYER OVER-ARCHITECTED?

The Good:

✅Clean separation of concerns

✅Reusable integration patterns

✅API management and event mesh

The Concerns:

⚠️Do we need event mesh for this use case?

⚠️Is Build Process Automation necessary or could we use simpler workflows?

⚠️Are we adding layers that slow down development?

Alternative: Direct SuccessFactors OData APIs with simple retry logic?

WHAT MIGHT BE A SIMPLER STARTING POINT?

Phase 1: Validate the Value

- Build a SuccessFactors extension app (UI5)

- Use SuccessFactors APIs directly

- Simple keyword-based matching

- Manual review and approval workflows

- Prove the business value first

Phase 2: Add Intelligence Gradually

- Introduce resume parsing (traditional NLP)

- Add skills taxonomy and synonyms

- Basic analytics dashboard

- Measure improvement over baseline

Phase 3: Scale What Works

- Only then consider microservices if we have clear scaling needs

- Add GenAI for specific high-value use cases

- Introduce vector search if keyword matching proves insufficient

- Expand to multi-cloud only if we need capabilities not in SuccessFactors

THE REAL QUESTIONS:

💭Am I solving for scale we don't have yet?

💭Am I choosing technology because it's interesting vs. because it's necessary?

💭What's the simplest thing that could possibly work?

💭How do we balance innovation with pragmatism?

💭What would a true MVP look like?

WHAT I'D LOVE YOUR INPUT ON:

🔹Have you built similar HR/talent extensions? What worked? What didn't?

🔹Where have you seen GenAI add real value in recruiting vs. just hype?

🔹When is microservices worth it vs. premature optimization?

🔹How do you balance "enterprise-grade" with "ship fast and learn"?

🔹What would you do differently?

I'm genuinely torn between building something robust and future-proof vs. starting simple and evolving based on real needs.

What's your take? Is this architecture the right approach, or should we start simpler and earn our way to complexity?

Drop your thoughts below - especially if you think I'm overcomplicating this! 👇

#EnterpriseArchitecture #SAPSuccessFactors #SAPBTP #TalentManagement #AIinHR #Microservices #CloudArchitecture #SoftwareEngineering #TechLeadership #ArchitecturalDecisions #BuildOrBuy #MVPFirst #OverengineeringDebate