The Fundamentals Of EDI

In order to electronically transfer form-based data between entities, the systems doing the transfer must agree on a number of parameters. Electronic data interchange (EDI) exists at the application layer to make that conversation among systems possible.

Some of those parameters can be negotiated during the transfer session; others must be agreed to beforehand. Such parameters as the transport medium, transport protocol, authentication, encryption, and format of the data itself must be agreed upon at some point.

In well-architected systems, a change in one parameter doesn't necessarily imply a change in another. For instance, moving from serial lines to a private or public network ideally shouldn't require new authentication and encryption choices. In practice, de facto standards crop up for electronic transfer--so transmitting data to a particular vendor may require using FTP via the public Internet and GS1-formatted documents, because "that's how they do it." Wal-mart, for instance, requires the AS2 protocol, which uses HTTPS and SMIME for transport, encryption, and session control.

Originally, EDI documents were designed to be as small as possible to facilitate transfer over slow serial lines. Because of their terse nature, they were often open to interpretation. If an order came in for 12 boxes of screws, it might not be clear if the sender intended to get 12 boxes containing 100 screws each, or 12 larger cases containing say 50 boxes of 100 screws each. The only way to fully resolve these issue was to test each connection to ensure both sender and receiver agreed on the format, and then test again if a new class of product came up.

The interpretation issue isn't limited to EDI, and computer science's answer to the problem is the Extensible Markup Language. XML allows for more extensive grammar definition and therefore the ability to produce nonambiguous (or at least less ambiguous) business documents.

The two largest sanctioned bodies for EDI standards are American National Standards Institute's ASC X12 committee, which creates standards for North America, and Edifact, which is sanctioned by the United Nations and creates standards largely used outside of the United States. While these standards are often codeveloped by the two bodies and are widely used, they are also widely ignored or extended in proprietary ways.

One challenge with XML based systems is that XML is extensible, and standards often form only the base of a company's or public entity's usage. Unique extensions are often developed for good reason, but they require unique support.

Other entities, such as GS1 (formerly UCC--the folks who dictate the universal bar codes), have grown their own sets of standards that partially overlap with those of X12 and Edifact. GS1 is a U.S. entity whose standards are largely aimed at supply chain management. It has subsidiaries including RosettaNet, which works in the business-to-business space and is largely used by the electronics industry. Other groups exist to serve the chemical, pharmaceutical, and energy industries.