How to run a process started from queue based trigger on multiple unattended robots

Hi,

I was wondering if it is possible to run pending items from a queue based trigger on multiple unattended robots.

For example, in my use case I receive 10 items in queue which will result in triggering 10 pending processes.

Is it possible to split those 10 processes ( 5 on a machine, 5 on the other machine so I can reduce the time) ?

Thanks in advance!

@darie.leolea,

No easy or out of the box solution for this.

Possible approaches:

  1. You can create multiple Queue as per machine
  2. Code the logic in a bot.

You can refer this thread for more discussion on this.

I think it’s the opposite of what @ashokkarale says. I fact it is core functionality of Queue Trigger.

You just need to allocate appropriate number of robot runtimes (hosts) to machine template associated with the Queue Trigger (1) and set “Maximum number of pending and running jobs allowed simultaneously.” (2)

Orchestrator will then automaticaly allocate queue items to available robot runtimes.

Cheers

Good point @J0ska. Your approach is feasible when all the available bots are configured and have the required accesses.

If we want to run only on bot1 and bot2 out of 10 available bots for example then can we configure it?

I suppose this is not possible - Orchestrator will utilise all runtimes associated with particular machine template. So if you have 10 bots but only 2 should process particular queue then only 2 bots should use that machine template.

1 Like

Exactly. If only 2 out of 10 bots are capable of executing a process you should group them separately using separate machine/machine templates, and linking them to the correct folders etc.

Although This is still a very static approach imho. I always set it as a requirement that all machines need to be able to do any task, and are therefor automatically eachothers backup. I’m aware that software license costs do not always make this economically viable, but that should pretty much be the only reason to not do this. And even then it is better to manage that on a user account level and not on a bot environment level, making it configurable with little effort.