[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tamie] Question on uc3 again...
Jacques, Good question. Well, this is just, I think, the limitation of the diagram - that it cannot show that such things are allowed. I don't think the diagram is intended to show what is incorrect, only what is clearly correct. Which is why the diagram alone does not give us everything we need which is the real world use of - in this case - UBL. If we used ebBP then it would allow us to substitute a document with an operation - the kind of thing the real world needs. In the real world there is a lot of use of punch-out where the order is placed by selection of goods from a catalogue and the order is implicit and not sent as a document from the buyer to the seller. The seller may, though, respond with a document response. There are cases of this which might not be called 'punch-out' of course but have similarities because the buyer ordering system would not be the best choice when an online buying website or catalogue system is available to provide a better facility than the traditional order-entry system can provide. There is no intention to preclude this with the diagram but that is how the diagram's being a summary doesn't go far enough as a full description. The text which accompanies this and the other such diagrams in the UBL spec adds that the diagrams are not intended to *limit* the use of UBL, so they should not be used to say, on their own, that some process path is *not* allowed. If we are looking for real-world use cases (to select one or a few related ones) then these three would warrant inclusion in the range of possibilities, I think. Sorry such a long answer. Best regards Steve 2009/3/10 Jacques R. Durand <JDurand@us.fujitsu.com>: > Stephen: > > -, or > -, ors > -, oc > > From a monitoring viewpoint, shouldn't such paths appear as failures? (not consistent with the UBL diagram where everything starts with a PO message) > How can we account for some "missing document"? Can we assume that these doc-less operations still generate some equivalent event? > > Jacques > > -----Original Message----- > From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green > Sent: Tuesday, March 10, 2009 3:01 PM > To: Moberg Dale > Cc: tamie@lists.oasis-open.org > 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 > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > -- 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]