This topic is locked

Guide 77- Executing tasks in queues in the background

1/26/2024 2:12:30 PM
PHPRunner Tips and Tricks
fhumanes author

img alt
I am very happy with this exercise, since it is something that the systems had (Oracle Forms and Report, for example) and it is very common in large systems, but it is not seen in Web Forms systems and is greatly missed.

We are used to Web Forms applications (like the ones we make in PHPRunner) for everything to be executed at the same time it is requested and this does:

  • That users remain “hanging” during the time the request is completed.
  • We have no way of ensuring the correct functioning of the system, since these long and heavy processes try to capture all the system resources and we have no way of limiting heavy executions, nor sequencing them so that all requests do not compete with all requests.
  • Applications for many users, makes these systems unstable and can “hang” with some ease.

Objetive

Have a system of different task execution queues in the “background” that allows us to regulate the load of the systems and ensure that heavy tasks are executed in order and sequenced, so that they do not saturate the system.

DEMO : https://fhumanes.com/scheduler_queue

Users: admin/admin and user1/user1

If you are interested in this article, continue reading it at this link.

fhumanes author 1/26/2024

Technical Solution

What I have done is give the application the possibility that long and heavy tasks can be executed in the background so that it does not get “hooked” on the user. In this way, reporting processes, updates of many records, communications with other systems or simply sending emails or similar processes are executed without being “hooked” to the user. When these tasks finish, through the Notification system that PHPRunner has, it notifies the user of their completion and provides them with information about the execution and even the files that may have been produced in these processes.

img alt
All tasks that can be executed in Background must be defined.
(1).- All tasks have a code (unique value in the system) and it is the one that will be used to request its execution.
(2).- The execution queue is defined. Executions are grouped by queues. In this example 2 queues have been defined. FAST (for fast tasks) and HEAVY (for very heavy tasks). This allows us to execute in parallel, but sequenced, tasks with lower resource costs and others that take longer to execute.
(3).- The command to be executed is established, including fixed parameters. Values ​​enclosed in curly braces “{}” are used so that the values ​​are calculated at run time. This allows us to move information between systems (development and production).
(4).- Just for the example, this button has been programmed to request the execution of the task. You can see the code so you can appreciate how simple it is to request execution.

img alt
This screen is only available to the “admin” user.

(1).- This is the block of information that is updated in the execution request. Tasks go through 4 states.
(2).- This is the block of information that is completed in the planning and execution of the task
(3).- When the task is finished, a new notification appears to the user who made the request.

img alt
(1).- If you click on the notifications button, it shows all the ones we have and the first one on the list is the most recent.
(2).- Information about the completed task and if we click on this information it provides details of the execution.
(3).- This icon shows the notifications that the system had not shown us.

img alt
Facilitates the detail of the execution of tasks.
(1).- Shows the result (message that the task has left us) in the “Result” field. And it also shows the files (reports, reports, etc.) that the task produces.
(2).- The “Close” button deletes that tab from the browser and returns you to the tab you were working on.

If you are interested in this article, continue reading it at this link.