Die richtige SAP-Schnittstelle wählen: von IDoc bis Event

Über welche SAP-Schnittstelle ein Fremdsystem angebunden wird, entscheidet sich in vielen Projekten spät und richtet sich dann nach der im Team vorhandenen Erfahrung. Mehrere dieser Wege funktionieren im Test und erzeugen danach unterschiedliche Betriebslasten. Dieser Artikel geht die verfügbaren Wege durch, benennt für jeden den Zweck, den laufenden Aufwand und die Lage, in der er die falsche Wahl ist. Danach folgen die Themen, die erst in Produktion sichtbar werden.

Was die Wahl der SAP-Schnittstelle tatsächlich festlegt

Die technische Machbarkeit trennt die Wege kaum: fast jede Anforderung lässt sich mit mehreren der hier beschriebenen Verfahren umsetzen. Was sie unterscheidet, sind vier Festlegungen, die nach dem ersten Produktivlauf teuer zu revidieren sind.

• Die Transaktionsgrenze. Ob der Aufrufer auf das Ergebnis der Buchung wartet oder ob er eine Nachricht abgibt und den Fehlerfall später erfährt. Diese Entscheidung wandert bis in die Oberfläche des Fremdsystems durch.
• Das Lastprofil. Ein Weg, der bei 50 Belegen pro Stunde unauffällig ist, kann bei 50 pro Sekunde die Dialogprozesse des Systems belegen.
• Der Aufwand pro Störung. Wer sieht eine fehlgeschlagene Nachricht, wie schnell, und wie wird sie erneut eingespielt. Diese Frage bestimmt die Betriebskosten stärker als die Entwicklungsdauer.
• Die Bindung an den Release. Freigegebene Objekte überleben eine Umstellung. Direkte Tabellenzugriffe und eigene Bausteine auf Standardtabellen sind bei jedem Upgrade ein Prüfposten.

Die allgemeinen Integrationsmuster, also Punkt-zu-Punkt, Hub, API-led und ereignisgetrieben, haben wir in Systemintegration für geschäftskritische Systeme beschrieben. Hier geht es um die SAP-seitigen Wege selbst und um die Auswahl zwischen ihnen.

IDoc als SAP-Schnittstelle für Massenbelege mit Nachweiskette

Ein IDoc ist eine asynchrone Nachricht mit Kontrollsatz, Datensegmenten und Statussätzen. Die Verteilung läuft über Partnervereinbarungen und Ports, der Verarbeitungszustand hängt am einzelnen Beleg.

Genau dieser Punkt ist der Grund, IDoc zu wählen. Bei Aufträgen, Lieferungen und Rechnungen muss jeder Beleg einzeln nachweisbar sein: eingegangen, verarbeitet, fehlerhaft, erneut eingespielt. Der Status pro Beleg liefert das ohne zusätzlichen Bau, mit Monitoring in WE02 und WE05 und einem definierten Weg zur Wiedereinspielung über BD87.

Was der Weg im Betrieb kostet: Partnervereinbarungen und Ports pro Partner sowie eine Statusüberwachung als tägliche Aufgabe mit einem Verantwortlichen. Erweiterungen gehören in Kundensegmente statt in eine Änderung des Basistyps, weil nur die erste Variante eine Umstellung übersteht.

Die falsche Wahl ist IDoc, wenn ein Aufrufer innerhalb seines Requests eine Antwort braucht, etwa eine Verfügbarkeitsprüfung hinter einer Eingabemaske. Der Weg ist auf Durchsatz und Nachweisbarkeit ausgelegt, die Antwortzeit hängt am nächsten Verarbeitungslauf.

BAPI und RFC: synchrone SAP-Schnittstelle in die Geschäftslogik

Ein BAPI ist eine freigegebene Methode auf einem Geschäftsobjekt, technisch ein RFC-fähiger Funktionsbaustein. Der Vorteil liegt in den Prüfungen: die Buchung läuft durch die Logik des Standards, damit bleiben die Folgetabellen konsistent. Ein direkter Tabellenlesezugriff umgeht diese Logik und bricht bei jeder Feldlängen- oder Sichtänderung.

Die Betriebsarten unterscheiden sich stärker als die Aufrufsyntax vermuten lässt. Der synchrone Aufruf blockiert einen Dialogprozess, bis die Antwort da ist. Der transaktionale Aufruf sichert über eine Transaktions-ID die einmalige Ausführung und wird in SM58 überwacht. Der eingereihte Aufruf ergänzt die Reihenfolge über Warteschlangen in SMQ1 und SMQ2, was bei abhängigen Belegen der einzige tragfähige Modus ist.

Der Aufwand im Betrieb liegt bei den Ressourcen. Dialogprozesse sind ein begrenzter Pool, und ein Aufrufer mit 200 parallelen Verbindungen verdrängt die Sachbearbeitung. Die Laufzeitbegrenzung schneidet lange Aufrufe ab, was bei Massenverarbeitung halb gebuchte Zustände hinterlässt. Dazu kommt jede RFC-Destination als eigenes Sicherheitsobjekt mit einem technischen Benutzer.

Falsch ist der Weg bei Massenladungen, weil jeder Aufruf Aufbaukosten und eine eigene Commit-Grenze hat, und wenn das Fremdsystem von der Verfügbarkeit des SAP-Systems entkoppelt sein soll. Ein wiederkehrender Fehler: ein BAPI ohne anschließenden Commit-Aufruf meldet Erfolg, ohne etwas zu persistieren.

OData und SAP Gateway: Zugriff für Oberflächen und Abfragen

OData-Dienste über den SAP Gateway liefern HTTP und JSON, damit kommt jeder Client ohne SAP-Bibliotheken zurecht. Für Lesezugriffe einer Oberfläche, gefilterte Abfragen, Blättern über Seiten und einzelne Schreibvorgänge mit optimistischer Sperre über ETag ist das der direkteste Weg. Mehrere Änderungen lassen sich über einen Batch-Aufruf zu einer logischen Arbeitseinheit bündeln.

Der laufende Aufwand steckt in zwei Punkten. Jeder Entitätstyp ist Code mit einem Lebenszyklus. Und die Leistung hängt daran, ob ein Filter bis auf die Datenbank durchgereicht wird oder erst in der Anwendungsschicht greift: im zweiten Fall liest der Dienst die vollständige Menge in den Applikationsserver, was im Test mit 500 Datensätzen niemand bemerkt.

Die falsche Wahl ist OData bei nächtlichen Vollextraktionen über Millionen Zeilen, weil HTTP-Umläufe und Serialisierung den Durchsatz begrenzen. Ebenso bei Prozessen, die eine garantiert einmalige Zustellung brauchen: ein fehlgeschlagener Aufruf hinterlässt ohne eigene Protokollierung keine Spur, an der ein Betriebsteam ansetzen kann.

SAP Integration Suite und CPI: Mapping, Routing und Monitoring

Eine Integrationsplattform wie die SAP Integration Suite nimmt Mapping, Routing, Protokollumsetzung und Zertifikatsverwaltung aus den Endpunkten heraus. Warteschlangen im Tenant puffern und wiederholen, das Monitoring liegt für alle Strecken an einer Stelle.

Der Nutzen wird erst ab einer bestimmten Zahl von Strecken sichtbar. Liegen Mapping und partnerspezifische Eigenheiten außerhalb des ABAP-Stacks, berührt eine Systemumstellung sie nicht, und ein Betriebsteam hat eine Oberfläche statt sieben. Bei zwanzig SAP-Schnittstellen rechnet sich das, bei zwei nicht.

Die Kosten sind eine Subskription, ein zusätzlicher Sprung in der Latenz und ein Artefakt mit Lebenszyklus: Integrationsflüsse brauchen Transport zwischen Tenants, Versionierung und Tests. Wir behandeln diese Plattformentscheidung deshalb als Teil der Systemintegration, mit Transportweg, Versionierung und Betriebszuständigkeit. Falsch ist sie, wenn eine synchrone Antwort im Millisekundenbereich innerhalb einer Transaktion gebraucht wird, und wenn niemand benannt ist, der den Tenant betreibt.

Replikation und CDC: Auswertung außerhalb des Transaktionssystems

Für Auswertung, Datenplattform und Modellbau arbeitet man mit einer Kopie statt mit einem Aufruf. Drei Verfahren sind verbreitet: triggerbasierte Replikation mit Protokolltabellen im Quellsystem, logbasierte Erfassung auf Datenbankebene und delta-fähige Extraktoren über die Operational-Data-Provisioning-Schicht.

Was der Weg leistet: Abfragen über viele Tabellen und lange Zeiträume finden außerhalb des Transaktionssystems statt, und SAP-Daten lassen sich mit Nicht-SAP-Daten verbinden.

Was er kostet, wird regelmäßig unterschätzt. Sie replizieren das Tabellenmodell samt seiner Semantik in der Anwendungsschicht: mandantenabhängige Schlüssel, Beträge mit währungsabhängiger Dezimalverschiebung, Initialdaten als Nullwert statt als leeres Feld, Cluster- und Pooltabellen ohne direkte Entsprechung. Jede Logik, die SAP oberhalb der Tabelle anwendet, muss nachgebaut oder bewusst verworfen werden. Triggerbasierte Verfahren erhöhen zusätzlich die Schreiblast der Quelle.

Die falsche Wahl ist Replikation als Ersatz für eine Schreibstrecke und als Abkürzung für drei Felder, die ein gezielter Dienst günstiger liefert. Auch dann, wenn keine Stelle die fachliche Bedeutung der replizierten Felder verantwortet.

SAP Events: Entkopplung über einen Message Broker

Ereignisse melden eine Änderung an einen Broker, Abnehmer registrieren sich darauf. Der Nutzen liegt bei mehreren, teils noch unbekannten Abnehmern einer Änderung und bei Lastspitzen, die der Broker abfedert.

Der Preis besteht aus drei Posten. Die Zustellung ist in der Praxis At-least-once, damit muss jeder Abnehmer mit einer Doppelzustellung umgehen. Die Reihenfolge gilt nur innerhalb einer Warteschlange oder Partition. Und die Fehlersuche über eine Kette von Ereignissen funktioniert nur mit Korrelationskennungen, die von Anfang an mitgeführt werden.

Falsch sind Ereignisse, wenn der Abnehmer den vollständigen Beleg braucht, das Ereignis aber nur den Schlüssel trägt und kein verlässlicher Leseweg daneben existiert. Bei genau einem Abnehmer erzeugt der Broker Betriebsaufwand ohne Gegenwert.

Fehlerbehandlung und Wiedereinspielung von SAP-Schnittstellen

Die Anforderung lautet: pro Nachricht ist sichtbar, ob sie ankam, ob sie verarbeitet wurde, warum sie scheiterte und ob sie erneut eingespielt wurde. IDoc bringt das mit, transaktionale RFC-Aufrufe über ihre Transaktions-IDs, eine Integrationsplattform über Warteschlangen und Nachrichtenprotokoll. OData bringt es nicht mit.

Zwei Punkte gehören in jedes Design, bevor die erste Strecke live geht:

• Der Weg zur Wiedereinspielung ist eine Betriebsaufgabe mit Verantwortlichem, ausführbar über eine Transaktion oder eine Oberfläche. Solange er einen Entwickler mit Debugger braucht, ist er kein Betriebsprozess.
• Wiederholungen haben eine Obergrenze. Ein Lauf, der die Verarbeitung einer fehlerhaften Nachricht endlos wiederholt, erzeugt Last ohne Fortschritt und verdeckt alles, was dahinter wartet. Nach n Versuchen wird die Nachricht geparkt und gemeldet.

Diesen Teil zieht DNA Solutions in der Entwicklung von SAP-Schnittstellen vor die Fachlogik, weil er die Betriebskosten der nächsten Jahre bestimmt.

Idempotenz bei doppelter Zustellung

Jeder Transportweg mit At-least-once-Semantik liefert irgendwann zweimal: nach einem Timeout beim Sender, obwohl der Empfänger schon gebucht hatte, nach einer manuellen Wiedereinspielung, nach einer Neuzustellung des Brokers.

Tragfähig ist ein fachlicher Schlüssel, auf den sich beide Seiten festlegen, gespeichert mit dem Verarbeitungsergebnis. Eine Nachrichtenkennung aus dem Transport genügt nicht, weil eine Wiedereinspielung eine neue erzeugt. In Richtung SAP heißt das eine Dublettenprüfung auf dem Referenzfeld des Belegs oder eine eigene Tabelle, die die externe Kennung auf die erzeugte Belegnummer abbildet.

Beide Fehlerrichtungen gehören in den Test. Eine Doppelbuchung ist sichtbar und aufwendig zu stornieren. Eine verlorene Nachricht, die als Dublette verworfen wird, fällt erst beim Abgleich Wochen später auf.

Stammdaten, Schlüssel und Umschlüsselung in SAP-Schnittstellen

SAP-Schlüssel sind intern und typisiert: Buchungskreis, Werk, Materialnummer, Kostenstelle, Mengeneinheit. Das Fremdsystem hat eigene. Jede Strecke trägt deshalb eine Umschlüsselung, und die Frage ist, wo sie liegt und wer sie pflegt.

Die Formate sind der zweite Posten. Die Materialnummer wurde in S/4HANA auf 40 Stellen erweitert, der Geschäftspartner ist das führende Objekt für Kunde und Lieferant, Mengeneinheiten existieren als interner Code und als ISO-Code, Beträge haben eine währungsabhängige Zahl von Dezimalstellen.

Umschlüsselungstabellen, die in jeden Integrationsfluss kopiert wurden, weichen nach dem zweiten Änderungsantrag auseinander. Die Zuordnung gehört an eine Stelle mit einem Verantwortlichen, und wie diese Stelle aufgebaut wird, behandeln wir im Artikel zum Stammdatenmanagement im Unternehmen.

Batchfenster, Sperren und Massenläufe im SAP-Betrieb

SAP-Landschaften haben ein nächtliches Fenster mit Periodenabschluss und Massenläufen. Eine Strecke, die in dieses Fenster schreibt, konkurriert um Sperren und Arbeitsprozesse, und das Symptom zeigt sich meist an anderer Stelle: ein Timeout in einem unbeteiligten Prozess.

Drei Festlegungen helfen. Das Zeitfenster wird schriftlich mit dem SAP-Betrieb vereinbart. Die Parallelität liegt als Parameter vor, damit sie unter Last ohne Codeänderung reduziert werden kann. Und die Verarbeitung ist auf Belegebene wiederaufsetzbar, damit ein Abbruch nach 80 Prozent keinen vollständigen Neustart erfordert. Der Periodenabschluss steht dabei in einem anderen Kalender als der des Integrationsteams.

Release-Wechsel und S/4HANA: was SAP-Schnittstellen bricht

SAP nennt für SAP ERP 6.0 das Ende der Standardwartung im Jahr 2027 und eine kostenpflichtige erweiterte Wartung bis 2030 (Quelle: SAP, Wartungsstrategie). In den meisten DACH-Landschaften steht damit eine Umstellung im Plan, und jede Strecke ist darin eine Position.

Stabil bleiben freigegebene BAPIs und Standard-Basistypen. Prüfposten sind direkte Tabellenzugriffe, eigene Bausteine auf Standardtabellen und Lesezugriffe auf Strukturen, die in S/4HANA durch Kompatibilitätssichten ersetzt wurden. Der Aufwand einer Umstellung wird meist deshalb falsch geschätzt, weil das Register fehlt, das pro Strecke Objekt, Freigabestatus, Verantwortliche, Mengen und Kritikalität führt. Wie diese Position in eine Planung eingeht, steht in IT-Migration planen.

Datenhoheit: welches System ein Attribut führt

Die Frage, die die Richtung jeder Strecke festlegt: welches System führt welches Attribut. Ohne diese Festlegung schreiben zwei Systeme dasselbe Feld, und der letzte Schreibvorgang gewinnt durch Zufall.

Die Entscheidung fällt pro Attributgruppe und wird schriftlich festgehalten. SAP führt üblicherweise die abrechnungsrelevanten und finanziellen Attribute, ein Produktinformationssystem die Beschreibungen und Medien, ein CRM die Kontaktdaten.

Bidirektionale Strecken auf demselben Feld gehören zu den aufwendigsten Konstrukten einer Landschaft: gegenseitige Aktualisierungen, Schleifenschutz und Abgleichberichte. Wo sie unvermeidbar sind, braucht es eine Konfliktregel ohne menschliche Bewertung.

Sechs Fragen zur Auswahl der SAP-Schnittstelle

Die Auswahl lässt sich auf sechs Fragen zusammenziehen, in dieser Reihenfolge.

1. Braucht der Aufrufer eine Antwort innerhalb seines Requests? Wenn ja, bleiben BAPI beziehungsweise RFC und OData. Wenn nein, geht es weiter.
2. Sind es Belege mit Nachweispflicht in Menge? Dann IDoc, wegen des Status pro Beleg.
3. Ist das Ziel eine Auswertung über viele Tabellen und lange Zeiträume? Dann Replikation, mit einer benannten Stelle für die fachliche Bedeutung der Felder.
4. Gibt es mehrere, teils künftige Abnehmer derselben Änderung? Dann Ereignisse, mit idempotenten Abnehmern.
5. Wer betreibt Umsetzung, Zuordnung und Monitoring? Wenn die Antwort nicht im SAP-Team liegt, gehört die Strecke auf eine Integrationsplattform.
6. Welches System führt das betroffene Attribut? Diese Antwort legt die Richtung der Strecke fest.

Sprechen wir über Ihre SAP-Schnittstellen

DNA Solutions unterstützt Unternehmen im DACH-Raum bei Auswahl, Aufbau und Betrieb von SAP-Schnittstellen: von der Transaktionsgrenze über Wiedereinspielung und Idempotenz bis zum Schnittstellenregister, das die Umstellung des Kernsystems überdauert. Wenn eine neue Anbindung ansteht oder eine bestehende Strecke im Betrieb zu viel kostet, beginnen wir mit den sechs Fragen der Entscheidungsreihenfolge; diese Arbeit liegt bei wenigen Tagen und bestimmt die Betriebskosten der Jahre danach. Sprechen Sie uns an.