[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 12/5/2005: Condition Expressions (Triggering or Enabling Events)
In Tuesday's call we briefly discussed condition expressions and transitions, as well as their use when you have external events (such as triggering ones). We have received similar questions from several user communities (health care, local government and textiles). I was asked to provide some insight and historical definition here to determine if the specification needs better descriptive text, delegate details to a primer (or FAQ), or expressed in the IIC ebBP profile. Here is a summary of these conditions, a summary of our discussion, and a partial recommendation for the use of conditions expressions to represent such events (regardless of where they come from): o What are condition expressions? + Elements that exist on Business Collaboration or Business Transaction Activities (BTA and ComplexBTA) - BeginsWhen, EndsWhen, PreCondition and PostCondition. Activities may define business rules via these elements or use them for annotation purposes. If used as computable conditions on the activities defined, these expressions could be a part of a standard application of a Business Transaction and/or specific to the context of which the transaction that is used (for a Business Transaction Activity). A specific use case for their use is found in Section 3.4.10.1. o Definitions: + PreCondition: A description of a state external to this activity that is required before the activity can commence. + PostCondition: A description of a state external to this activity that is required after the activity concludes (i.e. the state doesn't exist before the execution of this activity but does exist afterwards). + BeginsWhen: A description of an event external to this activity that normally causes it to commence (i.e. PreCondition + other variables = BeginsWhen). + EndsWhen: A description of an event external to this activity that normally causes it to conclude (i.e. PostCondition + other variables = EndsWhen) o Agreed scope: Enable and allow further specification in a later version. Previously we discussed if there were user community use cases to necessitate enabling these conditions to exist on the BT, whereby they could act as process gatekeepers into/out of the BT. At the time discussed (earlier this summer and fall), more concrete use cases had not been found. Proposed changes are below. I'd encourage comments from everyone and we can discuss on Tuesday, 6 December 2005. Thank you. ============ Section 3.4.9.3.3 Change from: ...In this case, the BTA is considered successful, again after it has reached a Protocol Success state. Condition guards on transitions are discussed in detail in Section 3.6.3.... Change to: ...In this case, the BTA is considered successful, again after it has reached a Protocol Success state. For example in the case of a Decision (linking construct), isPositiveResponse is in effect within a Decision related to the DocumentEnvelope. This is evidence of the preference to evidence collaborative shareable) information (i.e. the DocumentEnvelope) to align state between the parties involved. Condition guards on transitions are discussed in detail in Section 3.6.3.... Section 3.4.10.1 Change from: Business Transaction Activities, Complex Business Transaction Activities and Collaboration Activities MAY define business rules with the BeginsWhen, EndsWhen, PreCondition and PostCondition elements. These elements MAY be used for annotation purposes. If the expression attribute is rendered as computable, the BSI MAY use these attributes at run-time. If desired, variables MAY be used to further enable Pre- and PostConditions, BeginsWhen and EndsWhen elements, as they are of type ConditionExpressionType. For example, an XSLT variable may be used for these attributes and allow values to be placed in them. Variables are semantic enablers, as discussed in Section 3.4.11. It is possible that conditions, such as these, could be a part of a standard application of a Business Transaction and/or specific to the context of which the transaction that is used (for a Business Transaction Activity). If conditions existed on the BT, they could act as process gatekeepers into/out of the BT. Enabling conditions on the BT (in addition to where they currently exist on the BTA) may be considered in a future version. The semantics of BeginsWhen and EndsWhen indicate that the corresponding Business Activity is expected to be started or ended as soon as the expression in the attribute value is true. The BeginsWhen expression MAY be used to: · Link a semantic state (e.g. begins when "state" of "product-delivered" is reached) · Serve as a semantic definition that MAY be used to define that state (e.g. "in the context of this ebBP definition, "product-delivered" is defined as the existence of both product-delivered date and delivery-signature) For EndsWhen, in the case of a certification exam, a registrant is allowed three attempts to pass an exam to achieve certification; otherwise the registrant fails. In an academic setting, a health care provider, i.e. the registrant, attempts the certification exam three times. For the first try, the registrant submits a certification request and engages in a registration step. The registrant request fails and is returned. The registrant increases insurance, retries and fails. For a third try, the registrant increases staff capacity, then retries. The registrant requests fails a third time. The registrant attempts to re-register but must start over again. This scenario may apply to other than health care, such as Amazon self-registration. The EndsWhen is a quality of service attribute that may enable evaluation (and in the future computation) of Business Transaction status after the Business Document is received. In the future, these capabilities could be filter- or subscription-based capabilities to enable the business community to define the semantic business-event controlling the process. A constraint may be declared on an action that maps to information that is produced by that action. For example, BeginsWhen is based on business content in the business message delivered on that action. A PreCondition indicates that the corresponding Business Activity may start only if the corresponding expressions are true. A PostCondition expresses a condition that must be true once the activity has been completed. For example, Business Success is true (i.e. the status reported to the choreography is true) when the activity is completed. Whether BeginsWhen, EndsWhen, or Pre- or Post-Condition, the information MUST be visible to the parties involved. Change to: Business Transaction Activities, Complex Business Transaction Activities and Collaboration Activities MAY define business rules with the BeginsWhen, EndsWhen, PreCondition and PostCondition elements. These elements MAY be used for annotation purposes. If the expressions rendered as computable, the BSI MAY use them at run-time. These element definitions are: · PreCondition: A description of a state external to this activity that is required before the activity can commence. · PostCondition: A description of a state external to this activity that is required after the activity concludes (i.e. the state doesn't exist before the execution of this activity but does exist afterwards). · BeginsWhen: A description of an event external to this activity that normally causes it to commence (i.e. PreCondition + other variables = BeginsWhen). · EndsWhen: A description of an event external to this activity that normally causes it to conclude (i.e. PostCondition + other variables = EndsWhen). These expressions may also be made available elsewhere (such as used internally) to further verify the legitimacy of an activity. The partners involved collaboratively define the constraints whereby they engage in these activities. This may provide the capability for both parties to verify the conditions (rules or logic, for example) were followed. If desired, variables MAY be used to further enable Pre- and PostCondition, BeginsWhen and EndsWhen elements, as they are of type ConditionExpressionType. For example, an XSLT variable may be used for the expression of this condition and allow values to be placed in them. Variables are semantic enablers, as discussed in Section 3.4.11. It is possible that conditions, such as these, could be a part of a standard application of a Business Transaction and/or specific to the context of which the transaction that is used (for a Business Transaction Activity). If conditions existed on the BT, they could act as process gatekeepers into/out of the BT. Enabling conditions on the BT (in addition to where they currently exist on the BTA) may be considered in a future version. The semantics of BeginsWhen and EndsWhen indicate that the corresponding Business Activity is expected to be started or ended as soon as the expression in the attribute value is true. The BeginsWhen expression MAY be used to: · Link a semantic state (e.g. begins when "state" of "product-delivered" is reached) · Serve as a semantic definition that MAY be used to define that state (e.g. "in the context of this ebBP definition, "product-delivered" is defined as the existence of both product-delivered date and delivery-signature) These external events may drive a transition and condition to be possible or not (and hence could affect success or failure). For example, an invoice may not be generated until a product is delivered. For EndsWhen, in the case of a certification exam, a registrant is allowed three attempts to pass an exam to achieve certification; otherwise the registrant fails. In an academic setting, a health care provider, i.e. the registrant, attempts the certification exam three times. For the first try, the registrant submits a certification request and engages in a registration step. The registrant request fails and is returned. The registrant increases insurance, retries and fails. For a third try, the registrant increases staff capacity, then retries. The registrant requests fails a third time. The registrant attempts to re-register but must start over again. This scenario may apply to other than health care, such as Amazon self-registration. The EndsWhen is a quality of service attribute that may enable evaluation (and in the future computation) of Business Transaction status after the Business Document is received. EndsWhen may be a description of an event external to this collaboration that typically causes this collaboration to conclude. A PreCondition indicates that the corresponding Business Activity may start only if the corresponding expressions are true. A PostCondition expresses a condition that must be true once the activity has been completed. For example, Business Success is true (i.e. the status reported to the choreography is true) when the activity is completed. Whether BeginsWhen, EndsWhen, or Pre- or Post-Condition, the information MUST be visible to the parties involved. In the future, these capabilities could be filter- or subscription-based capabilities to enable the business community to define the semantic business-event controlling the process. A constraint may be declared on an action that maps to information that is produced by that action. For example, BeginsWhen is based on business content in the business message delivered on that action. Such constructs may be useful for process-context driven communication, monitoring and verification of rules related to content driven processes. For example, a Business Collaboration requires a notification of delivery. A DeliveryNotification transactionadheres to the Notification pattern is used that includes a Receipt Acknowledgement signal. However, the parties involved only want that notification to take place when the signature is available. This could occur when the driver return his device, although implementation (result) is visible to the business process. The transition occurs to this transaction as soon as the product is shipped, so the enabling component is then, in essence, waiting for an event that will start this transaction. ======== References: (email to the TC list) http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200511/msg00078.html (Technical specification reference) See Sections such as: 3.4.9.3.3, 3.4.10.1, and 3.6.3
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]