Managing Sensitive Logging Using the PrimedLogging Enterprise Library

As the sole robot master of my IT team, I’ve spent a considerable amount of time automating some of our back-office applications at my place of work. One of the biggest lessons I learned—when I descended into the real world with my hard-earned Robotic Process Automation (RPA) knowledge around my belt—was the sensitivity with which humans would treat a process when it was taken away from their hands and put into the charge of a software robot.

The more sensitive and confidential the nature of the function performed by the back-office process/application, the more scrutiny the robot attracted.

One such area, which (ironically) is most ubiquitous and often taken for granted, is application and error logging. As an RPA application builder, I relied on application logging to develop and test our RPA processes. Also, these logs were immensely helpful in demonstrating the workings of a robot to “robot owners” who would finally own and operate their robots once it was deployed (after due process). This is when I realized that in my line of work, managing application logs in our RPA application was quickly going from becoming an asset, to a necessary inconvenience.

It made me wish that I had given this aspect of our RPA process design a little more thought early in the development lifecycle.

So, why was this becoming a necessary inconvenience?

We went liberal with logging and that made it very easy to explain to the business teams how a software robot would automate certain aspects of their business processes. It raised eyebrows about how much of this information would be logged to the RPA application logs. As usual, the first option that came to mind was the human-intensive practice of disabling the activities in our code that logged sensitive information before we packaged and deployed our RPA application.

So, what do I do when I need to fix or enhance this application a few weeks after it has been deployed? How do I remember which Write Line or Log Message UiPath activity is sensitive and which isn’t?! And when I deploy the next update, do I have to do this all over again? This was becoming very painful and something had to be done—and quickly! 

Enter PrimedLogging

Primed is a synonym of the word managed. I wanted this name because everything we do in the modern workday environment is managed or needs to be informed or in readiness in one way or the other. And I didn’t want to create something with a cliché name. 

Therefore, I named this library PrimedLogging because it helps me to: 

• Be in a state of readiness to better manage the logs of the Robots output as they went about their daily business

• Very quickly take my Robots from full logging behavior to managed logging behavior at the flick of a configuration value

• Eliminate the archaic and human-intensive process of enabling and disabling the Write Line or Log Message UiPath activities when switching between development and production deployments 

Sensitive logging

Most organizations in the current age have strict guidelines on what kind of information can be disseminated across an enterprise through their modes of communication practices, documentation practices, or via automated processes. 

At least in my line of work, security is everything. 

The first thing we talk about when we bring in new software for the purposes of trials is to start thinking about how to get it cleared through our security team. And if it is cloud-based software, this task becomes much more involved! 

Therefore, there was genuine concern when I automated a couple of internal business processes that involved our internal ticketing system and “sensitive” human resources (HR)-related activities. The concern was related to what information is logged by the robot when it was finally deployed to UiPath Orchestrator. It didn’t make a difference if the Orchestrator was on-premises or in the cloud. 

And therefore, we had to have a way to meet the two objectives of our RPA process design that were opposite to each other:

• Enable detailed logging in the development environment for testing and end user acceptance

• Shut off snippets of sensitive information when the application was deployed to production with the least amount of effort possible 

That said, employing the PrimedLogging library in your RPA processes does not take you away from regular means of using the Write Line or Log Message UiPath activities. 

You can check out the PrimedLogging component and its documentation at the UiPath Marketplace to understand when and when not to use PrimedLogging.

Using PrimedLogging

The degree to which you will employ PrimedLogging in your RPA process is governed by several factors (in addition to your organizational guidelines). 

But, let’s take a quick look at how you would use this feature in your applications. 

The library documentation has detailed information on how to add PrimedLogging to your projects. But the main objective of this library is to replace certain Write Line or Log Message UiPath activities (that are deemed sensitive) with a PrimedLog activity and specify the message to be logged in the PrimedLog activity instead of utilizing Write Line or Log Message UiPath activities.

In this basic test harness, above, a message deemed “sensitive” has been put through a PrimedLog activity whilst an ordinary message follows the usual path of being logged via the Write Line activity. 

Next, you’ll need to configure the PrimedLog activities in your project to globally enable or prevent writing messages to the output log or console. You’ll do this by configuring a global setting that will be used by all PrimedLog activities in your project. 

Enabling this setting (during development) will empower all PrimedLog activities to output messages to the log. And when this setting is disabled (in production), all PrimedLog activities will be bypassed and prevented from writing output to the logs.

There are multiple ways to regulate this setting in your RPA processes: 

• Place the configuration setting in an external file and enable your RPA process to read this setting on startup.

• Alter the signature of your startup Main.xaml file (as shown below) to accept an input argument that can then be overridden at the Process level or Job level when you finally deploy to the Orchestrator.

As a best practice, it’s good to set the value of this configuration setting to N (or No) by default so that it becomes less painful and more secure when deploying your application to production. It can always be overridden in the development environment and set to Y (or Yes) to enable the logging of sensitive information for the purposes of development and testing.

In addition to these two important steps, the PrimedLogging library enables you to set different levels of logging for the PrimedLog activity. The PrimedLogging documentation covers these aspects in much more detail.

Here’s the result of our simple test: Observe how the logging behavior differs between development and production environments based on how the configuration is enabled or disabled.

The ordinary message is visible in both environments while the sensitive message has been suppressed in production on the right.

Conclusion

By employing a relatively simple series of steps, you can easily govern the behavior of your robots without having to go through extensive modifications and version changes to your code between environments.

Logging is indispensable to how we build, test, and monitor our RPA processes. The more intricate or larger the application, the more difficult it would be for us to manage this aspect of our process.