S/4HANA business events: designing consumers that handle duplicates

The problem

A team moves from nightly batch jobs to real-time S/4HANA business events. Within weeks, a downstream system creates the same delivery twice. Nothing is broken: brokers guarantee delivery at least once, which means occasional duplicates are expected behavior.

Understand the event

Many S/4HANA business events are notification events: they say that something changed and carry key fields, not the full business object. The consumer then reads the current state through an API. This is a strength, because the consumer always works with fresh data.

The pattern

• Subscribe through a queue, not directly to a topic, so events wait safely while the consumer is down.
• Take the event’s unique ID (or the object key plus a change timestamp) as the deduplication key.
• Check whether that key has already been processed, for example in a data store with an expiry period.
• If it has, acknowledge the event and stop. If not, read the current object state through the API, process it, and record the key.
• Configure a dead message queue so events that fail repeatedly are kept for investigation instead of retried forever.

Design tips

• Make downstream updates idempotent where possible, for example “set status to shipped” instead of “add one shipment.”
• Do not rely on strict ordering across different objects. If order matters for one object, compare timestamps before applying a change.
• Monitor queue depth. A growing queue is the earliest sign of a slow or failing consumer.

Result

You keep the speed of real-time integration while downstream systems stay accurate, even through retries, redeliveries and consumer restarts.