Differences Between the Legacy and Enhanced Apex Interfaces

Both interfaces define a single method: evaluate(event). This method functions the same way in both interfaces by evaluating an event to determine whether to trigger the transaction security policy. For both implementations, you code the evaluate() method to return true if the policy is triggered, and false if not. That’s about it for the similarities, now let’s look at the differences.

The data type of the event parameter of EventCondition.evaluate(event) is an sObject, which is the standard Salesforce API object that developers know. Using an sObject gives you more flexibility when you code the Apex class. To use the sObject, first cast it to one of the event objects that support transaction security policies, such as ApiEvent or ReportEvent. Be careful, though: If you cast the sObject to the incorrect event object, the policy fails to evaluate. For example, if your policy is based on ApiEvent, but you cast the sObject to a ReportEvent, the policy fails to execute at run time.

With enhanced policies, you use the event object’s fields to add conditions for evaluating the event. Because event objects are publicly documented, it’s easy to find the field that your condition requires by scanning the API documentation. For example, ApiEvent monitors a user’s API calls. Its field QueriedEntities contains the specific objects that the user queried, such as Account, Lead, or even a custom object. Using this field makes it easy and natural to write the Apex code to determine whether, for example, a user queried the Account object.

1apiEvent.QueriedEntities.contains('Account'))

Did you notice that the previous code snippet uses contains? If the API event queries multiple objects, the QueriedEntities field contains a comma-separated list of the object names, so using equals could miss some events. This behavior applies to any Real-Time Event Monitoring event object that has the QueriedEntities field.

The previous example shows another benefit of the TxnSecurity.EventCondition interface: You can track user activity on any Salesforce object, not just the five objects supported in the legacy framework (Lead, Contact, Opportunity, Account, and Contact). But this feature has an important consequence. Enhanced policies execute more often than legacy ones. This behavior results from Salesforce evaluating all enhanced policies on all report operations and API queries.

Let’s briefly go over how the legacy interface works to highlight the benefits of the enhanced interface. In the legacy framework , the data type of the event parameter of PolicyCondition.evaluate(event) is TxnSecurity.Event, a specialized class that contains information about the event using properties. All the property values are Strings, even if the value is numerical or Boolean. Much of the event information is contained in the data property, which is a Map<String,String> type populated with name-value pairs at run time. The run-time contents of this Map depends on the type of event that is being evaluated. As a result, the content isn’t standard, and you don’t know its structure when you code the class. For all these reasons, the Apex code to get the event data tends to be messy and convoluted.

The TxnSecurity.EventCondition interface offers a few more benefits.

• Because the evaluate method takes a generic sObject parameter that you then cast to an event object, you can program a single Apex class to handle multiple events.
• It’s easy to make an asynchronous Apex call in the class that implements a legacy policy by also implementing the TxnSecurity.AsyncCondition interface.
• You can use auto-complete in the Developer Console when writing an implementation of EventCondition. With PolicyCondition, because most of the useful data is in the data Map<> property and populated at run time, auto-complete doesn’t work.

  

• The Real-Time Event Monitoring event objects data model is consistent. As a result, you can write more generic Apex that applies to multiple event types. For example, let’s say Salesforce adds an event type, and you want to include it in your existing security policy. In the enhanced framework, you likely need to add only a few extra lines to your Apex code. In the legacy framework, you have to write a new Apex class.