If a process has a high-volume of items to work, allow multiple processes to run the same process simultaneously. This would drastically drive up the savings-per-process, and may give some more meaning to Work Queue prioritization.
It might have been a limitation of our environment (5.4), but when we have multiple schedule attempts to run the same process against a pool, we only get a single instance. This kind of ties into the other idea I had posted about tying processes to Work Queues, where a dynamic number of them could be spun up.
You probably know this already, so forgive me, but when you run a process on a pool, you'll get 1 session. It's a common misconception that you'll get a session on every member in the pool.
If a schedule has 3 tasks, each one to run process X on pool Y, then I'd expect to start 3 sessions. But I guess for you tasks 2 and 3 fail?
Pretty much, since they're pointed to the same root resource (the pool). If we have dedicated, non-pooled machines we can point to, then it works as you describe.
Can you please provide some more details on this for me? Can I ask whether you've tried creating multiple sessions on that single pool as part of the single schedule task and, if so, what you saw when you tried this?
Marking this idea as Needs More Info pending your response!
@robert.nicklin - Again, this was submitted back when I was working in a much earlier version of Blue Prism and may be resolved at this point. At the time, if we had a resource pool set up within the environment and attempted to execute a process against it (either manually or via schedule), we could only get the process to start once. Attempting to start the same process against the same pool would silent fail (process would not run, go into pending or throw a visible error) if we attempted additional instances. This was despite us having slots available in our license to run against.
Subsequent run attempts were attempted as either additional tasks in the same schedule, multiple attempts to run within a single task of a schedule, manually starting a schedule that was already running, or dragging a process to a resource pool while the process was already running on one resource within a pool.
I'm going to have the development team look into this and tell me whether this is expected to work as we think it should (i.e. you should be able to start multiple instances of a single process on a pool, provided that pool has members available and there are licenses available) and if so I'm going to mark this as Not Planned on the basis that is should already work!
If there's any deviation from that behaviour I would say that should be considered a bug that can be raised through support.
