Data is extracted from your application data base, using application integration software, typically into
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.
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.
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
- 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.
VAN communications script
executes the communications connection script and deposits data into your
- 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.
- 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.
- 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
- The VAN
transfers data based upon the destination
information in the envelope.
- 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.
- 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
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.
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
- 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
- Some VANs also serve as
ASP, or have an affiliation with
an ASP that provides a web application for small-to-medium trading partners.
- The gateway monitors all transactions for which a receipt
acknowledgment is expected.
- 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.
- 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."
- 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