Dear Community,

In this blog post, I would like to share how you can enhance your extensions running on SAP BTP to securely consume the data from the SAP S/4HANA system with the help of SAP Private Link Service.

To get started with the SAP Private Link Service I highly recommend you to read up on a great blog series by Martin Pankraz.

The focus of this blog is the extension use case built with SAP Cloud Application Programming Model (CAP) and SAP Cloud SDK for JavaScript.

Following releases of SAP Cloud SDK for JavaScript allows us to build our extensions with CAP Node.js using Private Link Service

• Release 1.54.0 is supporting the new proxy type PrivateLink of destination service which can be used from extension applications
• Releases 2.4.0 supports self-signed certificates using the trust store property of the destination, which closes the loop on the end-to-end SSL setup

Before getting into the technical details, I would like to share a couple of words about why you may want to work with the SAP Cloud Application Programming Model and Private Link Service for extensibility scenarios.

Why Cloud Application Programming?

SAP BTP offers a wide range of services and technologies and as a developer, it can get quite complex choosing the right selection of tools and technologies for your business problem. SAP Cloud Application Programming model provides developers a great framework to focus on business logic and not on the underlying technologies. In other words, CAP provides you with an abstraction in the form of the necessary tools, libraries, and best practices to build enterprise-ready applications. CAP Model is also widely used to extend business processes, such as the SAP S/4HANA.

Why Private Link Service?

With the increasing adoption of the RISE with an SAP offering, customers can now take advantage of new approaches to extend SAP S/4HANA or other SAP applications on SAP BTP by blending Microsoft Azure services.

SAP and Microsoft are closely working together to improve the integration, connectivity, and security of SAP solutions on Microsoft Azure. If you are interested in some of the co-innovation outcomes, feel free to check out this openSAP course titled “Building Applications on SAP BTP with Microsoft Services”.

Since the release of the openSAP course at TechEd 2021, our engineering teams released the SAP Private Link Service service to securely connect applications running on SAP BTP (deployed on Azure) to workloads running on Azure. This ensures that traffic is not routed through the public internet but stays within the Azure infrastructure.

A typical use case for the SAP Private Link service is to communicate with an SAP S/4HANA system deployed on Microsoft Azure. The communication can be used for the extensions running on SAP BTP and consuming the SAP S/4HANA APIs. This connection can be established by creating an Azure Private Link service that exposes a load-balancer that routes traffic to the SAP S/4HANA system.

Using the SAP Private Link service will not require the SAP Cloud Connector (reverse proxy tunnel over the public internet) to expose the systems and communication through the internet, the entire traffic is secured by an internal hyperscaler network without any exposure.

Customers and partners with extensive security requirements can benefit from this service.

Now let’s have a closer look at the different moving parts

Diagram 1 – Use case architecture overview

As an example, I choose the following end-to-end extension scenario and enhanced it with SAP Private Link capabilities (see diagram 1). You can find the use case details on SAP Discovery Center. The scenario represents a Business Partner Validation application, which was developed using the SAP Cloud Application Programming Model (CAP). It runs on the SAP BTP, Cloud Foundry runtime and leverages platform services like SAP Event Mesh, SAP HANA Cloud, etc. The CAP application on SAP BTP asynchronously consumes the event triggered by the SAP S/4HANA backend and data is read using OData APIs from the SAP S/4HANA system. The initial communication between SAP BTP and S/4HANA system over SAP Cloud Connector was replaced by the SAP Private Link Service.

To get started, first of all, the SAP Private Link Service needs to be activated on the SAP BTP subaccount (remember the subaccount should be on an Azure region), and on the Azure side, the Azure Private Link Service can be created by using an Azure Load Balancer. You can find the detailed steps in the following repository.

After successfully establishing connectivity  between Azure and SAP BTP, you will be able to find the generated set of private DNS hostnames (hostname, addinionalHostname) in the Private Link Service instance, which will be used later for private communication. An example you can find below:

hostname: "db0ebb6b-d6b9-edfb-85a6-a22076438dd0.43c6b4ab075f566feb1541589d570cd2c164c5d4acda6617f6e5139b.p1.pls.sap.internal"

additionalHostname: "db0ebb6b-d6b9-edfb-85a6-a22076438dd0.p1.pls.sap.internal"

The following two steps are required to enable the Private Link connection in CAP Application

1. Adapt Destination for PrivateLink Service – Configure/Update the destination
2. Bind application to Private Link service

Adapt Destination for PrivateLink Service – Update the destination

Instead of using Proxy Type On-Premise for Cloud Connector connectivity, SAP introduced a new Proxy Type PrivateLink. Choose that proxy type and use the Private Link hostname mentioned above as the Destination URL [https://<hostname>]. Below you can see an example of Destination configuration.

Destination Configuration

Although Private Link Service opens up a private tunnel, it is common to use Transport Layer Security (TLS) for security between applications.

For HTTPS communications you have 2 options. The first option is to set the additional property TrustAll=true. In this case, the server certificate will not be checked for SSL connections. It is intended for test scenarios, and should not be used in production (the server certificate will not be checked and you won’t notice MITM attacks).  The second option is to provide the server certificate by uploading it into the TrustStore of Destination service.

As you may remember, SAP Private Link service provided private DNS entries for Azure Private Link services. These entries can be used to issue TLS certificates so that connected systems can identify themselves. For that, you need to configure SSL in SAP S/4HANA System and create an additional PSE (Personal Security Environment) dedicated to the Private Link connections.

With help of the sapgenpse command, you can create a new PSE called e.g., SAPSSLS_PLINK.pse by providing a Distinguished Name which is the hostname of the Private Link service instance from SAP BTP.

Using the same sapgenpse command, you can export the certificate from the PSE file and upload it into TrustStore of Destination Service of SAP BTP. The Certificate can be either self-signed or signed by a custom/private Certificate Authority (CA).

sapgenpse get_pse -p /usr/sap/S4H/D00/sec/SAPSSLS_PLINK.pse "CN=40a42b84-39bb-4f42-9729-28703961e72c.d0c0e029c004f9708f238eda0225a8309caac87824aa1aae23ff658b.p6.pls.sap.internal"

sapgenpse export_own_cert  -p SAPSSLS_PLINK.pse

NOTE: The current approach is limited to self-signed certificates and public CAs cannot be used since Private Link service has internal DNS names and CAs will not provide certificates for internal name

The detailed steps on how to establish end-to-end SSL can be found in this GitHub repository.

For the Scenarios where you have SAP Web Dispatcher in front of your SAP S/4HANA System, you can configure SSL in SAP Web Dispatcher. Please refer to this blog post

Bind application to Private Link service

The second and last step of making your CAP application run/communicate with the SAP Private Link Service is to bind the application with the SAP Private Link Service instance. This gives the Cloud Foundry space access to the private endpoint. Upon the creation of a binding between a CF application and a private link service instance, the Private Link service creates a space-scoped Cloud Foundry application security group that enables network access to the IP address associated with the Private Endpoint.

There are a couple of ways to do that. One option is to manually bind using CF CLI, another option is to add the binding in the application descriptor. In this scenario, we have a Multitarget Application (MTA) and the binding is done in mta.yaml descriptor (see below).

modules:
 - name: BusinessPartnerVerification-srv
   type: nodejs
   path: gen/srv
   requires:
     - name: BusinessPartnerVerification-pl

...

resources:
  # PrivateLink Service
  - name: BusinessPartnerVerification-pl
    type: org.cloudfoundry.existing-service
    parameters:
      service: privatelink
      service-name: private-link-s4hana # change to your instance name
      service-plan: standard

After the above mentioned setup, you can execute the requests from your CAP service.

In the current version of CAP, you need to use SAP Cloud SDK for executing the requests (see code snippet below). In the next CAP major release, the Cloud SDK TrustStore feature will be available also in a httpClient implementation of CAP and there will be no need to execute the request over Cloud SDK (as long isn’t required in your scenario).

const { businessPartnerService } = require('@sap/cloud-sdk-op-vdm-business-partner-service');

this.on('READ', BusinessPartners, async (req) => {
        try {
            const { businessPartnerApi } = businessPartnerService();
            const result = await businessPartnerApi
                .requestBuilder()
                .getAll().select(
                    businessPartnerApi.schema.BUSINESS_PARTNER,
                    businessPartnerApi.schema.BUSINESS_PARTNER_FULL_NAME,
                    businessPartnerApi.schema.BUSINESS_PARTNER_IS_BLOCKED
                ).top(100)
                .execute({ destinationName: "BusinessPartner" });
            return result;
        } catch (err) {
            req.reject(err);
        }
 });

Summary

That was it! Once you have an existing extension application and established the Private Link connectivity, it is straightforward to update your extension application to communicate via a private connection.

The end-to-end scenario you can find in the following GitHub repository with source code and a step-by-step guide

What to expect next? In one of my next blog posts, I’ll share how to use a standalone application router as a proxy app to open a channel for SAP Private Link service to other BTP services like SAP Fiori Launchpad or SAP Cloud Integration.