EDI Meets XML

The concept of EDI is even more relevant today than it was 20 years ago because

• Paperwork is as costly today as it was then.

• More companies have computerized their accounting functions and most are connected to a worldwide network (the Internet). They could benefit from EDI.

EDI and the Internet

So, deploying EDI makes a lot of sense, but traditional EDI technologies, such as EDIFACT and X12, have not really taken off on the Internet. A number of reasons have been proposed to explain this lack of interest:

• EDI technologies are not familiar and do not integrate naturally in an HTML-centric Web.

• Few products, if any, ship with an EDI feature.

• No matter how effective, EDI technologies look old-fashioned and are not popular with developers.

• EDI standards have focused on building "universal" messages that are too difficult to use, as we have seen. Therefore, companies have implemented incompatible variations.

• EDI standards are complex and costly to deploy.

• Finding information on EDI on the Internet is difficult.

It is expected that XML could help alleviate some of these problems because

• XML supports complex data structures and can easily encode commercial and administrative documents as EDI does.

• An ever-growing list of products are XML-enabled (including a growing number of ERP and databases). In that respect, XML appears as the preferred format to exchange data.

• XML is popular with Web developers and interfaces neatly with the Web-centric world.

• XML supports modern, object-oriented modeling and programming.

• As we have seen before, XML has been designed to facilitate reusing vocabulary without putting unnecessary burden on the user . XML namespaces are helpful in this case.

• No shortage of resources on XML exists on the Internet.

These are all valid reasons, and I think the most important one is the integration with the Web. XML works as a natural extension of HTML for specific applications. See Figure 5.3 for an illustration.

Figure 5.3. XML supports both users on a workstation and a more automated approach.

The lower portion of Figure 5.3 is the familiar Web site, although this one is built on XML. The server of the seller uses XSL to present information to a buyer. This is similar to what we built in Chapter 4, "Content Syndication." However, instead of publishing news, it publishes commercial documents such as purchase orders, invoices, and customs declarations.

The upper portion skips the style sheet to demonstrate an EDI-like exchange of information. The same XML commercial documents are presented to the accounting system or the ERP of the buyer. What is interesting about this setup is that it uses Web technologies to integrate the two accounting systems.

The main benefit of this setup is that it enables the buyer to start with limited investments (a browser) and upgrade to the more automatic mode as the volume of transactions grows.

XML/EDI

In 1997, the XML/EDI Group ( http://www.xmledi.com ) was established as a grassroots effort to promote XML in business-to-business e-commerce. Since 1997, other groups, vendors , and organizations (such as ebXML, BizTalk, CommerceOne, RosettaNet, and more) have adopted XML as their preferred syntax for business-to-business e-commerce.

Unlike EDI, no worldwide, standardized XML version of the order and other commercial document exists. In fact, it is very unlikely that there will ever be one.

Listing 5.2 is one possibility for an XML version of an order. Figure 5.4 is a graphical representation of its structure. As you can see, it is a classic order with buyer and seller information followed by order lines. The XML order is very close to the EDIFACT order for a good reason: Most orders look alike.

Listing 5.2 orders.xml

 <?xml version="1.0"?> <Order confirm="true">    <Date>2000-03-10</Date>    <Reference>AGL153</Reference>    <DeliverBy>2000-04-10</DeliverBy>    <Buyer>       <Name>Playfield Books</Name>       <Address>          <Street>34 Fountain Square Plaza</Street>          <Locality>Cincinnati</Locality>          <PostalCode>45202</PostalCode>          <Region>OH</Region>          <Country>US</Country>       </Address>    </Buyer>    <Seller>       <Name>QUE</Name>       <Address>          <Street>201 West 103RD Street</Street>          <Locality>Indianapolis</Locality>          <PostalCode>46290</PostalCode>          <Region>IN</Region>          <Country>US</Country>       </Address>    </Seller>    <Lines>       <Product>          <Code type="ISBN">0789722429</Code>          <Description>XML by Example</Description>          <Quantity>5</Quantity>          <Price>24.99</Price>       </Product>       <Product>          <Code type="ISBN">0789724308</Code>          <Description>Applied XML Solutions</Description>          <Quantity>10</Quantity>          <Price>42.50</Price>       </Product>    </Lines> </Order> 

Figure 5.4. The structure of the XML order is more readily apparent than its EDIFACT counterpart .

Although they convey the same information, the XML and EDIFACT orders are not strictly identical:

• In XML, the internal organization of the order is apparent. It is clear when looking at the document that product identifiers are included in order lines. Consequently, XML does not need qualifiers to specify the relationship between elements as EDIFACT does.

• Some codes are different. For example, the EDIFACT order relies on code AB to request an acknowledgement , whereas the XML order uses a confirm attribute with a Boolean ( true or false ). Likewise, the code IB translates into ISBN . Differences of this sort are very common when transforming XML to and from other formats.

• The XML document is significantly larger than the EDIFACT version. Again, EDIFACT was developed to minimize bandwidth because it was more expensive at the time.

• In the XML document, product lines include descriptions. In practice, this is very common when building transformations. The two data structures are often similar, but they are rarely identical. Our transformation must cope with these differences.

Our goal in the next sections is to convert one format into the other and vice versa.

Warning

The XML document includes product descriptions that have no equivalent in EDIFACT. This is not a technical limitation of EDIFACT; it is more of a cultural one.

Specifically, including product descriptions using segment IMD is possible. However, EDIFACT users tend to be conservative with bandwidth, so if the ISBN is enough to identify the product, why waste resources?

Leverage EDI Experience in XML

As explained , it is expected that business-to-business e-commerce on the Internet will be based on XML. So, if you move into that space, you will need to develop XML versions of commercial documents such as purchase orders, catalogs, packing lists, and more.

I strongly suggest that, to develop such documents, you start with an EDI basis. A lot of effort has gone into making sure the EDIFACT (or X12) documents are complete and usable. Don't reinvent the wheel.

The XML/EDI Group has been advocating precisely this approach since the early days.

Many proposals exist on how to best turn EDI into XML, but here is one that has been field- tested :

• Reverse-engineer EDI messages of interest in object-oriented models (for example, using UML). If possible, start with real implementations instead of the official standard.

• Use aggregation to express relationships between classes. This makes the structure of the original message visible.

• Simplify. The original EDI message is always too complex.

• Convert your model in XML ”for example, create an XML element for every class in the model.