Real-time Environment Locking - what are the use cases?

[DipinDevP]

Hi All,

Thanks for addressing my question!

Kindly anyone share a real time scenario were environment locking concept needs to be used. Everywhere we can see environment locking concept is explaining with Load Queue process. It would be great, if anyone can explain any other process in detail.

Thanks,

Dipin Dev P
RPA Professional

[devneetmohanty07]

Hi @DipinDevP ,

By concept we use Environment Locking in case of Multi Bot architecture in order to avoid more than bots performing the same set of actions if they are run at the same time. This concept is used when let say you have a workflow and you want to add queue items from a file or some data source. Now, potentially if you don’t use environment locks here, then when you trigger more than one bots and let’s say both of them come to this stage then they can accidentally add duplicate data since one bot won’t know what the other bot is doing now. Another example can be let say, you have an excel file which needs to be read or written. Now with excel files, we know that if one user has already opened it then the other cannot open the same, in such a case to avoid multiple robots accessing the same file you can have an environment lock applied so that once one robot acquires the lock only it can be the one to read or write on that file while the other can skip this part of the workflow.

Also, if there are session based applications such as SAP for example where let say only one user profile can login into the application from one machine and you have multiple robots having the same username but they are running on different machine. In such  cases, you would want to avoid both the robots accessing the application at the same time. You can use environment locks here so that while one robot performs all the action within the application, the other can simply keep on waiting at the start of the flow till the other bot logs out of the application or you can make it go to some other part of the workflow and skip the application part altogether. 

Usage of environment locks and how you want to use it for controlling multiple robots completely lies on how you design your workflow. Mainly this is used to avoids multiple robots performing the same set of actions and they can be used in ways to make those robots get utilised the best as per your requirements.

Please also feel free to read this thread where I posted a detailed explanation quite a while back too: Acquire Lock - Environment Locking

[Chakkravarthi_PR]

Hi @DipinDevP
A sample scenario. 

Scenario:

HR department uses multiple automated processes to handle various aspects of employee onboarding, including document verification, account setup, and training scheduling. These tasks often need to be performed in a specific sequence to ensure completeness and accuracy.

Challenge:

Without proper coordination, these processes might try to access and update the same employee's information simultaneously, leading to issues such as incomplete records, duplicate efforts, or missed steps in the onboarding process. For example, if account setup begins before document verification is complete, it might result in creating accounts for ineligible candidates.

Use Case:

Environment locking can ensure that while one process is verifying an employee's documents, no other process can proceed with account setup or training scheduling until verification is complete. This ensures a smooth and orderly onboarding process.

Steps: 

1. Start Document Verification Process
2. Acquire Lock "OnboardingLock" (Employee ID as parameter)
3. If Lock Acquired:
   3.1 Verify Employee Documents
   3.2 Release Lock "OnboardingLock"
4. End Document Verification Process

5. Start Account Setup Process
6. Acquire Lock "OnboardingLock" (Employee ID as parameter)
7. If Lock Acquired:
   7.1 Setup Employee Account
   7.2 Release Lock "OnboardingLock"
8. End Account Setup Process

9. Start Training Scheduling Process
10. Acquire Lock "OnboardingLock" (Employee ID as parameter)
11. If Lock Acquired:
   11.1 Schedule Training Sessions
   11.2 Release Lock "OnboardingLock"
12. End Training Scheduling Process

The more detailed flow to build you can follow @devneetmohanty07 steps. 

[DipinDevP]

Thank you for the detailed scenario! It is really helpful.
I may be less knowledgeable in this concept, so I have few doubts.

1) Is this scenario requires multipart processing?
2) Is locks are environment specific or process specific?

It would be great if you can explain, how environment lock concept works in this scenario, if we have 10 employees details in the Work Queue.

[DipinDevP]

Thank you very much @devneetmohanty07 for the detailed explanation! Your excellent knowledge in the concept appreciated.

From the reads, I understand we can design the process in a way to decide whether process needs to wait for the lock release or skip the particular part of the workflow without waiting for the lock. Please correct me if I am wrong.

I have a question - Suppose we designed a process - if one instance of the process acquired the lock, other instance can skip that part of the workflow. First instance acquired the lock and entered the workflow, but somehow second instance processing slowly (due to some technical issues) and didn't reach the part of acquire lock stage even after first instance completed the workflow part and released the lock. In this case, I think second instance also will get the chance to enter the workflow which is against the expected design. Please correct me, If I am wrong, or else do we need to handle this situation in the design itself?

Please ignore if it explained already.

[Chakkravarthi_PR]

Is this scenario requires multipart processing?

Yes, this scenario involves multipart processing. Multipart processing means that the onboarding tasks are divided into separate processes (document verification, account setup, and training scheduling). These tasks are executed in a specific sequence to ensure that all steps are completed correctly and no conflicts arise.

Are locks environment-specific or process-specific?

Locks in BP are environment-specific. This means that the locks are available across the entire BP environment and are not confined to a single process. When a lock is acquired, it affects all processes running in that environment, ensuring that no other process can access the locked resource until the lock is released.

I will give you a rough overview of steps: 

Work Queue Initialization:

• The Work Queue contains items representing the onboarding tasks for 10 employees, each identified by a unique Employee ID.

• Document Verification Process:

  • Start Document Verification Process
  • Acquire Lock "OnboardingLock" (Employee ID as parameter)
    • The process attempts to acquire a lock specific to the current employee's ID, e.g., OnboardingLock_EmployeeID1.
  • If Lock Acquired:
    • Verify Employee Documents
    • Release Lock "OnboardingLock"
  • End Document Verification Process

• Account Setup Process:

  • Start Account Setup Process
  • Acquire Lock "OnboardingLock" (Employee ID as parameter)
    • The process attempts to acquire a lock specific to the same employee's ID.
  • If Lock Acquired:
    • Setup Employee Account
    • Release Lock "OnboardingLock"
  • End Account Setup Process

• Training Scheduling Process:

  • Start Training Scheduling Process
  • Acquire Lock "OnboardingLock" (Employee ID as parameter)
    • The process attempts to acquire a lock specific to the same employee's ID.
  • If Lock Acquired:
    • Schedule Training Sessions
    • Release Lock "OnboardingLock"

End Training Scheduling Process

Now with 10 employees in the Work Queue: 

Processing Each Employee:

• For each employee in the Work Queue, the three processes (Document Verification, Account Setup, Training Scheduling) will run sequentially.

• EmployeeID1:

  • Document Verification Process acquires OnboardingLock_EmployeeID1, completes the verification, and releases the lock.
  • Account Setup Process acquires OnboardingLock_EmployeeID1, completes the setup, and releases the lock.
  • Training Scheduling Process acquires OnboardingLock_EmployeeID1, schedules training, and releases the lock.

• EmployeeID2:

  • The same steps are repeated for EmployeeID2, and so on.
    

    Detailed Example for One Employee

    EmployeeID1:

    1. Document Verification Process:

       • Start Process
       • Acquire Lock OnboardingLock_EmployeeID1
       • If Lock Acquired:
         • Verify Employee Documents
         • Release Lock OnboardingLock_EmployeeID1
       • End Process

    2. Account Setup Process:

       • Start Process
       • Acquire Lock OnboardingLock_EmployeeID1
       • If Lock Acquired:
         • Setup Employee Account
         • Release Lock OnboardingLock_EmployeeID1
       • End Process

    3. Training Scheduling Process:

       • Start Process
       • Acquire Lock OnboardingLock_EmployeeID1
       • If Lock Acquired:
         • Schedule Training Sessions
         • Release Lock OnboardingLock_EmployeeID1
       • End Process

Environment-Specific Locks: Locks are environment-specific, meaning they are accessible across all processes within the Blue Prism environment.

[devneetmohanty07]

Hi @DipinDevP ,

Yes, your understanding is correct that we can design the process in a way to decide whether process needs to wait for the lock release or skip the particular part of the workflow without waiting for the lock.

The locking mechanism by design is built to handle scenarios where multiple runtime resources access the same flow at the same time itself even though there are instances when let say if one resources responded slowly it can acquire lock by the time other resource released the same in it's own session.

Such discrepancies should be handled as part of the solution design itself. For instance, as a best practice, whenever we deal with addition of items to queues, we use environment locks but at the same time we also use additional logic to check if each of the queue items are already added with the same Item Key or not so that addition of duplicate items can be avoided.

Also, one other method that I have seen people using is putting the Release Lock action near the end of the entire process. In such cases, they use Acquire Lock at the beginning but use Release Lock towards the very end of the process which ensures that for a specific action even if we are using environment locks, they shall be released only towards the very end of the current session ensuring the other parallel process session does not picks it up during any time the first session is actively running. However, I don't recommend this as it becomes tough to locate the release actions from a readability perspective during audits and code reviews and potentially one can miss to have this added properly while working on the exception handling part.

For scenarios, where let say you need to send out an email based on the completed or failed queue items, we generally keep such reporting logics in a separate process itself and we ensure that only one runtime resource is running that automation on the scheduler level itself. So multi-bot architecture itself won't be applicable for such reporting-based processes.

In my other projects, we also have used session specific files or process specific database tables where we can read and update flag values from our runtime resources to action upon items as an extra check to control a set of actions from getting executed on top of Environment Locking.

Again, while designing the solution, each of the situation needs to be considered and just having Environment Locks by itself can't help.

[DipinDevP]

Thanks @Chakkravarthi_PR @devneetmohanty07 for the detailed explanation. Much appreciated!
I may have more queries on this topic and other topics. Expecting continuous support from everyone.

[Ernest1]

Hello,

Thank you for these posts, thanks to I know more about Environment Locks.

However, do I understand correctly that if I run a process on several resources and let's say each resource is different (e.g. slower or faster) if the process on resource 1 executes the last element from the queue three times faster than it will on resource 2 and moves on to the final steps faster, e.g. starts removing processed elements from the queue (see template 2 - advanced scenario), then the environment lock makes no sense, because de facto it is difficult to determine the time for which this lock should be set, to avoid situation when the process from another resource will finish last element and will go to the same steps, means starts removing processed elements from the queue.

Additionally, if the process is working on 2 or 3 resources and after an hour or two of work it turns out that I should run the process on the next resource to complete the elements according to the SLA or faster before the deadline, do I understand correctly that here too the environment lock that we have when adding elements to the queue makes no sense (here we have to add an additional check whether the same element exists in the queue).

Please let me know if my understanding is correct.

Please also provide the methods you use to ensure that selected process steps are executed only once, regardless of the number of resources the process is running on and their execution time (apart from locking the environment).

Many thanks,

Marcin

[Denis__Dennehy]

Great answers on this thread!  As mentioned,  the main use of environment locks is to build logic into automations that allow multi-robot solutions to have parts of a processes logic that only one robot can do at a time.  That might be logic related to setting a system password or more often logic related to loading the work queue.

You might be wondering why they were called Environmental Locks?  Environmental locks were originally created many years ago as a mechanism to help multiple background task automations running at the same time in the same VDI environment when there was some part or parts of the automation that did require foreground interactions.  
So, as an example,  you have 10 robots all running in the same windows environment and 99% of the time they are interaction with a mainframe application using background objects.  This allows concurrent robots to work in the same environment.  
However...  the mainframe emulator has a problem where in just one area/keystroke/function the standard hllapi api interface does not work for some reason.  For that one component you need to do a foreground global send keys of a keystroke.
All the robots running in the same environment cannot all do this foreground function at the same time,  so that is what environment locks were originally designed for.  It was a method to lock the environment so that only one of the several robots running in the same environment can do the function(s) requiring foreground interactions.