EDIFlow-Infrastruktur: Parser, Repositories und Datenpakete im Detail

Infrastruktur-Schicht: Wo Theorie auf Praxis trifft

Nach der Anwendungsschicht folgt die Infrastruktur — der Ort, an dem Abstraktionen wie IMessageParser in konkrete Implementierungen wie EdifactMessageParser überführt werden. Hier werden 126 bis 319 JSON-Nachrichtendefinitionen zur Laufzeit geladen, und die theoretischen Ports aus der Domain-Schicht erhalten ihre technischen Entsprechungen.

Die Infrastruktur-Schicht ist der Ort, an dem die saubere Architektur von EDIFlow auf die harte Realität trifft. Während die Domain-Schicht die Regeln vorgibt und die Anwendungsschicht die Use Cases definiert, setzt die Infrastruktur die Schnittstellen (Ports) in funktionierende Code-Bausteine um. Hier wird aus einer abstrakten IMessageStructureRepository ein FileBasedMessageStructureRepository, das auf Dateisystemen operiert.

Drei Pakete für vier EDI-Standards: Warum die Aufteilung sinnvoll ist

EDIFlow unterstützt vier verschiedene EDI-Standards: EDIFACT, X12, HIPAA und EANCOM. Doch wie organisiert man die Infrastruktur für so unterschiedliche Formate? Die Antwort liegt in einer modularen Struktur mit drei separaten Paketen, die jeweils eine klare Verantwortung tragen:

• @ediflow/edifact – Spezifisch für EDIFACT: Parser, Builder, Validator und Tokenizer
• @ediflow/x12 – Spezifisch für X12: Parser mit angepasster Delimiter-Erkennung
• @ediflow/infrastructure-shared – Standardübergreifend: Dateiladung, Repositories und Caching

Warum nicht ein einziges Infrastruktur-Paket?

Die Trennung ist kein Zufall, sondern Notwendigkeit. EDIFACT und X12 teilen sich nicht nur keine gemeinsame Implementierung — sie unterscheiden sich fundamental in Struktur und Regeln:

• Delimiter: EDIFACT verwendet + : . ? ', X12 setzt auf * ~ >
• Envelope-Struktur: EDIFACT nutzt UNB/UNZ, X12 arbeitet mit ISA/GS/ST
• Escape-Regeln: Jeder Standard hat eigene Regeln für Sonderzeichen

Ein einziges Paket würde zu einem unüberschaubaren „God-Paket“ führen, das keine Kohäsion mehr aufweist. Die modulare Trennung ermöglicht es, jeden Standard unabhängig zu warten und zu erweitern, ohne dass Änderungen in einem Bereich Auswirkungen auf andere haben.

Die Rolle des Shared-Pakets: Warum es für die CLI unverzichtbar ist

Das Paket @ediflow/infrastructure-shared dient vor allem einem Zweck: Es stellt sicher, dass die CLI-Tools von EDIFlow mit allen unterstützten Standards arbeiten können. Die FileBasedMessageStructureRepository lädt JSON-Definitionen für EDIFACT-Nachrichten wie ORDERS genauso wie für X12-Nachrichten wie 850 — ohne Unterschied.

Diese gemeinsame Basis kann nicht in den standard-spezifischen Paketen liegen, da sie sonst zu zyklischen Abhängigkeiten führen würde: @ediflow/edifact kann nicht von @ediflow/x12 abhängen und umgekehrt. Stattdessen bietet das Shared-Paket eine neutrale Schnittstelle für alle Infrastruktur-Komponenten, die dateibasierte Operationen benötigen.

Abhängigkeitsgraph: Wie alles zusammenhängt

Die Infrastruktur-Pakete sind so strukturiert, dass sie niemals direkt voneinander abhängen. Stattdessen binden sie alle an das Core-Paket (@ediflow/core), das die gemeinsamen Interfaces definiert:

@ediflow/core ←── @ediflow/edifact
                ↑
@ediflow/core ←── @ediflow/x12
                ↑
@ediflow/core ←── @ediflow/infrastructure-shared ←── @ediflow/cli

Die CLI ist die einzige Komponente, die alle Infrastruktur-Pakete nutzt, um die verschiedenen Parser, Repositories und Builder zu einem funktionierenden System zu verknüpfen. Diese klare Trennung verhindert Abhängigkeitschaos und macht das System wartbarer.

Der Parsing-Prozess: Drei Schritte, drei Klassen

Das Parsen einer EDI-Nachricht ist kein einzelner Vorgang, sondern ein mehrstufiger Prozess. EDIFlow unterteilt diesen in drei logische Schritte, die jeweils von einer eigenen Klasse implementiert werden:

Raw EDI-String → Delimiter-Erkennung → Tokenisierung → Segment-Parsing → EDIMessage

Jeder Schritt folgt einem klar definierten Interface und kann unabhängig voneinander getestet und optimiert werden. Hier ein detaillierter Blick auf die ersten beiden Schritte.

Schritt 1: Delimiter-Erkennung — Flexibilität für Partner-Nachrichten

EDIFACT-Nachrichten können individuelle Delimiter über die UNA-Servicezeichenkette definieren. Die ersten neun Zeichen legen fest, welche Zeichen für Komponenten, Elemente, Escape-Sequenzen und Segmentabschlüsse verwendet werden:

class EdifactDelimiterDetector implements IDelimiterDetector {
  private static readonly UNA_PREFIX = 'UNA';
  private static readonly UNA_LENGTH = 9;

  detect(message: string): Delimiters {
    if (this.hasUNA(message)) {
      return this.extractFromUNA(message);
    }
    // Keine UNA? Standard-Delimiter für EDIFACT verwenden
    return EdifactDelimiterDetector.DEFAULT_DELIMITERS;
  }

  private extractFromUNA(message: string): Delimiters {
    return Delimiters.custom({
      component: message.charAt(3),  // Meist ':'
      element: message.charAt(4),     // Meist '+'
      decimal: message.charAt(5),     // Meist '.'
      escape: message.charAt(6),      // Meist '?'
      segment: message.charAt(8),     // Meist "'"
    });
  }
}

Diese Flexibilität ist entscheidend, da nicht alle EDI-Partner die Standard-Delimiter verwenden. Ohne diese Erkennung würden Parser bereits an der ersten Nachricht scheitern, die statt + den Delimiter * nutzt. Die Klasse prüft zunächst, ob eine UNA vorhanden ist, und extrahiert daraus die individuellen Delimiter. Fehlt die UNA, werden die Standardwerte verwendet.

Schritt 2: Tokenisierung — Segmentierung mit Escape-Handling

Nach der Delimiter-Erkennung folgt die Tokenisierung: Der Rohstring wird in einzelne Segmente aufgeteilt, wobei Escape-Sequenzen korrekt interpretiert werden müssen. Die EdifactTokenizer-Klasse übernimmt diese Aufgabe:

class EdifactTokenizer implements ITokenizer {
  tokenize(message: string, delimiters: Delimiters): string[] {
    const segments: string[] = [];
    let currentSegment = '';
    let position = 0;

    while (position < message.length) {
      const char = message[position];

      // Escape-Sequenzen überspringen (z. B. ?+ steht für ein wörtliches +)
      if (this.isEscapedCharacter(message, position, delimiters)) {
        currentSegment += this.consumeEscapedCharacter(message, position);
        position += 2;
        continue;
      }

      // Segmentabschluss gefunden — aktuellen Segment speichern
      if (char === delimiters.segment) {
        if (currentSegment.trim().length > 0) {
          segments.push(currentSegment);
        }
        currentSegment = '';
        position++;
        continue;
      }

      currentSegment += char;
      position++;
    }

    return segments;
  }
}

Der Tokenizer durchläuft den String Zeichen für Zeichen und sammelt Segmente, bis ein Segmentabschlusszeichen gefunden wird. Besonders wichtig ist die Behandlung von Escape-Sequenzen: Befindet sich ein Escape-Zeichen vor einem Delimiter, wird dieser wörtlich interpretiert und nicht als Steuerzeichen. Nach der Tokenisierung liegen alle Segmente als separate Strings vor, die im nächsten Schritt weiterverarbeitet werden.

Ausblick: Was die Infrastruktur für die Zukunft bedeutet

Die modulare Infrastruktur von EDIFlow zeigt, wie sich komplexe Probleme durch klare Abstraktionen und eine saubere Paketstruktur lösen lassen. Durch die Trennung von standard-spezifischen und standardübergreifenden Komponenten wird das System nicht nur wartbarer, sondern auch erweiterbar.

In den kommenden Teilen der Serie werden wir uns den Repositories und Datenpaketen widmen, die die Infrastruktur mit den Use Cases der Anwendungsschicht verbinden. Die Grundlagen sind gelegt — jetzt geht es darum, die Infrastruktur mit Leben zu füllen und sie für reale EDI-Szenarien zu nutzen.