Event Driven Architecture (a teaser)

Olaya Dayalı Mimari nedir ve bu mimariyi nasıl kullanıyoruz?(kısa anlatım)

What is Event Driven Architecture and how do we use it? (a teaser first)

ERP (misal S/4HANA) Sisteminizde bir değişiklik yaptınız, örneğin bir müşteri bilgisi değiştirdiniz, yeni bir sipariş açtınız, yeni bir fatura kestiniz.. Sizin sisteminize bağlı devam edecek başka servisler ve sistemler de bu bilgilere göre farklı bir takım işlemler gerçekleştirecek. (Örneğin onlar da kendi müşteri bilgisini güncelleyecek, sipariş başka bir ya da birkaç tedarikçiye geçilecek vs.). Operasyonel ve teknik olarak hergün çokça yapılan işlemler değil mi? Ama sistemi bloklamadan, ölçeklenebilir ve daha esnek şekilde yapılmasının yolları var. Nasıl mı? “Event Driven Architecture(kısaca EDA) Bu kısımda çözümden/yazılım-vendor’dan bağımsız bir anlatım yapıyoruz. Sonraki kısımlarda bunu #SAP #BTP üzerinde nasıl gerçekleştireceğimize de değineceğiz.. Sadece giriş Türkçe maalesef, “Article in English”

Imagine a scenario where you have done some data changes (creation of an order, update of account information, new invoice, .. ) in your source systems(i.e S/4HANA) and want some target systems to respond to or act with the change. Pretty familiar isn’t it? Looks like it happens every day in your business. But this time without blocking the process, in a flexible and scalable approach .. How? With Event Driven Architecture (a.k.a EDA) .. Brief introduction to EDA .. In this article solution/vendor agnostic. But in the following articles we’ll discuss about how we’re going to implement these scenarios in SAP’s #Cloud based Event Driven Solution in #SAP #BTP environment.

#eventdrivenarchitecture #eventbaseddesign #integration #sapcloud #sapintegration #fyir #saparchitecture #integrationarchitecture #sapbtp

 What is the deal with Event Driven Architecture then..

Obviously, our story above requires integration, but the integration architecture and the method & tools you use means a lot when number of transactions & number systems to integrate gets bigger. In the meantime you have to be elastic to integrate with possible future systems, with new types of data.

In today’s world of connected systems & APIs, no system has the luxury to block or wait for another system.

This is where Event Driven Architecture and fire-and-forget strategy comes into the stage. You basicly want to let the world know that something has happened and go to your next job and it’s their job to determine “when”, “how” and “what” to respond.

In the first part lets start with the basics / simple scenario(s): 

What is an event - Why do we need events?

An event is a change of state.  Then the world is notified about this change (the details depends on the scenario and what you want to expose)

What are the types of events

·     Notification Events – In this type of event, source system triggers a notification which indicates data change and the target system which is interested in this change, will then invoke a API call to get the complete set of data from source system. For instance when you update a BusinessPartner/Customer Data, only the ID of the Customer is sent with the event.

·     Data Events – In this type of event, source system publishes the complete (or enriched) data set of the business entity which has changed which is used by the target system. Therefore the payload and information provided is more than the notification event. In this case, when you update the BusinessPartner/Customer data, you are sending the complete Customer information not only the ID. The definition of complete information depends on what you want to do (it might be only the changed data, or Customer with all sub domain information you have decided)

When should you consider using event-driven architecture

To fan out a single event to multiple consumers. The event publisher pushes the event to all the appropriate consumers, without you having to write customized code. Each service can then process the event in parallel, yet differently. It’s the target systems’ responsibility to decide what to do with the event-data.

To provide interoperability between different technology stacks while maintainingthe independence of each stack. As a publisher you don’t need/want to know about the consumption details of the target systems. (How they pull the data, which API, which programming language they are using). Publisher only notifies the subscribers with the event-data.

 To monitor systems and receive alerts about anomalies or changes to system components, tables, virtual machines, or other resources.  Once the events (in this case alerts) happened, multiple systems can be notified. They can determine the severity-urgency of these alerts are further notification steps.

 When you “DONT” want your system to be blocked while others are responding to the event-data change. Asynchronous eventing and resiliency is another advantage in an event-driven system because events are generated asynchronously, and can be issued as they happen without waiting for a response. Loosely coupled components means that if one service fails to respond, the others are unaffected. If necessary, you can log events so that the receiving service can resume from the point of failure, or replay past events.

 Push-based messaging, real-time event streams, and lower costs. Event-driven systems allow for easy push-based messaging and clients can receive updates without needing to continuously poll remote (in this case your systems’) services for state changes. These pushed messages can be used for on-the-fly data. This means they are not asking each time, you’re notifying them when it’s happened.

If we want to give an example of a simple scenario let's say;

• You have created an order in your ERP system (might be S/4HANA)

As a result

• You want your Logistics Provider to start transporting order items from its warehouse. (might be a non-SAP system which has a SOAP based web service to be called which is possibly blocking your integration)
• You want invoicing to happen with this trigger (previously this system was polling your ERP in 10 minute intervals)
• You also want your B2B Partner to be notified that the order is created. (had a REST based API to be called once order is created)

·      All these 3 parties were polling your systems for new items or blocking your integration-process because you’re expecting a response(if designed in this way)

With the EDA based design

• You can create different queues for your target systems that are expecting the data.

Then,  your Logistics Provider listens to a queue for Queue-OrderCreated_ForMYLOGISTICSPROVIDER and gets the related order information whenever required (it doesn’t have to be when it’s created)

Invoicing partner gets the information from queue Queue-OrderCreated_ForMYINVOICINGPARTNER with necessary invoice-customer information.

B2B Partner will get the information from Queue-OrderCreated_FORMYB2BPARTNER which is specific to your B2BPartners.

The good news is you can publish the same information at once to different multiple-queues. But you also have the option for breaking down to different categories for the receivers (via for instance regions, segments, business categories.

In fact any structure that you want to design) ..

This is realized via the concept called topics: For instance you can publish premium orders to selected logistics providers which means you can create queues for those and publish to only these queues which are specific to these providers.  Or you can publish the same order to multiple logistics providers and let them respond with best offer from your another application of yours.. Number of scenarios are limitless..

This was only an quick introduction, in fact a “teaser” to the one of the latest approaches to integration world. The “movie” has different “parts” .. We only discuss about the publishing side of the story. What about the subscribing side? How events are published? How topics/queues are designed so that every receiver will get correct/necessary information? What about the problems/errors? How about iOT - high volume scnearios etc.. Coming soon.. 

.. I will be giving details about them in the following articles ..