Sometimes we need some extra time to let our transactions finish. Most of the times there is a solution for that script to make it be processed faster due to an improvement in performance: refactoring the code, using a different approach or simply ensuring the feature is still required are some of the actions we can take to deal with that time-consuming transaction.
If nothing of what is mentioned above works for you, you can always increase the timeout timer that is expiring and causing your transaction to be cancelled. These timers can be tweaked at the “Transaction Quota Rules” module, under the “System Definition” application. Let’s have a look at the “UI Transactions” one, as it is probably one of the most relevant to talk about. This “Transaction Quota Rule” will cancel -among many others- UI Actions or Business Rules that exceed 298 seconds.
For the sake of example, let’s imagine in our business rule we add a “gs.sleep(300000)” instruction as the one shown below. The transaction that will process this Business Rule will be “killed” by ServiceNow because it always takes more than 298 seconds to complete.
ServiceNow don’t analyse the code to check if it is taking too much time to be processed or if it is simply waiting. Someone could think that maybe if we split that gs.sleep into two with half the time each, it could work, but it is not the case, as the transaction is counted from the beginning the business rule is triggered till the moment it is finished.
The easy solution would be increasing the “UI Transactions” “Transaction Quota Rule” mentioned above to 350 seconds, for instance. That should be enough to wait for the sleep instruction and do what needs to do just after.
However, -as mentioned at the beginning of this article- sometimes there’s a better approach, and this case is a great example. The best practice would be calling an out of the box script include called ScheduleOnce that would let us schedule the execution of our script in an asynchronous way. Bear in mind gs.sleep is synchronous and that is why is being killed, because the business rule will remain being executed for those 5 minutes.
By using ScheduleOnce we are scheduling the execution of our script to be executed after those 5 minutes, but its execution won’t be consuming any resources in the meantime.
As you can see, the script can contain variables being used in the Business rule, we only need to build the script carefully to respect the quotes and double quotes required.
One last thing to notice is that ScheduleOnce expects seconds and not milliseconds to define the time it needs to wait. If you don't realise about the "setAsSeconds" method, you may end up scheduling things for a few days or weeks later than what you were trying to.
Conclusion
If there is an alternative to your time-consuming transaction, go for it! Improving the performance of a transaction is always the best practice. If the transaction is as much efficient as it can get, then increasing the "Time Quota" may be the only alternative.
If this blog article was useful to you, please click on “Helpful”
Other blog articles created by me:
