Innerhalb des Projekts ATEDI soll für die öffentlichen Spezifikationen ebenfalls freie GNU-Software zur Verarbeitung der EDI-Datenbestände bereitgestellt werden.

Die hier verfügbaren Programme heissen wie die EDI-Messages, die sie verarbeiten. (Das Programm atibxs verarbeit also zB. die EDI-Messages vom Typ ATIBxS) Die Programme lesen jeweils eine EDI-Message ein und stellen fest, ob sie strukturell korrekt ist. Dabei wird die gesamte Nachricht in ihre einzelne Segmente zerlegt und programmintern verfügbar gemacht. In EDI-Messages vom Typ ATIBxS enthaltene Images, eine besondere Erweiterung der STUZZA-Spezifikation, werden in separate Files ausgefiltert und/oder aus der EDI-Message entfernt. Über Optionen kann man das Ausgabeformat der EDI-Message steuern. Folgende Formate stehen zur Auswahl:

Abschliessend erfolgt eine Prüfung des im UNT-Segment enthaltenen Segmentzählers. Ein mögliches UNA-Segment zu Beginn einer Nachricht wird nicht beachtet. Wir gehen von folgender Grundeinstellung für die Trenn- und Sonderzeichen aus: UNA:+.? '

Grundlage des Abgleiches einer konkreten EDI-Message mit ihrer Struktur ist die Formulierung der Strukturbeschreibung als sogenannte Grammatik. Der Kern dieser formalen Beschreibung kann dabei direkt aus den sogenannten Branch-Diagrammen bzw. den Übersichten der Segmentbentbeschreibungen aus den Spezifikationen abgeleitet werden.

Die EDI-Spezifikationen beschreiben eine EDI-Message als Folge von Segmenten. Jedes Segment besteht dabei aus:

Aus heutiger Sicht erweist sich das Konzept der Trennezeichen bei Feldern und Subfeldern als nachteilig. Das aktuell vorherrschende Konzept der Textauszeichnung (Markup) das bei XML-Dateien angewendet wird, klammert daher auch jedes Datenelement mit einem öffnenden und schliessenden Paar zweier Tags. Wegen des Fehlens niederwertiger Abschlusszeichen (':' nach dem letzten Subfeld, '+' nach dem letzten Feld) kann der Typ des ersten Datenelementes eines Feldes nur kontextbezogen als Feld oder Subfeld ermittelt werden. In ATEDI wird daher konzeptuell jedes Feld als Folge einzelner Subfelder betrachtet.

Als Scanner für die EDI-Messages wird das GNU-Programm FLEX verwendet. Der Scanner qualifiziert jedes Datenelement der EDI-Message (Segment-Tags, Felder und Trenner) protokolliert diese Informationen und stellt sie dem Parser zur Verfügung. Alle Dateninhalte (Texte, Zahlen usw.) werden in einer Wertetabelle gesammelt und können vom Parser mit den Indexwerten Feldnummer und Sufeldfeldnummer referenziert werden.

Als Parser für die EDI-Messages wird das GNU-Programm BISON verwendet. Er übernimmt die Informationen des Scanners und prüft die Übereinstimmung der Datenelemente (Token) mit der formalen Beschreibung. Segmente, die nicht der geforderten Struktur entsprechen werden protokolliert. Am Ende der Verarbeitung jedes Segmentes stehen alle seine Dateninhalte in der vom Scanner aufgebauten Wertetabelle bereit.

Folgende Basisfunktionen stehen zur Verfügung:

Da alle Feldinhalte eines Segments gezielt angesprochen werden können, besteht eine gute Ausgangsbasis für individuelle Erweiterungen.

Soll eine in EBCDIC kodierte Message auf einem LINUX- oder UNIX-System verarbeitet werden, muss sie zuerst nach ASCII konvertiert werden. Enthaltene Images werden dadurch unbrauchbar. Um sie betrachten zu können, nachdem sie durch das ATEDI-Tool atibxs aus der EDI-Message extrahiert wurden, ist daher ein Rückübersetzung nach EBCDIC nötig. Die Codeumsetzung erfolgt praktischerweise mit dem Programm recode. Der Pseudocode des Ablaufes:

recode ebcdic..ascii _atibxs_message_ (das ist die EBCDIC kodierte Message)

mkdir images
cat _atibxs_message_ | ./atibxs -H -f './images/atibxs_%d.tif' >_atibxs_.html

recode ascii..ebcdic images/atibxs_*.tif

_atibxs_.html kann mit einem Browser betrachtet werden und enthält Links, die auf die extrahierten Images weisen.

Die Programme des ATEDI Projekts stehen unter dem Copyright der GNU General Public Licence - GPL.

Kontakt.