Cloud Platform Integration Role in the Event-Driven Integration with CAP and Open Connectors

It’s time for another part of the blog series “Expose your data in a fast and reliable way in real time with SAP BTP” in which I’m going to put some light on the CPI part of the solution architecture presented below.

Figure 1 – Solution architecture

As you can guess, the CPI plays one of the major roles in our scenario. As it usually happens with the integration solution, it stays in the middle, securely connects, enriches, maps and exchanges messages between all the applications and landscapes involved in the process. This includes on-premise S/4 HANA instance as well as the CAP application deployed on the Cloud Foundry, which as we are trying to emphasize with this series of blogs, is full of very useful APIs and therefore significantly extends integration possibilities.

Integration Flows

There are two integration flows created in the CPI to support the communication in our small project. Both are exposed via unique endpoints to which Event Mesh can send messages e.g. notifying CPI of the particular S/4 HANA event. Of course by definition we treat event as a significant change in state, which indicates that something happened in the source application, in our case it?s either the new sales order created in the S/4 HANA system or the following step being successful save of the sales order in the Cloud Foundry HANA database. Naturally we are not limited to sales orders only, practically any object in the system, once it is configured, can trigger event and therefore initialize data exposure via scenario designed in the similar way to the one we describe here. Thanks to event-based design we also do not have to frequently check whether the object of our interest has been created, instead we will be automatically, in real time, notified when it happens.

One of the main tasks of the first integration flow, once “sales order created” event is received, is to reach to the S/4 HANA environment via OData service and get all the additional information we want to expose to further applications deployed on the Cloud Foundry. As you can see on the diagram below, information collected via OData is then used to enrich the initial event based message that came from the Event Mesh.

Figure 2 – Message enrichment via OData

In this way we can set the content of the initial event-based message to minimum, in practice the ID of the created object and sometimes also a timestamp are enough. Due to a queue/topic subscription concept of the Event Mesh (figure 3), multiple iFlows can utilize the same message and perform any additional enrichments of different levels and complexity. To simplify data derivations of our OData service, we decided to build it on the basis of a custom CDS. View created to return only the data that we wanted to expose from S/4.

Figure 3 – Event Mesh – Queue/Topic concept

Second integration flow also works on the event based communication, this time however it is not SAP notifying CPI via Event Mesh but the CAP application deployed on the Cloud Foundry. The goal here was to close the loop and notify CPI that the initial object created in S/4 HANA was successfully passed to our custom CAP application, saved there in the HANA Cloud Database and that it is now ready to be further distributed via Open Connectors.

Please notice that both integration flows handle also all the additional and required message transformations, structure and value mappings as well as all the necessary technical adjustments. After all, we have to make sure that whatever is coming from the event raising side will be correctly recognized and processed by the receiving party.