[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 1/11/2006: Updated Text for Appendix D Recursion and Optionality
As a followup to our call yesterday, here is the change we agreed to for
Appendix D that will be included in Public Review Final Draft r04 that
will be added for vote today. I am working on the package updates as we
speak and will open the vote as soon as practical today [1].
You can look at the Appendices PR r03 located at:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=16067
(html version of Appendices document).
Appendix D:
Change from:
* Condition expressions using BeginsWhen, EndsWhen, PreCondition,
and PostCondition on Business Collaborations and Business
Transactions: When these expressions are enabled in a computable
way, they could be used as gating mechanisms to be available to
enter or enter, or be available to exit or exit activities. In
this manner, the activities flow using Fork and Join to drive the
correct Business Transactions.
o Explicit recursions: Any Business Transaction may be part of
a recursive loop that continues until explicitly terminated.
The EndsWhen could be used in this case.
o Explicit optionality: Any Business Transaction can be
fronted by a Decision that explicitly excludes execution of
the Business Transaction. For example, Partner A decides to
send a business document today only as a discount offer.
Partner A may handle that through parallel execution paths
and BeginsWhen.
* Other examples:
o Under certain conditions, it is unknown if more Order Status
Update will occur. At some point, a Delivery Confirmation
will be received with a different business document. A Join
may relate to this - when the Delivery Confirmation is
received, always move on. If this is not the case and
explicit closure is more difficult, a Fork may be used where
parallel processing occurs.
o Both a Delivery Advice and a Freight Status Advise could be
occurring. A PreCondition could be used to see if a
Delivery Advice is received; if a Freight Status Advice is
instead, the Business Collaboration is done and an error occurs.
Change to:
* Condition expressions using BeginsWhen, EndsWhen, PreCondition,
and PostCondition on Business Collaborations and Business
Transactions: When these expressions are enabled in a computable
way, they could be used as gating mechanisms to be available to
enter or enter, or be available to exit or exit activities. In
this manner, the activities flow using Fork and Join to drive the
correct Business Transactions.
o Explicit recursions: Any Business Transaction may be part of
a recursive loop that continues until explicitly terminated.
The EndsWhen could be used in this case.
o Explicit optionality: Any Business Transaction can be
fronted by a Decision that explicitly excludes execution of
the Business Transaction. For example, Partner A decides to
send a business document today only as a discount offer.
Partner A may handle that through parallel execution paths
and BeginsWhen.
* Other examples:
o Under certain conditions, it is unknown if more Order Status
Update will occur. At some point, a Delivery Confirmation
will be received with a different business document. A Join
may relate to this - when the Delivery Confirmation is
received, always move on. If this is not the case and
explicit closure is more difficult, a Fork may be used where
parallel processing occurs.
o Both a Delivery Advice and a Freight Status Advice could
occur concurrently. A PreCondition could be used to
determine that if a Delivery Advice is received, that branch
is done and the Business Collaboration completes.
Thanks.
[1] I didn't have email access last night due to instrusion attacks on
hotel network. Sorry.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]