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, Inbound
 
Special Notes:    

 
Van Data Transfer
Identify File
   Map or Pass-thru
   Validate
   Envelope for Internal Transmission
   Generate Receipt Acknowledgment
Execute VAN Communications Script
Log Transmission Data
Internal Data Transfer
Processing Into Back-end Application
Back to Implementation Option 1 Index

 

  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.  For more details on error and exception handling, see Generic Model 1- Generic Request/Response Transmission Tracking and Error Handling.
  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. The gateway logs information about the received transaction, including date and time received, and whether or not the transaction passed validation, and whether or not a  receipt acknowledgment (X12 997 or EDIFACT CONTRL message) was sent.
    1. If no receipt acknowledgement (997/CONTRL) is expected by the transaction sender, 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. 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