Parameters for Process Engine Caching

For performance reasons, the Process Engine is cached. By default the cache is updated with Process Engine restart.

Process Engine caching behaviour can be modified with mainparameters. The mainparameters use multiples of Process Interpreter steps as time measure.

Process Interpreter Steps

Process Interpreter works in steps and the frequency of the steps is determined by parameter'stepInMillis' specified within 'cxf-servlet.xml'. This means that every defined time 'stepInMillis' the Process Interpreter checks running process instances for changes.
The default value of 'stepInMillis' is about 20s. Shorter values are usually used in test environments, production values will be longer depending on customer needs. Note that shortening the time increases the database server workload.

Two mainparameters for Process Engine caching exist:

Change the cache update interval

PATH: ProcessEngine.ProcessInterpreter
PARAM: clearResourceCacheEveryNStep

Default parameter value is 0. With this setting, cache is persistent during the whole Process Interpreter runtime, no automatic refresh occurs. To refresh the cache, Process Interpreter restart is needed. (Note that this does not mean a server restart, just restart of the Process Engine.)
Typically organizational data are quite static and there is no need for frequent recalculation. In projects where this is not the case, it is necessary to set up automatic cache refresh by specifying a non-null value for the 'clearResourceCacheEveryNStep' parameter while taking into account the currently used time in 'stepInMillis'.

For example, if 'stepInMillis' is kept at 20s and your project calls for cache reset every hour, than set
'clearResourceCacheEveryNStep' = 180
(180x20s=3600s)

Limit the frequency of reading condition and message events

PATH: ProcessEngine.ProcessInterpreter

PARAM: checkConditionalAndMessageEventsEveryNStep

The default value is 1. With this setting, the condition of message and conditional event are evaluated every Process Interpreter step. Depending on the number of running process instances and the complexity of evaluated conditions, it may be necessary to adjust the frequency by setting a higher 'checkConditionalAndMessageEventsEveryNStep' value.

For example:

If the Process Interpreter step is set to 3s and the actual check (depending on the number of generated sql statements) takes 11s...

The expected plan of process steps is:

initialize step 0
1. step 3s
2. step 6s
3. step 9s
...
N. step Nx3s

But due to fact that the real step takes about 11s, the reality is:
initialize step 0
1. step 11s
2. step 22s
3. step 33s
...
N. step Nx11s

Such situation can cause performance problems due to the huge amount of sql generated by the events condition check. To remedy the problem, you can:

1. Change the process design, if possible
2. Lower the frequency of check events.

   For example, to check only in 2-minute intervals (with the Process Interpreter step set to 3s), set
   'checkConditionalAndMessageEventsEveryNStep' = 40
   (40x3s = 120s)

Real-life Implications

Let's use person - support group mapping as an example of cache refresh implications. The mapping is cached. It means that when a person is assigned to a support group and then an RFC is created for the support group, the newly assigned person does not get a task until the cache is cleared. This may be troublesome if the refresh frequency is set too low or manual (i.e. Process Engine needs to be restarted for the refresh to occur). In such case, the refresh frequency needs to be adjusted in the above described manner.

Also note that resource cache is shared between all processes. In this case it means that all processes using a particular support group read the same values from cache. For example, if

• a Ticket process definition references 1st Level Support and 2nd Level Support
• an RFC Ticket process definition references 1st Level Support and Development

then both processes will share 1st Level Support caching.