Why Do We Need an Event-Driven Architecture?
In my previous four-part SAP integration blog series, I showed how a custom C#/.NET application can be connected to SAP using RAP and OData V4. The series began with the post Modern SAP Integration with External Applications and continued through to Verification on the SAP Gateway Side in the final installment. The main lesson was that a working endpoint does not, by itself, mean reliable integration: business responsibilities, system boundaries, and error handling must also be designed.
Now we are taking the next step. What happens when an external application does more than store or retrieve data, continuously detecting changes, some of which require an immediate response? How does a technical alert become an incident that the local system can respond to, while the entire process remains traceable in SAP? This is what we will explore in a new three-part series.
A Measurement Alone Is Not an Incident
Imagine a refrigerated warehouse where sensors measure temperature. A new reading may arrive every second: 20,1 °C, 20,2 °C, then 20,8 °C. Just because a value has changed does not necessarily mean that business intervention is required. What matters is that the system can recognize when a deviation becomes persistent, dangerous, or relevant under a business rule.
- Telemetry: the continuous collection of measured values and device states.
- Monitoring: interpreting those values, tracking thresholds and trends, and identifying anomalies.
- Incident management: assigning a responsible process, state, action, and resolution criteria to a relevant deviation.
For example, a brief temperature fluctuation should not automatically create a new incident. If, however, the deviation persists for a defined period, the system may move into Warning and then Critical status. This is a business event that can trigger a local signal, an intervention, and an SAP-side record. The enterprise system therefore receives important state changes rather than thousands of individual measurements.
Why Is Request–Response Not Enough for Everything?
Traditional API communication works well when a system expects a specific answer to a specific request. For example, the C# backend can create an incident in SAP through an OData API, change its status, or retrieve its details. This remains an important part of our solution.
However, an HTTP response primarily reports the result of the request; it does not prove that every downstream system has already processed the change. If multiple applications must respond to the same incident, continuous polling can generate unnecessary traffic, while direct calls between systems create tight dependencies. A temporarily unavailable consumer can then easily slow down the entire process.
An event-driven architecture asks a different question: not what the current state is, but what significant state change has occurred. An event, such as IncidentCreated or IncidentSeverityChanged, is a signal to consumers, not the synchronous execution of an entire business process. APIs and events therefore complement each other: we use the former to query state or initiate an operation, and the latter to notify other systems of a change that has already occurred.
An important limitation: making a solution asynchronous does not automatically make it faster, more secure, or more reliable. If a simple operation requires an immediate response and strong consistency, a synchronous API is often still the right choice.
Which System Is Responsible for What?
In our example project, we plan three clearly separated areas of responsibility. The C#/.NET backend evaluates sensor data locally and makes rapid automation decisions. If it detects a critical deviation, it cannot wait for a remote enterprise service to respond: it must handle local signaling and an appropriately designed local response independently.
SAP is responsible not for storing every raw sensor reading, but for managing incident states that have business meaning: what happened at which site, how severe it was, which actions were initiated, and when the incident was resolved. A RAP-based business object and an OData API provide a controlled entry point for this purpose. An SAP RAP Business Event can signal a relevant business change that has occurred in SAP; SAP Event Mesh, acting as an intermediary for asynchronous messaging, helps consumers avoid direct dependencies on the incident creator.
The planned process can therefore be summarized as follows: the C# application detects the deviation locally, creates or updates the incident in SAP through OData, and the resulting SAP business state change can then reach subscribed consumers as an event through Event Mesh. The event may contain an identifier and basic context; if necessary, consumers can still retrieve the detailed current state through an API.
An Incident Is More Than a Single Alert
In a well-designed incident management process, creation is only the beginning. In our example, Normal represents regular operation without an active incident. Warning marks the first relevant deviation; Critical indicates that the situation has become more severe. During Mitigating, the system performs a specific risk-reduction action, while Recovering indicates that the measured state is returning to the permitted range. An incident can be marked Resolved only when the defined closure criteria have also been met.
It is particularly important here to distinguish a temporary improvement from actual recovery. If a value drops below the threshold for a few seconds and then rises again, the system should not open and close dozens of incidents in succession. Time-based rules, separate entry and exit thresholds (hysteresis), and unique incident identifiers help establish a stable state model.
Potential Pitfalls Must Be Considered During Design
Too Many or Poorly Defined Events. If we publish every measurement sample as a business event, both consumers and troubleshooting may become overloaded. Only meaningful state transitions should be turned into events. Noise filtering and threshold logic are part of local processing.
Late, Duplicate, or Lost Messages. With asynchronous delivery, we must not assume that every event arrives exactly once or in the expected order. Durable queues, retries with backoff, isolation of failed messages, and idempotent consumers are needed. An event ID or incident ID helps prevent the same operation from being executed twice.
Temporary Differences Between Systems. An incident may already be Critical in SAP while a consumer still displays the earlier Warning state. This can be a natural consequence of eventual consistency. State versions, timestamps, API-based verification when needed, and clearly designating SAP as the source of truth can help manage it.
Difficult-to-Trace Error Flows. With a synchronous request, it is easier to follow the call chain; with events, logs from several independent components must be correlated. A shared correlation ID, structured logging, processing statuses, and queue monitoring are worth introducing from the first version.
Security Misconceptions. Authentication verifies who the caller is. Authorization determines what the caller is allowed to do. CSRF protection is a separate security mechanism that may be required for modifying requests on the SAP/OData interface in use. API access, event subscriptions, and technical credentials must be treated as separate authorization boundaries.
Dependence on Central Service Availability. If SAP or the message broker is temporarily unavailable, local detection must not stop. The local response, reliable delayed delivery, and subsequent reconciliation are separate responsibilities.
What Is the Business Value?
The end result is more than just another notification. A well-modeled SAP incident makes it possible to trace where and when a problem occurred, what caused it, how severe it became, which intervention took place, whether it succeeded, and how long it took to restore normal operations. This allows us to measure not only the number of alerts but also response and recovery times, as well as patterns of recurring failures.
This information has business value: it supports operational decisions, the prevention of recurring problems, and the design of auditable processes. The real advantage of an event-driven approach is not message delivery itself, but the controlled availability of business-relevant changes for processing by multiple systems.
Where Do We Go from Here?
In this first part, we have seen why measurements, monitoring, and incident management must be distinguished, and how APIs and events work together. In the next post, we will build the technical integration: RAP Business Event, Event Binding, SAP Event Mesh, topics, queues, and a C# event consumer. In the third part, we will follow a simulated warehouse scenario from the sensor signal through physical status indication to an incident that is closed and traceable in SAP.
Technical References
SAP Help – Business Events for Process Integrations
