Hi Devneet, You already answered my question, but for some reason, I can't open the thread, it's shown blank
could you please paste the answer here?
thank you in advance
------------------------------
Sanaa Fallah
------------------------------
1 BEST ANSWER
Best Answers
Hi Sanaa,
Sure I would again write it here. So Environment Locking is a concept that is used for Multi-Bot Architecture framework. The way it works is to essentially lock a part of the workflow in such a way that only one Runtime Resource can access that part of the workflow at any particular point of time during execution.
Scenarios:
It is generally used in scenarios where let say there is one source data which needs to be read and you don't want two machines to read the data as duplication might occur or the file might get locked by one resource while the other tries to access it.
Also, if in you automation process, let say you deal with an application where the User ID is same for all the bots and only one session can be created at a time. Then ideally you won't want multiple robots to work on that session. Here also, Environment Locking works.
Working:
Now coming to it's working, we generally have three types of actions associated with Environment Locking which are: 'Acquire Lock', 'Query Lock' and 'Release Lock'. The way we can implement this concept is by first using the 'Query Lock' action where you provide the lock name which can be a custom name set by you and it will return a flag indicating if any token corresponding to that lock has been generated already or not as shown below. If we already know the randomly generated token text we can put that here though it is optional:
Next we use a decision stage to check the flag value, if the flag value is False then it means that the lock is free so we can use the 'Acquire Lock' action and pass the lock name which will generate a random token value for us till the lock has been released. Here Timeout, Preferred Token and Comment is optional. If we provide the preferred token, then no random token text will be generated. We can provide comments with meaningful values such as the 'Resource Name' which can tell us which Resource had the environment lock during debugging. Preferred Timeout can be used if there is a maximum time that we need for a lock to be acquired. Once the time is elapsed the lock gets released.
After that we can perform whatever actions we want as a part of our workflow and once everything has been completed successfully, we release the lock using the 'Release Lock' action where we need to pass the Lock Name and Token (that got generated from 'Acquire Lock' action previously) which are mandatory. Rest of the parameters are optional such as Comment, All Sessions and Keep Environment Lock. Comment indicates the comment we want to give while releasing a lock. All Sessions flag value determines if all the locks corresponding to the rest of the parameters needs to be released across multiple sessions. Keep Environment Lock flag value determines if the environment lock will be kept after that lock is released. It's default behavior is to delete the lock.
Sample Workflow:
Below is a sample workflow, where we want to read an excel file only suing a single resource. So if this process is run across multiple resources, there will be a race among them which will determine who queries the lock first, the resource who wins this race will read the file while the others will skip this entire workflow.
You can also view the environment lock details from the System Manager -> Workflow -> Environment Locks. The moment the lock has been acquired, you will see the lock visible in the panel as well as shown below:
Here you can see the lock as 'Unlocked' since we have released the lock using the 'Keep Environment Lock Flag' as True otherwise it would have been deleted. In case the Resource for some reason cant signal the database to release any lock, the lock remains in an orphaned state which will be 'Locked' only. Such locks can be deleted manually from the System manager as shown below:
------------------------------
----------------------------------
Hope it helps you and if it resolves you query please mark it as the best answer so that others having the same problem can track the answer easily
Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
Wonderbotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com
----------------------------------
------------------------------
Sure I would again write it here. So Environment Locking is a concept that is used for Multi-Bot Architecture framework. The way it works is to essentially lock a part of the workflow in such a way that only one Runtime Resource can access that part of the workflow at any particular point of time during execution.
Scenarios:
It is generally used in scenarios where let say there is one source data which needs to be read and you don't want two machines to read the data as duplication might occur or the file might get locked by one resource while the other tries to access it.
Also, if in you automation process, let say you deal with an application where the User ID is same for all the bots and only one session can be created at a time. Then ideally you won't want multiple robots to work on that session. Here also, Environment Locking works.
Working:
Now coming to it's working, we generally have three types of actions associated with Environment Locking which are: 'Acquire Lock', 'Query Lock' and 'Release Lock'. The way we can implement this concept is by first using the 'Query Lock' action where you provide the lock name which can be a custom name set by you and it will return a flag indicating if any token corresponding to that lock has been generated already or not as shown below. If we already know the randomly generated token text we can put that here though it is optional:
Next we use a decision stage to check the flag value, if the flag value is False then it means that the lock is free so we can use the 'Acquire Lock' action and pass the lock name which will generate a random token value for us till the lock has been released. Here Timeout, Preferred Token and Comment is optional. If we provide the preferred token, then no random token text will be generated. We can provide comments with meaningful values such as the 'Resource Name' which can tell us which Resource had the environment lock during debugging. Preferred Timeout can be used if there is a maximum time that we need for a lock to be acquired. Once the time is elapsed the lock gets released.
After that we can perform whatever actions we want as a part of our workflow and once everything has been completed successfully, we release the lock using the 'Release Lock' action where we need to pass the Lock Name and Token (that got generated from 'Acquire Lock' action previously) which are mandatory. Rest of the parameters are optional such as Comment, All Sessions and Keep Environment Lock. Comment indicates the comment we want to give while releasing a lock. All Sessions flag value determines if all the locks corresponding to the rest of the parameters needs to be released across multiple sessions. Keep Environment Lock flag value determines if the environment lock will be kept after that lock is released. It's default behavior is to delete the lock.
Sample Workflow:
Below is a sample workflow, where we want to read an excel file only suing a single resource. So if this process is run across multiple resources, there will be a race among them which will determine who queries the lock first, the resource who wins this race will read the file while the others will skip this entire workflow.
You can also view the environment lock details from the System Manager -> Workflow -> Environment Locks. The moment the lock has been acquired, you will see the lock visible in the panel as well as shown below:
Here you can see the lock as 'Unlocked' since we have released the lock using the 'Keep Environment Lock Flag' as True otherwise it would have been deleted. In case the Resource for some reason cant signal the database to release any lock, the lock remains in an orphaned state which will be 'Locked' only. Such locks can be deleted manually from the System manager as shown below:
------------------------------
----------------------------------
Hope it helps you and if it resolves you query please mark it as the best answer so that others having the same problem can track the answer easily
Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
Wonderbotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com
----------------------------------
------------------------------
Hi Sanaa,
Sure I would again write it here. So Environment Locking is a concept that is used for Multi-Bot Architecture framework. The way it works is to essentially lock a part of the workflow in such a way that only one Runtime Resource can access that part of the workflow at any particular point of time during execution.
Scenarios:
It is generally used in scenarios where let say there is one source data which needs to be read and you don't want two machines to read the data as duplication might occur or the file might get locked by one resource while the other tries to access it.
Also, if in you automation process, let say you deal with an application where the User ID is same for all the bots and only one session can be created at a time. Then ideally you won't want multiple robots to work on that session. Here also, Environment Locking works.
Working:
Now coming to it's working, we generally have three types of actions associated with Environment Locking which are: 'Acquire Lock', 'Query Lock' and 'Release Lock'. The way we can implement this concept is by first using the 'Query Lock' action where you provide the lock name which can be a custom name set by you and it will return a flag indicating if any token corresponding to that lock has been generated already or not as shown below. If we already know the randomly generated token text we can put that here though it is optional:
Next we use a decision stage to check the flag value, if the flag value is False then it means that the lock is free so we can use the 'Acquire Lock' action and pass the lock name which will generate a random token value for us till the lock has been released. Here Timeout, Preferred Token and Comment is optional. If we provide the preferred token, then no random token text will be generated. We can provide comments with meaningful values such as the 'Resource Name' which can tell us which Resource had the environment lock during debugging. Preferred Timeout can be used if there is a maximum time that we need for a lock to be acquired. Once the time is elapsed the lock gets released.
After that we can perform whatever actions we want as a part of our workflow and once everything has been completed successfully, we release the lock using the 'Release Lock' action where we need to pass the Lock Name and Token (that got generated from 'Acquire Lock' action previously) which are mandatory. Rest of the parameters are optional such as Comment, All Sessions and Keep Environment Lock. Comment indicates the comment we want to give while releasing a lock. All Sessions flag value determines if all the locks corresponding to the rest of the parameters needs to be released across multiple sessions. Keep Environment Lock flag value determines if the environment lock will be kept after that lock is released. It's default behavior is to delete the lock.
Sample Workflow:
Below is a sample workflow, where we want to read an excel file only suing a single resource. So if this process is run across multiple resources, there will be a race among them which will determine who queries the lock first, the resource who wins this race will read the file while the others will skip this entire workflow.
You can also view the environment lock details from the System Manager -> Workflow -> Environment Locks. The moment the lock has been acquired, you will see the lock visible in the panel as well as shown below:
Here you can see the lock as 'Unlocked' since we have released the lock using the 'Keep Environment Lock Flag' as True otherwise it would have been deleted. In case the Resource for some reason cant signal the database to release any lock, the lock remains in an orphaned state which will be 'Locked' only. Such locks can be deleted manually from the System manager as shown below:
------------------------------
----------------------------------
Hope it helps you and if it resolves you query please mark it as the best answer so that others having the same problem can track the answer easily
Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
Wonderbotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com
----------------------------------
------------------------------
Sure I would again write it here. So Environment Locking is a concept that is used for Multi-Bot Architecture framework. The way it works is to essentially lock a part of the workflow in such a way that only one Runtime Resource can access that part of the workflow at any particular point of time during execution.
Scenarios:
It is generally used in scenarios where let say there is one source data which needs to be read and you don't want two machines to read the data as duplication might occur or the file might get locked by one resource while the other tries to access it.
Also, if in you automation process, let say you deal with an application where the User ID is same for all the bots and only one session can be created at a time. Then ideally you won't want multiple robots to work on that session. Here also, Environment Locking works.
Working:
Now coming to it's working, we generally have three types of actions associated with Environment Locking which are: 'Acquire Lock', 'Query Lock' and 'Release Lock'. The way we can implement this concept is by first using the 'Query Lock' action where you provide the lock name which can be a custom name set by you and it will return a flag indicating if any token corresponding to that lock has been generated already or not as shown below. If we already know the randomly generated token text we can put that here though it is optional:
Next we use a decision stage to check the flag value, if the flag value is False then it means that the lock is free so we can use the 'Acquire Lock' action and pass the lock name which will generate a random token value for us till the lock has been released. Here Timeout, Preferred Token and Comment is optional. If we provide the preferred token, then no random token text will be generated. We can provide comments with meaningful values such as the 'Resource Name' which can tell us which Resource had the environment lock during debugging. Preferred Timeout can be used if there is a maximum time that we need for a lock to be acquired. Once the time is elapsed the lock gets released.
After that we can perform whatever actions we want as a part of our workflow and once everything has been completed successfully, we release the lock using the 'Release Lock' action where we need to pass the Lock Name and Token (that got generated from 'Acquire Lock' action previously) which are mandatory. Rest of the parameters are optional such as Comment, All Sessions and Keep Environment Lock. Comment indicates the comment we want to give while releasing a lock. All Sessions flag value determines if all the locks corresponding to the rest of the parameters needs to be released across multiple sessions. Keep Environment Lock flag value determines if the environment lock will be kept after that lock is released. It's default behavior is to delete the lock.
Sample Workflow:
Below is a sample workflow, where we want to read an excel file only suing a single resource. So if this process is run across multiple resources, there will be a race among them which will determine who queries the lock first, the resource who wins this race will read the file while the others will skip this entire workflow.
You can also view the environment lock details from the System Manager -> Workflow -> Environment Locks. The moment the lock has been acquired, you will see the lock visible in the panel as well as shown below:
Here you can see the lock as 'Unlocked' since we have released the lock using the 'Keep Environment Lock Flag' as True otherwise it would have been deleted. In case the Resource for some reason cant signal the database to release any lock, the lock remains in an orphaned state which will be 'Locked' only. Such locks can be deleted manually from the System manager as shown below:
------------------------------
----------------------------------
Hope it helps you and if it resolves you query please mark it as the best answer so that others having the same problem can track the answer easily
Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
Wonderbotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com
----------------------------------
------------------------------
