Different types of logs and their fields in RPA



The word "log" has probably been used or seen in at least one circumstance if you've worked with software for any length of time. Some frequent expressions, particularly in relation to RPA, are "Add them to logs," "verify the logs," "do they belong to logs?," these are some common types of questions that arise while working with RPA.

Consider the fact that you (or your business) have recently spent a sizable amount of money on infrastructure, development, training, process identification, and robotics. You'll want to find out how everything is doing, including how well you're using your robots, whether you're using them effectively, and whether your automations are working well or frequently failing.

There isn't exactly a straightforward way to see this information at every level. Even programmers can only really monitor the performance of their automations if they witness them in action and keep an eye on the process logs. In essence, it's impossible to find a comprehensive viewpoint in one place.

Types of Logs

The UiPath Platform has all possible capabilities for all of its important components. UiPath specific logs are based on the Nlog infrastructure (Nlog are nothing but the neutral log that work according to the different condition). These logs can be classified by different characteristics, which are as follows −

Log Category

  • Execution start

  • Execution end

  • Transaction start

  • Transaction end

  • Error log

Debugging Log

The log category can be judged in different ways, which describes whether the log message is designed by the physical user or is by default generated by the system itself, logs can either be −

Default Logs

generated by default itself when the execution of a project starts and ends at last, but let's assume when a system error occurs in between and the execution stops, or when the logging settings are configured to log the execution of every activity. The events logged by this category are −

  • Execution of task Start is generated every time a process is started (Level = Information)

  • Execution of task End is generated every time when a process is finalized (Level = Information)

  • Transaction of task Start is generated every time a transaction within a process is started (Level = Information)

  • Transaction End is generated every time a transaction within a process is finalized (Level = Information)

  • Error Log is generated every time the execution encounters an error and stops (Level = Error)

  • Debugging Log (Level = Trace) is generated if the Robot Logging Setting is set to Verbose and contains activity names, types, variable values, arguments etc.

User−Defined Logs

Generated according to the process designed by the user in Studio, when using the Log Message activity or the Write Line activity.

Log Fields

Default fields

  • Message − The log message.

  • Level − Defines the log severity.

  • Timestamp − The exact date and time the action was performed.

  • FileName − The name of the .xaml file being processes

  • jobId − The keyId of the job process.

  • processName − The name of the process that should be done by bots.

  • processVersion − The version number of the process.

  • windowsIdentity − The name of the user that performed the action.

  • robotName − The name of the Robot

  • machineName − The name of the bot machine.

  • machineId − The id of the bot machine.

These logs are stored as JSON files, which are essentially just key−value pairs with the format "fieldx=valuex" and "fieldy=value(y)." They are delivered to the UiPath Orchestrator, which adds the following new fields −

  • Log message-based message.

  • Degree of log severity.

  • The timestamp shows the date and time when the action was completed.

  • FileName, the name of the.xaml file being "run".

  • JobId − the unique key for the job that is conducting the process.

  • ProcessName is the title of the process.

  • ProcessVersion, or the process's version, is number seven.

  • WindowsIdentity − The user whose action was recorded.

  • RobotName, which is the name of the robot (defined in Orchestrator)

  • MachineName − the name of the device to which the Robot was attached when the process was being conducted.

When your logs are finished, you have a few options for where you want to put them. Your logs will automatically be forwarded to Elasticsearch and the SQL database that Orchestrator is supported by. Either confine your logs to just SQL or only Elasticsearch, or neither! The latter method is less recommended because the data is crucial for any type of analytics you choose to perform, but it is entirely up to you.


Advertisements