Processes failing sporadically

[mkkajtez (Miso)]

The problem we are facing are processes failing often at random spots within the program and a re-run will subsequently work. For example, in the screenshot below I have a simple activity to open a browser, type a username/password and login.

This works great most of the time, but there are times when the robot just fails, sometimes multiple times, and gives this error for example

In this particular example, I got this error twice in a row while running on orchestrator. When I decided to try re-running the process a third time while remoted into the computer to see why it was failing, the process worked without a problem. We often get these similar errors where the robot fails on us, and on a simple re-run will work. The process may run perfectly fine for ‘x’ days straight and fail the next day. Re-running will result in a success.

While this error was selector related, I don’t think it’s the main problem from what I mentioned above, the problem happens so sporadically. We understand that system performance (PolicyCenter/BillingCenter being slow, a webpage taking too long to open, etc…) can play a role but often times I wouldn’t say that’s the case either.

Is there anybody else experiencing similar issues or have input regarding this matter?

[Jan_Brian_Despi]

Hi @mkkajtez,

On the screenshot, it seems like the selector is wrong. It sometimes work and sometimes won’t. It is because the selectors may be dynamic.

[Raghavendraprasad (Raghavendraprasad Bhat)]

Well,

Just for a doing usecases to understand automation (basically when learning how to create bots) I had tried logging in to Linked In. It is famous for changing it’s layout from time to time.

But, even web programmers are short of time so there will always be a unique attribute that they will not change (ID, aaname etc.,) but the page layout and innertext and other attributes might change.

Also, when you click on the login field it might change the selector so better to have a click activity and after it changes capture the selector again to do a type into (or set text if the field allows it)

Better to follow some best practices and few details like initial element load to be set as 'COMPLETE" in the property panel, the Text box might look like it has loaded but it might take some time so try using the ‘On element appear’ activity by giving the selector etc.,

Maybe create redundancies like retry, and hovering over the element or setting focus before actually clicking on it might also help.

Sometimes when dealing with flash application and iFrames the window title tends to change or get frozen, so using a single attach browser container with the continuation of using a UiBrowser variable which carries the ‘handle’ of that browser session can also help in mitigating such issues.

Hope these things help.

Regards

[ClaytonM]

@mkkajtez

In this particular example, I got this error twice in a row while running on orchestrator. When I decided to try re-running the process a third time while remoted into the computer to see why it was failing, the process worked without a problem

If you think the problem is mostly related to the backscreen unattended automation, then it could be a number of things not related to your actual code. I suggest using TakeScreenshot and Save Image so you can see what it looks like while not remoted in. If it’s working consistently while remoted, then it’s most likely not a code issue, and I have rarely ever needed to use workarounds like clicks and such (but may depend on the application you are interacting with). But, like I said, those issues are normally found out while you are watching it run.

EDIT: Note: you will want to set your Resolution for the Robot in Orchestrator for each Robot, and set it to that of what you developed with (ie 1920 width, 1080 height, 32 color depth)

Regards.