Trigger Framework

The purpose of this trigger framework is to follow the same implementation across all triggers that may be implemented in University of Sydney’s Salesforce instance.

Base Components

The base components of the trigger framework includes:

• USYD_TriggerHandlerBase - contains the core methods of controlling the trigger.

• USYD_Trigger_Setting__mdt custom metadata type and its fields, namely:

  • After_Delete__c - checkbox to control whether the after delete event will be executed.

  • After_Insert__c - checkbox to control whether the after insert event will be executed.

  • After_Undelete__c - checkbox to control whether the after insert event will be executed.

  • After_Update__c - checkbox to control whether the after insert event will be executed.

  • Before_Delete__c - checkbox to control whether the after insert event will be executed.

  • Before_Insert__c - checkbox to control whether the after insert event will be executed.

  • Before_Update__c - checkbox to control whether the after insert event will be executed.

• USYD_System_Config__c.Trigger_Handler_Logging__c field - checkbox field whether to control whether to log trigger handler invocation. SM_ApplicationLog class is used for logging.

How to Implement

To use the framework, create an apex trigger as you would normally do. Kindly note, that the developer still needs to define the event that needs to be processed in the trigger itself. This includes the before and after events of specific trigger operation (insert, update, delete) that the programmer intend to catch as per business requirement.

1. Create the handler class by extending the USYD_TriggerHandlerBase class.

2. Create include a constructor method which carries a String parameter to pass/contain the trigger name (which can be automatically determined from the trigger body).

3. Override the applicable events (methods) that need to be implemented/executed (i.e. beforeInsert, beforeUpdate, etc.).

4. Write the business logic. It is recommended to have the business logic written in a separate method and invoke it from the overridden event/method, rather than in the event itself. This promotes separation of event invocation from business logic. The developer may also opt to have business logic written in a separate class and just invoke it from the applicable events.
   Sample Trigger Handler Class:

   //AccountTriggerHandler.cls public class AccountTriggerHandler extends USYD_TriggerHandlerBase{ //constructor as explained in step #2 public TriggerTestTriggerHandler(String triggerName) { super(triggerName); } //overridden event as described in step #3 public override void beforeInsert(List<sObject> newRecords){ for (Account record : (Account[])newRecords) { //invoke before insert business logic as described in step #4 } } //overridden event as described in step #3 public override void beforeUpdate(List<sObject> oldRecords, List<sObject> newRecords, Map<ID, sObject> oldRecordMap, Map<ID, sObject> newRecordMap){ for (Account record : (Account[])newRecords) { //invoke before update business logic as described in step #4 } } }

5. Create the Apex trigger.

6. In the trigger code, determine the name of the current trigger by having the this code just before invoking the trigger handler class:
   String triggerName = String.valueOf(this).split(':')[0];

7. Below the line that determines the trigger name, define and instantiate an instance of the trigger that you have written.

8. Execute the logic by invoking the trigger handler instance execute() method.
   Sample Trigger:

   //AccountTrigger.apxt trigger AccountTrigger on Account(before insert, before update) { String triggerName = String.valueOf(this).split(':')[0]; //step #6 AccountTriggerHandler handler = new AccountTriggerHandler(triggerName); //step #7 handler.execute(); //step #8 }

9. Create a new USYD_Trigger_Setting__mdt custom metadata record with Label/USYD Trigger Setting Name as the name of the Apex trigger.

10. Tick (mark as checked) the trigger events that need to be executed/enabled.
    
    

    Open