Allgemeines?
IDoc ist das Format, in dem SAP-Systeme ihre Daten ausspucken bzw. einlesen können. Wie sowas geht, ist im Kapitel zu SAP unter „Datenquellen und -senken“ angerissen. Auf unterer Ebene ist IDoc eine FixRecord-Struktur. Oder auch XML, je nach dem. Da aber das Format selbst schon verwirrend genug ist, klären wir den vorigen Satz gleich mal auf. SAP bietet für den Austausch kompletter Dokumente schon seit langem die sogenannte ALE-Schnittstelle an. Dazu schauen Sie bitte in das oben genannte Kapitel. Via ALE werden IDocs im FixRecord-Format ausgetauscht. Die ALE-Kommunikation war ursprünglich nur für den Austausch zwischen zwei SAP-Systemen gedacht. Seit einiger Zeit bietet SAP aber zur Kommunikation mit der Außenwelt (also nicht-SAP-Software) das Modul PI (bzw. vormals XI) an. Und das wiederum „spricht“ XML. Die XML-Strukturen sind im Großen und Ganzen platte Umsetzungen der alten FixRecord-Strukturen, nur eben in XML-Tags gehüllt.
Das heißt, der Inhalt ist (bis auf ein paar Kopffelder, die in XML wegfallen, und die eine oder andere Winzigkeit) derselbe, ob FixRecord- oder XML-IDoc.
Aufbau
Der Aufbau von IDocs ist – nun ja, wie sagt man das möglichst vorsichtig? – arg komplex. Daher wollen wir hier gar nicht allzu sehr in die Details gehen. Schauen wir uns einfach mal einen Strukturbaum zu einem ORDERS05, also einem Auftrag an, siehe Darstellung auf der nächsten Seite.
Hier sehen Sie in der linken Grafik den groben Aufbau des IDocs. Die rechte Grafik zeigt den Knoten E2EDP01006 nochmal einzeln, aufgeklappt dargestellt. Dieser Knoten alleine ist komplexer als alles drumherum. Das P steht für die Position, der Knoten und alle seine Unterknoten enthalten Daten zu je einer Position.
Struktur des IDocs ORDERS05, dargestellt in Lobster_data |
Struktur des Knotens EDP01 |
Wir sprechen hier gerade von Knoten, aber das ist natürlich nur die Darstellung in dieser speziellen Software. Im IDoc finden Sie ganz einfach Segmente, also immer schön eine Satzartkennung vorn weg und dann viele Daten.
Das im Detail zu erläutern, ersparen wir Ihnen. Nur ein paar Punkte:
- Jedes IDoc beginnt grundsätzlich mit einem Satz der Satzart EDI_DC40. An dem EDI in dieser Kennung sehen Sie, dass sie für den elektronischen Datenaustausch gedacht sind. So ein EDI_DC40 sieht auch im Aufbau immer gleich aus, egal, welche Art von IDoc man vor sich hat (über Versionen hinweg kann sich dann schon was ändern…). Hier stehen so grundlegende Informationen wie:
- Typ und Version des IDocs (z.B. eben ORDERS05)
- Mandant des SAP-Systems, dem es gehört
- Dokumentennummer
- Message-Typ (dazu später mehr)
- Sender und Empfänger-Informationen
- Datum/Zeitstempel
- usw.
- Ein IDoc-Typ (wie ORDERS) kann mehrere Message-Typen beinhalten. Z.B. kann nicht nur ein Auftrag, sondern auch die Auftragsbestätigung in einem IDoc der Art ORDERS enthalten sein. Das steht dann im Feld für den Message-Typ.
- Jeder Segment-Typ wird innerhalb SAP durch einen Struktur-Datentyp dargestellt, der die Anzahl, Größen, Typen und Namen der Felder in ihrer Reihenfolge definiert. Diese Strukturtypen haben alle einen Namen, der mit E1 beginnt, z.B. E1EDP01. In der Satzartkennung eines Fixrecord-IDocs beginnt der Name der Satzart aber mit E2, also E2EDP01 (fragen Sie nicht, warum…). Wegen der Satzartkennungen heißen die Knoten in obigen Bäumen auch schon so (mit E2 am Anfang). Bei XML-IDocs heißen die Tags dann aber doch wieder E1…, weil sie einen Typnamen darstellen.
- Sowohl die IDoc-Typen (wie ORDERS) als auch die einzelnen Satzarten (wie EDP01) haben eigene Versionen. ORDERS05 ist also Version 5 des ORDERS-IDoc, und EDP01007 ist Version 7 der Satzart EDP01. Wie Sie sehen, fehlt aber zum Beispiel beim EDK14 (erster blauer Knoten im linken Bild) eine Versionsnummer. Hier wird die Grundform genutzt, keine veränderte Version.
- Für FixRecord-IDocs gilt: Jedes Segment beginnt mit einem halben Dutzend Felder, in denen zum Beispiel Mandant und Dokumentennummer stehen. Alle Segmente eines IDocs müssen hier dieselben Werte haben. Außerdem werden Vater/Kind-Beziehungen zwischen Segmenten hergestellt. Aufgrund des hierarchischen Aufbaus der XML-IDocs sind diese Felder dort nicht nötig.
- Bei XML-IDocs ist der Name des Root-Elements identisch zum Message-Typ, es folgen ein oder mehrere Elemente IDoc und darin dann jeweils das eigentliche IDoc, beginnend mit Steuersatz EDI_DC40.
- SAP-Systeme sind oft stark auf die Bedürfnisse des jeweiligen Betreibers zugeschnitten. Auch die Dokumentenarten weichen dann vom Standard, den ein jungfräuliches SAP bietet, ab. Das Ganze nennt sich dann CIM-Typen. Will heißen, dass auch IDocs desselben Typs und der selben Version von SAP-Installation zu SAP-Installation unterschiedlich aussehen können.
Das gesamte IDoc-Format ist mehr oder weniger ein Tabellen-Dump im FixRecord-Format. Da es ursprünglich nur zur direkten Kommunikation zwischen zwei SAP-Systemen gedacht war und nicht, um Dateien in diesem Format durch die Welt (und in Fremdsoftware) zu schicken, ist das auch ganz in Ordnung. Was uns in der täglichen Arbeit allerdings nicht wirklich etwas nützt…
Die XML-Dateien, die ein SAP XI oder PI ausgibt, sind im Standard, abgesehen von der XML-Verpackung, sehr ähnlich aufgebaut wie die FixRecord-IDocs. Satzarten und Felder stimmen praktisch überein, abgesehen von den genannten Kopffeldern. Hier kann natürlich am Ausgabeformat gedreht, also von den Standard-IDocs abgewichen werden. Erfreulich ist aber die Tatsache, dass jedes SAP-System fähig ist, die Formatbeschreibung seiner IDocs auszugeben. Für Fix Record IDocs sind das die sogenannten IDoc Parser Files, für XML-IDocs bekommen Sie ein XML Schema. Beides erhalten Sie in der Transaktion WE60.
Was für Sie wichtig ist
Wenn Sie entweder selbst ein SAP-System besitzen oder Ihre Partner damit drohen, Ihnen IDocs zu schicken bzw. welche von Ihnen haben wollen, sollten Sie auf eine umfassende Integration dieses Dokumententyps bzw. der SAP-Kommunikation achten. Idealerweise kann die Software direkt mit SAP sprechen und die auf genau dieser Installation gültigen Strukturen selbst erfragen (Stichwort CIM-Typen). SAP bietet, wie schon gesagt, auch die Möglichkeit, Beschreibungen seiner Strukturen zu exportieren. Diese sollten entsprechend eingelesen werden können, damit Ihnen auch Ihre Partner direkt die passenden Strukturen zu Ihren IDocs geben können.