Menu Close
Settings Close

Language and Page Formatting Options

7.2. Runtime State

7.2.1. Runtime State

Whenever a process is started, an instance of that process is created. For instance, look at an example of a process representing a sales order. Each time a sales order is requested, one instance of the sales order process is created and contains only the information relevant to that sales order. When that instance is stored persistently, only the minimum set of information required to continue execution of the instance at some later time is stored. The engine automatically stores the runtime state in a database, ensuring that whenever the engine is invoked that any changes are stored at the end of the invocation and at safe points.
If it is ever necessary to restore the engine from a database, it is important not to reload the process instances and trigger them manually. Process instances will automatically resume execution if they are triggered, for example, by a timer expiring, the completion of a task that was requested by that process instance, or a signal being sent to the process instance. The engine will automatically reload process instances on demand. It is important to note that the snapshot of the process will be reloaded, and any changes that have occurred since the snapshot was taken will be lost.
The latest snapshot state can be retrieved using the following:
ksession.getProcessInstance(id)
The runtime persistence data should be considered internal, and the database tables where the data is stored should not be accessed directly. Where information about the current execution state of a process instance is required, refer to the history logs see Section 7.4.1, “History Log” .

7.2.2. Safe Points

The state of a process instance is stored at safe points during execution of the process. A safe point occurs when the process instance has completed, aborted, or reached a wait state in all parallel paths of execution. When the process instance is stored persistently at safe points, the current state of the process instance and all other process instances that might have been affected are stored.

7.2.3. Binary Persistence

Binary persistence, also known as marshaling, converts the state of the process instance into a binary dataset. Binary persistence is the mechanism used to store and retrieve information persistently. The same mechanism is also applied to the session state and any work item states.
When the process instance state is persisted, two things happen:
  • The process instance information is transformed into binary data. For performance reasons, a custom serialization mechanism is used and not normal Java serialization.
  • The binary data is stored alongside other metadata about the process instance. This metadata includes the process instance ID, process ID, and the process start date.
Apart from the process instance state, the session itself can also store other forms of state, such as the state of timer jobs. The session can also store the data that any business rules would be evaluated over. This session state is stored separately as a binary dataset along with the ID of the session and some metadata. The session state can be restored by reloading the session with the given ID. The session ID can be retrieved using ksession.getId().
Note that the process instance binary datasets are usually relatively small, as they only contain the minimal execution state of the process instance. For a simple process instance, the binary datasets usually contain one or a few node instances, i.e., any node that is currently executing and any existing variable values.
As a result of binary persistence, the data model is both simple and small:
A data model that provides sessioninfo, processinstanceinfo, eventtypes, and workiteminfo nodes.

Figure 7.1. Data Model

The sessioninfo entity contains the state of the (knowledge) session in which the process instance is running.

Table 7.1. SessionInfo

Field Description Nullable
id The primary key NOT NULL
lastmodificationdate The last time that the entity was saved to the database  
rulesbytearray The binary dataset containing the state of the session NOT NULL
startdate The start time of the session  
optlock The version field that serves as its optimistic lock value  
The processinstanceinfo entity contains the state of the process instance.

Table 7.2. ProcessInstanceInfo

Field Description Nullable
instanceid The primary key NOT NULL
lastmodificationdate The last time that the entity was saved to the database  
lastreaddate The last time that the entity was retrieved (read) from the database  
processid The name (ID) of the process  
processinstancebytearray This is the binary dataset containing the state of the process instance NOT NULL
startdate The start time of the process  
state An integer representing the state of the process instance NOT NULL
optlock The version field that serves as its optimistic lock value  
The eventtypes entity contains information about events that a process instance will undergo or has undergone.

Table 7.3. EventTypes

Field Description Nullable
instanceid This references the processinstanceinfo primary key and there is a foreign key constraint on this column NOT NULL
element A text field related to an event that the process has undergone  
The workiteminfo entity contains the state of a work item.

Table 7.4. WorkItemInfo

Field Description Nullable
workitemid The primary key NOT NULL
name The name of the work item  
processinstanceid The (primary key) ID of the process: there is no foreign key constraint on this field NOT NULL
state An integer representing the state of the work item NOT NULL
optlock The version field that serves as its optimistic lock value  
workitembytearay This is the binary dataset containing the state of the work item NOT NULL