From point-to-point integration to event-driven integration: building a practical SAP Event Mesh PoC

In a previous article, I explored how a traditional point-to-point integration can be redesigned using an event-driven architecture approach based on a logistics shipping-notification scenario.

This article continues that discussion by focusing on the practical implementation side.

Instead of discussing event-driven architecture only conceptually, this proof of concept (PoC) demonstrates how SAP Event Mesh and SAP Cloud Integration (CPI) can be used together to redesign an existing integration flow while preserving the existing backend integration logic.

The goal was simple:

Replace direct sender-to-CPI communication with asynchronous event-based messaging.

Original integration flow

The original integration scenario followed a traditional point-to-point design:

Sender System
↓
SAP Cloud Integration
↓
Mapping / Validation
↓
SAP AFS

In this model, the sender system communicated directly with CPI.

While technically straightforward, this architecture creates several common enterprise integration limitations:

• tight coupling between systems
• limited scalability
• difficult extension for additional consumers
• dependency on CPI availability
• reduced flexibility for future integrations

The objective of the PoC was not to redesign the backend integration logic itself.

The objective was to redesign the communication model.

Introducing SAP Event Mesh

Instead of sending data directly to CPI, the producer now publishes a business event to SAP Event Mesh.

The redesigned architecture became:

Producer
↓
Publish to Topic Address
↓
SAP Event Mesh
↓
Queue Subscription
↓
Queue
↓
SAP CPI Consumer
↓
SAP AFS

For the PoC, Postman was used to simulate the external logistics sender.

The producer published events to the following topic address:

logistics/shipping/notification/created/v1

This topic address represents the business event category:

A shipping notification was created.

Topics, subscriptions, and queues

One of the most important concepts in event-driven integration is understanding the relationship between topics, topic subscriptions, and queues.

Topic address

The topic address defines the event category:

logistics/shipping/notification/created/v1

The producer publishes messages to this address.

The topic itself is not a queue and does not directly store messages.

Queue

The queue used in the PoC was:

Q_CENTIRO_SHIPPING_NOTIFICATION_POC

The queue acts as the storage layer for events until a consumer processes them.

This enables:

• asynchronous processing
• buffering
• retries
• temporary consumer downtime without message loss

Topic subscription

The queue subscribed to the topic address through a topic subscription:

logistics/shipping/notification/created/v1

This means:

Every message published to this topic address is copied into the queue.

The producer does not know the queue directly.

The producer only publishes an event.

SAP Event Mesh handles the routing automatically.

This is a fundamental difference compared to traditional point-to-point integration.

SAP Cloud Integration as asynchronous consumer

On the consumer side, SAP Cloud Integration consumed messages asynchronously using the AMQP Sender Adapter.

The CPI flow became responsible for:

• consuming events from the queue
• triggering processing asynchronously
• performing mappings and validations
• forwarding the data to SAP AFS

The existing backend integration logic remained reusable.

Key implementation learning: AMQP over WebSocket

One particularly important technical aspect during the implementation was protocol handling.

The Event Mesh service instance exposed:

amqp10ws

This required configuring CPI with:

• AMQP over WebSocket
• OAuth2 Client Credentials
• TLS-enabled communication
• WebSocket path configuration

Initial attempts using classical AMQP TCP communication failed because the embedded Integration Suite Event Mesh configuration supported only AMQP over WebSocket.

This became one of the most important implementation learnings during the PoC.

The final CPI connection used:

Port: 443
Path: /protocols/amqp10ws
Authentication: OAuth2 Client Credentials

Decoupling producers and consumers

The most important architectural advantage introduced by Event Mesh is decoupling.

The producer no longer needs to know:

• whether CPI is currently available
• which consumers exist
• how many consumers process the event
• which backend systems are involved

The producer simply publishes an event.

This creates significantly more flexibility for future extensions.

Supporting multiple consumers

One of the strongest advantages of event-driven integration becomes visible when multiple consumers are introduced.

For example:

Topic Address
├─ Queue A → SAP AFS integration
├─ Queue B → Monitoring consumer
├─ Queue C → Analytics platform
└─ Queue D → Notification service

Each queue receives its own copy of the event.

This allows completely independent consumers to react to the same business event without changing the producer itself.

This differs significantly from traditional point-to-point integration, where every additional receiver usually requires direct integration changes.

What this means in practice

In real enterprise integration landscapes, this approach enables:

• asynchronous decoupling between systems
• reduced impact of CPI downtime on producers
• adding new consumers without changing the sender
• reuse of existing CPI mappings and integration logic
• increased flexibility for future integration scenarios

This is especially relevant in logistics-related scenarios, where shipping events are often relevant to multiple downstream systems.

Practical implementation challenges

The PoC also highlighted several implementation-level challenges that are often underestimated in architecture discussions:

• OAuth2 configuration
• AMQP WebSocket connectivity
• topic subscriptions
• queue routing behavior
• consumer authentication
• protocol handling in CPI

These operational details become important once event-driven concepts move from architecture diagrams into real enterprise integration landscapes.

PoC perspective

The goal of this PoC was not production hardening, but validating how event-driven communication can be introduced with minimal impact on existing CPI flows.

The focus was on:

• validating the communication model
• understanding runtime behavior
• identifying technical challenges
• preserving existing backend logic

Final thought

Event-driven integration is not only about introducing technologies such as SAP Event Mesh.

More importantly, it changes the communication model between systems.

Instead of tightly coupling applications through direct integrations, systems communicate through business events that are routed by the event broker.

This creates more scalable, extensible, and resilient integration landscapes.

The PoC demonstrates that existing SAP Cloud Integration scenarios can be redesigned incrementally using event-driven principles while keeping existing mapping and backend logic reusable.