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]

The script which creates the task, is it created from a business rule.

Can you check if it is an async business rule? You may need to make it async and also in the script wait until   you receive the response. So only when response is not empty, create task.

[Ahmad6]

Hi Sanjiv,

The BR which kicks off this whole process is async, running on the attachment table (when the pdf gets inserted into the attachment table). The rest of the functions (convert to txt, locate correct request/task to update, update/create task) call each other until they update the task. the BR only kicks off the script.

If I have an async BR when the task_sys_id field changes, will this mean that if the functions are running twice they will no longer run in succession? I understand from what I've read about async I'll need to perform a second check inside the script to make sure that the field is still empty, however this means that there will no longer be a situation where the task_sys_id field is updated by 2 different scripts at the same time?

[SanjivMeher]

Hi Anmad,

The BR should only run on insert and should be async, so that it only trigger one script. If it BR has both insert and update flag ticked, it may create a duplicate task.

When you run async, you don't need to do a second check. make sure the script you are running do an query to the facilities request and update the task_sys_id field after receiving response.

[Ahmad6]

Hi Sanjiv,

I did pick up on that async BR running on update and insert, i've unticked update to see if that fixes the issue before I proceed further. Can you please expand on what you mean by updating the field after receiving a response? Just to clarify the BRs that I have running in our system below:

1. First BR (async insert/update), when a pdf is modified/added to sys_attachment table matching the right name format, a function is called convert_pdf_to_text(current.sys_id,current.table_sys_id). This function then calls another function to update the request once the text file is processed (can't see why on update should actually trigger by the way, unless the attachment is inserted first and then the request sys_id is added shortly after).

2. Second BR (before insert) on the task table when the request.task_sys_id field is not empty and task is automatically created by system, then abort action. The first time the function above runs this BR won't trigger, but if it ran a second time then it should trigger and abort insert.

Hopefully removing the update tick on the first BR fixes it all, but if it doesn't can I make the second BR async with the first line of the script checking again to make sure the task_sys_id field is still empty before aborting? and should making that second BR async mean that now all insertions into the task table are performed asynchronously? should I take it even further and remove the conditions on this BR to force all task insertions to happen asynchronously, seeing as it's only really one or two new tasks per minute being created?