Speed to next item - workqueue assignment

[NeilPannett]

Hi all, In our BP set-up we have a "delegator" job that works through the items in an internal workqueue and distributes these to different queues depending on the nature of the item. The processing time per item is pretty small, maybe 3-4 seconds, but when you have over 1000 items this represents over an hour's worth of time to get from beginning to end. I have tried running multiple instances of the delegator job concurrently, but this doesn't seem to noticeably reduce the execution time (so one instance takes 60 mins, ten instances running in parallel still takes 60 mins). Is this a limitation of multiple instances searching for the "next available item" in an internal workqueue, or should I be expecting to see some reduction in runtime? Thanks Neil Pannett

[Denis__Dennehy]

Hello, your solution sounds complex so It is difficult to evaluate it based upon a short question in a forum, My recommendation is that your solution design should be discussed with/reviewed by a Delivery Enablement Manager or Trusted Advisor from the Blue Prism Professional Services team - if you have such a person available to you. If all your flow is doing is getting items from a queue and adding items to a different queue, 3-4 seconds sounds extreamly slow. Is there a latency issue with your database connection (is it in a different contenent or something!!). Multiple instances should reduce the time taken - the only reason it would not is if you were using some kind of locking mechonism to stop concurrencly.

[NeilPannett]

Thanks Denis. We do have assigned contacts within the Professional Services team, so I'll reach out to them - I thought it might be worth asking in case it was a known limitation.

[NeilPannett]

Having had a think about this over the weekend, I have a theory that I'm hoping someone can either confirm or deny... When this job worked the queue, it picks up all items in a pending status (which includes deferred items) and the first thing it checks is whether they have a deferred date. If they do, it checks whether this is in the future, and if it is the item is set back to deferred status. Now what I think is happening is that each instance of the process knows not to work the same item twice, so it won't pick up that item again even though it is in deferred status - HOWEVER I think that the other instances of the same process running at the same time WILL pick the item up again. So effectively what is happening is that each deferred item needs to be picked up, checked and then put back by each instance of the process before the supply of items is exhausted. Can anyone confirm if this sounds correct? If so, I'll look at parking the deferred items in another queue.

[ShreyansNahar1]

Hi Neil, As far as I understand, whenever you are using a Get next Item action, the process will not pick up any of the deferred items, but only the ones which are pending but not deferred. So, the process need not check from the deferred date if it has to process that item or not. However, managing deferred data in the same queue is quite complex and a lot of logic needs to be built around ensuring that items are picked correctly. From a controller point of view, he/she can easily see outstanding work in each Work Queue and reallocate robots accordingly, in case different queues are used for normal items and deferred items.This will be easier to build, test and support. However, from a reporting point of view, the multiple queues approach does not provide a single view to generate reports and related MI, which is not the issue in deferring items in the same queue.

[ShreyansNahar1]

Hi Neil, As far as I understand, whenever you are using a Get next Item action, the process will not pick up any of the deferred items, but only the ones which are pending but not deferred. So, the process need not check from the deferred date if it has to process that item or not. However, managing deferred data in the same queue is quite complex and a lot of logic needs to be built around ensuring that items are picked correctly. From a controller point of view, he/she can easily see outstanding work in each Work Queue and reallocate robots accordingly, in case different queues are used for normal items and deferred items.This will be easier to build, test and support. However, from a reporting point of view, the multiple queues approach does not provide a single view to generate reports and related MI, which is not the issue in deferring items in the same queue.