SAP Integration Suite: Shop clean-core anbinden 2026

Die Diskussion um das ECC-Wartungsende dreht sich meist um Finanzbuchhaltung, Logistik und Stammdaten -- der Online-Shop kommt selten vor. Genau das ist das Problem. In vielen mittelständischen Landschaften hängt der Shop über eine Schnittstelle am ERP, die über Jahre gewachsen ist: ein PI/PO-Szenario hier, ein direkter RFC-Aufruf dort, dazu individueller Z-Code, der Artikel-, Bestands- und Auftragsdaten transformiert. Solange ECC läuft, funktioniert das. Beim Umstieg auf S/4HANA jedoch ändern sich Datenmodelle, Tabellen und Funktionsbausteine -- und genau die Stellen, an denen der Custom-Code in den Kern eingreift, werden zur Migrationsbremse.

Der Zeitdruck ist real. Laut Gartner waren rund zwei Drittel der ECC-Kunden Ende 2024 noch in der Planungsphase ihrer Migration, weitere acht Prozent wollten über 2027 hinaus auf ECC bleiben (Gartner, via The Register, 2026) -- wer erst spät startet, wird einen sauberen Abschluss vor dem Stichtag kaum schaffen. Ein typisches Brownfield-Projekt dauert 9 bis 15 Monate, ein Greenfield-Projekt 12 bis 24 Monate (Basis Admin, 2026). Gleichzeitig haben laut Horváth-Studie 2025 rund 60 Prozent aller bisherigen Migrationsprojekte Budget, Zeitplan oder beides überschritten (Horváth, 2025). Eine Shop-Anbindung, die erst beim Go-Live als Blocker auffällt, verschärft genau dieses Risiko. Wer den Schnitt früh mitdenkt und die Integration auf eine zukunftssichere Plattform hebt, nimmt einen ganzen Stapel an Überraschungen aus dem Projekt heraus.

Wichtig ist die Einordnung: SAP hat für On-Premise-ERP-Kunden unter bestimmten Bedingungen eine Erweiterung der Wartung bis 2033 in Aussicht gestellt (Forrester, 2025). Das verschiebt den Termin jedoch nicht für alle und ändert nichts an der grundsätzlichen Richtung -- der Innovationspfad führt zu S/4HANA und zur Plattformschicht. Eine verlängerte Wartung kauft Zeit, sie ersetzt keine Strategie. Genau deshalb lohnt es sich, die Shop-Anbindung unabhängig vom konkreten ERP-Termin zukunftssicher zu bauen: Sie ist ohnehin der Teil, der am stärksten kundenseitig sichtbar ist und am wenigsten Stillstand verträgt. Ein eingefrorener oder fehlerhaft umgestellter Shop trifft den Umsatz unmittelbar, während interne Module einen holprigen Cutover eher verkraften.

Clean Core ist SAPs Leitprinzip für S/4HANA: Der Anwendungskern bleibt unverändert -- keine direkt modifizierten SAP-Tabellen, keine überschriebenen Standardprogramme, keine Aufrufe interner, nicht freigegebener Objekte aus eigenem Code. Erweiterungen und Integrationen laufen stattdessen über veröffentlichte Schnittstellen: freigegebene OData-Services oder ereignisbasierte Integration über die SAP Integration Suite. Der Vorteil: Solange der Kern sauber bleibt, lassen sich Upgrades schnell und planbar einspielen, statt jedes Mal Custom-Code anzufassen.

Für die Shop-Anbindung ist das ein Paradigmenwechsel. Statt im SAP-Kern eine Z-Logik zu pflegen, die Produkt- und Bestelldaten für den Shop aufbereitet, wandert diese Logik in die Plattformschicht: in Integrationsflüsse (iFlows) der Cloud Integration, in verwaltete APIs und in Event-Abonnements. Wie hoch der Hebel ist, zeigt die Ausgangslage: 91 Prozent der SAP-Anwender stützen geschäftskritische Prozesse auf Eigenentwicklungen, und bei 57 Prozent der Unternehmen hängt bis zur Hälfte der kritischen Prozesse an solchem Custom-Code (ASUG, 2021). Je mehr dieser Logik in die Plattformschicht statt in den Kern wandert, desto geringer die Modifikationstiefe -- und desto günstiger werden Entwicklung, Wartung und Support. Unternehmen, die früh auf BTP-Erweiterungen gesetzt haben, geben nach Branchenanalysen 30 bis 40 Prozent weniger für die jährliche Systemwartung aus (ERP Implementation EU, 2026).

Wirtschaftlich betrachtet verschiebt Clean Core die Kosten von der laufenden Pflege hin zu einer einmaligen, planbaren Umstellung. Solange Z-Logik im Kern liegt, fällt bei jedem Release-Wechsel Regressionsaufwand an: Anpassungen müssen geprüft, getestet und nachgezogen werden. Liegt dieselbe Logik in einem iFlow, ist sie vom Release-Zyklus des ERP entkoppelt. Das senkt nicht nur die jährlichen Wartungskosten, sondern macht auch die Personalplanung berechenbarer -- ein Faktor, der angesichts knapper SAP-Ressourcen zunehmend ins Gewicht fällt. Branchenanalysen berichten zudem, dass rund die Hälfte der SAP-Kunden inzwischen aktiv BTP-Dienste nutzt, mit deutlich steigender Tendenz (ERP Implementation EU, 2026); die Plattformschicht ist also kein Nischenpfad mehr, sondern der eingeschlagene Standardweg.

Die SAP Integration Suite ist die als Nachfolger empfohlene Integrationsplattform auf der SAP Business Technology Platform (BTP). Sie bündelt mehrere Fähigkeiten in einer iPaaS-Umgebung -- darunter Cloud Integration, API Management, Event Mesh, Open Connectors und den Integration Advisor (SAP Learning, 2026). Für eine event-getriebene Shop-Anbindung sind drei davon zentral.

Der Kern einer clean-core-konformen Shop-Anbindung ist die ereignisbasierte Architektur. Statt den Shop in festen Intervallen abzufragen, ob sich etwas geändert hat, publiziert S/4HANA ein Ereignis, sobald es eintritt -- etwa eine Bestandsbewegung, eine Preisänderung oder ein neuer Kundenstamm. Die Integration Suite nimmt dieses Ereignis über das Event Mesh entgegen, transformiert es im iFlow und stellt es dem Shop über dessen API zu. Wie sich das technisch von zyklischem Abfragen unterscheidet, beleuchtet der Beitrag zu Webhooks und Polling in der Shop-Integration im Detail.

Der entscheidende Punkt: All das passiert über die Plattformschicht, nicht im SAP-Kern. Die Transformationslogik liegt im iFlow, die Sicherung der Endpunkte im API Management, die Entkopplung im Event Mesh. Beim Umstieg von ECC auf S/4HANA muss die Anbindung dadurch nicht neu erfunden werden -- es ändern sich allenfalls die Quellobjekte, nicht die gesamte Integrationsstrecke. Wer tiefer einsteigen will, findet in unserem Beitrag zur event-getriebenen Architektur mit Message Queues die Muster für Entkopplung und Pufferung.

Damit eine event-getriebene Strecke verlässlich bleibt, gehören Beobachtbarkeit und Fehlerbehandlung von Anfang an dazu. Das Event Mesh entkoppelt Quelle und Senke, sodass eine kurzzeitig nicht erreichbare Shop-API kein Ereignis verschluckt -- die Nachricht wird gepuffert und später zugestellt. Verbleibt eine Nachricht dauerhaft unzustellbar, landet sie in einer gesonderten Ablage und löst eine Benachrichtigung aus, statt still verloren zu gehen. Wie man solche Strecken überwacht und auf Idempotenz auslegt, damit eine wiederholte Zustellung keinen Auftrag doppelt anlegt, vertieft der Beitrag zu Observability und Monitoring von Schnittstellen. Genau diese zentrale Sicht ersetzt das mühsame Durchsuchen verteilter Logdateien einzelner Z-Programme.

Über Jahre gewachsene Eigenentwicklungen -- Z-Objekte, BAdI-Implementierungen, Überschreibungen von Standardprogrammen -- haben in praktisch jedem ECC-System tiefe Spuren hinterlassen; der Weg zum Clean Core wird damit zum Sanierungsprogramm, das SAP über den Custom Code Migration Guide eigens adressiert (SAP, 2025). Genau diese Eingriffe sind teuer in der Migration: Jede Modifikation muss im Simplification-Item-Check geprüft, bewertet und angepasst werden. Der Simplification-Item-Check gilt als die häufigste Einzelquelle für Budgetüberschreitungen in Brownfield-Projekten (Basis Admin, 2026).

Die zweite Bremse ist die Datenmodell-Änderung selbst. S/4HANA fasst Tabellen zusammen, führt das Universal Journal ein und benennt Felder um. Greift eine Shop-Anbindung direkt auf ECC-Tabellen oder interne Funktionsbausteine zu, verändern sich genau diese Bezugspunkte unter der Schnittstelle -- oft unbemerkt, bis im Test falsche oder fehlende Daten auffallen. Eine über veröffentlichte OData-Services und Events gebaute Anbindung ist gegen solche internen Umbauten weitgehend abgeschirmt, weil SAP die freigegebenen Schnittstellen über Versionswechsel hinweg stabil hält. Die Anbindung folgt dann einem Vertrag, nicht einer internen Implementierung.

Hinzu kommt der personelle Engpass. SAP zählte Ende 2024 rund 35.000 ECC-Kunden weltweit, von denen ein Großteil noch vor der Migration steht (Gartner, via The Register, 2026), und Europa steht vor einem wachsenden Mangel an S/4HANA-Spezialisten (Computer Weekly, 2025). Wer seine Shop-Anbindung erst kurz vor dem Go-Live auf eine knappe Personaldecke wirft, konkurriert mit allen anderen um dieselben raren Profile. Branchenanalysen zeigen außerdem, dass klassisches ABAP-Wissen heute nicht mehr ausreicht -- gefragt sind Erfahrung mit BTP, Fiori und API-Integration (Rimini Street, 2026). Eine Anbindung, die von vornherein auf die Integration Suite setzt, baut genau auf diesen zukunftsfähigen Fähigkeiten auf.

Eine bestehende Shop-Anbindung lässt sich in der Regel schrittweise auf die Integration Suite heben, ohne den laufenden Betrieb zu unterbrechen. Bewährt hat sich ein Vorgehen, das zuerst die Schnittstelle entkoppelt und die Geschäftslogik aus dem Kern herauszieht, bevor das eigentliche ERP migriert wird.

Der Parallelbetrieb ist dabei mehr als eine Vorsichtsmaßnahme -- er ist der eigentliche Hebel, um den Migrations-Schnitt risikoarm zu halten. Solange alte und neue Strecke gleichzeitig laufen, lassen sich die Ergebnisse Datensatz für Datensatz abgleichen: Stimmen Bestand, Preis und Auftragsstatus auf beiden Wegen überein, ist die neue Anbindung belastbar. Erst wenn dieser Abgleich über mehrere Tage stabil ist, wird umgeschaltet. Diese Methode entkoppelt die Shop-Migration zeitlich von der ERP-Migration: Die Integrationsschicht kann bereits clean-core-konform stehen, während im Hintergrund noch das ERP umgestellt wird -- oder umgekehrt. Der Shop bleibt durchgängig erreichbar.

Ein häufiger Sonderfall ist die E-Rechnung: Mit der ab 2027 greifenden Stufe der E-Rechnungspflicht müssen ERP und Shop strukturierte Rechnungsdaten austauschen. Wie sich das in die Schnittstelle einbettet, vertieft der Beitrag zur E-Rechnungspflicht 2027 an der ERP-Shop-Schnittstelle. Wer von einer anderen ERP-Welt kommt, findet im Beitrag zur Dynamics-365-BC-Anbindung über die API v2 das Pendant für die Microsoft-Seite.

Unabhängig vom Ausgangssystem bleibt das Ziel dasselbe: eine Anbindung, die sich am veröffentlichten Vertrag orientiert statt an internen Implementierungsdetails. Wer diesen Grundsatz früh verankert, gewinnt nicht nur Robustheit für die anstehende S/4HANA-Migration, sondern auch für künftige Release-Wechsel, die danach folgen. Die Investition in eine plattformbasierte Shop-Integration zahlt also über den 2027er-Stichtag hinaus auf jede weitere Modernisierung ein -- und nimmt den Online-Vertrieb aus der Rolle des unsicheren Anhängsels heraus, das bei jedem ERP-Schritt neu verhandelt werden muss.