How can I prevent multiple users from accessing the same related action?

Hello:
Does anyone have a solution for how to avoid 2 users simultaneously triggering the same related action on the same record (assuming the related action would overwrite the record values).
We need a mutex solution, but I am not sure how to do this in Appian except through a database solution. Does anyone know of a mutex solution out-of-the-box in Appian?

OriginalPostID-215481

OriginalPostID-215481

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer
    Hey, check out this article from the Appian Playbook: forum.appian.com/.../Data_Locking_Strategies.html

    It outlines a couple of different options that you may find helpful.
  • We actually use a pessimistic locking strategy that's slightly different than the ones that are suggested in the playbook. We basically run a process report to check for an existing process on that record and display a message to the user indicating that the record is currently checked out.
  • For pessimistic locking, we implemented a solution where each related action had a timer (~10 minutes) and was configured as a quick task. This meant that if a user started a related action, no one would be able to perform the relation action.

    The exact mechanism that kept other users out was using a!queryProcessAnalytics and filtering on the rp!id to see if any related actions had been started and were still active for that specific record. If they had been started, the user would be directed to a form with a shorter timer to tell them that the record was currently being updated.

    For more complex related action interactions (let's say you want to be able to always do actions A and B, but C and D are exclusive) you can filter on the type of process model/ active task and the rp!id to determine the path of the XOR and lock users out.
  • I am not aware of anything out of the box. Would suggest to hide the Related Action if someone is already working on it.

    You will need a simple flag in database, then add a rule to check that flag in View condition of the Related Action.
  • The problem with the Data Locking Strategies is it is not user friendly. If the collision occurs at the updating of the data step, each of the 2 users trying to trigger the related action will spend X number of minutes editing the data, but only one users' update will go through. Instead, the locking should occur immediately at the beginning of the related action, and the user that cannot make the changes should be informed immediately before they take unnecessary action on the record. Process reports were how we were planning on designing the solution, but because of the random variations in the time it takes to pull the report, it is not a correct solution in that both related actions (2 triggered at the same time) could pull either 0 active processes, 1 active processes, or 2 active processes. What we need is a true locking solution to solve this. Does anyone have experience in building a dynamic mutex solution in Java for an Appian plug-in?
  • I would create a stored procedure run at the very beginning of the process which returns 'ok' if a flag in the DB is not set (proc also sets this hold flag at the same time), which allows the user to continue. The proc would also return 'not ok' if the flag is currently set, displaying a message to the second user about the item already being edited. In the first scenario, the user can continue to edit the item, clearing the flag when edits are complete or when a short exception timer fires on the user input task.
  • As real hard locking is nearly impossible to do without deep support from the plattform my idea is as follows: While the user modifies data on the form check if there is another instance of the same process is running and show a message in that case. You can even disable the whole form.
    When you do that check inside a with statement it is repeated on each user interaction. When you implement the process report in a clever way you can even show the name of the other user trying to modify the data. I will try to do an implementation of this and post my results here.
  • @stefanh That's pretty much the solution we chose to go with. It's been in production for 6 months now - works well, no issues.
  • How do you educate the user on what is going on? Disable the submit button? Replace the form by a message?