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
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 -----
Sent: Thursday, May 13, 2004 10:51
AM
Subject: RE: [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