Re: CPA composition from multi-role CPPs

[Duane Nickull <duane@xmlglobal.com>]

Martin W Sachs wrote:

> The second paragraph states "After receiving verification that the format
> and usage of a business scenario is correct, an acknowledgement...by the
> registry" . I don't understand "format and usage of a business scenario".
> The registry is application-independent. I don't see how it can possibly
> verify anything about the business scenario.  I would not expect the
> registry to check more than that the CPP can be parsed and that its
> metadata conforms to the registry rules.

This is all I had in mind too.  It coud have been better emphasized. 
Grammar has never been one of my strong points.(as you may have guessed
by my erroneous spelling ;-)

 The latter is probably a check on
> the registry's request form and not on the CPP itself. Furthermore if we
> continue on the path of referencing rather than embedding the business
> scenario, whatever checks the registry does on the business scenario
> document will have been performed when the business scenario document was
> submitted and would not have to be rechecked when a CPP referencing it is
> submitted.

Good points!!

> 
> Third paragraph:  this paragraph states an assumption that it is the
> discovering party that is responsible for performing any data
> transformations into a form in which the discovered party can process it.
> It is not obvious to me why there should be this restriction, even in an
> example (since the example will convey an impression of what the correct
> practice is).  A more appropriate scenario is that companies A and B agree
> on the format and syntax of the documents to be exchanged.  If data
> transformations are necessary to either company, that company performs the
> transformation before sending or after receiving the document.

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