SAP PI/PO

PI/PO receives messages from a sender, transforms them (mapping between formats/structures), and routes them to receivers, handling many protocols (IDoc, RFC, SOAP, REST, file, JDBC). It centralises integration so systems do not connect point-to-point, and provides monitoring of message flows.

A note on the names, since all of them appear in job adverts. XI was the original, PI the rename, and PO the version running on a single Java stack with additional process orchestration capability. They are the same lineage, and an advert saying PI usually means whichever of them the client is running.

• Integration Directory & Repository: configuration and design.
• Mappings: transform between message structures.
• Adapters: connect protocols (IDoc, SOAP, file, JDBC, REST).
• Message monitoring for troubleshooting.

Two runtime concepts worth naming because they appear in every troubleshooting conversation. The Advanced Adapter Engine is where messages are actually processed, and in PO it handles the whole path rather than handing between stacks. And message persistence means a message is stored as it passes, which is what makes monitoring, resending and auditing possible, and also why housekeeping on those tables matters.

The split that structures everything in PI is between what a message looks like and how it is routed, and the tools mirror it.

Design, historically the Enterprise Services Repository, holds the reusable definitions: message types, the data structures being exchanged; service interfaces, describing an operation; mappings, converting one structure to another; and operation mappings, tying them together. These are design objects, versioned and transportable, and they know nothing about which systems are involved.

Configuration, the Integration Directory, holds the specifics: which business system sends to which, over which communication channel, using which adapter, with which routing conditions. This is where a scenario becomes real, and it differs per landscape.

That separation is why one mapping can serve several partners, and why moving a scenario between landscapes means transporting design objects and reconfiguring the directory rather than copying everything.

In PO, the dual stack was retired and everything runs on Java, which removed a long-standing source of complexity: two stacks that had to be kept in step and could fail independently.

Half an hour, and it is the daily work of a PI support role.

1. Open the message monitor and find a recent message. Note its status: successful, waiting, system error or application error.
2. For a failure, read where it stopped. At the sender channel is connectivity. In mapping is data. At the receiver is the far end refusing it.
3. Open the message payload before and after mapping. The field that went wrong is usually visible by comparison.
4. Check the communication channel monitor for the channel involved. A channel in error affects every message using it, which is a different scale of problem.
5. Where the message is recoverable, resend it, and know whether that is safe before you do.

Step four is the distinction worth making early: one message failing is data, every message failing is a channel or an endpoint.

PI/PO remains in use in many on-premise/hybrid landscapes, but for new integration SAP directs customers to the cloud Integration Suite. Knowing PI/PO is valuable for existing estates and migrations.

The honest position on the future. PI and PO have a published maintenance horizon and Integration Suite is the strategic successor, so new development goes to the cloud. That does not make a working PO landscape urgent to replace: it moves scenarios, revalidates every interface and consumes a year, and the business case has to be more than the product being newer. Most organisations migrate gradually, new scenarios in the cloud and existing ones as they need changing anyway. See Cloud Integration for where they are heading.

Because that migration is where a lot of the work now is, it helps to know what carries and what does not.

Mappings mostly carry. Message mapping in Integration Suite is recognisably the same tool, and there is tooling to convert existing ones, with manual attention where custom functions were used.

Adapters mostly have equivalents, and the configuration differs enough that channels are rebuilt rather than moved.

Routing logic is rebuilt. Receiver determination and interface determination become routing steps inside an integration flow, which is a different shape rather than a different syntax.

Custom Java modules do not carry. They are reimplemented as Groovy scripts or replaced with standard steps, and this is usually the largest single item.

Nothing about the partners changes, which is the point often missed: every endpoint, credential and certificate has to be re-established, and every interface retested with the partner, and that coordination is more of the effort than the rebuilding.

The adapter is where a scenario meets the outside world, and the common ones are worth knowing by what they suit.

IDoc for SAP to SAP document exchange, and it remains the right answer for high volume between ERP systems.

RFC for calling function modules synchronously, which is how a PI scenario can ask an SAP system a question rather than send it a document.

File and SFTP for batch exchange, still the answer for banks and for partners whose systems produce files. Watch the polling interval and the archive settings, since a file processed twice is duplicated data.

SOAP for web services with a formal contract, and REST for the lighter modern equivalent.

JDBC for reading and writing a database directly, which works and couples you tightly to somebody's schema.

JMS for queueing, and it is the tool for decoupling a fast sender from a slow receiver inside the landscape.

The choice usually is not yours: the partner's capability decides it. Where you do have a choice, the question is whether the caller needs an answer, and everything else follows from that.

• Synchronous or asynchronous. Whether the sender waits. Asynchronous with a queue protects both ends from each other's downtime.
• Where transformation happens. In the middleware, keeping both endpoints simple, or at an endpoint, which spreads the knowledge.
• Error handling per scenario. Where a failed message goes and who is told. Defining this once for the landscape is better than per interface.
• Whether to migrate. A working scenario with no pending change is not a migration candidate on its own; one that needs work anyway is.

• Wrong tool for the integration style.
• Ignoring monitoring/error handling.
• Point-to-point instead of governed integration.

• Resending a message without knowing whether it is idempotent. Two orders is worse than none.
• Custom Java modules for things standard adapters do. They were a reasonable choice once and they are what makes a migration expensive now.
• Monitoring nobody watches. See IDoc integration, API Management and Event Mesh for the neighbouring styles.

• File polling with no archive. A file left in place is picked up again, and duplicated data is harder to unpick than a failed interface.

Reading a failed message is the daily skill, and designing a scenario with its mapping, routing and error handling is the part you do in the course.

The distinction to make first on any failure is whether one message failed or every message is failing. The first is data and belongs to whoever owns the record; the second is a channel or an endpoint and belongs to you.