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.
***Moderator Edit-Vidyaranjan: Updated Platform Capability***
Accenture
DE
By Default, the robot takes the work from all the work queues. Its mandatory that you need to write the activity started event for all the work queue.
Pegasystems Inc.
JP
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.
Pegasystems Inc.
JP
Ok, I've verified on a sandbox that
- a single VM does pick up work from any work queue associated with the work group, but
- the process flow does not terminate the robot process even if "maximum automation execution time" is exceeded.
The documentation says
"In the Maximum automation execution time (seconds) field, enter the amount of time that the VM is expected to take to run the automation that is specified on an assignment in this work queue."
but it doesn't say what's supposed to happen if that time is exceeded? Is pzProcessRoboticAssignments supposed to pick it up, and if so is it supposed to be configured to do so out of the box?
Pegasystems Inc.
JP
Pegasystems Inc.
US
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.
Pegasystems Inc.
JP
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.
Pegasystems Inc.
JP
Pegasystems Inc.
US
Hi Michael -
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)
Pegasystems Inc.
JP
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?