About human tasks

A human task is a component that involves a person interacting with a service or another person.

The interaction can be initiated either by a person or by an automated service. A service that is initiated by a person can be either an automated implementation or a service that is provided by another person. A human task that is invoked by an automated service can be replaced easily by an automated implementation, and vice versa.

Tasks can be used to implement staff activities in business processes that require human interactions, such as manual exception handling and approvals. All other exception handling is modeled natively in Web Services Business Process Execution Language (WS-BPEL, abbreviated to BPEL), by using faults and fault handlers, or compensation.

Who can interact with a task can be determined using one of the supported staff directories. Work items are created for users who have a reason to view or interact with the task.

Business Process Choreographer supports the following types of staff directories:

Kinds of human tasks

The kinds of human tasks are as follows:
Participating tasks
Support Web-service-to-person interactions, which enable a person to implement a service. For example, a participating task can be a human task activity in a business process.
Graphic of the interactions in a participating task
Administrative tasks
Administrative tasks are similar to participating tasks, except that they are used by administrators to solve technical problems that occur in processes. Currently, you can use administration tasks for business processes only.
Originating tasks
Support person-to-computer interactions, which enables people to create and start services through a graphical user interface. For example, a user can start a business process, or send it an event by means of an originating task.
Graphic of the interactions in an originating task
Purely human tasks
Support person-to-person interactions, which enable a person to share work with other people in a structured and controlled way. Purely human tasks do not interact with business processes or other Web services.
Graphic of the interactions in a purely human task.

Relationship of human tasks to business processes

A human task can be related to a business process in one of the following ways:
Inline tasks
An inline task is defined as a part of the business process. It is not visible as an Service Component Architecture (SCA) component, and it can share context data with the process.
Stand-alone tasks
A stand-alone task is an SCA component that implements human interaction as a service (participating task), leverages the person-to-service interaction with a graphical user interface (originating task), or supports the structured collaboration between people (purely human task). Task components can be combined with other services, including business processes.
The following table shows the differences between these two implementation types.
Inline tasks Stand-alone tasks
Part of the business process. Independent of the business process. This implementation can also be used in scenarios that do not include business processes.
The life cycle of the task is usually controlled by the process. The life cycle is independent of the process.
A participating task is a human task activity in a process. A participating task is an invoke activity in the process.
Inline tasks can access process context data, for example, variables, staff assignments, or custom properties. Stand-alone tasks cannot access process context data.
Task descriptions, display names, and documentation for participating and originating tasks support only one language. Task descriptions, display names, and documentation for participating and originating tasks support multiple languages.
Inline tasks are not visible as SCA components, and therefore they are not reusable (cannot be wired). Stand-alone tasks are reusable. Participating and originating tasks are visible as SCA components (can be wired).
Supported kinds of tasks: participating tasks, originating tasks, and administrative tasks. Supported kinds of tasks: participating tasks, originating tasks, and purely human tasks.

Subtasks

A subtask is an additional unit of work that is split out from a parent task. The subtask model can be selected from a template or it can be defined at runtime. Input data is provided by the person that creates or starts the subtask. The parent task waits until all of its subtasks are finished. The owner or editor of the parent task consolidates the subtask output data, and then completes the parent task.

If the subtask fails to complete within a specified period of time, the parent task can be escalated. The escalation indicates that the parent task is still waiting for subtasks to complete.

Subtasks can be purely human tasks or originating tasks.

Follow-on tasks

A follow-on task is a task that is created to complete an existing task. The follow-on task model can be selected from a template or it can be defined at runtime. Input data is provided by the person that creates or starts the follow-on task. The output and fault message types of the follow-on task must be the same as those of the previous task. The previous task is put into the forwarded state and it does not report completion to the service or person that invoked it.

When the follow-on task finishes, it reports its output or fault data to the service or person that invoked the original task. Escalations of the previous task continue to run and escalate. The follow-on task has its own escalations.

Follow-on tasks can be only purely human tasks.

Escalations

An escalation is a course of action that is executed when a task is not completed satisfactorily within a specific period of time. For example, if tasks are not claimed or are not completed within a defined time limit. You can specify one, or more, escalations for a task. These escalations can be started either in parallel or as a chain of escalations.

Escalations are initialized when the associated task reaches a certain state in its life cycle. After a defined duration, the task state is verified, and if it does not meet the modeled expectation, the escalation action is invoked. The following escalation actions are supported:
  • Create work items for a set of users
  • Send e-mails to the designated recipients
  • Send notification events to registered consumers

(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)