IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > BPEL processes and human tasks > Human tasks overview

To-do tasks and collaboration tasks with parallel ownership

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

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:

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.

Human tasks overview


Related concepts:
State transition diagrams for to-do tasks
State transition diagrams for collaboration tasks