Blogs

SAP PI and SAP PO: Everything You Need to Know (Architecture, Versions & Migration)

SAP PI (Process Integration) is SAP’s on-premise middleware platform for connecting SAP and non-SAP systems via A2A, B2B, and B2C integration scenarios. SAP PO (Process Orchestration) is its direct successor, adding Business Process Management (BPM) and Business Rules Management (BRM) to the same integration engine on a unified Java stack. Both platforms share the same core architecture — the difference is that PO extends PI with full process orchestration and rule automation capabilities.

2027 deadline: SAP mainstream maintenance for PI/PO ends December 2027. Organizations running PI/PO should be actively planning migration to SAP Integration Suite. This guide covers everything you need to know: architecture, components, versions, how messages flow, adapters, monitoring, and the migration path.

SAP XI, SAP PI, SAP PO: The Naming Evolution

One of the most common points of confusion around this platform is the naming. SAP has used three different names across the product’s lifetime, and all three refer to the same integration middleware:

  • SAP XI (Exchange Infrastructure) — The original name, introduced in 2002 with SAP NetWeaver 2004. XI was the first centralized SAP integration platform, built on a Java+ABAP dual-stack architecture.
  • SAP PI (Process Integration) — Renamed from XI starting with version 7.1 (released 2007). The architecture remained the same; the name change reflected a broader positioning as an enterprise integration platform rather than just an exchange infrastructure.
  • SAP PO (Process Orchestration) — Released in 2012 (version 7.31 SP05+), PO consolidated PI, BPM, and BRM into a single Java-only stack. PO is the last on-premise version and the one reaching end of mainstream maintenance in 2027.

In practice, “SAP PI/PO” is used as a combined term across the industry because most active deployments use either PI 7.31 or PO 7.4/7.5, and they share the same core integration engine. When someone says “SAP PI” today, they usually mean the PI/PO platform in general.

SAP PI/PO Version History

  • SAP XI 3.0 (2004) — First release on NetWeaver 2004
  • SAP PI 7.0 (2005) — NetWeaver 2004s, introduced Integration Server
  • SAP PI 7.1 (2008) — First single-stack option (Java only), dual-stack still supported
  • SAP PI 7.3 (2011) — Advanced Adapter Engine (AAE) enhancements
  • SAP PI 7.31 (2012) — Last pure PI version; single Java stack by default
  • SAP PO 7.4 (2013) — Full BPM 2.0, BRM integration; unified installation
  • SAP PO 7.5 (2016) — Current and final version; REST adapter added natively; mainstream maintenance through 2027

What Is SAP PI (Process Integration)?

SAP PI is an enterprise middleware platform built on SAP NetWeaver that enables seamless data exchange between SAP and non-SAP systems. It operates across three phases — design time, configuration time, and runtime — using a set of core components that together form the integration infrastructure.

Core Components of SAP PI

  • System Landscape Directory (SLD): Central registry of all technical and business systems — product versions, software components, and installed systems. SLD is the starting point for any new integration project.
  • Enterprise Services Repository (ESR): Design-time repository where all integration objects live — interface definitions, message types, data type structures, message mappings, and process definitions (ccBPM).
  • Integration Directory (ID): Configuration layer that brings ESR objects to life. Here you configure who sends what to whom: sender agreements, receiver determinations, interface determinations, and receiver agreements.
  • Advanced Adapter Engine (AAE): Runtime component providing the connectivity layer — adapters for SOAP, REST, HTTP, SFTP, JDBC, RFC, IDoc, AS2, and more. The AAE manages message pickup, delivery, and protocol conversion.

What Is SAP PO (Process Orchestration)?

SAP PO is the consolidated successor to SAP PI. Beyond data routing and transformation, PO enables end-to-end process automation where integration steps can be embedded within longer business workflows. PO adds two components to the PI stack:

  • SAP Business Process Management (BPM): Models and executes long-running business processes using BPMN 2.0 notation. Unlike PI’s ccBPM (cross-component BPM), PO’s BPM engine supports human tasks, parallel branches, wait states, escalations, and compensation steps.
  • SAP Business Rules Management (BRM): Externalizes business decisions from hardcoded integration logic into configurable rules managed by business users — routing decisions, approval thresholds, discount calculations.

How SAP PI/PO Works: Message Flow Step by Step

Understanding how a message travels through SAP PI/PO helps both developers and architects design reliable integrations. Here is the standard flow for an asynchronous A2A message:

  1. Message generation: The source system (e.g., SAP ERP) generates a message — an IDoc, RFC call, SOAP request, or file — and sends it to the PI/PO runtime endpoint.
  2. Sender channel pickup: The appropriate sender communication channel in the AAE receives the message and converts it from the source protocol (IDoc, SFTP, AS2, etc.) to PI/PO’s internal XI Message format.
  3. Integration Engine processing: The Integration Server applies the routing logic configured in the ID: sender agreement validation → receiver determination → interface determination → mapping execution → receiver agreement selection.
  4. Message mapping: The mapping program defined in the ESR transforms the message from the source structure to the target structure. Mappings can be graphical (drag-and-drop field mapping), XSLT-based, or Java/Groovy-coded for complex transformations.
  5. Receiver channel delivery: The target communication channel converts the transformed XI message to the target protocol and delivers it to the receiver system (REST endpoint, SFTP directory, database table, SAP system via IDoc/RFC).
  6. Message logging: Every step is logged in the Message Monitor (SXMB_MONI or PI monitoring UI), enabling administrators to trace payloads, debug mappings, and reprocess failed messages.

For synchronous scenarios (RFC, SOAP request/reply), the sender waits for a response; the pipeline returns the response message through the same channel within the timeout window.

ABAP Proxy Integration in SAP PI/PO

ABAP Proxy is one of SAP PI/PO’s most powerful — and most SAP-specific — integration mechanisms. Rather than using an external adapter to connect SAP ERP to PI/PO, ABAP Proxy generates native ABAP classes directly from interface definitions in the ESR. The generated proxy class handles all serialization, XML conversion, and communication with the PI/PO Integration Server automatically.

This means an ABAP developer calls the generated proxy class in their program exactly like a local function module — without writing any network or XML code. PI/PO picks up the call, applies the configured routing and mapping, and delivers to the target system. ABAP Proxy is faster and more reliable than adapter-based SAP-to-PI communication, and it is the recommended pattern for any integration between an ABAP-based SAP system and PI/PO.

On the PI/PO side, ABAP Proxy uses a dedicated communication channel (the ABAP Proxy sender channel), which requires no adapter configuration — the communication is internal to the SAP NetWeaver stack.

SAP PI vs SAP PO: Key Differences

  • Architecture: PI typically runs on dual-stack (ABAP + Java) in versions before 7.31; PO runs on a single Java stack only, simplifying administration.
  • BPM capability: PI supports only ccBPM (cross-component BPM) with limited workflow modeling; PO provides full BPMN 2.0 process design with human tasks and escalations.
  • Business rules: BRM is available only in PO, not in standalone PI.
  • REST support: Native REST adapter available from PO 7.5 onwards; PI required third-party adapters for REST.
  • Version relationship: PO includes all PI functionality — any organization running PO has complete PI capabilities plus orchestration.
  • End of maintenance: Both reach end of mainstream SAP maintenance in December 2027.

Common Adapters in SAP PI/PO

  • IDoc Adapter: SAP-native batch document exchange between SAP systems — the most common A2A adapter in ECC landscapes.
  • RFC Adapter: Synchronous calls to SAP function modules and BAPIs; enables real-time SAP-to-SAP communication.
  • SOAP Adapter: Web services over HTTP/HTTPS; essential for third-party system integration via standard web services.
  • REST Adapter (PO 7.5+): RESTful API connectivity for cloud and modern application integration.
  • JDBC Adapter: Direct database connectivity for SQL-based data exchange with non-SAP databases.
  • SFTP/FTP Adapter: File-based integration for batch data transfers — logistics, banking, HR file exchanges.
  • AS2 Adapter: B2B EDI communication over HTTPS with encryption and signing; required for many EDI trading partner connections.
  • Mail Adapter: Email-triggered integration and email delivery of processed output.
  • ABAP Proxy: Direct ABAP-to-PI/PO communication without an adapter; the preferred SAP-to-SAP integration method.

Third-party adapter providers (including MIP) extend the standard library with additional connectors for cloud platforms, banking APIs, and marketplace integrations.

SAP PI/PO vs SAP Integration Suite

With SAP PI/PO reaching end of mainstream maintenance in December 2027, the strategic successor is SAP Integration Suite — a cloud-native integration platform on SAP Business Technology Platform (BTP).

  • Deployment: PI/PO is on-premise; Integration Suite is cloud-native with hybrid extension via Edge Integration Cell.
  • Maintenance: PI/PO ends December 2027; Integration Suite is SAP’s active strategic investment.
  • Capabilities: Integration Suite adds API management, event mesh, AI-assisted mapping, and pre-built integration content alongside the Cloud Integration engine.
  • Licensing: Integration Suite uses consumption-based subscription; PI/PO uses perpetual license.
  • Migration tooling: SAP provides the Migration Toolkit inside Integration Suite to semi-automatically convert PI/PO integration objects (iFlows, mappings) to Cloud Integration. Standard scenarios (IDoc, RFC, file) migrate well; complex scenarios with custom Java mappings or ABAP proxy-heavy designs require manual re-engineering.

For organizations planning the transition, our SAP PI/PO to Integration Suite migration guide covers the full assessment and phased approach.

SAP PI/PO Monitoring

Operational monitoring in SAP PI/PO uses two primary tools. The Message Monitor (transaction SXMB_MONI or the PI monitoring UI) shows every processed message — sender, receiver, status (success, error, in-queue), and the full payload at each pipeline step including pre-mapping, post-mapping, and delivery. The Runtime Workbench (RWB) provides a higher-level view: component health, adapter channel status, and system resource utilization. Automated alerting via the Component-Based Message Alert Framework (CBMA) notifies administrators of failures without manual polling.

MDP Group provides 24/7 SAP PI/PO monitoring services for organizations that need continuous integration oversight without dedicated in-house PI/PO specialists on call.

Why Organizations Still Run SAP PI/PO

Despite the 2027 deadline, many enterprises continue operating PI/PO because migrations of complex integration landscapes take years, not months. Organizations with 200+ active interfaces, custom Java mappings, and ABAP proxy-based scenarios face significant re-engineering effort. On-premise PI/PO also meets data residency requirements that cloud deployments complicate for regulated industries. A phased migration — new interfaces on Integration Suite while existing PI/PO interfaces are gradually moved — is the standard approach MDP Group recommends.

Frequently Asked Questions

What is the difference between SAP XI, SAP PI, and SAP PO?

All three names refer to the same SAP integration middleware at different points in its evolution. SAP XI (Exchange Infrastructure) was the original name from 2002. It was renamed SAP PI (Process Integration) from version 7.1 onwards. SAP PO (Process Orchestration) is the final on-premise version, released in 2012, which added BPM and BRM capabilities to the PI integration engine on a single Java stack.

What is the difference between SAP PI and SAP PO?

SAP PI is the integration-only platform; SAP PO extends it with full BPMN 2.0 Business Process Management and Business Rules Management. PO runs on a single Java stack while PI required dual-stack (ABAP+Java) in older versions. Every PO system includes all PI capabilities plus orchestration — there is no functionality in PI that PO does not also have.

Is SAP PI/PO being discontinued?

SAP PI/PO mainstream maintenance ends December 31, 2027. After this date, SAP will no longer release support packages, security patches, or legal change updates under standard contracts. Extended maintenance (at additional cost) is available until 2030. SAP’s strategic path forward is migration to SAP Integration Suite.

What replaces SAP PI/PO?

SAP Integration Suite — specifically its Cloud Integration (formerly SAP CPI) component — is the strategic replacement for PI/PO’s message integration capabilities. Integration Suite also includes API Management, Event Mesh, and Data Integration, making it a broader platform than PI/PO alone.

What is ABAP Proxy in SAP PI/PO?

ABAP Proxy is a code generation mechanism that creates native ABAP classes from PI/PO interface definitions. These classes allow ABAP programs to call PI/PO integrations like local function modules, without writing XML or network code. It is the recommended integration pattern for communication between ABAP-based SAP systems and PI/PO because it is faster and more reliable than adapter-based alternatives.

How long does a migration from SAP PO to Integration Suite take?

Organizations with 50–100 interfaces typically plan 12–18 months. Those with several hundred interfaces, custom Java mappings, and complex ABAP proxy scenarios may plan 2–3 year migration programs. SAP’s Migration Toolkit accelerates standard scenarios; complex scenarios require manual re-engineering. A phased approach — moving new interfaces first while existing PI/PO interfaces follow in waves — is the lowest-risk migration pattern.

References


Similar
Blog

Your mail has been sent successfully. You will be contacted as soon as possible.

Your message could not be delivered! Please try again later.