Process States

In this section, we describe all possible states a process can have and how they are related.

CREATED

Definition: The process is created.
The default state when a process starts. This state continues as long as no WorkerQueueItem is edited.
Possible next states: RUNNING, SUSPENDED, ERRORSUSPENDED

RUNNING

Definition: The process is running.
Possible next states: COMPLETED, SUSPENDED, ERRORSUSPENDED

COMPLETED

Definition: The process itself is completed. There are no more tasks to execute.
Possible next states: none

SUSPENDED

Definition: The process is suspended (paused).
Possible next states: always the state before the process was SUSPENDED

ERRORSUSPENDED

Definition: The process was suspended (paused) due to an error.
Possible next states: always the state before the process was ERRORSUSPENDED

TERMINATED

Definition: The process is interrupted.
Technically, this state has no further meaning. It simply notes that a person terminated a suspended process.
Although it is technically possible to continue the process, it probably should not be continued.
A terminated process is not completed.
Possible next states: none

Process Actions from a Technical Point of View

Here we list the details of the actions that can be executed by the user, including the resulting state.

start

Sets the state to RUNNING and creates an instance of MainActivity.
Writes the process start in the process history.
You can start a process that has the state SUSPENDED. This creates the process but does not start a MainActivity instance.

finish

Sets the state to COMPLETED and sets the time the process ended.
Logs the end time of the process in the DMS history of each process file object.
Triggers the relocation of the process history.
Removes the user configuration from the database.
Marks the process as finished in the process history.
If there is a parent process, it is informed that the process is finished.

suspend

Stops all activities in a process.
Pauses all periods (delays or deadlines).
When due to an error
- the process history notes that the process was stopped due to an error.
- the ERRORSUSPENDED state is set.
When not due to an error
- the process history simply notes that the process was stopped.
- the SUSPENDED state is set.
If the process is to be terminated, the TERMINATED state is set.

resume

Sets the process state back to what it was before it was suspended.
Resumes all periods. If their fire-time is in the past, they are executed immediately. Otherwise, they continue ticking.
Sets the state of all process activities back to the states they had before they were suspended, while taking into account any deadlines or blocking periods.
The process history notes that the process was resumed.

Process Data Fields

Process Data Types

Basic
- Long
- Date
- LocalDate
- Boolean
- String
- Decimal
Complex
- Record
- List
- Set
- Codesystem

Attributes of basic data types

String

The data type String has an additional attribute, "regex". You can specify a regular expression to define which values can be saved. If you use a form to save values, the form checks the regular expression for each character entered in the input field before saving. If you don't use forms and change values via scripting or the REST API, the regular expression is checked on each save call.

Examples

German postal code: "\\d{5}" → you can enter only five digits.
Minimum and maximum length: ".{3,15}" → you can enter any character, but the length must be from 3 to 15 characters.

Important

The regular expression is stored as a string value. To escape the backslash character '\' , use "\\" .

Transition Types

About Multiple Transitions

A workflow activity with multiple outgoing transitions uses a split activity (“workitem” in screenshot), while an activity with multiple incoming transitions uses a join activity (“workitem_4” in screenshot). Each activity has a type, AND or XOR, which determines the behavior of the transitions. In yuuvis® RAD, the default split and join types are both AND.

Transition Process

When a transition is executed, the TransitionExpression event is fired first. If the return value is TRUE, the event script “transition” is executed. Before the target activity can be executed, the targetActivity.isCreatable event is also evaluated. If isCreatable returns TRUE, then the target activity is executed.

Whether a target activity is executed depends on both its split and join types. The types are described in more detail below.

Split Type AND

In an AND split type, all transitions are executed, in order of priority. The transition with the highest priority is executed first. If no priority is set for a transition, the default is 0 (lowest).

If the target activity has only one incoming transition, the activity is executed immediately after successful execution of the transition.

Split Type XOR

In an XOR split type, only one of the transitions is executed. The transition with the highest priority is checked first. If the evaluation returns FALSE, the transition with the next-highest priority is checked. The first transition where both TransitionExpression and targetActivity.isCreatable return TRUE is executed. The remaining transitions are ignored.

Join Type AND

In an AND join type, the target activity is executed only after all incoming transitions that can be executed have been executed.

If a transition path cannot be executed, for example if an event script prevents it from returning TRUE, this transition is ignored. All other incoming transitions are executed, and then the target activity is executed.

Join Type XOR

In an XOR join type, the activity is executed as soon as the first incoming transition is successfully executed. The activity is only executed once.

If the remaining transitions are executed later and return TRUE, the activity is not executed again.

Executing BPM Processes with workerqueue

While a BPM process is being executed, the process state constantly changes. To reach the next state in the process, a workerqueue item is created. The item contains all necessary information about the process, scope or activity, as well as the next process state.

The workerqueue item is pushed to the messaging system to balance the system load. The BPM microservices process the message and call the dms-service to change to the next state of the process. For example, the start condition may create an activity, or not.

Due to concurrent processing, the workerqueue item may fail if, for example, a database resource is blocked by another thread. When this happens, the error count of the item is increased and the item is pushed to the messaging system to try again. This mechanism exists for all erroneous workerqueue items.

After the set number of retries has been executed unsuccessfully, the process fails and goes into an error state. At this point, an administrator has to resolve the issue.

To configure the number of retries for the workerqueue item, in management-studio go to System > Settings > DMS-Service > Workflow > Global > Max worker item error count. The default setting is 3.

Browser not supported