Most business processes involve asynchronous processing and require to hold states persistent while communicating via asynchronous messages. In UML, this behavior is supported by state machines. A state machine diagram defines all states a process instance can be in - including the initial and the final state. While in a state, the process instance can receive asynchronous messages via signals, e.g. an abortion signal (MyProcessAbort (6) in the picture below). Changes of state are called transitions.
For each BPMN process that has been modeled with the Designer, the compiled xUML service contains one standard root state machine diagram that supports error handling and compensation as well as history states.
The actual process is integrated to this state machine as a sub state machine (see Executing MyProcess (2)).
The root state machine features the following states:
| State | Description | Signal | Setting | |
|---|---|---|---|---|
| 1 | Initialized | State Initialized is a temporary state. The process instance passes this state once triggered. | ||
| 2 | Executing | State Executing contains the sub state machine that executes the actual business process. Processes in this state can be aborted by sending the MyProcessAbort signal. |
| |
| 3 | Aborted | When a process has been aborted, it will be transitioned to this state. After having waited the holdTime, the process transitions to state Clean. |
| |
| 4 | Error | If the process triggers an error, it goes to the Error state. |
|
|
| 5 | Done | After the end event of the process has been executed it is in state Done. After having waited the holdTime, the process transitions to state Clean. |
| |
| Compensate | In future versions of the Designer it will be possible to define process compensation and clean-up tasks. The Compensate and Clean states are designated for that. | |||
| Clean |
| |||
State Transitions
Transitions between states can be automatically, time triggered, or signal triggered. Time triggered and signal triggered transitions can be controlled via the Bridge Integration Platform, or the Bridge API and xUML Runtime API as described on xUML Service Interface.
Time Triggered Transitions and Settings
The xUML service implementing the process features settings to control time triggered transitions.
| Setting | Description | Allowed Values | |
|---|---|---|---|
| holdTime | Specify a period of time the process will reside in state Done after the process has been finished. | A valid time duration as specified on Time Durations. | |
| autoRetry | Specify whether the root state machine should trigger a retry of the erroneous process step after the period of time defined in autoRetryTime. | true | Retry process step where the error occurred. |
| false | No auto-retry (default). | ||
| autoRetryTime | Specify a period of time to wait before triggering an auto-retry of a process in state Error. | A valid time duration as specified on Time Durations. | |
You can change these settings on the Bridge as described on xUML Service Settings.
Alternatively, you can use the Bridge API to do this. This is described in more detail on xUML Service Interface.
In short, send a GET to
/services/xuml/{name}/settings
to read all available settings, make your changes, and perform a PUT to write them.
Signal Triggered Transitions
The Persistent State tab of the Bridge lists all processes and their corresponding states.
Here, you can inspect the process and state details, and trigger available signals. In the screenshot above, you can see a process in Error state. You can trigger a retry by sending OrderApprovalRetry, or abort the process by sending OrderApprovalAbort.
Alternatively, you can use the xUML Runtime API to send those signals. This is described in more detail on xUML Service Interface.
Regarding the example above, you could send a POST request to /pstate/classes/OrderApproval/objects/00000e8477.../signals/OrderApprovalAbort if you wanted to abort the process.
On this Page:
Related Pages:
Related Documentation:
Overview
Content Tools