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