I am looking for the best way possible to implement the following scenario. For the example we’ll say we have 10 VM’s with bots: 5 of them automate different actions in ProgramA, 3 automate different actions in ProgramB, 2 automate different actions in ProgramC. So, to start, each of the bots managing a particular program will be in their own Environment.
Each of the 10 different actions will have their own Queue. Queue items will be added through API calls.
So one option is to simply run each bot on each VM 24/7, constantly looking for a new item in it’s assigned queue and working them as they come in. It’s OK, but I’d like a better option, because some of these automations will probably be more used than others. So I wouldn’t want a queue to start backing up with requests that manages ProgramA when we have 4 other bots that have the same program open sitting there not doing anything because they’re already looking at only 1 queue each.
Ideally I’d like to have a new incoming queue item initiate an automation, and end when finished until the next one comes in. If possible, I’d like to allow it to initiate any available robot within a particular environment.
Is there some way within Orchestrator to… orchestrate this?
I have a easier question… can a bot be initiated from the entry of an item into a queue or does the bot need to be running constantly looking for a queue item? Thanks
you can have a robot checking out every queue and starts jobs accordingly for the queues that have items. We call this a coordinator robot that uses the Orchestrator API to manage workload across queues.
The processes started by the coordinator robot must be transactional, meaning when they finish processing a queue they should stop, instead of waiting for new items to appear.
The coordinator robot must be long running, always checking out all queues and making sure processes are started accordingly
Technically if you’re adding QueueItems via API calls, you could add polling the Jobs and sending a StartJob call if nothing is running for that process.
This was one of the ideas that I had considered looking into but was hoping for something that didn’t involve an extra robot which is one more entity that must be maintained and add one more piece that could potentially break. If a queue item itself can’t initiate a bot then yes I would see that as the only way other than having each robot checking constantly.
Thanks for the answer, it really helps me decide which way to go on this.
I haven’t put this into production yet so we’ll see how it goes. The idea is that I’ll add a queue item with the necessary parameters via the API, then I’ll make a second API call to start the robot. Then robot is set to grab the queue item on startup, do what it needs to do, set the status of the item then shutdown.
I’ve only theorized it. Still in the development of the bots themselves so haven’t done much testing with the API yet. My understanding is the same as yours and andrzej that StartJobs should do it. According to the documentation it will create the job, set to Pending, and alert the robot.
I guess the key question is: who is responsible for handling the items in the queues? Currently a bot can take the responsibility when it’s running (scheduled, manually or via the API). That said, I would expect the Orchestrator to be able to take responsibility here as well and directly assign a new queue item to an available bot that is able to execute the relevant process.
Exactly the same thing I’m having an issue with. It is in all honesty … if this is true … shame! Enterprise level application and does not have an option to auto execute command to robot if queue item is available.
I’ll keep digging on this … but since andra responded I would assume UiPath is already aware. Is this on roadmap?
I get that @badita - the statement of “not short term” is beyond me. Do you honestly think that every individual that has this need will have to create exactly the same robot - all 100 of thousands of us, because I’m sure every individual that plans to have unattended bots will have to do the same.
I will vote it up - but this should not be something up for voting. Especially as easy as (in Orchestrator)
Specify environment to be executed when setting up queue
Check box an option “every time new item comes in - run robots in environment”
On the other note - here is how we will address this issue - hope it helps someone
There has to be something that adds items to queue (in my case one robot is screen scrapping a page to add data) - ADD API call once done screen scrapping to start a job (UiPath)
On File Change activity - if you have a process that changes file - you can use it to wake up robots
You have the right idea @Kemal and I’m sure that will come in time but keep in mind that there may be things that UiPath doesn’t currently do that may get higher priority (like Git integration ) so I understand their voting system. Not saying that it’s not important but which things to tackle first.
Voting, especially community voting, in my mind means - it is not as important to us (UiPath), so we will let you decide. What is the percent of users that use this forum? UiPath should recognize basic functionality need and put that on their road-map. Think of licensing cost as well … if I was to go with suggestion that means I have to buy a “coordinator bot” license to coordinate work, not to mention overhead and another bot that needs to be monitored and supported (support cost)
The category should be:
Nice to have - vote
Must have - on road map
Follow up, who determines the “must have” - they do, and should be directly correlated to cost and maintenance and competitor features.
Anyways, I love the product - don’t get me wrong - I hate workarounds
According to @badita they have it planned so it’s not about if it’s on the road map or not but where it lies in regards to priority. Since there is a workaround I’m guessing priority won’t be too high unless the community would really like a more direct method (where the votes come in).
Fair, I’ve stated it as such in my response to @badita. To me, “in plan” still means we are thinking about it … because I’m sure UiPath goal is absolutely to have everything and anything added to their product - it should be in their plans.
Anyways - I think after all this we are on the same page - just can’t wait to have it as an option.
Point 1. Sometimes not everything is in our mind and, hopefully, we are not one mind. Many opinions here . Many good things that we did not imagine came out via community (see the queue improvements). We don’t pretend to know everything and we try to challenge our ideas constantly. Priorities are permanently changing too.
Point2. Coming back to the point that is already on the roadmap and generated a long debate :). - Queue Based (Best) Scheduler. The only question is when it will be delivered. Voting and debating is a clue that we should prioritize it against other features like
job input arguments
decouple the machine/user for easier provisioning
licensing, to define and be able to run smoothly with different credentials on the same machine
) so I understand their voting system. Not saying that it’s not important but which things to tackle first.
sharazkm32
yulax
pikorpa
Darshan_Sable
AJITH_SK
ruchirmahajan
Manoj_Batra
V_Roboto_V
manasrlenka25