Getting Started with EDIFACTReader


Requirements:
EDISDK

Introduction

The EDIFACTReader component in EDISDK makes it easy to read and process EDIFACT messages. It can validate interchange structures, navigate messages and segments, and generate acknowledgments, all with minimal setup. This guide walks through the basics: loading a schema, parsing a transmission, and exploring the data.

Tip: Download the latest version of EDISDK to follow along.

Step 1: Load a Schema

EDISDK uses custom XML schemas, with one file per standard version. These schemas are:

  • Human-readable
  • Easy to maintain
  • Optional for parsing (but required for validation)

For reference, the demos include a D97A schema, so an application can start parsing immediately. Additional details on creating new schemas can be found in the EDIFACT Schema Format help docs

Note: Without a schema, EDIFACTReader can parse messages but validation won’t occur, and schema-related fields remain empty.

The EDIFACTReader component can load schemas in two ways:

Option A: Load Schemas beforehand

One option for loading a schema is to call LoadSchema before parsing. If the EDIFACT document contains only one known message type, simply pass the schema string or schema location along with the message name to LoadSchema. To load multiple messages, the messageName parameter can be set to '*' to load all messages from a file or a comma separated list of message types to load only the message schemas required.

Option B: ResolveSchema Event

For scenarios involving multiple standards or message types, the ResolveSchema event provides a way to dynamically load schemas. This event fires whenever an EDIFACT message is encountered without a corresponding schema, providing both the standard version and message name so that the appropriate schema can be loaded. An example of how this event may be handled is shown below: reader.OnResolveSchema += (s, e) => { string schemapath = basepath+e.MessageVersion+".xml"; reader.LoadSchema(schemapath, e.MessageType); };

Step 2: Handle Parsing Events

The EDIFACTReader component functions well in an event-driven architecture. Subscribing to and overriding these component events allows for easy customization and fine grained control.

Header Events

Header events such as StartInterchange, StartFunctionalGroup and StartMessage are unique in that the header values are exposed using clear, easy-to-understand identifiers, making validation straightforward. For example, an event handler for the StartInterchange event might look something like this: private static void EDIFACTReader_OnStartInterchange(object sender, EDIFACTReaderStartInterchangeEventArgs e) { Console.WriteLine("StartInterchange: " + e.Tag); if(e.SenderIdentification.Equals(trustedPartnerId)){ // Apply custom logic for trusted partner }
}

Segment Event

The Segment event is where most data-level logic happens. It fires only after a segment is fully parsed, providing:

  • Efficiency: fewer events, faster performance.
  • Simplicity: one central place to handle elements and components.
  • Context: full visibility of the segment before processing.

Inside the Segment event, it is easy to loop through the available elements and compound elements as needed. By consolidating all element-level processing into the Segment event, the parsing logic is simple and efficient.

Validation Error Event

The ValidateWarning event is fired when the parser encounters a validation issue. Common cases include element values that don’t match the expected code list, segments appearing out of order, or inconsistent data. Validation errors are not stored within the component and must either be saved or processed through this event. An example is shown below: reader.OnValidateWarning += (s, e) => { String err = String.Format("[{0}-{1},{2}] {3}: {4} - {5}", e.Position, e.Line, e.Column, e.ErrorCode, e.ErrorMessage, e.ErrorType); m_Warn += err + "\n"; }; This approach allows for applications to capture, review, or log warnings as they occur during parsing.

Step 3: Load Input Data

EDIFACTReader can parse data from any one of multiple sources:

  • File: reader.InputFile = "path/to/file.edi";
  • Stream: reader.SetInputStream(stream);
  • String: reader.InputData = ediString;

Once the data has been loaded, calling the Parse method will begin the process of parsing the provided document.

Step 4: Data Exploration

Once parsing is complete, the EDIFACTReader component can explore and process the data in different ways. Two common approaches are:

Option A: GetElement

If the path to the element is already known, the value can be retrieved directly. For example: string element = reader.GetElement("CPSGroup[2].LINGroup[2].QTY.1.2");

Option B: Iterate

When the path is not known, messages, segments, elements, and components can be looped through or accessed via their properties. This approach is also useful when more than the element value is needed, such as schema name, description, or other metadata. If this method of parsing is planned, the BuildDOM level must be set to capture the parts of the document that an application wants to explore. Typically, storing the entire document is the safest way to ensure that nothing is missed. Additional information on BuildDom settings may be found here. For example: List itemNums = new List(); for (int s = 1; s <= reader.SegmentCount; s++) { reader.SegmentIndex = s; if (reader.Segment.Tag != "LIN") { continue; // Skip segment tags that are not "LIN" } reader.ElementIndex = 3; // Select the third element in LIN reader.ComponentIndex = 1; // Select the first component if (reader.Component.SchemaName == "Item number"){ itemNums.Add(reader.Component.Value); // Save the item number } }

Conclusion

The EDIFACTReader component provides a flexible, event-driven approach to parsing EDIFACT messages. By combining schema-based validation with either direct element access or iterative exploration, it allows applications to efficiently process structured business data.

Whether the goal is to quickly extract known values, loop through segments to gather detailed information, or capture schema metadata for reporting and validation, EDIFACTReader makes these tasks straightforward. With proper configuration, it can be simply integrated into a wide range of workflows, from order processing and invoicing to inventory management and compliance checks.

By following the steps outlined in this guide, loading schemas, handling parsing events, loading input data, and exploring elements, developers can get up and running quickly with EDIFACTReader and begin automating the handling of EDI documents with confidence.

We appreciate your feedback. If you have any questions, comments, or suggestions about this article please contact our support team at support@nsoftware.com.