Processes run well with an open session, but fail to run when started through scheduling in Orchestrator

Greetings everyone!

I am having a huge problem I suspect is related to Orchestrator configurations. Also, I apologize in advance because the post is also huge, and thank you all as well in advance for any help!

In order to introduce the problem, here are some things to consider:

I have automated a few processes for a client, which use both web-based services (uploads files to a site) and process orders the client receives throughout the day within an RM Desktop Application. Pretty much standard stuff.

The processes are scheduled to run three times a day and execute in order. We have observed the processes in progress with an open session - i.e. while logged in the server through remote access - and the processes performed well, processing the orders and sending confirmations through e-mails within the RM. This works either when starting the processes from Studio or Orchestrator whithin an open session. Scheduling is also not a problem, as we allowed processes to run that way while we were logged in the server, and it worked just fine.

The problem begins when the processes are supposed to run within a closed session - i.e. they run directly from the Orchestrator at the scheduled time, but no one is looking. In that case, the RM sometimes does not load within the TimeOut set within the automation - I have already doubled the TimeOut (from two to four minutes) to prevent this, though it has not been implemented yet.

–Btw, that is a very important restraint in my work: due to company policies, as a Developer, and third party, I am not allowed to enter the Production Server without supervision from a collaborator within the client. So implementing changes in those processes in production is a drag…–

Two problems remain though, no matter what I do:

i) Within the RM, the robot has to capture information from a specific field. The process involves clicking that field so it can be accessed, then using a series of keystrokes to select all the text info from the field, right-clicking the field to open a pop-up, and selecting “Copy” from the pop-up’s list through keystrokes (down, down, enter). Lastly, the value copied to the Clipboard is then transferred to a specific variable to be used further in the process.
With an open session, that works just fine, although slowly, but with a closed session the robot sometimes fail to capture that information, and when analyzing the process’ logs, it is evident the bot has stored a wrong value, which sometimes matches another variable’s value - though we capture that after this step, using the same method. I have taken steps to empty both the clipboard variable and the specific variable before capturing the data (and after clipboard is pasted to the specific variable, in the case of the clipboard variable); I have introduced delays to force the bot to capture the info slowly; and, as a last resource, introduced a while loop to allow trying to capture the right pattern (no numbers) and save that to the variable. All to no avail.

Problem ii) is somewhat similar, as the while loop routine is implemented as well, but much simpler: the ‘Open’ window does not open within the browser, likely because the bot cannot click the button to open it. As in i) it never fails in an open session, but does fail when the session is closed.

Since sometimes the bot works fine, and the aforementioned errors do not occur, I believe screen resolution should not be a problem (although the Orchestrator runs in 1920 x 1080, the processes were automated in 2560 x 1080).

I have been wondering if user preferences might be causing errors or impeding some orders to be processed. Or if jobs have not been properly scheduled. I am kind of in the dark here…

Any possible explanations? Many thanks!

1 Like

according to your comment i realize 2 things
check where if they try to run via attended bot , because it will work when you in desktop but attend bot cannot login to windows

and the second thing is , yes screen resolution will be a effect , since your development screen resolution might take some eliminates
in your production server check the resolution of it and check your relevant robot resolution you have set any

We were having the screen resolution nightmare scenario and have learned the best approach is to have Dev Ops set the display resolution through a console session. This can’t be done from inside the remote desktop session and whatever you read in the display settings may or may not occur.

1 Like

Have you tried to resolve via robot resolution?

I’ve tried Invoke Workflow Interactive setting the screen resolution and screen resolution set in Orchestrator. Neither gave consistent resolutions on any of the remote desktops. After Dev Ops forced the proper resolution on those the bots started performing as expected.

What exactly do you mean by Robot Resolution?