When we build automation to attempt an RPA demand, we also need to pay attention to how we will manage the performance of this robot and what we need to monitor. Within these questions, we also need to evaluate which tools we will use for this. In this article, we want to show you how to do this orchestration and discuss some types of logs that may be important for your application, considering, as an example, the development with Python RPA.
What is a log?
A log records what happened at a certain point in our automation, returning data from the execution of one of your code’s processes.
It may have different structures according to the requirements that we must attend to. Still, logs usually have at least the date and time of the event, the message corresponding to the event, and some identification related to the context, among others.
What is the importance of a log?
During the execution of automation, we may have several necessary steps, which we need to know if the execution happened with success and how this process went. Was it a successful execution? Or has something gone wrong? If there was a problem, what was it? What was the context of the application during this problem? Is it something the team or the responsible person needs to act on or look into?
These and other questions that may arise in the meantime. Logs are part of a management process that helps us answer these questions and know where and how to act when there is a problem.
What are the types of logs?
Code execution error logs
These logs refer to errors related to the code built for running your RPA project. These are the exceptions. These exceptions can be related to the programming language used, or exceptions that you can create according to the context of your application. They often have specific names that help us to have an understanding of what may have happened, if returned.
Security logs
These logs can bring more specific context about the safety of your automation. Remember that an RPA project is also a software project. And it should have concerns such as quality, safety and other relevant points to follow up. They can bring more specific data such as access issues, security policies that were not followed, among others.
Business logs
Your project may have logs that do not refer to the code specifically but to the context of the executed process. They can have some information such as which process was or was not executed, in which stage the robot is at a given moment, and which documents treated in that task performed, among others.
Are there other types of logs?
Yes. It all depends on what you need to manage in your automation. There are, for example, logs related to auditing and associated with your robot’s metrics, among many others.
Do I need to have logs of everything that happens in the automation?
If you want to log everything, you can. But you don’t have to. And it is not recommended. The most important thing is not to log each piece of information. What you need to do is to understand the processes that executed and what is the crucial data to log for management. Otherwise, when you need, for example, to understand an error, you will have a lot to read and understand until you get to the point where you need to act.
And where do these records go and how to access them?
And now, we get into the management tools and how to do this in your code. After all, you can only record a log if you develop it in your project.
One of the ways to carry out this log management process would be using BotCity Maestro, with support from the tool’s API and also with support from the interface. We will look at this in part 2 of this series of articles.
Do you already know what you need to log in your automation?
Do this exercise to understand, according to your project requirements, which are the important logs to consider. Understand the processes that need to happen and what are the crucial points to manage. It is also important to remember what can and cannot be logged: for example, sensitive data such as CPF. Is it really necessary to expose this data? Or could you create a unique ID for each customer so that, if necessary, you can check which one the problem happened to?
Share these important points with your team, and in the next article we will show you how to create your log in practice.
