1 BEST ANSWER
Helpful Answers
Hi Sanaa,
You should be using Conditional Wait wherever possible. Conditional waits are used for dynamically determining if an element exists or not for the specified element in you Application Tree at the runtime. Since in a DEV environment and in a PROD environment, the target application to be automated can have different loading times, we specify a maximum time out indicating that within that time if the element exists then, we need to move ahead or throw a time out. Below is the example of a conditional wait:
Now coming to Unconditional waits or Throttle as they are known, here we do not put any condition and just give a specific time for our execution to pause. As the name suggests, you do not provide any condition for the element here and just provide the timeout value which indicates the static time the execution of the workflow will be paused for at that point of time.
The problem here is that the wait is not dynamic. If today we see that a webpage loads with 10 seconds and we put this time in our unconditional wait and let say tomorrow when we load the same web page due to server issue or the slowness of the environment or due to different network bandwidth, the web page loads after more than 10 seconds, then our workflow will fail. Basically solution is not that intelligent to respond to these scenarios. Hence, it is not recommended. However, these can be used in combination with unconditional wait stages depending on the use case. For example, if I need to click in a dropdown element and then again click with any of the element in the list that gets shown and if I see that there is a very minute time within which that list can be opened up on the screen I can use a unconditional wait again better option would be a conditional one here as well but if you are very sure that it is never going to take much time you can still go for a throttle stage or an unconditional stage.
Below is the example of an unconditional wait:
As a best practice in Blue Prism, always consider more time than less time for waiting. Waiting more can make your automation slow but waiting less can increase the chances of it breaking!
------------------------------
----------------------------------
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
----------------------------------
------------------------------
You should be using Conditional Wait wherever possible. Conditional waits are used for dynamically determining if an element exists or not for the specified element in you Application Tree at the runtime. Since in a DEV environment and in a PROD environment, the target application to be automated can have different loading times, we specify a maximum time out indicating that within that time if the element exists then, we need to move ahead or throw a time out. Below is the example of a conditional wait:
Now coming to Unconditional waits or Throttle as they are known, here we do not put any condition and just give a specific time for our execution to pause. As the name suggests, you do not provide any condition for the element here and just provide the timeout value which indicates the static time the execution of the workflow will be paused for at that point of time.
The problem here is that the wait is not dynamic. If today we see that a webpage loads with 10 seconds and we put this time in our unconditional wait and let say tomorrow when we load the same web page due to server issue or the slowness of the environment or due to different network bandwidth, the web page loads after more than 10 seconds, then our workflow will fail. Basically solution is not that intelligent to respond to these scenarios. Hence, it is not recommended. However, these can be used in combination with unconditional wait stages depending on the use case. For example, if I need to click in a dropdown element and then again click with any of the element in the list that gets shown and if I see that there is a very minute time within which that list can be opened up on the screen I can use a unconditional wait again better option would be a conditional one here as well but if you are very sure that it is never going to take much time you can still go for a throttle stage or an unconditional stage.
Below is the example of an unconditional wait:
As a best practice in Blue Prism, always consider more time than less time for waiting. Waiting more can make your automation slow but waiting less can increase the chances of it breaking!
------------------------------
----------------------------------
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,
You should be using Conditional Wait wherever possible. Conditional waits are used for dynamically determining if an element exists or not for the specified element in you Application Tree at the runtime. Since in a DEV environment and in a PROD environment, the target application to be automated can have different loading times, we specify a maximum time out indicating that within that time if the element exists then, we need to move ahead or throw a time out. Below is the example of a conditional wait:
Now coming to Unconditional waits or Throttle as they are known, here we do not put any condition and just give a specific time for our execution to pause. As the name suggests, you do not provide any condition for the element here and just provide the timeout value which indicates the static time the execution of the workflow will be paused for at that point of time.
The problem here is that the wait is not dynamic. If today we see that a webpage loads with 10 seconds and we put this time in our unconditional wait and let say tomorrow when we load the same web page due to server issue or the slowness of the environment or due to different network bandwidth, the web page loads after more than 10 seconds, then our workflow will fail. Basically solution is not that intelligent to respond to these scenarios. Hence, it is not recommended. However, these can be used in combination with unconditional wait stages depending on the use case. For example, if I need to click in a dropdown element and then again click with any of the element in the list that gets shown and if I see that there is a very minute time within which that list can be opened up on the screen I can use a unconditional wait again better option would be a conditional one here as well but if you are very sure that it is never going to take much time you can still go for a throttle stage or an unconditional stage.
Below is the example of an unconditional wait:
As a best practice in Blue Prism, always consider more time than less time for waiting. Waiting more can make your automation slow but waiting less can increase the chances of it breaking!
------------------------------
----------------------------------
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
----------------------------------
------------------------------
You should be using Conditional Wait wherever possible. Conditional waits are used for dynamically determining if an element exists or not for the specified element in you Application Tree at the runtime. Since in a DEV environment and in a PROD environment, the target application to be automated can have different loading times, we specify a maximum time out indicating that within that time if the element exists then, we need to move ahead or throw a time out. Below is the example of a conditional wait:
Now coming to Unconditional waits or Throttle as they are known, here we do not put any condition and just give a specific time for our execution to pause. As the name suggests, you do not provide any condition for the element here and just provide the timeout value which indicates the static time the execution of the workflow will be paused for at that point of time.
The problem here is that the wait is not dynamic. If today we see that a webpage loads with 10 seconds and we put this time in our unconditional wait and let say tomorrow when we load the same web page due to server issue or the slowness of the environment or due to different network bandwidth, the web page loads after more than 10 seconds, then our workflow will fail. Basically solution is not that intelligent to respond to these scenarios. Hence, it is not recommended. However, these can be used in combination with unconditional wait stages depending on the use case. For example, if I need to click in a dropdown element and then again click with any of the element in the list that gets shown and if I see that there is a very minute time within which that list can be opened up on the screen I can use a unconditional wait again better option would be a conditional one here as well but if you are very sure that it is never going to take much time you can still go for a throttle stage or an unconditional stage.
Below is the example of an unconditional wait:
As a best practice in Blue Prism, always consider more time than less time for waiting. Waiting more can make your automation slow but waiting less can increase the chances of it breaking!
------------------------------
----------------------------------
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
----------------------------------
------------------------------
