SAP IDoc (Intermediate Document) wird von SAP intern verwendet, um z.B. Bestelldaten abzubilden. In der Regel werden IDoc-Daten mittels Message Mapping in andere Formate hin- und herkonvertiert, z.B. in EDIFACT.
Eine generelle Definition von IDoc findet sich z.B. auf www.php-deluxe.de:
Ein IDoc besteht nur aus Textzeichen und besteht aus einem Kontrollsatz, den Datensätzen und Statussätzen.
Der Kontrollsatz besteht aus Sender, Empfänger, Nachrichtentyp und
IDoc-Typ. Der IDoc-Typ beschreibt die Struktur der Datensätze, der
Nachrichtentyp entspricht einem in dem IDoc-Typ definierten, konkreten
Geschäftsvorfall (z.B. Bestellung, Lieferung).In den Datensätzen sind die zu übertragenden Informationen enthalten, der Aufbau entspricht grundsätzlich einer Datenbanktabelle mit einer durch den IDoc-Typ definierten Struktur und den dazugehörigen Datensegmenten.
In den Statussätzen sind im IDoc-Format Verwaltungsinformationen wie
Bearbeitungsbeginn, Übermittlungszeit, Fehlermeldungen und ähnliches
abgelegt.
Prinzipiell können IDocs auch im XML-Format verwendet werden, dennoch ist das „klassische“ IDoc Format immer noch weit verbreitet, nicht zuletzt wegen des geringeren Datenvolumens durch die „schlankere“ Struktur.
Dieses „klassische“ IDoc-Format ist gekennzeichnet durch „feste Satzlängen“, d.h. eine Zeile im IDoc ist genau spezifiziert, was die Position der Datensätze (Offsets) und die „Zeilenlänge“ angeht. So kann z.B. eine Zeile im Dokument (Beispiel aus der „ORDERS05“ Struktur) folgendermaßen definiert sein:
Segment E1EDK01:
Segmentdefinition E2EDK01005
freigegeben seit Release 45B , Segmentlänge : 0357
- ACTION : Aktionscode, der die gesamte
EDI-Nachricht betrifft.interner Datentyp : CHAR
interne Länge : 000003 Stellen
Position in Segment : 001, Offset : 0063. externe Länge : 000003 - KZABS : Kennzeichen für
Auftragsbestätigungspflichtinterner Datentyp : CHAR
interne Länge : 000001 Stellen
Position in Segment : 002, Offset : 0066. externe Länge : 000001 - CURCY : Währunginterner Datentyp : CHAR
interne Länge : 000003 Stellen
Position in Segment : 003, Offset : 0067. externe Länge : 000003 - usw.
Der Parameter „ACTION“ ist also vom Typ „CHAR“, steht in der Zeile, die mit „E1EDK01“ beginnt, an Offset 63 und hat eine Länge von 3 Zeichen, danach kommt der Parameter „KZABS“, dieser steht an Stelle/Offset 66, ist ebenfalls ein „CHAR“ und hat eine Länge von einem Zeichen usw.
Dies würde nun folgendermaßen aussehen:
E1EDK01005 ABC 1
wobei sich rechts ggf. noch weitere Werte anschliessen würden.
Zudem hat jede „Zeile“ im Normalfall eine feste Zeichenlänge, unser Beispiel-Segment muss insgesamt 1063 Zeichen haben – stehen am Ende keine Werte, muss die Zeile mit Leerzeichen „aufgefüllt“ werden.
Für einen „IDoc Writer“ in PHP bräuchte man also vor allem eine Möglichkeit, Zeichenketten von vorgegebener (maximaler) Länge an bestimmte Stellen (Offsets) einer Zeile zu schreiben sowie die Zeile mit Leerzeichen bis zum Ende aufzufüllen. Ist eine Zeichenkette / ein Wert länger als an dem vorgegebenen Offset „Platz“ ist, muss die Zeichenkette gegebenenfalls abgeschnitten werden, um nicht versehentlich den Wert am nächsten Offset zu überschreiben. Zeilen werden im Regelfall nur mit „Line Feed“ beendet (in PHP entspricht dies „\n“):
$idocWriter = new smxIdocWriter();
$idocWriter->write(array("E1EDKA1","AG", "0815", "Stefan Moises", "Some company", "Street 45a"), array(0,63,66,100,135,240), 1063);
$idocWriter->toFile("/tmp/test_idoc.dat");
Ein kleiner Tipp am Rande: werden die IDoc-Dateien nach Erstellung per FTP transportiert, sollten diese im Binär-Modus versendet werden, da FTP im ASCII-Modus die Eigenart hat, am Zeilenende zusätzlich zum „Line Feed“ auch ein „Carriage Return“ (in PHP „\r“) einzufügen – zumindest macht dies der „ftp_put()“ Befehl in PHP, wenn man ihm FTP_ASCII statt FTP_BINARY als Transfer-Typ übergibt).
Viel Spass mit IDoc! 🙂 Hier gibt es eine einfache IDoc-Klasse zum Download: smxIdocWriter.php_.txt.