David
That won't work as you migrate to different versions (as an example) of the
same transaction for the same trading partners, and I assume that sooner or
later we will have multiple versions of XML (any thought about how to handle
XML version control yet). Yes, you can add version to your list of items to
be included in your look-up table, but I would think that a simple indicator
in the header would be easier. And, there are other reasons why you might
send test data using the same version, release, even the same data may be
sent, one in test and one in production to the same sender/receiver pair, so
the look-up table becomes very complicated or does not work.
Not sure that the "T vs. P" is a VAN thing however. Remember that in the
beginning (gee all the way back to the early days of TDCC, I am dating
myself) we didn't use headers above the GS in EDI and us VANs moved the data
right along. Also, the first header, the BG/EG didn't have the test vs.
production indicator and we still move a lot of data using that header
today. So, it sure doesn't sound like a "goofy VAN problem" to me. But it
is in vogue to blame everything on a VAN.
We here at Kleinschmidt can route data to different receiving locations
based on lots of other items in the header besides the sender/receiver pair,
so that is not an issue with us and many other VANs. It doesn't even have
to be a "standard" header, you can define one if you like and we can take
that. And, as for maintaining that for our customers, we do. We have test
and production processes that go on all of the time for our customers.
However, both the sender and receiver must have something in place in their
software to handle test vs. production in order for this to work. The test
vs. production indicator is an easy way to do that and is handled very easy
in software as you know. Maybe it was a "goofy translation software
problem".
Sounds like we are starting all over again. I seem to remember something
from my history classes in high school about why we study history, so that
we don't repeat the mistakes of the past. Maybe high school was not a waste
after all.
Just wanted to get folks thinking about it and see if there was a solution
already in place.
Doug
-----Original Message-----
From: David RR Webber [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 19, 2000 9:35 AM
To: Doug Anderson
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]';
[EMAIL PROTECTED]
Subject: re: Test vs. Production
Message text written by Doug Anderson
>
Good Afternoon:
Today in EDI we have a test/production indicator in the header (ISA in ASC
X12, UNB in UN/EDIFACT) that allows someone to route the data to the
correct
system. Is there something similar in XML either in use today or on the
drawing board? We don't want to create something if this has already been
solved. We have a customer that will be moving some of their trading
partners into production and would prefer not to have to change receiver
ID's in order to differentiate between those trading partners in test vs.
those in production.
Thanks in advance.
Doug
<<<<<<<<<<<<<<<<<<<
I hate to say this but this is nothing to do with transactions - but
everything to
do with the goofy way VAN's worked in the past.
A local look-up table:
Cust ID, Trans ID, Status (Test / Prod )
is all you need to fix this! Then locally you can choose what type of
processing
you are doing. This also helps when some TP's are in test, others already
in
prod' - they can locally determine their own actions.
Notice you can also use this to switch dynamically
on the fly -regardless of what the actual transaction says!
The VAN's just never wanted to maintain this for you.
DW.
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
