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