Personal Insights
myBank with SAP S/4HANA Cloud, APIM and Appgyver
![]() |
This brief is to showcase how one can implement access to any inbound ODATA or REST API by leveraging SAP Appgyver’s intrinsic Data integration capabilities. We shall see how this can be done using the BANK_0002 API (S4HC) against a productive S/4HANA Cloud system. |
Pre-requisites:
Good to know:
Disclaimer:
|
Before we start…
An aerial view of S/4HANA Cloud APIs.
![]() |
With a whooping […] and counting business APIs, there is an ever growing number of these APIs that support the principal business user propagation out-of-the-box. (this is with either OAuth2SAMLBearerAssertion or SAMLAssertion authentication flows) |
Good to know:
- However, even if the above still does not hold true for all the APIs, quite a large number of APIs supports x509 client certificate authentication (albeit with regard to a communication user).
- At present, the customer influence portal is conducting a S/4HANA Cloud campaign focused on the APIs without any upvoting threshold, namely https://influence.sap.com/sap/ino/#/campaign/1175
Let’s have a look at the line-up of the S/4HANA Cloud APIs on SAP_API_BUSINESS_HUB .
Good to know: As the SAP API Business Hub offers its own ODATA catalog service we shall be using it for APIs browsing and discovery as follows:
|
Additionally, the APIs can be broken down by subtype as follows:
Q: Is there an easy way to know what authentication methods are supported, what communication scenario are involved, etc ?
A: Indeed, it is fairly easy to [programmatically] retrieve a given API characteristics merely by its catalog name…for instance:
With merely knowing the name of an API the API definition can be looked up on API Business Hub as follows: for instance, https://api.sap.com/api/BANK_0002/overview Likewise is the possible to retrieve an openapi definition by its mere name, in either json or yaml format, as follows: |
Putting it all together.
Step1. The communication arrangement (S/4HANA Cloud)
Let’s create a new communication arrangement based on the Bank Integration communication scenario for the following API, namely BANK_0002
Please refer to the following gist for further details.
Step2. myBank API proxy (SAP API Management)
Let’s implement S/4HANA Cloud myBank API with the OAuth2SAMLBearerAssertion flow by leveraging API Management.
The end game is to be able to fetch the EDMX metadata using the API Proxy URL below:
https://<API Proxy hostname>/xxxx/BANK_0002/$metadata
Good to know:
- myBank API proxy has a built-in CORS policy where additional headers can be added or removed
Please refer to the following gist for further details.
Step3. Create a front end web application (SAP Appgyver)
SAP Appgyver offers a so-called “zero lock-in” approach to data. In other words your data never hits Appgyver backend servers.
All you need to do is to expose your backend functionality with either ODATA or REST APIs.
![]() |
![]() |
![]() |
and voila…
Please refer to the following gist for further details.
Conclusion.
Last but not least, I hope you enjoyed reading this blog. Please provide your feedback in the comments section below.
Appendix
A case for SAP API Management as a framework to implement your extensions with S/4HANA CloudQ. What is the key advantage of using SAP API Management (APIM) to implement extensions with S/4HANA Cloud ? A. There are several ones.
|
Great information Piotr Tesny
Hi Piotr,
You have provided some valid reasons for using SAP API Management for S/4HANA Cloud Extensions. However, I am wondering though for Step 2 above, is the reason for using API Management because AppGyver does not support the OAuth2SAMLBearerAssertion flow directly, which in contrast is supported by the Destination concept on BTP without the need for API Management?
Since API Management is no longer sold as a standalone product and now bundled with SAP Integration Suite, this adds significant cost for deploying AppGyver integrations with S/4HANA Cloud in a production system.
Regards,
Mustafa.
Hello Mustafa Bensan,
Thanks for reading my blogs. Indeed, there is no such a thing as one size fits all.
I personally strongly adhere into the paradigm of the separation of duties.
IMO, front end applications should be isolated from the backend services and LOB applications as much as possible.
That approach also enables the concept of plug-and-play.
And there is a number of ways to develop front end applications in the SAP ecosystem.
For this brief I picked SAP Appgyver because it is the no-code part of the LCNC paradigm. With APIM being the low-code asset management tool per-se.
And there are new upcoming SAP Appgyver features: https://roadmaps.sap.com/board?PRODUCT=73554900100800003801&range=CURRENT-LAST#;INNO=000D3ABE772D1EDC92ED963C569BFD1E
I hope that helps...regards; Piotr
PS.
On a side note I have written tons of blogs where I explore the integration/extensibility patterns leveraging BTP destinations (https://blogs.sap.com/2021/06/06/quovadis-or-how-to-find-your-destination/).
So watch this space for yet another one...quite soon...