“I love wasting time”, said no one ever. Searching for the cause of a problem can easily consume a lot more time than implementing its solution. Having an email notification system implemented in all UiPath robots is an essential element to having instant access to the most important data needed to find the cause of the problem.
In order to have a solid notification system, the robot should be implemented on the REFramework provided by UiPath. When used correctly, the REFramework provides important functionality through its state transitions and predefined workflows such as ‘SetTransactionStatus.’
During the processing, when an error occurs an exception is thrown. Those exceptions can be:
– Automatically thrown by having the timeout of an activity expire without the activity actually executing (e.g.: the robot cannot click on a button)
– Intentionally thrown by the developer using the ‘Throw’ activity. The developer can choose when an exception should be thrown.
It is important for the developer to throw exceptions in cases in which having an automatically thrown exception can be misleading. A good example of this is the following: After logging into a website, the robot fails the first ‘Click’ that it should do. This is generally caused by the robot not actually successfully logging into the website. The developer should first check if the robot successfully logged in and, in the case in which the login failed, throw an exception with a representative message. If the exception is automatically thrown, the user will see a message like: “Click ‘ButtonName’ Button Failed.” However, if the exception is intentionally thrown by the developer, the message would be: “The robot failed to login into the ‘WebsiteName’ website.” You can already see how useful intentionally throwing exceptions can be towards helping the user understand the issue.
Simply raising the exceptions however, is not enough to notify the user. Next up we have to send the notification to the user, who in this case is the person in charge of running the robot and, sometimes, the developer or the maintenance team.
There are certain events that the user should always be notified of. The following cases are:
– If an exception was thrown during the ‘Init’ stage
– If an exception was thrown during the ‘Process’ stage
– The robot finished processing all of the items
Other than that, there are also some events that can be useful to notify the user about, but are not considered mandatory and their importance is determined on a project-by-project basis. These cases are:
– Exceptions thrown in the ‘Get Transaction Data’ stage
– Exceptions thrown in the ‘End’ stage
In the majority of cases, the best way to notify the user of a certain event is by sending an email. The developer has to create a ‘SendEmail’ workflow by themselves that uses the activities required to send emails to the user’s specific platform (e.g.: Outlook, Gmail). When working on the ‘SendEmail’ workflow, the developer should make sure to allow the addition of screenshots to the email through the use of arguments.
Having a screenshot added to the email can drastically reduce the time of figuring out the source of the problem. A workflow for taking a screenshot is present by default in the REFramework and its name is ‘TakeScreenshot’. To use it, simply invoke it wherever needed and provide a variable for the ‘screenshotPath’ argument. A great example of the impact that it can have is when a popup that was not encountered before suddenly appears during processing. Without a screenshot attached, the developer has to waste time and effortto reproduce the popup in order to understand the error. If the email contains a screenshot then the developer will be able to see the message of the popup and this will make the whole process of resolving the issue significantly faster.
Screenshots should only be sent in the case of SystemExceptions (ApplicationExceptions). In the case of BusinessRuleExceptions, adding a screenshot is not really of any use, although it doesn’t have downsides either.
The other component of the email, besides the attachments, is the body of the email itself. The best method to store and use the body of the email is to get it from the configuration file and have it contain placeholders for relevant data. Those placeholders will then be replaced with actual values when the value is sent to the ‘SendEmail’ workflow as an argument.
The body should also contain a ‘Exception Details’ section. This is generally dedicated to the developer/maintenance team and should contain exception-related data. This data is stored in the exception itself and the most relevant fields to add to the email body are ‘exception.Source’ and ‘exception.Message’.
Once we have a working ‘SendEmail’ workflow, all that is left to do is invoke the workflow wherever it is needed. Generally, there are three places in which the ‘SendEmail’ workflow should be invoked:
– Inside the transition from the ‘Init’ Stage to the ‘End’ stage, when a System Exception has occurred.
– Inside the ‘SetTransactionData’ workflow, on the ‘BusinessException’ and ‘SystemException’ branches
– Inside the ‘End’ stage, after closing all involved applications
The ‘SendEmail’ workflow should be preceded by the ‘TakeScreenshot’ workflow whenever attaching a screenshot to the email is relevant.
Following the information described in this post should provide any developer with a great, solid, and extremely useful emailing notification system.
That’s all there is to it! Best of luck!