|
BPMN-OS
BPMN for optimization and simulation
|
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 --> [*]
After initialization, the state of the process token is immediately set to 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
A process token remains in BUSY state until the process
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.
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.
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.
When the process token reaches DONE state, it is disposed and the process instance has successfully completed.
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.
Upon failure, the process token is disposed.