SAP-Wiki

IDoc

Ein IDoc (Intermediate Document) ist ein SAP-eigenes Datenformat für den asynchronen Austausch von Geschäftsdaten zwischen SAP-Systemen oder mit externen Anwendungen. Aufträge, Lieferungen oder Rechnungen werden dabei in ein festes Segmentformat verpackt und über das ALE-Verfahren oder eine Middleware verschickt. IDocs zählen bis heute zu den am weitesten verbreiteten SAP-Schnittstellenformaten.

Definition

Was ist IDoc?

Das IDoc-Konzept stammt aus den frühen Tagen von SAP R/3 und wurde für die Anwendung Link Enabling (ALE) entwickelt, den Datenaustausch zwischen mehreren SAP-Systemen ohne direkte Programmverbindung. Ein IDoc bündelt die Daten eines Geschäftsvorfalls, etwa eines Auftrags oder einer Materialbewegung, in einer festen Struktur aus Kopf- und Datensegmenten. Diese Struktur ist seit Jahrzehnten stabil, wodurch sich Schnittstellen zu Fremdsystemen und Partnern verlässlich pflegen lassen, auch über Releasewechsel hinweg.

Relevant ist das IDoc-Format für jedes Unternehmen, das SAP mit anderen Systemen verbindet: einem Lagerverwaltungssystem, einem EDI-Provider für den Rechnungsaustausch mit Kunden oder einer externen Middleware. Technisch verantwortlich sind meist SAP-Basis-Administratoren und Entwickler, die Segmentstruktur, Partnervereinbarungen und die Verarbeitung fehlerhafter IDocs in Transaktionen wie WE02 oder WE19 im Blick behalten. In neueren Architekturen tritt das IDoc zunehmend neben modernere Formate wie OData oder REST-Schnittstellen auf der SAP BTP.

Im laufenden Betrieb entstehen die meisten Probleme an der Prozessüberwachung, kaum am Format selbst: IDocs, die wegen Systemfehlern oder falschen Partnervereinbarungen fehlschlagen, bleiben unbemerkt im Status Fehler stehen, wenn niemand das Monitoring pflegt. Wer viele Schnittstellenpartner hat, braucht klare Regeln für Wiederanstoß und Eskalation, sonst stauen sich fehlgeschlagene Belege unbemerkt über Wochen. Ein einfacher wöchentlicher Blick in die Fehlerqueue verhindert die meisten dieser Fälle, bevor sie beim Fachbereich zum Problem werden.

Funktionen

Wie funktioniert IDoc?

Technisch besteht ein IDoc aus einem Kontrollsatz, der Absender, Empfänger und Nachrichtentyp beschreibt, sowie beliebig vielen Datensegmenten mit den eigentlichen Feldwerten. Der Nachrichtentyp, etwa ORDERS für Bestellungen oder INVOIC für Rechnungen, legt die Struktur der Segmente fest. Beim Versand schreibt das sendende System das IDoc in eine Datenbanktabelle, das ALE-Layer verpackt es und schickt es über eine RFC-Verbindung oder eine Middleware an den Empfänger, der es in seiner eigenen Segmentstruktur wieder auflöst.

Im Zusammenspiel mit Nachbarsystemen übernimmt häufig eine Middleware wie SAP Process Orchestration oder die SAP Integration Suite die Übersetzung zwischen IDoc und externen Formaten wie XML oder EDIFACT. Auf der Empfängerseite prüft ein Partnerprofil, welcher Nachrichtentyp erwartet wird und welche Vorgänge im Zielsystem daraus entstehen, etwa ein neuer Lieferauftrag oder eine gebuchte Wareneingangsmeldung. Diese Partnervereinbarungen werden einmalig eingerichtet und sollten bei jedem neuen Schnittstellenpartner oder Nachrichtentyp aktualisiert werden, sonst bleibt die Verarbeitung im Zielsystem stecken.

Vorteile

Stabiles Format

Die Segmentstruktur ist seit Jahrzehnten kompatibel. Schnittstellen zu Partnern und Altsystemen laufen auch nach einem SAP-Release-Wechsel meist unverändert weiter.

Eingebautes Monitoring

Transaktionen wie WE02, WE05 und BD87 zeigen Status und Fehler direkt im System, ohne zusätzliches externes Werkzeug.

Weit verbreitet

Viele Partner, EDI-Provider und Altsysteme unterstützen IDocs bereits, was neue Anbindungen oft schneller macht als komplett neue Schnittstellenformate.

Stabil bei Lastspitzen

Da IDocs zwischengespeichert und bei Bedarf erneut verarbeitet werden, verkraftet das Verfahren auch kurzzeitige Ausfälle des Zielsystems ohne Datenverlust.

Grenzen

Kein Echtzeit-Standard

IDocs sind für asynchrone Verarbeitung gedacht. Wer Antworten in Millisekunden braucht, etwa für eine Web-Anwendung, ist mit OData oder REST besser bedient.

Monitoring wird unterschätzt

Ohne aktive Überwachung der Fehlerqueue stauen sich fehlgeschlagene IDocs unbemerkt. Das fällt oft erst auf, wenn Kunden nach fehlenden Lieferungen fragen.

Starre Struktur

Änderungen an Segmenten erfordern Custom-Erweiterungen und Abstimmung mit allen Schnittstellenpartnern. Für flexible, sich häufig ändernde Datenmodelle ist das Format unhandlich.

Kein Ersatz für moderne APIs

Für neue Cloud-Integrationen auf der SAP BTP setzen die meisten Projekte inzwischen auf OData-Services statt auf neue IDoc-Schnittstellen.

FAQ

Häufige Fragen zu IDoc

Was ist der Unterschied zwischen IDoc und BAPI?

Eine BAPI wird synchron aufgerufen und liefert sofort eine Antwort. Ein IDoc wird asynchron verschickt und zeitversetzt im Zielsystem verarbeitet. Für Massendaten wie tägliche Belegübertragungen ist das IDoc oft die einfachere Wahl, für Echtzeitabfragen die BAPI oder ein API-Aufruf.

Wie überwacht man fehlgeschlagene IDocs?

Über die Transaktionen WE02 oder WE05 lassen sich Status und Fehlertext einsehen, über BD87 lässt sich ein fehlgeschlagenes IDoc erneut anstoßen. In produktiven Landschaften lohnt sich zusätzlich ein automatisiertes Monitoring, das Fehler proaktiv meldet statt erst bei einer Kundenreklamation.

Ersetzt OData das IDoc?

Für neue Cloud-Integrationen auf der SAP BTP setzen die meisten Projekte inzwischen auf OData-Services. Bestehende IDoc-Schnittstellen zu Altsystemen und EDI-Partnern laufen aber in vielen Landschaften unverändert weiter, ein Wechsel lohnt sich meist erst bei einer größeren Systemumstellung.

Welche IDoc-Typen kommen am häufigsten vor?

Verbreitet sind ORDERS für Bestellungen, DESADV für Lieferavise, INVOIC für Rechnungen und MATMAS für Materialstammdaten. Welcher Typ benötigt wird, hängt vom jeweiligen Geschäftsprozess und Schnittstellenpartner ab. In der Praxis lohnt sich eine Liste aller genutzten Nachrichtentypen, um bei einer Systemumstellung keinen davon zu übersehen.

Braucht man Programmierkenntnisse, um mit IDocs zu arbeiten?

Für die reine Überwachung reichen SAP-Basis-Kenntnisse und Vertrautheit mit den Monitoring-Transaktionen. Für neue oder angepasste Segmentstrukturen ist ABAP-Entwicklung nötig, meist in Abstimmung mit dem Schnittstellenpartner. Wer nur bestehende Schnittstellen betreibt, kommt in aller Regel ohne eigene Entwicklungsarbeit aus.

Ihr Kontakt

Gabriele Görtz

Head of Sales & Growth

Sprechen Sie mit uns.

Ein Erstgespräch dauert 30 Minuten. Sie können auch direkt mit einem konkreten Thema kommen. Rufen Sie an oder schreiben Sie uns.

+49 40 69 658 50-0

Anwender-Helpdesk für Bestandskunden:

0800 52388 55 (kostenfrei)