| 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.
It is possible for a runaway process to 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.
|
