Getting Started with Human Tasks
Human Tasks is an extension to WS-BPEL 2.0 that includes human workflow activities within a BPEL process. In addition to receiving, replying, and invoking Web services, Human Tasks "invokes" a person to handle and complete a task. Similar to the behavior of an invoke activity, the person returns output data to the BPEL process.
Human Tasks is also based on the WSDL 1.1, WS-HumanTask 1.0 and WS-BPEL Extension for People (BPEL4People), Version 1.0 specifications.
Note: Human Tasks is currently available only using Process Developer with the on-premises version of Informatica Business Process Manager (ActiveVOS).
For details about the people involved in a BPEL process, see Introducing Human Workflow into a BPEL Process.
About the BPEL4People Specification
The WS-BPEL Extension for People (BPEL4People), Version 1.0 Specification provides extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions and a model of human interactions that are service-enabled. This specification is currently accepted by the OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee for discussion as adoption as an OASIS Standard.
For details, visit http://www.oasis-open.org/committees/bpel4people/charter.php.
Introducing Human Workflow into a BPEL Process
Human Tasks contains extension elements and an extension activity, called the People activity, which offer the following:
- •Creating a task definition.
- •Selecting people for working on or managing a task.
- •Creating workflow requirements, such as deadlines and escalations.
A People activity uses a task definition and contains several other properties. The People activity can be linked to any BPEL activity or contained within a scope or other container. You can add as many People activities to a BPEL process as needed.
See also Routing Tasks to People at Run Time.
Routing Tasks to People at Run Time
The following illustration shows what happens when a BPEL process executes a People activity.
When a BPEL process executes a people activity, the task defined by the activity is routed to all potential owners and administrators defined by the task. Each user can claim a task to work on, making it unavailable for other users.
When the task owner completes the task by submitting the required information into a form, the output data is sent back to the process so that the next activity can execute.
Typically a BPEL process containing a People activity is an asynchronous, long-running process. Since the people activity effectively "invokes" a person, the expected response time is high. For this reason, when you design a BPEL process containing a people activity, you should make the process asynchronous to avoid probable Web service communication timeouts.
About Task Life Cycle
The following are the basic states of a task after a BPEL process begins executing a People activity:
- •Unclaimed. The task is available for anyone designated as a potential owner.
- •Claimed. One person reserved and started the task. If only one user is assigned to the task, it is in the Claimed state automatically.
- •Completed. The output data was submitted and the owner declared the task complete.
- •Failed. The owner provided fault data and failed the task.
- •Exited. An error condition occurred, such as expiration or People activity termination.
Creating the Artifacts Needed for the People Activity
The People activity must route a task to the appropriate group of people. Doing this requires the following artifacts:
- •WSDL file that contains the port type and operation to "invoke" a person. The person receives the input data needed to make a decision in order to complete the task and reply with output data.
- •An identity service, which includes the groups and users available for tasks. As an option for choosing a task owner, you can define an identity service on the Process Developer Preferences page.
- •Informatica Business Process Manager includes an application to present task details to users. You can customize the presentation.
