Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
Implementation Options | Technical Basics | Internet Commerce Model  | Architecture |
Implementation (Technology) Options

Implementation Option 1 - "Traditional" EDI via a VAN  
 
Special Notes:  

 
Introduction
Business User View
History
When to Use this Implementation Option
What You Need for this Implementation Option
How it Works - Design Time (Initial Implementation, New Partner, New Business Process/New Business Document)
How it Works - Run Time, Outbound
How it Works - Run Time, Inbound
In Order Model 1 Section:
UML Activity Diagram - Purchase Order Example
 

Introduction

In "Traditional" EDI via a VAN, trading partners connect to a VAN's private network to send and receive business data formatted in the X12 or EDIFACT standard.  The EDI system supports high volumes and is integrated with back-end applications.


Business User View

Compare with Basic Implementation Options User View.

 


History

EDI originated the 1960's as an intra-industry (industry vertical) effort.  By the 1970's more and more industry verticals were involved, and work began for national and international standards.  The goal was to create standards that:

Although today there are many syntaxes for traditional (pre-XML) EDI, only two are widely recognized: X12 and EDIFACT.

The original EDI exchanges in the 1960s were handled with point-to-point direct connections.  Early adopters of EDI soon realized that maintaining lots of point-to-point connections with many trading partners using many computing platforms was very costly. ut this didn't last long.   The first Value Added Network was born when several industries in the early 1970s sponsored a shared EDI system and turned it over to a third party network.

Historically, VANs managed private networks that supported the exchange of standards like X12 and EDIFACT.  In general, partners who wanted to exchange documents used the same version of the same standard, e.g. X12 version 4010 or EDIFACT version D.97A.  This was not due to technical limitations but rather was to avoid maintaining many costly translation maps.  Additionally, VANs have always provided mapping services (translation/conversion/parsing) services and other gateway services, but most companies have historically preferred to perform their own mapping services in house, again due to the historical cost models for outsourced vs. insourced services.

The early adopters of EDI all considered back-end integration to be a fundamental precept in EDI.  Most EDI implementors included back-end integration in the project.  Some recipients, however, just implemented Rip-and-Read, or Rip-and-Read Plus.

Up until the early 1990's, trading partners needed mainframe computers or minicomputers to run EDI gateway software.  In the early 1990's, PC-based front end EDI software became available at a fraction of the cost of the mainframe and minicomputer software options.

Furthermore, the emergence of Internet technologies has been providing access to an open world-wide communications network, offering universal connectivity.   One of the reasons given for moving to new data content standards is that by "replacing EDI" you can "avoid using VANs".  The cost of EDI is attributed to the "high cost of VANs".  In fact, EDI can be exchanged across the internet.  80% of the cost of EDI is back-end integration, which still has to be done whether you are using a traditional EDI standard (X12 or EDIFACT) or one of the newer XML data content standards (such as RosettaNet, OAG, UBL).

This page describes the "traditional" or historical methods of connecting to VANs a- how it was done in ancient times before the internet was available to those outside the government and university communities and before digital communications technology existed.  Because this is pre-internet, not all the architecture components are described on the EIDX Internet Commerce Model, which is forward looking.


When to Use This Implementation Option

Web vs. EDI or XML/EDI - General Guidelines:

The partner is a candidate for using a web application if:

The supplier is a candidate for EDI or XML/EDI if:


Options for Connecting with Partners

Yesterday

Fifteen years ago, the following was mostly true:

In the very early 1990's client solutions for the X12 and EDIFACT standards became widely available.   With a client PC or Mac, a modem and software costing about $1500 USD, a company could send or receive any X12 or EDIFACT message in any version.  This did not include back-end integration.  Many large companies acquired these low cost solutions to use as a bridge while they developed a robust gateway and full back-end integration.

Today

In fact, anyone who is still has "Traditional" via "Traditional" VAN in place has these options available today:

 


What you Need

All the items listed in Basics You Need for Implementation are required for the "traditional" or legacy EDI, with exceptions noted below.

  1. Application Interface software
  1. Gateway - The gateway specifically requires functionality and dictionaries to support the legacy EDI standards, X12 and/or EDIFACT.  Multinational companies may support both standards, a U.S.-based company may support only X12, and a non-U.S. company may support only EDIFACT.  The gateway also requires functionality for "legacy" VAN communications methods.
  1. Network Service Provider -Because the internet was not secure and widely available until recently, and point-to-point network connections were expensive to support, legacy EDI has used  Value-Added Network (VAN) services for over 30 years.
  1. Hardware - Digital technology has only recently become available; legacy communications with EDI VANs uses Analag Modem(s) and telephone lines.  Most connectivity is dial-up, with direct-connection leased-lines used only by the largest companies.

How it Works - Design Time

Initial Implementation

All the items listed in Basics of Implementations:  Initial eBusiness Implementation are required for the "traditional" or legacy EDI, with exceptions noted below.

The initial implementation of an EDI gateway and initial back-end integration takes from 4 weeks to 6 months.

  1.  The first step, of course is to identify potential partners. In legacy EDI, this is all done manually.  This has nothing to do with the legacy EDI standards - this type of technology is very recent.
  1. The trading partner agreement process is all manual in legacy EDI.  Just as with partner discovery, this is because the automated TPA technology has only recently been developed.
  1. Assess requirements and develop implementation plan
  1. EIDX and EDIFACT began producing business models for computing and electronics in the late 1980's.
    1. The ability to specify business processes in a standard, machine-readable format is a new technology not previously available to the legacy EDI environment. 
  1. X12 and EDIFACT are the only business content standards used in legacy EDI.
  1. For legacy EDI in the electronics and computing industry, EDIFICE guidelines are used for EDIFACT, and EIDX guidelines for X12.
  1. In the legacy EDI environment, all 3rd party network providers of inter-company data communications were referred to as VANs.
  1. User interfaces in legacy EDI were not standardized.  Again, this was because interface standards had not been created; this was not a problem inherent in EDI.
  1. The buyer's existing back-end integration in legacy EDI was proprietary.  As with interfaces, this was not a problem inherent in EDI but was was because interface standards had not been created.
  1. In EDI for the EIDX/EDIFICE constituents, the usual practice for identifying partners is to use either DUNS or telephone numbers to identify partners.  The use of a qualifier makes each identity unique.  The use of proprietary identifiers is the norm for identifying locations.  Concatenating a partner identifier with each proprietary ID value ensures uniqueness.
  1. In legacy EDI for the EIDX/EDIFICE constituents, the usual practice is for the buyer's proprietary product identification to be used.
  1. Evaluate, select and implement gateway components.
  1. For ASC X12, implementing a gateway also means implementing Service Segments and Transactions, including the Functional Acknowledgment.
  1. Digital communications and the internet were not widely available until recently.  Legacy EDI messaging used a variety of communications, all non-internet, mostly dialup (with some direct-line connections), and a variety of requirements for enveloping messages.  However, each individual company only had to deal with one enveloping protocol and one connection method - to and from the VAN.
For the remaining implementation steps, legacy EDI does not have any differences than what is presented in the Basics of Implementations:  Initial eBusiness Implementation .

 


New Trading Partners and New Business Processes

All steps in the Basics of Implementations:  New Trading Partner implementations and Basics of Implementations:  New Business Process/New Business Document implementations apply to legacy EDI, except, of course, with the differences mentioned above.  In summary, the differences are:


How it Works - Run Time, Outbound

  1. Data is extracted from your application data base, using application integration software, typically into an interface file, usually a proprietary, flat-file format.  Some applications extract data into one or more standard formats.  The file must contain some identifier that the gateway will use to know how to process the file.
  1. If the application and the gateway are on different machines, an internal communications network is used to transmit the application data file to the gateway.
  1. The gateway uses the identifier in the application file to retrieve information about what to do with the application file.
  • Whether the file should be pass-thru or mapped into another format.  The most typical case is that the interface file is translated into the X12 or EDIFACT standard.
  • How the file should be enveloped, including how to identify the sender, the receiver, the data content standard and version, the type of message contained in the file, and assigning control numbers.  In traditional EDI via a VAN, the X12.5 protocol specifies how to envelope an X12 transaction, and ISO9735 specifies how to envelope an EDIFACT message.
  • How the file should be transmitted and what network should be used.
  1. The VAN communications script executes the communications connection script and deposits data into your VAN mailbox.
    1. The connection is a secure connection to the VAN's private network and the VAN verifies your identity and entitlement to services, and ensures that all security requirements are met for privacy, authentication, data integrity and non-repudiation.
  1. The gateway logs information about the transaction, including date and time sent.  If a receipt acknowledgment (X12 997 or EDIFACT CONTRL message) is expected from the recipient, the gateway sets a status flag so indicating, time the transmission was sent, and a time when a receipt acknowledgment is expected, based on a parameter set during implementation that indicates that a receipt acknowledgment is expected within n hours of the time of transmission.
    1. If no receipt acknowledgement (997/CONTRL) is expected, the transaction is "closed" as far as the gateway is concerned.  This has no relationship to the status of the business information in the back-end systems; it is merely the status of the transmission.
  1. The VAN transfers data based upon the destination information in the envelope.
    1. Your trading partner may not be using the same technology or service provider.  Any VAN that wants to stay in business today can support interconnections with other VANS and ISPs, re-mapping of data, and a variety of methods for getting data from you to your trading partners.  This allows your trading partners to implement low-cost technologies, or change technologies, or change service providers without you having to make changes at your end.
      1. Your trading partner may have a service provider make changes or do re-mapping without your knowing it.  Ideally, though, your trading partner should notify you of these kinds of changes, and provide information on how they are ensuring that there's no loss of data integrity due to the change.
    2. If the trading partner is also using the same VAN, the VAN just transfers the data from your mailbox to the partner's VAN mailbox.
    3. If the trading partner is using another VAN, and your VAN can interconnect with your partner's VAN, your VAN transfers the data to your partner's VAN.
    4. If the the trading partner is receiving traditional EDI files via the internet, your VAN may have a direct connection established with the trading partner, or an interconnection established with your trading partner's ISP.
    5. Some VANs also serve as ASP, or have an affiliation with an ASP that provides a web application for small-to-medium trading partners.
  1. The gateway monitors all transactions for which a receipt acknowledgment is expected. 
    1. If a receipt acknowledgement (997/CONTRL) is received within the configured amount of time, the transaction is "closed" as far as the gateway is concerned.  This has no relationship to the status of the business information in the back-end systems; it is merely the status of the transmission.
    2. If a receipt acknowledgment is not received within the configured amount of time, an exception occurs.  In legacy EDI, such an exception requires manual intervention.   After contacting the recipient, it is determined that either the transaction in question needs to be resent (this is done manually) or that the recipient successfully received the transaction but their system failed to successfully generate and send a receipt acknowledgment).  In the latter case, either the recipient tries to resend the receipt acknowledgment, or requests that the send manually set the transmission status to "closed."
      1. On average, Receipt acknowledgments are late for less than .1% of all transmissions send, and of those, less than 1% of failures were because the sent data was not received.  Most overdue receipt acknowledgments are due to the receipt acknowledgment itself failing.
 

How it Works - Run-Time, Inbound

  1. Your partners transmit data to your VAN, either directly, or by using a VAN that interconnects to your VAN.
    1. The VAN verifies the identity of the sender and their entitlement to services, and ensures that all security requirements are met for privacy, authentication, data integrity and non-repudiation.
    2. The trading partner may use the VANs translation service, whereby the partner sends data in a proprietary format, and the VAN translates the data into the EDI standard that you use.
  2. The VAN communications script deposits data into your VAN mailbox.
  1. The gateway uses the identifier in the EDI file to verify that it is from a valid partner entitled to trade electronically, and to retrieve information about what to do with the EDI file.
  1. How the received transaction should be validated.  Generally, this is related to whether the file should be pass-thru or mapped into another format.  The most typical case is that an X12 or EDIFACT file is translated into a proprietary format.
  1. There may be three levels of validation.   One is a compliance check against the standard's own dictionary.  The second occurs during mapping, where some business rules not contained in the standard are encoded.  The third level of validation occurs in the back-end system, where the majority of the business rules are encoded.
  1. How the file should be enveloped for the internal application, including how to identify the sender, the type of message contained in the file, and the internal destination computer and application.
  2. Whether a receipt acknowledgment (X12 997 or EDIFACT CONTRL message) should be sent to the trading partner.
    1. The receipt acknowledgment indicates what was received , and may indicate whether or not the transaction passed validation against the standard.  It does not indicate whether the transaction passed the mapping validation or the back-end validation.  The latter two validation steps result in exceptions that must be communicated manually.  For X12, some companies use the 824 to communicate the results of the latter two validation steps, but this is not used by EIDX.
  1. If required, the gateway connects to the VAN and transmits the receipt acknowledgment.
  1. If the application and the gateway are on different machines, an internal communications network is used to transmit the application data file from the gateway to the application computer.
  1. The application receives and processes the data.  The processing can be anything from just storing the data in the application for reporting to updating data bases and triggering other applications processes.

 

Last updated 02 March 2003