Question
Monitoring the health status of Pega Robotics Runtime
We have more than more 200 desktops installed with OpenSpan (Pega Robotics) Runtime installed on our systems. We would like to check if there is a way to monitor the health status of Pega Robotics Runtime, whether they are properly working as desired or if there is an issue with it (for example: in case any Microsoft Security Patch affecting the functionality of OpenSpan - as last year).
Is there a way to monitor the status without using OMC (OpenSpan Management Console)?
Thanks
Murugan
***Updated by Moderator: Marissa to update SR Details***
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Thanks, Thomas. I like the idea of reporting to the database (we currently do this to track the number of users logging in per day, requests taken, etc). But is there any specific exceptions that we could catch to track the health of the bot itself? Can understand on the automation errors, but will be really huge to track to catch all errors in the database.
I'm looking to see like if OpenSpan has successfully started the automations (once Runtime started), security patch issues, installation/configuration issues, any other...
Thanks
Murugan
Accepted Solution
I'm not sure there is anything generic you can track. Since Pega Robotics is a tool, you can build any functionality you want. There really is nothing specific you can watch for to determine if your automations are not working other than to record any error they may have. Thinds like Microsoft KBs that cause issues can be caught in a test environment beforehand by applying the patch to a machine automated to perform known steps as I suggested above.
As Thomas said, the way this is done within the product is through the Pega Robotic Automation Deployment Portal (formerly OMC). Any enhancements to this will be done within the confines of the Portal and operational reporting would currently satisfy most of what you have mentioned. Do you have a specific reason for not wanting to implement the Portal?
Hi Jeff,
Apologies for the delay in reply. The reason is because not all the end users (agents) have access to the Internet (much due to security reasons).
Thanks
Murugan
The product provides operational reporting to OMC when enabled. This won't specifically include the health of any automation, but rather raw data on their execution and timings. If you wanted to track the health though by running a specific automation on errors, you could do that.
There is no built-in way to track this otherwise, however we do have many data components available, allowing you to report anything you like to your own database or other applications without using OMC. If you had a web service or database that you wanted to call when there was an issue, you are certainly able to do that.
My guess on the issues with the security patch are that you would get better feedback from users when something critical happens that prevents the automations from working at all. Likely, users would not run them if they were not working, so tracking any errors would only help initially and you'd likely notice a fall off in the number of executions.
One thing other customers have done is to create automated tests across known accounts to execute specific automations regularly. This allows you to be somewhat proactive in that you can apply patches and newer versions to this machine first and run your tests against it.