SAP Integration overview

• SAP Integration Suite (cloud): the strategic iPaaS (includes Cloud Integration/CPI, API Management, more).
• SAP PI/PO (on-premise): the classic middleware, being succeeded by Integration Suite.
• IDoc/ALE & RFC/BAPI: classic SAP-to-SAP mechanisms.
• OData/REST & SOAP: service-based integration.
• Event-driven (Event Mesh): asynchronous events.

Choosing the technology is downstream of choosing the style, and the style follows from what the business actually needs.

Synchronous request and response. The caller waits for an answer. Right when the answer changes what happens next: a credit check before an order is confirmed, an availability check before a promise is made. Wrong for anything high volume, because the caller is blocked and a slow partner becomes your outage.

Asynchronous messaging. Fire the document and let it be processed. Right for document exchange at volume, where guaranteed delivery matters more than an immediate answer. IDoc and ALE were built for exactly this and still do it well. See SAP IDoc integration.

Batch file transfer. Unfashionable and still correct for large periodic loads, bank files and anything where the partner will only ever produce a file. Simple, auditable, and easy to rerun.

Event driven. Publish that something happened and let anyone interested react. Right when you do not know or do not care who consumes it, and when loose coupling matters more than a guaranteed handshake. See SAP Event Mesh.

Most landscapes run all four, and the mistake is not picking the wrong one once. It is defaulting to whatever the last project used.

On the classic side, SM59 maintains RFC destinations, which is where most connectivity problems are diagnosed because it has a connection test built in. WE20 holds partner profiles, WE02 and WE05 monitor IDocs and their statuses, and SOAMANAGER configures web services. SLG1 reads application logs when something failed quietly.

On the cloud side there is no SAP GUI. Integration Suite is a browser tenant where integration flows are designed, deployed and monitored, with its own monitoring view rather than a transaction. See SAP Integration Suite.

The practical habit worth building: when an interface fails, establish which side it failed on before anything else. SM59 proves the connection. The IDoc status proves whether the document arrived and what it thought of it. Application logs prove what happened after that.

Half an hour, and it is the skill an integration role is actually hiring for.

1. Open SM59 and find an RFC destination. Run the connection test. A green result proves the network and the credentials, and nothing else.
2. Look at WE20 for a partner and read which message types it is configured to send and receive. This is the contract between the two systems.
3. Post something that generates an outbound IDoc, or find a recent one in WE02.
4. Read the status. 03 means it left. 53 means it was posted successfully on the way in. 51 means it arrived and the application rejected it, which is a data problem rather than a connection problem.
5. For a 51, open the status record and read the message. It is usually a missing master record in the receiving system, and that is fixed there rather than in the interface.

Knowing that 51 is not a connectivity failure will save you a day at some point.

Integration is shifting from on-premise middleware (PI/PO) to the cloud SAP Integration Suite, aligning with cloud ERP and hybrid landscapes. New integrations increasingly use Cloud Integration (CPI) and API Management, while classic IDoc/RFC remains important for existing SAP-to-SAP flows.

Match the technology to the need: synchronous APIs (OData/SOAP) for real-time, IDoc/ALE for robust async document exchange, events (Event Mesh) for decoupled notifications, and Integration Suite/PI-PO as the middleware orchestrating and transforming between systems.

Two more considerations that decide more designs than the technology does. Who owns the error. An interface without a named owner for failed messages will accumulate them silently until somebody notices a month of missing orders. And what happens on a retry. If sending the same document twice creates two orders, the design is wrong, and idempotency is cheaper to build in at the start than to retrofit after a duplicate reaches a customer.

• Middleware or point to point. Direct connections are quick and multiply until nobody can draw the landscape. Middleware costs more up front and keeps the map readable.
• Where transformation happens. In the sender, the middleware or the receiver. Putting it in the middleware keeps both endpoints simple and concentrates the knowledge in one place.
• How much to monitor. Every interface needs an alert on failure and somebody who receives it. Monitoring that nobody reads is the same as no monitoring.
• Clean core. Building extensions and integrations outside the ERP core rather than inside it is what keeps upgrades from becoming rewrites.

Integration is usually described as a technical problem and is usually a data problem. Two systems that agree on the protocol still have to agree on what they are talking about.

Identity. The same customer is a number here, a code there and an email address somewhere else. Something has to hold the cross-reference, and deciding where that lives is a design decision people postpone until the first mismatch.

Timing. An order arrives referencing a material created five minutes ago in the sending system and not yet replicated. The interface is working perfectly and the message still fails. Sequencing master data ahead of transactional data is not a nicety.

Granularity. One system holds an address as five fields and the other as three lines. Mapping that is lossy in one direction, and the loss shows up months later on a delivery note.

Ownership. When both systems can change the same field, they will, and the last writer wins silently. Naming one system as the source of truth per field is tedious and it is the thing that prevents the worst class of integration bug.

The practical consequence for anyone learning this: time spent understanding master data is time spent on integration, and the interface itself is often the simplest part of the job. See Cloud Integration for where the mapping is actually built.

• Wrong integration style (sync vs async) for the need.
• Point-to-point sprawl instead of using middleware.
• Ignoring the cloud direction (Integration Suite).

• Testing only the happy path. The interface will meet a rejected document on day two, and how it behaves then is the design.
• Hardcoding endpoints. They differ per environment, and a transport that carries a production URL into development is a memorable incident.

• No dead letter handling. Messages that cannot be processed have to go somewhere a person will look, otherwise they are simply lost with a log entry nobody reads.
• Assuming the partner will send what the specification says. They will send what their system produces, and the interface has to survive the difference.

Reading an interface is the start, and building one with its error handling and monitoring is the part you do in the course.

If you take one working practice from this page, make it establishing which side failed before forming any theory. Connection, document status, then application log, in that order. It is faster than guessing and it stops the reflex of blaming the interface for what is usually a missing master record at the other end.