Where integration started

Before Integration Suite, before SAP Cloud Platform, before BTP — SAP customers built all their system-to-system integrations on SAP Process Integration (PI) and its successor SAP Process Orchestration (PO).

Understanding PI/PO is not just historical trivia. Thousands of companies still run PI/PO today. Many Integration Suite projects are migrations from PI/PO. And the integration concepts that PI/PO established — adapters, message mappings, routing rules, monitoring — are still present in Cloud Integration (CPI) on BTP, just with a different architecture underneath.

SAP PI — Process Integration

SAP NetWeaver Process Integration (SAP PI) was launched in 2005, built on the SAP NetWeaver Java Application Server. Before PI, SAP interfaces were built directly in ABAP on both sides of every connection — a bespoke, point-to-point approach that created unmaintainable integration spaghetti.

PI introduced the concept of a central integration hub — all interface traffic passes through one system, where it can be monitored, logged, and managed.

PI architecture components:

System Landscape Directory (SLD) — A central registry of all systems in the landscape. Every sender and receiver system registers in the SLD. PI uses the SLD to resolve routing rules.

Enterprise Services Repository (ESR) — Stores all integration artefacts: data type definitions, message types, message interfaces, and mapping programs. This is where integration objects are designed.

Integration Directory (ID) — The runtime configuration: which sender sends which message to which receiver via which mapping. Configuration in the ID references objects in the ESR.

Adapter Framework — Runtime adapters for connecting to different protocols and systems: IDoc, ABAP Proxy, RFC, SOAP, HTTP, JMS, FTP, JDBC, and more.

Integration Engine (ABAP) — The ABAP-side component on the SAP source/target systems that handles IDoc and Proxy-based communication.

Advanced Adapter Engine (Java) — The Java-based engine handling all non-ABAP adapters (HTTP, SOAP, FTP, SFTP, JDBC, etc.).

SAP PO — Process Orchestration

SAP Process Orchestration (PO) replaced PI around 2012, consolidating three previously separate products:

  1. SAP PI — Integration
  2. SAP BPM (Business Process Management) — Workflow and process automation
  3. SAP BRM (Business Rules Management) — Decision table-based business rules

PO brought all three onto a unified Java Application Server (SAP NetWeaver 7.31+), sharing infrastructure and offering more integrated tooling.

PO 7.5 (released 2016) is the most widely deployed version and the one most customers run today.

Building an interface in PI/PO

A PI/PO integration (called a "scenario") required configuration across multiple tools:

  1. SLD — Register sender system and receiver system
  2. ESR — Create data types and message types for both sender and receiver formats; create message interfaces; build XSLT or graphical mapping
  3. ID — Create communication channels (one per adapter per system); create sender and receiver agreements; create interface determinations and receiver determinations
  4. Alert configuration (optional) — Set up monitoring alerts

A simple file-to-IDoc interface might involve 20+ distinct configuration objects spread across ESR and ID. Changes required transporting through DEV → QAS → PRD using the Change and Transport System (CTS+).

Why PI/PO worked

Despite the complexity, PI/PO was very capable:

  • Breadth of adapters — Supported almost every enterprise protocol out of the box
  • Central monitoring — Every message visible in the Message Monitoring (MONI) transaction
  • ABAP-side integration — Native IDoc and Proxy support meant SAP-to-SAP scenarios were very reliable
  • Schema validation — Messages could be validated against XSD schemas in flight
  • Reusability — Shared data types and mappings in ESR
  • BPM integration — Complex multi-step processes with human tasks possible through PO BPM

Why PI/PO's time has passed

Maintenance cost — PI/PO is a full Java Application Server, requiring dedicated Basis expertise (SAP NetWeaver Java administration) separate from the ABAP Basis team. Two stacks, two teams, double the complexity.

Infrastructure cost — A proper PI/PO landscape requires DEV, QAS, and PRD systems, each on sizeable Java application servers with their own databases.

Release cadence — On-premise PI/PO releases once every few years. Integration Suite on BTP releases every six weeks.

Cloud adapter gaps — PI/PO was built for on-premise-to-on-premise. Connecting to cloud APIs, OAuth-protected REST APIs, modern SaaS applications, or GraphQL endpoints was bolted on, not native.

End of mainstream maintenance — SAP PI/PO on-premise mainstream maintenance ends in 2027, with paid extended maintenance until 2030. The same deadline as ECC. The message is clear: migrate.

Developer experience — Configuring PI/PO required opening multiple browser-based tools (SLD, ESR, ID) and navigating SAP-Java UI patterns that feel dated. Integration Suite runs in a modern browser-based workbench.

The next module covers why SAP Integration Suite is the answer to all of these limitations.