SAP Integration Suite: Entscheidungen und Abwägungen im Produktivbetrieb

SAP Integration Suite ist die Integrationsplattform von SAP auf SAP BTP: Cloud Integration (das frühere CPI) plus API Management, Event Mesh, Integration Advisor, Open Connectors und Werkzeuge für die Migration von PI/PO. Sie ist die Standard-Middleware für S/4HANA-Cloud-Programme und der Weg weg von PI/PO, dessen Mainstream-Wartung 2027 endet. Verzögerungen bei Schnittstellen kommen selten aus der Technik. Sie kommen aus unklaren Zuständigkeiten, ungeprüften Annahmen über Legacy-Systeme und Tests, die darauf ausgelegt sind zu bestehen, statt Fehler zu finden. Dieser Leitfaden richtet sich an Integrationsverantwortliche, Architekten und Programmmanager. Er behandelt, wofür jede Komponente da ist, Standard- gegenüber Eigenentwicklung, die PI/PO-Migration, Legacy- und Testrisiken sowie die Governance nach dem Go-live.

PI/PO läuft die Zeit davon. SAP Process Integration und Process Orchestration 7.5 befinden sich bis Ende 2027 in der Mainstream-Wartung. Optionale erweiterte Wartung läuft bis Ende 2030, danach endet der SAP-Support. Die Migrationsreferenzarchitektur von SAP beschreibt den Weg. Integration Suite enthält eine Migration-Assessment-Anwendung, die den Aufwand jedes PI/PO-Szenarios abschätzt, sowie assistentengestützte Migrationswerkzeuge in Cloud Integration. Migrieren Sie in Wellen: zuerst risikoarme SAP-zu-SAP-Flows, in der Mitte B2B und EDI, zuletzt Order-Flows mit hohem Volumen. Eine erzwungene Umstellung unter Termindruck dauert länger und kostet mehr.

1. Welle 1Risikoarme SAP-zu-SAP-FlowsZuerst jedes Szenario mit Migration Assessment bewerten
2. Welle 2B2B und EDI
3. Welle 3Order-Flows mit hohem Volumen
4. 2027Mainstream-Wartung für PI/PO 7.5 endetJahresende. Planen Sie die Wellen so, dass sie davor fertig sind
5. 2030Optionale erweiterte Wartung endetJahresende. Danach endet der SAP-Support

Quelle: SAP-Wartungstermine und Migrationsreferenzarchitektur, geprüft im Oktober 2026

Prüfen Sie, was Ihr Cloud-Vertrag abdeckt. RISE- und GROW-Verträge enthalten in der Regel SAP-BTP-Credits, mit denen sich Integration Suite bezahlen lässt. Klären Sie, welche Edition und welche Nachrichtenvolumen Ihr Anspruch abdeckt, bevor Sie Integration Suite allein nach Funktionen mit MuleSoft oder Boomi vergleichen. Die Wirtschaftlichkeit einer enthaltenen Plattform verändert den Vergleich.

KI kommt in Stufen. Cloud Integration bietet in der Premium Edition seit Mitte 2024 die Generierung von Flows per generativer KI. Sie erzeugt die Struktur eines iFlows (Schritte, Kanäle, Ausnahme-Subprozess), nicht die Mappings oder Skripte. Die erweiterte Edition von SAP, im März 2026 gestartet, ergänzt Text-to-Flow-Generierung und Skriptoptimierung, und SAP hat Joule in Integration Suite für die allgemeine Verfügbarkeit im dritten Quartal 2026 geplant. Nützlich für Standard-Flows. Komplexe Orchestrierung mit tiefer Geschäftslogik braucht weiterhin erfahrene Architekten.

Integration Suite ist eine Sammlung von Diensten. Den passenden Dienst für die jeweilige Aufgabe zu nutzen entscheidet darüber, wie gut die Landschaft hält.

Komponente	Rolle	Was schiefgeht, wenn sie falsch eingesetzt wird
Cloud Integration (CPI)	Nachrichtenflüsse, Routing und Transformation; der Standard für die meisten iFlows	Wird alles in CPI gestopft, auch APIs und Events, ist es schwer zu betreiben und zu testen
API Management	Steuert die Bereitstellung von APIs: Sicherheit, Ratenbegrenzungen, Analytik	Wer es auslässt, bekommt immer mehr Punkt-zu-Punkt-Aufrufe; Governance lässt sich schwer nachrüsten
Event Mesh	Asynchrone Nachrichtenübermittlung für entkoppelte Auslöser	Nicht überwachte Queues wachsen unbemerkt, ohne dass jemand alarmiert wird
Integration Advisor	Mapping-Vorschläge für B2B-Formate wie EDIFACT, X12 und IDoc	Teams gehen von hoher Abdeckung aus; ein Team erwartete 80 % und kam eher auf 40 %
Open Connectors	Vorgefertigte Konnektoren zu Cloud-Anwendungen von Drittanbietern	Änderungen an externen APIs brechen Konnektoren unbemerkt, solange niemand sie überwacht
Migration Assessment und Werkzeuge	Bewertet und migriert PI/PO-Szenarien	Wird als einmalige Schätzung behandelt statt als funktionierender Migrationsplan

Teams, die Integration Suite als „CPI mit Extras“ behandeln, ignorieren oft API Management und Event Mesh. Das geht gut, bis die Komplexität sie einholt. Mein Leitfaden zu SAP CPI geht tiefer auf Cloud Integration selbst ein.

Vorgefertigter SAP-Integrationscontent ist wirklich nützlich, wenn der Prozess standardnah ist. S/4HANA mit SAP Ariba oder SuccessFactors über Standardprozesse zu verbinden passt oft sauber. Echte Prozesse bleiben selten innerhalb der Referenzlinien von SAP.

Wählen Sie Standard-Content, wenn:

1. das Szenario SAP-zu-SAP ist und nah am Referenzprozess von SAP liegt
2. der Flow einfach und überwiegend einseitig ist
3. Sie mit dem Mapping von SAP leben können und nur über die vorgesehenen Exits erweitern

Wählen Sie eine Eigenentwicklung, wenn:

1. jahrelange interne Entscheidungen den Prozess vom Modell von SAP entfernt haben
2. bedingtes Routing, mehrstufige Logik oder Eigenheiten von Legacy-Systemen im Spiel sind
3. umfangreiche Änderungen die Support-Ausrichtung am SAP-Standardpaket aufheben würden

Treffen Sie die Entscheidung in der Blueprint-Phase. Fällt sie spät, stellen Teams mitten im Projekt fest, dass ein „Standard“-iFlow so stark verändert wurde, dass er die Support-Ausrichtung verloren hat, und bauen ihn unter Go-live-Druck neu. Ich habe erlebt, dass Projekte Wochen verloren, weil Teams annahmen, Standard-Content würde kundeneigene Stammdatenstrukturen, zusätzliche Felder und Legacy-Authentifizierung gleichzeitig verkraften. Das tat er nicht. Die Analyse, die ins Design gehörte, fand im UAT statt.

In großen SAP-Programmen fällt Integration oft als Erstes zwischen die Arbeitsströme. Schnittstellen überschreiten Teamgrenzen, aber niemand verantwortet die Abstimmung. Ich habe erlebt, dass zwei Projektteams getrennte Integrationen für denselben Geschäftspartner bauten, mit demselben Endpunkt, ohne voneinander zu wissen. Keines der Teams merkte es vor dem UAT. Das ist ein strukturelles Versagen, kein technisches.

Richten Sie früh eine zentrale Integrations-Governance ein:

1. Ein gemeinsames Integrations-Backlog, das jeder Arbeitsstrom sieht
2. Eine benannte verantwortliche Person für jede Schnittstelle, über die gesamte Umsetzung hinweg nachverfolgt
3. Abstimmungs-Checkpoints zwischen den Arbeitsströmen vor jedem größeren Deployment
4. Eine Prüfung der Schnittstellenabhängigkeiten vor jeder Go-live-Zusage, mit gemeinsamen Endpunkten und Queues, die im Cutover-Plan in die richtige Reihenfolge gebracht sind
5. Automatisiertes Deployment zwischen Umgebungen, mit dokumentierten Zugangsdaten je Landschaft

Die schwierigsten Integrationsprobleme sind selten die modernen Plattformen. Es sind die älteren Systeme mitten in kritischen Prozessen.

Ältere ERPs können oft keine gleichzeitigen synchronen Aufrufe verarbeiten. Schicken Sie fünf parallele API-Aufrufe, und der Server wird langsam, friert ein oder verliert stillschweigend Daten. Asynchrone Integration hilft nur, wenn das empfangende System eine Queue abarbeiten kann, und viele können das nicht.

Protokoll-Unterschiede sind häufig und werden spät entdeckt. Sie entwerfen mit OAuth2 und REST; das Legacy-System spricht SOAP mit einem fest codierten Timeout von 30 Sekunden und behandelt die Token-Erneuerung schlecht.

In einem Kundenfall scheiterte ein Middleware-Flow jeden Freitag, weil das Token, das ein Payroll-System eines Drittanbieters ausstellte, wöchentlich ablief. Niemand bemerkte es bis zum zweiten UAT-Zyklus. Solche Eigenheiten sind häufig, und sie fressen Zeitpläne auf.

Die Tabelle nennt die Risiken, die Sie vor dem Design-Freeze prüfen sollten.

Risiko	Typisches Problem	Was im Design zu tun ist
Synchrone Grenzen	Legacy blockiert bei parallelen Aufrufen	Asynchrone Nachrichtenübermittlung nutzen; Aufrufe über Event Mesh oder Cloud Integration entzerren
Protokoll-Unterschied	Legacy lehnt REST oder OAuth ab oder läuft bei SOAP in den Timeout	Protokolle und Timeouts bestätigen, bevor das Design beginnt
API-Ratenbegrenzungen	Batch-Jobs überschreiten die Drosselung von Drittanbietern	In API Management drosseln; Wartelogik im iFlow ergänzen
Ablauf von Token	Flows scheitern in verkehrsarmen Zeitfenstern stillschweigend	Erneuerungszyklen planen und den Ablauf überwachen
Starre Formate	Dynamische Payloads brechen das Parsing des Legacy-Systems	Mit echten Produktionsmustern validieren
Kein Fallback	Dateiübertragungen scheitern ohne Wiederholung, und Daten bleiben hängen	In der Middleware puffern; Wiederholung und Alarmierung in iFlows einbauen

Die Cloud-übergreifende Variante dieser Probleme behandelt mein Beitrag dazu, warum ERP-Integration mit Salesforce scheitert.

Integration bricht nicht so, wie funktionale Tests es prüfen. Sie scheitert unter Zeitdruck, wenn sich Hintergrundjobs überlagern und wenn Eingaben in Menge statt einzeln eintreffen. Ein funktionaler Test belegt, dass eine Transaktion gebucht wird und eine Nachricht im Log erscheint. Er belegt nicht, was passiert, wenn der erste Abrechnungslauf eine Flut von IDocs sendet. In einem Projekt blockierte ein IDoc, das im Systemintegrationstest sauber aussah, die Queue, als echte Abrechnungsvolumen eintrafen. Nur ein Lasttest fand es.

Schnittstellentests müssen abdecken:

1. Realistische Datenmengen mit gleichzeitigen Benutzern
2. Dienstunterbrechungen und das Verhalten bei der Wiederherstellung
3. Timeouts und Wiederholungen über Middleware und Backends hinweg
4. Batch-Jobs, die neben Echtzeit-Aufrufen laufen
5. Monatsende und andere Spitzenzeiten

Entwicklungsumgebungen sind sauber. Deadlocks, Race Conditions und Drosselung zeigen sich im UAT und in der Vorproduktion, wo andere Systeme und Batch-Fenster live sind, also führen Sie dort Lasttests durch. Teilen Sie die Verantwortung klar auf: Fachteams validieren die Geschäftsergebnisse über den gesamten Flow, Integrationsteams verantworten Logs, Wiederholungen und Ausnahme-Flows, und Projektleiter bestätigen die Abdeckung. Mein Leitfaden zu SAP-Performancetests behandelt die Lastseite.

Integration Advisor schlägt Mappings für strukturierte B2B-Formate vor. Bei Partnern, die strikten Konventionen folgen, spart er echte Einrichtungszeit. Bei Unternehmensintegrationen mit Legacy-Systemen, kundeneigenen Feldern, bedingter Logik und undokumentierten Regeln ist er ein Ausgangspunkt.

Ein Team, mit dem ich gearbeitet habe, erwartete 80 % Mapping-Abdeckung. Tatsächlich lag die Abdeckung bei etwa 40 %. Der Rest musste angepasst, mit dem Fachbereich validiert und manuell getestet werden.

Er löst keine Geschäftslogik, die sich über Jahre informell aufgebaut hat (Zahlungsbedingungen, Preiskategorien, Mengeneinheiten-Konventionen), keine bedingten Regeln, die vom Geschäftskontext abhängen, und keine Ausnahmen außerhalb des Standardformats. Dafür braucht es fachlichen Input. Ohne ihn sind Schnittstellen technisch gemappt und in bestimmten Fällen logisch falsch.

Integration verfällt nach dem Go-live, wenn die Dokumentation driftet und die Zuständigkeit nicht formal geregelt ist. Nützliche Dokumentation umfasst Feld-Mappings und Transformationslogik sowie Authentifizierungsdetails wie Endpunkte, Token-Erneuerung und Rotation von Zugangsdaten. Sie umfasst außerdem Fehlerbehandlung, Fallback-Regeln und Volumenerwartungen für kritische Zeitfenster wie Monatsende und Abrechnung. Der Test: Könnte jemand, der nächste Woche ins Support-Team kommt, eine ausfallende Schnittstelle allein anhand der Dokumentation analysieren?

Jede Schnittstelle, auch eine mit geringem Volumen, braucht eine benannte verantwortliche Person für Überwachung, Eskalation und Lifecycle-Änderungen. Ohne sie wandern Fehler zwischen Basis, Middleware und Fachteams hin und her, während der Fachbereich wartet. Nach der Hypercare lässt die Überwachung meist nach. Bauen Sie regelmäßige Reviews der Fehlerlogs ein, eine formale Übergabe vom Projekt in den Support und zwischen Fachbereich und IT vereinbarte Service Levels. Vernachlässigte Integration steckt hinter vielen verspäteten Buchungen, fehlenden Rechnungen und abweichenden Finanzberichten, die Wochen nach dem Go-live auftauchen.

Was ist SAP Integration Suite und wie unterscheidet sie sich von CPI?

Cloud Integration, früher SAP Cloud Platform Integration (CPI), ist eine Funktion innerhalb von Integration Suite. Die Suite ergänzt API Management für die gesteuerte Bereitstellung von APIs und Event Mesh für asynchrone Nachrichtenübermittlung. Außerdem enthält sie Integration Advisor für B2B-Mapping-Vorschläge, Open Connectors für Cloud-Anwendungen von Drittanbietern sowie Bewertungs- und Migrationswerkzeuge für PI/PO. Teams, die sie als CPI mit neuem Namen behandeln, lassen API Management und Event Mesh oft aus und zahlen später mit Governance-Lücken dafür.

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

SAP Process Integration und Process Orchestration 7.5 befinden sich bis Ende 2027 in der Mainstream-Wartung. Kunden können optionale erweiterte Wartung bis Ende 2030 nutzen, danach endet der SAP-Support. Integration Suite enthält eine Migration-Assessment-Anwendung, die jedes Szenario bewertet, und Migrationswerkzeuge, die Artefakte halbautomatisch übertragen. Beginnen Sie mit einem Wellenplan, statt auf den Stichtag zu warten.

Wann sollte die SAP-Integration Standard-Content nutzen und wann eine Eigenentwicklung?

Nutzen Sie Standard-Content, wenn das Szenario SAP-zu-SAP ist, nah am Referenzprozess von SAP liegt und relativ einfach ist. Bauen Sie individuell, wenn der Prozess vom Modell von SAP abgewichen ist, wenn Eigenheiten von Legacy-Systemen eine besondere Behandlung brauchen oder wenn bedingte und mehrstufige Logik umfangreiche Änderungen am Standardpaket erzwingen würde. Entscheiden Sie in der Blueprint-Phase; einen übermäßig veränderten Standard-Flow unter Go-live-Druck neu zu bauen kostet mehr als eine saubere Eigenentwicklung.

Was verursacht SAP-Integrationsfehler in komplexen Programmen?

Meist strukturelle Ursachen. Keine benannte verantwortliche Person für Überwachung und Fehlerbehebung, sodass Fehler zwischen Teams hin- und herwandern. Zwei Arbeitsströme, die Integrationen bauen, die sich einen Endpunkt oder eine Queue teilen, ohne es zu wissen. Legacy-Systeme, die keine gleichzeitigen Aufrufe verarbeiten können, was sich erst unter Last zeigt. Und Tests, die isoliert sauber laufen, aber nie Batch-Überlagerung oder Spitzenvolumen simulieren.

Wie sollten Integrationstests für SAP Integration Suite aufgebaut sein?

Decken Sie über funktionale Tests hinaus realistische Volumen ab, etwa den ersten Monatsabschluss oder Abrechnungslauf. Testen Sie Batch-Jobs, die neben Echtzeit-Schnittstellen laufen, die Wiederherstellung, wenn ein nachgelagertes System nicht verfügbar ist, und die Ratenbegrenzungen von Drittanbietern bei Massenjobs. Führen Sie Last- und Performancetests in Umgebungen durch, die der Produktion ähneln, denn saubere Entwicklungssysteme verbergen die Probleme.

Wie sollte die SAP-Integration nach dem Go-live gesteuert werden?

Geben Sie jeder Schnittstelle eine benannte verantwortliche Person für Überwachung, Eskalation und Änderungen. Halten Sie die Dokumentation aktuell: Mappings, Authentifizierung und Rotation von Zugangsdaten, Fehlerbehandlung und Volumenerwartungen. Und bauen Sie ein langfristiges Support-Modell auf, mit regelmäßigen Reviews der Fehlerlogs, einer formalen Übergabe vom Projekt in den Support und vereinbarten Service Levels. Integration, die unsichtbar wird, wird vernachlässigt.