In Part 1 of our series, we introduced you to the core concepts behind SAP Event Mesh and how event-driven architecture enables modern, decoupled systems. In this part, we will explore two important event types: Notification Events and Data Events, and how they function within SAP systems.
Before we dive into the specifics, let’s briefly define the key players in an event-driven architecture: event producer, event broker, and event consumer.
Key Concepts in Event-Driven Architecture
-
Event Producer: An event producer is a system or component that detects or triggers significant changes, such as the creation of a new sales order, an employee hiring, or an update to an inventory. This system sends out an event to notify other systems that the change has occurred. For example, an SAP S/4HANA system might be the event producer when a new sales order is created.
-
Event Consumer: The event consumer is the system or application that subscribes to and processes events. This could be an SAP or third-party system that reacts to events such as a SalesOrder.Created or a new employee hire. The consumer can either take immediate action based on the event data or request more information if needed.
-
Event Broker: The event broker is the intermediary responsible for managing events. It ensures that events sent by producers are routed to the appropriate consumers. Event brokers handle the distribution, delivery, and monitoring of events, ensuring that consumers receive the right notifications or data at the right time. SAP Event Mesh itself acts as an event broker in SAP systems, decoupling producers from consumers for scalable and flexible communication.
Event Types: Notification Events vs. Data Events
Now that we understand the roles of event producers, brokers, and consumers, let’s look at the two primary event types used in event-driven architectures: Notification Events and Data Events.
Notification Events
Notification events inform consumers about significant changes in the system, but only include minimal data. The goal is to notify the consumer about an event, and if the event is relevant, the consumer can request more information or trigger additional actions. Notification events are especially useful when the consumer doesn’t always need the full details of an event immediately.
How Notification Events Work
In an SAP system, let’s say a new Sales Order is created. The event producer (the SAP S/4HANA system) sends a SalesOrder.Created notification event. This event is small and only contains the Sales Order ID and a link for further details. The consumer, upon receiving the notification, can decide whether to fetch more details or ignore it if it’s not relevant.
The event is sent through the event broker (SAP Event Mesh), which manages subscriptions and makes sure the notification reaches all relevant consumers.
Figure 2.1 shows an example notification event for the creation of a sales order in an SAP S/4HANA backend system. The notification event is of type SalesOrder.Created and contains only minimal data, namely the ID of the sales order that was created.
Figure 2.1: SalesOrder.Created Notification Event
Advantages of Notification Events
- Minimal Data Transmission: Since only essential information (like an ID or link) is sent, notification events are lightweight, reducing system load and data transfer costs.
- Controlled Data Access: Only the essential data is included in the event. If more data is needed, the consumer must explicitly request it, ensuring greater control over sensitive data.
- Efficient for Low Follow-Up: If most events don’t require follow-up, notification events are highly efficient. Consumers only fetch details when absolutely necessary, minimizing resource use.
Disadvantages of Notification Events
- Extra Request Overhead: If follow-up is needed for most events, notification events introduce the additional overhead of API calls or data queries, making the system potentially less efficient.
- May Not Be Useful in All Cases: For scenarios where most events require immediate action, the consumer has to request further data, which adds complexity.
Data Events
Data events, in contrast to notification events, include all relevant information about the change directly within the event. This means the consumer can process the event immediately without needing to make any further requests. While this makes data events more powerful, it also means they are larger and can incur higher costs in terms of resources and data security.
How Data Events Work
Let’s consider an SAP SuccessFactors scenario, where a new employee is hired. The Employment.AssignmentInformation.Hire event contains all relevant details—like the employee’s start date, sequence number, and user ID. This allows the consumer to begin processing immediately, without querying for more data.
Data events are sent through the event broker, which distributes them to all relevant consumers subscribed to this type of event.
Figure 2.2 shows an example data event for an employee hire in an SAP SuccessFactors backend system. The event is an SAP SuccessFactors Intelligent Services event and is of type Employment.AssignmentInformation.Hire. You can see that the event holds more information, for example, the effective start date of the hired employee and a sequence number on top of the user ID. This event is actually a very small data event. Data events can be a lot bigger if needed. SAP SuccessFactors Intelligent Services events currently don’t follow the CloudEvents standard.
Figure 2.2: Employment.AssignmentInformation.Hire Data Event
Advantages of Data Events
- Immediate Processing: Since the event contains all necessary data, consumers can act immediately. This saves the time and resources that would otherwise be spent querying the producer for additional information.
- Comprehensive Data for Use Cases: Data events are ideal when most events require detailed information. For example, in HR systems where every hiring event needs full data for onboarding processes.
Disadvantages of Data Events
- Larger Data Load: Data events can be quite large, leading to higher costs for event brokers to transport and store these events.
- Less Control Over Data: Since the entire data payload is sent within the event, it becomes harder to control who has access to potentially sensitive information.
- Inefficiency for Unused Events: If the consumer is not interested in a majority of the events, the system becomes inefficient, as large datasets are processed unnecessarily.
When to Use Notification Events vs. Data Events
The decision to use notification events or data events depends on the specific needs of your system. Here are some guidelines:
- Use Notification Events when you only need to inform consumers about a change, and they can decide whether or not to retrieve more details. This approach works well in systems where not all events require immediate action.
- Use Data Events when most events will need to be processed immediately, and when it’s more efficient to send all relevant data upfront. This is useful for high-frequency systems where requesting additional data for every event would introduce too much overhead.
What’s Next?
In Part 3, we will explore CloudEvents and event standardization, helping you navigate how to further optimize your SAP systems for event-driven architecture. We’ll discuss how to ensure that your events conform to best practices and are easily consumed by diverse systems.
Stay tuned for more insights into SAP Event Mesh and Event-Driven Architecture!
Credits:
This blog draws heavily on resources from SAP Press, with special thanks for their in-depth insights and comprehensive coverage of SAP Event Mesh in event-driven architecture.