Add Log Field Advantages

What are log fields?

Open any logged message in UiPath Studio output pane and view the contents. It’s structured like a dictionary object, with keys and values. A few default keys are message, level, timestamp, and filename.

UiPath gives developers the ability to include additional custom log fields to every message. The REFramework leverages this activity in the Initialization state to add the business process name to every logged message thereafter. For a transactional data process, we can add custom log fields to include specific transaction data in every log message automatically.

Why use it? 

There are two main advantages to using Add Log Field, both of which speed up development and debugging time: 

1. More concise, less verbose log messages 

2. More visibility in log messages

3. Concise Log Messages

Let’s say you’re automating a process that enters employees’ hours worked per day for the whole month. Your source data consists of a Datatable with columns EmployeeName, Date, and HoursWorked. The data includes multiple employees and multiple days. Therefore, the unique identifier for each transaction would be the combination of EmployeeName and Date.

You could include those values in every log message using string concatenation, like below:

However, this adds wordiness to the logs, and takes longer to develop, especially if there are a lot of logged messages:

A better option is to automatically include those two values in every log message using the Add Log Fields activity. Notice the difference in cleanliness and readability compared to the above method.

Double-clicking on one of the log messages will show us our custom fields (highlighted) included with the default fields:

 Visibility

Not are the custom fields included with every Log Message activity, but also any error message. No need to look through previous messages to figure out the transaction information that failed; it is all included in the error message itself: 

This inclusivity/visibility speeds up debugging time in both Orchestrator and non-related to Orchestrator processes, and the custom fields can be easily parsed out of the JSON message if needed. 

How to use it

Configuring the Add Log Fields activity is straightforward; the tricky part is strategically placing the activity to serve the intended purpose. In our Time Entry example, the fields parameter would be configured per the below, with the Name being the field name in the message, and the value being the unique transaction value.

These values are essentially hard-coded and can be changed by removing and re-adding the log fields. Thus, at the end of the transaction, a Remove Log Fields activity is needed to reset and remove the fields in preparation of the next transaction. The value for Remove Log Fields is referring to the name of the custom log field, not the value of the field.

When considering the placement for both Add Log Fields and Remove Log Fields, remember that both must be executed. Guarantee that a possible thrown error doesn't bypass the Remove Log Fields activity. If using the REFramework, place the Add Log Fields activity before the “Invoke Process.xaml” workflow in the Process Transaction state. Then, place the Remove Log Fields activity in the Finally stage of the “Try to process transaction” try-catch in the Process Transaction state. This ensures the Remove Log Fields activity is executed regardless of an error during the process.