Imagine a scenario: you have a batch task that runs every five minutes to update your X3 system with the latest currency rates. The batch server goes down for 12 minutes for scheduled maintenance, but when the batch server comes back up again, the batch task runs three times. Do you care? Well, in this case it probably won’t matter too much, but what if the three runs caused contention and took hours to complete, whilst also impacting your user performance and efficiency.
The good news is that if you want to prevent this situation, you could consider implementing the “Allowable Delay” feature. This is described in the online help at https://online-help.sageerpx3.com/erp/12/staticpost/task-management/ Essentially if the task has not been executed at the planned start date/time, plus the specified delay (in minutes), then the task will be marked as being “out of time” and will no longer be considered for execution.
This delay could occur due to the batch server being stopped, the priority of the tasks being too low on a busy system to get selected or gets blocked because it is part of a group.
The example below illustrates how this works for separately submitted tasks:
- First, we’ll see what happens when allowable delay is not set
Setup 5 batch tasks to run every 5 minutes after the previous task
The first task (10524) completes OK
The batch server then gets shutdown and is not restarted for 12 minutes, so two tasks scheduled for 13:20 and 13:25 (10525 and 10526) have not been run at the appropriate time. When the batch server comes up, by default it will run the two missed tasks. We can see tasks 10525 and 10526 are now “In progress” status and complete successfully.
- If we didn’t need or want these two tasks to be run in these circumstances, we can set the “Allowable delay (minutes)” parameter in Usage, Batch server, Task Management to be 5 minutes.
To see the effect of this change, we resubmit the tasks to be run every 5 minutes again.
As before, after the first one has run (10536), the batch server goes down for 12 minutes.
When it comes back up, this time we see the two tasks (10537 and 10538) are processed, but when the tasks are considered they get flagged as being past the time limit, so are not actually executed. You can see this in the log file for the request as it says “Time limit exceeded” The other tasks (10539 and 10540) will be executed normally, as they are within the time limit or have not reached their execution time yet.
This is the effect we were hoping to achieve, so all is good.
- Recurring tasks
Recurring tasks work a little differently, so need to see what happens.
Submit a recurring task to run every 5 minutes.
Check it runs OK for the first execution (10743) and we can see the next task is setup to execute at 09:18 (10745)
Now the batch server goes down and comes back at 09:52. We can see task 10745 has been considered but did not run as it was past the time limit.
This causes a potential problem though, as the next task is not scheduled until the previous one completes. This means recurring tasks are not restarted automatically, and need manual intervention to restart them.
If you are using allowable delay with Recurring Tasks, it is therefore important to understand this is how it works and have a mechanism to cope with it.
Conclusion
I hope this article has shed some light on the Allowable delay functionality for you to consider if it would be useful for you to use.
Feel free to leave a comment below to let me know if you find this useful.
