SAP-IDoc-Tutorial - Teil 1: IDoc Grundlagen und Begriffe

Was ist ein IDoc in SAP ERP?

Diese Definition für SAP-IDocs sollte alle Anwendungsfälle abdecken. Die korrekte Groß-/Kleinschreibung ist übrigens IDoc - nicht IDOC oder Idoc.

IDocs werden verwendet, um Daten zwischen zwei Stellen auszutauschen, die diese benötigen. Beide Systeme müssen in der Lage sein, die Semantik und Syntax des IDocs zu verstehen. Sie können sich IDocs einfach als ein standardisiertes Schnittstellenformat vorstellen, genau wie eine REST-API-Antwort, die von einem Frontend gelesen wird. IDocs werden bei der Ausführung eines ausgehenden ALE- oder EDI-Prozesses erzeugt.

IDocs werden durch eine IDoc-ID oder -Nummer identifiziert, die innerhalb eines Mandanten eindeutig ist. Dies ist wichtig - die IDoc-Nummer auf einem System identifiziert nicht dasselbe IDoc auf einem anderen System eindeutig! Einige andere wichtige Fakten über IDocs:

• IDocs können unabhängig von der technischen Architektur des sendenden und des empfangenden Systems verwendet werden. Das bedeutet, daß man IDocs theoretisch auch für den Datenaustausch zwischen Nicht-SAP-Systemen verwenden könnte - in der Praxis geschieht dies jedoch nie.
• IDocs basieren auf (recht alten) EDI-Standards, ANSI ASC X12 und EDIFACT.
• IDocs sind durch IDoc-Typen gekennzeichnet, die die Daten definieren, die sie enthalten können. Für den ein- und ausgehenden Datenaustausch wird derselbe IDoc-Typ verwendet. Es gibt keinen Unterschied bei den ein- und ausgehenden Daten.
• IDocs werden nicht in einem binären Format kodiert - stattdessen können sie in einem Texteditor angezeigt und sogar als XML exportiert werden.

Aufbau von IDocs in SAP ERP

Idocs gibt es in zwei Varianten. Traditionell sind sie ein Format mit fester Länge (1000 Bytes), aber in neueren Versionen gibt es auch ein XML-basiertes Format. Dies hat den Vorteil, dass es flexibler in der Anwendung ist, da es auf dem XML-Standard des W3C basiert. Über die SAP-Transaktion WE60 kann die Dokumentation zu allen IDocs eingesehen werden.

Beispielstruktur eines IDocs

In SAP-Systemen bestehen IDocs immer aus den folgenden drei Teilen.

• Der Kontrollsatz enthält Systeminformationen wie z.B. die Art des IDocs, z.B. "INVOIC02" für Rechnungen. Er enthält auch andere Verwaltungsinformationen wie den Partnerport, in welchem SAP-Release dieses IDoc erstellt wurde und andere Dinge.
• Datensätze sind der Ort, an dem der eigentliche Inhalt von IDocs gespeichert wird. Datensätze bestehen aus mehreren Segmenten, deren Anzahl, Art und Reihenfolge vom IDoc-Typ abhängt. Segmente in SAP-IDocs kann man sich als einen hierarchischen Baum der Anwendungs-Payload vorstellen, wie z.B. einen Auftragskopf und mehrere Auftragspositionen.
• Statussätze werden zur Dokumentation und Fehlersuche an ein IDoc angehängt. Sie sind eine Reihe von Nachrichten, die den Fluß und die Verarbeitung des Idocs dokumentieren und Informationen wie "IDoc wurde erstellt", "Der Empfänger existiert", "IDoc erfolgreich an den Port übergeben", "Auftrag wurde gebucht" enthalten. Anhand der Informationen in Statussätzen können SAP-Berater nachvollziehen, wie das IDoc von den beteiligten Systemen verarbeitet wurde und wo die Gründe für Fehler liegen könnten.

Diese Struktur ist natürlich auch in SAP-Systemen über die Transaktionen WE02 oder WE05 sichtbar.

Struktur desselben IDocs, zu sehen in der SAP-Transaktion WE02 (IDoc anzeigen)

IDoc-Typen

Ein IDoc-Typ definiert, welche Art von Daten im IDoc enthalten sind. Sie können sich ein IDoc als eine Instanz eines IDoc-Typs vorstellen, so wie ein Objekt in der objektorientierten Programmierung eine Instanz einer Klasse ist. Der IDoc-Typ steuert unter anderem:

• Welche Segmente das IDoc enthalten kann und wie der Inhalt des Datensatzes interpretiert werden muß (denken Sie daran, es handelt sich nur um eine 1000 Byte lange Klartextzeichenfolge)
• Welche Art von Verarbeitung wird auf das IDoc angewendet, nachdem es erstellt und gesendet wurde - eingehend oder ausgehend

IDoc-Typen können mit der SAP-Transaktio WE30 (IDoc-Typ-Entwicklung) definiert werden.

Sehen wir uns einige detailliertere Informationen über die in jedem IDoc vorhandenen Sätze an.

Kontrollsatz (Control Record)

Kontrollsätze werden in der Tabelle EDIDC mit der IDoc-Nummer als Primärschlüssel gespeichert. Dies sind einige der wichtigsten Informationen, die im IDoc-Kontrollsatz gespeichert sind:

• IDoc-Nummer, Zeitpunkt der Erstellung und Zeitpunkt der letzten Änderung
• SAP-Release des IDoc
• Status
• Richtung (1 bedeutet ankommend, 2 bedeutet abgehend)
• Empfängerport (SAP-System, EDI-Subsystem)
• Partnertyp und Nummer des Empfängers
• Adresse des Empfängers
• EDI-Standard und -Version
• Port, Partnerart, Partnernummer und Adresse des Absenders

Datensatz (Data Record)

Der Datensatz enthält Anwendungsdaten - wie z.B. Rechnungs-, Bestell- oder Lieferdaten. Die Datensätze für jedes IDoc sind in den SAP-Tabellen EDID2, EDID3 und EDID4 gespeichert. Die tatsächliche Nutzlast wird als Klartextstring im Feld SDATA gespeichert, das ein 1000 Zeichen langes Feld ist (daher die feste Länge für IDocs). Die Datensätze sind weiter in Segmente strukturiert. Segmente sind wiederverwendbare Datenstrukturen, die das Format von Datensätzen in IDocs definieren. Für jedes Segment gibt es einen Segmenttyp, eine Segmentdefinition und eine Segmentdokumentation, die mit der Transaktion WE31 eingesehen werden können. Die letzten drei Zeichen in einem Segmentnamen sind die Version, die bei jeder Änderung in einem neuen SAP-ERP-Release inkrementiert wird.

Statussatz (Status Record)

In jedem Schritt der IDoc-Verarbeitung wird ein Statussatz an ein IDoc angehängt. Dies geschieht sowohl bei erfolgreicher Verarbeitung als auch im Fehlerfall. Statussätze werden in der Tabelle EDIDS gespeichert. Die Status 1-42 gelten für die Ausgangsverarbeitung, während die Status 50-75 für die Eingangsverarbeitung gelten.

IDoc-Tabellen in SAP ERP

IDocs werden in der Datenbank gespeichert, genau wie jedes andere SAP-Objekt. Dies sind die relevanten Tabellen für IDocs in SAP:

• EDIDC - Tabelle für Kontrollsätze
• EDID2, EDID3, EDID4 - Tabellen für Datensätze
• EDIDS - Tabelle für Statussätze

IDocs mit Erweiterungssegmenten erweitern

Wie (fast) alles in SAP ERP können IDocs erweitert werden. Das Instrument dafür sind Erweiterungssegmente. Sie können nicht für jeden IDoc-Typ die Grundstruktur der Segmente ändern, da dies die Standards, auf denen IDocs basieren, und damit die Kompatibilität mit anderen Systemen verletzen würde. Was Sie jedoch tun können, ist das Hinzufügen von Erweiterungssegmenten, d.h. Sie fügen kundenspezifische Daten am Ende des IDocs hinzu.

Ich werde in einem weiteren Blogbeitrag beschreiben, wie man dies im Detail macht.

IDoc-Typendokumentation in SAP ERP

Jeder IDoc-Typ verfügt über eine sehr detaillierte Dokumentation, die direkt in SAP ERP über die Transaktion WE60 eingesehen werden kann. Ein Beispiel:

Weitere IDoc-bezogene Definitionen

Um den Kontext zu verstehen, in dem IDocs arbeiten, ist es nützlich, einige Begriffe erklären zu lassen, bevor wir uns die Arbeit mit IDocs genauer ansehen.

Nachrichtenarten und IDoc Views

Nachrichtenarten repräsentieren bestimmte Arten von Geschäftsdokumenten im EDI - wie z.B. Bestellungen, Auftragsbestätigungen, Rechnungen. IDoc-Typen können mit Transaktion WE81 in einer Many-to-Many-Beziehung auf Nachrichtenarten abgebildet werden.

Da IDocs für mehrere Nachrichtentypen verwendet werden können, enthalten sie oft mehr Felder als für eine bestimmte Nachricht erforderlich. Daher können IDoc-Sichten verwendet werden, um Projektionen von IDoc-Typen zu erstellen, die nur einige der verfügbaren Segmente des IDoc-Typs verwenden. Sie gelten nur für die Ausgangsverarbeitung, da bei der Eingangsverarbeitung dieser Overhead unproblematisch ist. IDoc-Sichten können mit der Transaktion WE32 gepflegt werden.

Partnerprofile

Partnervereinbarungen im Kontext von EDI/ALE/IDoc sind Geschäftspartner, mit denen ein SAP-System Dokumente austauschen kann. Mit der Transaktion WE20 können Sie die für den Datenaustausch notwendigen Parameter pflegen.

Port

Ports sind der Ort, an dem die technischen Eigenschaften einer Verbindung zwischen einem SAP-System und einem angeschlossenen System ("Subsystem") gepflegt werden. Sie definieren, was mit IDocs nach dem Versenden geschieht. Einige der gebräuchlichsten Ports sind der HTTP-Port für den direkten IDoc-Austausch im XML-Format, der von EDI verwendete Datei-Port oder der von ALE verwendete TRFC-Port.

Der Dateiport eignet sich hervorragend für das Debugging, da er das erstellte IDoc in einer Datei innerhalb eines Dateisystems ausgibt. Er ist auch die grundlegendste Art, Schnittstellen zum Lesen von Daten aus SAP aufzubauen, da so ziemlich jedes andere System so konfiguriert werden kann, daß es Dateien in bestimmten Formaten liest.

Ein vollständiger IDoc-Prozessfluss

Hier ist ein Beispiel auf hoher Ebene für die Schritte bei der Verarbeitung eines IDocs. Nehmen wir an, wir möchten eine Bestellung an einen mit uns verbundenen Lieferanten über EDI senden. Nehmen wir an, der Lieferant hat auch SAP ERP.

• Die Bestellung wird auf welchem Weg auch immer im SAP-System angelegt.
• Es wird automatisch ein IDoc erstellt und an den Partner gesendet. Da EDI aktiviert ist und eine Partnervereinbarung gepflegt ist, wird das IDoc an diesen Partner gesendet.
• Der Lieferant erhält das IDoc in seiner Eingangsverarbeitungswarteschlange. Es erhält eine andere Nummer, da es sich jetzt in einem anderen System befindet, aber der Nachrichtentyp bleibt derselbe!
• Das IDoc wird für den Lieferanten verarbeitet, wobei aus den Daten des Datensatzes ein SAP-Business-Objekt erzeugt wird. In diesem Fall würde es wahrscheinlich einen Kundenauftrag anlegen.
• Ein Auftragsbestätigungs-IDoc wird erstellt und auf dem gleichen Weg an den ursprünglichen Partner zurückgeschickt.

Das Senden von Daten aus dem eigenen SAP-System wird als Ausgangsverarbeitung, das Empfangen von Daten aus anderen Systemen als Eingangsverarbeitung bezeichnet. SAP-Entwickler oder Berater werden häufig damit beauftragt, diese Kommunikationswege einzurichten. Hier sind die erforderlichen Schritte aufgeführt:

Wie Sie die Ausgangsverarbeitung für IDocs einrichten

Dies sind die übergeordneten Schritte, die zum Einrichten der ausgehenden IDoc-Verarbeitung erforderlich sind.

• Wählen Sie den zu verwendenden IDoc-Typ aus (Transaktion WE30).
• Prüfen Sie, ob es notwendig ist, einen Nachrichtenart zu erstellen (WE81).
• Ordnen Sie ggf. den IDoc-Typ einer Nachrichtenart zu (WE82).
• Wählen Sie einen Port aus oder legen Sie einen Port an (WE21).
• Legen Sie eine Partnervereinbarung an oder wählen Sie diese aus (WE20). Diese enthält die Kommunikationsdetails für den Partner, an den das IDoc gesendet wird.
• Legen Sie etwas an, das IDocs erzeugt - entweder manuell mit ABAP-Code in einem User-Exit oder mit der Methode der Nachrichtensteuerung (in diesem Fall ist es notwendig, einen Funktionsbaustein zur IDoc-Erzeugung anzulegen und ihn einem Ausgangsvorgangscode zuzuordnen).
• Das IDoc auslösen.

So richten Sie die Eingangsverarbeitung für IDocs ein

Dies sind die übergeordneten Schritte, die zum Einrichten der eingehenden IDoc-Verarbeitung erforderlich sind.

• Wählen Sie den zu verwendenden IDoc-Typ aus (Transaktion WE30).
• Prüfen Sie, ob es notwendig ist, einen Nachrichtentyp zu erstellen (WE81).
• Ordnen Sie ggf. den IDoc-Typ einem Nachrichtentyp zu (WE82).
• Erstellen Sie einen Funktionsbaustein, der tatsächlich etwas mit dem empfangenen IDoc macht. An dieser Stelle wird Ihre kundenspezifische Eingangsverarbeitungslogik ansetzen.
• Pflegen Sie Ihren Funktionsbaustein so, daß er tatsächlich eingehende IDocs verarbeiten kann (BD51).
• Ordnen Sie den neuen Eingangsfunktionsbaustein dem Nachrichtentyp zu (WE57).
• Definieren Sie einen Vorgangscode für den Eingang (WE42).
• Legen Sie eine Partnervereinbarung an oder wählen Sie diese aus (WE20).
• Warten Sie auf ein eingehendes IDoc oder stoßen Sie es manuell an, um zu sehen, wie es verarbeitet wird.

IDoc-Transaktionen in SAP ERP

Diese hilfreiche Liste enthält eine Auswahl von IDoc-Transaktionen, die bei der Entwicklung oder Arbeit mit IDocs nützlich sind.

IDoc-Such- und Anzeigetransaktionen

• WE05 - IDoc Lists
• WE02 – Display IDocs
• WE09 – Search IDocs by Content
• WE10 – Search for IDocs in Archive
• WE11 – IDoc Deletion

IDoc-Verwaltung und Dokumentationstransaktionen

• WE06 – Active IDoc Monitoring
• WE07 – IDoc Statistics
• BD87 – Status Monitor for ALE Messages
• WE20 – Partner Profiles
• WE21 – Port definitions
• WE60 – Documentation for IDoc types
• WE64 – Documentation for Message types
• SM59 – RFC Destinations
• SM58 – Error protocol asynchr. RFC

IDoc-Entwicklungstransaktionen

• WE31 – Development IDoc Segment
• WE30 – Development IDoc Type
• WE81 – Logical Message Types
• WE82 – Assign Message Types to IDoc Types
• WE41 – Process codes, outbound
• WE42 – Process codes, inbound
• BD51 – Maintain function modules (inbound)
• WE57 – Assignment Messages for Application Objects
• WE32 – Development IDoc Views

IDoc Testtransaktionen

• WE12 – Test Modified Inbound File
• WE14 – Test Outbound Processing
• WE15 – Test Outbound Processing from MC
• WE16 – Test Inbound Processing
• WE17 – Test Status File
• WE18 – Create Status File
• WE19 – IDoc Test Tool

Ich wünsche erfolgreiche IDoc-Entwicklung!!