I had some time this week to tinker with the output of uc3
lts for the POC connecting BPModels with BAM, so that now we have the following
new material for the xpaths for discussion on the next call
(in April?):
<Label2XPath label="PurchaseOrderRequest">/Order</Label2XPath>
<Label2XPath label="BusinessFailure" Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse">/Order</Label2XPath>
<Label2XPath label="Accept">/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath>
<Label2XPath label="ResponseReceiptFailure" Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse"
DocumentType="Accept">/Exception/ExceptionType/ReceiptException</Label2XPath>
<Label2XPath label="ResponseAcceptanceFailure"
Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse"
DocumentType="Accept">/Exception/ExceptionType/ResponseAcceptanceException</Label2XPath>
<Label2XPath label="AddDetailResponse">/OrderResponse</Label2XPath>
<Label2XPath label="ResponseReceiptFailure" Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse"
DocumentType="AddDetailResponse">/Exception/ExceptionType/ReceiptException</Label2XPath>
<Label2XPath label="ResponseAcceptanceFailure"
Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse"
DocumentType="AddDetailResponse">/Exception/ExceptionType/ResponseAcceptanceException</Label2XPath>
<Label2XPath label="Reject">/OrderResponseSimple[AcceptedIndicator='false']</Label2XPath>
<Label2XPath label="ResponseReceiptFailure" Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse"
DocumentType="Reject">/Exception/ExceptionType/ReceiptException</Label2XPath>
<Label2XPath label="ResponseAcceptanceFailure"
Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse"
DocumentType="Reject">/Exception/ExceptionType/ResponseAcceptanceException</Label2XPath>
<Label2Xpath label="AnyProtocolFailure" Service="PurchaseOrderCollaboration"
Action="PurchaseOrderResponse">/Exception/ExceptionType/GeneralException
or
/Exception/ExceptionType/ResponseAcceptanceException
or
/Exception/ExceptionType/ResponseReceiptException or
/Exception/ExceptionType/RequestAcceptanceException or
/Exception/ExceptionType/RequestReceiptException
</Label2Xpath>
<Label2XPath label="PurchaseOrderCancellation">/OrderCancellation</Label2XPath>
<Label2XPath label="BusinessFailure" Service="PurchaseOrderCollaboration"
Action="NoBusinessResponseDocumentOrMessage">/OrderCancellation</Label2XPath>
<Label2Xpath label="AnyProtocolFailure" Service="PurchaseOrderCollaboration"
Action="NoBusinessResponseDocumentOrMessage">/Exception/ExceptionType/GeneralException
or
/Exception/ExceptionType/ResponseAcceptanceException or
/Exception/ExceptionType/ResponseReceiptException or
/Exception/ExceptionType/RequestAcceptanceException or
/Exception/ExceptionType/RequestReceiptException
</Label2Xpath>
I incorporated Jacques’s suggestion to put document envelope
language labels in an attribute (remember that these are roughly speaking
xpaths into the soap:Body, so they may need some fixup to prepend the soap
ancestors.
As far as namespaces go for qnames, instead of localnames currently
shown, the easiest idea would be to emit the paths with prefixes, and then in
some other elements, put the prefix to namespace URI map. This approach would
be general enough for the POC but might need to be made more robust eventually.
I was trying to find out how prefix scope is determined when qname values are
placed in attributes (or in element text nodes). I have not found a definitive
standards or w3c ruling on this issue so far.
The above sample shows how condition guard values are mapped. Unlike
the document envelope labels, the condition guard value maps are contextual
(because they really summarize or reflect the overall “status” of a
BTA (or CA or CBTA) within a BusinessCollaboration. So the
BusinessCollaboration context is marked with the “Service” value (which
is the term for this metadata when it is on the wire using ebMS 2 or 3). The
Action indicates either the Request or Response in the BusinessTransaction. But
if ebMS 2 or 3 are used, most of the failure statuses are associated with
signals carrying Exceptions. The Exceptions will have a Service and Action
value, so this helps pick out what to look for.
Otherwise, it will be hard to say which Exception goes with which part
of the BP flow.
Another layer of monitorable functionality that can be associated with
XPaths (for a given protocol) will be the QOS values for security and
reliability. I have not started writing these up as the wire forms depend on
the specific messaging protocol. So, should we write up an ebMS 2, and ebMS 3, and
so on version _or_ (my
preference) just stick with one that will be used in building our event boards
for running against the scripts. Also when security is present, it can of
course block out XPaths intended for the plain text. So for the moment, I am
leaving these aspects out of the lts label.
One general issue is how to handle the hierarchy for the condition
guard values. The ebBP spec has the following hierarchy and, if there is time,
I would like to raise some questions about “operationalizing” these
values for XPaths and the eventual event catch statements that are supported. Specifically,
the issue to ponder is whether “Success” can be regarded as
consisting of occurring when none of the failures below occur?
