Re: EDI over the Internet

Mon, 07 May 2001 13:17:36 -0700

Joe,
We transfer files in our back end using FTP and have a very eloquent solution.
We transfer a .DAT file and a .DONE file containing the byte count of the
data file after.
If the .DONE file, byte count does not agree with the .DAT file or the
.DONE file is not present, then the condition is trapped such that an
investigation can be commenced to determine the source of the issue.
We have been using this scheme for about three years with very good
hands free results. It virtually ensures that the whole file got there
in one piece. Our processes are set to test and trap the existence of
both as a condition to process as well as matching the byte count contained
in the .DONE file with the actual byte length of the .DAT file
I will give you that this is an in-house standard, but it would not be
a bad idea to use via the internet for the same purposes. It provides
simplicity with a virtually robust FTP environment that allows for trapping
the problems when they occur.
the object is that this file name for both are the same as in the
following.
somethingtoprocess.DAT
This file contains the data as meant for processing on the target system.
the data can be EDI, Proprietary formats, XML or what ever....
somethingtoprocess.DONE
Contains the information pertaining to the .DAT file above including a count of
the number of bytes transmitted across the connection as the first record in the file.
The net result is that the presence of the .DONE file indicates that the transfer of the
first file succeeded, because it is moved if the first FTP put succeeded. A match on the
byte count contained in the .DONE file and the actual length of the .DAT file ensures that
the total .DAT file made it to the target system. Both checks must be passed to process the
file.
Once the process has occurred, the files are archived in another directory for backup and this
removes them from being processed a second subsequent time by another later process.
As I stated in my opening remarks, this solution is very simple to accomplish. It virtually
eliminates the inherent problems with FTP.
Regards,
Mark
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 05, 2001 5:04 PM
To: [EMAIL PROTECTED]
Subject: Re: EDI over the Internet
The hardest part is writing the scripts to drive FTP *reliably*. For
example, depending on your FTP client, an rc=0 from the FTP command may
*not* mean that the transfer was successful. It may just mean that the FTP
client didn't trigger a dump. In the general case, the safest thing to do
is to is to programmatically examine the FTP output for the message that
indicates a successful transfer.
If you are doing an mput or an mget, in the case of a problem you have to
programmatically figure out which files were successfully transferred so
that you know where to restart.
When doing a get or mget, you have to figure out a way to avoid pulling the
same file twice on two different FTP sessions. One obvious way is to delete
the file from the source remote directory after a successful get.
You also need to watch out for what I call the "FTP partial file transfer
syndrome" . I.e., you have to take steps to ensure that the system on the
receiving end of the transfer does not process partially transferred files.
One way of doing this is to "put" the file to a temporary directory on the
remote end, and then to do an "FTP rename" to place the fully transferred
file into the actual final target directory. That way the receiving system
can be assured that everything that it sees in the ultimate target directory
is a complete file.
The GEIS FTP server, for example, is customized to handle the "partial file
transfer syndrome" in a special way. It does not assume that an incoming
file has been completely transferred until the sending FTP client issues a
subsequent command after the "put".
In terms of encryption, a problem with FTP is that there is no standard
method of dealing with encryption. Some options are:
- You can not worry about it. You'll probably get away with this. It's a
matter of judgement but I personally don't like "probably" over the public
Internet.
- Use any of a number of commercial FTP products that provide a customized
client and server that interact with encryption technology in order to
provide authentication, data privacy, detection of data alteration, and
non-repudiation. The one's that I am aware of work well. The problem with
this approach is that you have to convince your trading partner to install
the appropriate commercial client and/or server on their end.
- Here is one effort of the open source community to wrap FTP (among other
things) in SSL: http://www.rickk.com/sslwrap/. The "ssleay" SSL
impementation is orphan code, so I'd use it with OpenSSL: www.openssl.org.
- You can encrypt files before transfer using something like PGP, then
decrypt them again on the receiving end.
Because there is no standard way of using encryption with FTP, you may end
up using a multitude of approaches with your multitude of trading partners.
As with deciding on an EDI guideline, deciding on a secure FTP approach is
often driven by who "needs" the trading partner relationship more. You
would want to establish what your most preferred approach is, so that you
can recommend it when the trading partner does not have a preference.
As has been mentioned by others, most of the major VANs, at least, have some
sort of FTP connectivity offering. However, some of them may still require
that you use private IP networks rather than the public Internet, because of
the above-mentioned chaos regarding encryption using FTP.
--Joe
--
Joseph Kellett
Legendary Systems
[EMAIL PROTECTED]
> -----Original Message-----
> From: Electronic Data Interchange Issues
> [mailto:[EMAIL PROTECTED]]On Behalf Of Lois Prather
> Sent: Friday, May 04, 2001 2:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EDI over the Internet
>
>
> http://www.icc.net
>
> -----Original Message-----
> From: Electronic Data Interchange Issues
> [mailto:[EMAIL PROTECTED]]On Behalf Of Arthur Weiner
> Sent: Wednesday, May 02, 2001 2:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EDI over the Internet
>
>
> At my last company (I was Dir. IS) I used FTP to all VANs and
> dialup direct
> to Wal-Mart. We had very few problems over the four years
> that we used the
> internet. It was on an AS/400 using Harbinger EDI/400 v. 2.11
>
> ------------------------------------------
> Arthur Weiner
> (973) 625-0832
>
>
>
> > -----Original Message-----
> > From: Electronic Data Interchange Issues
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Richer, Robert
> > Sent: Wednesday, May 02, 2001 4:49 PM
> > To: [EMAIL PROTECTED]
> > Subject: EDI over the Internet
> >
> >
> > Bonjour everyone!
> >
> > I'm new to this list. So may be this question has already
> > been asked and if
> > so I'm sorry about that.
> > Feel free to email me directly if needed.
> >
> > I'm just curious to know if any of you are using the Internet to
> > send/receive EDI transactions.
> >
> > If so, can you let me know how you are doing it (software
> > used, are you
> > using encryption, any problem with it, recommendations, etc....)
> > I'm looking for a solution that will allow me to send
> transactions via
> > Internet for some customers but I still need some kind of
> > access to the
> > regular VANs for my trading partners that won't be able to
> > support EDI on
> > the Internet.
> >
> > Here is my actual setup...
> > * I'm currently using EDI*Windows 5.2.6 as the EDI s/w
> > * I'm running it on an NT Alpha (client/server).
> > * My communication s/w is Cleo
> >
> >
> > Any information will be appreciate,
> >
> > Thanks in advance,
> >
> >
> > Robert Richer
> > Coordonnateur Commerce Électronique
> > Electronic Commerce Coordinator
> > IPEX Inc.
> > Édifice du Port de Montréal / Port of Montreal Building
> > Aile 3, 1ier étage, Cité du Havre / Wing 3, 1st floor, Cite du Havre
> > Montréal, Qc / Montreal, Qc
> > H3C 3R5
> >
> > Tél.: (514) 861-7221 ext.: 233
> > 1-800-363-2620
> > Fax:(514) 861-4188
> > Internet : [EMAIL PROTECTED]
> > WWW: www.ipexinc.com
> >
> > To contact the list owner: mailto:[EMAIL PROTECTED]
> > Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
> >
> >
>
> ==============================================================
> =========
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> ==============================================================
> =========
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/

Reply via email to