Figure 1: This chart explains how EDI documents are sent and received.

In this example, data from your ERP application is fed to the EDI translator application, which converts the data into an acceptable EDI document. This document is then sent through the use of a communications package to a third-party VAN, which sends the data to the trading partner. If the trading partner uses a different VAN than the VAN you use, the data is sent through an interconnect to the trading partner's VAN. In some cases, multiple interconnects may be required. The trading partner then retrieves the document from their VAN and sends out an acknowledgement that the document was received, which goes through the same process to make its way back to you. Some trading partners eliminate the need for the VAN by allowing other trading partners to communicate with them directly. While this does eliminate the need for a VAN, the trading partner must then have the infrastructure in place to support this. Figure 2 shows how documents flow in this scenario.


Figure 2: This flow represents a direct connection to a trading partner.

While this scenario eliminates the middleman, it also can require special hardware and software for each trading partner you communicate with.

Getting out of the VAN

You usually communicate with your VAN through a dial-up connection and pay the VAN for every character sent and received. In the case of interconnects, mentioned earlier, additional costs can be incurred. These costs can add up. When you consider that today most companies have some connection to the Internet--be it T1, DSL, or even dial-up--the idea of paying for a third-party network to transmit data doesn't seem to make much sense. That's where EDI INT comes in. EDI INT is the means by which EDI documents can be encrypted and sent through the public Internet, effectively eliminating the VAN (and the VAN charges). With EDI INT, you replace the communications package portion of the example above with a package that is compliant with the EDI INT standards as defined by the Internet Engineering Task Force (IETF). The IETF's EDI INT Web site is a great resource for information on the EDI INT standards. Figure 3 shows the flow of documents using EDI INT.

Figure 3: This flow represents the path of EDI documents when using EDI INT.

But cost savings aren't the only reason to switch. Many big retailers, including Wal-Mart and Lowe's, are mandating their trading partners to make the move to EDI INT. Your first thought might be "Why not just email the EDI documents to the trading partner?" After all, SMTP email is an existing means for sending and receiving data. The problem is security. Many times EDI documents contain data that is confidential between trading partners, such as pricing information, which could be compromised if sent through the Internet without some level of encryption. There are currently two specifications that are approved for EDI INT:

Applicability Statement 1 (AS1) uses Simple Mail Transfer Protocol (SMTP) as the means by which EDI documents are transmitted and received.

Applicability Statement 2 (AS2) is an extension of the AS1 standards that also allows Hypertext Transfer Protocol (HTTP) to be used as a means of transportation for data. It's not a replacement for AS1 but more an extension of the AS1 standard.

By using either of these specifications, it's possible to exchange data other than EDI documents (XML files, etc.) with a trading partner. AS1 data is secured through the use of Secure Multipurpose Internet Mail Extensions (S/MIME). S/MIME was originally developed by RSA Data Security, Inc. and is based on the PKCS #7 data format for messages and the X.509v3 format for certificates. PKCS #7, in turn, is based on the ASN.1 DER format for data. AS2 data secured through the use of Hypertext Transfer Protocol Secure (HTTPS) Secure Socket Layer (SSL). You may question why you would want to send the data via HTTP protocol in place of SMTP. Consider the fact that when you send an SMTP email message, the data is transferred from your PC, to a mail server, to another mail server, and then to a final destination. In some cases, there can be even more forwarding of the data to get it to the final recipient. This is one drawback of using SMTP to transmit EDI data when you consider that EDI documents are often time-sensitive and need to arrive as soon as possible. If any portion of this loop is down, the data won't reach its final destination in a timely fashion. Figure 4 shows what I'm talking about.

Figure 4: This flow represents the path of a document through SMTP.

The HTTP option available as part of the AS2 specification avoids this drawback because the data is sent directly from an AS2 "Web Server" to another. This means that as long as both AS2 servers are up, the data will get through. Figure 5 shows how much simpler the path of the document is through HTTP.

Figure 5: The flow of a document via HTTP is much simpler.

There can still be an issue, however, if one of the AS2 servers is down. In that case, you must have some sort of backup plan in place to handle transferring the data. This usually involves the use of a VAN. In most cases, EDI INT packages will require you to export your EDI documents to a flat file from your EDI translator package. This flat file is then read into the EDI INT package and sent to the required trading partner through either SMTP or HTTP, depending on whether you are using AS1 or AS2.

Getting from EDI to EDI INT

Cost savings alone can make EDI INT very attractive. When you add in the possibility of a mandate from a major customer, it can become a necessity. So at this point, you're probably wondering what it takes to get EDI INT in place. Depending on the requirements of your trading partner, you may be able to simply have your VAN prepare and send the EDI document through EDI INT. Using this scenario, of course, does not eliminate the VAN charges. On the other hand, this method is probably the simplest to accomplish and can be useful if you are unable to comply with a trading partner mandate within the allotted time. The other option is to install an EDI INT package. The number of software vendors with EDI INT offerings is increasing daily. If you go this route, you'll want to be sure that you select a package that has been certified by The Drummond Group, which is responsible for the testing and certification of all EDI INT software. Figure 6 contains a list of the packages currently certified as AS2-compliant by the Drummond Group.

Figure 5: Software packages currently certified per the AS2 specification.

The costs of any of these packages can depend greatly on the number of trading partners with which you intend to use the package, ranging anywhere from a few hundred to tens of thousands of dollars. It's also important to remember that you can only switch to EDI INT with trading partners who can also support EDI INT. In some cases, software vendors will offer the software to you at "no charge" for use with a specific trading partner. This is the case with Wal-Mart's announcement in mid-September 2002 that they would be mandating their trading partners to move to an AS2-compliant EDI INT solution. This announcement sent many of its trading partners and many EDI INT software vendors scrambling to figure out which way they would go. Many of the software vendors mentioned earlier will allow you to use their solution for AS2 connections to Wal-Mart "at no charge." Any additional trading partners, however, must be paid for separately. As with most software, annual maintenance fees will add to the costs of implementing any EDI INT solution. In most cases, however, the return on investment can be significant once the VAN charges have been eliminated.

Not IF but WHEN

The real question, when it comes to EDI INT may not be if you should consider it, but is more likely to be when a major customer will require that you communicate via EDI INT. In the not too distant future, VANs will become a thing of the past, in turn reducing overhead costs for everyone in the supply chain.

Mike Faust is the MIS manager for The Lehigh Group in Macungie, Pennsylvania, and is the author of The iSeries and AS/400 Programmer's Guide to Cool Things. Mike has over 15 years' of programming and systems experience. You can contact Mike at This email address is being protected from spambots. You need JavaScript enabled to view it..