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!