ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: CPA composition from multi-role CPPs


Duane,

	I am confused by your example:
If CompanyA in the CPP declares that is able to accept an Order.XML and
produce and OrderResponse.XML, and CompanyB accepts this by "agreeing"
with a CPA, then the format for exchaning data will be order.xml and
orderResponse.XML.
Which of the two who does not manage this natively would need a
transformation.

As in a previous comments, I actually believe that in reality each
internal legacy would not have any "XML format" to manage the legacy data
but would only have some "record layout" or some class. In this case a
logical transformation would be required on both sides.

Best regards and enjoy the weekend

/Stefano

 -----Original Message-----
 From: Duane Nickull [mailto:duane@xmlglobal.com]
 Sent: 19 January 2001 22:52
 To: Martin W Sachs
 Cc: Moberg, Dale; 'christopher ferris'; ebxml-tp@lists.ebxml.org
 Subject: Re: CPA composition from multi-role CPPs


....
....
...

 This was a question that the TA team wrestled with for a long time.  We
 originally had an idea that it could be done at either end however this
 was revised to reflect a possible scenario.

 Let's envision two parties (Company "A" and Company "B") as per the
 documents' example.  Comany "B" requests Company "A's" CPP and find, via
 the Buinsess Process document,  that they require an xCBL 3.0  purchase
 Order document (Order.xml) and they will send back a format called
 "OrderResponse.xml" as an official acceptance of the order.xml.  Company
 "A", who states this in their CPP, fully understands what it is they
 require,  but have no idea what other data formats other trading
 partners may have.  Accordingly,  they have no idea whether or not they
 are capable of performing data transformations on that data.

 Company "B", who now has the data format required by Company "A", can
 make a determination about whether or not they can transform the data
 from their format (for example say a cXML "PurchaseOrderRequest.xml"
 format) into the format required by Company "A".  If they decide yes
 they can, they can transform it and send it accross.  If not,  they
 chose another trading partner.

 Now - let's examine what can happen if they could send it accross
 without it being transformed.  Company "B" sends it and Company "A" now
 has the burden of performing the transformation.  This possibly takes
 more time and effort therefore their cost of sale s rises.  Also there
 is no guarantee of complete transformation or even the capabilities to
 semantically recognize the data.  The return confirmation, if data
 cannot be recognized, cannot be given accurately either, thereby leaving
 a Question as to whether or not the order was actually placed.

 In the time lapse between company "B" sending the PO and Company "A"
 rejecting it, several days may pass and/or other opportunities are
 missed.

 The most efficient path to take is a general assumption that the
 receiving end cannot do data transformations (unless there is a mechnism
 for an explicit statement of such in the CPP they post?).  This makes it
 easier for the sending side to be certain that their business process
 will succeed (or fail).   There is a great unknown variable on the type
 s of incoming data so it would be extremely difficult for a receiving
 company to state whether or not they can automatically (or manually)
 convert all data types that are sent to them.  It was felt that more
 than likely,  a receiving company making statements would at best be
 able to cover only a very minute amount of possible transformation
 possibilities, therefore this mechanism of stating capabilities is
 likely to be incomplete and result in a lot of missed business
 opportunities.

 ebXML methodology works in a manner such as this:

 declarations
 discovery
 agreement
 transact

 The delcarations are done via CPP's, Business processes, and GUID's on
 Core Components.

 The discovery makes use of those declarations to perform discovery.

 The agreement phase involves knowing or understanding that enables
 someone to take actions

 The transaction phase is the actual run time phase.

 <IMHO> a methodology of Transact, declare, discovery (with possible
 reversion to a previous state) is innefficient and is in contrast to
 most of the generally accepted methodologies of ebXML.

 Of course,  that is just my opinion.  I am certainly not the final voice
 on this and I invite alternative points of view.

 >
 > Fifth paragraph:  There is, of course, a bootstrapping issue here which
 > surfaces frequently.  If the two companies are negotiating a
 CPA via ebXML
 > messaging (or any messaging for that matter), they are performing a
 > business process that should be described by a negotiation CPA.
  Then how
 > do they first negotiate the negotiation CPA?  The answer is
 probably that
 > vendors may wish to supply sets of CPA templates for common
 functions and a
 > CPA should be able to be negotiated from one of these templates
 by a quick
 > phone call.  Another alternative is a "middleman" negotiation
 service that
 > supplies a canned negotiation CPA to each of its customers.

 I support your answer to this problem.  The CPA for negotiating
 subsequent CPA's probably needs to be placed somewhere in the CPP
 document.

 " how can you ask someone how to talk to them if you don't know how to
 talk to them"

 hehehe

 Nice

 Cheers all:

 Have a good weekend

 Duane Nickull




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC