The unit of SAP integration is a business document
Start with what an SAP interface moves. The unit is a business document rather than a row. A sales order carries a header that must agree with its items, a status deciding what may happen to it next, and a pricing result somebody in finance will reconcile. Copy the fields, ignore the lifecycle, and you get records that pass every technical check while describing a state the business never reached.
That gap separates an interface which survives a year of month ends from one which produces a reconciliation task at every close. A goods movement posted without the document flow behind it leaves a quantity correct in one system and unexplainable in the other. None of that shows up in a monitor counting messages delivered.
So the first design question is which document you are moving and which of its states you may create, change or cancel. Where a published interface already models the document, use it rather than assembling your own out of tables, and confirm what your licensing and release actually expose, because that varies by contract and by landscape.
Point to point earns its place and then outgrows it
Everybody disparages point to point and everybody builds it, because for a small number of stable connections it is the fastest thing that works and it is the correct answer. Two systems, one document, a known owner on each side, little money at risk if it stops. A direct call runs in days and asks nobody to learn a new platform.
The problem is never the first point to point interface. It is the twentieth, when a question as ordinary as what talks to the order system takes three people two days to answer and the answer still has gaps. Together those connections form dependencies nobody holds in their head, and every upgrade opens with a discovery exercise.
The useful discipline is naming the point where you stop. Some teams say any interface carrying money, or touching more than two systems, goes through the platform. The rule matters less than having one, because without it point to point spreads by default and the architecture gets decided by whoever is busiest. That is why we argue for putting the current interfaces on one map.
What a mediated platform actually costs to own
Mediated integration puts a platform between the systems, and what you buy is visibility, reuse and one place where failures land. A retry policy written once applies to everything running through it. A second consumer of the same document costs a configuration change rather than a project. Somebody can answer the what talks to what question from a tool.
What you pay is a component that needs owning. Somebody patches it, somebody tracks the certificates and their expiry dates, somebody keeps the conventions consistent so a stranger can pick up the fortieth flow. Those skills are specific and they are not free, and owning an interface properly involves more than watching a queue.
The platform earns its place when the same document goes to more than one place, or when somebody needs a single answer at two in the morning. Otherwise you have added a hop, some latency and a second thing to debug, and nobody in particular owns it.
Events for the cases that genuinely need them
Event-driven patterns earn their place in a narrow set of cases. A change has several independent consumers, the publisher must not wait for any of them, and the consumers cope with messages arriving out of order or arriving twice. Stock changes fanning out to several fulfilment systems fit. So does a status change three teams want and none of them wants to own.
Most SAP integrations do not fit that, and a request for events is frequently a request for something else. Teams who ask usually want their data sooner, or they want to stop being blamed for a nightly file that lands late. Both are answered often enough by running an existing extract more often. Ask what the consumer would do differently with a change inside a second rather than inside an hour.
What makes a message safe to deliver twice
A retried posting that creates a second invoice is the failure that costs real money, and you will meet it eventually, because networks time out after the receiving system has already committed. The design question to settle before any retry policy is what makes a message safe to deliver twice.
Usually the answer is a key the receiver checks before it posts. The sending document number, or a reference stored on the created document, anything that lets the receiver recognise work it has already done and hand back the original result. Persisting that reference is the step that gets skipped, because it costs a field and a lookup and nothing visibly breaks the day you leave it out.
Send the same message twice into a sandbox and look at what exists afterwards. Do that for every interface which creates or posts anything, and again after any change to the receiving logic, because idempotency lives in that logic and not in the transport. Picking the identifier is its own discipline, and choosing a durable business key covers the trade-offs.
A timeout and a rejection are different problems
Two kinds of failure arrive in the same error queue, and most implementations handle them identically. A technical failure means the message never reached the logic that would have processed it, after a timeout or an expired credential. Retry it and it will probably go through. A business rejection means the receiving system understood the message and refused it, because the account is blocked or the material is not defined in that plant. Retrying that forever fills the queue with work only a person changing data can clear.
Separating the two is the highest value change most teams can make to their error handling. Technical failures retry with backoff and escalate when they keep failing. Business rejections stop on the first attempt and go to whoever owns the data, carrying enough of the document that the person can act without opening two systems. We argued that case in error handling that reaches somebody.
Then make sure the queue reaches a person. A queue filling silently overnight is the recurring incident across every platform we cover, and the cause is rarely a missing dashboard. Somebody has to be named, and the alert has to arrive where that person already looks. Ask who was paged the last time an interface failed on a Saturday.
Definitions and owners decide what you can change later
Most integration defects are disagreements about data definitions that present as technical errors. The mapping is right and the message still fails, because one system counts a plant and a storage location as one thing and the other does not, or because two teams maintain the customer master under different rules and nobody wrote either rule down.
So settle the definitions before the payload. Which system owns each master object, which fields it may change, what happens downstream when an owner retires a value, and who arbitrates when two owners disagree. That removes more defects than any amount of retry tuning, and a starting point for master data governance beats a two-year programme.
The artefact that separates an SAP estate somebody can reason about from one nobody dares touch is an inventory. Every interface, both endpoints, the document it moves, the trigger or schedule, and a named owner. A person, not a team, because teams do not answer pages. Keep it where the next architect finds it without asking.
Clean core thinking belongs in the same inventory, since integration built on stable published interfaces survives an upgrade and integration reaching into internal tables does not. The same trade drives deciding what belongs side by side. So take the three interfaces moving the most money through your estate and answer three things this week. Who owns each one, what happens if its message arrives twice, and where a rejection goes when the receiving system refuses it.
