Apex Monitoring: Complex Architecture Practices

Apex code can be written in a limitless different ways and with different complexities, ranging from a simple Trigger snippet to a complex series of code layers that interact with one another in unique ways.  In our Basic Logging Practices article, we described the three-step process involved in running a basic monitor, as shown below.

    public static void calculateBillingLines(){
        jobcenter.JCLogger jcl = jobcenter.JCLogger.getJCLogger('Calculate Billing Lines');

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

        jcl.reportToJobCenter();
   }

This is a good start but more complex code interactions require more sophisiticated monitoring designs and implementations.  This is not really a constraint of Job Center, so much as it is a choice that monitor designers make about how they want information grouped and reported back to them. 

The code snippet below shows the same calculateBillingLines() method, but in this case, the method makes a call to a sub-method (getBillingRates()) during its execution.  A code snippet for getBillingRates() is also shown below.  Assuming that the getBillingRates() method also contains important information, the most notable question in this situation is whether we should create one monitor or two.

(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 Job Center monitors that can be tracked and followed separately by different people.  This may be appropriate, if for example the getBillingRates() method is so complex by itself that it takes a different knowledge to interpret and respond to situations and errors it encounters.

    public static void calculateBillingLines(){
        jobcenter.JCLogger jcl = jobcenter.JCLogger.getJCLogger('Calculate Billing Lines');
        jcl.log('Beginning the billing calculation process...');

        // ...many lines of business code

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

        // ...other business code

        jcl.reportToJobCenter();
    }

    public static Map<Id,Billing_Rate__c> getBillingRates(){
        jobcenter.JCLogger jcl = jobcenter.JCLogger.getJCLogger('Get Billing Rates');
        jcl.log('Retrieving billing rates...');

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

        jcl.reportToJobCenter();
        return result;
    }

In other situations, the getBillingRates() method may be simpler and even though it is a separate method, it is really just more content for the calculateBillingLines monitor.  How can we include logs from this sub-method into the parent monitor's logs?  Enter static logging. 

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

The Logging Methods Reference article discusses all of the static logging methods that are currently available.  Use of these methods is totally at the designer's discretion and help to create montiors and logs that are most beneficial to the organization.

Notice the differences in the updated getBillingRates() code below.  The JCLogger.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(){
        jobcenter.JCLogger.log('Retrieving billing rates...');

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

        return result;
    }

With the capabilities of static logging, we do not have to initialize a separate monitor, nor do we have to report anything to Job Center.  Whatever we log will automatically be added to and reported with the in-scope (already operating) monitor.  This technique keeps us from creating a monitor for every method, which would be extremely time consuming and would create so many different monitors that we would never be able to see the complete story, all in one place (one log).