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) - How It Works:  Run Time, Outbound
Special Notes:    

Data Extraction from Application
Transmit to Gateway
Identify File
   Map and Validate or Pass-thru
   Envelope for Transmission
Execute VAN Communications Script
Log Transmission Data
Van Data Transfer
Monitor for Receipt Acknowledgment
Back to Implementation Option 1 Index


  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.


Last updated 02 March 2003