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 »
Powered by
eList eXpress LLC