Resource Pool using Environment Locking

[BenAnderson]

Hi, I have created a pool of two resources, and a test process with several items which get added to the queue. I have added "Acquire Lock" and "Release Lock" actions at appropriate stages in the very small process. I have created a schedule to run the process using the Resource Pool, however it only ever seems to run on one Resource.  Does anybody have any experience in getting both resources to work a queue item, until there are none left? I have been trying to get this to work for some time now, and am having no luck.  Any thoughts or suggestions, would be greatly appreciated.  Thank you very much in advance. Ben P.S. Also, in the Session Management view of the Control Room, there is an asterisk beside one of the resources saying "* No sessions". This is whenever nothing has been scheduled or is running. (Please see the attached image). I'm not sure what this means, other than presumably, it is the lead resource.

[TetsujiJunicho]

Hi > however it only ever seems to run on one Resource.  Resource pool is not meant to do parallel processing.  If you want it to do parallel processing, simply put multiple runtime resources in a task of a schedule.   Hope this helps.

[BenAnderson]

Hi tjunicho, Many thanks for your reply,  I'm basically trying to get two bots to work on one process which has a high volume of cases, but can't seem to get it to work. So I've tried creating a task in a schedule, and putting two bots on to the same task - please see the attached screenshot. Would this be the correct way to go about it - and then use environment locking within the one process to acquire and release locks etc? Many thanks for your help, B  

[StevenBlake]

Hi Ben, So if you had a queue of 1000 work items, you want the flexibility to add multiple bots to the queue to work though and pick up any that can be processed? Tjunicho is correct. You don't want pooling for this, you just need to add however many robots you want to work your queue to your schedule setup Control > Schedules > [setup your schedule] > drag your resources into the Scheduled Sessions region. ...then once your schedule kicks off it will run on all of the bots you've specified. Hope that helps Cheers Steve

[BenAnderson]

Thank you Steve

[AmiBarrett]

We ended up writing a custom piece of controller software that would handle this exact scenario via AutomateC. We have ten bots in a pool currently - the software will figure out which queues have the highest load and will engage as many idle bots as-needed. Alternatively, it can also request a stop from a busy bot to make room for the higher priority work. TL;DR - There are ways of doing this, it's just not OOB. However, the API to let you do it is.

[BenAnderson]

Hi amibarrett, Many thanks for the above. So, in terms of using AutomateC, essentially I would want to create some sort of "".bat"" file and write a script which counts how many items are in the queue, and if they are above a certain threshold then engage my two resources? E.g.: ""C:\Program Files\Blue Prism Limited\Blue Prism Automate\AutomateC.exe"" /exportqueue ""QueueName"" ""C:\Program Files\Blue Prism Limited\Blue Prism Automate\AutomateC.exe"" /sso /run ""Process1""   Although I'm not too sure how to divide the queue items up amongst an available resource. I'm assuming that's done by doing what Steve said above - adding the two resources to the process in the Scheduled Sessions region? Many thanks, B

[AmiBarrett]

It's probably easiest to either have a compiled program running in the background, or a web application, which can hook into the DB directly and make calls to AutomateC on the target system, even by way of a batch if needed.   We keep track of which resources are busy, and which queues have the most work to do in separate summary tables for the sake of quick reference. If there are items to be worked, we fill up the resource slots that are available. If new items come in which need to be worked, we can request a stop of a busy resource to make room for a higher priority (by user-definition) queue. Stop requests need to be coded into a decision stage in the running process. For this method, we do not use the session scheduler built into Blue Prism. We have an entirely stand-alone application we've written to handle it instead.

[TetsujiJunicho]

Hi Ben, >Would this be the correct way to go about it - and then use environment locking within the one process to acquire and release locks etc? You got it right about the schedule setup. But I'm not clear about acquiring and releasing locks. If you're worried about some processes acquire the same item in a work queue at the same time, you don't have to. Blue Prism takes care of the locking exclusively unless you want to access a same file or any other resources.    Hope this helps.

[BenAnderson]

Hi tjunicho and amibarrett,   Thank you very much for your prompt replies. I'll take this away and see if I have any success with your solutions/ideas. Many thanks again, B