In this lesson, the following topics are discussed:
- Request Driven Architecture
- Event Driven Architecture
- Combination of request-driven and event-based architecture
What is a Request Driven Architecture?
A request-driven architecture is based on direct communication between a service provider and a service consumer. This communication is synchronous.
- Sample Request
A sample SOAP request may look like the following:
- Sample Response
A sample SOAP response may look like the following:
Event Driven Architecture
What are Events?
From a technical perspective, an event is a small message that provides information about an business occurrence. An event could be, for example, the creation of an order in an SAP S/4HANA system. The event is fired via push (asynchronously) to a broker.
An event may look like the following:
Event Producer at SAP
SAP offers the Event Enablement add-on in ECC and SAP S/4HANA (Cloud and On-Premise) to support you.
What is an event Driven Architecture?
The event-driven architecture (EDA) is a software design pattern in which decoupled applications can publish and subscribe asynchronously events via an event broker. An event broker is a modern message-oriented middleware, for example, Service Mesh at SAP.
Read more here: What Is EDA (Event-Driven Architecture)?
Pull Variant
The event provider (No.1) fires an event (No. 2) with a designation called Topic (No. 3). A topic would be, for example, BusinessPartner_Changed. This is an asynchronous communication. The topic is subscribed to by a queue (subscribe to topic). In this case, from queue A (No. 4). The message can now be actively picked up by the event consumer (No. 5). For this purpose, the Event Mesh provides an API. The communication comes from the event consumer, triggered by a pull on the queue. This is a synchronous communication.
Push Variant
The event Provider (No. 1) fires an event (No. 2) with a designation called Topic (No. 3). A topic would be, for example, BusinessPartner_Changed. This is an asynchronous communication. The topic is subscribed to by a queue (subscribe to topic). In this case, from queue B (No. 4). A webhook is now assigned to this queue. (No. 5). If an event with a topic arrives in the corresponding queue, the webhook is called up and the event is sent directly to the event consumer (No. 6) via push. The communication comes from the Event Mesh, triggered by an incoming event. This is also an asynchronous communication.
What are Webhooks?
A webhook is an HTTP callback: an HTTP POST that occurs when a change in state is made, that is, an event notification via HTTP POST. Webhooks are used for real-time notifications, so that your system can be updated directly at the time of the event. Basically, a webhook is a simple URL, which you can also call up regularly in the browser. In the context of the SAP Service Mesh, the webhook URL is used when subscribing. This allows the service to know where to send the message with the subscribed topic.
In combination with the event Mesh, a webhook URL is included in the subscription of a topic to a queue.
Combination of request-driven and event-based architecture
In reality, classic requests and events are combined.
No. 1 to No. 6 works as described in a previous section, but what is new is that the event consumer (No. 7) submits a request to the event producer (No. 1), for example, to read the product data that has just been changed. The event consumer can then process the data set.
Summary
There are two types of operating API first approach. The one, request driven, is based on synchronous communication of the partners involved. The second, event driven, works asynchronously and decouples the transmitter from the receiver in terms of time and content. This loose coupling offers many advantages. Both types are often used one after the other.