SAP-Integrationsmuster: Ein praxisnaher Leitfaden zur Auswahl des richtigen Musters

SAP-Integrationsmuster lassen sich sechs Kernfamilien zuordnen: Punkt-zu-Punkt, nachrichtenbasiert, API-basiert, ereignisgesteuert, Datenreplikation/-extraktion sowie hybrid/komposit. Die richtige Wahl hängt davon ab, welchem Integrationsstil Ihre Anforderung tatsächlich entspricht, nicht davon, welches Tool Ihr Team bereits kennt. Punkt-zu-Punkt-Verbindungen funktionieren bei einer oder zwei Integrationen gut. Mit jeder weiteren Verbindung wächst jedoch der Wartungsaufwand, bis Sie ein Spaghetti-Diagramm verwalten, das niemand anfassen möchte.

Die entscheidende Auswahlregel lautet: Identifizieren Sie zunächst den Integrationsstil (Prozess, Daten, Benutzererlebnis oder IoT/Geräte) und wählen Sie anschließend innerhalb dieses Stils das Muster, das Ihre Anforderungen an Latenz, Kopplung und Skalierbarkeit erfüllt. Die Integration Solution Advisory Methodology (ISA-M) von SAP und die SAP Integration Suite sind die beiden Referenzpunkte, an denen Sie Ihre Architekturentscheidungen ausrichten sollten. Sie bieten Ihnen ein gemeinsames Vokabular für Governance-Gespräche, die sonst schnell zu Diskussionen über persönliche Tool-Präferenzen werden.

Einige Grundregeln, bevor Sie sich entscheiden:

• Punkt-zu-Punkt ist für isolierte Verbindungen mit geringem Volumen akzeptabel. Sobald Sie mehr als einige wenige bilaterale Verbindungen warten, ist es das nicht mehr.
• API-basiert (OData/REST) ist die von SAP vorgegebene Richtung für die meisten neuen S/4HANA-Integrationsprojekte – in der Cloud ebenso wie in hybriden Szenarien.
• Ereignisgesteuerte Muster lösen Fan-out-Probleme, mit denen synchrone APIs nur schlecht umgehen können.
• Datenreplikation und -extraktion dienen Analytics und Reporting, nicht der Transaktionskonsistenz.

Profi-Tipp: Wenn Sie den Integrationsstil, unter den Ihre Anforderung fällt, nicht benennen können, sind Sie noch nicht bereit, ein Muster auszuwählen. Erst der Stil, dann das Muster und zuletzt das Tool.

Wichtigste Erkenntnisse

Bei der Auswahl eines SAP-Integrationsmusters geht es darum, die Anforderungen Ihrer Lösung an Latenz, Kopplung und Skalierbarkeit der passenden Musterfamilie zuzuordnen und diese Entscheidung anschließend mit einem schlanken, etablierten ISA-M-Prozess zu steuern – statt mit einem Dokument, das niemand liest.

es,	Details
Stil vor Muster zuordnen	Identifizieren Sie den Integrationsstil (Prozess, Daten, Benutzer, IoT), bevor Sie ein bestimmtes Muster auswählen.
Achten Sie auf den Schwellenwert für Punkt-zu-Punkt-Verbindungen	Wechseln Sie zu Middleware, sobald Sie ungefähr drei bilaterale Verbindungen überschreiten.
API-first für neue Cloud-Projekte	Bevorzugen Sie OData/REST für neue Integrationen; vermeiden Sie neue Abhängigkeiten von IDoc-Abläufen in Cloud-Zielsystemen.
Halten Sie die Governance kurz	Beschränken Sie die Dos und Don’ts auf eine kurze, einprägsame Liste, damit die Teams sie tatsächlich befolgen.
Planen Sie standardmäßig für hybride Szenarien	Die meisten realen Geschäftsprozesse benötigen zwei oder drei kombinierte Muster, nicht nur eines.

Inhaltsverzeichnis

• Was sind die zentralen SAP-Integrationsmuster?
• Wie wählen Sie für jede Anforderung das richtige Muster aus?
• Welche Governance-Regeln verhindern, dass SAP-Integrationen unüberschaubar werden?
• Welche betrieblichen Anforderungen müssen produktive Integrationen erfüllen?
• Wie sehen echte hybride Integrationsarchitekturen aus?
• Wie sollten Sie ISA-M an unübersichtliche reale Systemlandschaften anpassen?
• Quellen
• FAQ

Was sind die zentralen SAP-Integrationsmuster?

Jede SAP-Landschaft – ganz gleich, ob es sich um ein zehn Jahre altes ECC-System oder einen neuen S/4HANA-Cloud-Mandanten handelt – greift letztlich auf dieselben sechs Musterfamilien zurück. Was sich ändert, sind die Kombination, die Werkzeuge und die Konsequenz, mit der Sie vermeiden, im jeweiligen Moment standardmäßig die einfachste Option zu wählen.

1. Punkt-zu-Punkt-Integration

Punkt-zu-Punkt bedeutet genau das: System A kommuniziert direkt mit System B, ohne dass eine vermittelnde Schicht die Verbindung verwaltet. Dieses Muster lässt sich am schnellsten einrichten, und für eine tatsächlich kleine Systemlandschaft ist diese Geschwindigkeit ein legitimer Vorteil. Eine Integration zwischen einem SAP-ERP-System und einem einzigen Lagerverwaltungstool benötigt keinen zusätzlichen Middleware-Aufwand.

Das Problem zeigt sich bei wachsendem Umfang. Praxisnahe Architekturhinweise von SAP Press setzen die Schwelle zur Fragilität bei ungefähr drei bilateralen Verbindungen an. Wird diese Zahl überschritten, haben Sie es mit einer quadratischen Komplexität zu tun: Jedes neue System, das Sie hinzufügen, vervielfacht die Anzahl der Punkt-zu-Punkt-Verbindungen, die Sie einzeln warten, testen und überwachen müssen. Niemand plant, eine Spaghetti-Architektur zu bauen. Sie entsteht schrittweise – durch jeweils eine Integration, die angeblich „nur dieses eine Mal“ benötigt wird.

Langfristige Risiken summieren sich unbemerkt. Jede Punkt-zu-Punkt-Verbindung verfügt typischerweise über ein eigenes Authentifizierungsschema, eine eigene Fehlerbehandlungslogik und eigene undokumentierte Annahmen zum Datenformat. Wenn die Person, die sie erstellt hat, das Unternehmen verlässt, geht auch das damit verbundene Erfahrungswissen verloren.

2. Nachrichtenbasierte Integration (IDoc und SOAP)

Bei der nachrichtenbasierten Integration werden Daten über strukturierte Nachrichtenformate übertragen, in klassischen SAP-Umgebungen meist über IDocs (Intermediate Documents) oder in etwas neueren Umgebungen über SOAP-basierte Webservices. IDocs sind nach wie vor das Arbeitspferd für transaktionale Austausche wie Bestellungen, Kundenaufträge und Materialbewegungen, insbesondere in On-Premise-Bereitstellungen von ECC und S/4HANA.

Die Stärke liegt hier in der transaktionalen Zuverlässigkeit. IDocs unterstützen die asynchrone Verarbeitung mit integrierten Wiederholungsmechanismen und einer Statusverfolgung. Dadurch eignen sie sich besonders für volumenstarke, reihenfolgeabhängige Prozesse, bei denen Sie den Verlust einer Nachricht nicht riskieren können. SOAP bietet eine ähnliche Struktur mit mehr Flexibilität bei der Schemadefinition, verursacht pro Aufruf jedoch mehr Overhead als schlankere Alternativen.

Darauf müssen Architektinnen und Architekten bei der Planung achten: IDocs werden in bestimmten SAP-Cloud-Editionen schrittweise abgelöst, bleiben jedoch in vielen On-Premise-Kontexten relevant. Wenn Sie neue Integrationen für eine Cloud-First-Roadmap entwerfen, sollten Sie keine neuen Abhängigkeiten von IDoc-basierten Abläufen schaffen, ohne zu bestätigen, dass diese Ihr angestrebtes Bereitstellungsmodell überdauern werden. Bestehende IDoc-Integrationen in On-Premise-Systemen sind kein Notfall. Neue Integrationen für eine vollständig cloudbasierte Zukunft sollten Sie jedoch noch einmal prüfen.

3. API-basierte Integration (OData und REST)

Die API-basierte Integration, vor allem über OData und REST, ist der Bereich, auf den SAP auf absehbare Zeit strategisch setzt. OData bietet Ihnen eine standardisierte, abfragbare Schnittstelle zu SAP-Datenmodellen. Das ist besonders wichtig, wenn Sie Geschäftsobjekte für externe Entwickler bereitstellen oder kundenorientierte Anwendungen erstellen, die synchrone Antworten benötigen.

REST-Muster ergänzen OData ganz natürlich für einfachere Anfrage-/Antwort-Szenarien, insbesondere bei der Integration mit Nicht-SAP-Systemen, die konventionelle REST-Semantik statt der spezifischeren Abfragesyntax von OData erwarten. Verwenden Sie synchrone API-Aufrufe, wenn der Aufrufer eine sofortige Antwort benötigt: Prüfen der Bestandsverfügbarkeit vor der Bestätigung eines Auftrags, Validieren eines Kundendatensatzes vor dem Abschluss einer Transaktion oder Abrufen von Preisen in Echtzeit während des Bezahlvorgangs.

Der Nachteil ist die Kopplung. Ein synchroner API-Aufruf bedeutet, dass der Aufrufer auf den Aufgerufenen wartet. Ist der Aufgerufene langsam oder nicht verfügbar, breiten sich diese Verzögerung oder dieser Ausfall sofort bis zum Anforderer aus. Für echte Echtzeitanforderungen ist das ein vertretbarer Preis. Es ist jedoch ein schlechter Tausch, wenn Sie Prozesse zu synchronen Aufrufen zwingen, die tatsächlich keine sofortige Antwort benötigen.

4. Ereignisgesteuerte Integration

Eine ereignisgesteuerte Architektur kehrt das Modell um: Statt dass ein System ein anderes nach Daten fragt, veröffentlichen Systeme Ereignisse, sobald etwas geschieht, und beliebig viele Abonnenten reagieren unabhängig voneinander. SAP Advanced Event Mesh ist hier das wichtigste Werkzeug und löst ein Problem, mit dem synchrone APIs schlecht umgehen: die Verteilung an mehrere Empfänger.

Stellen Sie sich eine Auftragsbestätigung vor, die gleichzeitig Bestandsaktualisierungen, eine Kundenbenachrichtigung, eine Anfrage an die Auftragsabwicklung und eine Aktualisierung einer Analytics-Pipeline auslösen muss. Vier separate API-Aufrufe an vier separate Systeme bedeuten, dass der Auftragsservice nun vier Fehlerquellen und vier Latenzen auffangen muss. Veröffentlichen Sie stattdessen ein einziges Ereignis „Auftrag bestätigt“, und jedes nachgelagerte System abonniert es unabhängig. Fügen Sie im nächsten Jahr einen fünften Verbraucher hinzu, muss der Herausgeber überhaupt nicht geändert werden.

Die Nachteile sind allerdings real. In dem Moment, in dem Sie ereignisgesteuert arbeiten, sind Sie für Garantien zur Reihenfolge und Idempotenz verantwortlich. Wenn eine Netzwerkstörung dazu führt, dass ein Ereignis doppelt zugestellt wird, müssen Ihre Verbraucher damit angemessen umgehen, statt einen Auftrag doppelt zu verarbeiten. Planen Sie mit einer Zustellung „mindestens einmal“, sofern Ihr Event Mesh nicht ausdrücklich eine Semantik mit genau einmaliger Zustellung garantiert, und integrieren Sie Idempotenzprüfungen in jeden Verbraucher.

5. Datenreplikation und -extraktion

Muster für Datenreplikation und -extraktion übertragen Daten aus operativen Systemen in analytische Systeme und sind für eine grundlegend andere Aufgabe ausgelegt als die oben genannten Muster. Change Data Capture (CDC) und CDS-Views (Core Data Services) sind die beiden Mechanismen, die in aktuellen SAP-Landschaften den größten Teil der Arbeit übernehmen: Sie erfassen inkrementelle Änderungen und Delta-Extraktionen, statt wiederholt vollständige Datensätze abzurufen.

Dieses Muster gibt es, weil Analytics- und Reporting-Workloads andere Anforderungen haben als die transaktionale Integration. Ein Finanzdashboard, das alle fünfzehn Minuten aktualisiert wird, benötigt keine Latenz im Millisekundenbereich. Es benötigt konsistente, vollständige Daten, wobei die Leistung des transaktionalen Systems, aus dem sie abgerufen werden, nicht beeinträchtigt werden darf.

Der Nachteil ist das Spannungsfeld zwischen Aktualität und Systemlast. CDC in Echtzeit bietet nahezu sofortige Einblicke in operative Änderungen, erzeugt aber auch kontinuierliche Last auf dem Quellsystem. Die Extraktion von Delta-Daten im Batch-Verfahren ist schonender für Produktivsysteme, bedeutet jedoch, dass Ihre Analytics-Daten immer etwas veraltet sind. Die meisten Organisationen finden einen Mittelweg und passen die Extraktionshäufigkeit daran an, wie aktuell ein bestimmter Bericht tatsächlich sein muss – nicht daran, wie aktuell er idealerweise sein könnte.

6. Hybride und zusammengesetzte Muster

In nahezu jeder ausgereiften SAP-Landschaft kommt letztlich eine Kombination der oben genannten Muster zum Einsatz, statt sich auf ein einziges Muster festzulegen. Das ist keine architektonische Unentschlossenheit. Es ist die richtige Reaktion darauf, dass verschiedene Teile eines Geschäftsprozesses tatsächlich unterschiedliche Anforderungen haben.

Orchestrierung und Choreografie sind die beiden Koordinationsmodelle, deren Bezeichnungen Sie kennen sollten. Bei der Orchestrierung steuert ein zentraler Integrationsfluss die Reihenfolge der Aufrufe mehrerer Systeme. Das ist nützlich, wenn ein Prozess einen klaren Verantwortlichen hat und eine vorhersehbare Ausführungsreihenfolge benötigt. Bei der Choreografie reagiert jedes System unabhängig auf Ereignisse, ohne zentrale Koordination. Das eignet sich besser für lose gekoppelte Prozesse, bei denen im Laufe der Zeit neue Teilnehmer hinzukommen, ohne dass die bestehende Logik angepasst werden muss.

Wie wählen Sie für jede Anforderung das richtige Muster aus?

Die Auswahl eines Musters ist keine Frage persönlicher Vorlieben. Es handelt sich um ein Zuordnungsproblem: Vergleichen Sie Ihre konkrete Anforderung anhand einer kleinen Zahl von Entscheidungskriterien, bis ein Muster eindeutig besser passt als die anderen.

Die wichtigsten Kriterien:

• Latenztoleranz. Benötigt der Anforderer eine Antwort innerhalb von Millisekunden, oder sind einige Minuten (oder Stunden) akzeptabel?
• Anforderungen an die Konsistenz. Können nachgelagerte Systeme eine letztendliche Konsistenz tolerieren, oder erfordert der Prozess eine strikt transaktionale Genauigkeit?
• Kopplung. Wie viel muss das Quellsystem über die Systeme wissen, die seine Daten nutzen, und von ihnen abhängig sein?
• Anzahl der nutzenden Systeme. Stellt ein System eine einzelne Frage, oder müssen viele Systeme auf dasselbe Ereignis reagieren?
• Skalierung. Wie hoch ist das realistische Volumen – sowohl heute als auch in drei Jahren – und nicht nur im Pilotbetrieb?
• Betriebskosten. Wer wartet diese Integration, und was passiert, wenn sie um 2 Uhr morgens ausfällt?

Einige Faustregeln machen diese Achsen praktisch anwendbar statt rein theoretisch. Sobald Sie in einer Systemlandschaft drei oder mehr bilaterale Verbindungen betrachten, sollten Sie proaktiv auf ein Middleware- oder Hub-Muster umsteigen, statt zu warten, bis die vierte Verbindung Sie unter Zeitdruck zu dieser Entscheidung zwingt. Kundenszenarien, die eine Antwort in Echtzeit erfordern, sprechen für synchrone API-Aufrufe. Alles mit hoher Fan-out-Rate – also ein Ereignis, das Reaktionen in vielen Systemen auslöst – spricht für eine ereignisgesteuerte Architektur, statt eine synchrone Aufrufkette zu erzwingen.

Anforderungstyp	Am besten geeignetes Muster	Warum
Zwei Systeme, geringes Volumen, stabil	Punkt-zu-Punkt	Der Overhead der Middleware ist derzeit noch nicht gerechtfertigt
Transaktionsorientiertes B2B mit hohem Volumen	Nachrichtenbasiert (IDoc)	Integrierte Wiederholungsversuche, Statusverfolgung, asynchrone Zuverlässigkeit
Echtzeitabfrage für Kunden	API-basiert (OData/REST)	Der Aufrufer benötigt eine sofortige, synchrone Antwort
Ein Ereignis, viele nachgelagerte Reaktionen	Ereignisgesteuert	Fan-out ohne eine Vervielfachung von Punkt-zu-Punkt-Aufrufen
Analytics- und BI-Berichte	Datenreplikation/-extraktion	Die Aktualität wird auf den Berichtsbedarf abgestimmt, nicht auf die Transaktionslast
Komplexer mehrstufiger Geschäftsprozess	Hybrid/zusammengesetzt	Die verschiedenen Phasen haben tatsächlich unterschiedliche Anforderungen

Drei kurze Beispielzuordnungen zeigen, wie sich das in der Praxis auswirkt. Ein Order-to-Cash-Prozess, der sich über ein Retail-Frontend, die Bestandsverwaltung und die Auftragsabwicklung erstreckt, benötigt typischerweise eine synchrone API für die Transaktion selbst, kombiniert mit ereignisgesteuerten Benachrichtigungen für die nachgelagerte Auftragsabwicklung und einer Extraktionspipeline zur Versorgung der BI-Schicht – drei Muster, ein Geschäftsprozess. Ein Onboarding-Prozess für Lieferanten, bei dem Bestellungen und Rechnungen ausgetauscht werden, eignet sich in der Regel am besten für den nachrichtenbasierten B2B-Austausch, da das Volumen hoch und die Toleranz für Verzögerungen großzügig ist. Ein Finanz-Dashboard, das nächtliche Aggregate aus S/4HANA abruft, gehört eindeutig zur Datenreplikation, da niemand eine sekündliche Aktualisierung von Hauptbuchsummen benötigt.

Welche Governance-Regeln verhindern, dass SAP-Integrationen unbeherrschbar werden?

In den meisten SAP-Integrationsprogrammen ist die Governance der Bereich, in dem sie unbemerkt scheitern – nicht, weil Architektinnen und Architekten die falschen Muster auswählen, sondern weil niemand teamübergreifend konsistente Entscheidungen durchsetzt. ISA-M bietet Ihnen dafür eine Struktur, die am besten funktioniert, wenn Sie dem Impuls widerstehen, daraus ein 40-seitiges Dokument zu machen, das niemand liest.

Die Methodik umfasst vier Phasen, für die jeweils eine pragmatische, schlanke Variante existiert, deren Umsetzung sich tatsächlich lohnt:

1. Bewerten. Erstellen Sie ein Inventar Ihrer aktuellen Integrationen, halten Sie fest, welche Muster sie verwenden, und markieren Sie die Punkt-zu-Punkt-Verbindungen, die den Schwellenwert von drei Verbindungen für erhöhte Fragilität bereits überschritten haben oder sich ihm nähern.
2. Entwerfen. Definieren Sie Ihre angestrebten Integrationsstile pro Domäne – also beispielsweise einen Mustersatz für den Finanzbereich und einen anderen für den Handel – und dokumentieren Sie die Gründe dafür, damit die nächste Architektin oder der nächste Architekt sie nicht rückentwickeln muss.
3. Best Practices definieren. Halten Sie die wenigen Regeln fest, die Ihre Teams tatsächlich befolgen müssen – kein umfassendes Regelwerk, das niemand über die zweite Seite hinaus lesen wird.
4. Steuern. Prüfen Sie neue Integrationsanfragen anhand Ihrer definierten Stile, bevor die Implementierung beginnt, nicht erst, wenn sie bereits in Produktion ist.

Was die Empfehlungen und No-Gos betrifft, sollten Sie der Versuchung widerstehen, ein umfassendes Regelwerk zu verfassen. Die Lernmaterialien von SAP zum Entwickeln mit ISA-M empfehlen, die Liste der Empfehlungen ausdrücklich kurz zu halten, da lange Regel-Listen die Akzeptanz hemmen. Teams überfliegen eine Liste mit zehn Punkten. Eine mit fünfzig Punkten ignorieren sie.

Eine praktikable kurze Liste könnte etwa so aussehen:

• Empfehlung Setzen Sie bei neuen kundenorientierten oder cloudnativen Vorhaben standardmäßig auf API-basierte Integration.
• Empfehlung Leiten Sie alles, was über zwei oder drei bilaterale Verbindungen hinausgeht, über Middleware.
• Empfehlung Dokumentieren Sie für jede neue Verbindung den Integrationsstil, nicht nur das verwendete Tool.
• Vermeiden Sie es, für reine Cloud-Bereitstellungsziele Abhängigkeiten von IDoc-Flows aufzubauen.
• Vermeiden Sie Point-to-Point-Integrationen ohne einen definierten Migrationsauslöser als „vorübergehend“ zu betrachten.
• Vermeiden Sie es, den Governance-Prüfschritt auszulassen, nur weil eine Frist knapp ist; genau dann entsteht eine Spaghetti-Architektur.

Profi-Tipp: Formulieren Sie Ihre Integrationsrichtlinie als Entscheidungsbaum, nicht als Textwand. „Wenn X, dann Muster Y, außer Z“ lässt sich während einer Designprüfung an einem Dienstagnachmittag schneller erfassen als drei Absätze Fließtext.

Eine einfache Richtlinie zu verfassen bedeutet, Teams einen Standardweg sowie ein dokumentiertes Ausnahmeverfahren vorzugeben. Zum Beispiel: „Verwenden Sie für neue Integrationen standardmäßig OData. Ausnahmen erfordern die Freigabe durch die Architekturprüfung und eine dokumentierte Begründung.“ Dieser eine Satz leistet mehr für die Governance als ein umfangreiches Standarddokument, weil er tatsächlich einprägsam genug ist, um unter Zeitdruck befolgt zu werden.

Welche betrieblichen Anforderungen müssen Integrationen in der Produktion erfüllen?

Mit der Wahl des richtigen Musters haben Sie vielleicht die Hälfte geschafft. Die andere Hälfte ist das betriebliche Gerüst, das dieses Muster zuverlässig hält, sobald es echten Geschäftsverkehr verarbeitet – und genau hier brechen überraschend viele ansonsten gut konzipierte Integrationen unbemerkt auseinander.

API-Management verdient eine Behandlung als Produktfunktion und nicht als nachträglich an irgendeinen gerade bereitgestellten Endpunkt angehängte Nebensache. Die API-Management-Funktion der SAP Integration Suite arbeitet mit API-Proxys, die vor den Zielendpunkten liegen. Richtlinien steuern dabei das Laufzeitverhalten auf der Proxy-Ebene und nicht innerhalb Ihres Backend-Codes. Eine SpikeArrest-Richtlinie beispielsweise drosselt eingehende Anfragen, um ein Backend-System vor einem plötzlichen Anstieg des Datenverkehrs zu schützen – unabhängig davon, ob dieser Anstieg auf legitime Nachfrage oder auf einen fehlerhaften Client zurückgeht, der Ihren Endpunkt mit Anfragen bombardiert. Konkrete Tutorials von SAP Developers führen Sie durch das Erstellen eines Proxys, das Zuweisen einer Richtlinie wie SpikeArrest und die Bereitstellung des Ergebnisses. Sie sollten einen solchen Ablauf tatsächlich einmal durchführen, bevor Sie davon ausgehen, dass Ihr Team die Mechanismen beherrscht.

Beobachtbarkeit ist unverzichtbar, sobald mehr als eine oder zwei Integrationen in der Produktion laufen. Mindestens benötigen Sie:

• Korrelations-IDs, die durch jede Nachricht weitergegeben werden, damit Sie eine einzelne Transaktion über mehrere Systeme hinweg verfolgen können.
• End-to-End-SLA-Überwachung, die den vollständigen Pfad misst und nicht nur den Zustand eines einzelnen Abschnitts isoliert betrachtet.
• Ereignisgesteuerte Überwachung, die auf Verzögerungen bei Verbrauchern achtet und nicht nur auf die Betriebszeit von Publishern. Ein fehlerfreies Event Mesh mit einem ins Stocken geratenen Verbraucher sieht aus der falschen Perspektive intakt aus.

Bereitstellung und CI/CD für Integrationsartefakte oft weniger Disziplin aufgebracht wird als für Anwendungscode – obwohl das angesichts der Menge an Geschäftslogik in einem Mapping oder einer Routing-Regel genau umgekehrt sein sollte. Transportieren Sie Ihre Integrationsabläufe durch geeignete Umgebungen (Entwicklung, Test, Produktion), schreiben Sie automatisierte Tests für die tatsächliche Transformationslogik und erstellen Sie einen Rollback-Plan, der nicht darauf angewiesen ist, dass sich jemand aus dem Gedächtnis an die vorherige Konfiguration erinnert.

Sicherheit läuft auf eine kurze Liste konkreter Entscheidungen hinaus und nicht auf eine Checkliste zum bloßen Abhaken. Wählen Sie OAuth 2.0 für die meisten API-basierten Integrationen, bei denen Sie eine delegierte Autorisierung benötigen, und gegenseitiges TLS (MTLS) für System-zu-System-Verbindungen, bei denen Sie gegenseitiges, zertifikatsbasiertes Vertrauen statt Bearer-Tokens wünschen. Speichern Sie Zugangsdaten in einem geeigneten Secrets Vault, niemals in der Ablaufkonfiguration oder der Quellcodeverwaltung, und richten Sie Ihr Berechtigungsmodell nach dem Prinzip der geringsten Rechte aus: Ein Integrationsablauf sollte exakt auf die Objekte und Vorgänge zugreifen können, die er benötigt – auf nichts darüber hinaus „für den Fall, dass es später nützlich ist“.

Wie sehen echte hybride Integrationsarchitekturen aus?

Beschreibungen von Mustern aus Lehrbüchern sind nützlich, aber ihre tatsächliche Kombination in der Produktion sagt mehr über gute Architektur aus als jede einzelne Musterdefinition.

1. Bestellablauf mit Kundenkontakt. Beim Checkout im Einzelhandel wird eine sofortige Antwort benötigt. Daher läuft die Transaktion selbst über einen synchronen API-Aufruf, der die Bestellung anhand von Bestand und Preisen bestätigt. Sobald die Bestellung bestätigt ist, wird ein Ereignis veröffentlicht, um die Auftragsabwicklung zu benachrichtigen, eine Kunden-E-Mail auszulösen und die Treuepunkte zu aktualisieren – drei unabhängige Verbraucher reagieren auf ein Ereignis, statt dass der Checkout-Service drei separate API-Aufrufe verwalten muss. Parallel dazu extrahiert eine Datenreplikationspipeline die Bestellung in die Analyseschicht, um die Nachfrage zu prognostizieren. Drei Muster, drei unterschiedliche Aufgaben, ein kohärenter Prozess. Ein häufiger Fehler besteht darin, die Benachrichtigungs- und Analyseaufgaben in denselben synchronen Aufruf zu zwängen, der die Transaktion verarbeitet. Dadurch steigt die Latenz beim Checkout ohne wirklichen Vorteil.

2. Onboarding von Lieferanten und B2B-Partnern. Der Austausch strukturierter Dokumente in großen Volumen – Bestellungen, Rechnungen und Versandavis – eignet sich nach wie vor besser für eine nachrichtenbasierte Integration über ein B2B-Gateway als für alles, was neuer ist, da das Volumen vorhersehbar ist und die Toleranz für einige Minuten Verarbeitungsverzögerung großzügig ausfällt. Setzen Sie eine API-basierte Transparenzschnittstelle darauf, damit Beschaffungsteams den Bestellstatus nahezu in Echtzeit prüfen können, ohne direkt auf die zugrunde liegende Nachrichtenwarteschlange zugreifen zu müssen. Diese Kombination ermöglicht Lieferanten eine zuverlässige Stapelverarbeitung und Ihren internen Teams eine moderne Schnittstelle, ohne den gesamten Austauschmechanismus neu aufzubauen.

3. IoT- und Telemetriedatenaufnahme. Das Streaming von Sensordaten aus Fertigungsanlagen oder vernetzten Produkten erfordert für die Erfassung ein Event Mesh, da Volumen und Geschwindigkeit synchrone API-Aufrufe bei einer Skalierung auf große Mengen unpraktisch machen. Anschließend übertragen CDC- und Replikationspipelines diese Telemetriedaten in Reporting- und Analysesysteme, wo sie für die Prognose von Wartungsbedarf und die Analyse von Qualitätstrends aggregiert werden können. Der entscheidende Fallstrick: Teams versuchen manchmal, das Event Mesh direkt für historische Berichte abzufragen, obwohl es nie dafür entwickelt wurde, dies effizient zu leisten. Replizieren Sie die Daten zunächst in einen geeigneten analytischen Datenspeicher.

Profi-Tipp: Wenn Sie Muster kombinieren, zeichnen Sie den Datenfluss, bevor Sie die Systemkästen einzeichnen. Architekturdiagramme, die mit Systemen beginnen, verbergen häufig die tatsächlichen Abhängigkeiten; Diagramme, die mit dem Datenfluss beginnen, machen sie sofort sichtbar.

Die Prinzipien einer komposablen Architektur gelten hier unmittelbar. Wenn Sie genauer betrachten möchten, wie kombinierte Integrationsstile wirklich komplexe Umgebungen unterstützen, behandelt unser Beitrag zur Strategie für eine komponierbare Architektur das übergreifende Muster, das über SAP im engeren Sinne hinausgeht.

Wie sollten Sie ISA-M an unübersichtliche reale Systemlandschaften anpassen?

Vorlagen sehen in einer Präsentation übersichtlich aus. Reale SAP-Landschaften sind das nur selten, und die Lücke zwischen beiden entscheidet darüber, ob die meisten Integrationsprogramme entweder weiterentwickelt werden oder ins Stocken geraten. ISA-M funktioniert, wenn es als fortlaufender Prozess und nicht als einmalige Übung verstanden wird, in Ihre tatsächlichen Transport-, Test- und Betriebspraktiken integriert ist, statt in einem Governance-Ordner abgelegt zu werden, den nach dem Kick-off-Meeting niemand mehr öffnet.

Wenn Integrationsarbeiten in Analysen einfließen, treffen Sie außerdem eine Architekturentscheidung, die ISA-M nicht direkt abdeckt: wo die replizierten oder extrahierten Daten landen. Arbeiten Sie diese Checkliste durch, bevor Sie sich festlegen:

• Abfragemuster. Ist der primäre Anwendungsfall strukturiertes BI und Reporting, oder umfasst er auch Machine-Learning-Workloads für semi-strukturierte und unstrukturierte Daten? Ersteres spricht eher für ein Data Warehouse, Letzteres eher für ein Lakehouse.
• Stabilität des Schemas. Wenn Ihr Quelldatenmodell stabil und gut verstanden ist, zahlt sich Schema-on-Write in einem Data Warehouse durch eine hohe Abfrageleistung und eine einfachere Governance aus. Wenn es sich schnell weiterentwickelt, erspart die Flexibilität von Schema-on-Read in einem Lakehouse eine ständige Neugestaltung.
• Fachkenntnisse des Teams. SQL-zentrierte BI-Teams werden auf einem Data Warehouse schneller produktiv. Teams, die mit Spark, Python und offenen Tabellenformaten vertraut sind, können aus einem Lakehouse mehr Nutzen ziehen.
• Parallele Nutzung und Kosten. BI-Dashboards mit vielen gleichzeitigen Nutzern liefern auf für diesen Workload entwickelten Data-Warehouse-Engines nach wie vor tendenziell eine besser vorhersehbare Leistung.

Keines ersetzt das andere vollständig, und ein großer Teil des Marketings der Anbieter verwischt diese Grenze. Viele etablierte Organisationen betreiben beides: ein Lakehouse für die Ablage roher und semi-strukturierter Daten, das eine kuratierte Serving-Schicht im Stil eines Data Warehouses für eine kontrollierte BI-Nutzung speist.

Ridiculous Engineering hält Governance-Artefakte bewusst kompakt: ein einseitiger Leitfaden zur Musterentscheidung, eine kurze Liste mit Dos und Don’ts sowie vierteljährliche Prüfungen, bei denen neue Integrationen mit der aktuellen Stilübersicht abgeglichen werden – statt eines jährlichen Audits, für das niemand Zeit einplant. Wenn Sie abwägen, wie neue Tools in eine bereits komplexe Legacy-Umgebung passen, geht unser Leitfaden zu der Verbindung von Legacy-Systemen mit neuen Technologien geht auf diesen Perspektivwechsel ausführlicher ein.

Möchten Sie besprechen, wie diese Muster auf Ihre tatsächliche Systemlandschaft und nicht auf eine generische Referenzarchitektur angewendet werden können? Ridiculous Engineering konzipiert und realisiert individuelle API- und Systemintegrationslösungen für Organisationen, die ihre Legacy-SAP-Verbindungen entwirren, und wir nehmen uns lieber eine Stunde Zeit, um Ihre tatsächlichen Rahmenbedingungen zu verstehen, als Ihnen eine Vorlage zu verkaufen, die nicht passt.

Quellen

• SAP Integration Solution Advisory Methodology (ISA-M) – SAP Help
• Die zentralen SAP-Integrationsmuster: ein vollständiger Überblick – SAP Press

FAQ

Welche verschiedenen Arten der Integration gibt es in SAP?

Die SAP-Integration gliedert sich in sechs zentrale Musterfamilien: Punkt-zu-Punkt, nachrichtenbasiert (IDoc/SOAP), API-basiert (OData/REST), ereignisgesteuert, Datenreplikation/-extraktion sowie hybride oder zusammengesetzte Kombinationen der genannten Muster.

Welche verschiedenen Integrationsmuster gibt es?

Über die Musterfamilien selbst hinaus werden Integrationen üblicherweise mithilfe von Orchestrierung (ein zentraler Ablauf koordiniert mehrere Systeme) oder Choreografie (Systeme reagieren unabhängig auf gemeinsame Ereignisse) umgesetzt, wobei sich beide Ansätze für unterschiedliche Anforderungen an Kopplung und Zuständigkeit eignen.

Sind SAP BTP und CPI dasselbe?

Nein. Die SAP Business Technology Platform (BTP) ist die übergeordnete Plattform, während Cloud Integration (CPI, inzwischen Teil der SAP Integration Suite) eine spezifische Integrationsfunktion ist, die auf BTP ausgeführt wird.

Was sind SAP-Integrationen?

SAP-Integrationen sind technische Verbindungen, über die Daten zwischen SAP-Systemen (wie S/4HANA) und anderen SAP- oder Nicht-SAP-Anwendungen übertragen oder Prozesse ausgelöst werden. Sie werden je nach Anforderung mithilfe von Mustern wie nachrichtenbasiertem Austausch, APIs oder ereignisgesteuerten Abläufen umgesetzt.

Empfohlen

• Salesforce-Integration: Leitfaden zu Mustern, APIs und Architektur | Ridiculous Engineering
• Dynamics-365-Integration: Ein praxisorientierter Leitfaden für IT-Führungskräfte | Ridiculous Engineering
• NetSuite-Integration: Ein praxisorientierter Leitfaden für IT- und Business-Teams | Ridiculous Engineering
• QuickBooks-Integration für KMU: Eine praktische Anleitung | Ridiculous Engineering