Why wait stages before next action and not after completed action?

[MatthewHoldswor]

Hi All,
New to the product and just started the learning courses but have been advised that "best practice" is for the wait action to confirm screen exists is at the beginning of the following stage rather than the end of current stage.

My head logic works differently and I'm struggling with building processes with the "next" step throwing the exception rather than the "current". Why is it best practice to be pre-action rather than post as my head is hurting!!!

Cheers,
Matt

------------------------------
Matthew Holdsworth
------------------------------

[HarpreetKaur]

Hello Matthew,
The idea behind having an intelligent wait stage (Check Exists) before you start interacting with any element on a page is to allow the application time to completely load and those elements to be visible and accessible by the bot for further steps (read, write, click anything)
The way intelligent wait stages work are that if the elements are found immediately, blue prism will not spend any extra time and immediately move on to the next step, if not then it waits for the time you specify in your time-out option at the bottom.

Ideally the best practice for any page on an object is to always start with an Attach action, then followed by your intelligent wait stages and navigation through the page and finally if the last action you perform on that page is a click action then ideally end it with another intelligent wait stage that ensures that Blue Prism has landed on the right screen post the click.. just to tie things up nicely. We dont usually recommend clicking a button and ending the object.

Regards
Harpreet

------------------------------
Harpreet Kaur Product Consultant
------------------------------

[VedSengupta]

Hello Matthew,
Pre-Check is being done to validate an element before taking any action.

So ideally every pre check is a kind of post check for something other.

For example : You check for element A before performing something and get directed to element B.
Now you can check after A for element B which is technically checking for element B's existence . So its a vice versa situation.

Now it is a recommended best practice because your action on element A may not lead you to element B. So it is always better to pre check and not post check as post check will not be giving us any validation result.

Please let me know if you want to discuss more on this.

------------------------------
------------------------------
Best Regards,
Ved Sengupta
RPA Developer
Deloitte India (Offices of the US)
Bangalore | INDIA
*If you find this post helpful mark it as best answer*
------------------------------
------------------------------

[krishna.kodimurali9]

Hey Matt,

Maybe this can help you understand better.



https://www.youtube.com/watch?v=f_Vxcpg5JTk&t=306s




------------------------------
Murali
RPA Consultant
------------------------------

[ErinConnerley]

I think most of the replies so far have pretty much hit it straight on. I would say prechecks serve several purposes.

1. You don't know how you got to where you are (eg. different processes may arrive at the same place through different means. The precheck allows you to verify your current location and state in an application without a care for how you got there allowing reusability of the action.
2. You need to verify the state and location of where you are in an application before you proceed to perform your desired action.
   1. You may launch a login page and if you didn't have a preemptive wait for the username field Blue Prism would attempt to write / type the username into the field before the field is loaded and ready is an easy example
3. Wait stages also provide some latency for the application you're interfacing with and even though the application is 'ready' or looks 'ready' it may not be, latency also lets backend scripts and things inside those applications have breathing room (actually more important than you think, if you slam certain applications they may freeze or lock up)
4. Wait stages also provide latency to the OS / System you're automation on (the runtime resource). If you read BP's documentation regarding how to work with lower memory machines this is important because it gives .NET's built in garbage collector time to run and potentially clear up things from memory allowing you to automate for longer stretches with less memory consumption and more stability.
5. Wait stages AFTER an action should pretty much ALWAYS exist if the action you performed changed the state of the application in any way shape or form.
6. As always, there are exceptions to the above rules in certain scenarios (eg. You always know the sequence of events in an application and regardless of the performing process that sequence cannot change)(eg. You performed some sort of dynamic action where a wait stage after your action is impossible to do reliably because the thing you need to wait on is different for different scenarios.) (etc.)

------------------------------
Erin Connerley
Automation Consultant
Agilify Automation
America/Indiana/Indianapolis
------------------------------