Cyclical actions

Applies to version: 2020.1.x; author: Marcin Wiktor

Introduction

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.

Business case

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

Fig. 3. Connection diagram between processes

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. 4. A form field that will mark the updated expenses

Fig. 5. Control step configuration – Have all expenses been updated?

Fig. 6. A cycle that shifts expenses

Fig. 7. Configuration of the 1# Cyclical action

Fig. 8. Configuration of the 2# Cyclical action

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”

Fig. 10. Configuration of the action “Move expenses”

Fig. 11. Configuration of the action “Expense updated”

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.

Fig. 13. List of expenses after the first execution of the cyclical action

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.

Fig. 14. List of expenses after the second execution of the cyclical action

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.