A human task is, quite simply, a unit of work done by a human.
Quite often, this task involves the interaction with other services, and thus
becomes a task within a larger business goal.
The WebSphere® Integration
Developer tools have been designed so that users can easily compose integrative
business solutions without programming skills. To this end, you can easily
create and develop a human task in an intuitive graphical programming environment
called the human task editor.
Before you start to use the human task editor, you need to understand these
key concepts about human tasks:
Note: Human tasks can only be deployed to the WebSphere Process
Server.
An example of a human task
Let us begin
with an example of a human task. This graphic illustrates the steps involved
when a staff member accepts a task.

In this example, this
particular task is likely part of a much larger process which stops and waits
until the staff member makes a decision.
Here are some terms that you
will need to understand to use the editor:
- Task Definition
- A Task Definition is an representation of the task that includes the following:
- who can do the task (staff roles/verbs)
- what needs to be done (name)
- how it will be done (input and output data)
In the runtime environment, a task definition becomes a single work item
once it is started. Over time, there can be many work items from one task
definition.
- Work items
- A work item is the manner in which a task is presented to the user in
the Business Process Explorer or the generated client. A staff member (employee)
can browse all work items that they have the authority to claim, and then
execute the task.
- Roles
- A role is a group of employees who share the same level of authority.
A task is not assigned directly to a staff member, instead it is assigned
to one of the available roles. Any staff member in that role group can complete
the task.
- Verbs
- Verbs define the members of each of the role groups.
Presenting a task to a staff member
When
a human task is executed, the staff member interacts with the task through
a client environment.
If you take a look at the example again, you will
see that you have already been exposed to a client, it just was not spelled
out that way. Take a look at the example again with a few minor changes.

In this modified example,
we see that all interaction between the user and the task is facilitated by
a client. The task is delivered to the user through the client, and the resolution
is returned in similar means.
So far, both of our examples have shown
what happens when the task can be completed without a problem. What happens
when that is not possible?
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 instance, let us look at the same scenario
again, and see what happens when it isn't properly completed.

In this example, we see that the
staff member who claims the task isn't able to complete it in the specified
period of time, and another staff member is alerted. This second employee
has the authority to investigate the reasons behind why the task wasn't completed.
They can follow-up up with the first staff member or modify the task if necessary.
There
are three possible escalation settings:
- Ready
- When a human task is in a ready state, it is waiting to be claimed. If
it sits unclaimed for too long, an escalation is triggered and an appropriate
member of the staff is notified.
- Claimed
- If a staff member has claimed a task, but takes longer than the specified
period of time to complete it, an escalation is triggered and another staff
member is notified.
- Subtask
- A subtask is an additional unit of work that is split out from a parent
task. If the subtask fails to complete within a specified period of time,
the parent task is escalated and indicates that it is still waiting on the
subtask.
Different implementations: inline and stand-alone
tasks
There are two ways to implement a human task depending on
the usage scenario. If the task is implemented within a business process,
it is called an inline task. Otherwise, it is referred to as
a stand-alone task.
- Inline task
- An inline task is defined within an implementation of a business process.
It can either be implemented directly in the process using a human task activity,
or as a property of an invoke, pick, receive, event handler, or on message
activity.
- When you are first planning your human task, you should model it as an
inline task if any of the following conditions are present:
- You need information from the process logic to execute human interaction
- You want to execute administrative tasks
- You want to define authorization rights on specific activities
- Stand-alone task
- A stand-alone task exists independently of a business process, and implements
human interaction as a service that can be used in many of the different components
of the WebSphere Integration Developer family of tools.
- When you are first planning your human task, you should model it as a
stand-alone task if any of the following conditions are present:
- You do not need any information from the business process
- The task provides just another service
Types of human tasks
There are three
main types of human tasks:
- Participating task (P-task)
- This is where a service component (such as a business process) assigns
a task to a human. The human participates in the task.

A participating task can be either stand-alone
or inline.
- Originating task (O-task)
- This is where a human can assign a task to a service component. In such
a case, a human is invoking an automated service.

An originating task can be either stand-alone or
inline. When it is inline, an originating task allows humans to invoke the
operations that a business process exposes through activities such as receive,
pick or event handlers. Through this, a user can start a process and define
authorization for its inbound activities.
- Pure human task (H-task)
- This is where a human may assign a task to another human (perhaps as a
ToDo item). Similar to the previous type in that the human invokes a service,
but in this case, it is completed by another human.

A pure human tasks is stand-alone, in that
there is no interaction between it and a business process. It is self-contained
and implements a stand-alone human interaction without any reference or interface
to another service.
- Administrative task (A-task)
- This type of task grants a human administrative powers such as the ability
to suspend, terminate, restart, force-retry, or force-complete a business
process. Administrative tasks can be set up on either an invoke activity,
or the process as a whole.

This type of task
is only available with inline tasks.