Skip to Content
Technical Articles
Author's profile photo Alessandro Spadoni

SAP BTP client certificate destination for an IBP communication scenario: side-by-side extensibility

Hello community,

after several years, I am returning to write a blog. For almost a year now, I start a new professional adventure with my fellow adventures Patrizia Rossi ,  Sergio Ferrari  and other friends. I feel a renewed enthusiasm in writing and sharing my experiences, especially regarding the BTP platform .

The journey from 2010s Netweaver blogs to the new BTP era. So, I hope that this will be the first blog of a new long series.

In this blog, I want to describe how to set up a secure connection based on X.509 certificate from BTP to SAP IBP (SAP Integrated Business Planning for Supply Chain) within the context of side-by-side extensibility.

You can find detailed explanations about this process in the official documentation at the following link:

Important: Of course, this approach is applicable to any context of an ABAP environment and a communication scenario where we want to establish a connection via a certificate. In the blog, I will describe it focused on a specific communication scenario of SAP IBP.


I am not an IBP consultant, and I won’t go too deep into product-specific details.

The side-by-side extensibility scenario, as described in the link, involves a custom algorithm implemented in BTP / CAP, using the OData services exposed by SAP IBP for both reading and writing Master Data and Key Figures.

The communication arrangement used in this context is SAP_COM_0720, and you can find a detailed explanation of the OData services in this blog:

I will describe how to configure a connection between BTP and SAP IBP using X.509 certificates, allowing a seamless integration of your custom algorithm with SAP IBP’s OData services.

As we can see in the image below, OAuth 2.0 is not supported as an Inbound Authentication Method for the Communication Arrangement Managed by SAP


IBP Communication Scenario


We could generate a password for the user defined in IBP and use the simpler basic authentication. However, as we already know, and as emphasized in the IBP documentation “Secure Communication for Inbound Integration” the “Certificate-based authentication” option is highly recommended.

By opting for certificate-based authentication, we ensure a more robust and secure connection between BTP and SAP IBP.


Generate and download the Certificate via Connectivity service

With reference to the Connectivity service documentation (, navigate to the “Destinations” section of your subaccount and select the “Certificates” option. From here, you can generate a new SAP Cloud PKI Infrastructure Certificate. In this example, I am generating a PEM certificate, setting a password, and configuring it to be valid for one year.

Once the certificate has been generated, it will be listed among the available certificates. However, as mentioned in the highlighted message, downloading the certificate is only possible through the REST API.

To identify the API for accessing certificates within the subaccount, we can leverage the SAP Business Accelerator HUB. In our case, we want to access the certificates associated with the subaccount using the relevant API

Let’s proceed to use Postman. If you haven’t done so already, you can create a new instance of the “Destination Service” and generate a key to obtain the client ID / client secret pair required to invoke the API from Postman.

In Postman, we have to use the Grant Type “Client Credentials” where:

  • Access Token Url is the url of the key plus /oauth/token
  • Client ID and Client Secret the corresponding values from your key.

The endpoint we are going to use to access the certificates of the subaccount is

Once we obtain the OAuth token and send the request, we receive the list of certificates along with their corresponding content in Base64 encoding.

I’m a windows user , so to decode the Content from base64 to a file, I used Powershell but you can use the tool (or online tool) you prefer

$base64String = "pasteYourBase64Content"
$decodedString = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($base64String))
$decodedString | Set-Content -Path "C:\your\path\your_certificate.pem"

Now you have your .pem certificate containing both public cert and key.

pem can be opened with a text editor and splitted in 2 new files:

content between



in a .key and the fullchain starting from —-BEGIN CERTIFICATE—— in a .crt file





Upload the Certificate in Target System (SAP IBP in our scenario)

The certificate (.crt) must be uploaded in the “Communication User” Fiori App. This is the communication user will be used in the Communication Arrangement.


Now you can test the certificate with a request in Postman. In Settings, it’s possible to add key,crt , the host of your target system and the password you specified during the creation of PEM.

Additional details can be found here


Now we can create the destination that will use the certificate to authenticate towards IBP. However, before that, we need to upload the key that will be referenced during the definition phase. We can generate the key in .p12 format using OpenSSL (I’m not an OpenSSL expert). The command that can be used to generate it is:

openssl pkcs12 -export -in IBP_EXT.crt -inkey IBP_EXT.key -out IBP_EXT.p12

Go again in the “Certificates” of the subaccount and upload the .p12 file

Create the Destination

Now we are ready to create the destination with Authentication: ClientCertificateAuthentication

where URL is your IBP OData Endpoint of the communication arrangement

Key Store Location your .p12 and Key Store Password is your password

Side By Side: Test the destination in CAP / Application router

There are several ways to test the functionality of the destination to ensure it works correctly. We could create a CAP project or a project using the Productivity Tools within the space.

However, I believe the simplest and fastest way to test the routing and proper functioning of a destination is to define a custom app router that forwards inbound requests to the destination.

This tech byte perfectly explains how to define a custom app router for this purpose. The only adjustments I had to make compared to the template were to update the Node version, OAuth redirect-uris in xs-security.json and add a basic auth in order to easily test the application router’s endpoint from Postman

my repository can be found here

Once the Node app is deployed, we can open the link of the application router and append the relevant OData path for the master data (or key figure) we want to test.

At this point, we can verify that the OData service is correctly consumed using the routing destination.



The list of SAP IBP trusted root CAs is available in SAP Note 2801396  (SAP Global Trust List). SAP is not in the list but I suppose it’s “trusted” by default (also used for Cloud Connector). If you have some useful additional info about this, please add your comment


Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sergio Ferrari
      Sergio Ferrari

      Nice post Alessandro Spadoni !

      Very rich of technical information