[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RE: [ebxml-bp] Clarification - FORK and BusinessTransaction
+1 ----- Original Message ----- From: "Yunker, John" <yunker@amazon.com> Date: Thursday, May 13, 2004 10:23 am Subject: RE: [ebxml-bp] Clarification - FORK and BusinessTransaction > Not sure I'm on board with forking the response, since that > destroys the integrity of the transaction. > > When you send a PO you should expect to get a response that > details the disposition of each line item (accepted, rejected, > backordered, error invalid SKU, etc). That completes the PO > transaction. > In some business cases (automatic backorder or PO saying > "backorder if not available") the backorder transaction is part of > the Order transaction, in others you are required to send a > seperate order with the new delivery instructions. > > When there is a fork between business messages, each business > message is its own transaction, since by definition the > transaction is the atomic unit. For instance a optional response > becomes a notification (e.g. notification of acceptance, > notification of availability). > > We can get into trouble if we break up the atomicy transactions. > > In your example the transitions from the order transaction would > be guards for the possible outcomes based upon the content of the > response document. You would still get a response, and depending > upon the standard used the response would either include the > shipment / backorder information, or you would receive a seperate > ship notice (normalized message set). You would transition from > the order transaction to a backorder request to ship transaction > when the backorder guard is executed.... > > I can see that extreme simplification of the services and their > associated messages (map service directly to business outcome) can > allow easier understanding of how the business process maps to > services, however in that case each service invocation is an > atomic transaction (sometimes without an in-transaction response). > Thus the model still has the transitions at the transaction > level, and the compliance to service choreography is at the > business process level. > > Otherwise we completely blur the lines between transaction and > process, and re-use becomes a lot more problematic. > > John > > -----Original Message----- > From: David RR Webber [david@drrw.info] > Sent: Thursday, May 13, 2004 8:30 AM > To: Dale Moberg; BPSS ebXML > Subject: Re: [ebxml-bp] Clarification - FORK and BusinessTransaction > > > Dale, > > Here's the actual scenario I'm grappling with - and the need > to make it visually very clear for the user what is happening. > > Classic case of a 'create order' transaction - involving sending > a Purchase Order, and then receiving in response Order Confirm > with ShipNotice, or Order Rejected, or BackOrder notice. > > Four possible scenarios therefore fork from this - first is easy, > order rejected document received - done 'create order'. > Second - order confirm received followed by a shipNotice - these > should Join into the next transaction step - OrderFulfilment. > Then BackOrder notice should fork to "Create BackOrder BPSS". > > So we have a <BusinessTransaction> that contains 4 documents, > and then on the <BinaryCollaboration> we start with the 'create > order', and then want to do a Fork following that - based on the > document received back. > > OK - I see how this works now - the block approach is OK - because > first of all you have Success and Failure conditions, and then a > Fork for "other" that each references the document it gets back > via the conditions. > > That was the missing piece - you have to add those conditions. > Its still a bit ugly - would be better to just allow that on the > Fork directly > like the success and failure instead of indirectly - since on the > Fork you have to look at the BusinessTransactionActivity > under the Fork to find out the BeginsWhen to figure out what's > going on. > > Sequencing may throw you out too. In the example above - the succeed > involves both a ConfirmOrder transaction and a ShipNotice coming > back. So you have to use two success conditions and Join them - > that will work. > > Ok - I think I'm getting the hang of this! > > Thanks, DW > > > > ----- Original Message ----- > From: Dale Moberg <')" >dmoberg@cyclonecommerce.com> > To: David RR Webber <')" >david@drrw.info> ; BPSS ebXML > <')" >ebxml-bp@lists.oasis-open.org> > Sent: Thursday, May 13, 2004 10:51 AM > Subject: RE: [ebxml-bp] Clarification - FORK and > BusinessTransaction > > > -----Original Message----- > From: David RR Webber [david@drrw.info] > Sent: Wednesday, May 12, 2004 9:39 PM > To: BPSS ebXML > Subject: [ebxml-bp] Clarification - FORK and > BusinessTransaction > > Folks, > > I'm just getting to the final details on the V2 > model. > Right now the schema points FORK at > > BusinessTransactionActivity.businessTransaction > > Dale> I think that Fork could be semantically > constrained to link BTAs with BTAs. [At present it is more open in > that the ToLink takes IDREFs that could point to a pseudo-state > (like a Choice/Decision) as well as to a BTA. On both the incoming > and outgoing link, there is a conditionGuard and the "document > language" can (and probably should) hang on those links. So the > FromLink can transition automatically ( "true" on its condition), > then each ToLink's condition can be checked. Several can occur > with the "Or" semantics. XPath language on links is probably even > more appropriate for selecting (one or more) paths to pursue. I > don't think we want to collapse the node and edge layer of > description with the boolean condition layer of description. That > would be more of an architectural change than I would be > comfortable with. I think simulation or monitoring/verification > use cases would get very hard to do. > > This may make sense in the case where only one > document outcome can occur - but I believe it is more > accurate to point it at : > > > BusinessTransactionActivity.businessTransaction.RespondingBusinessActivity.document > > I think historically the conditionGuard with the > DocumentLanguage has been used to make the fork branches depend > on document. The same document could be on several branches of course. > > since what is potentially happening is that > within a > BusinessTransaction exchange there are several > possible outcomes > indicated by what document(s) are returned, based > on condition > and state. > > Dale> I think you are refactoring even more that > I was doing. While I see where you are going, the exisiting BPSS > has "edges" for the main potential paths, but uses booleans to > filter traversals. > > > As it is now - you have to split the outcomes up > into separate BusinessTransactions. > While this works - its not very intuitive. > > DW > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]