Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]

[Tim McGrath <tmcgrath@tedis.com.au>]

Maybe another way to consider this situation is that, every vertical, region,
business-type, business size, at any moment in time, each operate across various
mixes of these 'contexts'.   businesses are dynamic and fluid structures.  this
i why current EDI standards have these increasing numbers of message
implementation guidelines, and all the inherent non-standard features,you
describe.  I too, once thought that if my trading partner supported X12 855 then
I can just send my version of an 855 to him.  Makes you wonder what a standard
is, doesn't it?

There is not, and i suspect never will be, the universal Invoice or Purchase
Order - in whatever syntax you wish to name.  This is not simply because the
Airline EDI standards people think and operate differently from everyone else.
In some contexts, they really are different.  Traditionally, EDI standards
bodies have proudly stood by their vertical 'business focus' groups.  There has
been less attention to an 'information systems focus' - that is, the analysis of
the common data models and processes.  I believe, this is one of the major
achievements of ebXML - it gave voice to those who have been struggling with
this problem.

For example, in such a situation, rather than establish and enforce a fixed
structure, an alternative strategy is to define the framework for defining data
to be exchanged.  If this is consistent and unambiguous, then this information
can drive the automated exchnage of whatever data the parties involved require.
Remember, the names "Purchase Order", "Invoice" are arbitrary titles to bunches
of data that support business processes.

As you say, ebXML has not achieved this state yet, but at least it isn't
avoiding the real problem.

What is more, it is an open forum that has enticed people such as yourself , to
comment and participate in developing this new paradigm.


Abid Farooqui wrote:

> Thanks for the answers Chris. I am not directly into the EDI world much, I
> am a Java developer but I do work with a lot of people using EDI tools like
> DI for doing Maps and so on.
> One problem that nagged me about EDIFACT was that even though it is a
> standard what was quite annoying and what made it much more complex than it
> ever needed to be is the fact that each of the vertical markets can
> basically come up with their own version of an 855 and so on. So many fields
> are optional making it even more complex. I am not sure, may be it is my
> strict upbringing or something (hope my mom never reads this:)) but giving
> so much leeway really gets away from the point of being a standard. With
> such complexity you give rise to complex programming tasks making EDI or
> ebXML platforms rise way higher in price than they otherwise would be and
> make so many people so specialized in one area that their whole career is
> based on it. For instance there are EDI people who are just experts in the
> Airline industry and so on.
> If the standard was more like a standard (more stringent) then there could
> be say just one and only one version of a PO and it would be easy to parse
> it, reducing cost and complexity a hundread fold. It seems like ebXML has
> not achieved that state yet either. May be we are just making jobs and
> careers for ourselves in the industry and not really solving business
> problems. In my opinion there is no reason that if enough thought is put
> into a standard that anything should be left up to the vertical markets to
> decide.
> Sincerely,
> Abid Farooqui
>
> ----- Original Message -----
> From: "christopher ferris" <chris.ferris@east.sun.com>
> To: "Abid Farooqui" <farooqui@tampabay.rr.com>
> Cc: <ebxml-dev@lists.ebxml.org>
> Sent: Monday, June 04, 2001 4:46 PM
> Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]
>
> > Abid,
> >
> > Please see below.
> >
> > Cheers,
> >
> > Chris
> >
> > Abid Farooqui wrote:
> > >
> > > Dear James,
> > > So let me understand this correctly.
> > > As far as I can make out from your kind answers below what seems to be
> the case is
> > > that :
> > > 1) ebXML can be used as a messaging mechanism to deliver traditional EDI
> to
> > > traditional EDI engines
> >
> > Yes, it can.
> >
> > > 2) Now you mention 2 problems:
> > > "First, it must correctly interpret the element that identifies the
> schema
> > > (such as X12) in which the payload documents are encoded, so it can send
> > > that data stream to something that can interpret it.  (Like your EDI
> engine.)"
> > > My question to that is : Doesn't ebXML messaging has in it some
> indicator that
> > > describes what kind of data it is and if not ... why?
> >
> > Yes, it does. This is the purpose of the Manifest. Of course, there are
> other
> > elements of the ebXML SOAP extension headers that the message service can
> > use for purposes of internal dispatching of messages to the appropriate
> handler
> > application. These include the CPAId, Service and Action elements. The
> CPAId
> > can be used to identify a CPA (whether a true CPA document or an implied
> or
> > logical "agreement" between the parties that specifies what messages will
> > be exchanged, etc.). The Service and Action elements can be used for
> internal
> > dispatching as well. Again, ebXML MSH places no specific constraints on
> > how these elements are (or are not) used in any given implementation.
> >
> > >
> > > "Second, it must correctly apply the ebXML business signals so that it
> can
> > > read and process the simple business-rule context of that payload -- Is
> > > this a response?  A request?  To what?  Is it logically dependent on or
> > > conditioned on another message already received, or to come?  Is this
> > > binding?  Does it conform to whatever rules for acknowledgement,
> encryption
> > > or signature are invoked?"
> >
> > The business signals referred to here are those that are defined in terms
> > of an ebXML business process. The business signals are low-level messages
> > that parties exchange to signify things such as:
> > - I've received your message
> > - I've pre-processed your message and it passed the preliminary
> > edits
> > - ...
> >
> > The ebXML Business Process Specification Schema specification describes
> these
> > in more detail. Business signals may, or may not be necessary. This is
> clearly
> > the realm of the "owner" of a business process to determine. Typically,
> this
> > would be the purview of a vertical standards body such as OTA, RosettaNet,
> OAG, etc
> > or a horizontal standards body such as X12 or EDIFACT, etc.
> >
> > > Isn't this what an ebXML server would do anyway? I think these are
> basically
> > > requirements for an ebXML platform, regardless of EDI payload or any
> other payload.
> > > Am I correct?
> >
> > Basically, yes.
> >
> > >
> > > Thanks
> > > Sincerely,
> > > Abid Farooqui
> > >
> > > James Bryce Clark wrote:
> > >
> > > > At 11:17 AM 6/4/01, you wrote:
> > > >
> > > > >Date: Mon, 04 Jun 2001 14:16:14 -0400
> > > > >From: Abid Farooqui <farooqui@tampabay.rr.com>
> > > > >Subject: Re: Example Scenarios Used Within the Aerospace Industry
> > > > >
> > > > >Isn't it true that ebXML messaging can be used to deliver traditional
> EDI
> > > > >payloads as well.
> > > >
> > > > Yes indeed.
> > > >
> > > > >Probably there has to be ways of delivering that payload to
> > > > >the EDI mapping engine like DI or GenTran but ebXML messaging could
> be used as
> > > > >the transport correct?
> > > >
> > > > Once past transport, the receiver's business service interface has,
> broadly
> > > > speaking, two problems.
> > > >
> > > > First, it must correctly interpret the element that identifies the
> schema
> > > > (such as X12) in which the payload documents are encoded, so it can
> send
> > > > that data stream to something that can interpret it.  (Like your EDI
> engine.)
> > > >
> > > > Second, it must correctly apply the ebXML business signals so that it
> can
> > > > read and process the simple business-rule context of that payload --
> Is
> > > > this a response?  A request?  To what?  Is it logically dependent on
> or
> > > > conditioned on another message already received, or to come?  Is this
> > > > binding?  Does it conform to whatever rules for acknowledgement,
> encryption
> > > > or signature are invoked?
> > > >
> > > > >I am new to ebXML so feel free to correct me.
> > > > >I believe that changes from large EDI users to adapt ebXML will be
> slow
> > > > >but they
> > > > >have to be made because there is a very good business case to do
> that.
> > > >
> > > > The ebXML business process group spent a lot of time working closely
> with
> > > > the X12, EDIFACT and RosettaNet communities precisely to preserve the
> > > > upgrade path you describe.
> > > >
> > > > Best regards
> > > >
> > > > James Bryce Clark
> > > > McLure Moynihan Inc.
> > > > 818 597 9475     jamie.clark@mmiec.com

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142