Providing Integration and Extensibility

Enterprise businesses have complex needs involving many human, device, and increasingly, machine interactions, often distributed across the globe. Allowing them to work together in an efficient and secure manner is no easy task, and as such, it is no great surprise that utilizing cloud-based software over the internet has become so popular. High-grade security, scalability, and availability is high on checklists when choosing a new application, often followed by API needs and the ability to customize.

By developing on the Lightning Platform, your application already has a good start. http://trust.salesforce.com/ provides a wide selection of industry strength, compliance, and encryption standards that are equally applicable to your applications. With this comes a selection of standard APIs offered in the SOAP and REST forms, as well...

Reviewing your integration and extensibility needs

Before diving into the different ways in which you can provide APIs to those integrating or extending your application, let's review these needs through the eyes of Developer X. This is the name I give to a persona representing a consumer of your APIs and general integration and extensibility requirements. Much like its use in designing a user interface, we can use the persona concept to sense check the design and interpretation of an API.

Defining the Developer X persona

Asking a few people (internal and external to the project) to represent this persona is well worth doing, allow them to provide use cases and feedback on the features and functions of your application...

Standard platform APIs for integration

Chapter 2, Leveraging Platform Features, provided a good overview of the many platform APIs that are available to those integrating with your application from outside of the Lightning Platform, from environments such as Java, .NET, PHP, and Ruby. It also covered best practices to ensure that your application and the developers using these APIs have the best experience.

As stated in that chapter, these APIs are mostly focused on record data manipulation and querying, often known as CRUD. Leveraging the Salesforce APIs means developers wishing to learn how to integrate with your application objects can leverage the standard Salesforce API documentation and websites such as https://developer.salesforce.com/.

Although the Enterprise API provides a strongly typed SOAP API, its larger size can be problematic to load into development environments...

Application integration APIs

This section describes ways in which you can expose your application's business logic functionality that's encapsulated within your Service layer.

In some cases, Developer X is able to achieve such functionality through the standard Salesforce APIs. However, depending on the requirement, it might be easier and safer to call an API that exposes existing business logic within the application. You can decide to do this for the same reason you would create a custom UI rather than expect the end users to solely utilize the standard UI (because using your objects directly requires them to understand the application's object schema in more detail).

Providing Apex application APIs

If...

Exposing platform events

The sample code in this chapter contains a Race News Feed platform event object. As described earlier in this chapter, such objects can be used to define an asynchronous API for your application that applies the pub-sub communication pattern. In this use case, a mobile application (not included in this sample) is used by news reporters employed by the customers of your FormulaForce package. The goal is to ensure that whenever something not-worthy occurs in the application, they get real-time updates on their mobile devices.

The mobile application uses the CometD (https://cometd.org/) protocol in mobile applications' JavaScript to subscribe (listen) to the platform events from the Race News Feed object. Within the RaceService.awardChampionshipPoints method code shown here, the RaceNewsFeed__e object is registered with the Unit Of Work associated...

Exposing Lightning Components

In the previous chapter, we looked at several components that are included in the FormulaForce package. These have all been exposed for use by tools and developers' code in the subscriber org through the global access level.

When developers consume these components inside their own component, there is a facility through the bundle metadata for them to express what package version they want the platform to assume when their code interacts with the packaged component. This allows the definition and behavior versioning of your components. If this information is not present, the currently installed package version is assumed.

System.requestVersion, {!Version}, and cmp.getVersion() are available to determine the version your component needs to honor in Apex or JavaScript.

At the time of writing, this feature is not supported for Lightning...

Extending Process Builder and Flow

The Process Builder and Flow tools allow users to create customized processes and wizard-like user experiences. Both tools offer a large selection of actions they can perform based on criteria defined by the user.

Available actions can be extended by packages installed in the org. This provides another way in which you can expose your functionality to build customized scenarios. This approach does not require the user to write any code.

The following code creates an invocable method, which is a global class and a single method with some specific annotations. These annotations are recognized by the tools to present a dynamic configuration UI to allow the user to pass information to and from the method you annotate:

global with sharing class UpdateStandingsAction { 
     
   global class UpdateStandingsParameters {

 
      @InvocableVariable...

Alignment with platform extensibility features

Here are some other platform features that can help ensure that your application's functionality is open to being extended by Developer X or subscriber org administrators:

• Apex Triggers: Developer X can write their own triggers against your application's managed Custom Objects. These will execute in addition to those packaged. This allows Developer X to implement the defaulting of fields or custom validations, for example. Salesforce does not guarantee that packaged triggers will execute before or after Developer X triggers in the subscriber org. To ensure that all changes are validated regardless of the trigger execution order, perform your validation logic in the after-phase of your packaged triggers. It is recommended that you advise Developer X to be considerate about how much code is written in triggers because the...

Extending application logic with Apex interfaces

An Apex interface can be used to describe a point in your application logic where custom code written by Developer X can be called. For example, in order to provide an alternative means to calculate championship points driven by Developer X, we might expose a global interface describing an application callout that looks like this:

global class ContestantService {
   global interface IAwardChampionshipPoints { 
    void calculate(List<Contestant__c> contestants); 
  } 
} 

By querying Custom Metadata records from the Callouts Custom Metadata type, which has been included in the source code for this chapter, code in the application can determine whether Developer X has provided an implementation of this interface to call instead of the standard calculation code.

Using Custom Metadata is an excellent use case for this sort of requirement...

The MuleSoft platform

The MuleSoft platform from Salesforce allows your customers to connect to a wide variety of APIs, not just those exposed via the Lightning Platform and your application, but ones from other platforms and products available throughout the industry. It contains many connectors so that it is easy for customers to integrate many different solutions together into one set of APIs. It also contains a strong orchestration engine that allows processes to be described with conditional logic and some level of programmatic transformation through its DataWeave scripting language. One of the most powerful features is composing new APIs from several APIs. These APIs can also be consumed from within Apex logic. 

At the time of writing, there is no support for packaging MuleSoft configurations, so this is purely a customer-focused tool. However, you should take...

Summary

In this chapter, we have reviewed enterprise application integration and extensibility requirements through the eyes of a persona known as Developer X. By using this persona, much like your UI designs, you can ensure that your API tracks real use cases and requirements from the representative and, ideally, actual users of it.

When defining your API strategy, keep in mind the benefits of the standard Salesforce APIs, how to evangelize them, and the significant investment Salesforce puts into them in order to provide access to the information stored in your Custom Objects. We have also seen that platform tools such as Lightning App Builder, Lightning Process Builder, and Flow can be extended with embedded functionality from your package that can be accessed without the need for code. Platform events are also worth considering to provide an asynchronous loosely API to allow...