How EDIFlow’s Infrastructure Layer Handles Multi-Format EDI Parsing

EDIFlow’s journey through Clean Architecture reaches a critical milestone in its Infrastructure Layer—where abstractions from the Domain and Application layers meet practical implementation. This layer transforms theoretical interfaces like IMessageParser into functional components such as EdifactMessageParser, while bridging the gap between standardized interfaces and real-world data formats. Here’s how EDIFlow’s modular design handles the complexity of multi-standard EDI parsing without sacrificing cohesion or scalability.

Bridging Theory and Reality: The Role of the Infrastructure Layer

In Clean Architecture, the Infrastructure Layer’s primary responsibility is to implement the interfaces defined by the Domain and Application layers. For EDIFlow, this means translating abstract concepts into concrete solutions for parsing, validating, and storing EDI messages across multiple standards. Unlike the Domain and Application layers—where logic remains standard-agnostic—the Infrastructure Layer must account for the nuances of each format it supports.

This layer is where the rubber meets the road. For example, the EdifactMessageParser doesn’t just parse text; it orchestrates a multi-step pipeline that begins with delimiter detection and ends with structured message objects. Without this layer, EDIFlow’s use cases would remain theoretical, unable to interact with real-world EDI data.

Modular Design: Why EDIFlow Splits Infrastructure into Three Packages

EDIFlow supports four EDI standards—EDIFACT, X12, HIPAA, and EANCOM—but it avoids the pitfall of a monolithic infrastructure package. Instead, it distributes responsibilities across three distinct packages, each tailored to a specific role:

• @ediflow/edifact: Focuses exclusively on EDIFACT parsing, validation, and tokenization. This package handles EDIFACT-specific delimiters (+, :, .), envelope structures (UNB/UNZ), and escape rules.
• @ediflow/x12: Specializes in X12 parsing, including delimiter detection and segment handling. X12 uses different delimiters (*, ~) and has a distinct envelope structure (ISA/GS/ST).
• @ediflow/infrastructure-shared: Provides shared utilities like file loading, repositories, and caching. This package is standard-agnostic and supports functionality required by tools like the CLI, which needs to load message definitions for all standards from a single entry point.

The separation isn’t arbitrary. EDIFACT and X12 parsing share almost no implementation code due to differences in delimiters, envelope structures, and escape rules. Combining them into a single package would create a bloated, unmaintainable solution—a classic "God package" problem. By splitting responsibilities, EDIFlow ensures each package remains focused, testable, and scalable.

The dependency graph reflects this modularity. Core depends on all three infrastructure packages, while the CLI depends on them all to assemble the complete system. No package depends on another directly, preserving the Clean Architecture principle of dependency inversion.

The Parsing Pipeline: A Step-by-Step Breakdown

Parsing an EDI message isn’t a single operation but a multi-stage pipeline. EDIFlow breaks this process into three distinct steps, each handled by a dedicated class implementing a shared interface. This design allows for flexibility and reusability, particularly when supporting multiple standards.

Step 1: Delimiter Detection – Adapting to Non-Standard Formats

EDIFACT messages can define custom delimiters using the UNA service string, which occupies the first nine characters of the message. These delimiters specify characters for components, elements, escaping, and segment termination. For example, a UNA:+.? ' string indicates that + separates elements, : separates components, . denotes decimals, ? is the escape character, and ' terminates segments.

The EdifactDelimiterDetector class handles this variability:

export 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);
    }
    // Fall back to EDIFACT defaults if no UNA is present
    return EdifactDelimiterDetector.DEFAULT_DELIMITERS;
  }

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

This flexibility is critical because real-world EDI partners often use non-standard delimiters. Without this step, even a minor deviation—like replacing + with *—could break the entire parsing pipeline.

Step 2: Tokenization – Splitting Raw Data into Segments

Once delimiters are identified, the raw EDI string must be split into segments. The EdifactTokenizer class handles this by iterating through the string, respecting escape characters and segment terminators:

export 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];

      // Skip escaped characters (e.g., ?+ represents a literal '+')
      if (this.isEscapedCharacter(message, position, delimiters)) {
        currentSegment += this.consumeEscapedCharacter(message, position);
        position += 2;
        continue;
      }

      // Segment terminator found — finalize current segment
      if (char === delimiters.segment) {
        if (currentSegment.trim().length > 0) {
          segments.push(currentSegment);
        }
        currentSegment = '';
        position++;
        continue;
      }

      currentSegment += char;
      position++;
    }

    return segments;
  }
}

Tokenization is format-specific. X12, for instance, uses ~ as a segment terminator and lacks an escape character, so its tokenizer would implement the same interface but with different logic. This separation ensures EDIFlow can support multiple standards without duplicating shared infrastructure code.

Step 3: Message Parsing – Orchestrating the Pipeline

The final step combines delimiter detection, tokenization, and segment parsing into a cohesive workflow. The EdifactMessageParser class acts as the orchestrator, validating the input, detecting delimiters, tokenizing segments, and parsing each segment into a structured object:

export class EdifactMessageParser implements IMessageParser {
  constructor(
    private readonly delimiterDetector: IDelimiterDetector,
    private readonly tokenizer: ITokenizer,
    private readonly segmentParser: EdifactSegmentParser
  ) {}

  parse(ediString: string, config?: ParserConfig): EDIMessage {
    this.validateMessage(ediString);
    const delimiters = config?.delimiters || this.delimiterDetector.detect(ediString);
    const segments = this.tokenizer.tokenize(ediString, delimiters);
    return this.segmentParser.parse(segments, delimiters);
  }
}

This modular approach ensures that each component remains independent, testable, and replaceable. For example, swapping the EdifactTokenizer for an X12Tokenizer would require no changes to the parser itself, thanks to shared interfaces.

The Future: Scalability and Standard Support

EDIFlow’s Infrastructure Layer demonstrates how modular design can tame complexity in systems that must support multiple standards. By separating concerns into dedicated packages and leveraging pipelines for parsing, EDIFlow ensures that adding support for new formats—like HIPAA or EANCOM—requires minimal changes to existing code.

Looking ahead, the focus will likely shift to optimizing performance for large-scale EDI processing and expanding validation capabilities. As EDI ecosystems evolve, EDIFlow’s infrastructure will need to adapt, but its modular foundation provides the flexibility required to meet these challenges head-on.