SAP Community - SAP Connectivity service

Tell us about Your Experience with SAP BTP Connectivity

2023-10-18T23:22:32+02:00

Have you ever been in touch with the Connectivity service or the Destination service for SAP Business Technology Platform (SAP BTP)?

For example, creating or configuring a destination in the BTP cockpit, or doing some connectivity configuration in your app code?

If so, let us know about your experience.

There's a really short survey (5 minutes or less) that will help us improve SAP BTP Connectivity components according to your feedback.

You can find the survey here.

Thank you!

It has never been easier! Connecting cloud apps to Internet and on-premises systems using SAP BTP Connectivity

2023-11-14T21:29:59+01:00

It is a common scenario that cloud applications need to connect to remote systems to fulfil the business goals of their creators and those of their end users. This is essential for enterprise applications, which are generally complex and consume data from and/or push data to a variety of sources or destinations – systems that are directly accessible, systems hosted in public or private cloud, or such that are hosted in the customer premises. This use case is called hybrid connectivity.

Sounds complex, right?! With this blog post, I show you that it has never been easier to solve this problem. Let’s get started and see how SAP BTP Connectivity can help with this challenge, more specifically, in SAP BTP Kyma environment.

Prerequisites

Well, complex things cannot be made simple without proper preparation work. Therefore, I need to setup the environment. For the purposes of this blog post, I don’t get into details on how each step is done, if interested, you can follow the links:

Setup the cloud environment:

Create a SAP BTP subaccount - the PaaS context in the domain of SAP BTP, i.e., an account enabled to instantiate cloud application development environments, create and manage service instances, etc.
Enable Kyma environment - the cloud-native application hosting environment
1. Enable Connectivity Proxy for cloud to premise technical connectivity, an integrated module in Kyma environment
  Edit: In the meantime, since March 12, 2024, Connectivity Proxy has become a native Kyma Module
2. Enable Transparent Proxy for unified, virtually transparent technical connectivity to any destination or data source, an integrated module in Kyma environment

Setup the local environment
1. Install Kubectl - the command line interface for connecting to and interacting with the Kyma instance
2. Install Cloud Connector for controlled and secure exposure concrete systems or resources, hosted in a VPC on Hyperscalers or on-premises - in my case, on my PC.
For each scenario use case, create the relevant destinations in SAP Destination service using SAP BTP cockpit.

Overview of the scenario

Image: Scenario Schematic Overview

This solution diagram depicts the high-level architecture and layout of the SAP BTP tools, software components, services listed above in the Prerequisites section. The focus on the scenario is on the Application side. The rest is depicted for completeness and better end-to-end understanding.

In this blog, I showcase how I can connect my cloud application to the following target systems. I start with the trivial and then continue with the more advanced use cases:

Google - direct connectivity without using any of the SAP BTP Connectivity software and services
Google via destination - direct connectivity with usage of SAP BTP Connectivity software and services
Google via destination and Cloud Connector - indirect cloud to premise connectivity - in my setup Google is directly accessible via my local Cloud Connector
Note: this use case is presented only for the purpose of showcase and ease the perception of the reader, it is not expected to be done in production
SAP Authorization and Trust Management Service (XSUAA) via destination - OAuth based REST API
An HTTP system hosted on-premises via destination and Cloud Connector - indirect cloud to premise connectivity
An HTTPS system hosted on-premises via destination and Cloud Connector - indirect cloud to premise connectivity with Principal Propagation enabled, i.e., end-to-end secure user context propagation, a.k.a Single Sign On (SSO).

I pick those systems to showcase what I claimed in the begging of this blog - It has never been easier!

Note: For the creation of the destination pointing to XSUAA in step 4 of the scenario, I followed these two simple steps in BTP cockpit:

Create a service instance of service "xsuaa", plan "apiaccess"
Create a destination pointing to the service instance via destinations UI - just a few clicks job!

Configure the scenario

To get the scenario in action, at first I need to configure the target systems as technical connection configurations, a.k.a. destinations. In this way I control to which systems the application has access to and can switch the used technical authentication and authorisation mechanisms on the fly – changing the destination attributes without affecting the experience of the end user, and without affecting the lifecycle of the application.

Expose the on-premises system to the cloud

For the destinations pointing to systems hosted in the customer premises (points 5 and 6 of the scenario overview), I need to securely expose those to the cloud.

You guessed it, for this I configure the respective Access Controls in my SAP Cloud Connector:

Image: Access Control entries in Cloud Connector

In this example, the two systems hosted in the on-premises are simple HTTP and HTTPS servers:

System #1: localhost:8000 - serves HTTP, returns status code: 200 with the received HTTP request line as a message.

System #2: localhost:9000 - serves HTTPS, returns status code: 200 with the received HTTP request line as a message, and the subject common name (CN) of the received X.509 client certificate as part of the HTTP request - the user context propagated from the cloud, achieving Single Sign-On (SSO).

Manage the technical connection configurations

One of the best practices for cloud-native applications is to externalise any configuration and avoid coupling it with the lifecycle of the application, e.g. via hard-coding it. I use Destination service for managing the technical connection configurations (a.k.a. destinations), as guided by the Golden Path defined in Cloud Application Programming model of SAP BTP.

In the context of my SAP BTP subaccount, I create the following destinations, pointing to the variety of systems I’ll connect my cloud app workload running in my Kyma instance.

Image: Destinations in BTP cockpit

Expose the destinations in the Kyma instance

To allow an application to consume the defined destinations, I declaratively expose only those I'm interested in, and are specific for this particular use case. For this, I create specific Destination Custom Resources, a common practice for cloud-native applications based on Kubernetes. In Kyma environment, I can do this either via Kyma Dashboard, or via command-line using Kubectl.

Image: Creation of a Destination CR in Kyma Dashboard

Shortly after the Destination CR is created, Transparent Proxy process it and updates the status of the Destination CR with a message that the technical connectivity is successfully configured, and this destination is ready to be consumed.

Image: Status of a Destination CR in Kyma Dashboard

Using the same approach, I expose all the destinations required specifically for this use case.

Image: Destination CRs in Kyma Dashboard

It's all set now, let's play with the application.

Scenario in action: Connect the application to the remote systems

As described in the status message of the Destination CR, the Transparent Proxy exposed the referenced destination via the specified name in the form of locally accessible host, leveraging the concept of Kubernetes Service.

As a result, it’s trivial for the application to connect to those local hosts, and this is the only task needed to be performed. It’s that easy!

For simplicity and versatility reasons, my application is represented by a local terminal attached to a container running in a Kubernetes Pod in the Kyma Instance. Then I use cURL command-line tool for executing HTTP requests towards the target systems.

How it’s done? Once connected to the Kyma instance via Kubectl, I run a sample cURL image as a Kuberenetes Pod and open a terminal session via the following command:

kubectl run mycurlpod -n sap-transp-proxy-system --image=curlimages/curl -i --tty -- sh

Executing request to Google:

This is a trivial direct invocation of the public web page of Google:

~ $ curl www.google.com -v

*   Trying 142.250.179.164:80...

* Connected to www.google.com (142.250.179.164) port 80

> GET / HTTP/1.1

> Host: www.google.com

> User-Agent: curl/8.4.0

> Accept: */*

> 

< HTTP/1.1 200 OK

...

< 

<!doctype html><html...<title>Google</title><script...

Executing request to Google via destination:

This is an example reaching the same public web page of Google, but this time via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service:

~ $ curl google -v

*   Trying 10.111.255.220:80...

* Connected to google (10.111.255.220) port 80

> GET / HTTP/1.1

> Host: google

> User-Agent: curl/8.4.0

> Accept: */*

> 

< HTTP/1.1 200 OK

...

< 

<!doctype html><html...<title>Google</title><script...

Executing request to Google via destination via Cloud Connector:

This is an example of reaching the same public web page of Google via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:

~ $ curl mypremisegoogle -v

*   Trying 10.111.159.5:80...

* Connected to mypremisegoogle (10.111.159.5) port 80

> GET / HTTP/1.1

> Host: mypremisegoogle

> User-Agent: curl/8.4.0

> Accept: */*

> 

< HTTP/1.1 200 OK

...

< 

<!doctype html><html...<title>Google</title><script...

Executing request to XSUAA API via destination:

This is an example for getting the registered service instances of the current subaccount via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service.

~ $ curl xsuaa-api/sap/rest/authorization/v2/apps -v

*   Trying 10.106.192.162:80...

* Connected to xsuaa-api (10.106.192.162) port 80

> GET /sap/rest/authorization/v2/apps HTTP/1.1

> Host: xsuaa-api

> User-Agent: curl/8.4.0

> Accept: */*

> 

< HTTP/1.1 200 OK

< cache-control: no-cache, no-store, max-age=0, must-revalidate

< content-length: 10621

...

< 

[{"appid":"app123!b13","serviceinstanceid":"15442f82-7d82-11ee-b26d-ab53f17d39a5","planId":"HWEgt9/213f90b0+/7d82-11ee=","planName":"broker"...

Executing request to an on-premises HTTP server via destination via Cloud Connector:

This is an example of connecting to a simple on-premises HTTP server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:

~ $ curl mypremserver/test-path -v

*   Trying 10.110.23.19:80...

* Connected to mypremserver (10.110.23.19) port 80

> GET /test-path HTTP/1.1

> Host: mypremserver

> User-Agent: curl/8.4.0

> Accept: */*

> 

< HTTP/1.1 200 OK

...

< 

Response generated by HTTP server: 

GET /test-path HTTP/1.1

Executing request to an on-premises HTTPS server via destination via Cloud Connector with Single Sign-On enabled:

This is an example of connecting to an on-premises HTTPS server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The HTTPS server requires the cloud user identity to be propagated. The destination is configured with PrincipalPropagation as authentication type, and to point to an on-premises system, exposed to the cloud via Cloud Connector:

~ $ curl myppserver -H 'Authorization: Bearer eyJhbGciOiJSUzI1Ni...bwKMpAGKbhECqvkyibC7Q' -v

*   Trying 10.105.101.106:80...

* Connected to myppserver (10.105.101.106) port 80

> GET / HTTP/1.1

> Host: myppserver

> User-Agent: curl/8.4.0

> Accept: */*

> Authorization: Bearer yJhbGciOiJSUzI1Ni...bwKMpAGKbhECqvkyibC7Q

> 

< HTTP/1.1 200 OK

< server: envoy

< date: Tue, 07 Nov 2023 15:17:47 GMT

< content-type: text/plain; charset=utf-8

< content-length: 1956

< x-envoy-upstream-service-time: 657

< 

>>>>>>>>>

Response generated by HTTPS server: 

GET / HTTP/1.1

=========

Received X.509 client certificate with Subject: <Name(CN=manol.valchev@sap.com)>

Summary

As you can see, it’s that simple! No matter of the type and hosting location of the target system, from the application development perspective the user experience is the same – simple, unified, virtually transparent, and the technical complexity is handled by the usage of software components and services part of SAP BTP Connectivity product portfolio:

Destination service for managing the technical connection configurations (a.k.a. destinations)

Transparent Proxy for unified, virtually transparent technical connectivity to any destination or data source, an integrated module in Kyma environment, also available in Docker Hub.

Connectivity Proxy for cloud to premise technical connectivity, an integrated component in Kyma environment, also available in Docker Hub.

Cloud Connector for controlled and secure exposure concrete systems or resources, hosted in a VPC on Hyperscalers or on-premises.

Connectivity service as the backbone for the multitude of Connectivity Proxy and Cloud Connector instances serving thousands of SAP BTP customers

Тhis simple yet powerful approach enables application developers to focus more on their business goals and delegate the technical complexity to SAP BTP Connectivity, and at the same time the application administrators can manage the outbound technical connections (via destinations) without affecting the lifecycle and availability of the application itself.

Stay tuned and subscribe to What's New for SAP BTP Connectivity page.

Hey ABAP Cloud please let me save my data export to Azure Storage please🥺🙏- part 4

2023-11-21T13:21:26+01:00

👉🏿back to blog series or jump to GitHub repos🧑🏽‍💻

<<part 3

Hello and welcome back to your ABAP Cloud with Microsoft integration journey. Part 3 of this series got you covered with modern GraphQL API definition on top of your ABAP Cloud RAP APIs to expose a single API endpoint that may consume many different OData, OpenAPI, or REST endpoints at the same time.

Today will be different. Sparked by a SAP community conversation with dpanzer and lars.hvam including a community question by rammel on working with files with ABAP Cloud, I got inspired to propose a solution for the question below:

Before we dive into my proposal see here a list of alternative options that I came across as food for thought for your own research.

Mount a file system to a Cloud Foundry app	Create custom API hosted by your CF app and call via http client from ABAP Cloud
Connect to SFTP server via SAP Cloud Integration	Design iFlow and call via http client from ABAP Cloud
Integrate with SAP Document Management Service	Call SAP BTP REST APIs from ABAP Cloud directly
Integrate with SAP BTP Object Store exposing hyperscaler storage services using SDKs	Create custom API hosted by your CF or Kyma app and call via http client from ABAP Cloud
Serve directly from ABAP Code via XCO	Base64-encode your file content, wrap into ABAP code, and serve as XCO class. Lars likes it at least 😜. There were sarcastic smiles involved and some more “oh please”, so take it not too seriously.
Raise an influencing request at SAP to release something like the former NetWeaver MIME repos	Live the dream

A common theme among all the options is the need to interact with them from ABAP Cloud via the built-in http client. On the downside some options require an additional app on CF or Kyma to orchestrate the storage interactions.

Ideally ABAP Cloud integrates directly with the storage account to reduce complexity and maintenance.

You guessed rightly my own proposal focusses on direct integration with Azure Blob

To get started with this sample I ran through the SAP developer tutorial “Create Your First ABAP Cloud Console Application” and steps 1-6 of “Call an External API and Parse the Response in SAP BTP ABAP Environment. This way you can easily reproduce from an official reference.

Got your hello world on Eclipse? Great, onwards, and upwards in the stack we go then 🪜. Or down to the engine room – that depends on your perspective.

All the blob storage providers offer various options to authenticate with the service. See the current coverage for Azure here.

Fig.1 Screenshot of supported authentication methods for Azure Storage

The Microsoft Entra ID option offers superior security capabilities compared to access keys – which can be leaked or lost for example – and is therefore recommended by Microsoft.

For developer ease, I left the code using the simpler to configure “Shared-Access-Signature (SAS) tokens” commented on the shared GitHub repos. SAS tokens can be created from the Azure portal with two clicks.

The shared key approach requires a bit of hashing and marshaling on ABAP. Use the ABAP SDK for Azure to accelerate that part of your implementation. Check the “get_sas_token” method for reference.

Anonymous read access would only be ok for less sensitive content like static image files or the likes because anyone can access them once they have the URL.

For an enterprise-grade solution however, you will need to use a more secure protocol like OAuth2 with Microsoft Entra ID

Technically you could do the OAuth2 token fetching with plain http-client requests from ABAP Cloud. See this blog by jacek.wozniczak for instance. However, it is recommended to use the steampunk “Communication Management” to abstract away the configuration from your code. Think “external configuration store”. Also, it reduces the complexity of your ABAP code, because Communication Management handles the OAuth2 flow for you.

📢Note: SAP will release the needed capability to maintain OAuth2 scopes in communication arrangements as part of your ABAP Cloud requests with the upcoming SAP BTP, ABAP environment 2402.

So, till then you will need to use the BTP Destination service. Target destinations living on subaccount level by calling them like so (omitting the i_service_instance_name, thank you thwiegan for calling that out here😞

destination = cl_http_destination_provider=>create_by_cloud_destination(

        i_name = |azure-blob|

        i_authn_mode = if_a4c_cp_service=>service_specific

    ).

Or call destinations living on Cloud Foundry spaces like so:

destination = cl_http_destination_provider=>create_by_cloud_destination(

        i_name = |azure-blob|

        i_service_instance_name = |SAP_BTP_DESTINATION|

        i_authn_mode = if_a4c_cp_service=>service_specific

    ).

For above Cloud Foundry variation you need to deploy the “standard” communication scenario SAP_COM_0276. My generated arrangement id in this case was “SAP_BTP_DESTINATION”.

Be aware, SAP marked the approach with BTP destinations as deprecated for BTP ABAP. And we can now see why. It will be much nicer doing it from the single initial communication arrangement only, rather than having the overhead with additional services and arrangements. Looking forward to that in February 😎

Not everything is “bad” about using BTP destinations with ABAP Cloud though. They have management APIs, which the communication arrangements don’t have yet. Also, re-use of APIs across your BTP estate beyond the boundary of your ABAP Environment tenant would be useful.

A fully automated solution deployment with the BTP and Azure terraform providers is only possible with the destination service approach as of today.

See this TechEd 2023 session and watch this new sample repos (still in development) for reference.

The application flow is quite simple once the authentication part is figured out

Access your communication management config from your ABAP web Ui:

https://your-steampunk-domain.abap-web.eu20.hana.ondemand.com/ui#Shell-home

Steampunk supports the typical set of authentication flows for outbound communication users using http that you are used to from BTP. I chose the OAuth2 Client Credentials grant because that is most widely referenced in the BTP world and reasonably secure.

Fig.2 ABAP Cloud API flow including OAuth2 token request from Microsoft Entra ID

Since I am integrating with an Azure Storage account, I will need to authenticate via Microsoft Entra ID (formerly known as Azure Active Directory).

Yes, Microsoft likes renaming stuff from time to time, too 😉.

Using the Azure Storage REST API I can create, update, delete, and list files as I please.

The Entra ID setup takes a couple of clicks

Create a new App registration from Microsoft Entra ID service on your Azure portal and generate a new secret. Beware of the expiry date!

Below preferred option will start working once SAP adds the scope parameter for OAuth2 Client Credentials grant as described before.

Fig.3 Screenshot of attribute and secret mapping for ABAP Cloud Outbound user

For now, let’s have a look at a destination on subaccount level instead. Be aware the scope parameter needs to be “https://storage.azure.com/.default” (see fig.4 below, additional properties section called “scope” on the bottom right). That is also the setting that we are missing for the preferred approach mentioned above.

The standard login URLs for OAuth token endpoints on Microsoft Entra ID are the following:

https://login.microsoftonline.com/your-tenantId/oauth2/v2.0/token

https://login.microsoftonline.com/your-tenantId/oauth2/v2.0/authorize

Fig.4 Screenshot of attribute mapping from Entra ID to SAP BTP Destination

So far so good. Let’s roll the integration test from our ABAP console application on Eclipse (ADT).

Fig.5 Screenshot of file interaction from ABAP Cloud and data container view on Azure

Excellent, there is our booking request: Safe and sound stored as Azure Blob, posted from ABAP, and read again seamlessly.

See the shared Postman collection to help with your integration testing.

Thoughts on production readiness

The biggest caveat is the regularly required OAuth2 client credential secret rotation. Unfortunately, credential-free options with Azure Managed Identities are not possible, because BTP is hyperscaler-agnostic and does not expose the underlying Azure components to you.

Some of you might say next: let’s use client certificates with “veeery long validity time frames like 2038” to push out the problem beyond so far out someone else will have to deal with it. Well, certificate lifetimes get reduced more and more (TLS certs for instance have a maximum of 13 months at DigiCert since 2020) and you have to rotate them eventually, too 😉. With shorter certificate lifetimes more secure hashing algorithms come into effect much quicker for instance.

I will dedicate a separate post on client certificates (mTLS) with steampunk to consume Azure services.

What about federated identities? You could configure trust between your SAP Cloud Identity Service (or Steampunk auth service) and Microsoft Entra ID to allow requests from ABAP Cloud to authorize Azure services. However, that would be a more complex configuration with implications for your overall setup causing larger integration test needs. And we embarked on this journey to discover a simple solution not too far away from AL11 and the likes, right? 😅

See a working implementation of federated identities with SAP Cloud Identity service consuming Microsoft Graph published by my colleagure mraepple in his blog series here.

Ok, then let’s compromise and see how we can automatically rotate secrets. Azure Key Vault exposes events for secrets, keys, and certificates to inform downstream services about due expiry. With that a small low code app can be provided to perform the secret update. See below sample that went the extra mile asking the admins via Microsoft Teams if they wanted to perform the change or not:

Fig.6 Architecture of secret rotation with Azure Key Vault and secret refresh approval

A new secret for the app registration on Entra can be generated with the Microsoft Graph API like so. See this post for details on the Azure Key Vault aspects of the mix.

To apply that flow and propagate the new secret to steampunk, we need to call BTP APIs to save the new secret. See the BTP REST API for Destinations here to learn about the secret update method.

Have a look at my earlier blog post for specifics on how to do the same with certificates.

Estimated cost for such a secret rotation solution for 1000 rotations per month is around 2$ per month. With simpler configurations and less rotations, it can be covered by free tiers even.

Once you have applied the means of automation as discussed above you may incorporate this into your DevOps process and live happily ever after with no manual secret handling 😊.

Final Words

That’s a wrap 🌯you saw today how – in the absence of an application server file system and NetWeaver MIME repository (good old days) – you can use Azure Storage Account as your external data store from BTP ABAP Environment (steampunk) using ABAP Cloud. In addition to that, you gained insights into the proper setup for authentication and what flavors are supported by steampunk now. You got a glimpse into automated deployment of the solution with the BTP and Azure terraform provider.

To top it up you learnt what else is needed to operationalize the approach at scale with regular secret/certificate rotation.

Check SAP’s docs for external APIs with steampunk for further official materials.

What do you think dpanzer and lars.hvam? Not too bad, is it? 😉

Find all the resources to replicate this setup on this GitHub repos. Stay tuned for the remaining parts of the steampunk series with Microsoft Integration Scenarios from my overview post.

Cheers

Martin

Child's play: Install SAP BTP transparent proxy using Helm

2024-01-15T16:14:28+01:00

It is inevitable that cloud solutions have to communicate with other remote solutions. The latter can be situated on public or private clouds, or set up on client sites. Of course, it would be easier to have levers to facilitate this in the simplest possible way. This is where the SAP BTP Connectivity services and components come to the rescue! In this blog post, you will understand how to install one of these components using Helm: the SAP BTP transparent proxy.

SAP BTP transparent proxy simplifies the connection between Kubernetes workloads and target systems defined as destinations in the SAP Destination service. To understand more about some of the features of the Transparent Proxy, you could check this blog.

Prerequisites

Before you start, you should have the following:

A Kubernetes cluster
Kubectl installed and configured on your local machine
Helm installed on your local machine
SAP BTP subaccount with a Destination service instance and a Connectivity Proxy instance (optional for on-premise connectivity)
Istio or cert-manager running in your Kubernetes cluster as a foundation for traffic encryption between the micro-components of the Transparent Proxy
Connectivity proxy installed in your cluster (optional for on-premise connectivity)

Installation steps

To install the Transparent Proxy using Helm, follow these steps:

1. Create a namespace for the Transparent Proxy in your Kubernetes cluster. For example:

kubectl create namespace transparent-proxy

2. Create a Kubernetes secret with the credentials of your Destination service instance

You can obtain the credentials from the SAP BTP cockpit. Navigate to Services -> Instances and Subscriptions -> Click on the service instance row -> Service Keys -> View -> Copy JSON

Use the service key data to create the Kubernetes secret. For example:

kubectl create secret generic dest-svc-key -n transparent-proxy --from-literal=secret='<credentials>'

3. Create values.yaml according to your needs. You can find all available parameters here. For example:

config:
  security:
    communication:
      internal:
        encryptionEnabled: true
  integration:
    destinationService:
      defaultInstanceName: <instance-name>
      instances:
        - name: <instance-name>
          serviceCredentials:
            secretKey: <secret-key>
            secretName: <secret-name>
    serviceMesh:
      istio:
        istio-injection: enabled

4. Install the Transparent Proxy using the Helm values from step 3:

helm install transparent-proxy oci://registry-1.docker.io/sapse/transparent-proxy --version <version of helm chart> --namespace transparent-proxy -f <path-to-values.yaml>

You should receive a similar to this response:

Successful installation of Transparent Proxy with Helm

5. Verify that the Transparent Proxy is running by checking the status of the pods and the health check:

kubectl get pods -n transparent-proxy

There should be two pods running:

Transparent Proxy components after installation

As you can see, the Transparent Proxy has a health check pod which constantly checks the status of all Transparent Proxy components. You can look at what capabilities the health check has in the Verification and Testing page in the Help portal. Here's how you can execute a component check:

kubectl run perform-hc --image=curlimages/curl -it --rm --restart=Never -- curl -w "\n" 'sap-transp-proxy-int-healthcheck.transparent-proxy/status'

And the result should be the following:

This means that the sap-transp-proxy-manager, the heart of the Transparent Proxy, is running smoothly and you are ready to consume your first target system through the Transparent Proxy!

Try it out

To use the Transparent Proxy, you should create a Destination Custom Resource (CR). Let's create a dynamic one. "Dynamic" means a Destination CR will serve all destinations for a Destination service instance or its tenants. Follow these steps:

1. Create a Destination CR file with name dynamic-destination.yaml:

apiVersion: destination.connectivity.api.sap/v1
kind: Destination
metadata:
  name: dynamic-destination
  namespace: transparent-proxy
spec:
  destinationRef:
    name: "*"
  destinationServiceInstanceName: dest-service-instance

2. Create the resource from step 1 in your cluster:

kubectl create -f dynamic-destination.yaml

3. Wait for a successful status of the Destination CR. To check it execute:

kubectl get dst dynamic-destination -n transparent-proxy -o yaml

You should observe a status similar to this one:

status:
  conditions:
  - lastUpdateTime: "2024-01-11T11:56:33.605473101Z"
    message: Technical connectivity is configured. Kubernetes service with name
      dynamic-destination is created.
    reason: ConfigurationSuccessful
    status: "True"
    type: Available

4. Create a curl pod, from where you can test the consumption of the target system through the Transparent Proxy:

kubectl run curlpod -n transparent-proxy --image=curlimages/curl -n transparent-proxy -i --tty -- sh

5. Consume a target system defined as a destination in your Destination service instance:

curl dynamic-destination -H "X-Destination-Name: <destination-name>"

Examples

In the context of my SAP BTP subaccount, I have created two destinations: one pointing to the SAP XSUAA API, and another pointing to a server on my local machine, exposed to the cloud via the SAP Cloud Connector.

Configured destinations in the SAP BTP Cockpit

Executing a request to the SAP XSUAA API. This is an example for getting the registered service instances of the current subaccount via destination, locally exposed and served by Transparent Proxy, and centrally managed via the SAP Destination service:

~ $ curl dynamic-destination/sap/rest/authorization/v2/apps -H "X-Destination-Name: xsuaa-api" -v
* Host dynamic-destination:80 was resolved.
...
> GET /sap/rest/authorization/v2/apps HTTP/1.1
> Host: dynamic-destination
> User-Agent: curl/8.5.0
> Accept: */*
> X-Destination-Name: xsuaa-api
> 
< HTTP/1.1 200 OK
...
[{"appid":"auditlog!b3718","serviceinstanceid":"0889a7e7-61d8-41...

Executing a request to an on-premise system using principal propagation. That system is a simple server that maps the user certificate to a concrete user. The current response greets the requestor.

~ $ curl dynamic-destination/principal-propagation -H "X-Destination-Name: my-on-premise-system" -H "Authorization: Bearer $TOKEN" -v
* Host dynamic-destination:80 was resolved.
...
* Connected to dynamic-destination (10.104.69.106) port 80
> GET /principal-propagation HTTP/1.1
> Host: dynamic-destination
> User-Agent: curl/8.5.0
> Accept: */*
> X-Destination-Name: my-on-premise-system
> Authorization: Bearer eyJhbGciOiJSUzI1NiIsImprdS...
...
< HTTP/1.1 200 OK
...
Hello Iliyan Videnov!

In this blog post, you have learned how to install SAP BTP transparent proxy using Helm, and how to easily set up it for system consumption. I hope you find it useful and enjoy it. Ideas, suggestions, and comments are welcome. Thank you for reading!

New Release Available: SAP Cloud Connector 2.17.0

2024-05-10T14:33:54.505000+02:00

We are happy to announce that the fresh version of the SAP Cloud Connector is now available for download. It is (as usual) packed with a host of new features and improvements. From bug fixes to enhancements, we've worked diligently to deliver an updated connector that addresses critical issues while also enhancing usability and functionality, which you can find more detailed in the release notes.
Moving onto enhancements, we've made changes to the underlying architecture and features of the Cloud Connector. One of the major changes is the switch from JavaWeb 3.x runtime on Tomcat 8.5 to JavaWeb 4.x, which operates on Tomcat 9. This new runtime container facilitates better performance and stability.
In addition, Cloud Connector 2.17 now supports the use of SapMachine 21 as Java runtime. This change can provide increased efficiency and flexibility for your operations.
One of the significant enhancements in this release is the addition of support for up to 3 LDAP servers for authentication.

This feature is essential for setups where the user base is spread across multiple LDAP user stores or multiple user bases in a single LDAP user store (find more in the documentation).
We've also introduced the option to configure a separate port for the HA-related communication between the master and shadow instances.

This new feature enables you to use HA in conjunction with certificate-based authentication to overcome the limitation from 2.16 (find more here)
Additional hardware monitoring REST APIs have been provided for disk and CPU status, allowing for more comprehensive system insights. Plus, you can now use the hardware monitor on the shadow instance as well.
To improve your operations, we’ve introduced for the access control settings a creation timestamp, providing more detailed and useful information for your operations:

Finally, we've improved the Cloud Connector UI by adding a session expiration progress bar. This new addition helps you keep track of your active session and alerts you when you need to log in again.

In summary, with this release, we've not only ensured the highest security levels but also worked on improving the overall user experience and functionality. Don't hesitate to upgrade your Cloud Connector to version 2.17.0 today (by downloading it from here) and explore these new features and improvements. For more detailed information, make sure to check out the official release notes. Enjoy the enhanced performance and functionality of the new SAP Cloud Connector!Happy Connecting!

Configuration as code (CaC) with destinations.

2024-05-13T12:54:57.123000+02:00

Configuration as code (CaC) with destinations.

Destinations are very handy and powerful mechanism to facilitate access to target systems and devices.

When it comes to SAP BTP destinations, the idea is to manage both subaccount and instance level destinations (and/or their certificates) as shared configuration resources on a provider subaccount level.

That way, the destinations configurations can be stored as versioned assets in a source repository and need to be maintained only once per provider, thus, without incurring application runtime tie-in.

Last but not least, BTP destination service is used as a self-configuration tool.

Configuration as code with SAP BTP destination service

Table of Contents

Configuration as code with SAP BTP destination service.

create shared destination service instance and binding.

Provision bootstrap destinations.

Configure destination resources.

Documentation.

PS.

Bootstrap destinations definitions.

Even, if there is no intrinsic BTP CLI command to assist in creation of destinations from service bindings, this can be achieved quite easily with a bit of jq gimmick by applying service binding credentials to a json payload template, for instance:

{
    "init_data": {
        "subaccount": {
            "destinations": [
                  {
                    "Description": "dest-httpbin",
                    "Type": "HTTP",
                    "clientId": "sb-clone12847c4c89544b4f9234b26ede429f62!b282590|destination-xsappname!b62",
                    "HTML5.DynamicDestination": "true",
                    "HTML5.Timeout": "60000",
                    "Authentication": "OAuth2ClientCredentials",
                    "Name": "dest-httpbin",
                    "tokenServiceURL": "https://<subdomain>.authentication.us10.hana.ondemand.com/oauth/token",
                    "ProxyType": "Internet",
                    "URL": "https://httpbin.org",
                    "tokenServiceURLType": "Dedicated",
                    "clientSecret": "<clientSecret>"
                  },
                  {
                    "Description": "SAP Destination Service APIs",
                    "Type": "HTTP",
                    "clientId": "sb-clone12847c4c89544b4f9234b26ede429f62!b282590|destination-xsappname!b62",
                    "HTML5.DynamicDestination": "true",
                    "HTML5.Timeout": "60000",
                    "Authentication": "OAuth2ClientCredentials",
                    "Name": "destination-service",
                    "tokenServiceURL": "https://<subdomain>.authentication.us10.hana.ondemand.com/oauth/token",
                    "ProxyType": "Internet",
                    "URL": "https://destination-configuration.cfapps.us10.hana.ondemand.com/destination-configuration/v1",
                    "tokenServiceURLType": "Dedicated",
                    "clientSecret": "<clientSecret>"
                  }
            ],
           "certificates": [
           ],

            "existing_certificates_policy": "update",
            "existing_destinations_policy": "update"           
       }
   }
}

Alternatively, one could resort to using SAP Cloud SDK built-in service binding destinations.

The below nodejs code snippet demonstrates how to leverage SAP Cloud SDK with its service binding destinations with the likes of service manager and destinations services.

apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
  name: {{ .Values.services.srv.name }}
  labels:
    {{- include "app.labels" . | nindent 4 }}
    app: {{ .Values.services.srv.name }}
spec:
  runtime: {{ .Values.services.srv.runtime }}
#  runtimeImageOverride: {{ .Values.services.srv.runtimeImageOverride }}
  source:
    inline:
      dependencies: |
        {
          "name": "{{ .Values.services.srv.name }}",
          "version": "0.0.1",
          "dependencies": {
            "axios":"latest"
            ,"debug": "latest"
            ,"@sap/xsenv": "latest"
            ,"@sap-cloud-sdk/http-client": "latest"
            ,"@sap-cloud-sdk/connectivity": "latest"
            ,"@sap-cloud-sdk/resilience": "latest"
            ,"async-retry": "latest"
          }
        }
      source: |
        const debug = require('debug')('{{ .Values.services.srv.name }}:function');
        const NOT_FOUND = 'Not Found';
        const xsenv = require('@sap/xsenv');

        const services = xsenv.getServices({
          sm: { label: 'service-manager', name: 'saas-sm' }
          ,
          dest: { label: 'destination' }

        });
        console.log('saas-sm: ', services.sm);

        const readServices = xsenv.readServices();
        console.log('readServices: ', readServices);

        const httpClient = require('@sap-cloud-sdk/http-client');

        const cloudSdkConnectivity = require('@sap-cloud-sdk/connectivity');
        const { retrieveJwt, decodeJwt, Destination } = require('@sap-cloud-sdk/connectivity');
        const { setGlobalLogLevel, createLogger } = require('@sap-cloud-sdk/util');
        const { retry } = require ('@sap-cloud-sdk/resilience');
        const { resilience } = require ('@sap-cloud-sdk/resilience');
        const ResilienceOptions = {
          retry: 10,
          circuitBreaker: false,
          timeout: 300*1000 // 5 minutes in milliseconds
        };          

        const retryme = require('async-retry');

        setGlobalLogLevel('debug');
        const logger = createLogger('http-logs');

        module.exports = {
          main: async function (event, context) {
            const req = event.extensions.request;

            const message = `Hello World`
              + ` from the Kyma Function ${context['function-name']}`
              + ` running on ${context.runtime}!`
              + ` with the request headers ${JSON.stringify(req.headers,0,2)}`;
            console.log(message);
            
            if (typeof req.path !== undefined) {
              console.log('path: ', JSON.stringify(req.path,0,2))
            }
            if (typeof req.params !== undefined) {
              console.log('params: ', JSON.stringify(req.params,0,2))
            }
            if (typeof req.url !== undefined) {
              console.log('url: ', JSON.stringify(req.url,0,2))
            }
            if (typeof req.authInfo !== undefined) {
              console.log('authInfo: ', JSON.stringify(req.authInfo,0,2))
            }

            const { pathname } = new URL(req.url || '', `https://${req.headers.host}`)
            console.log('pathname: ', pathname)

            const url = require("url");
            var url_parts = url.parse(req.url);
            console.log(url_parts);
            console.log(url_parts.pathname);

            // returns an array with paths
            let path_array = req.url.match('^[^?]*')[0].split('/').slice(1);
            console.log(path_array)

            console.log(req.url.match('^[^?]*')[0])

            if (!path_array?.length) return 'Please use an API verb';  
            const actions = [ 
               { name: 'offerings', verb: 'service_offerings', dest:  'saas-sm', url: '/v1/' },
               { name: 'plans', verb: 'service_plans', dest:  'saas-sm', url: '/v1/'  },
               { name: 'instances', verb: 'service_instances', dest:  'saas-sm', url: '/v1/'  },
               { name: 'bindings', verb: 'service_bindings', dest:  'saas-sm', url: '/v1/'  },
               { name: 'instanceDestinations', verb: 'instanceDestinations', dest:  'faas-dest-x509', url: '/destination-configuration/v1/'  },
               { name: 'subaccountDestinations', verb: 'subaccountDestinations', dest:  'faas-dest-x509' , url: '/destination-configuration/v1/' }
            ];
            
            const action = actions.find( ({ name }) => name === path_array[1] )
            console.log('action found: ', action)

            if (path_array[0] == 'srv' &&  action !== undefined) {

              path_array = req.url.match('^[^?]*')[0].split('/').slice(2);

              console.log('path_array: ', path_array)

              const queryString = req.query;
              console.log('queryString: ', queryString)
              const urlParams = new URLSearchParams(queryString);

              const params = req.params;
              console.log('params: ', params) 

              try {
                  // https://sap.github.io/cloud-sdk/docs/js/features/connectivity/destinations#service-binding-environment-variables
                  const endpoint =  path_array[1] !== undefined ? '/' + path_array[1] : '';
                  console.log(endpoint)
                  let res = await httpClient.executeHttpRequest({ destinationName: action.dest }, {
                      method: 'GET',
                      url: action.url + action.verb + endpoint
                  });
                  return res.data;
              } catch (err) {
                  console.log(err.stack);
                  return err.message;
              }
              
            }            
          }
        }
   scaleConfig:
    maxReplicas: 5
    minReplicas: 3
  resourceConfiguration:
    function:
      profile: S
  env: ## https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-configuration-parameters/svls-02-environment-variables/#node-js-runtime-specific-environment-variables
    - name: FUNC_TIMEOUT ## Specifies the number of seconds in which a runtime must execute the code.
      value: '1800'
    - name: REQ_MB_LIMIT ## payload body size limit in megabytes.
      value: "10"

    - name: DEBUG
      value: '{{ .Values.services.srv.name }}:*'
    - name: SERVICE_BINDING_ROOT
      value: /bindings
    

  secretMounts: 
    - secretName: {{ .Values.services.sm.bindingSecretName }}
      mountPath: "/bindings/saas-sm"
    - secretName: {{ .Values.services.dest.bindingSecretNamex509 }}
      mountPath: "/bindings/faas-dest-x509"

Technical User Propagation from JCo towards On-Premises

2024-05-22T15:06:16.024000+02:00

This blog lays out how to use a technical user instead of basic authentication from JCo based on the SAP Java Buildpack in CF towards on-premises.

Background

JCo retrieves an access token representing the technical user which is then be sent to the Connectivity service. This is similar to principal propagation, but in this case, a technical user is propagated instead of a business user. The retrieval of the access token performs the OAuth 2.0 client credentials flow, according to the token service configurations in the destination. Currently for JCo the token service generation supports basic authentication only. The token service is called from the Internet, not from the Cloud Connector.

Configuration

Generally speaking, the setup as described in the documentation stays the same, only the destination configuration in the Destination Service needs to be adjusted.

In the UI select the authentication type TechnicalUserPropagation. You now need to enter three values for:

jco.client.tech_user_id - the technical user name (client ID) which is forwarded towards on-premises and used for token retrieval
jco.client.tech_user_secret - the secret for jco.client.tech_user_id used for token retrieval
jco.client.tech_user_service_url - the URL of the token service, against which the token exchange is performed

Example

We are going to use the token of the XSUAA service instance here. We specified for the instance in the configuration JSON the xsappname as jco-technicalProp.

After the application binding we can retrieve the relevant parameters from the CF environment variables VCAP_SERVICES:

"clientid": "sb-jco-technicalProp!t77058"
"clientsecret": "TMsePptYQLSRf6qUWWt+l1D0rUQ="
"url": "https://cf.authentication.hana.ondemand.com"

Entering it in the Destination Service:

The token will now be forwarded to the Cloud Connector. Assuming all necessary basic steps for principal propagation are configured, we can configure a pattern to extract its name for the short-lived certificate:

The ABAP backend needs to maintain a user mapping for this technical user, in this case mapping it to the ABAP user SKYWALKER:

That's it!

Announcing the New "In-Metro" Disaster Recovery Solution for SAP BTP

2024-10-18T17:27:59.877000+02:00

Overview

We’re excited to unveil the latest enhancement to SAP Business Technology Platform (SAP BTP):
The In-Metro Disaster Recovery (DR) solution.

This solution is designed to protect you against disasters affecting a single Availability Zone (AZ) with contractually committed SLAs RPO and RTO, offering enhanced resilience and uninterrupted operations for your cloud services.

What is "In-Metro" DR for SAP BTP?

The In-Metro DR solution is built to protect against local disasters by leveraging a Multi-AZ setup. It ensures that, in the event of a single AZ disaster, which is defined by SAP, services remain operational, data is protected, and business continues without significant downtime.

The key metrics are:

RPO (Recovery Point Objective): 5 minutes – Ensuring that data can be recovered with a maximum of 5 minutes' loss in case of a disaster.
RTO (Recovery Time Objective): 2 hours – Ensuring that the full system is restored and operational within 2 hours of an incident.

The Power of Multi-AZ Architecture

At the heart of In-Metro DR is the Multi-AZ (Multi Availability Zone) architecture, ensuring that your applications and databases are spread across different zones to safeguard against single-point failures.

This includes:

Active-active applications across 3 AZs: Applications are distributed across three AZs, with real-time data replication ensuring that if one AZ fails, the others automatically take over without impacting availability.
Active-passive databases across 2 AZs: Databases are set up in active-passive mode, with a failover mechanism in place to switch operations to a backup AZ if the primary one fails.

Through automatic failover, load balancing, and failure detection, the solution ensures that services stay online seamlessly. Internal stress tests, such as regular “Chaos Day” exercises, further reinforce the reliability of this DR solution.

Availability and Scope

As of now, the In-Metro DR solution is not available for all SAP BTP services. While it already covers a wide range of services, its scope will continue to expand over time as we improve coverage and extend it to additional SAP BTP services. The services in scope will be regularly updated in the corresponding documents.

In-Metro DR is specifically designed for SAP-managed scenarios, meaning that customers using SAP BTP under SAP’s management can take advantage of the In-Metro DR setup without additional configuration or costs. However, for customer-managed scenarios, such as side-by-side extensions, the customer is responsible for configuring it accordingly (e.g. deploy the apps with multiple instances or configure data replicas on the persistency level).

DR Planning and Regular Testing

To ensure the highest levels of reliability:

The DR plan is updated every 12 months, ensuring that it incorporates the latest technology and best practices.
A DR test is conducted at least once a year to verify that the solution can meet its RPO and RTO commitments under real-world conditions.

The In-Metro DR solution currently supports SAP BTP regions hosted on both AWS and Azure cloud infrastructures, providing flexibility for your organization’s cloud setup.

Next Steps

By leveraging In-Metro DR within SAP-managed scenarios, you can trust that your critical data and services are protected with cutting-edge resilience, without the need for extra investment. For customer-managed scenarios, setting up corresponding HA and DR solutions will ensure your setup is equally resilient.

To explore which services are already covered and get all information, check the description in SAP Trust Center.

Alternatively, you can re-watch this deep dive: Watch the Webinar about SAP BTP High Availability and Disaster Recovery.

SAP Cloud Foundry - Python and Cloud Connector - HTTP

2024-12-17T16:17:56.738000+01:00

SAP Cloud Foundry enables developers to create full-stack applications with seamless backend integration to on-premise systems. This blog explains how to use Python to connect to on-premise resources through the SAP Cloud Connector. Python is the preferred language in the AI ecosystem, making it increasingly important for developing intelligent agents. For instance, we may want our agent to access APIs in an S4HANA system. With the Cloud Connector, this can be done securely within the enterprise environment.

Access HTTP-based resources:

In this scenario, we want to connect to an HTTP-based API, such as a RESTful API or an OData service, using Python in SAP Cloud Foundry. To do this, we need to set up the SAP Cloud Connector.

For this demonstration, we will use a simple "Hello World" server running locally on my computer. The goal is to access this local server from the SAP Cloud Foundry runtime through the Cloud Connector. This setup will show how to bridge cloud applications with on-premise resources.

Szenario Architecture

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.

Second requirement is a BTP subaccount with a Cloud Foundry Environment. 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".

Localhost Example Server

To create the configuration, navigate to the admin interface for the cloud connector and create a "Cloud to On-Premise" configuration.

Cloud To On-Premise Configuration

In the screenshot above, you can see that I exposed the internal host "localhost" with port 3333 via a virtual host called "virtualhost". This virtual host is the host that we will be requesting from the BTP side. For the time being, I exposed all paths using an unrestricted access policy, but in production scenarios, access policies can be defined more granularly.

BTP Registered Cloud Connectors

On the BTP end, we can check the cockpit and the connected cloud connectors in the respective menu tab. If you cannot see this tab, you may be missing some roles. It is important to note that we see the LocationID "FELIXLAPTOP", which is an identifier that distinguishes multiple cloud connectors connected to the same subaccount.

2. Create Connectivity Service instance:

To use the Cloud Connector from our runtime environment, we first need a connectivity service instance. Here’s how to do it:

In the BTP Cockpit, go to your desired Subaccount and create a new service instance, as shown below.

We use the "Connectivity Service" with the plan "lite". Give the service instance a name, assign it to a space, and click create.

The important credentials are stored in a service key. To get these credentials, we create a service key.

{
    "clientid": "sb-sampleclientid!b3008|connectivity!b137",
    "clientsecret": "****-****-****-****",
    "url": "https://tenant_name.authentication.sap.hana.ondemand.com",
    "identityzone": "sample-zone",
    "tenantid": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantmode": "dedicated",
    "verificationkey": "-----BEGIN PUBLIC KEY-----\nXXXXXX...\n-----END PUBLIC KEY-----",
    "xsappname": "sampleappname!b3008|connectivity!b137",
    "uaadomain": "authentication.sap.hana.ondemand.com",
    "credential-type": "binding-secret",
    "onpremise_proxy_host": "connectivityproxy.internal.cf.sap.hana.ondemand.com",
    "onpremise_proxy_http_port": "20003",
    "onpremise_proxy_ldap_port": "20001",
    "onpremise_proxy_port": "20003",
    "onpremise_proxy_rfc_port": "20001",
    "onpremise_socks5_proxy_port": "20004",
    "token_service_domain": "authentication.sap.hana.ondemand.com",
    "token_service_url": "https://tenant_name.authentication.sap.hana.ondemand.com"
}

We now have a set of credentials, as shown above. The key details are:

OAuth Credentials: These include the "clientid", "clientsecret", and "url". They are used to authenticate when accessing the proxy.
Proxy Details: These include the "onpremise_proxy_host" and the various ports, such as "onpremise_proxy_port", "onpremise_proxy_http_port", and "onpremise_socks5_proxy_port". These details are configured as the proxy to route traffic. The proxy securely tunnels requests through the Cloud Connector to the on-premise destination.

3. Developing a Cloud Foundry App:

Now let’s put this together in a simple Python example to perform an actual HTTP request:

The Python script will send a request using Python's standard requests library. We use the connection details provided by the Connectivity Service. To route the traffic through the Cloud Connector, we specify the proxy configuration, including the host, port, and the proxy-authentication header.

import requests

# Connectivity Service Service Key
connectivity_service_key = {
    "clientid": "sb-sampleclientid!b3008|connectivity!b137",
    "clientsecret": "****-****-****-****",
    "url": "https://tenant_name.authentication.sap.hana.ondemand.com",
    "identityzone": "sample-zone",
    "tenantid": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantmode": "dedicated",
    "verificationkey": "-----BEGIN PUBLIC KEY-----\nXXXXXX...\n-----END PUBLIC KEY-----",
    "xsappname": "sampleappname!b3008|connectivity!b137",
    "uaadomain": "authentication.sap.hana.ondemand.com",
    "credential-type": "binding-secret",
    "onpremise_proxy_host": "connectivityproxy.internal.cf.sap.hana.ondemand.com",
    "onpremise_proxy_http_port": "20003",
    "onpremise_proxy_ldap_port": "20001",
    "onpremise_proxy_port": "20003",
    "onpremise_proxy_rfc_port": "20001",
    "onpremise_socks5_proxy_port": "20004",
    "token_service_domain": "authentication.sap.hana.ondemand.com",
    "token_service_url": "https://tenant_name.authentication.sap.hana.ondemand.com"
}


# Target Application Details (replace with your app information)
application_host = "virtualhost"
application_port = 3333
application_path = "/hello"
location_id = "FELIXLAPTOP"  # Adjust to match your Cloud Connector location

def get_connectivity_service_token(client_id, client_secret, token_service_url):
    """
    Fetches an OAuth token from the SAP Connectivity Service.
    """
    response = requests.post(
        url=token_service_url,
        params={"grant_type": "client_credentials"},
        auth=(client_id, client_secret)
    )

    if response.status_code != 200:
        print(f"Error: {response.status_code} - {response.text}")
        exit(-1)

    return response.json().get("access_token")


def example_http_request(host, port, path, auth_token, location_id, proxy_host):
    """
    Performs an HTTP GET request through SAP Cloud Connector.
    """
    url = f"http://{host}:{port}{path}"
    headers = {
        "Proxy-Authorization": f"Bearer {auth_token}",
        "SAP-Connectivity-SCC-Location_ID": location_id
    }
    proxies = {"http": proxy_host}

    response = requests.get(url, headers=headers, proxies=proxies, verify=False)
    return response


# Fetch OAuth Token
print("Fetching OAuth token...")
token = get_connectivity_service_token(
    connectivity_service_key["clientid"],
    connectivity_service_key["clientsecret"],
    connectivity_service_key["token_service_url"] + "/oauth/token"
)
print("Token acquired successfully.")

# Build proxy URL
proxy_host = "http://" + connectivity_service_key["onpremise_proxy_host"] + ":" + connectivity_service_key["onpremise_proxy_port"]

# Perform HTTP Request
print("Sending HTTP request through SAP Cloud Connector...")
response = example_http_request(application_host, application_port, application_path, token, location_id, proxy_host)
print("Response received:")
print(response.content.decode("utf-8"))
print("Script execution completed.")

First, we obtain a token from the OAuth 2.0 Token Service URL. This is done using the get_connectivity_service_token function, where we send the necessary credentials.

Note: Make sure to add /oauth/token at the end of the Token Service URL.

The response will return a Bearer Token, which we need to perform the actual HTTP request.

In the example_http_request function, we use Python's requests library to send the request. The proxies option allows us to route the traffic through the Cloud Connector's HTTP proxy. For this, we:

Combine the proxy_host (connectivity service proxy host) and port (e.g., HTTP port).
For other traffic types, such as TCP-based traffic, we would use the SOCKS5 port.

We also include important headers:

Proxy-Authorization: This includes the Bearer Token ("Bearer <token>").
SAP-Connectivity-Location-ID: This optional header specifies the location ID of the connected Cloud Connector. For example, if my Cloud Connector is connected under "FELIXLAPTOP", I include this value.

The actual destination URL points to the virtual host and virtual port configured in the Cloud Connector. For this example:

virtualhost:3333 communicates with my local server.
The path /hello returns a sample message.

Finally, we combine all steps into a simple sequential script to demonstrate the entire flow.

To make it deployable on Cloud Foundry, we add a standard manifest.yaml file.

---
applications:
- name: cloud_connector_test_task
  memory: 128MB
  buildpack: python_buildpack
  command: python app.py

It sets the buildpack to python_buildpack.

Additionally, we include a requirements.txt file in the directory.

requests

Ending up with the following structure:

my-python-cloud-connector-app/
│
├── manifest.yaml
├── requirements.txt
├── app.py (or your main Python script)

Note: The script we created obviously does not run on our local environment. Because a) we cannot connect to the connectivity service from outside of the BTP and b) the destination URL is not reachable from our local environment. In this blog, I show how to use a hybrid testing setup to develop against backend resources that are behind the cloud connector.

4. Testing the Application:

Now lets deploy using the following command:

cf push cloud_connector_test_task --task

You push your script as a task (one-time executable) to the Cloud Foundry space. Then, you start the task using the following command:

cf run-task cloud_connector_test_task --command "python app.py" --name example_task
cf logs cloud_connector_test_task --recent

This will show the logs from the latest task execution. It may take a few seconds for the task to start and complete.

In the logs, if everything worked correctly, you should see the "Hello World" message from your on-premises PC, confirming that the connection through the Cloud Connector was successful.

2024-12-17T15:25:11.52+0100 [APP/TASK/example_task/0] OUT Fetching OAuth token...
2024-12-17T15:25:11.69+0100 [APP/TASK/example_task/0] OUT Token acquired successfully.
2024-12-17T15:25:11.69+0100 [APP/TASK/example_task/0] OUT Sending HTTP request through SAP Cloud Connector...
2024-12-17T15:25:13.66+0100 [APP/TASK/example_task/0] OUT Response received:
2024-12-17T15:25:13.66+0100 [APP/TASK/example_task/0] OUT {"message":"Hello World 2024-12-17T14:25:13.444Z"}
2024-12-17T15:25:13.66+0100 [APP/TASK/example_task/0] OUT Script execution completed.

That means we have successfully established connectivity via the cloud connector and made a HTTP request.

In the next blog I will show how to create a TCP socket in Python to connect to TCP resources.

Hope you find the content of this blog helpful. Feel free to comment for further clarifications.

Hybrid Local Development with SAP Cloud Foundry: Access On-Premises APIs via the Cloud Connector

2024-12-18T22:15:21.226000+01:00

When building full-stack applications on SAP BTP, debugging against on-premise backends is a common requirement. This post outlines a simple method to simulate the connectivity available in the BTP Cloud Foundry runtime on your local machine, enabling access to on-premise APIs through the BTP Subaccount and Cloud Connector.

Scenario:

Imagine you're developing an AI Agent and need to create tools that interact with an on-premise API. In line with SAP best practices, this API is exposed to your Subaccount via the Cloud Connector. While deployed applications can access the API directly, how do you test this setup locally?

The solution is to use the Cloud Foundry CLI tooling to establish a tunnel to the Cloud Foundry environment, routing traffic through it. This allows local development and debugging as though you're working directly within the BTP runtime.

Concept: SAP Cloud Connector:

The SAP Cloud Connector (SCC) acts as a secure bridge between on-premise systems and cloud applications. It allows cloud applications, such as those running on SAP BTP (Business Technology Platform), to access resources in on-premise environments securely. The connector ensures data transfer via encrypted communication, maintaining the integrity and confidentiality of sensitive information. It supports fine-grained access control, enabling administrators to define which systems, services, or data can be exposed to the cloud. Additionally, SCC simplifies integration by avoiding the need for complex network configurations like VPNs. This makes it a critical tool for hybrid cloud setups, enabling seamless and secure connectivity.

Example Setup:

For this example, I configured a Cloud Connector on a machine and exposed an HTTP-based sample server. You can refer to this detailed blog post here to see the process outlined in Step 1.

The setup results in the virtualhost:3333 being securely exposed to my BTP Subaccount.

Taking the script from that blog as an example, I make an HTTP request to the exposed virtualhost:3333:

def example_http_request(host, port, path, auth_token, location_id, proxy_host):
    """
    Performs an HTTP GET request through SAP Cloud Connector.
    """
    url = f"http://{host}:{port}{path}"
    headers = {
        "Proxy-Authorization": f"Bearer {auth_token}",
        "SAP-Connectivity-SCC-Location_ID": location_id
    }
    proxies = {"http": proxy_host}    response = requests.get(url, headers=headers, proxies=proxies, verify=False)
    return response

Doing the request on BTP, we receive the expected "Hello World" response. Running the same request on my local machine, however, would result in a connection error, as the on-premise API is not directly accessible from the local environment.

An error occurred: HTTPConnectionPool(host='connectivityproxy.internal.cf.sap.hana.ondemand.com', port=20003): Max retries exceeded with url: http://virtualhost:3333/hello (Caused by ProxyError('Unable to connect to proxy', ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x00000191F0BFF6B0>, 'Connection to connectivityproxy.internal.cf.sap.hana.ondemand.com timed out. (connect timeout=None)')))

Note: No surprise there, as the connectivity proxy is an internal host: connectivityproxy.internal.cf.sap.hana.ondemand.com.

Setting Up a Tunnel to a Sample Application

There’s a light at the end of the tunnel: the Cloud Foundry Command Line Interface offers the ability to create an SSH tunnel for deployed apps, as described in the documentation here. This feature can be useful in various scenarios. One example is accessing a database deployed within the environment, which is not exposed to the outside world—only your internal apps can access its ports. Another example is our case: developing locally against an on-premise backend.

However, this can only be done in relation to an app. You can either use your own existing app or a sample dummy app. In this case, I’ll use a sample app, which I’ve named myapp, based on the code available here.

After quickly running cf push, the deployment is successfully completed.

Waiting for app myapp to start...Instances starting...
Instances starting...
Instances starting...
Instances starting...name:              myapp
requested state:   started
routes:            myapp-brash-warthog-cj.cfapps.sap.hana.ondemand.com
last uploaded:     Wed 18 Dec 21:43:35 CET 2024
stack:             cflinuxfs4
buildpacks:
        name               version   detect output   buildpack name
        python_buildpack   1.8.30    python          pythontype:            web
sidecars:
instances:       1/1
memory usage:    128M
start command:   python hello.py
     state     since                  cpu    memory   disk     details
#0   running   2024-12-18T20:43:49Z   0.0%   0 of 0   0 of 0

Having deployed the app we can then establish the SSH tunnel using the following command:

cf ssh -L 8888:connectivityproxy.internal.cf.sap.hana.ondemand.com:20003 myapp

Lets break this down:

cf: Refers to the Cloud Foundry CLI.
ssh: Invokes the SSH feature of the Cloud Foundry CLI.
-L 8888:connectivityproxy.internal.cf.sap.hana.ondemand.com:20003:
This specifies the SSH tunnel with the following parts:
- 8888: The local port on your machine where the tunnel will be accessible.
- connectivityproxy.internal.cf.sap.hana.ondemand.com: The target host inside the Cloud Foundry environment.
- 20003: The target port on the remote host within the Cloud Foundry environment.
myapp: The name of the application you want to connect to via SSH.

Essentially that leaves us with a tunnel that is reachable from localhost:8888 - forwarding our traffic to the internal connectivity proxy host at its http proxy port 20003.

Running the ssh tunnel command now gives us access to the runtime environment of the app:

PS C:\Github\sap-cloud-foundry-python-cloud-connector> cf ssh -L 8888:connectivityproxy.internal.cf.sap.hana.ondemand.com:20003 myapp
vcap@3e707408-4eca-41f4-7dee-d848:~$ ls
app  deps  logs  profile.d  staging_info.yml  tmp
vcap@3e707408-4eca-41f4-7dee-d848:~$
vcap@3e707408-4eca-41f4-7dee-d848:~$

Running the Local Script via the Tunnel

While the SSH session is active, the tunnel remains open. However, there’s a small adjustment we need to make: instead of using connectivityproxy.internal... as our proxy host URL, we must reference localhost:8888. This requires updating the corresponding value in the secret. Once that’s done, we can run the script seamlessly—whether through a debugger or by executing it with the Python interpreter in a separate command-line process. It should now work as expected.

PS C:\Github\sap-cloud-foundry-python-cloud-connector> python app.py
Fetching OAuth token...
Token acquired successfully.
Sending HTTP request through SAP Cloud Connector...
Response received:
{"message":"Hello World 2024-12-18T20:46:49.181Z"}
Script execution completed.

Great! We've seen how to connect to on-premise systems from our local environment using the cf ssh tunneling options to route traffic through the Cloud Connector.

This approach works for both HTTP and TCP traffic. Feel free to check out my other blog on how to proxy TCP traffic using Python.

SAP Cloud Foundry - Python and Cloud Connector - TCP

2024-12-19T09:35:58.651000+01:00

The Transmission Control Protocol (TCP) is a widely used protocol that provides a reliable and ordered delivery of data between applications running on different hosts. It serves as the foundation for many technologies and plays a crucial role in modern IT infrastructure.

SAP Cloud Foundry is the Platform-as-a-service offering on BTP to build all kinds of Apps, Integration and nowadays also AI functionalities.

In this blog post, we will walk you through the process of establishing connectivity to an on-premises TCP-based system using Python within the Cloud Foundry runtime.

Accessing TCP-Based Resources

Scenario: The objective is to establish a connection to a TCP-based system using Python within SAP Cloud Foundry. Many commonly used systems, such as databases like SAP HANA, PostgreSQL, and MySQL, as well as protocols like SSH and SFTP, rely on TCP for communication.

To achieve this, we will configure the Cloud Connector, a crucial tool for enabling secure communication between SAP Cloud Foundry and on-premises systems. For demonstration purposes, we will use a simple "Hello TCP" server running locally on my computer. The goal is to successfully connect to this server from within SAP Cloud Foundry using the 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.

The second requirement is a BTP subaccount with a Data Intelligence cluster. To this Subaccount we will connect the Cloud Connector.

1. Configuration:

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

telnet localhost 4444

Connecting to localhost ...

Hello TCP!

To create the configuration, navigate to the admin interface for the cloud connector and create a "Cloud to On-Premise" configuration.

Cloud Connector configuration

In the screenshot above, you can see that I exposed the internal host "localhost" with port 4444 via a virtual host called "virtualhost". This virtual host is the host that we will be requesting from the BTP side. Compared to HTTP resources, we do not need to explicitly expose paths.

BTP Cockpit Cloud Connector Resources

2. Create Connectivity Service instance:

To use the Cloud Connector from our runtime environment, we first need a connectivity service instance. Here’s how to do it:

In the BTP Cockpit, go to your desired Subaccount and create a new service instance, as shown below.

We use the "Connectivity Service" with the plan "lite". Give the service instance a name, assign it to a space, and click create.

The important credentials are stored in a service key. To get these credentials, we create a service key.

{
    "clientid": "sb-sampleclientid!b3008|connectivity!b137",
    "clientsecret": "****-****-****-****",
    "url": "https://tenant_name.authentication.sap.hana.ondemand.com",
    "identityzone": "sample-zone",
    "tenantid": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantmode": "dedicated",
    "verificationkey": "-----BEGIN PUBLIC KEY-----\nXXXXXX...\n-----END PUBLIC KEY-----",
    "xsappname": "sampleappname!b3008|connectivity!b137",
    "uaadomain": "authentication.sap.hana.ondemand.com",
    "credential-type": "binding-secret",
    "onpremise_proxy_host": "connectivityproxy.internal.cf.sap.hana.ondemand.com",
    "onpremise_proxy_http_port": "20003",
    "onpremise_proxy_ldap_port": "20001",
    "onpremise_proxy_port": "20003",
    "onpremise_proxy_rfc_port": "20001",
    "onpremise_socks5_proxy_port": "20004",
    "token_service_domain": "authentication.sap.hana.ondemand.com",
    "token_service_url": "https://tenant_name.authentication.sap.hana.ondemand.com"
}

We now have a set of credentials, as shown above. The key details are:

OAuth Credentials: These include the "clientid", "clientsecret", and "url". They are used to authenticate when accessing the proxy.
Proxy Details: These include the "onpremise_proxy_host" and the various ports, such as "onpremise_proxy_port", "onpremise_proxy_http_port", and "onpremise_socks5_proxy_port". These details are configured as the proxy to route traffic. The proxy securely tunnels requests through the Cloud Connector to the on-premise destination.

3. Developing a Cloud Foundry App:

Now let’s put this together in a simple Python example to perform an actual TCP request:

The Python script will send a request using Python's standard socket library. We use the connection details provided by the Connectivity Service Service Key. To route the traffic through the Cloud Connector, we specify the proxy configuration, including the host, port, and the proxy-authentication header.

To realize the connection to the Connectivity Proxy, we will be using the sapcloudconnectorpythonsocket library I created for this purpose. This is a seperate dependency and needs to be included into the requirements file. The reason we cannot use standard library's like PySocks to connect to the connectivity service, is the custom authentication flow used.

The actual script looks straightforward:

import requests
from sapcloudconnectorpythonsocket import CloudConnectorSocket

# Connectivity Service Service Key
connectivity_service_key = {
    "clientid": "sb-sampleclientid!b3008|connectivity!b137",
    "clientsecret": "****-****-****-****",
    "url": "https://tenant_name.authentication.sap.hana.ondemand.com",
    "identityzone": "sample-zone",
    "tenantid": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantmode": "dedicated",
    "verificationkey": "-----BEGIN PUBLIC KEY-----\nXXXXXX...\n-----END PUBLIC KEY-----",
    "xsappname": "sampleappname!b3008|connectivity!b137",
    "uaadomain": "authentication.sap.hana.ondemand.com",
    "credential-type": "binding-secret",
    "onpremise_proxy_host": "connectivityproxy.internal.cf.sap.hana.ondemand.com",
    "onpremise_proxy_http_port": "20003",
    "onpremise_proxy_ldap_port": "20001",
    "onpremise_proxy_port": "20003",
    "onpremise_proxy_rfc_port": "20001",
    "onpremise_socks5_proxy_port": "20004",
    "token_service_domain": "authentication.sap.hana.ondemand.com",
    "token_service_url": "https://tenant_name.authentication.sap.hana.ondemand.com"
}


# Target Application Details (replace with your app information)
application_host = "virtualhost"
application_port = 4444
location_id = "FELIXLAPTOP"  # Adjust to match your Cloud Connector location

def get_connectivity_service_token(client_id, client_secret, token_service_url):
    """
    Fetches an OAuth token from the SAP Connectivity Service.
    """
    response = requests.post(
        url=token_service_url,
        params={"grant_type": "client_credentials"},
        auth=(client_id, client_secret)
    )

    if response.status_code != 200:
        print(f"Error: {response.status_code} - {response.text}")
        exit(-1)

    return response.json().get("access_token")


def example_tcp_request(host, port, auth_token, location_id, proxy_host, proxy_port):
    """
    Performs an TCP request through SAP Cloud Connector.
    """
    cc_socket = CloudConnectorSocket()
    cc_socket.connect(
        dest_host=host, 
        dest_port=port, 
        proxy_host=proxy_host, 
        proxy_port=proxy_port, 
        token=auth_token,
        location_id=location_id
    )
    
    cc_socket.send(b"")
    
    response = cc_socket.recv(4096)
    return response
    

# Fetch OAuth Token
print("Fetching OAuth token...")
token = get_connectivity_service_token(
    connectivity_service_key["clientid"],
    connectivity_service_key["clientsecret"],
    connectivity_service_key["token_service_url"] + "/oauth/token"
)
print("Token acquired successfully.")

# Perform TCP Request
print("Sending TCP request through SAP Cloud Connector...")
response = example_tcp_request(application_host, application_port, token, location_id, connectivity_service_key["onpremise_proxy_host"], int(connectivity_service_key["onpremise_socks5_proxy_port"]))
print("Response received:")
print(response)

print("Script execution completed.")

Let’s break down the steps performed in the script:

Authentication
The script begins by authenticating with the OAuth endpoint using the details from the service key in
get_connectivity_service_token. This step retrieves a Bearer Token, which is required to access the Connectivity Proxy.
Establishing the Connection
Next, the example_tcp_request function is called to send a sample request. This function establishes a connection to the target system via the SAP Cloud Connector. Under the hood, this involves multiple TCP request exchanges, during which the authentication token and location ID are passed. This process results in an open connection through the secure tunnel created by the Cloud Connector.
Using the SOCKS5 Proxy Port
A key detail to note is that the script uses the SOCKS5 proxy port instead of the standard HTTP proxy port of the Connectivity Service. Looking at the service key of a Connectivity Service instance provides clarity:
- HTTP Proxy Port: 20003
- SOCKS5/TCP Proxy Port: 20004
The SOCKS5 port (20004) is explicitly specified when opening the socket, as it is required for TCP communication in this context.
Sending and Receiving Data
With the socket successfully opened, the script sends a request to the TCP server. In this example, an empty request body is sent, and the local server should respond with "Hello TCP!" for every request.

To make it deployable on Cloud Foundry, we add a standard manifest.yaml file.

---
applications:
- name: cloud_connector_test_task
  memory: 128MB
  buildpack: python_buildpack
  command: python app.py

It sets the buildpack to python_buildpack.

Additionally, we include a requirements.txt file in the directory.

requests
sapcloudconnectorpythonsocket

Ending up with the following structure:

my-python-cloud-connector-app/
│
├── manifest.yaml
├── requirements.txt
├── app.py (or your main Python script)

4. Testing the Application:

Now lets deploy using the following command:

cf push cloud_connector_test_task --task

You push your script as a task (one-time executable) to the Cloud Foundry space. Then, you start the task using the following command:

cf run-task cloud_connector_test_task --command "python app.py" --name example_task
cf logs cloud_connector_test_task --recent

This will show the logs from the latest task execution. It may take a few seconds for the task to start and complete.

In the logs, if everything worked correctly, you should see the "Hello TCP!" message from your on-premises machine, confirming that the connection through the Cloud Connector was successful.

2024-12-18T23:30:15.23+0100 [APP/TASK/example_task/0] OUT Fetching OAuth token...
2024-12-18T23:30:15.38+0100 [APP/TASK/example_task/0] OUT Token acquired successfully.
2024-12-18T23:30:15.38+0100 [APP/TASK/example_task/0] OUT Sending TCP request through SAP Cloud Connector...
2024-12-18T23:30:15.53+0100 [APP/TASK/example_task/0] OUT Response received:
2024-12-18T23:30:15.53+0100 [APP/TASK/example_task/0] OUT b'Hello TCP!'
2024-12-18T23:30:15.53+0100 [APP/TASK/example_task/0] OUT Script execution completed.

That means we were successful and the script was able to request the local TCP server on my windows machine. Checkout my similar blogpost targeting a example based on HTTP.

Hope you find the content of this blog helpful. Feel free to comment for further clarifications.

Consuming external services(Odata/Rest) using destinations configured in BTP cockpit.

2025-01-14T16:22:49.327000+01:00

Hello All,

In this blog post, I will be demonstrating on how to call external services using destinations configured in Destinations in BTP cockpit.

Before we start with demonstration, I would like to provide a brief information about the type of application development that we will be following in this demo.
- We will be creating a MTA application
- We will use managed approuter, In order to use this, we have to enable/configure the SAP Build Workzone subscription in trial account.
- We will deploy the application on cloud foundry.
- We will be consuming below mentioned external services:
-- https://services.odata.org/V3/Northwind/Northwind.svc/Customers?$format=json
-- https://api.restful-api.dev/objects/4

Step 1: Creating Destination in BTP subaccount.
Destinations has to be created at each subaccount level. Since, we are using Trial account for this demo, our cockpit will have only one subaccount.
We have created 2 destinations as mentioned below:
1. Northwind destination
2. Restful API destination
To create destination, follow the path Trial home -> Account Explorer (Global account) -> trial subaccount -> Connectivity -> Destinations
Below are the screenshot of the Destinations created.

Step 2: Create new project from template

We are going to create a Basic multitarget application. Configure the settings as shown below.

A new mta project will be generated (Workspace will be automatically created) with below structure.

Note that the mta.yaml file will be initially empty as shown below.

schema-version: "3.2"
ID: demomta
version: 0.0.1

Step 3: Adding approuter to the mta project.

Use managed app router, which is maintained by SAP. For using managed approuter, you need to subscribe to portal/launchpad service. We have subscribed to workzone service in cockpit.

Right click on mta.yaml file and select 'Create MTA Module from Template'.
Follow the steps shown in below screenshots for approuter creation.

Note: mta.yaml file will be automatically updated as shown below.

_schema-version: "3.2"
ID: demomta
version: 0.0.1
modules:
- name: demomta-destination-content
  type: com.sap.application.content
  requires:
  - name: demomta-destination-service
    parameters:
      content-target: true
  - name: demomta_html_repo_host
    parameters:
      service-key:
        name: demomta_html_repo_host-key
  - name: uaa_demomta
    parameters:
      service-key:
        name: uaa_demomta-key
  parameters:
    content:
      instance:
        destinations:
        - Name: demomtaapprouter_demomta_html_repo_host
          ServiceInstanceName: demomta-html5-app-host-service
          ServiceKeyName: demomta_html_repo_host-key
          sap.cloud.service: demomtaapprouter
        - Authentication: OAuth2UserTokenExchange
          Name: demomtaapprouter_uaa_demomta
          ServiceInstanceName: demomta-xsuaa-service
          ServiceKeyName: uaa_demomta-key
          sap.cloud.service: demomtaapprouter
        existing_destinations_policy: ignore
  build-parameters:
    no-source: true
resources:
- name: demomta-destination-service
  type: org.cloudfoundry.managed-service
  parameters:
    config:
      HTML5Runtime_enabled: true
      init_data:
        instance:
          destinations:
          - Authentication: NoAuthentication
            Name: ui5
            ProxyType: Internet
            Type: HTTP
            URL: https://ui5.sap.com
          existing_destinations_policy: update
      version: 1.0.0
    service: destination
    service-name: demomta-destination-service
    service-plan: lite
- name: demomta_html_repo_host
  type: org.cloudfoundry.managed-service
  parameters:
    service: html5-apps-repo
    service-name: demomta-html5-app-host-service
    service-plan: app-host
- name: uaa_demomta
  type: org.cloudfoundry.managed-service
  parameters:
    path: ./xs-security.json
    service: xsuaa
    service-name: demomta-xsuaa-service
    service-plan: application
parameters:
  deploy_mode: html5-repo
  enable-parallel-deployments: true

Step 4: Create a UI module in the mta project.

Right click on mta.yaml file and select 'Create MTA Module from Template'.
Follow the steps shown in below screenshots for UI module creation.

Note: Project folder path should be the path of the MTA project created earlier and select the option to add deployment configuration to the project.

Note: Mta.yaml file will be updated automatically to include newly added UI module in module section as highlighted below.

_schema-version: "3.2"
ID: demomta
version: 0.0.1
modules:
- name: demomta-destination-content
  type: com.sap.application.content
  requires:
  - name: demomta-destination-service
    parameters:
      content-target: true
  - name: demomta_html_repo_host
    parameters:
      service-key:
        name: demomta_html_repo_host-key
  - name: uaa_demomta
    parameters:
      service-key:
        name: uaa_demomta-key
  parameters:
    content:
      instance:
        destinations:
        - Name: demomtaapprouter_demomta_html_repo_host
          ServiceInstanceName: demomta-html5-app-host-service
          ServiceKeyName: demomta_html_repo_host-key
          sap.cloud.service: demomtaapprouter
        - Authentication: OAuth2UserTokenExchange
          Name: demomtaapprouter_uaa_demomta
          ServiceInstanceName: demomta-xsuaa-service
          ServiceKeyName: uaa_demomta-key
          sap.cloud.service: demomtaapprouter
        existing_destinations_policy: ignore
  build-parameters:
    no-source: true
- name: demomta-app-content
  type: com.sap.application.content
  path: .
  requires:
  - name: demomta_html_repo_host
    parameters:
      content-target: true
  build-parameters:
    build-result: resources
    requires:
    - artifacts:
      - nwui.zip
      name: nwui
      target-path: resources/
- name: nwui
  type: html5
  path: nwui
  build-parameters:
    build-result: dist
    builder: custom
    commands:
    - npm install
    - npm run build:cf
    supported-platforms: []
resources:
- name: demomta-destination-service
  type: org.cloudfoundry.managed-service
  parameters:
    config:
      HTML5Runtime_enabled: true
      init_data:
        instance:
          destinations:
          - Authentication: NoAuthentication
            Name: ui5
            ProxyType: Internet
            Type: HTTP
            URL: https://ui5.sap.com
          existing_destinations_policy: update
      version: 1.0.0
    service: destination
    service-name: demomta-destination-service
    service-plan: lite
- name: demomta_html_repo_host
  type: org.cloudfoundry.managed-service
  parameters:
    service: html5-apps-repo
    service-name: demomta-html5-app-host-service
    service-plan: app-host
- name: uaa_demomta
  type: org.cloudfoundry.managed-service
  parameters:
    path: ./xs-security.json
    service: xsuaa
    service-name: demomta-xsuaa-service
    service-plan: application
parameters:
  deploy_mode: html5-repo
  enable-parallel-deployments: true

Now, the UI module will be created automatically with below structure.

Step 5: Update the xs-app.json

Update the xs-app.json file in the UI module folder to add routes for northwind service.

i.e. URLs which have nwdest in them will be redirected from mentioned destination in cockpit.

{
  "welcomeFile": "/index.html",
  "authenticationMethod": "route",
  "routes": [
    {
      "source": "^/nwdest/(.*)$",
      "target": "/$1",
      "authenticationType": "none",
      "destination": "northwind"
    },
    {
      "source": "^/resources/(.*)$",
      "target": "/resources/$1",
      "authenticationType": "none",
      "destination": "ui5"
    },
    {
      "source": "^/test-resources/(.*)$",
      "target": "/test-resources/$1",
      "authenticationType": "none",
      "destination": "ui5"
    },
    {
      "source": "^(.*)$",
      "target": "$1",
      "service": "html5-apps-repo-rt",
      "authenticationType": "xsuaa"
    }
  ]
}

Step 6: Calling the Northwind Service using AJAX call.

Add the below code in View1 controller init to call the NW service using destination configured in xs-app.json

  var sURL = "nwdest/V3/Northwind/Northwind.svc/Customers?$format=json";
            var data = jQuery.ajax({
                method: "GET",
                async: false,
                url: sURL,
                success: function (data) {
                    console.log("in success");
                }
            });

Step 7: Creation of second UI Module.

Repeat the Steps 4 to 6, to create another UI module which will call service using restful destination.

Below project structure will be created.

Note: Mta.yaml should be automatically updated to include both UI modules

_schema-version: "3.2"
ID: demomta
version: 0.0.1
modules:
- name: demomta-destination-content
  type: com.sap.application.content
  requires:
  - name: demomta-destination-service
    parameters:
      content-target: true
  - name: demomta_html_repo_host
    parameters:
      service-key:
        name: demomta_html_repo_host-key
  - name: uaa_demomta
    parameters:
      service-key:
        name: uaa_demomta-key
  parameters:
    content:
      instance:
        destinations:
        - Name: demomtaapprouter_demomta_html_repo_host
          ServiceInstanceName: demomta-html5-app-host-service
          ServiceKeyName: demomta_html_repo_host-key
          sap.cloud.service: demomtaapprouter
        - Authentication: OAuth2UserTokenExchange
          Name: demomtaapprouter_uaa_demomta
          ServiceInstanceName: demomta-xsuaa-service
          ServiceKeyName: uaa_demomta-key
          sap.cloud.service: demomtaapprouter
        existing_destinations_policy: ignore
  build-parameters:
    no-source: true
- name: demomta-app-content
  type: com.sap.application.content
  path: .
  requires:
  - name: demomta_html_repo_host
    parameters:
      content-target: true
  build-parameters:
    build-result: resources
    requires:
    - artifacts:
      - nwui.zip
      name: nwui
      target-path: resources/
    - artifacts:
      - restfulapiui.zip
      name: restfulapiui
      target-path: resources/
- name: nwui
  type: html5
  path: nwui
  build-parameters:
    build-result: dist
    builder: custom
    commands:
    - npm install
    - npm run build:cf
    supported-platforms: []
- name: restfulapiui
  type: html5
  path: restfulapiui
  build-parameters:
    build-result: dist
    builder: custom
    commands:
    - npm install
    - npm run build:cf
    supported-platforms: []
resources:
- name: demomta-destination-service
  type: org.cloudfoundry.managed-service
  parameters:
    config:
      HTML5Runtime_enabled: true
      init_data:
        instance:
          destinations:
          - Authentication: NoAuthentication
            Name: ui5
            ProxyType: Internet
            Type: HTTP
            URL: https://ui5.sap.com
          existing_destinations_policy: update
      version: 1.0.0
    service: destination
    service-name: demomta-destination-service
    service-plan: lite
- name: demomta_html_repo_host
  type: org.cloudfoundry.managed-service
  parameters:
    service: html5-apps-repo
    service-name: demomta-html5-app-host-service
    service-plan: app-host
- name: uaa_demomta
  type: org.cloudfoundry.managed-service
  parameters:
    path: ./xs-security.json
    service: xsuaa
    service-name: demomta-xsuaa-service
    service-plan: application
parameters:
  deploy_mode: html5-repo
  enable-parallel-deployments: true

xs-app.json in second UI module will look like below.

{
  "welcomeFile": "/index.html",
  "authenticationMethod": "route",
  "routes": [
    {
      "source": "^/restfulapi/(.*)$",
      "target": "/$1",
      "authenticationType": "none",
      "destination": "restful"
    },
    {
      "source": "^/resources/(.*)$",
      "target": "/resources/$1",
      "authenticationType": "none",
      "destination": "ui5"
    },
    {
      "source": "^/test-resources/(.*)$",
      "target": "/test-resources/$1",
      "authenticationType": "none",
      "destination": "ui5"
    },
    {
      "source": "^(.*)$",
      "target": "$1",
      "service": "html5-apps-repo-rt",
      "authenticationType": "xsuaa"
    }
  ]
}

and below code should be added to the View 1 controller of second UI Module.

  var sURL = "restfulapi/objects/4";
            var data = jQuery.ajax({
                method: "GET",
                async: false,
                url: sURL,
                success: function (data) {
                    console.log("in success");
                }
            });

Step 8: Build and deploy the project to cloud foundry

Right click on the mta.yaml file and select 'Build MTA Project' to start the project build.

Once the build is successfully completed, a new folder 'mta_archives' will be added to the MTA project as shown below.

The mta_archives folder will contain a .mtar file which will be used for deployment to cloud foundry.

Right click on the .mtar file and select deploy option.

Note that system may prompt you to enter your Cloud Foundry credentials. Kindly enter the credentials and select correct API Endpoint and Org Space.

Once, application is successfully deployed, You will be able to find those applications in the cockpit under HTML5 Applications tab.

When you click on the link, you should be able to check the service call in network tab as shown below.

With this, we come to the end of this blog post. I hope this blog post proves to be a useful resource in the future.

Communicate from a Java Application to ABAP via WebSocket RFC using JCo - Migration Guide

2025-01-21T19:20:20.825000+01:00

WebSocket RFC is available for a while now. Continue reading, if

you want to communicate from an external Java application to an ABAP-based system via this new protocol using the JCo library.
you have an existing JCo setup using classic CPIC-based RFC and want to migrate.

Adjusting the destination

For specifying the destination, instead of providing properties for application server logon (jco.client.ashost, jco.client.sysnr) or message server logon (jco.client.mshost, jco.client.msserv, jco.client.r3name), the following properties must be provided:

jco.client.wshost: the hostname of the target system
jco.client.wsport: the port for HTTPS/WSS (WebSocket Secure) of the target system

Optionally, you can also specify

jco.client.tls_client_certificate_logon: If set to 1 this property enables to logon at the backend via the X.509 client certificate that is used in the TLS handshake (mTLS). An associated user or mapping rule must be defined at the backend.

Extending the implementation

WebSocket RFC is based on TLS, thus a PKI infrastructure is required to be setup. To achieve that, following methods from the JCo interface DestinationDataProvider must be implemented:

SSLContext getSSLContext(String destinationName)

This method returns a javax.net.ssl.SSLContext instance to JCo, which is used to create the TLS session for a given destination. How such an instance is created is up to the application - we are going to describe a simple use case in which all keys and CAs are stored in a local p12 file (p12FilePath) and the password is read from a secured database.

SSLContext loadSSLContextFromFile() throws KeyStoreException, NoSuchAlgorithmException, CertificateException, IOException, UnrecoverableKeyException, KeyManagementException {
    File p12File = new File(p12FilePath);

    try (InputStream p12FileStream = new BufferedInputStream(new FileInputStream(p12File))) {
        KeyStore ks = KeyStore.getInstance("PKCS12");

        char[] pwd = SecuredDatabaseConnection.readPassword();

        ks.load(p12FileStream, pwd);
        KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
        kmf.init(ks, pwd);

        // delete the plain text password from the heap memory as soon as possible
        Arrays.fill(pwd, (char) 0);
        pwd = null;

        TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tmf.init(ks);

        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
        return sslContext;
    }

(Optionally) If jco.client.tls_client_certificate_logon is used, the API below must be implemented additionally:

X509Certificate getClientCertificate(String destinationName)

This method must return the java.security.cert.X509Certificate instance of the client certificate used for logon. It must be the one provided in the SSLContext, which is used during the TLS handshake.

Setting up Trust

Creating the p12 File

Create a p12 file with a private key using a tool like keytool or OpenSSL. Create a CSR and import the CA response. Furthermore, import the CA certificate from the ABAP system which has been exported (see next section).

Configuring trust in ABAP

Navigate to transaction STRUST and select "SSL-Server Standard". Select the own certificate and export it. For more information, see also here. Also, import the CA certificate from the p12 file and add it to the certificate list, so that mutual trust can be established.

Using WebSocket RFC in BTP

If you use JCo in BTP in conjunction with the Destination Service and you want to use WebSocket RFC to call publicly exposed endpoints, you can skip the above "Extending the implementation" part. This integration is already implemented by SAP in the supported environments. You can follow the steps in the BTP Connectivity Service documentation on how to configure the Destination Service accordingly.

New Destinations UI available now in BETA version

2025-02-03T08:53:17.016000+01:00

A new Destinations UI for managing destination configuration objects is now available as a BETA version in the SAP BTP cockpit, side-by-side with the current UI. It is not yet at feature parity with the current UI, but feel free to try it out and send us your feedback.

Old Destination UI

Getting Started with the New Destinations UI

To start using the new Destinations UI, follow these steps:

Access the SAP BTP Cockpit: Log in to your SAP BTP account and navigate to the cockpit.
Navigate to Destinations: In the cockpit, go to the Connectivity section and select Destinations.
Explore the New UI: you can access to the BETA version, you will see the new interface. Take some time to explore the different features and options available.
Create a New Destination: Click on the "Create Destination" button and fill in the required details, such as the destination name, URL, and authentication method.
Save and Test: Save your new destination and test the connection to ensure everything is configured correctly

Check Connection

Export Destination in (JSON, YAML & Properties)

Benefits of the New Destinations UI

The new Destinations UI offers several benefits for SAP BTP users:

Efficiency: The streamlined workflow and enhanced configuration options save time and reduce complexity.
Usability: The intuitive interface makes it easier for users to manage their destinations, even if they are new to SAP BTP.
Flexibility: The ability to configure advanced settings and custom headers provides greater flexibility in connecting to remote systems.
Visibility: Improved visibility into destination details helps users quickly identify and address any issues, ensuring smooth operation of their applications

Conclusion

The new Destinations UI in the SAP BTP cockpit is a significant step forward in simplifying the management of destination configuration objects. As a BETA version, it offers a glimpse into the future of SAP BTP, where usability and efficiency are at the forefront. If you have access to the BETA version, be sure to explore the new features and provide feedback to help shape the final release.

SAP Cloud Connector 2.18 is out!

2025-03-19T23:42:44.566000+01:00

We’re excited to announce the availability of SAP Cloud Connector version 2.18. Building on previous iterations, this latest version offers several technical enhancements and solutions aimed at streamlining operations. Here are the key updates:

This release introduces support for Windows Server 2025. If you're preparing to upgrade your infrastructure, now’s the time to explore this compatibility. Note that some older OS versions will no longer be supported, so check the Product Availability Matrix for precise details.

Certificates are crucial for maintaining secure connections, but they come with expiration dates. As frequently requested by our users, the new version supports automatic renewal for subaccounts, minimizing the risk of downtime due to forgotten refreshes.

Don’t forget to enable Certificate refresh in the BTP Cockpit. This capability isn't available in all cloud regions immediately; it will be rolled out in phases across different regions. Once it becomes available in your region, the toggle button in the BTP Cockpit will be visible.

The administration UI defaults to Morning Horizon theme. However, you can also choose from other Horizon options, including Evening Horizon and Black/White High Contrast variants.

Navigate to Configuration > User Interface to set your preferred theme.

Version 2.18 introduces centralized management of E-mail and LDAP server trust stores directly within the Cloud Connector, bypassing the traditional JDK trust store. This setup allows finer control over securing backend communications with trusted certificates.

A new Troubleshooting section proactively diagnoses problems within the Cloud Connector.

You’ll find detailed reports on issues, especially those affecting data tunnels, along with root cause analyses and potential fixes. The framework categorizes and tracks recurring issues, providing insights into their recurrence patterns over time.

The cross-subaccount performance monitor aggregates metrics from all subaccounts related to cloud-to-on-premises traffic.

This consolidation aids in a more comprehensive analysis, helping you optimize resource allocation and network configurations efficiently.

Configure a fadeout time for service channels in HA setups to ensure smoother transitions when roles change intentionally between master and shadow instances. Known as the Service Channel Termination Grace Period, this new feature minimizes service disruptions by maintaining active channels during switches.

Certificate-based authentication now has a fallback mechanism to revert to user/password authentication if necessary. This added flexibility in logon processes ensures continual access, even when certificate-related issues arise.

Overall, SAP Cloud Connector 2.18 delivers enhancements focused on facilitating better security management, improving performance insights, and increasing reliability in high-stakes environments. Upgrade today to leverage these new features. For all technical details, see our comprehensive release notes.

Happy connecting!

Solving the ServiceInstanceName Dilemma: Token-Forwarding Destinations on SAP BTP with init_data

2025-06-05T10:59:00.926000+02:00

Solving the ServiceInstanceName Dilemma: Token-Forwarding Destinations on SAP BTP with init_data

When building multi-application landscapes on SAP BTP, configuring destinations correctly is crucial for seamless service integration. A common pattern is to forward an existing authentication token from an incoming request to a backend service secured by the same identity provider. The expectation is to avoid explicitly configuring authentication credentials or service bindings in the destination—just forward the token and go.

The Goal

We wanted to create subaccount-level destinations using the Generic Application Content Deployment (GACD) module in our MTA. These destinations should:

Forward the authorization token from the request (forwardAuthToken: true).
Avoid the need for service bindings or token service configurations.
Be configured with NoAuthentication, since the actual token is already included in the request.

The Problem: Our Initial Approach with GACD

Based on SAP documentation, we structured our mta.yaml like this:

modules:
- name: destination-content
  type: com.sap.application.content
  requires:
  - name: destination-service
    parameters:
      content-target: true
  - name: foo-api
  - name: bar-api
  parameters:
    content:
      subaccount:
        destinations:
        - Name: foo-api
          URL: ~{foo-api/url}
          forwardAuthToken: true
        - Name: bar-api
          URL: ~{bar-api/url}
          forwardAuthToken: true
resources:
- name: destination-service
  type: org.cloudfoundry.managed-service
  parameters:
    service: destination
    service-plan: lite

The expectation was straightforward: deploy this MTA, and the foo-api and bar-api destinations would be created, correctly forwarding the authorization token.

The Unexpected Outcome: Missing destination property [ServiceInstanceName]

However, upon deployment, we were met with the following error:

[ERROR] Missing destination property [ServiceInstanceName] in destination foo-api

This error was perplexing. Why would ServiceInstanceName be required for a destination designed to forward an existing token, rather than obtain one from a service instance (like an XSUAA or IAS service)? This seemed to contradict the very purpose of forwardAuthToken: true in this context.

Clarification from SAP Support

After seeking clarification, insights from SAP Development Support shed light on the situation. Here are the key points:

The GACD destination scenario, as currently implemented, primarily supports creating destinations through a service instance.
This means that even with forwardAuthToken: true, the GACD content module expects a ServiceInstanceName property. This implies an implicit dependency on a service instance for destination configuration, even if not for token fetching in the runtime.
For creating "NoAuthentication" destinations that simply forward the authorization token and do not rely on the destination service to obtain one from a bound service instance, the init_data approach is the recommended method.

The Recommended Solution: Using init_data

The init_data configuration within the resources section of your mta.yaml allows for direct definition of destination properties, bypassing the GACD content module's specific requirements for ServiceInstanceName in this `forwardAuthToken` scenario.

Here are corrected examples demonstrating how to achieve this using init_data:

Example 1: Creating my_destination_service-1

_schema-version: 3.1.0
ID: destination-with-app-1
version: 4.0.0

modules:
- name: app-provides-url-1
  type: staticfile
  path: ./hello-world.zip
  parameters:
    memory: 64M
  provides:
  - name: srv-api-1
    properties:
      srv-url: ${default-url}

resources:
  - name: my_destination_service
    type: org.cloudfoundry.managed-service
    requires:
      - name: srv-api-1
    parameters:
      service-plan: lite
      service: destination
      config:
        HTML5Runtime_enabled: true
        init_data:
          subaccount:
            existing_destinations_policy: update
            destinations:
              - Authentication: NoAuthentication
                HTML5.ForwardAuthToken: true
                Name: my_destination_service-1
                ProxyType: Internet
                Type: HTTP
                URL: ~{srv-api-1/srv-url}

Example 2: Appending my_destination_service-2 (reusing the same destination service instance)

_schema-version: 3.1.0
ID: destination-with-app-2
version: 4.0.0

modules:
- name: app-provides-url-2
  type: staticfile
  path: ./hello-world.zip
  parameters:
    memory: 64M
  provides:
  - name: srv-api-2
    properties:
      srv-url: ${default-url}

resources:
  - name: my_destination_service
    type: org.cloudfoundry.managed-service
    requires:
      - name: srv-api-2
    parameters:
      service-plan: lite
      service: destination
      config:
        HTML5Runtime_enabled: true
        init_data:
          subaccount:
            existing_destinations_policy: update
            destinations:
              - Authentication: NoAuthentication
                HTML5.ForwardAuthToken: true
                Name: my_destination_service-2 # Name must be different from existing destinations
                ProxyType: Internet
                Type: HTTP
                URL: ~{srv-api-2/srv-url}

Key Highlights for `init_data` Destinations:

Authentication: NoAuthentication: Explicitly states that the destination itself will not handle authentication.
HTML5.ForwardAuthToken: true: This specific property (often used in the context of HTML5 applications and Approuter) instructs the runtime to forward the incoming authorization token.
No ServiceInstanceName Needed: When defined via `init_data` in this manner, you avoid the GACD-imposed requirement for this property.
Direct Configuration: The destination is configured directly as part of the destination service instance's parameters, rather than through a separate `com.sap.application.content` module.

Understanding Resource Reuse and Destination Merging

A crucial point highlighted was how the my_destination_service resource behaves across multiple MTA deployments. When a resource with the same name and type (org.cloudfoundry.managed-service) is defined in several MTAs:

The system creates the service instance with the initialization data from the first deployment.
Subsequent deployments of other MTAs defining the same resource will update this existing service instance. Their init_data will be incorporated, effectively merging the destinations.
Crucially, existing destinations (with different names) will not be deleted. New destinations are appended to the existing set. This "append" behavior is governed by the existing_destinations_policy: update setting within the init_data.

This means that if you deploy "destination-with-app-1" first, my_destination_service is created with my_destination_service-1. If you then deploy "destination-with-app-2" (using the same my_destination_service resource name), my_destination_service-2 will be added, resulting in both destinations existing within the same my_destination_service instance.

Conclusion

While the GACD content module offers a streamlined way to deploy destinations alongside application content, its current limitations prevent it from directly supporting simple token-forwarding destinations without a mandatory `ServiceInstanceName`. For now, leveraging the init_data configuration provides the flexibility to define these "NoAuthentication" destinations, ensuring that the authorization token is forwarded as intended without unnecessary dependencies.

Understanding the nuances of how service instances and their init_data are managed across MTA deployments is key to building robust and scalable solutions on SAP BTP. We hope to see future enhancements to the GACD module to more intuitively support this common and valuable pattern.

Exposing SAP S4 Onprem data to external System || Odata Service || BTP || Destination-Connectivity

2025-07-24T09:09:11.979000+02:00

Prerequisites from BTP Side

SAP BTP Account
- Access to SAP Business Technology Platform (BTP) with appropriate entitlements.
SAP Cloud Connector Setup
- SAP Cloud Connector installed and configured to connect your on-premise S/4HANA system to SAP BTP.
- Destination configured in BTP cockpit pointing to your on-premise system.
Connectivity Service and Destination Service
- SAP BTP Connectivity service and destination service instance on the BTP account.
Cloud Foundry Environment
- Cloud Foundry space set up in your BTP subaccount to deploy the application.

Use Case:

Lets take a simple use case for creating a RAP service on S4, which is a wrapper API call on the reprocess IDOC function module.

For this we will create a RAP service on the S4 box, than activate the service with the /IWFND/MAINT_SERVICE and activate the ICF Node as well.

Note: In this blog we will not go through the steps of setting cloud connector and destination on the BTP account. We will assume that destination with cloud connector setup is already available on the BTP.

Step 1: Create and activate the RAP service on the S4 Box.

We will create a unmanaged rap scenario with custom entity and than we will create a service definition and top of service definition we will create service binding.

Lets create the class for the query implementation.

We are calling the FM to reprocess the idoc and checking the relevant table to get the latest reprocessed idoc status for the same.

Now we will create a service definition and service binding for the custom entity created.

Service Definition

And overall project will look something like this.

Here i have created two types of service bindings v2 and v4 but we will be using only v2 for this.

So overall we created below 4 artifacts.

1. Custom entity

2. Class

3. Service definition

4. Service binding

Now to test the service we will publish the service first and than call the generated url

if you see the image, i have published the service and after publish we also got the custom entity that we have created, click on the service url and it will open in browser asking for authentication of S4 user id and password.

Once the authentication is successful you should be able to see this.

Now lets open the SAP GUI so that i can show you the ICF node activation, which is generally taken care by basis team.

Open the Tcode: /IWFND/MAINT_SERVICE

Here you can find your activated service binding and make sure all components of the service looks as it is in the image.

Assuming cloud connector and destination is setup on BTP.

With this we completed the S4 box setup, now its ready to communicate with other external systems.

Step 2: Creating the Destination service and Connectivity service on the BTP Account.

1. Destination service, this will help us to get the destination details, Destination service gets all the registered destinations on the BTP, from which we can filter out the destination that is up for our S4 onprem box.

Destination service will give us all the relevant things like user id passwd, location and etc. for that destination.

Service key for the destination service

2. Connectivity Service, Since we are trying to get the data out of onprem system we will have to use connectivity service from btp, which will provide us proxies, this proxies will be use to call the onprem odata url.

It is important to paste here the service keys for better understanding since we will be using many things from the service key into our application

Step 3: Lets create a python application to call the onprem service.

Important things to consider here.

By using destination and connectivity service we cannot test the application on local system, we will have to deploy our app on CF to test the same.

We will use the flask requests and certain other libraries for the python programming

file: .env file to store all the secrets this secrets are from the service keys only.

File: Requirements.txt

File: Runtime.txt

python-3.11.*

file: manifest.yaml

file:idocapis.py (should be same as mentioned in Manifest.yml file

Load all the required libraries.

define the function to get the token

Define function to get the list of all destinations on the BTP

Define the function to construct the URL for the odata call

Define function to get token for the connectivity service

Define function to call the odata service with connectivity things

Now lets define the final route in flask to call this service

One thing to note here the RESOURCE variable will depend on the destination url of the onprem that is setup on BTP.

STEP 4: Deployment

Lets deploy the app on the CF by pushing the app to the cloud foundry from the BAS

Use command cf push after successful authentication for your cloud foundry space.

After the deployment on the cloud we can get the url that is generated on the cloud.

Testing the application:

Lets create a small python program to call this API in local now to test it.

You should get response coming from your S4 onPrem system.

Thanks for staying till the end!!!😊

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.

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!

5th SIBS Partners Meeting: Innovation with connectivity: SIBS with SAP

2026-01-26T14:50:18.361000+01:00

Last Thursday, I had the pleasure of participating, in the 5th SIBS Partners Meeting, held at Quinta da Atela, in Alpiarça. Once again, the event proved to be a key moment for knowledge sharing, strategic alignment, and strengthening the partner ecosystem around SIBS and its technologies.

This fifth edition reinforced the focus on collaboration, technological innovation and future vision, while also bringing new and highly relevant topics to the forefront — particularly the real impact of Artificial Intelligence (AI) on partner products, business models and go-to-market strategies.

Two panels, one shared goal: creating value

The event featured two discussion panels, both offering strong practical and strategic insights.

The first panel focused on the relationship between SIBS and its partners, addressing:

Different interaction models with SIBS
Real examples of products and solutions built on SIBS technologies
Technical, operational and integration challenges in real market contexts

This discussion clearly highlighted the maturity of the partner ecosystem and the importance of a collaborative approach to accelerate innovation while ensuring secure, scalable and reliable solutions.

The second panel was dedicated to Artificial Intelligence in partner products, fostering an open and pragmatic discussion around:

Security challenges related to the adoption of AI
The impact of AI on product value propositions
Commercial challenges and opportunities, including how AI can drive differentiation, sales growth and new business models

It became evident that AI is no longer just a technological topic, but a strategic business driver, requiring the right balance between innovation, trust, compliance and commercial viability.

Recognition for SAP–SIBS interface award

For me, one of the most significant moments of the event was the recognition given to Makevalue, which I represented, that received an award for the SAP–SIBS interface developed throughout 2025. I participated in this project in 2025, and it was a game-changer in terms of knowledge sharing and a comprehensive approach to product development: purpose, security, technology, sales, and marketing.

This project was a key enabler for the official certification of SAP/SIBS connectivity by SIBS, representing an important milestone in the integration between SAP systems and the SIBS payments and services ecosystem.

The solution was developed within the scope of a SIBS LABS project, further underlining its innovative nature and the strong collaboration between the technical and functional teams involved.

This recognition reinforces Makevalue’s commitment to:

Deliver robust, certified and enterprise-grade solutions
Enable seamless integration between core business platforms such as SAP and critical market infrastructures
Actively contribute to the evolution of the national and international technology ecosystem

Conclusion

The 5th SIBS Partners Meeting once again confirmed that the future is built on strong partnerships, continuous innovation and the responsible adoption of emerging technologies, particularly Artificial Intelligence. For the partners, this event was a moment of pride, exchange and strategic alignment, reinforcing our role as a trusted technology partner in complex integration and innovation projects

We remain fully committed to creating value, now strengthened by a recognition that reflects consistent work, close collaboration and a long-term vision.

SAP Community - SAP Connectivity service

Tell us about Your Experience with SAP BTP Connectivity

It has never been easier! Connecting cloud apps to Internet and on-premises systems using SAP BTP Connectivity

Prerequisites

Overview of the scenario

Configure the scenario

Expose the on-premises system to the cloud

Manage the technical connection configurations

Expose the destinations in the Kyma instance

Scenario in action: Connect the application to the remote systems

Executing request to Google:

Executing request to Google via destination:

Executing request to Google via destination via Cloud Connector:

Executing request to XSUAA API via destination:

Executing request to an on-premises HTTP server via destination via Cloud Connector:

Executing request to an on-premises HTTPS server via destination via Cloud Connector with Single Sign-On enabled:

Summary

Hey ABAP Cloud please let me save my data export to Azure Storage please🥺🙏- part 4

You guessed rightly my own proposal focusses on direct integration with Azure Blob

For an enterprise-grade solution however, you will need to use a more secure protocol like OAuth2 with Microsoft Entra ID

A fully automated solution deployment with the BTP and Azure terraform providers is only possible with the destination service approach as of today.

The application flow is quite simple once the authentication part is figured out

The Entra ID setup takes a couple of clicks

Thoughts on production readiness

Final Words

Child's play: Install SAP BTP transparent proxy using Helm

Prerequisites

Installation steps

Try it out

Examples

New Release Available: SAP Cloud Connector 2.17.0

Configuration as code (CaC) with destinations.

Configuration as code (CaC) with destinations.

Configuration as code with SAP BTP destination service

Technical User Propagation from JCo towards On-Premises

Background

Configuration

Example

Announcing the New "In-Metro" Disaster Recovery Solution for SAP BTP

SAP Cloud Foundry - Python and Cloud Connector - HTTP

Access HTTP-based resources:

Prerequisite:

1. Cloud Connector Configuration:

2. Create Connectivity Service instance:

3. Developing a Cloud Foundry App:

4. Testing the Application:

Hybrid Local Development with SAP Cloud Foundry: Access On-Premises APIs via the Cloud Connector

Scenario:

Concept: SAP Cloud Connector:

Example Setup:

Setting Up a Tunnel to a Sample Application

Running the Local Script via the Tunnel

SAP Cloud Foundry - Python and Cloud Connector - TCP

Accessing TCP-Based Resources

Prerequisite:

1. Configuration:

2. Create Connectivity Service instance:

3. Developing a Cloud Foundry App:

4. Testing the Application:

Consuming external services(Odata/Rest) using destinations configured in BTP cockpit.

Communicate from a Java Application to ABAP via WebSocket RFC using JCo - Migration Guide

Adjusting the destination

Extending the implementation

Setting up Trust

Creating the p12 File

Configuring trust in ABAP

Using WebSocket RFC in BTP

New Destinations UI available now in BETA version

A new Destinations UI for managing destination configuration objects is now available as a BETA version in the SAP BTP cockpit, side-by-side with the current UI. It is not yet at feature parity with the current UI, but feel free to try it out and send us your feedback.Old Destination UI

Getting Started with the New Destinations UI

Check ConnectionExport Destination in (JSON, YAML & Properties)

Benefits of the New Destinations UI

Conclusion

SAP Cloud Connector 2.18 is out!

Solving the ServiceInstanceName Dilemma: Token-Forwarding Destinations on SAP BTP with init_data

Solving the ServiceInstanceName Dilemma: Token-Forwarding Destinations on SAP BTP with init_data

The Goal

The Problem: Our Initial Approach with GACD

The Unexpected Outcome: Missing destination property [ServiceInstanceName]

Clarification from SAP Support

A new Destinations UI for managing destination configuration objects is now available as a BETA version in the SAP BTP cockpit, side-by-side with the current UI. It is not yet at feature parity with the current UI, but feel free to try it out and send us your feedback.

Old Destination UI

Check Connection

Export Destination in (JSON, YAML & Properties)