topic Re: Environment Locking real time use case in Product Forum

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

DipinDevP — Tue, 15 Apr 2025 09:52:57 GMT

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

Re: Environment Locking real time use case

devneetmohanty07 — Thu, 30 May 2024 07:36:07 GMT

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

Re: Environment Locking real time use case

Chakkravarthi_PR — Thu, 30 May 2024 08:19:51 GMT

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.

Re: Environment Locking real time use case

DipinDevP — Thu, 30 May 2024 10:18:46 GMT

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.

Re: Environment Locking real time use case

DipinDevP — Thu, 30 May 2024 10:40:16 GMT

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.

Re: Environment Locking real time use case

Chakkravarthi_PR — Thu, 30 May 2024 11:11:04 GMT

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.

Re: Environment Locking real time use case

devneetmohanty07 — Thu, 30 May 2024 11:18:48 GMT

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.

Re: Environment Locking real time use case

DipinDevP — Fri, 31 May 2024 03:49:51 GMT

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.

Re: Environment Locking real time use case

Ernest1 — Tue, 08 Apr 2025 21:18:26 GMT

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

Re: Environment Locking real time use case

Denis__Dennehy — Sat, 12 Apr 2025 10:05:56 GMT

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.

Re: Environment Locking real time use case

Ernest1 — Mon, 14 Apr 2025 17:15:05 GMT

I understand that, but do you have any methods that you use to make sure that only selected process steps are executed only once, regardless of the number of resources on which the process is launched. I would like something that will block selected process steps once they have been executed and that steps will not be longer available to execute for the process on the rest resources.

For example, you launch process X has that steps:
1. Step A (duration 8 min)
2. Step B (duration 8 min)
3. Step C (duration 8 min)
4. Step D (duration 25 min)

in the following order:
on Resource 1 - 9:00 AM (process performed Step A, B, C and go to step D)
on Resource 2 - 9:30 AM (process on resource 1 still working and I would that this process avoid steps A, B, C and perform step D)
on Resource 3 - 10:00 AM (processes on resource 1 and 2 still working and I would that this process avoid steps A, B, C and perform step D)
on Resource 4 - 10:30 AM (processes on resource 1, 2 and 3 still working and I would that this process avoid steps A, B, C and perform step D)

Of course I have a solution (eg. I use env variable to store flags if some steps was done), but I would like to know others tips.

Many thanks,

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

Michael_S — Tue, 15 Apr 2025 09:51:42 GMT

Hey everyone, just dropping to say that this is a really interesting discussion with lots of fantastic, practical advice - so I'm going to feature it on our homepage banner.

Thanks @DipinDevP for kicking this off, thanks @Denis__Dennehy, @devneetmohanty07, @Chakkravarthi_PR for excellent input and thank you @Ernest1 for asking even more interesting questions!

Re: Environment Locking real time use case

Denis__Dennehy — Tue, 15 Apr 2025 14:48:44 GMT

Hi Ernest1, Another way to design your solution solution where different steps can only be done once and you want different resources to be able to do the work if they have capacity would be to have a separate work queue for each step. Your process is created with the logic to work 4 queues instead of 1 depending on the priorities of the separate queues and the work search logic you build within your process.

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

Denis__Dennehy — Tue, 15 Apr 2025 14:46:49 GMT

Hi Dipin
The Blue Prism developer training has exercises related to adding items to work queues that use environment locks.
The flow is:
Robot Resource 1, running Process A: Gets Environment Lock called "My Work Queue Loading Lock"
Robot Resource 1, running Process A: Runs logic to load work into my Work Queue.
Robot Resource 2, also running Process A: Tries to get Environment Lock called "My Work Queue Loading Lock" but cannot, so it cannot load work at the same time as Robot 1. Being prevented from loading work means 2 robots cannot load work at the same time which might duplicate work incorrectly. Instead it either goes on to do work in the queue or into waiting logic that waits for work to be in the queue.
Robot Resource 1, running Process A: Releases Environment Lock called "My Work Queue Loading Lock"

My previous example with 10 robots all working in the same windows desktop environment would be like this:
Robot Resource 1, running Process A: Gets lock called "Foreground Interface Lock - Process A"
Robot Resource 1, running Process A: Then performs an action that requires the windows foreground. For example activating a window and sending a global keystroke.
Robot Resource 1, running Process A: Gets lock called "Foreground Interface Lock - Process A"
Robot Resources 2 to 10, all also running Process A: If any of the other robots running in the same environment needs to use the foreground they will also try to get the lock but fail. they will go into a loop that tries to get the lock again every few seconds.

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

Ernest1 — Wed, 16 Apr 2025 14:17:36 GMT

Hi Denis, my process from example was created and is running on one queue (two in total: Parent and Child) and I can run that process on different resources/users on the same time/or different time and they work on the same queues and then not duplicate any works/items.

I have prepared logic that does not repeat steps at the beginning of the process (especially for Populate Queue) and at the end (especially for creating reports and moving files to arch).
I used various available options: environmental locks, checking if there is any element in the queue, before adding an element to the queue if there will be a duplicate, etc.). However, I would still like to know if it is possible to execute a fragment of the process only once if this process is running in parallel on other resources in given time or range time (e.g. once on given day) and how to do this? Any more tips?

Many thanks,

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

Denis__Dennehy — Wed, 16 Apr 2025 16:58:14 GMT

It should be possible Earnest, can you simply get an environment lock at the start of a process sub-page and if it is already use exit the process sub-page immediately instead of of going through the actions in that page. If you only want each page to be run once per day have a work queue item just for recording when the page is worked so that the last timestamp on that could also be checked.
However, it very much seems the solution we are talking about makes set and fast decisions within the process about how and when the work is worked. Maybe think about a solution where those decisions about how many robots can do the work and on which machines is something the controllers can make at run time, and change their mind depending on business need.

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

Ernest1 — Thu, 17 Apr 2025 14:15:01 GMT

Thanks Denis, timestamp I think it might be a good solution, alternatively I also considered using properties values (from Credentials) and when a sub-page is executed by one process it inserts a flag or something like status into the properties value (like Sub-Page Status = Worked / Not Worked) and then all robots check this flag every time when they call to the Sub-page.

topic Re: Environment Locking real time use case in Product Forum

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

Re: Environment Locking real time use case

Re: Environment Locking real time use case

Scenario:

Challenge:

Use Case:

Re: Environment Locking real time use case

Re: Environment Locking real time use case

Re: Environment Locking real time use case

Detailed Example for One Employee

EmployeeID1:

Re: Environment Locking real time use case

Re: Environment Locking real time use case

Re: Environment Locking real time use case

Re: Environment Locking real time use case

Re: Environment Locking real time use case

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

Re: Environment Locking real time use case

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

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

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

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