Publishing a package that needs to be run by multiple robots

orchestrator
package
highdensity

#1

Hi there. Beginner question regarding Orchestrator. Please correct me if I make any wrong assumptions.

Let’s say we have one machine with Windows Server and multiple users/robots (RDP), so a High-Density scenario. We have a project that we publish, which sends a package to Orchestrator. Then we can create a process in Orchestrator for the published project, create a job and assign multiple robots to run the job at the same time. This will unpack the project and place it by default in C:\ProgramData\UiPath\Projects.

Do all robots share and use the project files placed in ProgramData? Seems to me like that’s the case, as I can access the same project files with each user. Which means that if the process involves deleting files on certain conditions, or even modifying them or moving them around, one robot might mess up what the other robots are doing. This seems wrong to me (each robot should have its own project space) and I’m wondering if I have an incorrect understanding. How do environments come into play, if at all?

Thank you kindly!


#2

This should give an idea to an extent. Probably it’s a good idea to access the files from User Profile folders than common folders.


#3

Thank you for the quick reply, @vvaidya. Just to make sure we’re on the same page, I’m talking about creating/modifying files that are in the root project folder that gets published, like files inside the Data\Input, Data\Output, Data\Temp folders from the ReFrameWork for example. Are these files/folders shared between robots during the simultaneous execution of the same process? So if I understand you correctly, does this mean that I can’t use the project folder at all and instead I have to use the User Profile folder? Please confirm. Going out on a limb here but is there a way to tell Orchestrator to unpack the project in the User Profile folder of each user and run it from there?

I’m a bit unclear on how the execution of the same process by multiple robots is intended to be done. It seems that if the robots are on different machines then there would be no problems of overlapping but using the High-Density approach changes things quite a bit.


#4

I don’t think there is a way( as of now) to change the Orchestrator unpack location, but I would check UiRobot settings file in the installation folder.

I haven’t really tested same process scenario earlier, but ran different processes.It looks like the resources will definitely be in use and could create a conflict when running with multiple instances.I will try to implement this and let you
know my findings.

Let’s see if @andrzej.kniola is available to give his articulate inputs.

Thanks,

Vinay


#5

I’d avoid using ProgramData / project folders anyway and go for either UserProfile folders or dedicated paths.
Either way you set it, as long as the robots are not using (especially writing to/moving/deleting) the same files they should be fine.


#6

Thanks for the reply, @andrzej.kniola. So it sounds to me like the project should reside in the User Profile folder of each user. But I don’t think there is a way to tell Orchestrator to unpack the project in every User Profile folder (same project unpacked in one folder per user/robot), is there?


#7

Not any I know of.
But the project itself is safer in the ProgramData - normal (non-admin) users can’t access it.
When I wrote that I’d avoid using ProgramData, I meant for input/output files (maybe aside of config, but it loses a lot of functionality if it’s part of the project anyway).


#8

Ok, I’m beginning to see the light. So the Data folder from the ReFrameWork should be in the User Profile folder. How about the Exceptions_Screenshots folder? And can you please give me some examples of why it would be better to have the Config file outside of the project folder as well? Could there be a problem if I leave the Config file in the project folder and multiple robots are trying to read it at the same time? Much appreciated!


#9

Few thoughts

  1. Just an idea, another way to compartmentalize the files for multiple User Instances is to create the folders on the fly at the beginning of your process (probably Pre Init State) but you have to change your paths accordingly.

If Path Exits - If Not

Create Directory Activity

Environment.CurrentDirectory+""+Environment.UserName+"\Data"

Environment.CurrentDirectory+""+Environment.UserName+"\Data\Input"

Environment.CurrentDirectory+""+Environment.UserName+"\Data\Output"

  1. I don’t think if multiple robots reading Config file could cause any issues as long as it is read only. From 2nd Robot on wards the config will open in Read-Only mode.

  2. Regarding the Exception_Screenshots, make sure the Naming Convention of the Images does not create conflict between users.Probably you can append UserName to the File name.


#10

Thank you, vvaidya and andrzej, for your input. So basically when dealing with a process that needs to be run by multiple robots on the same machine I have to choose between two approaches: either I make folders per user inside the project folder or I use the User Profile folder of each user. I’d be curious to know what would be the pros and cons of having a way to unpack the project in each User Profile folder. At first glance, it seems like the best of both worlds but it could lead to problems I’m not aware of (having different copies of the same thing in different places smells fishy already). I pretty much flipped a coin on the marked answer.