How do I avoid duplicate processing (idempotency) in SAP integration?
Avoid duplicate processing by making every receiver idempotent: give each message a stable business key or message ID, record which keys have been processed, and ignore or safely acknowledge repeats. Retries, at-least-once event delivery and manual reprocessing all create duplicates, so idempotency must be designed in rather than hoped for.
Duplicates are a normal consequence of reliable messaging. If a call times out after the target has already posted the document, the sender cannot know, so it retries, and without protection the target posts twice.
Practical techniques, from most to least preferable:
- Use the target's own duplicate check. Many business APIs detect a repeated external reference, such as a supplier invoice number or purchase order reference.
- Carry a stable key end to end. Use the source document number or a message ID, never a value generated on each attempt.
- Check before you post. In Cloud Integration, the Idempotent Process Call step records processed IDs and skips repeats; a Data Store entry can serve a similar purpose.
- Make updates absolute, not relative. Setting a status to shipped is safe to repeat; adding one to a quantity is not.
| Source of duplicates | Example |
|---|---|
| Retry after timeout | Target posted, but the response was lost |
| At-least-once events | Broker redelivers after a consumer restart |
| Manual reprocessing | An operator restarts a failed batch |
Test duplicates deliberately before go-live. See the retry guide and error handling patterns.
Related questions
See what Spanovix would fix in your landscape
Bring your hardest interfaces. In a short working session we show where the agents cut failures, manual work and risk for your teams.