Applies to version: 2020.1.x; author: Marcin Wiktor
For applications with a large number of interconnected workflows there is often a problem with performance these applications due to creating/moving multiple workflow instances at the same time. The speed of creating/updating sub-workflows depends on many factors such as the type of the form, the amount of data/actions/rules, the speed of response from external sources, server load or overall performance. When trying to update tens of sub-workflows the maximum execution time (timeout) may be exceeded.
The case below shows us how can we deal with this problem by using only the standard WEBCON BPS functionalities. You can create a queuing mechanism that will update ten documents at a time.
We want to create the application “The settlement of business expenses” that will allow our employees to settle individual business expenses. Due to the fact that there is a lot of single expenses in our company, we want the accounting department to receive a group review of expenses instead of individual tasks.
Let’s create the simple application that allows our employees to register individual business expenses. It will contain two steps:
- Registration of business expenses (steps: Registration – Waiting for settlement (system step) – Archives/Rejected
- Settlement of business expenses (steps: Registration – Waiting for settlement (system step) – Archives
The application “The settlement of business expenses” will allow you to group dozens of single expenses. The accounting department will be able to decide what to do: undo for correction, accept or reject each expenses separately.
The next cyclical action will search each of the instances and ten instances will be updated at the same time. We do this for improving application performance and preventing situations in which too many actions or operations (at the same time) will cause a timeout.
In the production environment you must assess what quantity of instances can be reasonably updated at the same time. You should take into account the number of actions on the path, possible integrations with external systems, and the overall performance of the server. For the purpose of showing the operation of such a mechanism – let’s determine that we will update 10 instances at the same time.
In the background, a second cyclical action will be running, which will move all settlement instances to the archives (in which all expenses have already been updated).
Fig.1. New expense reporting form
Fig. 2. Form for settling reported expenses
Let’s create the queue mechanism in such a way, that the cyclical action takes only those instances that haven’t been moved in the previous cycle. For this purpose, we need to add a new form field – a simple checkbox technical field which will store information on whether the expense has been moved or not. By default we set it to “NO”, because at the beginning all expenses will be waiting to be moved.
Fig. 6. A cycle that shifts expenses
The next step is to support the transfer of expenses from the level of the “Expense settlement” workflow. At the “Waiting for completion” step we must prepare two actions:
- The action responsible for moving ten expenses to the appropriate step (depending on the accounting decision)
- The action that updates the list of expenses on the settlement stage, indicating which expenses were updated by the first action
Fig. 9. Actions on the path “Check if all expenses have been settled”
Configuration is now ready. Let’s try to add several expenses and try to settle them. After the first starting of the cycle, ten expenses should be updated, and in the second run, the remaining ones will be updated.
Fig. 12. Settlement pending complexion
After the first execution of the cycle, we can see that only ten expenses were updated and the “Settlement” workflow instance still remained in the “Waiting for completion” step.
After the second execution of the cycle, the remaining four expenses have also been updated. All expenses are moved and therefore the settlement instance has been archive.
The above example shows only a simple workflow – the complexity of the process will depend on businesss requirements of your company. Therefore, such a mechanism should be properly thought out in terms of the mode of operation, and the amount of data we are able to processes in one cycle.