loading table of contents...

4.1.4. Tasks

Tasks are the main building blocks of workflows. There are UserTasks and AutomatedTasks, as well as auxiliary control flow tasks like If, Choice, Fork, Join, Switch, ForkSubprocess and JoinSubprocess. All mentioned different types of tasks can be defined using the CoreMedia Workflow XML format.

Like a process definition is a template for concrete process instances, a task definition is a template for specific task instances. While being executed by the workflow engine, a task instance can take several states as shown in the state diagram in Figure 4.4, “State diagram of a task”.

State diagram of a task

Figure 4.4. State diagram of a task


Different operations are possible or mandatory during the execution of a task instance to enter or leave the different states. A rights policy defines which operations are allowed to a user. You can configure this rights policy. The following table shows how to leave or enter the different task states. A user task always requires its performing user to have the appropriate rights to perform an action which changes the state of a task.

State

Enter State

Leave State

not_started

This is the starting state of all task instances after process creation.

The state is left automatically after the workflow server has entered the task.

waiting

This state is entered automatically, after the task is reached by the workflow server.

It is also entered from the activated state if instance context changes have been made. So the guards are recalculated.

The state is left automatically when the task is ready for activation, that is if the following conditions have been fulfilled:

  • The control flow of the workflow has reached the task.

  • The optional guard specified in the task definition evaluates to "true".

activated

This state is entered automatically, after the waiting state has been left.

Assigning a task

If this state has been entered, you can nominate a user or group for this task via Task.assignTo(). So only these users will see the task in their task list (if they have the appropriate rights). This operation will not change the state of the task.

Rejecting a task

A user can also reject the task via Task.reject(), so it will not be offered to him anymore. If all appropriate users have rejected the task, it will be offered again to all these users (this is the default performers policy).

Canceling a task

The state activated is also entered if a task was accepted by a user and then canceled by this user via Task.cancel(). All changes made so far by the user are saved, but the task is offered again to all appropriate users like before it was accepted.

A user task must be accepted by the user in order to leave the state 'activated' via Task.accept(). Then preconditions and entry actions are performed. After successfully running the actions, the task is performed by the user and no more available to other users.

Another way to leave the state is to skip the task via Task.skip(), switching to the state 'skipping'.

A fallback to waiting is possible.

suspended

This state can only be entered via Process.suspend() which suspends the workflow. All task are withdrawn from the task list (GUI specific).

This state can be left via Task.resume(). The workflow will restart at the same task where it was suspended.

running

If an automated task has been activated it automatically leaves the state 'activated' and changes to 'running'.

A user task must be accepted by the user via Task.accept() in order to enter the state 'running'. The task is then performed by the user and is no more available to other users.

An automated task leaves the state 'running' and enters one of the states 'completed' (via Task.complete()) and 'aborted' depending on the success of the actions and preconditions and Postconditions performed.

A user task can leave the state 'running' and enter one of the states 'waiting', 'completed' (via 'completing') and 'aborted'.

'Activated' is reached, when the user cancels the task via Task.cancel(). All changes made so far by the user are saved, but the task is offered again to all appropriate users.

'Completed' is reached, when the task is completed via Task.complete() and the exit actions execute successfully and the post-conditions evaluate to "true".

'Aborted' is reached, when one of the exit actions and postconditions fails.

skipping

Intermediate state.

Intermediate state.

skipped

This state is entered if the task has been skipped by a user via Task.skip(). The process continues with the following task.

This state can only be left, when the flow of operation returns to the task. That is, there is a loop in the workflow definition which returns to the task.

completing

Intermediate state.

Intermediate state.

completed

An automated task enters this state when all actions have been successfully performed and the preconditions and postconditions have been evaluated to "true".

A user task enters this state when the user completes the task, the exit actions have been successfully executed and the post-conditions evaluated to "true".

This state can only be left, when the flow of operation returns to the task. That is, when there is a loop in the workflow definition, which returns to the task.

aborted

This state is entered if the process is aborted via Process.abort().

Final state.

escalated This state is entered automatically when an error occurs, if, for example, a postcondition fails. The previous user is still the performer if there was a performer (depends on the former state). You can leave this state retrying the task via Task.retry(). This will retry the last operation, which has failed: for example, if a precondition has failed, the task will restart with the state transition from activated to running, or if a postcondition has failed the task will restart with the state transition from running to completing and repeating all actions.

Table 4.2. Status of Tasks