Automation Behavior changes on different Run time Resources

[ManasJena]

Hello All,

We developed an automation which interacts with UNIX OS and does password reset . The automation works as expected in debugger mode . When we run it on various Run time Resources the behavior is not predictable.
We see in few RR it completes successfully and in other RR it fails.

Did anyone faced this kind of scenarios ? Please suggest.


------------------------------
Manas Jena
Sr Analyst
ZimmerBiomet
America/New_York
------------------------------

[DaveMorris · Accepted solution]

When an automation works in DEBUG mode but not when running from Control Room (even if it works sometimes), usually it is a speed of execution issue. The way I usually handle is one of two ways.

First option: Over-engineer the automation with conditional waits, arbitrary waits, checks for files or Windows processes, and any other checks/waits necessary to ensure that the automation goes as fast as possible but will NEVER go faster than the applications being automated can handle.

Second option: Attempt to identify each specific place where it is failing and then only treat that situation. For example, you might have to remote into a Runtime Resource (RDP or other way) and then start a process from Control Room on that resource and watch when it fails. Or you could change the stage logging so that it's easier to identify in the session logs where exactly it's failing. Or you could try reproducing on your own machine by running the automation on your local machine but from Control Room. Use some combination of those techniques to identify where the problems are happening. Then experiment with putting conditional waits or arbitrary waits as needed to make sure it doesn't go too fast.

Granted, the issue may not be speed of execution. It could be a difference in the environments themselves. But unless you have an error or other symptoms to go off of, I would first assume it is speed of execution that you need to tend to first.

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[ManasJena]

Thanks ! Dave

We are using Surface automation (region mode) .The process reads from UNIX CLI  and proceeds with various commands. We have seen the wait time issue in couple of places and adjusted those. Conditional waits is something we can't use the way we are automating.

All our RRs are on same VDI and there is no mismatch in those. We monitored process on RR via console viewer (v Center). While we did that the process executed without any issues.We did that 3 times to test. 


------------------------------
Manas Jena
Sr Analyst
ZimmerBiomet
America/New_York
------------------------------

[DaveMorris]

Surface Automation can be tough. I'm not sure why you wouldn't be able to use conditional waits. It should work the same with SA as with browser mode, AA, or UIA except that instead it'd be waiting for an image element to appear. Is there any chance you're using an older version of Blue Prism, such as v5? I only used Surface Automation in v5 a little bit, and I can barely remember the restrictions involved. In v6 though, you can configure elements to be located anywhere and then use that in conditional waits.

I think you already know these things, but you'll want to make sure that the environment is as perfect for Surface Automation as possible, such as disabling font smoothing, setting the screen resolution to be consistent across all instances/machines, ensuring the zoom level or size of text etc. in apps. Again, I think you know all this already, but I figured I'd mention it.

I suppose one thing I would try is implementing screenshots that get taken and saved at the moment any element (even Region mode) isn't found. Then you might be able to visually identify what's wrong by comparing the screenshot to the image saved in Application Modeller.

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[diane.sanzone]

Hi Manas,

Dave (already replied to you) is most definitely more of an expert than I – he's helped me on more than one occasion. I did, however, have a similar issue with a surface automation object I created last month. I found that even though the screen resolution of my dev machine is the same as the bot VM, the screen ratio is different (my dev machine is widescreen and the bot VM is standard). This caused some elements to shift location on the screen when the bot was running – not every time, just sometimes based on the other data resident on the screen. I redid my surface automation for those pages while logged on to the bot VM and the issue resolved. I don't know if this applies to you but thought it was worth a mention.

Good luck!

------------------------------
Diane Sanzone
------------------------------

[ZdeněkKabátek]

Hi, Manas,

the other replies are 100% valid and should be checked, however, you mentioned that while you were monitoring process through vCenter it ran fine. Did you check locking screen or logging out after some time of inactivity? There are two typical scenarios when you don't watch the process and it fails:
1. RDP access but as you said you don't use it (after closing RDP session the desktop is closed and Surface Automation won't work)
2. locking the screen or logging the user out after some time is another reason for such a behavior

Regards,

Zdenek

------------------------------
Zdeněk Kabátek
Head of Professional Services
NEOOPS
http://www.neoops.com/
Europe/Prague
------------------------------

[ManasJena]

Thanks ! a ton Everyone for looking at this and helping with your valuable suggestions.

The issue is resolved. This is how we fixed it

1- We enabled Screen capture and found there is a inconsistency in screenshots between Run time Resources (Bot is not able to find what it is looking for in few RRs)
2- We did a remediation and added a scroll down to make the BOT read what it is looking for

This helped in our scenario.


------------------------------
Manas Jena
Sr Analyst
ZimmerBiomet
America/New_York
------------------------------