SAP CPI: was es ist, die Architektur und der Umstieg von PI/PO

SAP CPI (Cloud Platform Integration) ist die Cloud-Middleware von SAP, mit der Sie SAP- und Nicht-SAP-Systeme verbinden. Heute heißt sie Cloud Integration und ist die Kernfunktion der SAP Integration Suite auf der SAP Business Technology Platform (SAP BTP).

Sie überträgt Nachrichten zwischen Anwendungen, wandelt ihr Format um und leitet sie an das richtige Ziel weiter. Wenn Sie noch SAP PI/PO betreiben, läuft die Uhr: Die Standardwartung für SAP NetWeaver 7.5, zu dem PI/PO gehört, endet Ende 2027.

Dieser Leitfaden zeigt, was CPI leistet, wie die Architektur funktioniert, wie es sich mit PI/PO vergleicht und wie Sie den Umstieg planen. Er richtet sich an Integrationsverantwortliche und CIOs, nicht nur an Entwickler.

Ich habe Teams gesehen, die Monate damit verbracht haben, fragile eigene Skripte zu bauen, um SAP- und Nicht-SAP-Systeme zu verbinden. Zuerst funktioniert etwas. Dann ändert ein Systemupdate einen Feldnamen, oder eine neue API-Version wird ausgerollt, oder der Datenverkehr verdoppelt sich.

Das Skript bricht leise. Niemand merkt es, bis ein Bericht veraltete Daten zieht oder ein Auftrag drei Tage unbearbeitet liegt.

CPI ersetzt das durch verwaltete, wiederverwendbare Integrationsflüsse. Nicht, weil es einfacher ist (oft ist es das nicht), sondern weil die Architektur darauf ausgelegt ist, überwacht und gewartet zu werden. Kleine Entscheidungen, die früh im CPI-Design fallen, wachsen schneller zu technischer Schuld an, als die meisten Teams erwarten.

Mein Rat an jedes Unternehmen, das noch auf SAP PI/PO ist: Wechseln Sie zur SAP Integration Suite. Der häufigste Integrationsfehler, den ich sehe, ist, zu wenig Zeit in die Integration zu stecken.

SAPs eigener Migrationsleitfaden beschreibt Cloud Integration als die Funktion, mit der Integrationsflüsse über Cloud-, On-Premise- und hybride Landschaften gestaltet und betrieben werden. Sie deckt Szenarien von Anwendung zu Anwendung (A2A), von Unternehmen zu Unternehmen (B2B) und von Unternehmen zu Behörden (B2G) ab. Die meisten Berater sagen weiterhin „CPI“ oder „SAP CI“ dazu, und das ist in Ordnung.

Die SAP Integration Suite bündelt Cloud Integration mit weiteren Funktionen. Die wichtigsten sind API Management, Event Mesh, Integration Advisor, Trading Partner Management, Open Connectors und Migration Assessment.

Was CPI leistet: überträgt Daten zwischen Systemen, wandelt Nachrichtenformate um, leitet an das richtige Ziel weiter und behandelt Fehler und Wiederholungen. Es verbindet SAP-Systeme (S/4HANA, SuccessFactors, Ariba) und Nicht-SAP-Plattformen (Salesforce, Workday, ServiceNow) über Standardadapter.

Was es nicht leistet: Daten langfristig speichern, ein ERP ersetzen oder als ETL-Werkzeug für die Massendatenmigration dienen. Es ist für Nachrichten in Echtzeit oder nahezu in Echtzeit gebaut. Wer es als Data Warehouse oder Migrationswerkzeug nutzt, bekommt später Architekturprobleme.

CPI im Vergleich zu SAP BTP: BTP ist die gesamte Plattform: Anwendungsentwicklung, Daten, KI, Analytics und Integration. CPI ist ein Service darauf. Ein BTP-Architekt plant über Services hinweg; ein CPI-Spezialist verantwortet Flüsse, Adapter, Mappings und Konnektivität.

Das Diagramm unten zeigt die Integrationsszenarien, für die CPI gebaut ist. Cloud zu Cloud, On-Premise zu Cloud, Unternehmen zu Unternehmen (B2B), Unternehmen zu Behörden (B2G) und Verbindungen zu Anwendern und Geräten.

Die CPI-Architektur zu verstehen ist nicht nur Sache der Entwickler. Nach meiner Erfahrung treffen Teams, die begreifen, wie CPI Integration auf struktureller Ebene behandelt, von Anfang an bessere Designentscheidungen.

CPI läuft als mandantenfähiger Cloud-Service auf SAP BTP. SAP betreibt die Plattform, Sie warten also keine eigenen Integrationsserver. Wo ein Fluss innerhalb Ihres eigenen Netzwerks laufen muss, ist die Edge Integration Cell eine optionale hybride Laufzeit: Sie gestalten und überwachen in der Cloud und führen den Fluss in Ihrem eigenen Netzwerk aus.

Der Nachrichtenfluss in der Praxis

Im Kern steht der iFlow (Integrationsfluss). Jede Integration in CPI wird als iFlow modelliert, und jeder iFlow bringt eine Nachricht in drei Stufen von einer Quelle zu einem Ziel:

1. Sender-Adapter. Empfängt die Nachricht vom Quellsystem über SOAP, REST, OData, IDoc, SFTP, JMS, AS2 oder ein anderes Protokoll.
2. Verarbeitungsschritte. Mapping, Formatumwandlung (zum Beispiel JSON zu XML), inhaltsbasiertes Routing, Aufrufe anderer Systeme, Verschlüsselung und Fehlerbehandlung.
3. Empfänger-Adapter. Sendet die verarbeitete Nachricht an ihr Ziel.

Flüsse laufen synchron oder asynchron, je nach Anwendungsfall. Welche Variante die richtige ist, ist nicht immer offensichtlich, also testen Sie beide mit echten Volumina.

Das Monitoring spielt eine große Rolle. Es gibt Nachrichtenverarbeitungsprotokolle, Trace und persistierte Nachrichten, jeweils für einen anderen Zweck. Beim Testen oder Debuggen wechsle ich meist zwischen Trace und Persist, je nachdem, wie tief ich gehen muss.

Komponenten der SAP-CPI-Architektur

Die Tabelle ordnet jeder Komponente ihre Aufgabe in der Architektur zu.

Komponente	Was sie tut	Rolle in der Architektur
Laufzeit für Integrationsflüsse	Führt iFlows aus	Übernimmt zur Laufzeit Routing, Mapping, Transformation und Sicherheit
Webbasierter Designer	Grafischer Editor zum Bauen, Konfigurieren und Deployen von iFlows	Hier modellieren Entwickler die Flüsse; komplexe Logik braucht weiterhin Groovy oder JavaScript
Adapter	SOAP, REST, OData, IDoc, JDBC, SFTP, JMS, AS2 und SaaS-spezifische Adapter	Verbinden Cloud- und On-Premise-Systeme
Sicherheit	OAuth 2.0, SAML, TLS, Zertifikats- und Schlüsselverwaltung	Schützt Zugangsdaten und Nachrichten bei der Übertragung
Monitoring und Betrieb	Nachrichtenprotokolle, Fehlerdetails, Wiederholungen, Alerting	Ermöglicht Supportteams, Fehler zu finden und zu beheben
Vorkonfigurierter Content	Von SAP gelieferte Integrationspakete im SAP Business Accelerator Hub	Beschleunigt Standardszenarien mit getestetem Content
SAP Cloud Connector	Sicherer Tunnel aus Ihrem Netzwerk zu SAP BTP	Erreicht On-Premise-Systeme, ohne sie dem Internet auszusetzen
Edge Integration Cell	Optionale Laufzeit in Ihrem eigenen Rechenzentrum oder Ihrer Private Cloud	Für Flüsse, die On-Premise bleiben müssen

Groovy-Skripte übernehmen Logik, die die grafischen Schritte nicht abbilden können. Ich empfehle oft, das schlank zu halten, denn zu viel Skripting führt später zu Wartungsproblemen. Pakete sind versioniert, also geht keine Änderung außerhalb eines deployten Pakets in die Produktion.

Drei Termine bestimmen derzeit fast jeden Integrationsplan.

1. 2027Standardwartung für PI/PO endetJahresende, für SAP NetWeaver 7.5
2. 2028Cloud Integration auf Neo wird abgeschaltet31. Dezember. Neo-Tenants ziehen nach Cloud Foundry um
3. 2030Erweiterte Wartung für PI/PO endetJahresende. Die letzte Station für jedes PI/PO-System

Quelle: SAP-Hinweis 1648480 und SAP-Knowledge-Base-Artikel 3355661

1. PI/PO geht der Weg aus. SAP-Hinweis 1648480 legt die Standardwartung für SAP NetWeaver 7.5, zu dem PI/PO gehört, bis Ende 2027 fest, mit erweiterter Wartung bis Ende 2030. Das System bleibt am 1. Januar 2028 nicht stehen, aber jedes Jahr danach kostet der Weiterbetrieb mehr.
2. Neo schließt. Der SAP-Knowledge-Base-Artikel 3355661 bestätigt, dass Cloud Integration in der Neo-Umgebung von SAP BTP am 31. Dezember 2028 abgeschaltet wird. Ältere CPI-Tenants auf Neo müssen in die Multi-Cloud-Umgebung (Cloud Foundry) umziehen, und dieser Umzug ist ein eigenes kleines Projekt.
3. Für hybride Szenarien gibt es eine Antwort. Die Edge Integration Cell führt Flüsse der Integration Suite innerhalb Ihres eigenen Netzwerks aus. Damit entfällt der häufigste Grund, den Teams für den Verbleib auf PI/PO genannt haben.

Zur kaufmännischen Seite: Wenn Sie RISE with SAP nutzen, prüfen Sie, welche SAP-BTP-Berechtigung Ihr Vertrag bereits enthält, bevor Sie Kapazität für die Integration Suite separat kaufen.

PI (Process Integration) und PO (Process Orchestration) sind die On-Premise-Middleware von SAP. So schneiden sie im Vergleich zu CPI ab.

Faktor	SAP PI/PO	SAP CPI (Integration Suite)
Betrieb	On-Premise, Ihre Server	Cloud auf SAP BTP; Edge Integration Cell für eine On-Premise-Laufzeit
Wartungsaufwand	Hoch: Patches, Upgrades, Serververwaltung	Geringer: SAP betreibt die Plattform
Erweiterbarkeit	Tiefe Anpassung; schwerer zu aktualisieren	Modular; schnellere Updates; weniger Kontrolle auf unterer Ebene
Lizenzierung	Lizenz plus eigene Infrastruktur	Abonnement auf SAP BTP, je nach Edition
Investitionsrichtung	Nur Wartung, keine neuen Funktionen	Aktive Weiterentwicklung
Ende der Standardwartung	Ende 2027 (erweitert bis Ende 2030)	Nicht zutreffend (Cloud-Service)

Der Migrationsleitfaden von SAP behandelt Cloud Integration als Hauptersatz, weil es den Großteil dessen abdeckt, was PI/PO leistet. Fragen Sie SAP, wie Ihre Edition gemessen wird, und rechnen Sie das gegen Ihre echten Nachrichtenvolumina durch, bevor Sie migrieren. Manche Unternehmen stellen fest, dass ihr Integrationsverkehr höher ist als gedacht.

Die Migration ist keine automatische Konvertierung. Adapter verhalten sich in PI und CPI unterschiedlich, und Fehlerbehandlung, die in PI funktioniert hat, kann sich in CPI anders verhalten. Manche Flüsse müssen neu gebaut werden; andere ziehen mit kleinen Änderungen um.

SAP stellt zwei offizielle Werkzeuge bereit:

1. Migration Assessment. Eine Funktion der Integration Suite, die sich mit Ihrem PO-System verbindet, Integrationsszenarien extrahiert und den Aufwand für ihren Umzug schätzt. SAPs Tutorial beschreibt die Einrichtung.
2. Migration Tooling. Eine Funktion von Cloud Integration, die die Migration teilautomatisiert, nämlich die von integrierten Konfigurationsobjekten (ICOs) aus PO in iFlows. Nur Szenarien, die als „Ready to migrate“ oder „Adjustment required“ bewertet wurden, lassen sich damit migrieren.

SAP Learning stellt klar, dass kein einzelner Migrationspfad zu jedem Kunden passt, und viele betreiben PI/PO und die Integration Suite während des Umstiegs parallel. Die Werkzeuge verringern die mechanische Arbeit. Die Abwägung, was neu gebaut und was stillgelegt wird, nehmen sie Ihnen nicht ab.

Hier ist der Wellenplan, den ich als Ausgangspunkt nutze. Passen Sie die Wellen an Ihr eigenes Inventar an.

Welle	Was umzieht	Warum diese Reihenfolge	Verantwortlich	Abschlusskriterien
0. Inventar	Jede PI-Schnittstelle: Häufigkeit, Volumen, Adapter, Kritikalität, Verantwortlicher	Sie können nicht planen, was Sie nicht gezählt haben	Integrationsleitung	Inventar von den fachlichen Verantwortlichen abgezeichnet
1. Geringes Risiko	SAP-zu-SAP-Flüsse mit Standard-Content	Belegt das Betriebsmodell und das Monitoring	Integrationsleitung	Zwei Wochen stabil in Produktion, PI-Pfad stillgelegt
2. Partner	B2B- und EDI-Flüsse mit wichtigen Handelspartnern	Braucht Testfenster mit Partnern und eine abgestimmte Umstellung	Integrationsleitung mit Einkauf und Vertrieb	Jeder Partner bestätigt schriftlich
3. Hohes Risiko	Flüsse mit hohem Volumen, regulierte oder umsatzkritische Flüsse	Zieht zuletzt um, mit den meisten Generalproben	Integrationsarchitekt	Volumentest bestanden; Rückfall auf PI geprobt
4. Stilllegung	PI/PO abgeschaltet	Beendet die Kosten für zwei Plattformen	CIO	Alle Flüsse migriert oder stillgelegt; Lizenzen beendet

Halten Sie für jede Welle einen Rückfallweg zu PI bereit, bis der neue Fluss sauber in Produktion gelaufen ist. Die Reihenfolge zählt: Belegen Sie das Betriebsmodell an Flüssen mit geringem Risiko, bevor Sie die Schnittstellen anfassen, die Umsatz tragen.

Beim Integrationstest verschwindet die Zeit. Planen Sie Regressionstests mit B2B-Partnern und Nicht-SAP-Zielen früh ein, denn die brechen leise. Mein Leitfaden zu SAP-Tests zeigt, wie Sie Integrations- und Regressionszyklen strukturieren.

Wenn der Umstieg von PI/PO Teil eines S/4HANA-Programms ist, stimmen Sie die beiden Pläne aufeinander ab. Mein Leitfaden zur Migration von ECC auf S/4HANA behandelt die Wege und Fristen auf der ERP-Seite.

Die Szenarien, die ich am häufigsten sehe:

1. S/4HANA zu SuccessFactors. Organisationsdaten, Personalbestand und Vergütungsänderungen. Der Standard-Integrationscontent von SAP deckt die gängigen Szenarien ab; eigene Flüsse übernehmen die Abweichungen.
2. Altes Beschaffungssystem zu SAP Ariba. Bestellungen hinaus, Bestätigungen und Rechnungen zurück. Meist in beide Richtungen.
3. Finanzdaten zu SAP Analytics Cloud. Daten aus ECC oder Nicht-SAP-Systemen in SAC übertragen.
4. Salesforce zu SAP. Abgeschlossene Geschäfte fließen zur Auftragserfüllung, Fakturierung und Bestandsaktualisierung in SAP. Mein Beitrag dazu, warum Integrationen zwischen Salesforce und ERP scheitern, behandelt die Designfehler.

Wenn die Integrationsarbeit in Ihrem Programm bereits in Verzug gerät, behandelt Verzögerungen bei der Lieferung mit der SAP Integration Suite die üblichen Ursachen. Die Übersicht über SAP-Integrationsplattformen vergleicht die Optionen nebeneinander.

Was ist SAP CPI und wie heißt es heute?

SAP CPI steht für Cloud Platform Integration. Heute ist es die Funktion Cloud Integration der SAP Integration Suite auf SAP BTP, neben API Management, Event Mesh und Werkzeugen für die Partnerintegration. „CPI“ ist weiterhin der Alltagsname für das Bauen von Integrationsflüssen.

Was ist SAP CI?

SAP CI ist die Kurzform für SAP Cloud Integration, den aktuellen Namen dessen, was früher SAP CPI hieß. Beide Begriffe bezeichnen dieselbe Funktion innerhalb der SAP Integration Suite.

Ist SAP CPI eine Middleware?

Ja. CPI ist Cloud-Middleware: Sie sitzt zwischen Systemen, transformiert und routet Nachrichten und behandelt Fehler und Wiederholungen. Sie ersetzt On-Premise-Middleware wie SAP PI/PO und speichert Geschäftsdaten nicht langfristig.

Wie unterscheidet sich SAP CPI von SAP PI/PO?

PI/PO ist On-Premise-Middleware, die Sie selbst installieren, patchen und betreiben. CPI ist ein Cloud-Service auf SAP BTP, den SAP für Sie betreibt, und neue Adapter und Inhalte kommen zentral hinzu. Die Edge Integration Cell deckt Flüsse ab, die On-Premise bleiben müssen.

Wann endet der Support für SAP PI/PO?

Die Standardwartung für SAP NetWeaver 7.5, zu dem PI/PO gehört, endet Ende 2027. Erweiterte Wartung ist bis Ende 2030 verfügbar. SAP bietet Migration Assessment und Migration Tooling an, um Szenarien in die Integration Suite zu übertragen.

Ist SAP CPI dasselbe wie SAP BTP?

Nein. SAP BTP ist die Plattform: Anwendungsentwicklung, Daten, Analytics, KI und Integration. CPI ist der Integrationsservice darauf.

Bei der Planung von Arbeiten unterscheiden sich Budget und Kompetenzen: Ein BTP-Architekt arbeitet über Services hinweg, ein CPI-Spezialist verantwortet Flüsse, Adapter und Mappings.

Wenn Sie einen Umstieg von PI/PO planen oder die Integration für ein neues S/4HANA-Programm gestalten, beginnen Sie mit dem Schnittstelleninventar. Wenn Sie eine zweite Meinung zum Plan möchten, bevor Sie sich festlegen, nehmen Sie Kontakt auf.