Getting Started with EDI Objects for EDIFACT

Requirements:
EDISDK

Introduction

EDI Objects in EDI SDK provide a strongly typed, schema-driven interface to EDIFACT documents. EDI Objects model EDIFACT documents as an object (class) hierarchy that matches a given EDIFACT schema. As a result, developers do not need to navigate segments through tag names and tracking element positions, but rather can use an intuitive set of named properties and methods to read, write, and modify EDI data.

The first section of this guide covers the process of generating EDI Objects.

The second section provides an introduction to using EDI Objects:

• Using EDI Objects to read EDIFACT documents
• Handling repeating EDIFACT segments
• Working with mixed transaction set types
• Using EDI Objects to write EDIFACT documents

Generating EDI Objects

EDI Objects are generated from XML schemas that are distributed with EDI SDK. Schemas for all official UNECE EDIFACT releases can be found under "schemas/EDIFACT" in the installation directory. If these schemas need to be customized, the XML can be edited in accordance with our schema format rules.

The ediobjects.exe tool processes these schemas into classes that reflect the message, segment, and element structure. This ensures consistent, reliable classes across all message types.

First, identify the version and specific messages required. For example, an organization using EDIFACT D97A may need the ORDERS and DESADV EDI Objects.

The CLI command follows this pattern for EDIFACT:

./ediobjects.exe "/path/to/d97a.xml" -m DESADV,ORDERS -o "path/to/output/folder/" -l java

Omitting the -m flag will default to generating EDI Objects for all messages in the source directory.

Generated EDI Objects provide classes for all messages, groups, segments, and elements, reflecting the schema hierarchy. Repeating segments and groups are exposed as collections, and nested structures are represented through the object hierarchy. Each set of EDI Objects supports reading, writing, and validating without requiring separate classes or helper modules for each task.

The generated EDI Objects code is fully accessible, allowing inspection and easy integration into existing projects. Because all EDI Objects follow the same structure, adding support for additional message types requires only generating the new EDI Objects and including it in the build. For trading partners using custom implementations or when extending standard specifications, EDI Objects can be regenerated from modified schemas and integrated seamlessly.

Using EDI Objects

Once generated, EDI Objects can be used to easily read, write, and modify EDIFACT documents. This section provides an introduction to common operations using EDI Objects.

Using EDI Objects to Read EDIFACT documents

With EDI Objects generated, reading EDIFACT documents becomes a matter of accessing named properties rather than parsing segment tags and element positions.

Accessing Segment Data

Unlike traditional methods that rely on element positions, EDI Objects provide explicit property paths:

itemNumber = lin.LIN.ItemNumberIdentification.ItemNumber.Value;

Property names derive directly from the EDI specification, making the code self-documenting. The structure reflects the schema exactly, eliminating ambiguity about composite contents or element positions within the hierarchy.

Handling Repeating Segments

EDI messages frequently contain repeating segments and loops. EDI Objects represent these as collections, enabling natural iteration without segment counters or manual index management.

Processing quantity information from multiple QTY segments:

foreach (var qty in lin.QTYList) 
{ 
  if (qty.QuantityDetails.QuantityQualifier.Value == "12") 
    item.ShippedQty += int.Parse(qty.QuantityDetails.Quantity.Value); 
} 

EDI Objects handle repeating segments internally, letting programs focus on business logic like checking qualifiers and extracting quantities.

Working with Mixed Message Types

EDI interchanges can contain multiple message types in a single file. EDI Objects handle this by exposing all messages through a common IMessage interface. Each message is automatically routed to a handler method that matches its specific type.

One option for C# is to use the dynamic keyword:

foreach (IMessage message in interchange.Messages) 
{ 
    Process((dynamic)message, lineItems); 
} 
private static void Process(ORDERS order, List<LineItem> lineitems) { ... } 

private static void Process(DESADV desadv, List<LineItem> lineitems) { ... } 

In Java, the correct method is found and called based on the message type:

for (IMessage message : interchange.getMessages()) { 
    processMessage(message, lineItems); 
} 

private static void processMessage(Object message, List<LineItem> items) { 
  Method m = edifactEDI Objectsreader.class.getDeclaredMethod( 
    "processMessage", 
    message.getClass(), 
    List.class 
  ); 
  m.invoke(null, message, items); 
}  

private static void processMessage(ORDERS order, List<LineItem> lineitems) { ... } 
private static void processMessage(DESADV desadv, List<LineItem> lineitems){ ... } 

This approach eliminates the need to manually inspect message header segments to determine message type. The EDI Objects provides the correctly typed object, and the handler methods route each message to the appropriate processing logic. The same iteration code handles files containing any combination of message types.

Using EDI Objects to Write EDIFACT documents

Creating EDIFACT documents with EDI Objects follows the same property-based approach used for reading. The schema-driven structure ensures values can only be assigned to valid locations.

Building Document Structure

Creating a document involves instantiating the message type and populating its properties:

ORDERS order = new ORDERS() order.UNH.MessageReferenceNumber.Value = "1" order.UNH.MessageIdentifier.MessageVersionNumber.Value = "D" order.BGM.DocumentNumber.Value = "1001" order.BGM.DocumentMessageFunctionCode.Value = "9"

Value validation occurs when the document is written. As the EDI Objects serializes the document to EDI format, values are validated against schema requirements. Individual elements and components include a checkValue() method that can be called to validate specific data points before writing the complete document.

Adding Line Items

Repeating groups are created by adding instances to the appropriate collection:

lineItem = new LINGroup() lineItem.LIN.ItemNumberIdentification.ItemNumber.Value = "12345" lineItem.LIN.LineItemNumber.Value = "1" order.LINGroupList.add(lineItem)

The EDI Objects maintains proper segment ordering and hierarchy, ensuring that line items and their child segments appear in the correct location within the document structure.

Next Steps

The consistent structure across all EDI Objects means that knowledge of one message type translates directly to others. Whether working with EDIFACT shipping notices or custom message types, the property-based approach remains the same. As additional message types are needed, generate the corresponding EDI Objects and integrate it into the project using the same patterns established with the first message type.