OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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