- Question.
-
After automatically launching a large number of cases that include automated steps, the completion of subsequent automated processing and the arrival of tasks have become slow.
- Answer.
-
The workflow engine is in a backlogged state. There are too many active tokens, causing the internal processing queue to build up.
When a case is launched, the token on the workflow advances through each step in order. The job queue within the workflow engine executes the following processes sequentially:
- Token movement processing
- Execution of automated steps
- Task assignment and offer processing in Human Task steps
This job queue is not observable by users. When a large number of cases are launched simultaneously, these processes accumulate in the queue in large volumes, and the wait time before each one is executed becomes longer. The impact affects not only the launched cases but all users on the same environment.
Particular caution is needed for Workflow Apps that contain many automated steps or OR/AND gateways. Human Tasks naturally limit the load on the queue because tokens stop until the assignee processes them. On the other hand, automated steps execute continuously without the token stopping. Furthermore, when OR/AND gateways are involved, tokens multiply, further increasing the load.
To resolve this situation, you need to reduce the number of active tokens. By force-terminating unnecessary cases, the load on the processing queue is reduced, and the processing speed of the remaining cases will recover.
As a preventive measure going forward, when launching a large number of cases for such Workflow Apps, limit the number of cases launched at one time. It is recommended to pace the launches so that a large number of in-progress cases do not accumulate.
The method of launching does not matter. This phenomenon is not limited to launches via HTTP requests or REST API. It occurs regardless of how the cases are launched in bulk, whether manually, by email reception, by timer, or by any other method. The cause is not the launch method but the simultaneous increase in active tokens that causes the job queue to build up.
