How does does RuntimeConfig and the Workgroup get assigned via Robot Manager & the RPA Service?
I have been working on setting up a proof of concept using non-persistent VMs for robots. I noticed that in Robot Manager you can move robots from one workgroup to another. You can also create and assign Runtime configs.
I notice that the workgroup assignment is in the Common config file, which I assume is edited by the RPA service when Robot Manager tells it that the value must be changed. Is that so?
Does the RPA Service check with Robot Manager to get the assigned workgroup and Runtime config each time it starts up? Or does it only get the new values when they're changed in Robot Manager?
If it's the former then the non-persistence of the VMs would not matter, as the RPA service will set things like they should be on each start and/or heartbeat, no matter what the default settings are in the local configs.
But if it's the latter then the non-persistence of the VMs means that when it's reverted to its original state, the default config files will also be restored and both the workgroup and the RuntimeConfig would have to be manually reassigned in Robot Manager. And that would be undesirable.
I'm asking these questions now to get some idea, as I'm not currently able to continue with the proof of concept to try it first hand.
Thanks!
Pegasystems Inc.
GB
Hi,
The work group value in CommonConfig.xml can be used but it's the legacy way of setting it. It can be setup directly within Robot Manager https://community.pega.com/knowledgebase/articles/pega-rpa/configuring-pega-robot-manager-842#registration and https://community.pega.com/knowledgebase/articles/pega-rpa/changing-settings-pega-robot-manager-interface-842
The connectivity to Robot Manager it is setup in CommonConfig.xml you at least will need to have this in the VM configuration. The RPA Service setup requires to configure which accounts should be used to create the Windows session this should be in the VM configuration was well. You could potentially use non-persistent VMs but if for whatever reason the automation you create fails or the VM crashes you won't have the log files to understand what went wrong.
In sort, you can get it to work with non-persistent VMs if the default configuration contains everything required to connect to RM and to manage the sessions but you won't have logs if things go wrong.
Does this make sense?
Angel
HealthFirst
US
Hi Angel.
Yes that makes sense. I have some different possibilities for getting the logs, including copying them to a network folder or using Splunk.
For the configurations, I just want to make sure that someone would not have to manually reassign the workgroup and Runtime config through RobotManager every time the VMs get restarted and revert to their original state. We can take care of making sure the default configs point them to the correct Robot Manager and specify the correct session and registration operator accounts.
Pegasystems Inc.
GB
Hi,
RuntimeConfig.xml can be assigned from Robot Manager as well and the Runtime will download it at startup so you don't need to worry about that.
The solution package is dynamic and the only overload is that it will be downloaded every time instead of be cached in the VM as it does when the VM is persistent.