Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
quovadis
Product and Topic Expert
Product and Topic Expert









Just think of SAP BTP as a solar system with its native runtimes and services but still allowing you to reach destinations in a different universe.











Indeed, SAP BTP offers a number of kernel services. Among them the connectivity services.

SAP BTP Connectivity services comprise a connectivity lite, connectivity proxy and destination services.

The destination service is the messenger, the go-between.

It is there to broker an authorised access to the target resource (based on business user identity and this user's authorisations) and eventually yields the key to the Sesame, a so-called bearer access token.

The connectivity proxy service is there to soften the effort of calling the target resource ODATA or REST inbound endpoints -  and make it as seamless and transparent, as it can possibly be.

Please see the following gist for further details.

Q. OK. The cloud to on premise connectivity is sorted out. What about the business logic? Where and how do I run it?

A. Likewise, SAP BTP offers a number of runtimes to host and run your business logic workloads.

Among them there is SAP Kyma Runtime which is the SAP-managed kubernetes cluster offering. Furthermore, SAP Kyma Runtime offers an out-of-the-box integration with the SAP BTP connectivity services. 

Thus SAP Kyma is a de facto runtime of choice when it comes to extending SAP LOB applications with the cloud native applications.

 

Disclaimer:

  • This is playground only. It is based on publicly available information and resources. Always refer to official SAP documentation where applicable.

  • Please note all the code snippets and gists are provided “as is”.

  • All the x509 certificates, bearer access and refresh tokens and the likes have been redacted.

  • Images/data in this blog post is from SAP internal sandbox, sample data, or demo systems. Any resemblance to real data is purely coincidental.


 

Putting it all together


The principal propagation with OAuth2SAMLBearerAssertion flow.


The security is paramount. The OAuth2SAMLBearerAssertion flow combines a user's authentication (principal propagation) and user's authorisations (scopes).

Thus allowing to securely and selectively reach to SAP (and non-SAP LOB) applications resources.

Q. Would you reckon a single call to a destination service OAuth2SAMLBearerAssertion destination can broker access to OAuth2 resources (based on the business user identity and authorisations) from anywhere?

And that includes a native support of a cloud connector tunnel in case your target resources/systems are not or cannot be exposed to the public internet.

A. Well, it's always good to do and see things by example. Let's use SAP S/4HANA ABAP (1909) on premise for this purpose.

The landscape.


For this brief, I opted for mostly free and publicly available SAP resources (including the ABAP 1909). Always refer to T&C.

Pre-requisites:

  • SAP BTP Kyma Runtime cluster (a BTP free-tier Kyma Runtime free plan can do) with the connectivity proxy plan and destination lite entitlement for the sub-account.

  • S/4HANA ABAP system with admin rights (an ABAP 1909 can do)

  • SAP Cloud Connector



A couple of explanations to the above landscape architecture:

  • There is only one single code snippet required to implement the S/4HANA business logic extension on kyma runtime. With most of the effort going into the configuration of the landscape.

  • The business logic is a kyma cluster workload. And for the sake of simplicity I opted for a single nodejs inline kyma function (lambda). But any other type of application like for instance CAP application would fit in here.

  • The destination service can be either provisioned on the kyma runtime side or on the BTP subaccount level. However, the connectivity proxy should be provisioned on the kyma runtime side.

  • For the sake of brevity, I'm not showing how to call the find destination API of the destination service as this is covered in the official SAP help pages.


The blueprint.


The solution blueprint is a sequence of three tasks as depicted below:


















Task1

Task1 is all about either using the destination service trust or using your own trust with the remote target system OAuth2 application.

A destination definition is a json formatted descriptor telling the destination service how it should call the remote target system OAuth2 application's token service.

For instance, the QUOVADIS_A4H-JWT destination definition has a number of mandatory headers and attributes and has also several additional properties. Please refer to the following gist for all the details.
Task2 Task2 is all about S/4HANA OAuth2 configuration steps 1-2-4-3 as described in the S/4HANA ABAP OAuth2 communication configuration blog
Task3

Task3 is single call to the destination service to broker the access to S/4HANA resources.

If the Find destination call succeeds then access bearer token will be made available as the Authorization header value.

SAP S/4HANA inbound API access with cloud connector and connectivity proxy.


The remaining one-off landscape configuration steps with SAP Cloud Connector and connectivity proxy service provisioning are described in the Appendix section below.

As already explained, with the authTokens[0].http_header.value you should be able to call any OAuth2 enabled S/4HANA API that matches the list of scopes.

Here you go.... that is all it takes to call into an ODATA API of your S/4HANA ABAP on premise system.
var value = authTokens[0].http_header.value;

async function callS4H(value)
{
let sap_client = '001';
let entity = 'Products';
url = 'https://vhcala4hci:50001/sap/opu/odata/sap/EPM_REF_APPS_SHOP_SRV/' + entity + '?sap-client=' + sap_client;

let documents = {}
try {
const options = {
proxy: {
protocol: 'http',
host: 'connectivity-proxy.kyma-system',
port: 20003
},
headers: {
'Authorization': value,
'Content-Type': 'application/atomsvc+xml',
'SAP-Connectivity-SCC-Location_ID': 'connectivity-proxy',
}
};
const response = await axios.get(url, options);
documents = JSON.stringify(response.data, null, 2);
console.log(documents);
console.log(response.status);

}
catch(error) {
console.log(error.message);
documents = JSON.stringify(error, null, 2);
};
return documents;
}

 

and if that was still too much code you may always opt for the SAP Graph (cf Appendix below) service to take this burden away.

 

Conclusion.


Last but not least, I hope you enjoyed reading this blog. Please provide your feedback in the comments section below.

Subsequently, I am planning to publish a sequel blog with SAP Appgyver as a front end tool consuming S/4HANA ODATA endpoints via protected Kyma API rules...

 




 

Appendix


 

SAP S/4HANA inbound API access with cloud connector and connectivity proxy. One-off configuration.


Before we can use the destination service to broker access to on premise S/4HANA ABAP system resources we need to tie the S/4HANA ABAP system to the BTP sub-account of the kyma cluster as follows.

1. First we need to hook up our Cloud Connector to the BTP sub-account where the connectivity proxy service is running.











CC side (on premise) BTP side (cloud)

2. Next we need to create at least one physical to virtual host mapping. Here goes the CC physical to virtual HTTPS ABAP host mapping:


 

3. Connectivity proxy (one-off operation). The following gist has a few more details on the provisioning itself.

 

SAP Graph.


Another good example of the destinations and connectivity proxy is SAP Graph service.

SAP Graph is a unified ODATA API middleware

SAP Graph can help build business graphs and ease the navigation pain between different functional entities of SAP LOBs through a ODATAv4 composition paradigm.

In order to build its spider web of... compositions SAP Graph relies on... BTP destinations.

If a destination is an on premise type of destination SAP Graph will  eventually leverage the connectivity proxy to fetch the business API ODATA endpoint /$metadata.

This can make your business logic even simpler because you will no longer need to deal with the connectivity proxy on your own.

Last but not least, you may find a comprehensive overview of SAP Graph service here: https://blogs.sap.com/2021/12/20/unboxing-sap-graph-early-adopter-release/

 




Troubleshooting


The following gist offers in-depth troubleshooting notes.





8 Comments