Hello, my name is Cláudia and today I'm going to present a solution for dealing with timeouts on the OutSystems platform.
I'll use as an example a company that receives support requests.
Due to the high volume of requests, the company noticed a drop in the performance of their application and to mitigate this, they created a data archiving system.
In this system, closed tickets or tickets older than 6 months are stored in an archive database and removed from the main database. This reduces the amount of data displayed on the dashboard.
However, while testing the file logic, the company noticed errors in the Service Center related to timeouts and wondered how to deal with this situation.
By default, the time limit for running a timer is set to 20 minutes. Therefore, we will limit the execution time of the archive action to a shorter period of time and re-run it if we haven't archived all the records.
Our archive management application is called Timeout. Analyzing the action, we see that there is a query to the database to extract the old records, then they are iterated once, then archived in the archive database and removed from the main database catalog.
To avoid timeouts, we can start by dividing the processing logic into a smaller number of records per cycle, reducing the number of records we ask the database to process.
To do this, we should change the maximum number of records in our aggregate to a value that makes sense in the current context.
I'll create a local variable, change its name to "MaxRecords", and set the value to 10 in this scenario.
When we return to the aggregate, we'll need to change the defined value of "Max Records" to the value of our new variable.
After processing the cycle for 10 records, we should check to see if there are more records to process.
This means that we can make a decision with a condition, and we want to check that the total number of possible records to be returned by the database is greater than the maximum number of records we tried to process in this last interaction.
If this is true, we should run our database query again. And repeat the process for 10 more records.
Otherwise, all records have been processed and we can finish our action.
Reducing the number of records doesn't prevent the timer from running out, but it does prevent the transaction from processing in the database.
To handle the timer timeout, we'll first add a new variable, change its name to "Timeout", and set its data type to "Date Time".
At the beginning of the action, we defined that the timeout has a lower value than expected. For example, make a mapping where the timeout is 17 minutes.
Select an "Assign", select our "Timeout" variable and set the value to 17 minutes from now.
To do this, we can use some of the built-in functions that come with the platform, in particular, inside the "Date and Time" folder, we can use the "AddMinutes" function and inside it, call the current date and time and add the 17 minutes.
With our timeout defined, we need to check at the end of a process, and if there is more data to process, we're close to the timeout or not.
This guarantees a gap of 3 minutes between the maximum time we want the logic to run and the actual timeout of the timer of 20 minutes.
So we can add an If and change the logic so that if there are more records, we first check if we are close to the timeout or not.
In the condition, we need to check that our "Timeout" variable is less than or equal to our current date time (CurrDateTime), and if it's true, it means we've exceeded our timer.
In this situation, we will have to call a new timer again to go through all the cycle logic and finish our action.
Otherwise, it means that we still have time to go through a new cycle of registrations and we should target our query again, asking it to run for another 10 records.
With this implementation, we were able to manage the maximum number of records and, by checking for proximity to a timeout, ensure that we don't have performance issues or timeout errors in the future.
There are advanced solutions and different scenarios when it comes to asynchronous processes in OutSystems, such as dealing with not one but multiple timers or using Light BPT through processes.
I hope you enjoyed this and I invite you to join our Advanced Developer course available on the ITUp website where you will not only explore some advanced scenarios on this topic but also find other topics such as architecture, integrations, authentication and authorization and performance and good practices.
Thank you and see you next time!
