Run published robot from Command Prompt or Task Scheduler

robot
package
publish
schedule

#1

Hello, I have a question and I would appreciate some help.

I want to be able to run a published robot, either from Command Prompt or Task Scheduler (Orchestrator is out of the question). I know you can run it from UiRobot from the system tray but I want to do it with Command Prompt or Task Scheduler. I have seen these examples: Start Process From Command Line and How to: Schedule a Process Manually but they seem to use a .xaml file and not the generated .nupkg file. What am I missing here? For reference, UiPath version is 17.1.6522 community edition.

On a side note, I noticed that after I publish the process and go to UiRobot in the system tray, I first need to click the “Update” button, which seems to create a folder C:\Users\LoggedUser\AppData\Local\UiPath\Projects\Test.1.0.6527.20287 with the .nupkg file and a lib folder containing the .xaml file.

Capture

Am I correct in the assumption that when I hit the “Start” button UiRobot runs the .xaml file from the lib folder?

Thank you!


#3

This seems to be the case. I published a robot that displayed the Environment.CurrentDirectory in a Message Box and it was the path to the lib folder. So I suppose I have to use the .xaml file from there when scheduling the process. But then what is the point of publishing the robot in this context? What is the difference between running the .xaml file from my project folder (before publishing) and running the .xaml file from the lib folder (after publishing)?


#4

Hi Florin,

First, from what I understand, your Robot is not connected to Orchestrator.

There is no difference if you have both Studio and Robot on the same machine and you want to run the .xaml from either paths(at least for now; it is planned for future versions to not be able to open the .xaml from lib folder in Studio).

But if you have Studio on one machine(for development) and Robot on another one(for execution) that means that on the Robot machine you won’t have the .xaml from your project folder.

On the Robot machine, the automation packages feed is the value of the NuGetServerUrl parameter from UiPath.Settings file(%localappdata%\UiPath or %ProgramData%\UiPath).

When not connected to Orchestrator, like in your case, the default folder is %ProgramData%\UiPath\Packages. Best practice in this case(Studio and Robot on different machines) is to have a shared folder and change the default value of NuGetServerUrl parameter to the path of the shared folder. This way, when you publish from Studio machine, on the Robot side you will be able to run the same package.

Please let me know if anything is not clear enough.


#5

Thank you kindly for your response, @ovi! Now I understand the bigger picture a little more. Yes, I’m talking about the case when the robot is not connected to Orchestrator.

There are two more things I would like to inquire about if you would be so kind. I am planning on executing the robot with Task Scheduler through a batch file. Firstly, let’s say the robot is published to a shared folder, which means the folder will now contain the .nupkg file. Do you know how to “unpackage” the .nupkg file from Command Prompt (or any other way that can be scheduled) in order to obtain the .xaml file that needs to be run? And secondly, from your experience, how reliable would you say Task Scheduler is for starting a robot?

Any insight is greatly appreciated.


#6

As you said here, the Robot unzips the process automatically.
This means that the .nupkg file is actually an archive => you can rename it with the .zip extension and it will become an archive containing the lib folder that contains the .xaml file.

From command line, i’ve found some posts on stackoverflow with a command to extract directly from the .nupkg file(you will need the nuget.exe in the same folder as your package). Here it is:
https://stackoverflow.com/questions/16587291/extracting-nupkg-files-using-command-line

Or you can first rename the file with .zip extension then using unzip mydir.zip to extract the files in the archive and then start the process with the .xaml path(UiRobot.exe -file “%HOMEPATH%\Documents\UiPath\test_debugging\Main.xaml”)

Now, about the Task Scheduler, this feature is now deprecated therefore we don’t recommend it anymore. However, as you probably noticed, there are several posts here on how to use it and what issues may occur when using it. You can give it a shot, but my recommendation is to use Schedules from Orchestrator.

P.S.: If you have suggestions or any feedback regarding the package files feel free to drop it here somewhere :wink: It’s really useful.


#7

@ovi i am having some trouble accessing the UiPath.Settings file? Have this been locked in 2018.2.3 version of uipath? & in that case how does one go about changing the NuGetServerUrl?


#8

Hi @nwi

Did you try opening it from %localappdata%\UiPath? For Community Edition you don’t need any permissions.
For Enterprise version or Trial version, you will need admin rights in order to access it. Is this your case?


#9

Hi @ovi

The setup is an windows server 2016, with an licensed Enterprise studio, in version 2018.2.3

The: %localappdata%\UiPath\UiStudio.Settings i can open, but is has no
setting name=“NuGetServerUrl”

The: %ProgramData%\UiPath\UiStudio.Settings i try to open in notepad++ and gets the error:
Can not open file “STRT_REPLACE”.
If i try in normal notepad i get the error:
Access is denied.

When i use my admin rights to take ownership of the file in the properties, i end up with the same errors.


#10

@nwi

NugetServerUrl would be a part of UiPath.settings file . Please open command prompt by right clicking and “Run as administrator” , change the directory to the %programdata%\UiPath and then try opening UiPath.setting file.


#11

@nwi

Do not open the UiPath.settings file by dragging/dropping in the notepad window, even if it was opened as admin, it won’t work and will trigger the STRT_REPLACE error.


#13

UPDATE: I tried to restart the UiRobotService as well, this made it read the UiPath.Settings file again, and it now uses the network share to publish! Thanks for all the help!