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/
