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 can look like the following:
- Sample Response
A sample SOAP response can look like the following:
Event-Driven Architecture
What are events?
From a technical perspective, an event is a small message that provides information about a 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 can 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 to 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 can 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 can 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 been changed. The event consumer can then process the dataset.
Summary
There are two types of operating the 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.