RE: [tamie] Question on uc3 again...

["Moberg Dale" <dmoberg@axway.com>]

Hi Stephen,

I have been thinking about your observations below, which are good ones. It seems to me that the UBL diagram we have been working from really presents a "union" of possible message exchanges or patterns that are made possible using UBL purchase orders. 

For ebBP, I think each alternative process pattern contributing to the union would be put into its own BusinessCollaboration as an alternative "contract".

In other words, if you wanted to do a choreography that worked by reducing the reactions to a detail changes state to paths where there is either a Cancel or nothing other than signal sent (thus making the default reaction that of acceptance) we would make that a toplevel alternative PO management scenario within its own BusinessCollaboration. UBL would then support maybe 10 or more distinct patterns, each pattern reflecting different ways of defaulting, reducing message traffic, or setting up options.

[In fact, my first PO mgmt use case-- before we tried to be UBL realistic-- just had an "always cancel PO change request" behavior documented.]

I now envision that we are going to have a family of BusinessCollaborations associated with the UBL message set. That is actually what should be expected. For the uc3 we need to explain this, and maybe document just a couple of the patterns. Then I can generate the LTSes from them and feed them to the script generating transform that Jacques is to provide. If you agree with this way of describing the situation, we can edit the uc3 text to incorporate this approach. Then I will try to draw up at least one other BC, do the BPMN 2 and LTS diagrams, generate the XML inputs, and then we would be complete. (Well, except for all the more technical details, like namespaces and XPaths etc.)

Additionally, I think that this "union" of alternatives mode of diagram is a main reason that it is very hard to actually draw a diagram with all the alternative combinations of choreographies made possible by a given SDO message set simultaneously present, yet distinquishable. What is really needed are various traces through the transition diagram, each one of which representing a coherent contractual possibility where defaults, conventions, expectations and options were cleanly highlighted.

Anyway that is my response to your comment. We can pursue this more on the call this evening/afternoon.



-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Saturday, March 07, 2009 5:15 AM
To: Moberg Dale
Cc: tamie@lists.oasis-open.org
Subject: Re: [tamie] Question on uc3 again...

OK, your requirement from a business process management
application perspective makes sense; but from the business
perspective of the parties in the collaboration I'd say it also
would make sense that they can accept some kinds or detail
changes or additions to the order (notified using the Order
Response) which do not require a further document to be sent.
Maybe the sending of a signal is enough. These might be
either
1. non-contractual changes (such as contact telephone number)
or
2. contractually agreed changes such as change of delivery time
within agreed limits
Most likely though they are notifications of
BuyerAgreedSubstituteOrderItems where the buyer already agreed
that if one kind of item couldn't be provided then another particular
item would be OK.

It would seem a bit weak for the technical engineers to have to
say to the business parties that the MUST use a document to
agree on a case by case basis to such changes. It would seem
OK to gloss over this for the purpose of our use case though. In
some cases it may well be that the software partly has to dictate
the business process a little. Maybe in some cases it would also
be the contract legal technicalities which would dictate that there
be an acceptance response to the response (such as OrderChange).
The latter I doubt though.

Best regards

Steve

2009/3/6 Moberg Dale <dmoberg@axway.com>:
> Question follows uc3 ubl diagram
>
>
>
>
>
>
>
>
>
> Consider the flow back through "Add Detail" activity. An Order Response
> message is sent. A Receive Response activity occurs leading to an update
> order choice.
>
>
>
> Why do we have three choices at "update order"?  I think there should just
> be "Cancel Order" or "Change Order"
>
>
>
> The "Accept Order" activity produces no message, while the other two produce
> the changed order message or the cancel order message.
>
>
>
> What is the Seller expected to do if the Buyer enters the Accept Order
> state? (A time out will lead to a performance failure...)
>
>
>
> It would make more sense to me if we reached Order Accepted by going back to
> the Seller and then Receiving his Order Response Simple (or by agreement,
> response not required.)



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice