Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 


I have a worry that without usage guidance and configurable usage limitations, these amazing beautiful powerful ODATA API's could bring down the S/4HANA Digital Core.

I recently got de ja vu and have the feeling ODATA API's need a Safety Belt like we had back in the day with BI Java 1127156 - Safety belt: Result set is too large - SAP for Me 

In this blog I will explain why I propose to SAP that they put in a Safety Belt for ODATA API's.

Ultimately, I think that we should be ring fencing the S/4HANA Digital with Enterprise Blockchain and therefore Digitally DeCoupling the S/4HANA Digital Core from being an API End Point for 3rd Party Applications. But, in the meantime a Safety Belt will help. That's explained here: RingFencing & DeCoupling S/4HANA with Enterprise Blockchain and SAP BTP - Ultimate Cyber Security 🚀

If you have time, read on for the whole story 🙂


Ok, let's go...

Back in 2001, at Sapphire, Hasso Plattner gave a keynote which included introducing, "the beast called ABAP WebDynPro".

I grew up with BAPI's and RFC's, looking back, those were simpler times,  for me (and, disclaimer, I am not the world expert) BAPI's have three dimensions:

The Import Parameters

When we call a BAPI we pass as part of the call, some parameters which are needed to execute the BAPI and which influence the processing of the BAPI

The Business Logic / Processing Logic

This is where the BAPI does it's work, the ABAP / SQL program which triggered by the call and the Import Parameters does something and returns data

The Export Parameters

This is the output of executing the BAPI, this is what we get back in return when we call the BAPI

Looking back, in terms of Operating/Running the ECC R/3 from the Basis perspective, BAPI's were relatively easy for us BASIS Teams to work with and to control.

When I say control, what I mean is control the system resources and work load impact of the BAPI.

We really had a good view as to what the BAPI can do, how it can be executed, what's its limits are, what kind of maximum load it would put on the system, because actually, looking back, it was very limited as to what the BAPI could do, based upon the Import Parameters the BAPI ran a program and returned Export Parameters.

And now we fast forward to 2024, and we have the magic of ODATA API's.

There is no doubt ODATA API's are magical, what they can do is amazing, compared to BAPI's and RFC's they are a different generation.

Let's just look at the SAP S/4HANA standard Business Partner ODATA API:



This thing is amazing, it is huge, it is enormous, it enables:





of Master Data for Business Partner, across:



on the surface, it is fantastic. It is so powerful.

But, how is it powerful and what do I mean by powerful ?

I consider powerful to be its capabilities, what we can do with it, and I see the power of it when I compare to how limited we were when working with BAPI's and RFC's.

The power of the ODATA API_BUSINESS_PARTNER goes across a number of dimensions including:

Schema's, just look at the Data Schema's



and now the best part, remember, with BAPI's and RFC's we had Import Parameters and Export Parameters, that was it, and now, with the power of the ODATA API's, the One, the Person, the Application calling the ODATA API can do all of this in the call to the API:



The API Caller, calling the API End Point on the S/4HANA Digital Core is able to call this API, and perform actions from this rich list of actions:






this is amazing, compared to BAPI's and RFC's, this is a different world, the possibilities this creates for the caller of the API are fantastic, the caller of the API can now do much much more than simply calling some data.

Let's walk through an example and using the SAP documentation, let's imagine, we are the System Owner of a 3rd Party Application which depends on Business Partner Master Data from the S/4HANA Digital Core as the single source of truth.

As a 3rd Party Application, we have been provided with the S/4HANA API_BUSINESS_PARTNER Url End Point, and with a User and Certificate which can Authenticate all the way through to the S/4HANA and which has Authorisation on the S/4HANA to call the API and get the Data.

And on our 3rd Party Application, we find that we have a use case where we need Customer and Supplier Business Partner Data from the S/4HANA. 

In the "Try Out" section of the SAP API Hub, we are able to "self service" model the API call to the S/4HANA for the Data which we wish to replicate from the S/4HANA.

In the "Schema View" we can choose the data elements which we want to replicate, which we want to call from the S/4HANA, eg for Customer:



In the "Try Out" view we can then model the "Query" which we would like to perform when the S/4HANA is preparing the data for us, as described above, we have a rich set of options which we can include in the data preparation (Refer to the Specification OdataV2.pdf (




So, it can be seen there is a very rich set of Query options which can be used together when calling the ODATA API BUSINESS PARTNER on the S/4HANA, to enable the data which will be replicated to be prepared in the way which is the most useful for the API Caller.

And as I keep saying, this is amazing, and a huge step forward when compared to BAPI's and RFC's.

These capabilities are so rich, we are almost at the point where the API Caller can construct Analytics API calls and perform Analytical tasks on S/4HANA Data in the S/4HANA.


Unfortunately, however, as is often the case in life, too much of a good thing can be a bad thing.


As Queen sang in their song, Too Much Love, 



Unfortunately, it is the same for the S/4HANA Digital Core, too much of a good thing could kill it.

The ODATA API_BUSINESS_PARTNER worries me for two reasons:

a) what can be done with it is so rich

b) the calling System, once they have a User which has Authentication and Authorisation to call the API_BUSINESS_PARTNER on the S/4HANA, once they can do that, they are free to compose whatever Query of whatever Data is available in that API and which whatever complex combination or Selects, Expands, Filters, Orderby that they so wish.

These features are so rich, the capabilities are so rich, the Data preparation which an calling Application can do in the S/4HANA when calling an S/4HANA API are on the edge of being Analytical !

And the people Running and Operating the S/4HANA Digital Core have no control over that.

I am seeing performance implications of this in the S/4HANA.

And it is obvious, as the Complexity of the API call AND the Volume of Data being called, goes up, so the demand on the S/4HANA system resources will be higher, very simply it is like this:



When I see this, I am getting de ja vu, it reminds me of installing BI Java Portal for Bex Web back in 2008 and the End Users crashing the Portal because they were bringing so much data back from the BW,

SAP's answer at the time was the Bex Web Safety Belt, 1127156 - Safety belt: Result set is too large.



With the Safety Belt, we Basis Admins were able to protect the Bi Java Portal from crashing by putting in physical restrictions on the amount of data that End Users could bring back.

With the S/4HANA ODATA API_BUSINESS_PARTNER we don't have that, we Basis Admins cannot control how the calling System Administrators/Developers will use the API.


What can we do, what are SAP doing ?  I see some OSS Notes for other standard S/4HANA API's 


In these Notes SAP is giving guidelines on how to use the API's do's and don'ts, which helps, but it is not a catch all way of protecting the S/4HANA from API Callers unintentionally bringing down the S/4HANA because of how they are using the ODATA API's.



We are thinking about alternatives, what to do, how to ensure that API Callers cannot bring down the S/4HANA Digital Core ?

We could copy the API's and make Z versions with restricted capabilities, but that would not be 100% clean core compliant.

I see two fundamental long term options:

Safety Belt - either SAP bring in a "Safety Belt" feature like we had back in the day with the Bex Web. The safety belt will ensure, reliably, consistently, that an API Caller cannot call an API in such a way that it will over load the S/4HANA and bring down the S/4HANA

Enterprise Blockchain - or alternatively, we do what I was advocating over here, we say no to the S/4HANA Digital Core being an End Point for 3rd Party Applications API calls, and in cases where S/4HANA Data needs to be replicated to other system we Ring Fence the S/4HANA with an Enterprise Blockchain and replicate S/4HANA Data to the Enterprise Blockchain and let 3rd Party Applications read the Data from the Enterprise Blockchain. This succeeds to stop 3rd Party Applications calling API End Points on the S/4HANA, therefore increased Cyber Security, and at the same time means that 3rd Party Applications cannot over load the S/4HANA, and enables the Enterprise Blockchain to become the common single shared source of truth across the Organisation and Organisations.

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth


What do you think ? What's your solution ?

Until next time,

Andy Silvey.

Independent SAP Technical Architect and CEO of

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto  inc, an startup whose ambition is to make Blockchain easy for Enterprise.'s flagship product is the atkrypto Enterprise Blockchain Platform for SAP,  and is a SAP Partner Edge Open EcoSystem Partner. 

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups  being featured at TM Forum's DTW Ignite in Copenhagen in June 

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.




Labels in this area