Tasks are the main building blocks of workflows. There are UserTask
s and
AutomatedTask
s, 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”.
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:
|
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
Rejecting a task
A user can also reject the task via Canceling a task
The state activated is also entered if a task was accepted by a user and then
canceled by this user via |
A user task must be accepted by the user in order to leave the state 'activated'
via
Another way to leave the state is to skip the task via A fallback to waiting is possible. |
suspended |
This state can only be entered via |
This state can be left via |
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
|
An automated task leaves the state 'running' and enters one of the states
'completed' (via 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
'Completed' is reached, when the task is completed via
'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
|
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 |
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