Connect SAP to Everything Else Without Touching the Core

By the document and the volume, not by fashion. IDoc is still the right answer for classic document exchange such as orders, deliveries, invoices and master data, because the structures, acknowledgements and reprocessing tools already exist. OData suits Fiori apps and anything that reads or writes a small set of records interactively. REST and SOAP through the Integration Suite suit third party systems that publish their own contract. RFC and BAPI are for function calls inside a trusted network. We pick per interface and write down why.

No. If you already run MuleSoft, Boomi or Azure Integration Services and your team supports it, adding a second platform for five interfaces is a waste of money and we will say so. Integration Suite earns its place when you want the pre-built SAP integration content packs, SAP to SAP scenarios, Event Mesh, and support that does not stop at the SAP boundary. We size both options against your interface count before you commit.

SAP PI and PO are heading for end of maintenance, so they have to move. We inventory every interface first, because in most estates 20 to 40 percent are dead or duplicated and should be retired rather than rebuilt. What remains is rebuilt as Cloud Integration iFlows, mappings and value mappings carried across, and run in parallel until the message counts match. It is scoped per interface, not as one lump sum.

Every interface gets defined error handling before it goes live. Transient failures retry with backoff. Anything that still fails lands in a queue with the payload kept, raises an alert naming the interface and the document, and can be reprocessed once the cause is fixed. Interfaces are built to be idempotent, so a retry does not post a second invoice or a second goods movement.

They will if they sit outside the core. That is the whole point of clean core: interfaces and extensions live on BTP and talk to released APIs and standard IDoc types, so an upgrade does not touch them. Interfaces wired into modified core code or reading tables directly are the ones that break, and those are the ones we move first.

Both, and the choice is per interface. Sales orders, payment confirmations and shipment status belong in real time or on events, because a delay changes what someone does next. Master data loads, bank statements in MT940 or CAMT format, and reconciliation extracts belong on a schedule, because one batch you can rerun is safer and cheaper than thousands of individual calls you have to chase.