Getting Pending and Deferred Items

[stepher]

Greetings, All,

I just recognized that I have been missing something...for years.  File this under 'I assumed it was working the way I expected.'

I have a number of processes where the target application only allows a single instance of the 'parent' record to be open while working the 'child' record.  To accommodate this, I set up an Environmental Lock keyed to the 'parent' record ID.  If the 'parent' record is found to be in use, the 'child' record is deferred for some amount of time.  

Now to the process and the question/challenge at hand.  I have a screenshot of my standard 'Get Next Item' loop.  This checks for a pending Item and, if it finds one, it goes on its way.  If it does not find a pending record, it waits 15s (in this case) and then rechecks.  Again, if it finds one, it continues on.  If it still does not find a pending record it now looks for [what I believed] was any pending item.  My thought was that any record that had been deferred, based on an existing lock, would reset the check process.  I honestly thought my primary issue was going to be akin to an 'infinite loop', but that never happened.  And now I know why.  The get 'Pending Items' is not recognizing deferred items, which closes out this step and sets the deferred items as orphans.

Looking at the screenshot, I have one clarification:  The 'Got Item?' decisions are based on returning an Item ID, which is held off-page in a global variable.

Does anybody have a better (or at least functional) method to address this?

Thanks in advance,

Red

Our Standard 'Get Next Item' Loop

[Denis__Dennehy · Accepted solution]

Hello. From your flow I am not sure if you are using one queue or two? From your explanation I think you have one queue with same keys in a number of items and are using environmental lock to try to make sure all items are processed together by the same robot? 

I required a similar process logic many years ago at a telecom client (2012 maybe!). My solution was to have two work queues, a parent queue and a child queue.  The child queue would only be read by the robot that had locked the parent item. This seemed clean as the parent queue was good for monitoring how many of the unique keys had been processed, it also avoided needing complex lock logic.

[stepher]

Thanks so much for your reply, @Denis__Dennehy ,

The suggestion make sense.  The process currently uses two Blue Prism WQs, one for 'workqueues' (sic) within the target application and one for the records contained within these.  I could insert a third BPWQ to manage the parent records.

I will look into this. Thanks!

Red

[grbanares]

Agree on using multiple work queues. Load the child work queue when you are processing the parent work queue then process them one-by-one. This will keep your parent item locked while working on the subsequent items. You won't need to defer the queue item at this stage as they are getting processed in a waterfall style. I hope that makes sense... and it helps. 🙂