Using the SightLane Wrapper Package

A common concern for organizations that use AppExchagne products is package dependency.  If a subscriber adds components from a managed package directly into their Flows and Apex, then their code becomes dependent on the existence of that package in the org.  This makes removing the product much more difficult and could potentially place the subscriber in a position in which they are beholden to the package provider.

Pro Tip: Any organization can convert to the Free edition of SightLane at any time.  Although the free version doesn't have all the bells and whistles of the Plus and Premium versions, it will prevent errors from occurring during a license change or package removal.  Simply request the free version by writing to [e-mail].

The SightLane Wrapper Package

To help organizations eliminate this risk, we created the "SightLane Wrapper" unmanaged package. The SightLane Wrapper package is primarily composed of seven Apex classes.  It is free code that we give away to customers (reach out to [e-mail]) and is easily installed in any org.  The customer can then modify or remove these classes at any time.

• SightLane.cls
• SightLaneFlowDataLog.cls
• SightLaneFlowFail.cls
• SightLaneFlowFlowInitialize.cls
• SightLaneFlowReport.cls
• SightLaneFlowUpdateCurrent.cls
• SightLaneTest.cls

SightLane.cls is the core component of the wrapper package and contains everything needed to develop "wrapped" monitoring for Flows and Apex.  The additional classes contain the Flow component definitions that are used from inside Flow Builder (for you techies, this is where the InvocableMethod definitions live.  Changes can be made to these classes at any time (to enhance wrapper behavior) at the discretion of the subscribing customer.

Using the Wrapper for Apex Code

SightLane.cls defines a generic "Logger" class, which contains a SightLane EventLogger inside (as shown below).  That means whenever you create a generic Logger, you are creating a SightLane EventLogger.  However, because the generic Logger class is not a part of the managed package, your code that references it will create no direct dependencies on the managed package.  Each Apex logging method in the Logger class directly wraps a SightLane method.  In other words, a call to the wrapper class IS a call to SightLane.

public class Logger{
  private sightlane.EventLogger el;
  public void log(String logString){el.log(logString);}
  public void reportToSightLane(){el.reportToSightLane();}
  public void reportFailureToSightLane(Exception e){el.reportFailureToSightLane(e);}
  public void setPrimaryRecordId(Id primaryRecordId){el.setPrimaryRecordId(primaryRecordId);}
  // Other methods omitted in this example
}

From your org code, simply create a Logger and call its logging method(s) accordingly.  As in the example below, you can create amazing SightLane visibility without making your business logic dependent on the SightLane managed package.  Try it and see for yourself!

public class MyBusinessClass{
   public void method doSomething(){
       SightLane.Logger myLogger = SightLane.getLogger('My first monitor');
       Decimal totalAmount = MyOtherClass.getTotalAmountForThisCustomer();
       myLogger.log('The total amount is ' + totalAmount);
       myLogger.reportToSightLane();
    }
}

SightLane Flow Wrappers

Besides SightLane.cls and a Test class, the other five classes in the package are Flow component Wrappers.  These classes are used in Flow Builder to drop Flow components into your business Flows.  Just like the Logger class from the last section, these classes refer to the SightLane managed package, but they are not in the SightLane managed package.

In the picture above, the Create Contact Flow contains a SightLane Wrapper component.  This component automatically calls the appropriate SightLane methods internally but does not make the subscriber Flow dependent on SightLane.

For people who build and support Flows, using the wrapper component is no different than using the standard SightLane Flow component.  All of the inputs to the wrapper are identical.  Just remember that the wrapper and standard SightLane components will both be available to you.  Be sure to select the wrapper version of the component when you are adding actions to your Flow.

Removing SightLane when Using the Wrapper

Now, if a subscriber needs to remove the SightLane product, they only need to update a single Apex wrapper class in their org to "turn off" all Flow and Apex usage simultaneously.  Simply comment out the direct SightLane references in SightLane.cls and redeploy that one class.  That's it!

public class Logger{
   // sightlane.EventLogger el;  (commented out)

   public void log(String logString){
     // el.log(logString); (commented out)
   }
}

Remaining wrapper references can be "cleaned up" through normal maintenance over time or replaced with an alternative solution.  That is SO much easier!

Conclusion

We certainly hope you never have to remove the product and that SightLane continues to provide daily value to your team, organization, and customers.  However, if an uninstall becomes necessary, rest assured that the process to "unwind" SightLane from your business code and Flows is a simple and straightforward activity that can be done in less than 30 minutes.  With that in mind, build visibility anywhere you need it without worrying about what the future may bring!