EDI as a Reference for Integration Services

This blog post suggests consideration or even use of Electronic Data Interchange standards when implementing integration services between applications.

Electronic Data Interchange (EDI) “can be defined as the transfer of structured data, by agreed message standards, from one computer system to another without human intervention” (Electronic data interchange – Wikipedia).

EDI standards such as X12 define consistent but flexible formats for exchanging information between systems. Each standard contains numerous definitions for common types of records (“transactions”) such as purchase orders and purchase order responses, shipping notifications, inventory and point of sale reports, product test reports, and so forth.

X12 EDI Examples | X12 provides a helpful list of common transaction types. Note that the verticals are just examples – X12 uses transaction 850 for all purchase orders, not just Aerospace purchase orders.

Rather than each vendor defining proprietary formats and each customer implementing custom formats, both can use EDI standards to define formats. For example, systems that output data that indicate payment required could use the X12 810 “Invoice” transaction, while systems that provide payment could use the X12 “Payment Order/Remittance Advice (EFT)” transaction. Anything that involves planning dates and times could use the 830 “Planning Schedule/Material Release” transaction. EDI standards define transactions that support almost any conceivable use of data.

Using EDI standards in any way to define data exchange formats has a few potential advantages.

• The existing EDI standards have been developed to support almost any use case.
• Existing EDI standards could help to define requirements for generic data formats.
• Consistent standards simplify system integration and customer migration between vendors.
• Existing organizations and processes maintain EDI standards.

EDI standards may appear complex, but implementation is often simple. The standards define options that apply to specific use cases but which most implementations omit.

EDI ensures that records (documents) meet transaction schemas. For some JSON implementations, similar functionality may be appropriate to ensure that data conforms to conventions. Because EDI standards are extensive, simplification and reference implementations of common transactions may be appropriate.

EDI transactions can define very course or very fine-grained information. Formats based on EDI standards could apply at any layer of a service-oriented architecture, su.

With or without simplification, there are at least three ways that an existing EDI standard could be used but systems not intended for use in EDI.

• EDI: Exchange data in the raw EDI format.
• New: Use the standard to define a new format for the same data (define a JSON schema based on data present in an X12 schema).
• JSON: Use the standard to implement a new format for the same data (convert an X12 schema to a JSON schema).

While raw EDI formats are simple and compact, JSON is more familiar to developers and consistent with modern solution architecture and development tooling, making EDI an unlikely option.

Using the EDI standards for implementation (JSON) rather than defining new standards (New) could have additional advantages in reducing the time required to define data formats. All EDI structures should map easily and cleanly to JSON structures, allowing programs to define JSON formats based on EDI standards and convert data between EDI and JSON formats.

EDI standards and concepts may apply not just for HTTPS service endpoints, but for any generic data exchange, such as event and message passing systems.

It would be interesting to know what types of data exchanged by modern systems align with various EDI transactions, what transactions would require extension for modern purposes, and what types of data would require new transaction types.

At the very least, EDI standards and concepts may deserve some reconsideration in the age of JSON service APIs. Please comment on this blog post to share your opinion and perspective.