Posted: 15 Aug 2018 22:43 EDT Last activity: 31 Aug 2018 11:48 EDT
Pega Robotics Studio 8: VM taking work from multiple queues (work baskets)
In PRPC 7.4,
a single VM is configured to be associated with a single work group
a single work group can only have one default work queue (work basket), but many work queues can be associated with that work group
Can the VM be configured to take work not only from the default work queue, but all work queues which have that work group as its default work group?
The reason we need this is:
the timeout for a robot which runs too long is set on the work queue,
but the expected time a robot takes to run depends on the actual robot activity, so
we want to create a different work queue for each robot activity, but
have the VM pick up any robot activity linked to any of the multiple work queues associated with its work group
If we can't enable this, we'll need separate VMs for each job type, which defeats the goal of improving efficiency as we have up to 40 robot activities which run in sequence, some big, some small. We don't want to have to set up 40 VMs each waiting for it's job to come round then idle the rest of the time: we want all PCs to be able to run all activities.
Thank you for your prompt response: yes I did suspect that but I couldn't find it in the help (if you could link help documentation which states that it would be even better). We are currently on 7.22 which does not behave like this and it will become a factor in our upgrade.
Is that written somewhere in the documentation? Without this we can't even tell if behaviour we see is correct or incorrect, and hence whether we should build it ourselves or report to GSC.
My current automation doesn't change the status of the assignment - it goes right past the timeout and completes the processing normally. From my observation the agent which calls pzProcessRoboticAssignments is running.
The max execution time is simply a guideline for what turns the icon red when viewing the bot on the robot manager page. It does not trigger anything in the bot itself. If you wanted the automation itself to stop after a period of time, you'd need to code that into the bot.
If my reading of the agent is correct, the activity pzProcessRoboticAssignments (which according to its comment "transfer(s) stale records in robot assignment back to work basket") is called from the agent RoboticAssignmentProcessing every 30 minutes; it moves any job which has taken longer than double the max execution time to the stale job workbasket.
The strange thing is max execution times are usually in the order of 5-10 minutes, but if the agent is only set to run every 30 minutes, in most cases it will allow the job to run much longer than it should - but in some cases, namely jobs which start running just a bit more than their max execution time before the 30 minute mark, the job will be moved pretty much on its max execution time. This is very unusual behaviour - we will modify the agent to run every two minutes.
I verified that the job does indeed timeout if the agent Mode is set to Advanced; I couldn't get it to work with Standard; however, this is an agent queuing issue and not the topic for this thread.
Ok, this is my take from reverse engineering and experimentation. If I'm right it means that SharathBabu523 was 80% right at the outset.
1. Our current version of Runtime (1088) takes assignments from all Work Queues associated its Work Group as set in CommonConfig.xml. This was not the case with our previous version (1037) where it only took from the Work Basket of the same name as the Work Group
2. PRPC has an agent, RoboticAssignmentProcessing, which despite the misleading name looks for stale assignments and moves them back to the work basket. In our current version (7.4), a "stale" assignment is one which has been running for more than *twice* the timeout specified for that Work Queue. This is was not always the case - in our previous version (7.22) it was simply the timeout specified.
3. In both versions the above agent appears to run far too rarely (once every 30 minutes) to pick up most stale assignments - it must be built on the assumption that the average robot runs for hours. In addition, the agent does not appear to run by default and we had to change the settings to get it to run.
Are you still having issues or are you all set now w/ this thread? The robot pulls assignments from any workqueues which it has access to. (You can always double-check which queues are "visible" to a robot by looking at the robot operator record inside Dev Studio).
Our best practice is to have work queues that belong to distinct workgroups, without mixing and matching.
(Eg. A workgroup points to a default queue. That queue also "points back" to that same workgroup)
Funny, I just recently announced to our client that work groups and work queues no longer need to be 1:1, and recommended that they use different work queues to enable different timeout settings. Given a VM (≅work group) runs multiple activities each of which have different expected run times, setting different timeouts is mandatory for us as it probably is for anyone else who doesn't have a machine dedicated to each activity.
Assuming the above advice is correct, I first wanted to know if Pega-ProCom:RoboticAssignmentProcessing was indeed the agent which is supposed to pick up robot jobs which have exceeded their maximum run time (now twice pyMaxExecutionTime, right??), and if so why is it set to run so infrequently?