Get rid of annoying data corruptions with Appian process locking
By Aaron Emmert
We’ve all been there – we’re working on something and end up having to do it all over again because our changes weren’t saved or they were overwritten. All of our hard work is gone in an instant. “If only there was a way to prevent this from happening!” Lucky for you, there is. Within Appian, a low-code business process management (BPM) software, you can add process locking to help reduce data corruption.
Dirty writes
Dirty writes are when a user saves their changes at the same time that information is also being worked on by someone else. It’s “dirty” because their recently saved changes will be overwritten.
In Appian 19.3, there’s no locking currently implemented. What does this mean? Well, even though you have the right visibility logic to allow only some people to work on a specific action, you need to include an additional check to see whether someone else is already running that action. Without this, there’s a risk of dirty writes and data corruption. The more users working on actions, the bigger the risk.
One way to reduce this risk is to put in your own pessimistic locking into an Appian process. This will make sure only one user is working on a task, getting rid of the data corruption risk.
Pessimistic locking
Pessimistic locking is a user-friendly way of implementing locking on actions. Basically, whenever a user wants to edit an object, they “check it out” so only they can make changes to it for a period of time, or until they’re finished. Think of it like checking out a library book; someone else can’t read it until you’ve finished reading it and checked it back in.
This is different from optimistic locking, where the user is only warned when a collision occurs. In that case, how is the user supposed to know which changes should be kept, theirs or the other? Pessimistic locking gets rid of this dilemma.
Locking the minimum
Chances are users will like having this locking mechanism, but they won’t want it to slow down their productivity by getting blocked by locks. This can happen if the lock is being applied too broadly; when even though a user might only change a few items, the system might lock many other unrelated fields. Therefore, it’s important to get to a very specific level when applying your locks so different users are able to work in the same object, but each on unrelated values.
Now think of it like taking your car to the mechanic. Multiple mechanics can work on it at the same time if the parts don’t directly impact each other; one can do an oil change while the other puts on your winter tires. Don’t lock the whole car; lock only what needs working on.
The implementation overview
The below screenshot shows two workflows.
1.
2.
The first workflow acts as the lock. The second workflow shows a specific action you want to lock. Place the lock towards the front of the process. Since the lock is technically a process, you can add dynamic information in the process task name. Then other process locks can view this information to help determine which process is currently modifying data.
Let’s walk through an example.
Let’s say Mary just initiated the process “Order Supplies” for record ABC. The first thing the process does is start the “lock” subprocess. The “lock” queries the process report for other active “Order Supplies” for record ABC. None are found so the subprocess does not terminate and allows Mary to see the “Order Supplies” form. The lock changes its display name to tell the process to let Mary through.
Now let’s say John also initiates the process “Order Supplies” for record ABC. John’s process does the same thing by starting the “lock” subprocess and then queries the report. His process finds Mary’s active process and the “lock” with an active status. Therefore, instead of seeing the “Order Supplies” form for record ABC, and possibly overwriting Mary’s changes when he submits after her, he sees a form telling him that Mary is currently ordering supplies for this record.
With process locking in place, you can feel good knowing that whatever changes your users make, your data integrity will remain strong without slowing them down.
About the author
As an Appian developer, Aaron strives to meet and exceed the expectations of our clients. He grew up in Superior, Wisconsin, where he’s a fan of the Packers, dairy products, and cider. His hobbies include walking the dog, exercising, reading and playing video games.
