Plan Item Lifecycles

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

CMMN case instances and plan items go through a lifecycle of states during their execution. Depending on their state, different actions may be carried out to interact with them. Moreover, state transitions may automatically trigger changes in other plan items. The concrete lifecycle of a plan item depends on its plan item definition.

The following descriptions cover the CMMN lifecycles as supported by the Camunda engine. This is a subset of states and transitions that the CMMN standard defines. Any state or transition that is currently not supported is marked in grey.

The descriptions in this section are general for the constructs they describe. Considerations that are specific for individual plan item definitions can be found in the respective sections of this guide.

Lifecycles By Example

To understand the role lifecycles play for CMMN execution, consider the following case:

example lifecycle case

This case contains two human tasks Task A and Task B that are connected by a sentry. The sentry expresses that Task B can be enacted when Task A finishes. This is formally specified by lifecycles. In our example, the following steps might take place:

  1. A user instantiates the case by caseService.createCaseInstanceByKey("case");. A new case instance is created in state ACTIVE.

  2. Two instances for each human task are automatically created, both in state AVAILABLE.

  3. Task A does not have a condition to start, so it immediately reaches state ENABLED. Note that the steps 1 to 3 all happens synchronously with the caseService invocation from step 1. The case is now in the following state: <center> lifecycle example 1 </center>

  4. A user manually starts Task A by calling caseService.manuallyStartCaseExecution(taskAExecutionId);. As a consequence, Task A reaches state ACTIVE and a task instance is added to the assignee’s task list. Note that starting a task is only allowed if that task is in state ENABLED. Thus, trying to manually start Task B here by caseService.manuallyStartCaseExecution(taskBExecutionId); would fail. The state is now: <center> lifecycle example 2 </center>

  5. The assignee completes the task instance by calling taskService.complete(taskId);. Task A reaches the state COMPLETED.

  6. Task A’s state transition triggers Task B’s sentry. In consequence, Task B becomes ENABLED. This happens synchronously in the invocation from step 5. Accordingly, the case’s new state is: <center> lifecycle example 3 </center>

  7. Similar to Task A, a user may now use the CaseService and TaskService to start Task B, complete the corresponding task instance, and complete Task B. Ultimately, Task B reaches the state COMPLETED.

  8. With both tasks in state COMPLETED, the case instance automatically reaches the state COMPLETED as well. The state has case has reached the following state: <center> lifecycle example 4 </center>

  9. A user may close the case instance by invoking caseService.closeCaseInstance(caseInstanceId);. The case instance reaches the state CLOSED.

Notice how the lifecycle states define the overall state of the case and restrict the interactions that are possible. For example, the tasks A and B can only be worked on when in state ACTIVE. Before, they go through states AVAILABLE and ENABLED, which represent that conditions for working on the task are not yet met, for example that the task was not manually started or that a sentry is not fulfilled yet.

This formal lifecycle model is exposed via the CaseService API in Camunda. Not only is it possible to trigger state transitions as in the code examples above. By making a case instance or case execution query, the current lifecycles state of a plan items are exposed. For example, the following code gets the state of the plan item for Task A:

CaseExecution caseExecution = caseService.createCaseExecutionQuery().activityId("taskA").singleResult();
caseExecution.isAvailable();
caseExecution.isActive();
caseExecution.isCompleted();
...

Note that a CaseExecution object corresponds to a plan item, here the plan item for Task A.

Case Instance Lifecycle

Case instance refers to an instance of the case plan model. More specific, it is an instance of the single top-level stage in a case definition. The lifecycle of a case instance is the following:

CaseInstanceLifecycle

States:

Task/Stage Lifecycle

The lifecycle of a task or stage plan item is the following:

TaskStageLifecycle

States:

Milestone Lifecycle

The lifecycle of a milestone plan item is the following:

MilestoneLifecycle

States

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org