grefe´s webnotes

Skip to: [content] [navigation]

Programmierung im EDI-Umfeld ( nun bei EDI_HH)

Goethes Faust - als Grobspec

Du musst verstehn!
Aus Eins mach Zehn,
und Zwei laß gehn.
So bist Du reich.
Verlier die Vier,
aus Fünf und Sechs-
so sagt die Hex-,
mach Sieben und Acht,
so ists vollbracht:
Und neun ist Eins,
Das ist das Hexen-Einmaleins!

Motivation/Ziel

Mein Ziel ist es meine über Jahre vernachlässigten Programmierkenntnisse aufzufrischen und mit Java zu erweitern. Java hat sich im Bereich der Web-Technologien durchgesetzt und ist auch bei Cocoon die Sprache der Wahl. Zum anderen weist Java große Parallelen zu C++ auf. Einer Sprache die mir um einiges vertrauter ist.

Schwerpunktmäßig werde ich mich im Bereich EDI und XML engagieren. Im EDI-Bereich habe ich jahrelang als Programmierer und anschliessend als Consultant gearbeitet. Aufgrund dieser Erfahrungen erwarte ich eine zügige Einarbeitung in diese Thematik mit heute gebräuchlichen Java-Technologien. Java unterstützt die Verarbeitung von XML-Dateien mit umfangreichen Paketen. XML hat sich bereits bei Webservices durchgesetzt und beginnt auch beim klassischen Datenaustausch Boden zu gewinnen. Obwohl ich bezweifle, dass es beim "Massendatenaustausch" EDIFACT den Rang streitig machen wird. Dennoch wird XML in beinahe beliebigen Bereichen federführend sein.
Zur "parallelen" Einarbeitung gedenke ich eine Art EDI-Workbench basierend auf Cocoon und einer Konvertierungs-Library/Engine in Java zu entwickeln. Den Zeitplan möchte ich mir bei diesem weiten Feld nicht zu eng setzen, da meine Familie diesem Hobby denn doch nicht die gleiche Bedeutung beimisst wie ich :-)

Konvertier-Module

XML

Nagios-Plugins

Je nach Bedarf/Anforderung

Cocoon

Sofern Java-Programmierung bei der Nutzung überhaupt anfällt!

EDI-Begriffe

Die folgenden Erläuterungen dienen nicht der Einarbeitung in die EDI-Thematik. Dazu sind eher die angeführten Links oder gar weiterführende Literatur geeignet. Aber vielleicht wird dem kundigen Leser wieder einiges vertrauter und dem Sachfremden das Thema ein bischen weniger fremd :-)

Datenformate:

EDI steht für Electronic Data Interchange oder für den Austausch von strukturierten Geschäftsdokumenten zwischen Anwendungssystemen. Dies sollte möglichst automatisch und insofern ohne Medienbruch ( kein Papierformat !) erfolgen. Bereits in den frühen 70 ´Jahren waren SEDAS in der deutschen Konsumgüterindustrie und VDA in der Automobilindustrie weit verbreitet. Diese Datenformate besitzen feste Satzlängen und sind speziel für die jeweilige Branche entwickelt worden. Meist erlangten diese Formate auch nur eine nationale Ausbreitung. VDA wurde mittlerweile weitgehend durch ODETTE und SEDAS durch das EDIFACT Subset EANCOM ersetzt. Im nordamerikanischen Raum hat sich ein Datenformat etabliert, welches der Syntax von EDIFACT ähnlich ist. ANSI X12 ist ein branchenübergreifendes, "nationales" Datenformat und wird wohl dem UNO-Format EDIFACT nicht weichen.

EDIFACT:

Electronic Data Interchange For Administration Commerce and Ttransport wurde 1985 von der UNO im Auftrag entwickelt und als internationale, branchenunabhängige Norm erhoben. EDIFACT zeichnet sich durch eine flexible Satzlänge und einer Vielzahl an Nachrichtentypen aus. Da vielen die Messagetypen zu komplex erschienen, reduzierten einige Branchen bestehende Messagetypen (INVOIC,ORDERS,...) auf ihr Anwendungsgebiet und entwickelten sogenannte Subsets.  Als Beispiel sei hier die CCG und EANCOM für die Konsumgüterindustrie genannt.

Der Nachrichtenaufbau einer Übertragung entspricht der folgenden Syntax:

Service String Advice                           UNA     Conditional
+----- Interchange Header                       UNB     Mandatory
| +--- Functional Group Header          UNG     Conditional
| | +- Message Header                           UNH     Mandatory
| | | User Data Segments
...BGM'DTM'NAD'CUX'LIN'QTY'MOA'NAD'NAD..UNS'MOA'MOA...
| | +- Message Trailer                          UNT     Mandatory
| +--- Functional Group Trailer                 UNE     Conditional
+----- Interchange Trailer                      UNZ     Mandatory
wobei UNA:
UNA:+,? '
|||||+---> Segmentendezeichen
||||+----> reserviert, bleibt leer
|||+-----> Release-Zeichen
||+------> Zeichen für's Dezimalkomma
|+-------> Datenelement-Trennzeichen 
+--------> Composite-Element-Trennzeichen 
Bei Bedarf,Lust und Zeit (wohl kaum :-( werde ich eine Übertragungsdatei auf Datenelementebene "herunterbrechen" und genauer erläutern.

 

IDOC

IDOC ist ein/das SAP Datenaustauschformat mit verschiedenen IDOC-Typen (ORDERS01). IDOC´s wurden mit Focus auf existierende Datenelemente in ANSI X.12, EDIFACT und interne SAP Felder entwickelt.

Charakteristisch für IDOC´s sind:

Ein IDOC besteht aus drei records. Der control record identifiziert das IDOC (IDOC-ID, Absender-ID, Empfänger-ID, IDOC-Typ, Struktur). Das data record besteht aus einer "key section" zur Identifizierung/Zuordnung des IDOC´s (Segment -Name, -Nummer, -Level,..) und der "data section". Die "data section" enthält die Anwendungsdaten. Der status record tracked den Weg/Status des IDOC´s zum/vom Partner.

Auf die Anforderungen an das EDI-Subsystem, das Message Control System (oder gar auf das Customizing) möchte ich nicht eingehen.

XML

eXtensible Markup Language ist ein Dokumentenstandard des W3C. Es ist - ebenso wie HTML - eine vereinfachte Form des SGML. Im Gegensatz zu HTML ist es nicht statisch, sondern kann vom Benutzer auf seine Bedürfnisse angepasst werden. Die Datenformate sind dadurch in der Regel selbstbeschreibend und die Struktur wird in DTD´s oder in Schema´s festgelegt. Die Darstellung der Daten erfolgt durch XSL kann aber meist auch durch CSS erfolgen, welches durch die meisten XML-Anwendungen unterstützt wird. Beispielsweise wird ein XML-Datensatz durch ein XSLT-Stylesheet für einen Browser aufbereitet oder mit XSL-FO in PDF überführt. XSL vermag im Gegensatz zu CSS auch die Struktur der XML-Daten ändern und ist nicht wie CSS auf die Darstellung beschränkt.

Kommunikationsprotokolle

X.400 gehört ebenso wie FTAM zu den OSI-Protokollen. X.400 ist ein "stay-and-forward" Protokoll. Es ist eine Abbildung der gelben Post mit Möglichkeiten des "Einschreibens" - sogar mit "Rückantwort". Insofern gleicht es modernen Mailsystemen. Der Client heißt RUA (Remote User Agent) und kommuniziert - da er nicht immer online ist - mit dem Messagestore. Das zugrundeliegende Protokoll P7 wurde im 88´ Standard definiert. Für den permanent erreichbaren Client UA (User Agent) ist das P3 Protokoll ausreichend, um mit dem MTA (Message Transfer Agent) zu kommunizieren.

        P7            P3         P3
  RUA<------>MS|MTA<------>MTA<------>UA

Das OSI-Protokoll FTAM ist ein Punkt zu Punkt Protokoll. Es wird direkt mit dem Partner eine Verbindung aufgebaut. FTAM besitzt weitreichende Sicherheitsvorkehrungen und wird deshalb auch gern von Banken eingesetzt ( NICHT Onlinebanking). FTAM ist allerdings sehr umfangreich und wurde nicht von vielen Softwarehäusern komplett umgesetzt. So hat sich ein weiteres "abgespecktes" Punkt zu Punkt Protokoll zumindest in der europäischen Automobilindustrie durchsetzen können - OFTP.

Aus der Familie der TCP/IP Protokolle hat sich FTP eine weite Anhängerschaft gesichert. Es ist ein einfaches aber auch unsicheres Protokoll. Die Daten auch die Passwörter werden im Klartext übertragen und können mit einfachen Mitteln von Dritten gelesen werden. Die übertragene Dateigröße wird nach dem Transfer nicht überprüft. Und dennoch hat FTP seine Berechtigung. Es gibt eine Vielzahl kostenloser bis kostengünstiger Clients. Mit der weiteren Verbreitung von Linux-Derivaten werden sich künftig aber sicherere Applikationen/Protokolle durchsetzen.

kleinergrößernormal