Debugging with the orchestrator is frustrating

Feedback Orchestrator
1

We have several bots that are encountering various issues, some are based on user input, some are external dependencies with apps or sites, and some are bad code. It is essential for me to easily track these issues down and find the patterns, and this appears difficult with the current tools available.
Recent changes
First off, the recent change to the orchestrator introducing folders, have been implemented by us to differentiate the bots we have across the different areas of the business. So, we have folders for sales, shipping, finance and so on. It’s great to have an easier navigation of the bots, but we are just two people managing the entire organisation, so it is essential that we can get a broad overview of the current state of the system and see where an issue has occured. We are looking for application errors in queues through monitoring > queues, because this is the only way we can view the entire state, by ticking off “include sub folders”. Most of the other features of the monitor is useless, because it is only set for the current folder. An easier way to monitor every foldre would make lots of sense.
Navigation
Second, once I identify an issue with a queue, I can’t simply get the relevant logs from the view. I have to navigate to the transaction of the queue, and often the job log as well. This is horrible. After seeing ten red lamps in the monitor, for each I have to go to: Queues > Find the relevant queue > View transactions > Sort by Application Error / Failed > View details for each - and then, for each job: Using the timestamp (which I have to hover the UI to read off), find the job that ran the transaction by going to Jobs, seraching the job name, hovering each timestamp until one matches (usually flipping through pages), opening the job log, flip through pages to look for the timestamp that matches, open View Details and then read the actual error that UI Path gave me. This is insane.
Traceback
Finally, when I have the error, I have to open UI Path and search for the error message I got. This might be something like “Assign: an object reference is not set”. This is very little information to go by. I know we should write meaningful names for every activity, but we haven’t for a long time and there are other ways to make the traceback easier. What I do now is, I search all files for the activity name, then look through each occurence to check if the error might make sense. Very time consuming and labor intensive. Why don’t I get a complete path like Transaction.xaml > Init > Assign?
Solutions
For clarity, I want to tell you what I would like to be able to do when debugging:

  1. Open a monitor which shows me all queues and their status, like we have now, but without the requirement of selecting Show Subfolders. This should be standard.
  2. Clicking each queue should lead me to logs and details relating to the error, eg the data I have to search up through queues and jobs.
  3. Clear, inambiguous traceback from the error message to the file and complete context of the error message. Preferably with a link that will open the project and file in Studio.

I hope there is something I am doing wrong, and there actually is a much better way to debug, but I really had to get this off my chest. For now, it’s back to the horrible browsing.

3

Hi @kbak,

For the first solution you mentioned, have you checked UiPath Insights to see if it can help you with that?

1 Like
4

Hi @kbak,

I second that and I feel your pain.

After some very frustrating days we decided it was enough. Orchestrator does not help us when we need a hotfix and are stuck with parsing logs to find the needle in the haystack. The search function is great but when we are a small team we need results quick.

We use a custom dashboard on Splunk and get all the diagnostic metrics of robot executions, failures and time usage for every process and can slice and dice the data to our liking.

I did pen down the entire process in this thread.

You can choose any software does not need to be Splunk. Even good old excel will be good enough. I cannot talk about UiPath insights as I have not tried it myself and UiPath selling it as another license to me is not a good model in the long run. Too many licenses!

My suggestion is that you take some time to build up a good Nlog format and then start using any visualize / analysis software to ingest and make sense of your logs.

Failure spotting and reporting becomes a simple chore thereafter.

Hope this helps you.

5 Likes