Multiple Tasks

robot
i_parked
tasks
licenses

#1

Hi guys,

I have been thinking that it was a bit of a mistake to restrict machines to running only one process at any given time, and I am wondering if it possible for you to re-implement this in some form. Here are my reasonings for this:

  1. I understand that you want to prevent misuse of licenses, however, the main strength of UiPath is the simulation of user actions in Windows/Citrix etc…Therefore, if people are using UiPath to simply run hundreds of tasks, they could probably just do this using other scripting tools such as Powershell. At least they are using UiPath in this case.

  2. It remains annoying that you couldn’t run a non-interactive load process for back office automation. Now we are forced to find workarounds which effectively does the same thing but is less impressive. For example, you cannot run constantly in the background checking every 5 minutes for some activity such as a new email in the Inbox.

  3. When considering Front Office automation, this restriction could have a huge impact. Rather than running multiple processes simultaneously whether they be email generation or simulating activity with an application, we are forced to run things sequentially. This obviously means the overall time is far greater and the impact of FO automation is not as impressive.

Happy to hear your reasons for not doing this but thought it was worth raising. I really don’t think the concerns over misuse are valid but I may be wrong. Perhaps you could restrict to 3 processes to make this more reasonable?

Richard


#2

Have you tried High-Density robots? I haven’t, but it might be a solution (although still requiring multiple users AFAIK).


#3

So what shall we implement? Allow for batch processes (no interactive session). Robots are cheap on the BO side.
FO is for interactive processes, otherwise you could switch it to BO.


#4

#2 You can use the “Parallel” activity for non-interactive back office processes.


#5

I wouldn’t consider this a reliable solution, as it would still run as a single job - no separation of run times, no separation of workflows (need to update whole package). If one side goes south, they’re both gone.


#6

High Density Robots (now I’ve done my research) doesn’t really help here as you still need a license per new resource (VM). This is two processes which are related but ideally need to run at the same time.

I was thinking along the lines of maybe just having two licenses but that’s quite expensive when really they’re part of the same job. So much of the training/standards is based around a Load and then a Work process (or a despatcher and something else you’re calling it now!!) that I feel this is fundamental to the way things should be done.

RD


#7

I don’t regard to this as being a big issue. You could have 20 Work processes on 40 bots. Load processes are usually less time consuming so one license could be enough to handle the load, is it? Just schedule them to run every 3 mins during one hour.


#8

OK let’s end this. I’ll re-raise again if it ever become a problem.

RD