WFE Lock/Unlock => Flow Designer Equivalent? (sys_mutex, GlideMutex(), ... )
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-01-2025 03:13 AM
Hi there,
I am looking for ServiceNow-supported/recommended advice on implementing a generic Mutex / Exclusive Access solution for (short-running) Flowdesigner Action Sequence. It must be ensured, that only 1 instance of the critical sequence part is running at a time.
(Use cases: take item from external pool, mark it as used, OR: submit a SC request as a sub request, inhibiting MIX of shopping cart by parallel flow running from another RITM with same user / cart context)
Basically, WorkflowEditor Core Utility Functions Lock/Unlock implement seemingly exatcly that (although I never used - but knowing the concept from other environments)
Investigating, I stumbled over several things , like sys_mutex table, and GlideMutex(), and vague references to "Wait For Condition" (this, imho, requires a COMMON "central" record between 2 or more concurrent RITM workflows, which isn't there - so, I don't see how to make wait 1 RITM flow instance waiting for another (unknown) one syncing on a (non-existing) common record.
GlideMutex() (with take() + release(), might need (or has) a timeout option , but it's rarely documented or rather hidden - and I did'nd get it work so far, although I would expect it works with sys_mutex-table - I suspect some permission issue or other restrictions)
Does anyone have a good description with a working example for such a basic core functionality, that I assume is there in some form out of the box? I understand that it might be critical in terms of creating dead locks when misusing, so timeout and "admin-release" functionality needs to be foreseen)
(So far, there is an event queue approach with serial/single event processing, but that requires to port the critical action into the Script Action definition, rather than keeping it in the Main Code flow and just embrace it by LockStart/Unlock.
I look for something like:
- flow action 1
- flow action 2
- mutex.requestAndWaitForLock(keyIdentifier, timeout) <=== ("Lock")
- - if (taken / no timeout in waiting for lock)
------- DO the CRITICAL action(s)
------- mutex.release(keyIdentifier) <=== ("Unlock")
- other actions and subflows, that have no concurrency issue
...
Thanks in advance!