9 November 2026 · Christian Buck
Interfaces as contracts
Many SAP landscapes have hundreds of interfaces. What is usually documented is the mapping: which field goes to which field. It is rarely written down who is responsible for the interface from the business side, which system is right in case of doubt and how old the data may be at the receiver. As long as everything runs, nobody asks. When an error occurs or an interface is replaced, the basis for any decision is missing.
Many companies currently have a concrete reason to ask these questions. SAP has announced mainstream maintenance for SAP Process Orchestration 7.5 until the end of 2027 and extended maintenance until the end of 2030. The successor is SAP Integration Suite on SAP BTP. Anyone who has to touch the interfaces for this anyway can describe them as contracts at the same time.
What belongs in the contract
An interface contract is not a long document. For each data flow it answers a few questions:
- Business owner: Who decides on content and changes? For example, sales for customer orders; IT only operates the interface.
- Leading system: Where is the record created and changed, where is it only read? For example, the business partner in S/4HANA with a copy in the application on SAP BTP.
- Freshness: How old may the data be at the receiver? Seconds for an availability check, one day for reporting.
- Error handling: Who is notified, who corrects, may the message be resent? Resending is safe if the receiver detects duplicates.
The version of the data model comes on top. An API used by several applications needs a rule for how changes are announced and how long the old version remains available.
Event or synchronous call
The second decision concerns the pattern. A synchronous call fits when the caller needs the answer to continue: a price calculation, an availability check, a credit check. The caller waits, and the called system must be available at that moment.
An event fits when a system informs others about a change and expects no answer itself: order created, business partner changed, delivery posted. The sender does not know the receivers, and new receivers can be added without changing the sender. On SAP BTP, an event broker such as SAP Event Mesh handles the distribution.
Both patterns have limits. Chains of synchronous calls couple availability: if A calls B and B calls C, A stops as soon as C fails. Events, on the other hand, require receivers that detect duplicates and can handle a changed order. Without a business owner, events can also turn into a web in which nobody knows who reacts to which message.
Three examples from projects
In regulatory reporting for banks, the contract is defined externally. The supervisor sets the XML schema, the transfer runs via a web service, and the reporting date determines the freshness. Internally, the open question is usually who corrects a rejected report. It should be answered before the first reporting date.
When source systems are loaded into SAP BW/4HANA, freshness is the load time. If data is loaded at night, it is up to a day old during the day. That is sufficient for most reports, but it should be agreed with the business before a daily report is used for steering.
In an application on SAP BTP built with CAP that runs side-by-side with S/4HANA, S/4HANA leads the master data and the BTP application leads its own transactions. Read access to master data runs synchronously via OData. Changes to the application's own transactions that S/4HANA needs to know about are candidates for events.
What this means for a replacement
A migration that rebuilds every interface one to one also carries over the open questions. I would record each interface with the four decisions first. This usually shows three groups: some interfaces are no longer used and can be dropped, some synchronous queries can be replaced by events, and for some no business owner can be found. The last group needs a decision before it is migrated.
How do you document interfaces in your landscape, and who owns them on the business side?
Questions about this article or your project? info@bissanda.com · All articles