How can I ensure a business rule runs in a "single threaded" manner?

[aray]

I have a situation where I have many records hitting a table at once.     There is however an order, and the auto number field gets the order right.  

It's important that the first record is processed completely by the business rule, before the second record begins processing.    

The issue I have is it seems that in Eureka if multiple records hit the table in rapid succession, they are processed at the same time.     So records 1-4 are processed at the exact same time, which doesn't help me.    

I've tried experimenting with writing "lock" type records into a temporary table, but this has proven unreliable since all of the threads go and write the lock file at the same time.

Any ideas on how I can force a business rule rule to run in a single threaded, ordered mode?       Can be before or after type, doesn't necessarily matter for my purpose.

Thanks!

[Andrii]

Good question - one of those that touch parallel processing principles. I'm not gonna provide you ready solution but the idea that comes to mind is to have one entry point where the ID or a record that is being processed at the moment will be located and every other request for processing would to this place and check if it is empty or it has the same ID as a record itself.

[aray]

Thanks for the feedback, we ended up implementing this a scheduled job that runs on a time basis.

Scheduled jobs seemed to be the only thing that we could find to ensure only one process/thread was running at a time. Everything else would conflict -- basically 4-5 threads would kick off at once, all try to access the same lock file / flag / or state record at the same time and yield unpredictable results.    

The ideas of creating a Run Once, or an Import Sets were good, but we have extremely high volume number of records being processed.     Import Sets and Run Once make a lot of "extra" writes and aren't as efficient for our purpose.  

Thanks!

[johnnyd54]

Little late on this but I just faced the same issue. My idea is to have a random sleep variable from 1 to 10,000 milliseconds at the start of the business rule. That way if records are getting created at same time, that's fine since the business rules will start their logic at different times(Unless the 1 in 10000 chance of a duplicate sleep variable happens). I'm going to test this now but in theory I think it would work

[shahidkalaniya2]

Hi All,

I have a requirement, where multiple emails are received at ServiceNow for the same issue reported by the same user, which creating multiple Case records via Inbound email action.

I considered writing a logic in the inbound email, to check if an existing record is present - skip creating a new Case. But considering Multi-threads, more then one case is getting created as multiple emails are getting processed parallelly.

I had a thought to fix the above via a Script action - triggered via event from the inbound email. The only concern - how can I restrict that the events should be processed on a single thread? Only that will resolve it.

Appreciate any suggestions on the above or any new idea.

Thanks!

@Ankur Bawiskar @Chuck Tomasi 

[Nikolay Mikheev]

Hi,

We have exactly the same requirements with one difference - incoming requests come from an external monitoring system as REST API calls to create incidents. They can be conditionally Down (when the problem is detected) and Up (when the problem disappears). Occasionally there can be less than a second between requests (Flapping service). And the order of processing is much more important to us than the speed - and multi-threading is a big hindrance here. Is it possible to use something like mutexes or semaphores in ServiceNow?

Thanks