Error Handling¶
Error Handling lets Anymate help you look at the big picture and ensure that everything is running how it should be.
Retrying Tasks¶
Retrying is enabled with the "Allow Mates to retry Task" option. If it is not enabled and a Mate attemps to Retry a Task by using the Retry endpoint, the task will automatically be sent to Manual with an Error. This is done as typically a Task is sent to be retried because something unexpected happened, but the Developer anticipates that the error was not consistent (e.g. a timeout error in UiPath) and might not happen when trying to Task again later.
If retrying is enabled, using the Retry endpoint will result in the Task returning to the bottom of the Ready queue. Once the Mate gets to it again, it will appear as a normal Task.
Use Reason as the Tasks state
As Reason is included in the object when calling TakeNext, it is possible to use Reason to keep a state on how much of the Task has been completed. For some advanced Processes, maybe solving a Task involves performing work in several systems. Maybe the Task is sent to Retry after the work has been done in the first two systems with still another third system to go. By setting a Reason that indicates this state, it is possible to code the Mate to resume directly in the third system without possible generating errors because the work has already been completed in the first two.
When enabling retrying, a limit is set for how many times each Task can be retried. This is done to avoid infinite retry-loops. What we have seen is, if a Task can't be completed after 3-5 retries, it probably never will without a code change in the software automation.
Emergency Stops¶
Emergency Stops works to monitor how many Errors we have in total on the Process, and once a threshold is passed the Process Gate will be set to closed and it will not be possible for the Mate to do any further work until a Developer has looked at the situation.
Anymate looks at two types of Errors - Errors reported by the Mate using the Error endpoint and "Not Closed Right" errors.
Error Endpoint errors can be monitored seperately by enabling "Stop on Errors" and setting a threshold. Once the threshold is passed, the Process Gate is closed and will be automatically closed everytime the Mate tries to access the Process, until the Errors have been solved. An Error is solved by moving the Task to a new Queue (it can also be moved to the Manual queue to keep it in the Manual queue without the Error flag).
Not Closed Right errors happen when a Mate is taking tasks using TakeNext but never return them to Anymate. Once a Task has been taken, it must be returned using either Solved, Manual, Error or Retry. It is always a good idea to enable Stop Mate if Task is not Closed right and put a reasonable threshold. The problem is obvious - if the Task is taken but not returned to Anymate, then nobody will know whether that is because a Mate is still working on it, if there was an error or if it was solved perfectly fine.
Always enable emergemncy stops
We always recommend enabling both these emergency stops. If a pattern of errors should emerge, it is always better to catch it early after 5-10 instances have occurred, rather than end up with 500 errors and having to explain the business that they have to do some overtime.
Monitoring¶
All our monitoring is based on when we see a Mate. We see a Mate is active, when for instance the OkToRun, StartRun or TakeNext endpoint is called.
This way, we can give early warnings even if there isn't any Tasks waiting in the queue for Mate. And likewise, a Mate can be running perfectly fine but not doing any work, and we can recognise that.
AI Monitoring¶
The Anymate AI Monitoring uses machine learning to monitor each Process, looking at when and how often a Mate is running. Once a Process is put in production, Anymate starts learning how the Mate interacts with the Process. It typically takes a few weeks before Anymate AI has enough data to see a pattern in behavior.
Be careful of schedule changes
As the Anymate AI learns how the behavior on the Process, if the schedule is suddenly changed then the AI will generate warnings that are according to the old schedule until it learns the new. It happens gradually, as Anymate AI can not know if the schedule was changed on purpose or another external action happened that is causing the pattern to change.
Warn if Mate has not run¶
This warning is schedule based. You set the schedule of how often your mate is supposed to run, and Anymate will generate warnings if it doesn't hear from the Mate according to that Schedule. The schedule is based on CRON expressions but have an easy to use UI on top.
Be careful of threading
If the server responsible for running the Mates has a limited number of threads, and you have a lot of Mates sharing resources, you can sometimes see false warnings if one Mate has a lot of work and is blocking other Mates from getting started.
Dead man's Switch¶
Dead man's Switch is a very simple form of monitoring. It works by setting a threshold, in hours, for how long it can be between hearing from the Mate. Simply put, if it is set to 72 hours then if Anymate does not see any life signs from the Mate for 3 days it will raise a warning. It can be useful as a warning if all else fails, or for Mates that you know run very often (e.g. once every 2 hours) where you want a warning as early as possible.
Be careful of mondays
If your Mate is not working in the weekend, then you can easily end up having false warnings monday morning until the Mate starts working. The same applies after holidays. Either you live with a few false warnings, or you rely on one of the other monitoring options.
Manual Control¶
Manual Control is used to randomly sample Tasks that are solved by Mate. Once you have a set how large an amount of Tasks you want sampled, e.g. 3 out of 100 tasks, Anymate will randomly take out Tasks that are solved by a Mate and move them to Manual with the reason Manual Control. From here, an employee will have to review them and manually move them to Solved if they are solved correct.
Use Manual Control to catch Errors that would otherwise go unnoticed
Manual Control is a great way to ensure that someone keeps an eye on what the Mate is doing. When coding a piece of software automation, it can happen that the Mate thinks it is solving everything how it should be but some error goes unnoticed. If a Mate does not know something is an Error, it can't possible report it as such. This is one of the places where Manual Control really shines.