Event Driven Architecture has been here long time. With SAP Backend solutions this has not been the way how integrations have been built – until lately.
In integration projects, typically development can be start when business process and application development is almost done. Its understandable since processes has to be defined and trigger points in ones defined. Also you need data for integration testing. What if this would not have to be so? What if you could start doing integrations without waiting apps to be ready?
With Events, those trigger points are almost certainly known when processes are defined. At least you know which kind of data objects is created in process and then you can search events to be triggered to Cloud. This is a huge benefit in integration development.
To start with events, you can set tracing on in SAP ECC/S4 to see which kind of events are created in system. You can use api.sap.com site to see what is offered there. There are many kind of event trigger mechanisms like BOR, Classes, Change Pointers, Change Documents and such. If no events found, you can use simple BAdI’s for triggering business object Id to be used for fetching data. SAP has standard Function Module to trigger events which makes development easy – almost copy paste coding.
Another topic in projects are how you do initial loads to receivers?
Events can help in this too. If you use Notification Events, only thing you need to do is to build separate mass-load integration process to fetch ONLY data identifiers you need (small amount of data) and then create events with this data. Benefit is, you can use separate massload processes for event creations and another event process handles enrichments and sending data to receivers. Markable benefit I would say.
Data from Backend – Push or Pull?
With Push type of integrations (asynchronous from backend), updating interfaces is time-consuming task. It requires changes to be sent to test and finally production via transport request management. Almost always, it requires abap developer.
It will be much faster to implement GET based queries to SAP using OData interface instead trying to have all fields in interface at once and push them forward to receiver. If connection is broken, with events they just wait in queue or you can easily trigger them forward.
One another thing to consider is that if you use (and most probably you use) Fiori apps, those consume and handle data mostly via OData interfaces. With co-operating with Fiori developers, you may get Odata interfaces ready also for integrations with almost same work amount.
Biggest impact for integration developers is to learn designing integrations differently than you did with SAP Process Integration/Orchestration.
If you want to go with Odata and Events, you might want Data Architects to cover all the data objects so that developers don’t implement same functionality multiple times (for Fiori, integrations etc).
If you choose to use Event solutions like Kafka, you can use Event Store to save events and maybe use ones to simulate event streaming and start from the timestamp you want. Really useful if you need to send data again for receivers or you will have new receivers which need data from some timestamp forward. If you go full event based, publish/subscribe architecture, then Kafka can be the one where consumers and publishers connects. No more problems when your backend is down for maintenance.
Finally
Event integrations offers lot of interesting opportunities for testing. If you store even event identifiers, you can reuse ones for testing (assuming data for objects like purchase orders, vendors, gl-accounts etc is not changing). If that can change, you can always start using data events which contains full data of business object.
Event mesh is natural way of handling data and building integrations. When something happens, it will be informed and the ones interesting this data will consume data and add some one flavours into it. As in real world, you don’t want to receive data (like email spam) you don’t need. Just sign in and let ones know what is the thing your are interested of. Basically working with events is just that simple. What you do with the triggering info is always up-to you.
