Have you ever run into the following scenario:
- An end user complains about an issue with custom functionality that you recently built.
- You are a developer and know that unless you re-create the scenario, troubleshooting or debugging will be impossible.
- You ask the user for more information, set up the test environment and then use real-time native Debug Logs to troubleshoot and fix the issue.
During such times, don’t you wish that the Debug logs were persistent and could somehow store logs of type error or information resulting from various Apex Classes in the org? At least I did and decided to do something about it. The idea was simple and straightforward:
- Create an Apex class to expose methods that can be re-used by other Apex classes to create Persistent Logs of type Error or Information
- Create a custom object (Let’s call it Apex Debug Logs) that holds and stores the above logs as records
This way I can go into the Apex Debug Logs object anytime and take a look at what exactly happened. The records, exception messages and other info from the past are now at my disposal at any given time which is a great help when troubleshooting code related issues. After having implemented this in my instance and religiously using it for over three months now, I can claim that this is a must-have in any Salesforce org which utilizes Apex code for developing custom business logic.
Let’s get down to business and see how it can be implemented in three simple steps:
- Create a Custom object to store the logs of type Error or Info
This object is where you store all the Logs. The exception caught by our try catch block in functional code invokes the method that creates a record in this object. For every exception caught, a new record is created.
- Create an Apex class to expose methods for creating Persistent logs
- Change existing code or new code to invoke our exposed createLog method from #2
Want to see what the records look like when they are fed into our Apex Debug Logs custom object? This is just a list view and you can go into each record to view more detailed information on each exception or information captured from our Apex classes.
You can easily report on the above, eliminate the use of native Debug Logs and System.Debug statements in code and utilize the ADL (Apex Debug Logs) records instead and save yourself a ton of time when troubleshooting and debugging code in most situations. In case you are interested in implementing the above in your own org, here are links to the needed code:
- Main Apex Class:
- Test Class: