Overriding Service Classes/SObject Wrappers

Types of Overrides

  We support multiple ways to override our Service classes/SObject wrappers. In both cases you are extending the ones that Fonteva provides with custom logic. This custom logic can be in addition to or fully replace our logic. Types of overrides are:

1. Global Override using the Custom Metadata Type records
2. Contextual Override to only override a single instance.

Global Overrides

   This override is done to replace all occurrences of a particular class with a custom version of it. This custom version will be instantiated and used within the platform and also returned to anyone calling the platform directly. This allows developers to impact core functionality for example how we pull event data to show in a Fonteva component. These overrides will also be applied to the calls that happen against the REST API. 

  There are two custom metadata types:

1. Fonteva Service Module
2. Fonteva Service Module Class

Once the details are provided, the platform will auto-instantiate the custom version of the class.

Contextual Overrides

This override is done to replace a single occurrence or all occurrences in an execution context. This custom version will be instantiated and used within the platform and also returned to anyone calling the platform directly. This allows developers to impact core functionality (for example, how we pull event data to show in a Fonteva component.) This override type does not apply to the REST API. 

FDService.ImplementationOverride.overrideContextImplementation('Finance','Catalog',GetStoreItemsResponse.Catalog.class.getName());


List<FDService.Catalog> tempCatalogs = FDService.CatalogService.getInstance().get(new FDService.SearchRequest()
        .filter('OrderApi__Store__c = {0} AND OrderApi__Is_Published__c = true',new List<Object>{storeId})
        .entityId(contactId)
        .orderBy('OrderApi__Display_Order__c ASC NULLS LAST'));
for (FDService.Catalog catalogObj : tempCatalogs) {
    GetStoreItemsResponse.Catalog cat = (GetStoreItemsResponse.Catalog) catalogObj;

}

 The above example will override all instances of the FDService.Catalog wrapper with the custom provided class. You can dynamically cast it to the custom class as you iterate through the list of returned records.

Service Overrides

  The Fonteva Platform allows the ability to override service classes that do basic CRUD operations to more complex actions. You can elect to override individual methods inside of the service classes for example:

global with sharing class ReceiptServiceExt extends FDService.ReceiptService {
	public override List<FDService.Receipt> get(FDService.SearchRequest sr) {
       return new List<FDService.Receipt>();
	}
}

 Once you register this override, each time the platform calls this service your method will be called instead of the core method. You can also call the parent method like the following:

global with sharing class ReceiptServiceExt extends FDService.ReceiptService {
	public override List<FDService.Receipt> get(FDService.SearchRequest sr) {
       List<FDService.Receipt> receipts = super.get(sr);
       //DO ACTION
       return receipts;
	}
}

SObject Wrapper Overrides

As we continue to build out the new platform we will continue to expand the SObject wrappers to include all fields that Fonteva ships. However, we do fully support any custom fields that are created on our objects. If those need to be injected into the platform or pulled into the wrapper itself, then you can create an extension class as follows and apply the overrides outlined above. This will automatically map the core fields from the Fonteva Platform and also the custom fields that are created by your organization:

global with sharing class Catalog extends FDService.Catalog {
    @AuraEnabled
    public Integer size;
    @AuraEnabled
    public Boolean hasItems = false;
}

All attributes from the platform are`@AuraEnabled`so they can be directly used in Lightning Components. We will auto map custom fields as long as they are in the desired format.