Interaktiver Produktdatenaustausch mit EDIFACT. Holger Aisch, Michael Joosten, Wolfgang Muller, Frank Buijs. Cadlab. Furstenallee 11.

Interaktiver Produktdatenaustausch mit EDIFACT Holger Aisch, Michael Joosten, Wolfgang Muller, Frank Buijs Cadlab Furstenallee 11 33102 Paderborn Zusammenfassung Wahrend der Produktdatenaustausch heute vorwiegend uber geschaltete oder gemietete Punkt-zu-Punkt-Verbindungen wie ISDN oder X.25 mit speziellen Protokollen (z.b. ODETTE) vollzogen wird, stellen wir ein System vor, um die EDIFACT- bzw. VDA- Nachrichten ENGDAT und CONDRA und die in ihnen referenzierten STEP Dateien im Internet interaktiv mittels des World Wide Web Protokolls HTTP auszutauschen. Das System gewahrleistet eine komplette Ubertragung von Geschafts- und den referenzierten Produktdaten, sowie, im Falle von STEP, die Ubertragung der in der STEP-Datei referenzierten Datenspezikation in EXPRESS. Wir stellen ferner einen Ansatz vor, wie die Struktur von EDIFACT-Nachrichten durch EXPRESS-Beschreibungen speziziert werden kann. Das System wird so durch EXPRESS-Datenspezikationen fur individuelle EDIFACT-Nachrichten kongurierbar. Veroentlicht imtagungsband der CAD'96, 7./8. Marz, Kaiserslautern, Springer, Berlin, 1996.

1. Einleitung Der vielerseits etablierte Einsatz elektronischer Medien zum Informationsaustausch fuhrt in jungster Zeit zu verstarktem industriellen Interesse am system- und hardwareunabhangigem elektronischen Austausch von Wirtschaftsdokumenten. So gibt es weltweit im Bereich EDI (Electronic Data Interchange) eine Vielzahl von Aktivitaten, wie z.b. Federal EDI (X12) [FECAT94], Open{EDI [ISO94c], PlantSTEP und die Arbeiten innerhalb des ISO TC184/SC4/WG8 Projektes 1 im Kontext von STEP (STandard for the Exchange of Product Model Data). Eine fuhrende Rolle nimmt hier der weltweit akzeptierte UN/ECE 1 bzw. ISO 9735 Standard EDIFACT 2 [ISO88] ein. EDI wird heutzutage vorwiegend uber geschaltete oder gemietete Punkt-zu-Punkt-Verbindungen, wie ISDN oder X.25, mit speziellen Protokollen (z.b. ODETTE) vollzogen. Eine erhebliche Produktivitatssteigerung erhot man sich, EDI mit Protokollen des Internets durchzufuhren, z.b. mit Hilfe von MIME (Multipurpose Internet Message Exchange) [BF92], was das Thema der EDI Working Group der IETF (Internet Engineering Taskforces) ist. Gerade in letzter Zeit, in der sich das Internet von einem reinen Forschungsnetz zu dem globalen Informationsnetzwerk wandelt, steigt das Interesse, weitere Protokolle des Internets fur geschaftliche Transaktionen zu verwenden. Der Siegeszug des World Wide Webs (WWW) trug u.a. dazu bei, da vor allem fur private Geschafte rasch Methoden entwickelt wurden, um einen sicheren Zahlungsverkehr auf den inharent oenen\, also unsicheren, Protokollen (z.b. TCP/IP, HTTP, FTP, SMTP) zu erlauben. Wahrend sich EDIFACT in den letzten Jahren vorwiegend auf die Denition von Verwaltungs- bzw. Geschaftsdaten konzentrierte, fanden in jungster Zeit Bestrebungen statt, EDIFACT zum Austausch von Produktdaten im Ingenieursbereich zuverwenden. Hierzu denierte die ODETTE WG 11 die ENGDAT-Nachricht [ODETTE92], die aber nicht in den oziellen EDIFACT-Standard ubernommen wurde. Da EDIFACT bis vor kurzem keine vergleichbare Nachricht denierte, fand ENGDAT bis heute im europaischen Bereich groe Verbreitung. Mittlerweile ist aber die EDIFACT CONDRA-Nachricht, die als Alternative zur ENGDAT-Nachricht deniert wurde, als Status 1 (Draft) verfugbar. Wir schlagen in diesem Artikel ein aktuelles Szenario zum modernen, auf dem Internet basierenden Produktdatenaustausch vor. Hierzu skizzieren wir kurz die Grundmechanismen einer auf dem World Wide Web basierten Kommunikation und beschreiben eine generische Architektur zum Produktdatenaustausch, die darauf basiert, da sowohl die Produktdaten als auch die Datenspezikation sowie die Spezikation der Struktur der EDIFACT-Nachricht ubermittelt werden. Dabei werden wir die Vorteile aufzeigen, die die Spezikation von EDIFACT-Nachrichten mit Hilfe der innerhalb von STEP denierten Datenspezikationssprache EXPRESS (ISO 10303-11) [ISO94a] in diesem Umfeld bietet. Dies ist moglich, da der EDIFACT-Standard in vielen Teilen ahnlich dem des innerhalb von STEP denierten STEP Physical File Formats\ (ISO 10303-21) [ISO94b] strukturiert ist, zu dessen Beschreibung EXPRESS innerhalb von STEP Verwendung ndet. Die so spezizierten EDIFACT-Schemata nden in dem vorgestellten System zur automatischen Generierung verschiedener Teilkomponenten Verwendung, was uns eine erste Bestatigung der Modellierungskonzepte im Einsatz von EXPRESS ermoglichte. Ferner diskutieren wir in diesem Artikel den elektronischen Austausch von Produktdaten mittels der ENGDATbzw. der CONDRA Nachrichtunter den oben angefuhrten Aspekten. 1 United Nations/ Economic Commission for Europe 2 Electronic Data Interchange for Administration, Commerce and Transport 2

2.1. HTTP Das World Wide Web ist ein Internet-basiertes Informationssystem zum Austausch von Hypertextdaten. Seine Infrastruktur basiert auf dem Client/Server-Prinzip: Die Daten werden auf Servern bereitgestellt und uber das Internet-Protokoll HTTP (HyperText Transfer Protocol) an anfragende Clients on-line ubermittelt. HTTP steht damit auf der gleichen Ebene wie die bekannten Protokolle der Internet-Welt, z.b. FTP fur den den Dateiaustausch, SMTP fur elektronische Mail und NNTP fur News. Sie alle basieren auf TCP/IP. Das HTTP besteht aus 4 sogenannten Methoden, GET, HEAD, PUT und POST, von denen die erste uber 99% aller Operationen ausmacht. Die Argumente dieser Operationen sind netzwerkweit eindeutige Bezeichner fur Dateien, die sog. URLs (Universal Resource Locators): HTTP://www.premenos.com/unedifact/table.html?UNTDID Ein URL enthalt neben der Angabe der Internetadresse des Servers und einem lokal zu interpretierenden Pfad die Methode des Zugris, also das Protokoll. So sind neben HTTP Zugrie uber andere Protokolle (FTP, News, etc.) moglich, was aber nichtvon allen Clients, den sog. WWW-Browsern, wie Mosaic oder Netscape, unterstutzt wird. HTTP bietet im Vergleich zu den bisherigen Protokollen fur den Datenaustausch Erweiterungen an, die gerade den Transport von multimedialen Daten erleichtern. Diese Erweiterungen sind dem MIME-Protokoll [BF92] entnommen, das neben der expliziten Identizierung des Dateiformates mehrere Dateien zusammenbinden kann und bei Binardaten, wie Bitmap-Bildern, eine standardisierte Kodierung fur die Ubertragung uber eingeschrankte Kanale (z.b. EBCDIC, ASCII) bereitstellt. Ferner erlaubt HTTP die Adaption von HTTP-Servern an die Darstellungsmoglichkeiten von Browsern, indem eine sog. Content Negotiation\ durchgefuhrt werden kann. So kann ein Server, wenn ein Bild im JPEG-Format durch einen Browser nicht darstellbar ist, dieses in ein akzeptables Format wie GIF umwandeln und dann erst dem Browser schicken. Eine weitere wichtige Eigenschaft ist es, uber Attribute den Zeitpunkt der letzten Modikation oder gar der Ungultigkeit des gesendeten Dokuments anzugeben. Fur jede Operation wird eine TCP/IP-Verbindung aufgebaut und nach Empfang der Antwort, die einen Statuscode enthalt, wieder abgebaut. Das folgende Beispiel skizziert eine erfolgreiche Antwort: HTTP/1.0 200 OK Date: Friday, 18 Aug 95, 15:43:25, GMT Server: NCSA/1.3 MIME-Version: 1.0 Content-Type: text/html Last-Modified: Monday, 10 Jul 95, 12:35:42, GMT Content-Length: 1620 Der Kopf speziziert die Protokoll-, Server- und MIME-Version. Ferner werden dem Empfanger Ubertragungszeitpunkt, Art der Datei (Content-Type), Lange der Datei (Content-Length), sowie das Datum der letzten Modikation der Datei zuruckgeliefert. In der ersten Zeile bendet sich auerdem der Statuscode, wobei Codes, die mit der Zier 2 beginnen, fur eine positive Quittung stehen. Der Kopf wird beim Empfang vom Client entfernt, der dann Aktionen je nach erkanntem Content-Type ausfuhrt und z.b. den Inhalt anzeigt oder an externe Werkzeuge weitergibt. Fur EDIFACT Ubertragungen wurde hier bereits der Content-Type Application/EDIFACT reserviert. Die Methode HEAD liefert nur diesen Kopfteil und kann damit zur Aktualisierung von Daten durch Polling eingesetzt werden (aufgrund von Last-Modified: oder Expires:). Mit PUT und POST sind Methoden gegeben, um Daten auf den Server zu ubertragen. 3

Dieser einfache Mechanismus erlaubt es auch Programme auf der Serverseite zu starten. Eine Interaktion mit dem Server ist hier jederzeit moglich, da deren Ausgabe (Standardausgabe) automatisch an den Client zuruckubertragen wird. Damit konnen sog. dynamische Skripte implementiert werden, die die Moglichkeiten von HTML 2.0, Eingabemasken bzw. Formulare zu spezizieren, perfekt erganzen und in unserer Implementierung daher genutzt werden. Wie hier zu sehen ist, bietet sich das HTTP wegen seines einfachen Aufbaus zum interaktiven Produktdatenaustausch an. Durch die erwahnten Formulare und den Aufruf von Programmen auf der Seite der Server wird bereits ein Groteil der notigen Funktionalitat abgedeckt. Welche Erweiterungen zur weiteren Automatisierung notwendig sind, wird im folgenden vorgestellt. 2.2. Systemarchitektur Im Kontext des HTTP stellen wir eine Architektur eines generischen Systems vor, um den Austausch von EDIFACT-Nachrichten im Internet mittels der wohlbekannten Konzepte des WWWs hinsichtlich mehrerer Aspekte zu automatisieren. Das hier vorgestellte System lost im wesentlichen die folgenden zwei Problemstellungen. a. Automatische Beschaung von referenzierten Dateien b. Adaptierbarkeit auf alle existierenden und zukunftigen EDIFACT-Standards und auf EDIFACT-orientierte Formate Im Kontext der Ubertragung von Produktdaten tritt das Problem der Referenzauosung an mehreren Stellen auf. Zum einen konnen ENGDAT- und CONDRA-Nachrichten (siehe nachstes Kapitel) Referenzen auf eine STEP-Datei [ISO94b] beinhalten. Zum anderen enthaltet jede STEP-Datei eine Referenz auf eine EXPRESS-Datei, die sie zur Interpretation benotigt. Daher haben wir ein ETP (EDIFACT Transport Protocol) deniert. ETP ist ein auf EDIFACT angepasstes und um die Funktionalitat der Referenzauosung erweitertes HTTP. Referenzauosung im Kontext von ETP heit hier, da die Ubertragung einer referenzierten Datei automatisch veranlat wird, falls diese beim Empfanger noch nicht vorliegt. Diese Automatisierung garantiert die Vollstandigkeit der Nachricht und spart fehleranfallige, zeitraubende Handarbeit. Bei der Ubertragung von Produktdaten tritt das Problem der Referenzauosung an mehreren Stellen auf. Zum einen konnen ENGDAT- und CONDRA-Nachrichten Referenzen auf eine STEP-Datei [ISO94b] beinhalten. Zum anderen enthaltet jede STEP-Datei eine Referenz auf eine EXPRESS-Datei, die sie zur Interpretation benotigt. Um das System fur alle existierenden und zukunftigen EDIFACT-Standardnachrichten und EDIFACT-orientierte Nachrichten anzupassen, wurden die Komponenten unseres Systems in wesentlichen Teilen kongurierbar gestaltet. Die Kongurierbarkeit wird durch die Beschreibung von EDIFACT-Nachrichten durch EXPRESS-Spezikationen (EDIFA- CT-Schemata) erreicht. Die ISO 10303-11 Datenspezikationssprache EXPRESS [ISO94a] wird hier zur Spezikation der Struktur und der Basiselemente von EDIFACT-Nachrichten herangezogen, worauf im nachsten Kapitel noch naher eingegangen wird. Eine Systemkomponente interpretiert den Eingabestrom anhand der gegebenen EXPRESS-Spezikation der individuellen EDIFACT-Nachricht. Abbildung 1 skizziert die Gesamtarchitektur des Systems. 4

EDIFACT-SCHEMA HOST EDIFACT-SCHEMA WWW Client TCP HTTP POST +Daten EDIFACT Gateway ETP Internet Dateisystem ETP Receiver EDIFACT Server EDIFACT-SCHEMA Konverter EDIFACT-SCHEMA SDAI DB Dateisystem DB Abbildung 1: EDIFACT basierter Produktdatenaustausch im Internet Den eigentlichen Kern des Systems bilden ein EDIFACT-Gateway und ein EDIFACT- Server. Das Gateway konvertiert unternehmensinterne Formate in die gewunschten EDI- FACT-Nachrichten. Die entsprechende Nachricht wird dann uber ETP an den in der Nachricht spezizierten Empfanger versandt. Es ist sinnvoll, alle EDI-Kommunikationen eines Unternehmens uber ein EDIFACT-Gateway abzuwickeln, um u.a. die Kontrolle und die Protokollierung zu zentralisieren. Die Internet-Adresse der Empfanger wird anhand der Adreangaben in der EDIFACT-Nachricht mit Hilfe eine Umsetztabelle bestimmt. Zu jedem Empfanger wird uber das ETP-Protokoll eine (sichere) TCP-Verbindung aufgebaut, die solange bestehen bleibt, bis eine Bestatigung der Vollstandigkeit des Datenaustausches oder aber eine Fehlermeldung empfangen wird. Auf der Empfangerseite bendet sich ein EDIFACT-Server, der den Datenstrom empfangt und weiterverarbeitet. Der EDIFACT-Server wird im Prinzip durch einen HTTP-Server mit erweiterter Funktionalitat dargestellt. Das System ist, wie bereits erwahnt, hinsichtlich der verschiedenen EDIFACT-Nachrichten voll kongurierbar. Zur Konsistenzprufung bei der Konvertierung der unternehmensinternen Daten in EDIFACT-Nachrichten benotigt das Gateway ein EDIFACT-Schema, welches als EXPRESS-Spezikation [ISO94a] deniert ist. Die Werkzeuge auf der Empfangerseite benutzten die gleiche EXPRESS-Spezikation zur Dekodierung und Weiterverarbeitung der Nachricht. Dies ermoglicht auf Empfangerseite u.a. auch ein Einbringen der Nachricht mittels SDAI (STEP Data Acess Interface { ISO 10303-22) in eine Datenbank. Die in EDIFACT enthaltenen Nutzdaten konnen so, ohne eine weitere Interpretation vornehmen zu mussen, direkt durch SDAI-Aufrufe weiterverarbeitet werden. Fur diese Konvertierung und zur Generierung der individuellen SDAI Funktionen benotigt der Empfanger das gleiche EDIFACT-Schema wie der Absender. Die Ubertragung dieses Schemas wird durch das ETP gewahrleistet. 5

Abbildung 2: HTML-Formular vor und nach der Expandierung Das EDIFACT-Gateway verhalt sich an der Schnittstelle zum WWW-Client wie ein HTTP-Server. Dies ermoglicht die Verwendung von Standard WWW-Clients wie Mosaic oder Netscape als Benutzungsoberache. So konnen die Daten, wie Kunden-Nr., Dateireferenzen, etc., in HTML-Formulare, die aus dem gegebenen EDIFACT-Schema automatisch generiert werden konnen, eingegeben werden. Da eine EDIFACT-Nachricht viele optionale Felder enthalten kann, die bei einer individuellen Ubertragung nicht alle benotigt werden, besteht die Moglichkeit einer individuellen Kongurierung eines Formulars in einem Zwischenschritt. D.h., da in einem vorlaugen Formular nur die vorgeschriebenen (mandatory) Felder vollstandig sichtbar sind und man eine Moglichkeit hat, aus den optionalen Feldern eine Auswahl durch Anwahlen eines Schalters (remove/expand) zu treen. Das vorlauge Formular wird dann in einem Zwischenschritt um die angewahlten Felder expandiert und um die nicht angewahlten Felder verkurzt. Abbildung 2 zeigt das aus einer EXPRESS Spezikation automatisch generierte Formular zur Eingabe einer ENGDAT-Nachrichtvor und nach der Expandierung. Weite Teile des vorgestellten Systems wurden unter NCSA/1.3 mit HTTP/ V1.0 unter C auf SunOS 4.1 implementiert und sind demonstrationsfertig. Die Implementierung umfat das skizzierte ETP (EDIFACT Transport Protocol), das vollstandige System auf Seiten des Senders inklusive dem HTML-Generator fur EXPRESS-Spezikationen und das EDIFACT-Gateway. Auf Empfangerseite wurde bis jetzt der EDIFACT-Server implementiert. Da die EDIFACT-Schemata in dem System eine zentrale Rolle einnehmen, wird im verbleibenden Artikel EDIFACT und die Spezikation von EDIFACT-Nachrichten mittels der Datenspezikationssprache EXPRESS detailliert erlautern. 3. EDIFACT Bevor auf die eigentliche Modellierung eingegangen werden kann, wird ein kurzer Uberblick uber EDIFACT und dessen Struktur gegeben. Der EDIFACT-Standard besteht aus einer Reihe von EDI-Standards, die von der UN/ECE im UNTDID (UN/Trade Data 6

Interchange Directory [UN95a]) aufgefuhrt sind. Beispiele sind Regeln fur die Erstellung von neuen Standard-Nachrichten, Verzeichnisse von standardisierten Nachrichten (UN/EDIFACT Standard Message Directory), Codes (UN/EDIFACT Code List) und Elementen (UN/EDIFACT Data Element Directory). Zum besseren Verstandnis der Standard Nachrichten und der nachfolgenden EXPRESS- Modellierung, mu hier zunachst auf den syntaktischen Aufbau von EDIFACT Nachrichten eingegangen werden, welcher in Teil 4 des UNTDID zu nden ist. 3.1. EDIFACT Syntax Eine EDIFACT-Nachricht ist eine Folge von Service- und Datensegmenten. Servicesegmente enthalten Strukturinformationen, Kontrollinformationen, sowie Zusatzinformationen zur Beschreibung des Senders, des Empfangers und der Nachricht selbst. Datensegmente beeinhalten die eigentlichen Daten. Es werden bzgl. ihres Auftretens optionale (conditional) und notwendige (mandatory) Segmente unterschieden. Segmente werden durch den Segmentseparator ['] getrennt. Die generelle Struktur einer EDIFACT- Nachricht lat sich inerweiterter Backus-Naur Form (EBNF) folgendermaen darstellen. edifact_msg ::= [una] unb ''' ( functiongrps messages ) unz '''. functiongrps ::= functiongrp { functiongrp }. functiongrp ::= ung ''' messages une '''. messages ::= message {message}. message ::= unh ''' segments unt '''. segments ::= segment ''' { segment ''' }. Jedes Segment bis auf una ist durch das Segment-Separator-Zeichen ['] abgeschlossen. Eine Nachricht beginnt optional mit dem Servicesegment una (Service String Advice). Hier konnen die einzelnen vordenierten Trennzeichen umdeniert werden. Hierauf folgt das notwendige Service-Segment unb (Interchange Header), was Informationen uber Sender und Empfanger, wie Identikation, Adresse oder Passworter enthalten kann. Hiernach folgen entweder die eigentlichen Nachrichten (Messages) oder eine Reihe von Funktionsgruppen (Functional Groups), die wiederum mehrere Nachrichten enthalten konnen. Funktionsgruppen bilden die Moglichkeit, Nachrichten semantisch zu gruppieren. Abgeschlossen wird der gesamte Datenaustausch mit unz (Interchange Trailer). Das Segment ung (Functional Group Header) enthalt genauere Information des Empfangers (Abteilung innerhalb eines Unternehmens o.a.). Eine Funktionsgruppe wird durch une (Functional Group Trailer) abgeschlossen. Die eigentliche Nachricht beginnt mit unh (Message Header) und wird mit dem Servicesegment unt (Message Trailer) abgeschlossen. In unh wird zum Beispiel der Nachrichtentyp 3 beschrieben. Das unt Segment enthalt Kontrollinformationen, wie z.b. die Anzahl der in der Nachricht vorkommenden Segmente. Die Syntax eines einzelnen Segments kann in EBNF wie folgt beschrieben werden. segment ::= tag '+' [ element ] {'+' [ element ]}. tag ::= code {':' VALUE}. code ::= a3. element ::= simple_element composite_element. simple_element ::= VALUE. composite_element ::= [ component_element ] {':' [ component_element ]}. component_element ::= VALUE. VALUE steht hier fur eine beliebig lange Folge von beliebigen Zeichen aus dem zugrundeliegenden Zeichensatz. Einschrankungen der Lange und des Typs werden in EDIFACT im Bezeichner kodiert. a3 steht in der obigen Spezikation fur ein Wort mit genau drei 3 Jeder Nachrichtentyp hat eine eindeutige, 6-stellige Kennung, z.b. Rechnung mit INVOIC. 7

Buchstaben (Alpha-Zeichen). Die Kurzel an und n stehen fur alphanumerische bzw. numerische Zeichenfolgen. Variable Obergrenzen werden mit [ ] dargestellt. So speziziert z.b. a 3 eine Zeichenkette mit bis zu 3 Buchstaben. Ein Segment beginnt mit einem sogenannten Tag, das durch eine eindeutige, dreistellige Kennung, den Code, bestimmt ist. Es folgt eine Reihe von durch [+] (data element separator) getrennte Felder, die entweder ein einfaches Datenelement (simple data element) oder ein zusammengesetztes Datenelement (composite data element) enthalten, welches wiederum aus mehreren durch [:] (component data element separator) getrennten Datenelementen (component data element) besteht. Die Datenelemente (element) und Komponenten (component element) sind optional. Da aber ein Element ausschlielich anhand der Position innerhalb des Segmentes bzw. eines zusammengesetzten Elementes identiziert wird, mussen alle Trennzeichen vollstandig angeben werden 4. Bei den einfachen Datenelementen unterscheidet man die Codes, deren Inhalt im Standard genau festgelegt ist, und die konventionellen Elemente, die beliebige Werte enthalten konnen. Eine Folge von Segmenten kann logisch zu einer Segmentgruppe zusammengefat werden, die wiederum Segmentgruppen enthalten kann. Durch eine Segmentgruppe kann man eine zusammenhangende Folge von logisch abhangigen Segmenten bzw. wiederum ganze Segmentgruppen wiederholbar machen. Man kann fur jedes Segment explizit die Wiederholung innerhalb der Nachricht und Segmentgruppe angeben. Dies wird durch die Werte, die direkt auf den Segment-Code folgen, speziziert, was das folgende Beispiel veranschaulichen soll: DTM:2:3+009+950204. Der Segment-Code DTM steht fur Date/Time/Period. Die ersten beiden Komponenten zeigen die Schachtelung des Segments an. Es ist also das 3. DTM-Segment in der 2. Wiederholung der aktuellen Segmentgruppe. Das erste einfache Datenelement ist ein Code. 009 steht fur Processing date/time\. Es wird hier das Erzeugungsdatum 4.2.1995 ubermittelt. Manche EDIFACT-Standardnachrichten unterteilen die Segmentfolgen logisch in Sektionen, worauf hier aber nicht naher eingegangen werden soll. 3.3. EDIFACT Standard Nachrichten Fur die Spezikation einer EDIFACT Standard Nachricht wurde im ISO Standard [ISO88] eine Diagrammschreibweise eingefuhrt, welche die Reihenfolge aller Segmente und Segmentgruppen inklusive Nebenbedingungen festgelegt. Ein Diagramm besteht aus einer Sequenz von Blocken, die von links nach rechts bzw. von oben nach unten zu interpretieren ist. Ein Block speziziert entweder ein einzelnes Segment oder eine Segmentgruppe. Im Block werden Status (optional/notwendig) und die maximale Wiederholungsrate speziziert. Siehe hierzu das Diagramm der Invoice-Nachricht in Abbildung 3. Jeder Block steht auf einer bestimmtenschachtelungstiefe (Level) bzgl. der logischen Struktur in dem Nachrichtendiagramm. Blocke der Tiefe 0 durfen nicht wiederholt werden. Alle Segmente, die mehr als einmal auftreten durfen liegen also auf einer Tiefe 1. Ein Segment identiziert sich durch seinen Code. Das erste Segment innerhalb einer Gruppe wird als Trigger-Segment bezeichnet. Die Gruppe wird anhand dieses Segments identiziert. 4 Man beachte hier die Korrespondenz zu der Struktur des ISO 10303-21 STEP Physical File Formats. 8

Level 0 1 UNH BGM PAI IMD M 1 M 1 C 1 C 1 DTM ALI FTX RFF M 35 C 5 C 5 NAD M 1 M 1 2 Segmentcode oder Segmentgruppe DTM C 5 LOC FII C 25 C 5 M = Mandatory C = Conditional Anzahl der max. Wiederholungen C 10 C 20 Segment Group 1 Segment Group 2 Abbildung 3: Ausschnitt aus einem Diagramm der INVOIC-Nachricht Alle Standard-Nachrichten sind im UNTDID als informelle textuelle Spezikation abgelegt. Bedauerlicherweise wird von der UN/ECE bzw. ISO bisher keine formale Grundlage zur Spezikation einer EDIFACT-Nachricht zur Verfugung gestellt, obwohl es schon seit langerem Bestrebungen dazu gibt. Wie wir im nachsten Kapitel demonstrieren, bietet die ISO Datenspezikationssprachen EXPRESS eine ideale Grundlage fur solch eine vollstandig formale Denition. 4. EXPRESS zur Spezikation von EDIFACT Da wir hier nicht unbedingt Kenntnisse der ISO-Datenspezikationssprache EXPRESS voraussetzen konnen, sei ein kurzer Uberblick uber die textuelle Auspragung der Sprache der Spezikation von EDIFACT-Nachrichten vorangestellt. Fur eine Einfuhrung in EXPRESS sei an dieser Stelle an die Originalliteratur verwiesen [ISO94a]. 4.1. EXPRESS Die Datenspezikationssprache EXPRESS liegt seit Ende 1994 als internationaler Standard ISO 10303-11 vor [ISO94a]. Eine EXPRESS Spezikation besteht aus einer oder mehreren Schemaspezikationen. Eine Schemaspezikation stellt einen Gultigkeitsbereich fur die Deklaration von Datentypen dar. Ein Datentyp ist entweder ein Basistyp (NUMBER, REAL, INTEGER, BINARY, BOOLEAN, LOGICAL, STRING), ein Aufzahlungstyp, ein Selektionstyp, ein benutzerdenierter Typ oder ein Entitytyp. Eine Entitytypdenition umfat die Denition einer Menge von Attributen. Attribute konnen als OPTIONAL deniert werden, was bedeutet, da der Attributwert nicht vorhanden sein mu. Relationen werden in EXPRESS als Attribute vom Typ eines Entitytyps dargestellt. Zur Attributdenition stehen in EXPRESS vier verschiedene Aggregationstypen zur Verfugung: BAG, SET, ARRAY, LIST. Kardinalitatsbeschrankungen werden durch die untere und obere Grenze einer Aggregation angegeben. Attribute konnen durch sogenannte DERIVE Spezikationen funktional abhangig von anderen Attributen deniert werden. Einzelne Attribute bzw. Attributtupel konnen innerhalb eines Entitytyps als UNIQUE speziert werden. Dieses bedeutet, da ein Wert eines Attributs bzw. eines Attributtupels nur einmal innerhalb aller Instanzen eines Entitytyps auftreten darf. 9

Als Besonderheit gegenuber anderen Datenspezikationssprachen kann zum einen die SUPER/SUB-Typ Relation zwischen Entitytypen und zum anderen die Spezikation von lokalen (Bereichsregeln) und globalen Regeln gesehen werden. Bei der Denition einer SUPER/SUB-Typ Relation werden alle Attribute und Regeln des Supertyps an den Subtyp vererbt. Die SUPER/SUB-Typ Relationen konnen zusatzlich mit Einschrankungen bzgl. der Komposition von Entitytypen versehen werden: ONEOF, AND, ANDOR. Auf Basistypen konnen einfache Einschrankungen bzgl. Prazision, Lange, usw. speziziert werden. So deniert z.b. a : STRING (3) FIXED\ ein Attribut a als Zeichenkette mit der konstanten Lange 3. Lokale Regeln denieren weitere Einschrankungen auf dem Wertebereich bzw. den Attributen des jeweiligen Typs. Globale Regeln spezizieren Konsistenzbedingungen zwischen allen Instanzen eines oder mehrerer Entitytypen. 4.2. Das EDIFACT-Schema Wie in Kapitel 3. beschrieben, besteht eine EDIFACT-Nachricht aus einer Folge von Segmenten bzw. Segmentgruppen. Eine Segmentgruppe kann ebenfalls Segmente oder Segmentgruppen enthalten. Ein Segment besteht aus einer Folge von einfachen oder zusammengesetzten Elementen, welche wieder aus einfachen Elementen bestehen. Elemente konnen im Standard denierte Codes bzw. Wertfelder mit gewissen Einschrankungen darstellen. Zusatzlichwerden zu den Segmenten, Segmentgruppen, zusammengesetzten oder einfachen Datenelementen der Status angegeben, also notwendig (mandatory) oder optional (conditional). Dieser Status ist aber kontextabhangig, d.h., da zum Beispiel das Segment DTM nicht bei jedem Auftreten den Status M haben mu. Zu jedem der EDIFACT-Strukturelemente wird eine Entitydenition in einem Meta- Schema Globals zur Verfugung gestellt. Der Supertyp enthalt gemeinsame Meta-Attribute 5. Hinzu kommen Hilfsfunktionen, die der lexikalischen Einschrankung von einfachen Datenelementen dienen. Das globale Schema ist im folgenden skizziert. SCHEMA Globals; TYPE SECTIONTYPE = ENUMERATION OF (header,detail,summary); END_TYPE; ENTITY MESSAGE; Id : STRING(6); ENTITY SECTION; Which : SECTIONTYPE; ENTITY SEGMENT; Code : STRING(3) FIXED; ENTITY GROUP; No : INTEGER; ENTITY COMPOSITE; Ref : STRING; ENTITY ELEMENT; Ref : STRING; ENTITY CODE; Ref : STRING; FUNCTION IS_NUMERICAL(s : STRING) : BOOLEAN; END_FUNCTION; FUNCTION IS_ALPHA(s : STRING) : BOOLEAN; END_FUNCTION; END_SCHEMA; Fur die Klassen der Segmente, Codes, zusammengesetzten und einfachen Elemente wird analog zu den Verzeichnissen des UNTDID ein separates Schema erzeugt, in dem die Strukturelemente der jeweiligen Klasse deniert werden. Jede Standardnachricht wird in einem separaten Schema deniert. Ein individuelles Strukturelement wird als Subtyp des Entities der zugehorigen Klasse deniert, welche aus dem globalen Schema referenziert wird. Zum Beispiel wird ein individuelles Segment als Subtyp von SEGMENT deniert. Die Bezeichner der Strukturelemente werden vom EDIFACT Standard direkt ubernommen. 5 Aus Platzgrunden werden in diesem Artikel nur die wichtigsten erwahnt. 10

Der Status C (=conditional) eines Strukturelementes wird durch eine optionale Denition des entsprechenden Attributs abgebildet. Sind Wiederholungen eines Elements erlaubt, so wird das durch eine Liste der entsprechenden Lange realisiert. Ist eine Wiederholung eines optionalen Elementes moglich, so wird das durch OPTIONAL LIST[1:] speziziert. Zusammengesetzte Elemente und einfache Datenelemente haben dann folgende Form: SCHEMA Composites; REFERENCE FROM Globals; REFERENCE FROM Elements; REFERENCE FROM Codes; ENTITY COMP082 SUBTYPE OF (COMPOSITE); De1 : CODE3039; De2 : OPTIONAL LIST[1:3] OF CODE1131; De3 : OPTIONAL LIST[1:3] OF CODE3055; WHERE Ref = 'C082'; END_SCHEMA; SCHEMA Elements; REFERENCE FROM Global; ENTITY ELEM6066 SUBTYPE OF (ELEMENT); Elem : STRING(18); WHERE IS_NUMERICAL(Elem); Ref = 'EDED6066'; END_SCHEMA; Bei dem Element 6066 handelt es sich allgemein um einen Kontrollwert, der zum Beispiel fur die Summenbildung bei einer Rechnung verwendet wird. Das Element beinhaltet einen reinen Zahlenwert, was durch die Einschrankung IS NUMERICAL speziziert wird. Datenelemente mit fester Lange werden als FIXED-String deniert. Das Attribut Ref, das vom Supertyp ELEMENT vererbt wird, wird auf die im EDIFACT-Standard angegebene Referenz gesetzt. Segmente werden in einem Schema zusammengefat und sind wie folgt deniert: SCHEMA Segments; REFERENCE FROM Globals; REFERENCE FROM Elements; REFERENCE FROM Codes; REFERENCE FROM Composites; ENTITY BGM SUBTYPE OF (SEGMENT); De1 : OPTIONAL COMP002; De2 : OPTIONAL ELEM1004; De3 : OPTIONAL CODE1225; De4 : OPTIONAL CODE4343; WHERE Code = 'BGM'; END_SCHEMA; Bei der obigen Spezikation handelt es sich um ein Segment, das in der INVOIC-Nachricht Verwendung ndet (siehe hierzu Abbildung 3). Man beachte bei der Spezikation des Segments, da der Code BGM als Einschrankung des vom Supertyps vererbten Attributes Code deniert wird. Eine EXPRESS-Spezikation einer EDIFACT-Nachricht soll schlielich anhand der IN- VOIC-Nachricht (Rechnung), welche bereits in Kapitel 3.3. in Diagrammschreibweise eingefuhrt wurde, aufgezeigt werden. Das Diagramm in Abbildung 3 zeigt hier die Denition der Header Section\ der INVOIC-Nachricht. Diese Nachricht wird vom Standard entsprechend der Gliederung einer Rechnung logisch in drei Sektionen unterteilt: Header-, Detail- und Summary-Section. Diese Aufteilung wird 1:1 in die EXPRESS-Spezikation ubernommen. Fur die Denition der Sektionen kann dann das Diagramm von links nach rechts sequentiell in EXPRESS-Text ubertragen werden, wobei die Hierarchie des Dia- 11

gramms in eine Entitystrukturierung abgebildet wird, wie im folgenden zu sehen ist. SCHEMA Invoic; REFERENCE FROM Globals; REFERENCE FROM Segments; ENTITY INVOIC SUBTYPE OF (MESSAGE); Una : OPTIONAL UNA; Unb : UNB; Header : HEADER_SECTION; Detail : DETAIL_SECTION; Summary : SUMMARY_SECTION; Unz : UNZ; WHERE Id = 'INVOIC'; ENTITY HEADER_SECTION SUBTYPE OF (SECTION); Seg1 : UNH; Seg2 : BGM; Seg3 : LIST[1:35] OF DTM; Seg7 : OPTIONAL LIST[1:10] OF FTX; SegGroup1 : OPTIONAL LIST[1:10] OF SEGGROUP1; SegGroup2 : OPTIONAL LIST[1:20] OF SEGGROUP2; WHERE Which = header; ENTITY SEGGROUP2 SUBTYPE OF (GROUP); Seg1 : NAD; Seg2 : OPTIONAL LIST[1:25] OF LOC; Seg3 : OPTIONAL LIST[1:5] OF FII; END_SCHEMA; Man beachte bei den Denitionen der Entities, da sich deren Semantik aus dem verwendeten Supertyp im Meta-Schema und aus den lokalen Einschrankungen ableiten lassen. So braucht keine Interpretation bei der maschinellen Verarbeitung der EXPRESS Spezi- kation aus dem Bezeichner des Enitities vorgenommen zu werden. Im obigen Beispiel wird das Entity INVOIC durch seine Supertyprelation zu MESSAGE als Nachricht und durch das Setzen des Attributes Id als INVOIC identiziert. Beides zusammen identiziert das Entity als INVOIC-Nachricht. 5. Produktdatenaustausch mit EDIFACT Im Kontext von EDIFACT gibt es zwei Nachrichten, die z.zt. als Rahmen fur die Ubertragung von CAD Produktdaten zur Verfugung stehen. Zum einen gibt es die vom VDA 6 ubernommene ENGDAT-Nachricht, die von der ODETTE WG 11 [ODETTE92] entwickelt wurde. Sie wurde bis jetzt von der UN/ECE jedoch als Standard-Nachricht nicht akzeptiert. ENGDAT ndet dennoch besonders in der europaischen Automobilindustrie weite Verbreitung, da es bis jetzt keine vergleichbare Status 2 Nachricht 7 der UN gibt. In jungster Zeit erlangte jedoch die mit ENGDAT vergleichbare CONDRA Nachricht den Status 1 (Draft) und wird wohl in naher Zukunft als UN/EDIFACT-Standardnachricht vorliegen. Beide Nachrichten beschreiben einen qualitativen Transfer von Dateien, d.h., da nur Referenzen auf Datenbestande ubertragen werden. Wie die referenzierten Daten schlielich den Empfanger erreichen ist im EDIFACT- bzw. VDA-Standard nicht vorgeschrieben. Beide Nachrichten ubertragen zur Referenz auf eine Datei allgemeine Daten, wie z.b. Absender, Empfanger, sowie Werkzeug, Datum der Erzeugung. Die wesentlichen Teile des Schemas der ENGDAT-Nachricht stellen sich dann analog zum vorherigen Kapitel wie folgt dar: 6 Verband Deutscher Automobilhersteller 7 Status 2 : Ozielle Empfehlung als UN-Standard Nachricht akzeptiert zu werden. 12

SCHEMA Engdat; REFERENCE FROM Globals; REFERENCE FROM Segments; ENTITY ENGDAT SUBTYPE OF (MESSAGE); Una : OPTIONAL UNA; Unb : UNB; Seg1 : UNH; Seg2 : MID; Seg3 : SDE; Seg4 : RDE; Seg5 : OPTIONAL LIST[1:?] OF DAN; Seg6 : OPTIONAL LIST[1:?] OF FTX; SegGroup1 : LIST[1:?] OF SEGGROUP1; Seg7 : TOT; Seg8 : UNT; Unz : UNZ; WHERE Id = 'ENGDAT'; ENTITY SEGGROUP1 SUBTYPE OF (GROUP); Seg1 : LIST[1:?] OF EFC; Seg2 : OPTIONAL LIST[1:?] OF FTX; SegGroup2 : OPTIONAL LIST[1:?] OF SEGGROUP2; Seg3 : OPTIONAL LIST[1:?] OF LOF; Seg4 : OPTIONAL SEC; ENTITY SEGGROUP2 SUBTYPE OF (GROUP); Seg1 : DSD; Seg2 : OPTIONAL LIST[1:?] OF FTX; ENGDAT Beispiel: UNB +UNOA:2 +abc.koeln.de +920227:1354 +920227135401ABKLN++++++1' UNH +920227135401ABKLN +ENGDAT:1:0:OD' MID +920227135401ABKLN:920227' SDE ++Firma ABC:Hahn Str 10:5000 Koeln ++Abt. DEF:Hr. Maier:0211/88-0:345 +Firma ABC ++Abt. UEB:3369' RDE ++Firma X:Postf. 88:8000 Paderborn ++Abt. VW:Hr. Mueller:089/45:4499' EFC +2:992647001.g +IGE:4.0 +646 +Intergraph EMS:2.4.1 +Einbaumuntersuchung +3D-Flaechenmodell' FTX +Kombi-Instrument fuer E-XY' TOT +2' UNT +7 +920227135401ABKLN' UNZ +1 +920227135401ABKLN' END_SCHEMA; Zur Erlauterung der ENGDAT-Nachricht haben wir ein kleines Beispiel aus [ODETTE92] beigefugt. In diesem Beispiel ist zu beachten, da in einer EDIFACT-Nachricht keine Trennzeichen, wie Zeilenendezeichen, erlaubt sind. Die Formatierung des Beispiels haben wir hier lediglich zur besseren Ubersichtlichkeit eingefugt. Auallig bei der ENGDAT-Nachricht ist, da es im Gegensatz zu EDIFACT-Nachrichten Segmente gibt, die beliebig oft wiederholt werden durfen. Die Dateireferenz wird in ENG- DAT im Element File Name des Segments EFC (Engineering File Characteristics) ubertragen. Dieses Element darf hochstens 3-mal auftreten und ist jeweils durch 35 Zeichen beschrankt. Da im Kontext unserer WWW Anwendung URLs als Dateinamen ubermittelt werden mussen, bildet die Begrenzung auf 3 x 35 Zeichen eine erhebliche Einschrankung, die leicht uberschritten werden kann. Falls man hier einen URL mit einer Zeichenlange 106 ENGDAT-konform ubertragen will, musste man den URL auf mehrere EFC Segmente aufspalten oder das FTX (Free Text) Segment, das beliebige oft wiederholt werden darf, benutzen. Beide Losungen sind eindeutig nicht zufriedenstellend und es scheint eine Modizierung dieses Standards fur den erweiterten Einsatz unabdingbar. Die CONDRA-Nachricht (Drawing Administration Message) [UN95b] wurde vom westeuropaischen EDIFACT-Board (MD5) [NB U94] deniert und bendet sich zur Zeit noch im Status 1 (Draft). Die EXPRESS Spezikation der CONDRA-Nachricht ist im folgenden skizziert: 13

SCHEMA Condra; REFERENCE FROM Globals; REFERENCE FROM Segments; ENTITY CONDRA SUBTYPE OF (MESSAGE); Una : OPTIONAL UNA; Unb : UNB; Seg1 : UNH; Seg2 : BGM; Seg3 : LIST [1:5] OF DTM; Seg4 : OPTIONAL LIST[1:2] OF AUT; Seg5 : OPTIONAL LIST[1:2] OF AGR; Seg6 : OPTIONAL LIST[1:10] OF FTX; Seg7 : OPTIONAL LIST[1:5] OF QTY; SegGroup1 : LIST[1:10] OF SegGroup1; SegGroup2 : LIST[1:999] OF SegGroup2; SegGroup5 : OPTIONAL LIST[1:99] OF SegGroup5; Seg8 : UNT; Unz : UNZ; WHERE Id = 'CONDRA'; END_SCHEMA; ENTITY SegGroup5 SUBTYPE OF (Group); Seg1 : EFI; Seg2 : LIST[1:10] OF CED; Seg3 : OPTIONAL LIST[1:10] OF RFF; Seg4 : OPTIONAL LIST[1:5] OF DTM; Seg5 : OPTIONAL LIST[1:5] OF QTY; SegGroup6 : OPTIONAL LIST[1:100000] OF SegGroup6; Dateireferenzen konnen hier im Element File name des zusammengesetzten Element COMP077 des EFI (External File Link Identication) Segments der Segmentgruppe 5 ubertragen werden. Die Beschrankungen fur eine Ubertragung eines URL sind hier noch gravierender, da das Element nur einmal auftreten darf und auf 35 Zeichen beschrankt ist. Daher mute fur eine standardkonforme Benutzung der URL innerhalb einer EFI Sequenz ubertragen werden, falls er die Lange von 35 Zeichen uberschreitet. Eine Ubertragung als Free Text\ (FTX) ist hier allerdings moglich, da das FTX Segment ein zusammengefugtes Element von 6 x 70 Zeichen zur Verfugung stellt. Auch hier bieten beide Alternativen keine eleganten Losungen und es scheint eine Modikation der CONDRA-Nachrichtim Kontext globaler Ubertragungstechnologien dringend erforderlich. 6. Schlubemerkung Wir haben vorgestellt, wie EDIFACT-Nachrichten vollstandig in EXPRESS speziziert werden konnen. Die hier vorgestellten EDIFACT-Schemata bilden eine vollstandig formale Grundlage zur Denition des EDIFACT Standards und sind als Anregung fur die zustandigen ISO Arbeitsgruppen gedacht, EDIFACT in einem elektronischverarbeitbaren ISO Standardformat, namlich EXPRESS, zu denieren. Unsere EXPRESS-Spezikationen wurden nach dem Gesichtspunkt der praktischen Anwendbarkeit, d.h. der maschinellen Verarbeitbarkeit, erstellt und im Kontext der EDI- FACT Interpretation und der automatischen Erstellung von EDIFACT-Eingabeformularen erprobt. Potentielle Anwendungen durfte dieser Ansatz fur die Konvertierung von EDIFACT-Datenbestanden in Datenbanken liefern, wie es in unserem Szenario vorgestellt wurde. Eine genauere Betrachtung der im EDIFACT-Umfeld existierenden Mittel (Nachrichten bzw. Segmente) zum Austausch von Produktdaten und ihren Modellen hat hier ergeben, da noch ein erheblicher Klarungsbedarf besteht. Zur genauen Identikation von Dateien schlagen wir im Kontext einer Ubertragung im Internet vor, den URL als Dateireferenz auszutauschen. Zusatzlich sollte der Zeitstempel der letzten Dateimodikation ubertra- 14

gen werden, da nur so eine eindeutige Identizierung mit Plausibilitatsuberprufungen moglich ist. Die beiden hier untersuchten Nachrichten, ENGDAT und CONDRA, leiden unter den typischen Schwachen von EDIFACT, namlich der Limitierungen in der Lange der Datenelemente und ungenaue Spezikation des Inhalts, wie z.b. der Form der Referenzen. Vor allem die Frage der Referenzidentikatoren bedarf evtl. einer weitergehenderen Losung; im Bereich der verteilten Systeme sind dazu schon seit langerem Global Identi- ers\ eingefuhrt, wie z.b. die UUIDs (Universal Unique IDentiers) in DCE (Distributed Computing Environment) oder die Object Identiers\ von ASN.1. Wahrend erstere eine Eindeutigkeit gewahrleisten, ohne eine globale Registrierung zu erfordern (durch die Benutzung von Zeitstempeln und der (schon registrierten) Netzwerkadresse des austellenden Rechners), bedurfen letztere einer expliziten Registrierung, die allerdings durch den hierarchischen Namensraum delegiert werden kann. Im Umfeld des WWW wird versucht, die physikalischen\ URLs zukunftig durch positionsunabhangige URNs (Universal Resource Names) zu ersetzen; hierzu gibt es bereits mehrere Ansatze, aber nur wenige Implementierungen. Um das hier vorgestellte System zum praktischen Einsatz zu bringen, mu schlielich das Problem der Sicherheit, insbesondere das der Sabotage und illegales Abhorens, gelost werden. Die traditionelle Art uber ein VAN (Value Added Network) EDIFACT-Nachrichten auszutauschen, erlaubt es, diese Verantwortlichkeiten an den Betreiber des VANs abzuwalzen. Durch die Verwendung von gemieteten, privaten Verbindungen zum VAN ist schon eine gewisse Sicherheit gewahrleistet, die im Falle der Benutzung des Internets allerdings entfallt. Es gibt aber eine Reihe von sehr sicheren Verschlusselungsverfahren basierend auf Public-Key-Systemen, die das Risiko minimieren. Eine Losung bei der Benutzung von WWW ist S-HTTP, bei dem einzelne HTTP-Nachrichten verschlusselt werden. Andererseits gibt es kanalbasierte Verschlusselungsverfahren, wie SSL (Secure Socket Layer), die die gesamte Konversation verschlusseln. Literatur [BF92] N. Borenstein und N. Freed, \MIME, Multipurpose Internet Mail Extensions, RFC 1521, IETF Networking Group, Juni 1992. [IETF95] Internet Engineering Task Force (IETF), \Basic HTTP, URL: http://www.w3.org/ hypertext/www/protocols/http/http2.html, November 1995. [ISO88] ISO/TC154, \Electronic Data Interchange for Administration Commerce and Transport (EDIFACT){ Application Level Syntax Rules ISO 9735, ISO, Geneve, Switzerland, 1988. [ISO94a] ISO/TC184/SC4, \EXPRESS Language Reference Manual - ISO 10303-11, ISO, Geneve, Switzerland, Dezember 1994. [ISO94b] ISO/TC184/SC4, \STEP Physical File Format - ISO 10303-21, ISO, Geneve, Switzerland, Dezember 1994. [ISO94c] ISO/IEC JTC1/SC30, \Open-EDI Referenz Model Standard { Working Draft, N075, ISO, 1994. [NB U94] Normenausschu Burowesen (NBu-3.04) im DIN, \UN/ EDIFACT Organisation und Ansprechpartner in Deutschland und Europa, DIN, Oktober 1994. [FECAT94] Federal Electronic Commerce Acquisition Team, \Streamlining Procurement Through Electronic Commerce, Falls Church, VA, Oktober 1994. [ODETTE92] ODETTE WG11, \ENGDAT, Engineering Data, Organisation for data exchange by teletransmission, Juni 1992 [UN95a] UN/ECE, \UN Trade Data Interchange Directory, URL: http://www.premenos.com/ unedifact, November 1995. [UN95b] UN/ECE, \UN/EDIFACT Draft Directory D.95B, Westeuropaisches EDIFACT-Board - MD5, Geneve, Switzerland, Marz 1995. 15