How do you handle your race conditions in BRs?

[Ahmad6]

Hi guys,

I was looking for some advice on how to handle ServiceNow being too fast for its own good. We had consultants assist with setting up a PDF parser: a certain incoming email with a pdf attachment creates a Facilities Request, and the PDF gets sent to a MID server to parse into a text file, then on attachment of the text file back to the request the information is processed, and a task created for the person responsible to action the request. We did not experience the issue in Dev, however when moving to production every now and then two tasks are being generated from the script which is confusing for everyone involved.

The sys_id of the task that gets automatically generated is saved in a new field in Facilities Request, so I thought I'd make a simple BR for all inserted tasks: If the task_sys_id field is not empty, and it's not the same sys_id, abort insertion of that new task. The problem is that when both tasks are being created, this field is still blank, so the BR is being skipped. I could easily implement a different BR to get rid of the second task (ie if the task_sys_id field is trying to be overwritten, cancel that update and find and delete the second task), however I'm expecting that the email notification will have already been triggered and sent to the user for this second task, so it's not the best solution.

Does anyone have experience with inserting an arbitrary pause in script includes? That way I could potentially pause the script by a random number of seconds each time it is called, forcing the two inserts to no longer be simultaneous allowing my BR to (hopefully) work.

[SanjivMeher]

According to my understanding,

You receive an incoming mail with an attachment, which creates a facilities request.

You run a async business rule on sys attachment table, which send a rest api request, receive the response and creates a task by populating update a field task_sys_id in facilities request table. This BR should only be running on insert.

So this one BR is doing everything you want.

Do you really need a second business rule here?

[Ahmad6]

Hi Sanjiv,

You're correct in your understanding (but instead of a rest API request, the pdf is sent to MID server to convert to a txt file, and txt file is converted to JSON then passed into functions). We only need that one BR, the second one I am trying to implement as a band-aid fix to one of the functions running twice, so 2 tasks are being created instead of 1. The problem is very inconsistent, and doesn't appear at all on our Dev environment, so I wanted to add the second BR temporarily until I can investigate further.

[SanjivMeher]

Ok. I think you should just keep one business rule and run it on insert. If you do that, do you still see the issue?

The 2nd BR can cause more issue and confusion.