[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]