Business Rule executing in an infinite loop

[Anish Somadevan]

In order to implement a retry logic in specific part of the code in my business rule I made a mistake that ended up the rule executing in an infinite loop. Although I have reverted back the changes, I can still see the logs of the previous code executing every second and cluttering the complete logs. I tried disabling the business rule, but that didn't help and the logs continue to pile up. Is there a way to stop this execution?

Regards,

Anish

[Tony Chatfield1 · Accepted solution]

Hi, if the transaction is running with your credentials you may be able to terminate it with this URL in browser

<instance>/cancel_my_transaction.do

If not, can you see and kill the transaction in active node transactions

<instance>/now/nav/ui/classic/params/target/v_cluster_transaction_list.do%3Fsysparm_query%3D%255EGROUPBYnode_id

Note: you should not 'delete' the transaction as it will not cause desired result, but use the 'kill' action.

[Anish Somadevan]

Thanks a lot. I was able to use the second option you provided to kill the required node transactions. On a side note, can you please suggest me what's the best way to implement retry mechanism in business rules? My business rule runs on the Incident table on async, and gets the information about the incident, transforms it and makes a HTTPS POST call to a 3rd party endpoint. There could be scenarios where the 3rd party endpoint might not be available intermittently, and so I would want to retry the API call a maximum of 5 times, each call separated by a minute's interval. Should I use gs.sleep() and with a retry counter or is there any retry mechanism out of the box that can be used. I noticed the Retry policies defined for HTTP calls, but I am not sure if those apply for business rules as well.

Regards,

Anish

[Tony Chatfield1]

Hi, if you use the ECC queue for your messages, there is an ECC retry plugin that you can request via SNC support, but documentation seems to be hard to find.

Plugin Required to activate the ECC Queue Retry Policy - Support and Troubleshooting (servicenow.com...

Flow also offers retry functionality.

Retry policy (servicenow.com)

and I would move my integration code to a script-include function(s) and then use flow to manage the integration.

Personally, I do not consider any sort of 'delay' in a script as being best practice as these types of solutions do not scale well and can impact platform performance.
What happens if the target goes down\doesn't respond and your platform triggers x hundred or thousand occurrences of your delay script.

[Anish Somadevan]

Thanks for the suggestions. Will try to use Flow designer and script-include and see if it works for me.