Process Engine Configuration

The Process Engine component manages process templates and process instances.

The configurable properties for the Process Engine component are:

Property Default Description
maxInstancesPerRestCall 50 If no $top parameter is passed, this dictates the maximum number of instances the server will return in a single REST call.
maxSubProcessCallDepth 100

The maximum sub-process depth that can be reached from a parent instance. The call depth is inclusive.

Example 1

  • If you have the following process hierarchy - main process > sub-process 1 > sub-process 2 > sub-process 3 > sub-process 4, and
  • the maxSubProcessCallDepth is 3, the parent instance halts if it tries to create an instance of sub-process 4. However, sub-process 1 could create hundreds of sub-processes without the parent instance halting.

Example 2

  • If you have a main process that calls a sub-process recursively, and
  • the maxSubProcessCallDepth is 3, the parent instance halts if it tries to create a fourth instance of the sub-process. This prevents a recursive sub-process loop from creating hundreds of sub-processes, and tying up the Process Engine, preventing the processing of other work.

maxTasksPerInstance 1000 The maximum number of tasks that can be generated by a process instance. If this threshold is reached, the process instance is halted.

A runaway process can generate a very large number of tasks within a single instance, resulting in a large number of Event Collector events for the instance, as well as a large number of rows in the database tables for the process instance.

You may want to configure this threshold if:

  • your process design contains a large number of loops or tasks.
  • you have long-running processes, whose task count may get large even though the process isn't running away.

If you set a high value, your system could stall if process instances reach a runaway state, as it will take time to reach the threshold. If you know your task per instance count, you may want to set the threshold to a lower value.

BPEL Maintenance
bpelPendingMessageProcessorNumMessages 500 The batch size for pending-message cleanup jobs, that is, the number of expired signals that are to be processed at one time.
bpelUnclaimedPendingMsgProcessorInterval P30 If system-wide locking is disabled (com.tibco.bx.lockOperation=false), this property specifies how frequently a background job checks for, and processes, unclaimed messages. Specified as either of the following:

  • P# - Where "P" indicates "periodic" and # is the number of minutes. For example, P60 causes it to check every 60 minutes. The lowest valid value is P1.
  • D# - Where "D" indicates "daily" and # is the hour number (1-24). For example, D20 causes it to check daily at 8 PM.

bpelUnclaimedPendingMsgProcessorNumMsgs 500 If system-wide locking is disabled (com.tibco.bx.lockOperation=false), this property controls the maximum number of unclaimed messages that will be picked up per execution. The minimum is 50.
  • bpelUnclaimedPendingMsgProcessorStart
false  
Global signals
  • globalSignalProcessorInterval
P30 Specifies how frequently expired global signals are cleaned up. Specified as either of the following:

  • P# - Where "P" indicates "periodic" and # is the number of minutes. For example, P60 causes the cleanup job to run every 60 minutes.
  • D# - Where "D" indicates "daily" and # is the hour number (1-24). For example, D20 causes the cleanup job to run daily at 8 PM.

  • globalSignalProcessorNumMessages
500 The batch size for expired global-signal cleanup jobs, that is, the number of expired signals that are to be processed at one time.