Datenformate & Nachrichtenstandards

Grundlegendes zu Datenformaten & Nachrichtenstandards

Als Datenformate wollen wir hier die unterste Ebene der Struktur von Dateien verstehen. Letztlich also die Frage, wie die einzelnen Werte in einer Datei dargestellt werden.

Hier gibt es einige Grundtypen von Datenformaten:
CSV: Comma separated values; durch Komma (oder andere Zeichen) getrennte Werte

Feste Länge alias FixRecord: Jeder Wert hat eine exakte Anzahl von Zeichen, somit kann er auch exakt mittels seiner Position innerhalb seiner Datei gefunden werden.

XML: Die Extended markup language, in der den Werten (und auch Gruppen von Werten) eigene Namen (Tags und Attribute) gegeben werden.

Es existieren auch komplexere Abwandlungen davon, z.B. werden die Werte in EDIFACT- und X12-Nachrichten durch mehrere verschiedene Zeichen getrennt, während das im Buchhandel verwendete BWA-Format eine Mischung aus FixRecord und CSV nutzt. Die Trennung der einzelnen Werte ist aber nur ein Teil des Themas. Denn bei jedem etwas komplexeren Format sind die Werte logisch gruppiert, bei CSV und FixRecord nennt man so etwas
dann üblicherweise Satzarten, in EDIFACT oder X12 spricht man von Segmenten (und als nächsthöhere Ordnung von Segmentgruppen oder „Loops“) und bei XML ist es ein
komplexes Element.

Einfache Beispiele

CSV:

AK;4711;K0815;20130530
POS;1;S123;5;9.99
POS;2;H456;3;17.95

FixRecord:

AK 4711    K0815   20130530
POS0001S123    0005000009990
POS0002H456    0003000017950

XML:

<Auftrag>
<Kopf>
<AuftragsNr>4711</AuftragsNr>
<KundenNr>K0815</KundenNr>
<Auftragsdatum>2013-05-30T00:00:00+2</Auftragsdatum>
</Kopf>
<Positionen>
<Position nr="1">
<ArtNr>S123</ArtNr>
<Menge>5</Menge>
<Einzelpreis>9.99</Einzelpreis>
</Position>
<Position nr="2">
<ArtNr>H456</ArtNr>
<Menge>3</Menge>
<Einzelpreis>17.95</Einzelpreis>
</Position>
</Positionen>
</Auftrag>

Drei mal dieselben Informationen, in drei verschiedenen Formaten. Sie sehen schon, der Auftragskopf hat bei CSV und FixRecord die Kennung „AK“, die Position die Kennung „POS“. An irgend etwas muss man ja erkennen, worum es geht. XML ist offensichtlich wesentlich ausführlicher und für Menschen viel leichter zu lesen, dafür braucht es aber auch wesentlich mehr Platz. Mit einem halbwegs brauchbaren Kompressionsalgorithmus ist das allerdings zumindest während der Übertragung kein wirkliches Problem.

Näher beleuchtet werden diese Formate auf  den folgenden Seiten, hier sollen die kleinen Beispiele genügen.

Beispiel für das EDIfact-Format

UNA:+.? '
UNB+UNOC:3+ILN Absender+ILN Empfänger+130230:1025+1++98765'
UNH+1+ORDERS:D:96A:UN'
BGM+220+9'
DTM+4: 20130230:102'
NAD+SU+++Hardwarequelle+Ladenstraße1+Nirgendwo+NRW+54321+DE'
NAD+BY+++Lobster:GmbH+Hindenburgstr.15+Poecking+BAY+82343+DE'
LIN+1++4711:SA'
IMD+++::USB-Stick'
QTY+1:100'
UNS+S'
CNT+2:1'
UNZ+1+98765'

Hier wurden am 30. Februar 2013 von der Firma Lobster (Die Kennung BY steht für den Buyer, also den Käufer) bei der Firma Hardwarequelle (SU = Supplier = Lieferant) 100 USB-Sticks (Artikelnummer 4711) bestellt.
Kleine Anekdote am Rande: In Fulda wurde tatsächlich im Januar 2013 ein Genie festgenommen, das in mehreren gefälschten Ausweisen den 30. Februar als seinen Geburtstag angegeben hatte.

Obiges Beispiel ist eine Bestellung (ORDERS) im EDIFACT-Format der Version D 96 A. Das ist die erste von zwei Versionen, die im Jahre 1996 herausgegeben wurden. Die UNECE als verantwortliche Stelle gibt im Jahr üblicherweise zwei Versionen (A und B) heraus, manchmal auch noch eine dritte (Überraschung: C).

Normalerweise ändert sich nicht jede Nachricht in jeder Version, und sehr oft sind die Änderungen abwärtskompatibel. Von den definierten Nachrichtentypen wird fast alles abgedeckt, was man im elektronischen Datenverkehr so braucht, von AUTHOR (Authorization Message) bis WKGRRE (Work grant request message). Genaueres hierzu im EDIFACT-Kapitel.

Das ENGDAT-Verfahren

Ein Nachrichtenstandard kann bei der Definition komplexerer Datenformate beginnen und bis hin zu genauen Verfahrensvorschriften, z.B. die Übertragungswege betreffend, reichen. Beispiele für einen Standard, der sich auf das Datenformat (will heißen die Definition  bestimmter Nachrichtentypen und deren genauen Aufbau) konzentriert, sind EDIFACT oder BMEcat. Letzteres nutzt wiederum als Datenformat XML.

Hingegen ist ENGDAT ein sehr komplexer Industriestandard, der zwar auch Datenformate beinhaltet, aber daneben auch den Inhalt der Dateien (bzw. der Metadaten, siehe ENGDAT-Artikel) bestimmt und Vorschriften zur Übertragung und sogar zu den Dateinamen macht.

Weitere Nachrichtenstandards

Ähnlich wie EDIFACT, das sein ganz eigenes Format mitbringt (eine kompliziertere Art
von CSV mit mehreren Trennzeichen unterschiedlicher Bedeutung, Sie sehen es ja oben), arbeitet auch X12. Dieser Standard ist eine Art Vorläufer von EDIFACT und wird immer
noch – in erster Linie in Übersee – verwendet. Auch hier werden Unmengen verschiedener Nachrichtenarten definiert.
Fortras und die älteren VDA-Nachrichten dagegen nutzen ein reines FixRecord-Format, wobei die Anzahl der verschiedenen Nachrichten sich allerdings in Grenzen hält.
Näheres zu diesen Standards in den entsprechenden Artikeln.

Fazit:
Sie sehen, eine EDI-Software muss mit ziemlich vielen, verschiedenen Nachrichtenstandards und Datenformaten klarkommen. Je größer die Auswahl ist, desto besser. Auch, wenn
vielleicht im Moment nur einfache CSV-Dateien anstehen, kann sich das schnell ändern, wenn Sie z.B. mit neuen Geschäftspartnern zu tun bekommen. Daher sollte ein EDI-System eine möglichst große Auswahl an Formaten bieten.

Als Beispiel hier die Wahlmöglichkeiten
bei der Datenmanagement-Software
Lobster_data:

Wie schon gesagt, verbergen sich hinter CSV, XML und Feste Länge viele verschiedene Formate und Nachrichtenstandards, die alle auf eines dieser grundlegenden Datenformate setzen. Und ja, Excel wird (leider) auch immer wieder für den Datenaustausch missbraucht. SAP IDOCs sind übrigens in ihrer alten Form auch FixRecord-Dateien, haben aber einen sehr speziellen Aufbau, daher sind sie gesondert aufgeführt. In neuerer Zeit gibt es diese Dokumente auch im XML-Format. Mehr dazu im IDOC-Artikel.

Eine passende Lösung für die Integration der unterschiedlichen Daten-
formate bietet Ihnen Lobster_data (siehe www.lobster.de/lobster_data).