After looking around for answers, I’ve found the following posts addressing the same or similar issue.
However, none of the answers would directly resolve or guide us to resolve the issue.
As the unattended bots goes to production, and pass the hypercare period, it is not feasible to watch or monitor the bots performance all the time (if not 24/7). Thus it requires a method to know:
If the bot is stuck in a never-ending situation, or it is being idle for a long time. Sometimes, the bot is designed not well enough to detect certain errors in the run time that it would be stuck there without moving forward or throw exceptions. For instance, a new pop-up window or a faulty state transition* If the bot is working as scheduled. Cause the schedule could be pushed by other bots running on the same environment, it is crucial to know that whether the bots schedule is being disrupted or not
If the bot is ended earlier than it supposed to. Cause the bot can be well designed to catch all errors, and end the process without crashing. For instance, only half of the queue is executed and the bot goes to “catch” block and stopped
In general, you will always encounter some issues in production robots that were not envisaged or caught during testing. That’s the same for any and all applications.
However, it reads to me as if you are looking to implement some kind of high level monitoring system for your robots, with acceptable thresholds (such as waiting time on a particular process perhaps). This is a very common requirement and there have been a few solutions, using different analytics tools, to provide for it on UiPath Go.
Well said @ronanpeter . Exactly, sometimes it’s not worth to invent wheel from the scratch. I mean it’s not like we don’t want to. But there are other already created solutions which fits perfectly here.
Totally agree there! No need to reinvent the wheels.
However, the project was running with SQL DB for quite a while now. And to use SQL data to construct the Kinana dashboard is indeed reinvent the wheel in my case.
So far, only final productions are found on online as shared by @ronanpeter, however no tutorials of how to come to that final place.
For instance how to create each individual log to fit a proper “Index”. How to keep the data flow from SQL to ElasticSearch.