SAP un ne‑SAP integrācija: IDoc, OData, faili un ziņojumu brokeris — salīdzinājums ar tipiskajām kļūdu situācijām

Der Anruf kommt selten mit einem sauberen Ticket. Meist heißt es: „Der Auftrag ist im SAP da, aber im Non-SAP-System fehlt er. Gestern ging es noch.“ Im Monitoring ist nichts Rot, der Batch-Job lief „grün“, und trotzdem passt der Datenstand nicht. Spätestens wenn jemand vorschlägt, „einfach nochmal anzustoßen“, wird es heikel: Der schnellste Weg zur doppelten Buchung ist ein Retry ohne Diagnose.

Genau in solchen Situationen entscheidet sich, ob SAP- und Non-SAP-Integration als planbarer Betrieb läuft oder als Dauerfeuer aus Rückfragen. Die weniger hilfreiche Reaktion ist: „Wir standardisieren jetzt alles auf eine Integrationsart.“ Das klingt ordentlich, ignoriert aber Prozessrealität, Fehlerbilder und Zuständigkeiten. Die bessere Reaktion ist, den entscheidenden Moment ernst zu nehmen: Erst trennen, welche Fehlerklasse vorliegt (Transport, Security, fachliche Ablehnung, temporäre Überlast), dann die passende Technik wählen oder die bestehende Strecke betriebsfest machen.

SAP- und Non-SAP-Integration: Der entscheidende Moment ist die Kopplung

Für die Architektur ist nicht die Schnittstellenform das Problem, sondern das Versprechen dahinter. Vier gängige Wege – IDoc, OData, Files und Message Broker – stehen für vier Arten von Kopplung:

• IDoc (Intermediate Document) steht in SAP für asynchrone Belegflüsse mit Statuskette und klarer Trennung zwischen Transport und Anwendung.
• OData ist eine HTTP-basierte Service-Schnittstelle, meist synchron genutzt (Request/Response), typischerweise über SAP Gateway.
• Files (z. B. CSV/XML via SFTP/FTP) sind batch- und ordnergetrieben. Sie sind schnell angebunden, bringen aber ohne Zusatzregeln wenig Nachvollziehbarkeit.
• Message Broker (z. B. RabbitMQ, Kafka) entkoppeln Systeme über Queues oder Topics/Logs. Sie puffern, verteilen und skalieren – aber Zustellsemantik muss bewusst gestaltet werden.

Die operative Leitfrage dahinter ist simpel: Muss jemand auf die Antwort warten (synchron), oder reicht „innerhalb von X Minuten sichtbar“ (asynchron)? Und ist das fachliche Objekt ein Belegfluss (Auftrag/Lieferung/Rechnung) oder ein Service-Zugriff (Status, Stammdaten, Freigaben)?

IDoc, OData, Files, Message Broker im Vergleich: Was sich im Betrieb wirklich unterscheidet

Viele Diskussionen drehen sich um „Modernität“. Im Betrieb zählen andere Kriterien: Wo sehe ich den Fehler? Kann ich nachverarbeiten, ohne Daten zu beschädigen? Was ist die kleinste sinnvolle Beobachtungseinheit (Beleg, Nachricht, Datei, Request)?

IDoc: Statuscodes als Diagnose-Kompass statt Bauchgefühl

IDoc ist in vielen Landschaften das Rückgrat für Belegintegration. Der Vorteil: Das System gibt Ihnen eine nachvollziehbare Verarbeitungskette. Wer diese Kette sauber liest, spart sich blinde Retries.

Typische IDoc-Fehlerbilder entlang der Verarbeitungskette

SAP dokumentiert IDoc-Status und deren Bedeutung – und damit die Grundlage, Transportfehler von Applikationsfehlern zu trennen.^[Quelle] Für den Betrieb ergibt sich daraus ein klarer Nutzen: Runbooks können nach Statusfamilien strukturiert werden, statt bei jedem Ticket „alles“ zu prüfen.

• Status 02: Fehler beim Übergang an den Port. Häufig ist die Ursache in der Port-/Kommunikationsschicht (Erreichbarkeit, Subsystem, Dateisystem), nicht im Fachobjekt.
• Status 03: Daten an den Port übergeben – ab hier ist die Frage: Wie sieht der Weitertransport aus (z. B. tRFC)?
• Status 51: Anwendung hat nicht gebucht. Das ist typischerweise fachlich oder Customizing-getrieben (Stammdaten, Prüfungen, Sperren).
• Status 53: Anwendung hat gebucht. Wenn danach dennoch „nichts ankommt“, liegt das Problem meist hinter der Buchung (Folgeprozesse, Mapping, Downstream).

Wenn Inbound „steht“: nicht neu senden, sondern Stauursache finden

Ein verbreitetes Fehlerbild ist, dass ein Inbound-IDoc zwar eingetroffen ist, aber die Anwendung nicht erreicht. SAP beschreibt für die Fehleranalyse unter anderem Wiederhol-/Folgeverarbeitung sowie Sperr- und Objektkonflikte als mögliche Ursachen.^[Quelle] Praktisch heißt das: Ein „nochmal senden“ kann den Stau vergrößern. Die bessere Reihenfolge ist: Blockade erkennen, gezielt nachverarbeiten, dann erst entscheiden, ob ein erneutes Senden fachlich erlaubt ist.

tRFC als nächster Prüfpunkt: Zuständigkeiten sauber trennen

Wenn ein IDoc im Monitor zeigt, dass es weitergegeben wurde, liegt die nächste Spur oft im tRFC-Umfeld. SAP verweist bei solchen Fällen explizit auf tRFC-Monitoring (z. B. SM58) und nennt typische Ursachen wie fehlerhafte RFC-Destination oder Portkonfiguration.^[Quelle] Das ist mehr als ein technisches Detail: Es ermöglicht eine klare Eskalation (Basis/Netzwerk vs. Applikation/Customizing) und reduziert Ping-Pong zwischen Teams.

OData: Wenn HTTP sauber ist, aber Security die Strecke stoppt

OData ist in vielen Projekten die Brücke zu Portalen, mobilen Apps oder externen Business-Software-Komponenten. Der Vorteil liegt in klaren Ressourcen und einem standardisierten Web-Stack. Der Alltagshaken: Viele Störungen sind keine „Datenprobleme“, sondern entstehen an der Schnittstelle von HTTP-Mechanik, SAP Gateway und Rollen/Berechtigungen.

Typisches Fehlerbild: HTTP 403 ist nicht gleich „fehlende Rolle“

SAP beschreibt 403-Probleme im Gateway-Kontext unter anderem im Zusammenhang mit CSRF-Token-Anforderungen (CSRF = Schutzmechanismus gegen unerwünschte Schreibzugriffe) sowie mit inaktiven ICF/SICF-Services oder bestimmten Konfigurations-/Hub-Varianten.^[Quelle] Die praktische Konsequenz: Ein 403 kann korrektes Schutzverhalten sein. Dann hilft kein „Retry“, sondern ein sauberer Blick auf Token-Handling, Service-Aktivierung und den technischen Aufrufkontext.

Auch „No authorization to access Service“ ist ein häufiger Klassiker (ebenfalls oft als 403 sichtbar). SAP verweist hier auf die Gateway-Error-Logs und die klassische Berechtigungsanalyse als Standardpfad.^[Quelle] Für den Betrieb lohnt sich ein festes Schema: Welcher Benutzer? Welcher Service? Welches Backend? Welche Rolle? Gibt es vorgeschaltete Komponenten (Reverse Proxy, WAF), die zusätzlich sperren?

Diagnosestartpunkt: /IWFND/ERROR_LOG und /IWBEP/ERROR_LOG

OData-Fehler sind ohne Kontext schwer zu greifen. SAP nennt die dedizierten Error-Log-Transaktionen /IWFND/ERROR_LOG (Hub) und /IWBEP/ERROR_LOG (Embedded/Business Suite) als zentralen Einstieg, weil dort Service, Zeitpunkt und technische Details zusammenlaufen.^[Quelle] Operativ heißt das: Wer nur im Client oder im Webserver-Log sucht, sieht häufig nur Symptome. Die Gateway-Logs liefern die Richtung, in der sich die Störung tatsächlich auflösen lässt.

Files: Der schnelle Projektstart rächt sich, wenn Quittung und Idempotenz fehlen

Dateibasierte Integration ist verbreitet, weil sie organisatorisch niedrigschwellig ist: Ein Partner kann Dateien ablegen, ein Job liest sie ein. Das Problem beginnt, wenn „Datei vorhanden“ als Erfolg gewertet wird und niemand festlegt, wie Fehler, Wiederholungen und Versionen gehandhabt werden.

Typisches Fehlerbild: Encoding, Codepage und „unsichtbare“ Abweichungen

SAP beschreibt beim File/FTP-Adapter unter anderem die Abhängigkeit von in der Java-Runtime installierten Codepages für Zeichensatzkonvertierung.^[Quelle] Der praktische Effekt ist vielen Teams unangenehm bekannt: In Test funktioniert der Import, in Produktion kippt er bei Umlauten, Sonderzeichen oder Delimiter-Kollisionen. Ursache ist dann nicht „die Datei“, sondern die Laufzeitumgebung inklusive Locale und Codepage-Ausstattung.

Fünf Regeln, die Files betriebsfest machen

Wenn Files bleiben müssen (Partnerfähigkeit, Altsystem, Übergangsphase), dann sollten sie wie eine Schnittstelle mit Vertrag behandelt werden. Eine praxistaugliche Reihenfolge ist:

1. Atomare Übergabe: Upload als Temp-Datei, erst danach Rename/Move als Fertig-Signal. Kein Einlesen offener Dateien.
2. Technische Quittung: „angenommen/abgelehnt“ als eigener Kanal (z. B. Quittungsdatei oder Message) mit eindeutiger Referenz.
3. Fachliche Quittung: bei Belegbuchungen getrennt von der technischen Annahme: „gebucht/abgewiesen“ inkl. Grundcode.
4. Idempotenz: Jede Datei/jeder Datensatz braucht eine eindeutige ID; das Zielsystem prüft „schon verarbeitet“ bevor es schreibt.
5. Reprocessing-Regeln: Was darf erneut eingespielt werden? Wie werden Korrekturen gekennzeichnet (Version/Delta), und wer darf das auslösen?

Ohne diese Punkte sind Files nicht „einfach“, sondern nur schnell – und ziehen später Support, Datenbereinigung und Streit über Verantwortlichkeiten nach sich.

Message Broker: Entkopplung ist wertvoll, aber Zustellsemantik ist ein Designentscheid

Broker sind attraktiv, wenn mehrere Systeme versorgt werden müssen, wenn Lastspitzen gepuffert werden sollen oder wenn sich eine Event-Architektur entwickeln soll. Der Effekt ist spürbar: Sender und Empfänger müssen nicht gleichzeitig verfügbar sein. Die Gegenleistung ist ebenso spürbar: Der Betrieb muss Backlogs, Consumer-Fehler und Zustellgarantien aktiv managen.

RabbitMQ: Acks, Requeue, Redelivery – und warum Duplikate „normal“ sind

RabbitMQ beschreibt im Reliability Guide die Konsequenzen der Acknowledgement-Strategie: Ohne Acks ist Message Loss möglich (at-most-once). Mit (manuellen) Acks kann es bei Verbindungs- oder Consumer-Problemen zu Requeue/Redelivery kommen (at-least-once), wodurch Duplikate entstehen können.^[Quelle] Die operative Folgerung ist hart, aber hilfreich: Wenn Ihr Zielsystem nicht idempotent konsumieren kann, ist die „Zuverlässigkeit“ des Brokers fachlich gefährlich, weil Retries reale Doppelverarbeitung auslösen.

Kafka: at-least-once als Default, Exactly-once ist kein Häkchen

Kafka dokumentiert at-least-once als Standard und beschreibt Idempotenz/Transaktionen als Mechanismen, um Duplikate durch Retries zu vermeiden bzw. Commit-Verhalten zu steuern.^[Quelle] Für IT-Entscheider bedeutet das: Kafka ist stark, wenn Sie Replay, Streaming und Auditierbarkeit benötigen. Es verlangt aber Disziplin bei Schema-Evolution, Consumer-Versionen und Aufbewahrungszeiten. Sonst wird aus „Event-Verteilung“ ein schwer debuggbarer Datenstrom mit Interpretationskonflikten.

Von der Störung zur Entscheidung: ein pragmatischer Ablauf, der im Alltag trägt

Wenn die Landschaft schon gemischt ist (und das ist sie meistens), hilft eine kurze Schrittfolge, die Diagnosefähigkeit und Design zusammenbringt. Sie lässt sich für neue Strecken genauso nutzen wie für „Dauerbrenner“-Schnittstellen.

1. Prozesscharakter klären: Belegbuchung, Stammdaten, Statusabfrage, Massendaten. Müssen Reihenfolge und Vollständigkeit garantiert sein?
2. Kopplung festlegen: synchron (Nutzer wartet) oder asynchron (Puffer, SLA in Minuten). Das entscheidet über Timeouts, Lastspitzen und Fehlertoleranz.
3. Fehlerklassen definieren: Transport/Netz, Security/Berechtigung, fachliche Ablehnung, temporärer Fehler (Retry-fähig). Jede Klasse braucht einen sichtbaren Ort.
4. Idempotenz fest verdrahten: Schlüsselstrategie (z. B. externe Beleg-ID + Position + Version) und persistierter „schon verarbeitet“-Nachweis im Ziel.
5. Observability planen: Korrelation-ID, fachliche Referenzen, Metriken (Backlog, Durchsatz, Fehlerquote), und eine Stelle, an der Teams gemeinsam nachsehen.
6. Reprocessing regeln: Wer darf neu starten, wie oft, mit welchen Stop-Kriterien? Was passiert mit Poison Messages oder fachlich abgewiesenen Fällen?
7. Rollout und Versionierung: API-/Schema-Versionen, Cutover-Fenster, Rückfallweg, Testdaten und Kommunikationsplan.

Klare Grenzen: sinnvolle Kombinationen statt „Entweder-oder“

In der Praxis ist die beste Lösung häufig hybrid – aber nicht beliebig. Ein paar klare Grenzen halten den Integrationsstack beherrschbar:

• IDoc ist stark für klassische ERP-Belegflüsse und asynchrone Robustheit. Grenze: Für interaktive, fein granulare UI-Operationen ist es oft zu schwerfällig.
• OData ist stark als Service-Schicht für Portale und gezielte Prozess-APIs. Grenze: Ohne API-Lifecycle (Versionierung, Deprecation, Rollenmodell) entsteht schnell Wartungsdruck.
• Files sind sinnvoll als Randintegration oder Übergang, wenn Quittung, atomare Übergabe und Idempotenz geregelt sind. Grenze: Ohne Vertrag werden sie zum Duplikat- und Supportgenerator.
• Message Broker eignet sich als Rückgrat für Entkopplung und Ereignisverteilung. Grenze: Er ersetzt weder fachliche Konsistenzlogik noch Datenmodell; er verschiebt Verantwortung in Consumer-Design und Betrieb.

Ein häufig tragfähiges Zielbild ist: IDoc für Belegströme aus SAP, OData für gezielte Status- und Stammdaten-Services, Broker zur Verteilung an mehrere Non-SAP-Komponenten, und Files nur dort, wo Partnerfähigkeit oder Archivierung es erzwingt – dann aber mit Quittung und kontrollierter Nachverarbeitung.

Schlussmoment: Beim nächsten „Es kommt nichts an“ zuerst kategorisieren, dann handeln

Wenn die nächste Störung aufläuft, hilft keine Technologiedebatte. Hilfreich ist eine schnelle Kategorisierung: Transport? Security? Fachliche Ablehnung? Temporäre Überlast? IDoc-Statusketten, Gateway-Error-Logs, File-Konventionen und Broker-DLQs sind dafür keine Extras, sondern Betriebsvoraussetzung. Wer das sauber aufsetzt, reduziert nicht nur Incidents, sondern auch den Druck, „einfach nochmal zu senden“.

Wenn Sie Ihre SAP- und Non-SAP-Integration so ordnen möchten, dass Architekturentscheidungen, Betrieb und Reprocessing zusammenpassen, lässt sich das in einem kurzen Abgleich zu Zielbild, Schnittstellenverträgen und Runbooks klären: Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.

Für dieses Thema sind auch Sap Idoc Status 02 51 53 und Sap Gateway Odata 403 Csrf wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.