7 - Building an Extensibility Plugin

Each extensibility plug-in is implemented in an Apex class that implements the FCRM.FCR_ExtensibilityAPI.IExtensibilityPlugin interface.

Define the Plugin Apex Class

Start by creating a new class. In this example, we will call the class YourExtensibilityPlugin. Use the following template:

global class YourExtensibilityPlugin Implements FCRM.FCR_ExtensibilityAPI.IExtensibilityPlugin
 {
    global void ExtensibilityEvent(String eventname, FCRM.FCR_ExtensibilityAPI.IExtensibilityEventArgs args)
    {
        // Perform your hook operation based on the event name (eventname) // and arguments (args)
    }
    global String GetUniqueName()
    {
        return('yourcompanyandpluginname');
    }
    global SET<String> RequestedAPIs()
    {
        return new Set<String>();
    }
    global Map<String,Set<String>> RequestedFields()
    {
        return null;
    }
}

Refer to the section The FCR_ExtensibilityAPI Class Interfaces and Methods for details on implementing each of the interface methods in your plugin.

Installing or Uninstalling the plugin class

You can install or remove your plugin class through the advanced configuration page for the Full Circle CRM Response Management system, or by calling one of the following functions:

String FCRM.FCR_ExtensibilityAPI.InstallPluginClass(String classname)

classname = The fully qualified name of the class (namespace.classname)

This function installs your class into the extensibility system so that it will received requested events.

Returns an error message if an error occurs. NULL on success.

void FCRM.FCR_ExtensibilityAPI.UninstallPluginClass(String classname)

classname = The fully qualified name of the class (namespace.classname)

This function removes your class from the extensibility system so that it will no longer receive events.

Requesting Additional Fields to Query

In some cases, an extensibility event will provide your plugin with access to an object before it is saved by the system. This allows you to make field modifications to the object without a separate DML call, and without the risk of introducing side effects due to interactions with the Response Management application. In some cases, such as during triggers, you automatically have access to all of the object's fields. However, in many cases when working with related objects, you would only have access to those fields that were queried by the application.

To address this situation, your plugin can add fields to the list that are queried by the application. This is done by returning a Map<String,Set<String>> object from the RequiredFields call on the IExtensibilityPlugin interface implemented by your plugin.

Response Evaluation Control The key to this map is the object type, and can have the value: CampaignMember, Lead, Contact or Opportunity". These are case sensitive. The value is a set of fields to query. These can be standard or custom fields, or even package fields belonging to other packages. Do not include fields that are part of the Response Management application. Be sure to include the namespace when including fields from other packages.

• You cannot query fields on related objects using this mechanism. For example: You cannot specify Account.Name on a contact object.
• Avoid querying large numbers of fields – adding fields increases the use of heap space and the number of script statements run.
• Do not include object types in the map for which you are not requesting fields.
• On orgs supporting person accounts, the Response Management application only provides access to fields on the underlying Contact object.
• Refer to the notes for individual extensibility events in the extensibility events reference for more information