From point-to-point integration to event-driven integration: a logistics example

In many enterprise integration scenarios, interfaces are still built as fairly linear processing chains. A sender transmits data to one receiving endpoint, the payload is processed in an integration layer, and then forwarded to a backend system. That model is well understood, reliable, and often completely sufficient.

The current architecture shown here builds on the logistics scenario from my previous blog on SAP PI-to-SAP CI migration. I’m reusing that example because it offers a practical baseline for discussing how the same interface could evolve into an event-driven design.

A typical logistics-related example looks like this:

External sender → service layer → SAP Cloud Integration → SAP backend

This kind of flow works well when the message has one clear destination and one main processing path. But once the same business information becomes relevant for multiple systems, a different architectural question appears: should the sender really push the same business fact through one central point-to-point route, or should the fact be published once and consumed by whoever needs it?

That is exactly where event-driven integration and concepts such as Event Mesh become interesting.

The current integration view

Let’s use that shipping-notification scenario as an example. A logistics platform sends shipping-related information through a service layer. The data is then processed in SAP Cloud Integration, mapped into the expected target structure, and forwarded to an SAP backend such as AFS.

From a technical perspective, this is a classic integration path:

• one sender
• one main route
• one integration layer
• one backend handover

That design is perfectly valid. But it is also tightly centered around the assumption that the information exists mainly to reach one downstream target.

What changes when we think in events?

In an event-driven model, the same business fact would be described differently.

Instead of saying:

“Send this payload to SAP CI so it can be forwarded to AFS,”

we would say:

“A shipping event has occurred. Publish it.”

The business fact itself becomes the central element. A shipping update, parcel status change, tracking notification, or shipping confirmation is treated as an event — something that happened in the business domain and may be relevant to more than one consumer.

The basic event-driven roles

This is where a few core concepts matter.

Event

An event is a business-relevant occurrence, for example:

• shipment created
• shipment closed
• parcel updated
• tracking event received

The event is not primarily a technical request. It represents a fact.

Producer

A producer is the system that publishes the event.

In the logistics example, that could be:

• the logistics platform itself
• or a service layer that exposes and republishes the event

Subscriber

A subscriber is any system that consumes the event because it is interested in it.

Possible subscribers could be:

• SAP CI for backend integration
• a tracking portal
• a parcel platform
• analytics or monitoring services
• notification services

Event broker

An event broker is the technical intermediary that receives published events and distributes them to subscribers.

Event Mesh

An Event Mesh extends this idea across distributed landscapes and allows producers and consumers to be decoupled from each other while still exchanging events in a controlled way.

Event-driven architecture is not tied to one specific product. While SAP Event Mesh is one relevant option in an SAP-centered landscape, the underlying pattern can also be implemented with other technologies such as Apache Kafka, Azure Event Grid, Azure Service Bus, AWS EventBridge, or similar event-broker platforms. The core idea remains the same: producers publish events, brokers distribute them, and subscribers consume them independently. The architectural value lies in the decoupled event model, not in one specific vendor product.

How the logistics scenario could look in an event-driven model

Today, the flow is roughly:

Centiro → Service Layer → SAP CI → SAP AFS

In an event-driven target picture, the same scenario could be thought of more like this:

Producer publishes shipping event → Event Broker / Event Mesh distributes it → SAP CI subscribes and maps it for AFS

And SAP CI would not necessarily be the only subscriber.

At that point, the architecture becomes more flexible. The same event could also be consumed by:

• parcel platforms
• tracking applications
• monitoring services
• reporting or analytics solutions

That reduces the need to duplicate integration logic every time a new consumer needs the same business fact.

What SAP CI would still do

Event-driven architecture does not mean SAP CI becomes irrelevant. On the contrary, SAP CI still has an important role.

In a scenario like this, SAP CI could act as:

• an event subscriber
• a validation layer
• a mapping layer
• a backend handover layer

For example, SAP CI could subscribe to shipping-related events, transform them into the required IDoc structure, and then hand them over to SAP AFS exactly as it does today.

The difference is not that SAP CI disappears. The difference is that SAP CI would no longer need to be the only central path through which the business fact is forced to travel.

Why this matters architecturally

The main advantage of this model is decoupling.

In the current point-to-point pattern, the sender and the downstream integration path are relatively closely tied together. In an event-driven pattern:

• the producer publishes once
• subscribers consume independently
• new consumers can often be added with less impact on the original producer

That is especially attractive for logistics-related information, because shipping and tracking events often have more than one business audience.

Final thought

Not every existing interface needs to be rewritten as an event-driven solution. In many cases, a conventional SAP CI interface is still the right and simplest answer. But shipping notifications and similar logistics events are strong candidates for event-driven thinking, because they naturally describe business events that multiple systems may want to consume.

That is why this kind of scenario is a useful way to explain events, producers, subscribers, and event brokers. It shows that event-driven architecture is not just a new technology label. It is a different way of looking at the same business fact: not as a request that must travel along one fixed path, but as an event that can be published once and consumed where needed.