Sounds like you have overcome some of the problems of using FTP but I would
recommend you use a POSIX checksum command not a byte count to determine if
a transfer is successful. It allows you to absolutely verify that the
source file and the target file are identical across virtually any platforms
or OSes. It is possible to have a garbled character or two in a
transmission that does not change the byte count.
Jim Divoky, EC Solutions
----- Original Message -----
From: "Mark Kusiak" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 4:18 PM
Subject: Re: EDI over the Internet
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/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
