RE: [bpel4people] ISSUE BP-19: Title: Using process variables in constellations 1 and 2

["Mark Ford" <mark.ford@activevos.com>]

Sorry, I sent prematurely, finished email is below. 

-----Original Message-----
From: Mark Ford [mailto:mark.ford@activevos.com] 
Sent: Friday, June 20, 2008 4:16 PM
To: bpel4people@lists.oasis-open.org
Subject: [bpel4people] ISSUE BP-19: Title: Using process variables in
constellations 1 and 2

The consensus from the face to face meeting was that the variables would be
live such that a change to a process variable that is used in an escalation
handler is visible to that escalation handler during its execution.

For example:

<ht:escalation ...>
   <ht:condition>ht:getActualOwner() = 'Bob' and $v1 = 100</ht:condition>
   ...
</ht:escalation>

If the value of v1 at the time of the people activity's execution is 100
then this condition may evaluate to true. If the process changes the value
of v1 to 101 prior to the deadline's alarm firing then this condition will
never be true.

My initial thought here was to add some text to Section 4.9.2 in the b4p
specification to clarify this. The current text reads as follows:

--- quote ---
4.9.2 Context Data
Tasks defined as part of a BPEL4People business not only have access to the
context data of the task, but also of the surrounding business process. The
process context includes
.	Process state like variables and ad-hoc attachments
.	Values for all generic human roles of the business process, i.e. the
process stakeholders, the business administrators of the process, and the
process initiator
.	Values for all generic human roles of human tasks running within the
same business process
--- end quote ---

However, there is some text in the HT specification which touches on this
area. 

--- quote ---
4.7.1 Normal processing of a Human Task 
Upon creation, a task goes into its initial state Created. Task creation
starts with the initialization of its properties in the following order:
1.	Input message 
2.	Priority 
3.	Generic human roles (such as excluded owners, potential owners and
business administrators) are made available in the lexical order of their
definition in the people assignment definition with the constraint that
excluded owners are taken into account when evaluating the potential owners.
4.	All other properties are evaluated after these properties in an
implementation dependent order. 
--- end quote ---

Item #4 from above states that the properties are evaluated in an
implementation dependent order. It seems possible that an implementation
could evaluate the conditions for some escalation handlers upon the task
execution. 

I'm thinking that the proposed resolution would need to make a change in
both b4p and ht specs. The b4p spec would have to state that references to
process variables in a task definition behave like any other variable
references. The ht spec would have to change to state that escalation
condition expressions shouldn't be evaluated until the alarm fires.