In this short blog, I’ll cover an extensibility scenario for SAP S/4HANA Cloud (S/4HC) and SAP Business Technology Platform (BTP) Cloud Integration that is not typically thought of as a normal integration pattern. Essentially, this integration scenario is S/4HC integrating with itself to replicate what would traditionally be done in the SAP ERP system and scheduled as a batch job. By leveraging white listed APIs and Custom Business Objects (CBOs) in SAP S/4HC, a developer can quickly create a robust iFlow and schedule to run at periodic intervals.
S/4HC customers often have these requirements to execute jobs at certain frequencies to perform calculations and create additional postings/documents in the SAP S/4HC system. For example, you may want to poll all projects in the system and based on the work package information add an additional burden to the project. Or you may want fetch some accounting documents and based on certain values post a subsequent journal entry.
These programs are not part of standard jobs in S/4HC and customers will often explore using side by side extensibility on SAP BTP to fulfill the requirement. This entails building an app with a UI, configuring security, calling APIs, etc. However, if the customer is already using SAP BTP Cloud Integration for their integrations, has a Cloud Integration developer and a UI is not required (or even a nice to have), it can be much faster to develop an integration flow (iFlow) on BTP to meet the requirements for the batch job.
There are several advantages to using BTP Cloud Integration. The iFlow can leverage the Timer start event for scheduling the program execution. If needed, you can customize the scheduler start using Groovy Script to handle custom start requirements (for example, the first Monday of the month).
In addition, it is easy to quickly chain API calls together and implement calculation/transformation logic based on the data returned in the calls. And because no UI is required, the development time is significantly less than a full BTP application due to decreased complexity.
For program execution, the iFlow can use externalized parameters on the iFlow (which does require a redeployment on every change) or if the requirement is more dynamic / complex, you can leverage a Custom Business Object (CBO) in S/4HC to hold configuration information that is required during program execution. You could even set up the integration so that it is triggered by an email with the necessary runtime parameters by authorized users.
An example iFlow in this pattern might be:
- Fetch all customer projects created/changed since last program execution from the standard whitelisted OData API
- Split the payload returned in #1 and process each record individually
- For each project:
- Call a CBO in S/4HC for some additional data required to perform calculations
- Call a custom CDS view API for the costs already allocated to the project
- Calculate the amount billed to date, use the data from #2 and then post a journal entry to S/4HC using the whitelisted SOAP API
- Email a report (or email any errors) to the power user
I hope this blog shows just one of many ways that SAP BTP Cloud Integration can be used outside of the traditional system to system integration patterns.