This blog post explores common architectural patterns using SAP Event Mesh in a cloud-native integration landscape.

Audience & Prerequisites

Audience: Integration architects and developers familiar with AMQP principles and SAP Cloud Integration.
Prerequisites: Basic understanding of event-driven design.

Key Components

• Producer System: Source of events (e.g., e-commerce platform).

• SAP Cloud Integration Suite: Acts as an AMQP broker or event router.

• Consumer System(s): Subscribers processing events (e.g., warehouse, analytics).

1. Single Publisher → Single Event Type → Single Subscriber

Use Case
A customer places an online order. The e-commerce app publishes an OrderCreated event, and a warehouse service processes it to trigger shipping.

Motivation
Simplest guaranteed-delivery scenario for point-to-point integration.

Description

• Producer sends events to a dedicated queue.

• Consumer subscribes to the queue for ordered processing.

Pros & Cons

• Pros: Guaranteed delivery, simple error handling.

• Cons: Tight coupling, no scalability.

When to Use
Legacy system integrations or one-to-one workflows.

Configuration

• Queue: Queue_OrderCreated

• Protocol: AMQP (pull-based).

2. Single Publisher → Single Event Type → Multiple Subscribers (Fan-out)

Use Case
A retail platform publishes OrderCreated events to notify analytics, billing, and notification services in parallel.

Motivation
Broadcast events to multiple consumers for independent processing.

Description

• Producer publishes to a topic.

• Event Mesh replicates the event to subscriber queues.

Pros & Cons

• Pros: Decoupled subscribers, scalable.

• Cons: Resource overhead, management complexity.

When to Use
Multiple downstream systems need the same event.

Configuration

• Topic: Topic_OrderCreated

• Subscriber Queues: Queue_Analytics, Queue_Billing, Queue_Notification.

3. Multiple Event Types → Single Subscriber

Use Case
A fulfillment engine handles OrderCreated and OrderUpdated events from a single subscription.

Motivation
Centralize logic for related event types.

Description

• Producers emit events to a shared topic.

• Subscriber filters events by headers (e.g., type=Created).

Pros & Cons

• Pros: Fewer endpoints, unified logic.

• Cons: Filtering overhead, load concentration.

When to Use
A service needs multiple event types.

Configuration

• Topic: Topic_OrderEvents

• Queue: Queue_OrderProcessor with header-based bindings.

4. Multi-Topic Selective Subscription

Use Case
A procurement system subscribes to material/vendor events, while analytics uses product events.

Motivation
Domain-driven subscriptions for segregated data.

Description

• Producers publish to domain-specific topics.

• Consumers bind to relevant topics.

Pros & Cons

• Pros: Fine-grained control, domain isolation.

• Cons: Binding management.

When to Use
Segregated event types per domain.

Configuration

• Topics: Topic_MaterialEvents, Topic_ProductEvents, Topic_VendorEvents.

• Queues: Queue_Procurement (material/vendor), Queue_Analytics (product).

5. Aggregator Pattern

Use Case
An integration flow aggregates daily material/product updates into a MasterDataBundle for reporting.

Motivation
Batch processing of related events.

Description

• SAP Cloud Integration (CI) consumes source queues, aggregates data, and publishes a bundled event.

Pros & Cons

• Pros: Simplified downstream consumption.

• Cons: Latency, complex logic.

When to Use
Batch reporting or composite events.

Configuration

• Source Queues: Queue_MaterialEvents, Queue_ProductEvents.

• Output Topic: Topic_MasterDataBundle.

6. Event Enrichment Pipeline

Use Case
Enrich raw order events with customer credit scores and product availability.

Motivation
Decouple enrichment steps from producers/consumers.

Description

• CI flows progressively enrich events across stages.

Pros & Cons

• Pros: Modular design, separation of concerns.

• Cons: Increased latency.

When to Use
Progressive event enhancement.

Configuration

• Topics: Topic_RawOrderEvents → Topic_EnrichedEvents.

• Queues: Queue_Enrich1, Queue_Billing, Queue_Shipping.

7. Scatter–Gather Pattern

Use Case
A credit-check flow queries two agencies in parallel and aggregates responses.

Motivation
Parallel execution and result collation.

Description

• CI publishes requests to a topic.

• Subscribers process requests and publish responses.

• Aggregator CI flow correlates responses.

Pros & Cons

• Pros: Parallelism, resilience.

• Cons: Correlation complexity.

When to Use
Multi-service orchestration.

Configuration

• Topics: Topic_Requests, Topic_Responses.

• Queues: Queue_ServiceA, Queue_ServiceB, Queue_Aggregator.

8. Error Handling & Dead-Letter Queue

Use Case
Malformed events are moved to DLQ_OrderProcessor after retries.

Motivation
Isolate poison messages for analysis.

Description

• Configure queues to route failed messages to a DLQ.

Pros & Cons

• Pros: Prevents message loss.

• Cons: Requires monitoring.

When to Use
Critical pipelines needing reliability.

Configuration

• Primary Queue: Queue_OrderProcessor.

• DLQ: DLQ_OrderProcessor (bound via dead-letter exchange).

9. Webhook Integration Pattern

Use Case
Event Mesh invokes a third-party SMS gateway’s webhook on OrderShipped events.

Motivation
Real-time integration with HTTP endpoints.

Description

• Event Mesh pushes events to HTTP endpoints via POST.

Pros & Cons

• Pros: No persistent consumer needed.

• Cons: HTTP reliability challenges.

When to Use
Lightweight integrations with REST APIs.

Configuration

• Topic: Topic_OrderNotifications.

• Webhook: https://api.sms-gateway.com/notify (TLS + OAuth).

Conclusion

Choose patterns based on coupling, scalability, and latency needs. SAP Event Mesh’s flexibility with queues, topics, and webhooks supports diverse integration scenarios.

It was also published here:

https://medium.com/@vbalko/sap-event-mesh-architecture-patterns-11e8deae45dc

https://community.sap.com/t5/technology-blog-posts-by-members/sap-event-mesh-architecture-patterns/ba-p/14103610