Rich Nering asks some very good questions about this topic:
... It sounds so simple, there just has to be a technical catch
somewhere, right ?
There are many technical gotchas. Depending on how you choose to more your
data. Remember, you can move files using FTP, HTTP and SMTP/POP. These
catches tend to be server software and server configuration dependent
(maximum size of attachment). They all seem to be fine on files up to 10
megabytes. If you are transferring Gigabyte sized files, FTP would be the
optimal choice.
Scalability appears to be the biggest problem for many commercial products.
The problem is that once you start using IP for communication you get more
trading partners, sending and receiving more transactions. I would
encourage you to establish benchmark tests testing 10 times your current
volume.
What if our server is down ?
Generally, you would have backup mail or FTP servers. For our clients using
FTP as the primary transport mechanism, the general script says try site 1,
if not available try site 2.
Do we use FTP ? If so, what if the partner has a different flavor and
we can't connect ?
Standard FTP is fine, except for file naming problems. I would make sure I
avoided proprietary FTP protocols. You do not want to force your trading
partner to use a particular piece of FTP software. (Most of the proprietary
FTP solutions on the market also support standard FTP).
What kind of problems have people seen when moving away from the
mothership (VANS) such as resolution of the age ol' problem of " I sent
you a transaction on ... no you didn't ...."
Lost data is always an issue. The advantage of X12 based Edi is that one at
least has Functional acknowledgments to help track receipt of data. If you
look at the EDIINT specs for encrypted EDI over SMTP, they added a function
for delivery notification. Hence, you can get double notification. This
actually makes life better than it was previously, in that you can now react
to "negative" delivery information. In other words, in prior days when you
dumped the data on the Van, you had to go back and check if the information
was picked up by the trading partner, with EDI-INT you know right away
whether or not their server received the data.
However, if you are moving non-EDI data with non-standard protocols, then
you may have to wait a while for robust delivery notification mechanisms to
be in place.
Are there security setups that need to be done with every new partner
that wants to send or is it a one time setup of the server ?
If you wish to encrypt the data you exchange with your trading partners,
then you need to establish your mutual keys. This is a given. If your
trading partner wants you to penetrate their firewall, then yes, you need to
establish security. However, most folks moving data over the net, have set
up landing zones outside their firewalls.
Andy Clifford's note to look at
http://www.uc-council.org/e_commerce/ec_internet_mail_pilot_final_r.html
Was a great pointer. One of the benefits today is that there are standards
(AS1, AS2,...) emerging to help you accomplish your goal. Furthermore,
there are many products on the market which already support these standards.
Good Luck,
Dan Kazzaz
PaperFree Systems, Inc.
I
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 04, 2000 12:27 PM
To: [EMAIL PROTECTED]
Subject: EDI over Internet
At the risk of showing my technical ignorance, I must ask the following
question ! I've asked around my company but haven't got a real good
reading yet.
First some background. I have about 1,200 trading partners setup through
VANs and private dials to OEMs. We process about 140,000 transactions per
month. We are also growing (slowly) our connections with suppliers. I
want to open up other ways to send/receive EDI transactions (ANSI,EDIFACT)
using the Internet instead of VANs for those partners that want to
participate in such a path. I also want to be prepared to accept data
from other sources such as XML. All of these inputs will go, by various
translation methods, into my legacy EDI system which I use to distribute
transactions to my business units using an internal standard format.
My question is in two parts:
First, what is the general range of administration cost to support
partners sending data to an Internet server ? I'm not asking about the
cost of servers, firewalls, etc. Assume for this question that these
already exist and are paid for by the department that owns our website.
My question is specifically about how many people it takes so support the
setup and maintenance of the actual partner connections and movement of
data into backend legacy systems.
Second, If I start telling our partners that we can accept data over an
Internet IP connection, what types of problems can I expect to see - none,
some, alot... It sounds so simple, there just has to be a technical catch
somewhere, right ?
Things that pop into my head are:
What if our server is down ?
Do we use FTP ? If so, what if the partner has a different flavor and
we can't connect ?
What kind of problems have people seen when moving away from the
mothership (VANS) such as resolution of the age ol' problem of " I sent
you a transaction on ... no you didn't ...."
Are there security setups that need to be done with every new partner
that wants to send or is it a one time setup of the server ?
I ask these questions because I need to evaluate whether it is cost
beneficial to have an third party host a site that all partners connect to
or it is easier and cheaper to just let everyone drop data onto a server
connected to our website (with all the proper security bells and whistles
included). I don't know the costs on these hosted sites yet, but they
claim to give you the same capabilities as the VANs for store-and-forward
functions and also claim to shield the hub company from all the plethora of
different types of connections by providing one IP pipe into the hub. The
idea sounds good in some ways. I know I'll need to get data from the ANX,
Internet and probably other sources soon. It also looks like these hosted
sites can gather data from VANs so I can have one pipe into my legacy EDI
system instead of the various dials I have now.
Any opinions and information is greatly appreciated.
Regards,
Rich Nering
EDI System Manager
Parker Hannifin Corporation, Cleveland, Ohio
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at www.deja.com in bit.listserv.edi-L newsgroup. Use powersearch.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at www.deja.com in bit.listserv.edi-L newsgroup. Use powersearch.
