PI/PO Migration Part 3: Mapping PO Concepts to Cloud Integration

📌 KEY POINTS
✅ Receiver and interface determination become routers, multicasts and splitters in iFlows.
✅ Most PO adapters have Cloud Integration equivalents; on-premise systems are reached through Cloud Connector.
✅ ABAP proxies keep working with the XI adapter, which supports the XI 3.0 protocol.
✅ PO BPM processes are redesigned with iFlow patterns, SAP Build Process Automation or event-driven designs.
⚠️ Replicating every PO design one-to-one can carry old complexity into the new platform.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 used tooling. Part 3 explains how to think when tooling can't decide for you.

━━━━━━━━━━━━━━━━━━━━
▶ 1. ROUTING
In PO, receiver determination and interface determination decide where messages go. In Cloud Integration, routing is part of the iFlow: routers with conditions, multicast for recipient lists, splitters for interface splits. Conditions use XPath or headers. The logic is the same; the tooling is visual.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ADAPTERS
SOAP, IDoc, RFC, HTTP, SFTP, mail, JDBC, JMS and others exist in Cloud Integration, plus many cloud adapters. On-premise systems are reached through SAP Cloud Connector with virtual hosts. File-based integrations usually move to SFTP; direct file system access is not available in the cloud runtime.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ABAP PROXIES
S/4HANA and ECC ABAP proxies communicating via XI 3.0 can talk to Cloud Integration with the XI adapter, keeping proxy implementations unchanged. The ABAP system's integration engine configuration points to Cloud Integration instead of PO.

━━━━━━━━━━━━━━━━━━━━
▶ 4. MAPPINGS AND MODULES
Graphical message mappings migrate. Java mappings and adapter modules are rewritten as Groovy scripts or replaced with standard steps such as converters, encoders or content modifiers. Reuse via script collections avoids copy-paste.

━━━━━━━━━━━━━━━━━━━━
▶ 5. BPM AND STATEFUL LOGIC
PO BPM processes with waits, correlations and human steps don't map directly. Options are iFlow patterns with data stores and JMS, event-driven designs with Event Mesh, or SAP Build Process Automation for human workflow. Use migration as a chance to simplify.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Map one PO receiver determination to an iFlow router.
2. Identify adapter equivalents for a list of PO channels.
3. Configure an ABAP proxy scenario with the XI adapter in test.
4. Rewrite a small Java mapping in Groovy.

✅ CHECKPOINT: you can translate any PO interface design into Cloud Integration concepts.

A team planned to rewrite 120 ABAP proxy interfaces as SOAP web services for the migration. Using the XI adapter instead kept all proxy implementations unchanged; only the integration engine configuration was switched to Cloud Integration, saving months of ABAP work.

• Rewriting ABAP proxies unnecessarily.
• One-to-one copies of overly complex designs.
• Assuming file system access in the cloud.
• Copy-pasting Groovy across iFlows.

• XI adapter for proxies.
• Simplify during migration.
• SFTP and Cloud Connector for on-premise.
• Script collections for reuse.

Interviewers ask how PO concepts map to Cloud Integration, especially receiver determination, adapters, ABAP proxies, Java mappings and BPM processes.