Tasks with parallel ownership allow potential owners to
work simultaneously on the task. A common example of parallel ownership
is when a set of potential owners need to approve a to-do task in
a BPEL process. Parallel ownership can be specified for to-do tasks
and collaboration tasks.
When a task with parallel ownership is started, a subtask for each
potential owner is created and started, and the parent task goes into
the running state. The potential owners can be individuals or groups.
If a subtask is created for a group, any member of this group can
claim the task. The input message and all other relevant information
for the parent task are copied to each subtask. The subtasks are always
collaboration tasks.
After the subtasks are started they go into either the ready state
or, if automatic claim is specified for the parent task and the potential
owner has an individual work item, the claimed state. When the subtasks
are created, the parent task goes into the waiting-for-subtask substate.
The subtasks then go through the normal lifecycle of a collaboration
task; the parent task remains in the waiting-for-subtask substate
until all of its subtasks reach an end state. If the completion condition
for the parent task becomes true, all of the subtasks, which are not
yet in an end state, are terminated.
Because parent tasks do not have an owner, you cannot use the API
operations, such as claim or cancelClaim on
them. If the parent task is modeled so that its subtasks are claimed
automatically, the subtasks are automatically assigned to each of
the potential owners.
Authorization considerations
Note: To ensure
that a subtask can be created for each potential owner, do not use
the Nobody or Everybody people
assignment criteria for a task with parallel ownership.
The
subtasks that are created have the following authorization roles:
- The administrator of the task with parallel ownership becomes
the administrator of each of the subtasks
- The person who starts the task with parallel ownership becomes
the originator of each of the subtasks
- One potential owner
In addition, the subtask can also inherit authorization
roles from the task with parallel ownership. The inherited roles depend
on the role propagation settings that are defined for this task in
Integration Designer:
- All
- The readers, editors, originator, potential owners, and owner
of the parent task become readers of the subtask and its escalations
- All or Administrator
- Administrators of the parent task become administrators of the
subtask and its escalations
Completion conditions
Generally, a parent
task waits in the waiting-for-subtask substate until all of its subtasks
are in an end state. However, in certain parallel ownership situations,
you might want the parent task to finish without waiting for all of
the subtasks to enter an end state. For example, if the subtasks are
for the approval of a document, you might want the parent task to
end even if not all of the subtask owners approve the document. To
enable this type of scenario, you can specify completion conditions
for the task with parallel ownership in Integration Designer. The
following types of completion conditions are available:
- XPath-based completion condition
- This completion condition can exploit both the completion condition
functions and result construction functions. The condition is evaluated
before the subtasks are created and after each subtask enters the
finished, expired, terminated, or failed state. It must evaluate to
true for a task with parallel ownership to finish.
For example,
the completion condition for a task with parallel ownership that should
finish when at least 50% of the subtask owners have provided their
data might look similar to the following code snippet:
tel:getCountOfFinishedSubtasks() div tel:getCountOfSubtasks() > 0.5
- Calendar-based completion duration
- A duration that specifies when the task with parallel ownership
should finish at the latest. The duration syntax is determined by
the calendar that is specified for the task definition.
If one of the completion conditions
applies, the task with parallel ownership finishes and the aggregated
result for all of the subtasks is constructed. If subtasks exist that
are not yet finished, they are automatically terminated.
Result construction
The result of the task
with parallel ownership is constructed by aggregating the results
of its subtasks. You can use XPath expressions in the task definition
to specify how fields in the output message of the task with parallel
ownership are to be filled based on the outcome of the subtasks.
The
result for a specific field consists of the following attributes that
are defined by an XPath expression identifying a value in the context
of the output message of the task. - part
- This attribute identifies the part in the output message that
contains the location field that is to be used. This field must be
omitted for message definitions that use the document literal wrapped
binding style.
- location
- This attribute identifies the following fields:
- The field in the output message of each of the subtasks that is
the source for result aggregation
- The field in the output message of the task with parallel ownership
that is the target for the result of the aggregation
- condition
- This attribute specifies that the subtask field is relevant for
result construction. The field is identified by the location attribute.
If a subtask field is not relevant, it is ignored when the results
are constructed.
- aggregationFunction
- This attribute defines how the values of the subtask fields are
combined into one aggregated result. The fields are identified by
the part, the location, and the condition attributes. The aggregated
result is stored in the output message of the task with parallel ownership,
in the field identified by the location attribute.
Example of a TEL definition of a task with parallel
ownership
The following example shows the TEL definition
of a task with parallel ownership:
<tel:result>
<tel:aggregate location="/reviewresult" function="tel:and()"/>
<tel:aggregate location="/reviewcomments"
condition="/reviewresult=true()"
function="tel:concatWithDelimiter('|')"/>
</tel:result>
In this example, result aggregation
is specified for the reviewresult and reviewcomments fields
in the output message. The location /reviewcomments specifies
that the corresponding field in the output message of the subtask
is used as the source for aggregation. The XPath indicator “/” denotes
the root of the output message definition. The /reviewresult=true() condition
specifies that a subtask is considered only if the value of the reviewresult field
in its output message is set to true. The aggregation function specifies
that the values of the qualifying output messages are concatenated
into an aggregate String using the specified delimiter.