The Internet has opened up many ways for companies to send and
receive EDI files. Below
are short descriptions of some them and how they are supported by the Framework EDI
Dial-up transmission was the main method of sending and receiving EDI files
before the high-speed Internet became popular. Communications would
traditionally be over
dedicated lines directly between trading partners or through a VAN (Value-Added-Network).
But not only was this transmission slow, it was cumbersome and expensive, because
several modems and lines were required to support multiple trading
partners. (Please note that the Framework EDI component has no dial-up
SMTP or email
Email over the Internet provides for a less expensive and simple means of
sending and receiving EDI files. However, EDI files are less secure if
sent by email over the Internet, and the size of an account's mailbox limits the
size of EDI files one can send. Also, email generally requires a user
to retrieve an attached message, which is not in accordance to the EDI
definition of having no human intermediary.
Below is an example of how one can use the
Framework EDI component to send an EDI file by SMTP:
Send by SMTP
Set oTransport = oTransports.CreateTransport
With FTP communication servers becoming affordable, and easier to set up and
operate, the FTP protocol has become one of the popular ways of
sending and receiving files. Trading partners can easily set up their own
FTP server and have their EDI files uploaded directly to them. However, with
this protocol, files can only be sent/received into folders (directories) where
they wait to get polled for processing, which can be
taxing to a system depending on the polling interval.
Below is an example of how
one can send and receive EDI files by FTP with the Framework EDI component:
- Download an example program in VB6 that sends an EDI
file by FTP.
- Download an example program in VB6 that gets an EDI file by FTP.
HTTP or HTTPS
With almost every company having a Web Site and a Web Server, the HTTP server is
the most available of all communication servers, but yet only a handful of
companies take advantage of this powerful and already available resource for sending
and receiving EDI
files. Just like the FTP server, the HTTP server is inexpensive and is easy
to set up; but the major advantage HTTP has over FTP, is that the HTTP protocol
sends/receives files directly to an application or "destination
application". This makes it possible to have the destination
application run a process immediately once a file is received. One
such process can be to trigger an alert or even to acknowledge the received
Below are example programs of a HTPP client and
a destination application to demonstrate how one can send and receive EDI files
by HTTPS, and get an
acknowledgment back immediately.
- An example VB6 program that sends an EDI X12 file by HTTPS to a destination application
on a server, and synchronously
receives a TA1 acknowledgment.
- An example of a destination application written in ASP VB .NET. This
program receives EDI files, and then generates
and sends a TA1 file acknowledgment back to the sender synchronously .
EDIINT AS2 is basically a more sophisticated version of the above HTTP file exchange,
but more complicated because of the extra standards it introduces over the HTTP
protocol responses, and message format wrapped over the EDI standard. The AS2 protocol is not
specific to EDI files only, so another acknowledgment called the MDN
is used to acknowledge receipt of AS2 files. The extra layers in AS2 that
are not related to EDI make this protocol cumbersome and difficult to implement,
and can become expensive if certification and support maintenance are required.
Below is an example program (with source
code) of an AS2
Server using Framework EDI .NET hybrid component:
Before exchanging secured AS2 messages,
trading companies have to generate their own public and private keys.
Technically, these keys are held in a key container in the O/S. The
private key remains in the key container, but the public key can be exported to
a certificate file so that it can be exchanged between trading companies.
Public keys are used for encrypting each other's EDI files, while the private
key is used for decrypting. Below are sample programs in VB6 to
show how one can use the component to create and import security
- Creates a key container, certificate store and a certificate file.
Q. Is it possible to send and
receive AS2 messages with only the Framework EDI Professional License (without using the
A. Yes, it is possible to send and receive AS2 messages with the Framework
License. However, it does not have AS2 development support because utilities such as the eSecurity Console and ISAPI
Extension Console are not available in the Professional License, which
would facilitate AS2 development.
Q. Can the security
certificates created by Framework EDI be used in a production environment?
A. We don't recommend it because these security certificates are not
trusted, or have not been specifically assigned to you, which means that it
could be possible for someone else to create the same certificate you may have
created for yourself. Creating your own certificates (not trusted) should
be limited to testing environments only.
Q. Is the Framework EDI AS2
functionality certified by Drummond?
A. No, we have not sought for Drummond certification. The
functionalities in our component have not been limited or restricted to AS2
making it possible to create other message standards exchanged over HTTP (such
as NAESB) with the
Framework EDI component.
The example programs provided in this
article are for illustration only, and have no purpose other than to show
software developers how to use the Framework EDI component in programming
languages to process EDI files. If you have any questions, don't hesitate
to contact us: