Warning! Controversial! Wait Stages in Objects and their timeouts...

[Asilarow]

Hi All,

I have a bit of a controversial topic... namely, the proper usage of timeouts in wait stages.

We've all seen the above, we do it, we don't question it.

However, I do want to question it.

What is the point of adding an exception stage after timeout?

And before anybody answers, let me just say that I am not looking for a justification in terms of best practices, conceptual designs, or any sort of design rule-based justification.

I am looking for a detailed technical justification here. Is there any impact on the product by not doing so?

To allow a decent discussion, I will present a point of view opposing the current status quo:

- There is no point in adding an exception stage after a timeout. Rather, it would be more beneficial to simply leave it without linking any stage to it. If the timeout is reached, an exception will be thrown anyway, and will be very informative:

' ERROR: Internal : Failed to find stage linked from stage 'Time Out - Wait for Home Page' on page 'Launch'.

This would save time and effort in building the object, and avoids creating typos when designing the Exception Stage details.

The error is clear, easy to capture in process exception handling, and highlights that a certain part of the Object design has an issue.

Note: Before anybody points out the obvious fact that the built-in error checker will highlight this as an error, Yes - I know. However, this can be configured to be ignored in the settings if you so wish, so is a moot point.

Go. Prove me wrong please 🙂

[Denis__Dennehy]

Hi Asilarow,

I get where you are coming from,  in terms of speedy development it would be far quicker to not put down the exception stage and just let the wait fail - it will still lead to an exception.   However, there are reasons to keep adding in the exception stage.  I was part of the team that helped design exception handling for v3.5 of the Blue Prism product and was involved in discussions at the time that led to the current best practices you know all about.

Firstly,  without an exception stage your object will fail /warn when you use the check for errors or validate button in Studio because there is a missing link in your flow - the check button sees it as an error.  Therefore every single time anyone needs to edit your work in future they will click that button and should check your missing exception stage to make sure it is not a problem - you will be causing work for others.  At many companies such an object cannot be published because validation rules set in System Manager would prevent it (maybe at your company that block is not in place).

Second,  a developer should be spending time thinking about their exception handling,  the message they want to throw and any other logic they might want to put in.  Having no exception stage on wait stages encourages speed over thought in regards to exceptions.

Thirdly - the type of exception being thrown with no exception stage will be an internal error rather than a System or Business exception.  This is not what I personally would want to see on my MI - I want to know how many system and business exceptions are being thrown.  Internal exceptions specifically demonstrate process errors and should be investigated by the controller/ops team - by not putting your exception stage in all over your solution may be impacting the usefulness of exception MI.

I am pedantic in relation to things like this...!!!

[Sheela]

Hi,

Adding a System exception is a best practice. I would recommend that strongly, as had helped me to design my code in a better way.

Below are the points which I would like to justify for throwing an exception explicitly.

1. This make sures the correct/expected exception to be thrown.
"ERROR: Internal : Failed to find stage linked from stage 'Time Out - Wait for Home Page' on page 'Launch'."
is the not first/actual exception. So this is misleading logically.
Wait stage was not able to find the element in the application -> this the actual exception.
If you throw the exception, then you can throw the actual exception which is "Unable to find the element"

2. You can decide the type of exception which is System exception(SE), rather than a default internal exception.

3. The system exception can be customized to capture as much as information which will help you to easily debug it.

4. A developer who developed the code can identify a defect/cause with the internal exception also. But for a third person who is investigating the issue,  this type for practice will reduce time and effort.

5. Also a system exception is thrown from an object, you have a control of handling this SE in Process level.  

6. <May be you would have point it already> This will keep the code an error(link) free and you might also avoid suppressing actual link errors in other flows of the object.

P.S

Best practice are always a suggestion to avoid known issues and no one can still stop you in designing your templates.

Happy Coding!

Regards,

Sheela

RPA

[Asilarow]

Hey Den,

It worked a treat at the beginning where most devs were trained properly... But times have changed, and sadly this is not the case anymore.

So, the thought here is more led by the poke-yoke approach to eliminate as many possibilities for users to make errors as possible.

Instead of making the developers add extra logic on top of the product's functionality (driven by use case), wouldn't it be better for the app to take care of this, and enforce it(driven by design)?

To touch on your point of errors, to make this work, it would have to mean some changes to the product's functionality - i.e. take away the internal error from this, and mark it appropriately automatically.

This would not take away the need for the Devs to think about exception handling (especially in the process), only make it simpler.

[Denis__Dennehy]

Hi Asilarow,

Slightly concerning if you have junior developers either not trained properly or not being well mentored not adhering to best practices.  Ideally every developer should have senior developer or solution architect doing peer review work on their designs and builds and providing mentoring advice so everyone becomes great - back when I was a developer I always got my work checked by a colleague even though I was probably one of the most experienced BP developers on the planet.

The Blue Prism application already has this functionality to not allow solutions to be published until there are no errors.  There is fairly Design Control in System Manager to set which errors stop the ability to publish and which are just warnings where publishing can still happen: Design control (blueprism.com)

[Asilarow]

Firstly, let me clarify that I do not have any developers trained incorrectly or not being mentored properly... and that it is beside the point I am trying to make.

I have been in the BP game since 2011, and for the last couple of years have seen a steady decline in quality of developer training(in various companies)... I will not be getting into the reasons why this is the case, as I could easily write a book about it 🙂

The point I am trying to make may be easier explained with an example:

Before a car with an automatic transmission can be started, the gearbox needs to be in the "Park" or "Neutral" position. This is to prevent overrevving, and/or driving into something before being ready to move.

The car mechanism (in an automatic car) is thus constructed in such a way, as to force the user to behave in a certain way, and eliminate the possibility of making a mistake in the start up process.

This same methodology can be applied to software(with moderation ofc), to make the user experience better. 

Now if we look back at the example of wait stages here... how many steps are required currently to ensure everything is spot on? Let's count:

1. Set the dynamic wait stage properties to target the required element from application modeller
2. Create an exception stage
3. Set the properties of the exception stage by selecting (or typing in) the exception type and exception details
4. Connect the timeout branch to the exception stage

An you'd think it's done, right? Wrong.

There's actually more, "hidden" steps:

3a. - Carefully review the list of existing exception types, and select the matching one (including sifting through all the typos)

Example here:

3b. - Decide on what should the Exception Details be, and provide a meaningful message... or create an entry in a data dictionary for each new exception, and provide a reference in the Exception detail.

3c. Update documentation with the exception details and explain what action(if any) is to be taken to resolve them.

Now... after all this is done, then you should have a properly documented and meaningful exception... But, does this happen very often? No. Because it takes far too much effort, and people like to be lazy.

So, wouldn't it be better if all that would be handled gracefully by the application itself? If an element being interacted with that failed to be recognized, is no longer there, or has been configured incorrectly was reported automatically when it happens, instead of having to design lengthy processes around it?

And that's where this idea of mine comes from.

@Denis__Dennehy - Your point about the block on errors in releases is true though... but also makes the case for this change even stronger... As if this would not be causing an error, but instead was actual application design, things would be easier.