[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 12/19/2005: Resolution for Recursion and Optionality - SuggestedAppendix
I've received feedback from John that no additional flag is needed unless, at some time in the near future, we have a better idea of the requirements surrounding its usage for optionality. Therefore, in reviewing the discussion and suggestions thus far, a short appendices may be helpful. This is the option we chose when we addressed manual or implicit activities. Therefore I'd suggest a short Appendix D (that moves our glossary to Appendix E) related to Recursive or Optional Activities. It will be short and to the point, recognizing the investment and ideas thus far. Change from: Add Appendix D: Handling Recursive or Optional Activities Change Appendix D (existing) to Appendix E: ebBP Glossary Change to: Appendix D: Handling Recursive or Optional Activities. In eBusiness, a business partner or collaborating party may need to plan for potential activities - those that may occur more than once or more, or not at all (i.e. they are optional). Several mechanisms can assist in realizing these needs including semantic variables, condition expressions and guards on transitions. In the technical specification, we describe these capabilities in detail. However, understanding their usage in user communities to solve complex eBusiness needs is important. For example, the textile industry in Italy often engage in activities which may or may not occur, and, others that may occur more than once. Different order statuses or types of business messages with business documents may occur. The process designer may utilize the ebBP capabilities for these purposes, including: 1. Condition expressions using BeginsWhen, EndsWhen, PreCondition, and PostCondition: 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. * 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. * 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. 2. Condition expressions on gateways for Fork, Join and Decision: Using condition expressions on ToLink and FromLink: Condition expressions can be associated with the ToLink and FromLink element. The conditionGuard attribute of the FromLink element can contain status values obtained from the state pointed to by the FromLink; matching the value governs whether a transition is made at run time. For the ToLink completion states can have condition expressions that are checked at runtime to determine whether the transition to a state is actually made. * For example for recursion: For re-entering a transaction, a Fork could send the process back into the same Business Transaction. Conditions could be used on the Fork that preclude re-entry. For example, a Freight Status Advice has several possible values - one that reoccurs many times with a condition on the Fork after the advice that says that if this status is 'delivered', then re-entry may not occur. Otherwise, recycle and look for another one. In the future, an optional declaration on a Business Transaction may be considered to support certain types of status messages. In this case, assuming the explicit modeling of execution paths, any declaration would be considered documentation. See the technical specification associated with this appendix for more details on condition expressions, condition guards, business states and their characteristics. Change to: Appendix D (current) becomes Appendix E: ebBP Glossary.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]