"One-Liner" Logging

The classic monitoring model of creating a logger, logging statements against it, and then reporting it back to SightLane gives you powerful control over when and how to create in-process visibility.  However, sometimes, you just need to write a quick logging statement and don't want to take up all that space in your code or disturb its existing design.

public void saveAccountUpdates(Account acc){
SightLane EventLogger el = SightLane.Logging.startLog('Account Update');
validateAccountData(acc);
upsert acc;
el.log('Account Updated!');
el.reportToSightLane('Account Update', 'Account updated successfully!);
}

Fortunately, the Logging class includes a collection of static methods to simplify creating log statements. In the version below, you can accomplish everything simultaneously, which is handy for simple monitoring scenarios (such as logging results at the DML layer or reporting simple errors).

public void saveAccountUpdates(Account acc){
validateAccountData(acc);
upsert acc;
SightLane.Logging.reportToSightLane('Account Update', 'Account updated successfully!');
}

Remember that these statements include the declaration, logging, and reporting all in one, so they will commit to the database each time they are executed.  If the event needs multiple statements, the best practice is to use the classic logging style or collect statements in a String list and log them all at once.

static void reportToSightLane(String monitorName, String logStatement)
static void reportToSightLane(String monitorName, List<String> logStatements)
static void reportToSightLane(String monitorName, String logStatement, SObject record)
static void reportToSightLane(String monitorName, List<String> logStatements, SObject record)

The four methods above represent a sample of the available methods.  You can find the whole list and examples of each method in the SightLane Logging Reference.  

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.