Technical Articles
Blueprinting LOB extensions with SAP BTP services and API Management
![]() |
SAP BTP is a platform with several technical built-in-in services like connectivity, identity, application router etc and application runtimes like Cloud Foundry, Kyma, ABAP or Other. The native platform services can be consumed from any runtime. For instance, the Other runtime options allows for consuming native services from anywhere (from other bespoke runtime or environment). Disclaimer:
|
![]() |
The best practices for SAP BTP explain in more details the approach towards Extending Existing SAP Solutions Using namely:
|
Let’s take a step back and try to understand how you could proceed to design and blueprint a bespoke extension of yours. |
Blueprinting LOB extensions with SAP BTP services and API Management. Qu’est ce que c’est ?
Recently I got pulled into a project extending an existing SuccessFactors ECP on-premise integration with a digital twin on SAP BTP. Overall, a design with a very classic architecture on SAP BTP with SAP BTP sub-account acting as a service provider for the SuccessFactors tenant, as depicted below:
There is one more identity provider and one more service provider in this diagram… Guess what, the destination service itself is this other identity provider as it will produce a saml bearer assertion that will be consumed by the ECP OAuth client. And the ABAP NW server hosting the ECP engine is this other service provider. The destination service is like a travel agent acting on behalf of the business user to get the user to the destination. The authentication flow just described is commonly referred to as IDP-initiated authentication dedicated to unattended, unmanned integration scenarii. The project was at stalemate. I said to myself..hmm. that’s actually pretty well documented here: SuccessFactors Employee Central with S/4HANA ECP (Employee Central Payroll). So why the stalemate ? Me again back to reading the manual. OK. SuccessFactors is a very “clever” piece of software. Well thought through and well designed. And in this type of outbound integration towards an ECP payroll system a SFSF tenant can do it all.
|
Putting it all together.
Me back to solving the problem. OK. The digital twin should be capable of offering the same “all-in” outbound destination features as the SFSF tenant can do. Thus I split the problem into three separate tasks, namely: |
Task 1 (prepare destination).
{
"Name" : "QUOVADIS",
"Type" : "HTTP",
"URL" : "https://<FQDN>/sap/opu/odata/sap/PYC_CONF_SRV/?sap-client=<***>",
"Authentication" : "OAuth2SAMLBearerAssertion",
"ProxyType" : "Internet",
"KeyStorePassword" : <Password>,
"tokenServiceURLType" : "Dedicated",
"audience" : <audience>,
"authnContextClassRef" : "urn:oasis:names:tc:SAML:2.0:ac:classes:x509",
"Description" : "QUOVADIS",
"x_user_token.jwks_uri" : "https://<indentityzone>.authentication.<region>.hana.ondemand.com/token_keys",
"tokenServiceUser" : <OAuth client user>,
"tokenServiceURL" : "https://<FQDN>/sap/bc/sec/oauth2/token?sap-client=<***>",
"tokenServicePassword" : <password>,
"KeyStoreLocation" : <location>,
"clientKey" : <OAuth client user>,
"nameIdFormat" : "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
"scope" : "PYC_CONF_SRV_0001",
"userIdSource" : "user_name"
}
Task 2 (prepare the OAuth communication channel).
Prepare the OAuth communication channel with ABAP server. That’s the hardest part of the configuration. You may not have done it before but the ABAP skills are a “must have”. I have never done it before, However, with ABAP is like with riding a bike, once you’ve learnt it you never forget it. Indeed my ABAP skills helped me overcome all the hurdles on the way. On a side note, the whole process is also very nicely documented on public SCN wiki pages here.
Good to know:
|
Task 3 (Find destination).
Find destination with SAP BTP destination service. Please note that an ABAP server OAuth Provider does not expose an “idp” endpoint to generate a signed saml bearer assertion.
Here follows the json output from the find destination call to SAP BTP destination service with the above destination definition. Based on that definition the destination service will internally build a saml assertion and will call into the OAuth client token endpoint to get the bearer access token. Please note the [business] user identity used by the destination service to build the saml assertion is either implicitly provided by the XSUAA’s user JWT or it has to be provided in the X-user-token header of the find destination call. And in either case the mandatory x_user_token.jwks_uri property is a pointer to the jwks uri of the OIDC provider (in this very case the XSUAA service is the OIDC provider). |
{
"owner": {
"SubaccountId": "<SubaccountId>",
"InstanceId": null
},
"destinationConfiguration": {
"Name" : "QUOVADIS",
"Type" : "HTTP",
"URL" : "https://<FQDN>/sap/opu/odata/sap/PYC_CONF_SRV/?sap-client=<***>",
"Authentication" : "OAuth2SAMLBearerAssertion",
"ProxyType" : "Internet",
"KeyStorePassword" : <Password>,
"tokenServiceURLType" : "Dedicated",
"audience" : <audience>,
"authnContextClassRef" : "urn:oasis:names:tc:SAML:2.0:ac:classes:x509",
"Description" : "QUOVADIS",
"x_user_token.jwks_uri" : "https://<indentityzone>.authentication.<region>.hana.ondemand.com/token_keys",
"tokenServiceUser" : <OAuth client user>,
"tokenServiceURL" : "https://<FQDN>/sap/bc/sec/oauth2/token?sap-client=<***>",
"tokenServicePassword" : <password>,
"KeyStoreLocation" : <location>,
"clientKey" : <OAuth client user>,
"nameIdFormat" : "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
"scope" : "PYC_CONF_SRV_0001",
"userIdSource" : "user_name"
},
"certificates": [
{
"Name": <location>,
"Content": "MIIQeAIBAzCCEDIGCSqGSIb3DQEHAaCCECMEghAfMIIQGzCCCggGCSqGSIb3DQEHAaCCCfkEggn1MIIJ8TCCCe0GCyqGSIb3PG/HcO5xW0ai3ZkwPTAhMAkGBSsOAwIaBQAEFMyS26dKft/dWRSIVg/SQvDnQmaSBBQTST14Lse+rKA3igKg4Q7gzIB0mAICBAA=",
"Type": "CERTIFICATE"
}
],
"authTokens": [
{
"type": "Bearer",
"value": "AFBWi3u9Htuzw77bWyiBXc7kUQjy51gIBlvMSGqJN07****",
"http_header": {
"key": "Authorization",
"value": "Bearer AFBWi3u9Htuzw77bWyiBXc7kUQjy51gIBlvMSGqJN07f****"
},
"expires_in": "3598",
"scope": "PYC_CONF_SRV_0001"
}
]
}
Task1+Task2+Task3 === Bon voyage:)
As a result the digital twin can talk to the ECP payroll instance on premise extension on behalf of SFSF tenant business users whose identities are propagated securely by the destination service towards the ECP payroll system.
Bon voyage:) |
![]() |
Conclusion.
As a rule of thumb, it is so much worth decomposing your solution into smaller building blocks and try to assemble them – pretty much as you would be doing it with your kids lego sets. My own experience is that often you come up with a way simpler solution than the initial design! This is how I ended up with using API Management, part of SAP Integration Suite, for both calling the destination service APIs and/or implementing the saml bearer authentication with the security policies SAP ships on API Business Hub. |
Appendix
Configuring OAuth 2.0SAP currently supports the following OAuth 2.0 flow for unattended integrations:
SAML 2.0 Bearer Assertion Flow for OAuth 2.0Prerequisites
For more information, see Configuring OAuth 2.0. |
__________
Additional resources.
You may refer to Best Practices for SAP BTP – SAP Help Portal for more information. Also available as PDF here: Best Practices for SAP BTP Quovadis or how to find your destination? How to generate SAML bearer assertion token with SAP BTP Destination Service? |