BPMN-OS
BPMN for optimization and simulation
Loading...
Searching...
No Matches
Processes

A process instance is created when all data required for the attributes defined for the process element, in particular, the instance identifier and the timestamp, become known and the timestamp is reached. Upon instantiation, a token is created which resides at the process element.

A token at a process element changes its state as follows:

stateDiagram-v2
    state feasibleEntry <<choice>>
    state feasibleExit <<choice>>
    [*] --> ENTERED
    ENTERED --> feasibleEntry
    feasibleEntry --> BUSY: [feasible]
    feasibleEntry --> FAILED: [infeasible]
    BUSY --> COMPLETED
    BUSY --> FAILING: failure
    COMPLETED --> feasibleExit
    feasibleExit --> DONE: [feasible]
    feasibleExit --> FAILING: [infeasible]
    DONE --> [*]
    FAILING --> FAILED
    FAILED --> [*]

Token creation

After initialization, the state of the process token is immediately set to ENTERED.

ENTERED

Upon entry, the initial assignment of attributes are conducted in the order of attribute definitions. Feasibility of the token status is validated. If any of the restrictions is violated, the token state is updated to FAILED. Otherwise, a token is created at the start node of the process and at the start event of each event subprocess (excluding those having a compensate start event). These tokens inherit the status attributes of the process token. Furthermore, the token state is updated to BUSY and

Attention
It is assumed that each process has a unique blank start event.
Note
Event-subprocesses must have a unique typed start event.
Note
A failure occurring at this stage can not yet be caught by an event subprocess with an error start event.

BUSY

A process token remains in BUSY state until the process

  • is terminated due to an uncaught failure, or
  • the last active token within the scope has completed without failure.

While the process token is in BUSY state, the token status may be updated due to an escalation raised downstream by an escalation event. If the token resides at a process which is the performer of a sequential ad-hoc subprocess, the token status is also updated whenever a token exits a child activity of the sequential ad-hoc subprocess.

When an uncaught failure is raised within the scope of the process, the status of the process token is set to the status of the token raising the failure. All tokens within the scope of the process (excluding those created for compensation) are disposed before the state of the process token is updated to FAILING.

Note
A failure occurring at this stage may be caught by an event subprocess with an error start event.

When all tokens within the scope of the process have reached DONE state and no event subprocess is running, the status of the process token is updated with the merged status of all these tokens within the scope. All child tokens are disposed (including those at start events of event subprocesses) before the state of the process token is updated to COMPLETED.

A process also completes if an event subprocess with a start event that is interrupting completes successfully. In such a case, the token status of the process is analogously updated with the merged status of all tokens in DONE state within the scope of the interrupting event subprocess. All of these tokens are disposed before the state of the process token is updated to COMPLETED.

COMPLETED

Feasibility of the token status is validated. If none of the restrictions is violated, the token state is updated to DONE. Otherwise, the token state is updated to FAILING.

Note
The failure occurring at this stage can no longer be caught by an event subprocess with an error start event.

DONE

When the process token reaches DONE state, it is disposed and the process instance has successfully completed.

FAILING

When the process token reaches FAILING state, the status of the process token is updated using the values of the token causing the failure, all tokens within the scope of the process are withdrawn, and the state of the process token is updated to FAILED after all relevant activities within the scope of the process have been compensated.

FAILED

Upon failure, the process token is disposed.