Architecture · 2026-06-27 · 10 min
SAP ↔ DMS: three integration patterns and when each one breaks
File batch, synchronous API, and event-driven. Each is correct somewhere. Choosing by fashion instead of by failure mode is how distribution programmes lose a year.
Pattern 1 — Scheduled file exchange
Still the right answer for low-volume, tolerant-of-latency master data with a small partner count and weak partner IT capability. It is cheap, debuggable, and every DMS vendor supports it.
It breaks when partners need same-day stock visibility, when partial-file failures cannot be isolated, and when reconciliation becomes a monthly spreadsheet exercise. The tell: someone maintains a manual 'files that did not arrive' tracker.
Pattern 2 — Synchronous API calls
Right when the caller genuinely needs an answer now: credit check, stock reservation, order acceptance. Simple mental model, easy to authorize, easy to trace.
It breaks under coupling. SAP dialog work processes are a finite resource; a chatty DMS in one market can starve them for all six. Add a slow partner network and your ERP inherits their latency. If you take this route, budget concurrency per partner and enforce it at the gateway.
Pattern 3 — Event-driven
Right at scale: many consumers, different SLAs, partner systems that go offline. Producer and consumer fail independently, and replay turns an outage into a delay.
It breaks when the organisation is not ready for eventual consistency. If a commercial user expects a claim to appear the instant it is raised, someone must own that expectation. It also breaks without schema governance — an unversioned event contract is a distributed outage with a delay fuse.
How we choose
Four questions: what is the acceptable staleness, how many consumers will exist in three years, what happens when the partner is offline for a day, and who owns the schema. The answers pick the pattern; the pattern rarely picks itself.
Most real distribution landscapes end up hybrid: events for domain state, synchronous for decisions, files for the long tail of partners who will never build an API.
The migration path that works
Introduce the gateway first, keep the existing files flowing through it, then move consumers to events one at a time. Never big-bang a landscape where six markets bill against the same master data.