SAP Process Integration / Process Orchestration (PI/PO)

SAP's on-premise middleware for mediated integration between SAP and non-SAP systems using adapters and mapping.

PI/PO is a broker sitting between systems. Rather than every system knowing how to talk to every other, each one talks to PI/PO.

PI/PO is like a universal translator and mail-sorting hub at the center of a multinational conference - instead of every attendee needing to personally learn every other attendee's language and hand-deliver messages (point-to-point integration), everyone just hands their message to the hub, which translates and routes it to the correct recipient in their own language.

Key Concepts

Why a hub instead of direct connections. Ten systems connected directly need up to 45 interfaces. Each new system adds ten more.

    point to point   every pair needs its own interface and mapping
    hub and spoke    each system has one connection: to the broker

That is the architectural argument, and it holds up: the broker also gives one place to monitor, one place to retry, and one place where a format change is handled.

How a message travels through it.

    sender adapter    receives -- IDoc, SOAP, HTTP, JDBC, file, ...
        |
    routing           receiver determination: who should get this?
        |             (one message can fan out to several receivers)
    mapping           graphical, XSLT or Java: source format -> target
        |
    receiver adapter  delivers to the target system

Design time and runtime are deliberately separate.

    ESR (Enterprise Services Repository)   message types, interfaces,
                                           mappings. Designed once.
    Integration Directory                  which sender and receiver,
                                           which channel, what
                                           credentials. Per environment.

So the same mapping is reused across development, quality and production, while connection details differ per environment. Collapsing the two is how teams end up redesigning interfaces for every system.

Process Orchestration adds two things on top of the integration engine: BPM for multi-step processes involving human tasks, and BRM for business rules. That is what distinguishes PO from plain PI — it goes beyond system-to-system messaging into workflow.

Where it stands now. Supported, widely deployed, and not where SAP is investing. New integration development goes to Cloud Integration on BTP.

The concepts carry over almost directly — adapters, mapping, routing, and a monitored pipeline — so someone who understands PI/PO understands CPI's model quickly. What differs is the hosting, the credential handling, and reaching on-premise systems from the cloud.

The honest position for an interview: PI/PO is the right thing to keep running and the wrong thing to start new work in, and a migration to CPI is usually part of a wider S/4HANA and cloud programme rather than a project of its own.

What the interviewer is probing.1. "What is the difference between PI dual stack and PO single stack?" Probing: currency. Stalls: "Nothing." Moves up: single stack is Java only, which is the supported direction; dual stack with the ABAP integration engine is retired.

2. "What are the main design objects?" Probing: the structure. Stalls: "Mappings." *Moves up:* data types, message types, service interfaces, message and operation mappings in the ESR, then configuration in the Integration Directory.

3. "What is an adapter module for?" Probing: the extension point. Stalls: "Nothing." *Moves up:* custom Java in the adapter pipeline for things the standard adapter cannot do, such as unusual file handling or signing.

4. "Where is PI going?" Probing: strategic awareness. Stalls: "It is fine." Moves up: to Integration Suite in the cloud — new integrations should go there, with PI/PO maintained for existing on-premise flows.