[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tamie] Question on uc3 again...
Paths I count as potentially correct paths thru diagram: Key: o=order ors=order response simple or=order response och=order change oc=order cancellation - = no document (signal or other document-less operation) Paths: o, - o, or o, oc o, och o, ors o, or, oc o, or, och o, ors, oc o, or, och, oc slightly less obvious paths (e.g punchout): -, or -, ors -, oc -, or, oc -, or, och -, ors, oc -, or, och, oc other possible allowable paths: o, och, or o, och, oc o, och, or, och...(repeatable) o, och, ors o, och, or, oc -, och, ors -, och, or ... etc Maybe some can be discounted - Steve 2009/3/10 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 > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]