Re: [ebxml-bp] Clarification - FORK and BusinessTransaction

["David RR Webber" <david@drrw.info>]

Title: Message

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

To: David RR Webber ; BPSS ebXML

Sent: Thursday, May 13, 2004 10:51 AM

Subject: RE: [ebxml-bp] Clarification - FORK and BusinessTransaction

 

-----Original Message-----
From: David RR Webber [mailto: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