I have been working with UIpath community edition. I developed activities in UIpath and I was able to deploy with Orchestrator. I was successfully able to schedule and queue jobs into the Ochestrator.
Now, I have an evaluation UIpath enterprise edition licence for 2 months. I want to deploy my job into production. I will publish my project to orchestrator which will schedule jobs on an unattended robot(in house machine containing UIpath robot installed).
I have question here. Just like when we were building activity using UIpath studio and were able to see the process happening in realtime(like open google chrome, enter url, enter login details, enter login etc.) Does the same happen when the project is published to orchestrator and orchestrator schedule jobs on a machine containing UIpath robot? Will I be able to see visually what is happening on the in house machine screen(unattended robot)?
I want to see if the process is happening correctly. Of course I won’t be able to intervene it. It will first fail if any error occurs, only then I would be able to intervene.
There are some business oriented person in the room who are concerned about the visibility of the process.
Thanks in advance.
Welcome to our UiPath Forum!
If you schedule a job in Orchestrator on a development machine, it will run and show everything just as you would press F5 in your Studio. So everything will be visible.
If you want to hide the process, you should schedule the job on a Robot machine with an unattended license. This way the Orchestrator will connect to that Robot machine via RDP connection and work ‘hidden’.
Keep in mind that unattended automation can be tricky when UI interaction is concerned due to some restrictions of the Click (and others) activities. See here for more info:
If you are new to environment migration, and unless the IT supporting the environments are awesome at what they do, there could be some headaches. I am assuming that’s why you are questioning the visibility of a production environment
If you have an unatttended license, you can run it just like an attended, where you can watch it. This is what you would want to do while developing to ensure all requirements are met and is working flawlessly on each robot environment, including production. I almost never just publish to Production, without first testing in that environment as attended. Then, if that passes, test as unattended and ensure each robot user is configured for successful runs. This would also require that you have some robots designated as development or non-production robots, because you wouldn’t want to try and share users running production jobs.
For further visibility, you should have designs in your code for each project that allows you to store screenshots when errors occur. This lets you escalate issues to IT or troubleshoot coding flaws much easier.
(there is also a StreamRobot in Go!, but be warned that IT will not like this and ensure that it is only used “temporarily” given certain restrictions on trying to resolve those rare errors you just can’t figure out)
So those are just some thoughts from my experience.