Logging With RFLIB1

Logging in Salesforce with RFLIB

Debugging in Salesforce has its challenges. Sometimes, there might be an Apex error email with a stack trace, but this does typically just point at a location without telling the support person anything about the context of the error. What were the arguments passed into this method? What did those queries return? Nobody knows.

To answer those questions, more detailed logging information is necessary. Out of the box, the platform provides you only with a mechanism to turn on logging for a limited amount of time for log files to be collected and presented in a flat list without any filter criteria and limited navigation capabilities. Since the prediction of errors in your org would require some wizardry skills, any effort to investigate and resolve issues reported by your users would require reactive debugging efforts – meaning that a developer or admin would need to turn on the log files for a user and ask them to reproduce their steps. Unfortunately, that’s not always possible. 

And what if the problem does not lie in Apex, but in the Javascript code of a Lightning Component (Apex or Aura)? That’s even worse because the support staff has to set up a screen sharing session with the user to reproduce the problem and explain to them how to open up a browser developer console, unless they have remote or physical access to the computer.

While those existing tools still allow you to support your users and enable you to identify most problems, I would assume that most of us would agree that it is extremely challenging, time consuming, and at times frustrating to go through such an exercise.

The Art of the Possible

But what if there were a way to monitor the Salesforce org, at least on a business feature level, around the clock (24/7)?

What if admins and developers could be notified of any malfunction within the custom logic of their app, independent of the problem occurring on the server or the browser side? What if there were a way to better filter and view diagnostic information right in Salesforce?

If we keep doing things the same way because, “that’s the way it’s always been,” we’ll never get the chance to see a new way that might actually be so much better. – Donna Martini

Imagine John, a developer at Universal Containers, receiving a notification in his inbox that there was an issue in one of the triggers that got recently deployed to production. He can see the details of the error but also view detailed information of what happened in the transaction before the error occurred, including the ID for the user that experienced the problem, the proper timestamp and diagnostic information about the state of the variables. John can easily retrace the path the code took and eventually understand why the provided exception was thrown. By the time the help desk ticket was opened, John was already working on the fix and close to pushing it to the integrated DEV environment for initial testing.

Imagine Jane, another developer at Universal Containers, was assigned a ticket where Bob, a business user, reported that some component in Salesforce was not displaying the correct information. There is no error related to this issue. Jane signs in to Salesforce, increases the browser logging level for Bob and asks him to reproduce the problem. She launches the log monitoring application in Salesforce and waits for any activity from Bob. As the log events come in, Jane starts to filter them based on implementation details she knows about the component.

Eventually, she finds a log message that confirms the results of Bob’s error description, but also includes a significant amount of context information on what happened in the browser before the issue occurred. This includes information from other custom components as well. She connects the information with logs from the server side and eventually finds a regression that was recently introduced mismatching some arguments for a server query. All of this was accomplished without accessing the Bob’s workstation a single time.

If these stories resonate with you then you are at the right place, because all of this is actually possible with the adoption of the Open Source library called RFLIB! 

RFLIB is a library consisting of multiple modules, but at the core, it is a logging framework for Salesforce that allows developers and admins to add diagnostic information to their Apex and Javascript code, as well as their Process Builders and Flows. All logs are collected 24/7 and when an specific log statement (i.e. an error) is logged, the framework automatically reports all the log statements it has collected in the form of a Platform Event. The event can be viewed in a special dashboard that makes it easy to navigate logs, review or even download them. And if you need the Salesforce Apex logs and other tools in Salesforce to connect the dots, the Salesforce Request ID will allow you to link the information together. 

Interested to hear more?

Check out the video below where you will find more details about the library and a live demo to see the magic happen. Logging is not a nice-to-have but a necessity for any cloud application, and needs to be always active and cover as many areas of the platform as possible. While RFLIB cannot help you to annotate your custom business logic with good diagnostic information, it sure can assist you to access those when it matters the most.

And that’s not all, take advantage of the Feature Switch and Trigger Framework that also come with the library, providing an integrated experience with logging already embedded into it. 

I hope you enjoy the video! 

Leave a Comment