Static Logging

Ok, now we're getting to the topics that are a little more complicated.  That being said, they are really important to understand so that you can design logs that are as clear and simple as possible.

Apex code can be written in limitless ways and with different complexities, ranging from a simple Trigger snippet to a complex series of code layers that interact uniquely with one another.  Our Apex Monitoring Basics article described the three-step process of creating a basic monitor, as shown below.

 public static void calculateBillingLines(){
     EventLogger el = Logging.startLog('Calculate Billing Lines');

     el.log('Beginning the billing calculation process...');
     // ...many lines of business code

     el.reportToSightLane();
 }

This is a great start, but the more complex your code is, the more questions there are about when and how to create logs that make sense and are easy to understand.

For example, the code below shows the same calculateBillingLines() method, but this time, it calls a sub-method (getBillingRates()) during its execution. Assuming that the getBillingRates() method also contains important information, you must decide whether to create one monitor or two for these two methods.

(Hint:  There is no right answer to the previous question.  It is all up to the designer!)

Consider the two snippets below. This type of monitoring will create two distinct and separate SightLane monitors that different people can track and follow separately. This may be appropriate if, for example, the getBillingRates() method is so complex that it requires different knowledge to interpret and respond to situations and errors it encounters.

    public static void calculateBillingLines(){
        EventLogger el = Logging.startLog('Calculate Billing Lines');
        el.log('Beginning the billing calculation process...');

        // ...many lines of business code

        Map<Id,Billing_Rate__c> billingRates = MyApexClassHelper.getBillingRates();

        // ...other business code

        el.reportToSightLane();
    }

    public static Map<Id,Billing_Rate__c> getBillingRates(){
        EventLogger el = Logging.startLog('Get Billing Rates');
        el.log('Retrieving billing rates...');

        Map<Id,Billing_Rate__c> result = [select id, name, amount, from Billing_Rate__c];
        el.log('Found ' + result.size() + 'Billing Rates');

        el.reportToSightLane();
        return result;
    }

In other situations, the getBillingRates() method may be simpler. Even though it is a separate method, it provides more content for the calculateBillingLines monitor.  How can you include logs from this sub-method in the parent monitor's logs? Enter static logging. 

Static Logging

SightLane's Logging class contains methods to get an EventLogger object, but it also contains a collection of static methods with very similar functionalities to those in the EventLogger class.  Instead of creating a new monitoring event, these methods add a log statement to the currently active monitoring event (if one exists).

Logging.log('This is my statement');

Notice the differences in the updated getBillingRates() code below.  There is no "startLog" statement or "reportToSightLane" statement.  The Logging.log method will automatically add log statements to the log of the Parent Monitor in operation at the time (in this case, the calculateBillingLines() monitor).  

    public static Map<Id,Billing_Rate__c> getBillingRates(){
        Logging.log('Retrieving billing rates...');

        Map<Id,Billing_Rate__c> result = [select id, name, amount, from Billing_Rate__c];
        Logging.log('Found ' + result.size() + 'Billing Rates');

        return result;
    }

The result of static logging is that everything that happens within the Apex call stack (methods that call other methods, that call other methods...) can all be connected and added to the same Event Log.  allowing you to design logs that span an entire business process.