Chapter 10. 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 Force.com platform, your application already has a good start. The http://trust.salesforce.com/ site 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 as the ability to create your own application APIs. In my view, there is not a more integration-ready...

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, allowing them to provide use cases and feedback to the features and functions of your application's API strategy, as it is all too easy to design an API you think makes sense, but others with less knowledge of the application do not easily understand. A good way to develop a developer community around your API is to publish designs for feedback. Keep in mind the following...

Force.com platform APIs for integration

Chapter 2, Leveraging Platform Features, provided a good overview of the many platform APIs available to those integrating with your application from outside of the Force.com platform, from environments such as Java, .NET, PHP, and Ruby. It also provided the best practices to ensure that your application and 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/.

Tip

Although the Enterprise API provides a strongly typed SOAP API for Java or .NET developers, its larger size can be problematic to load into development environments (as it includes all Custom Objects and fields present in the org). As such, more general...

Application integration APIs

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

Note

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 an existing business logic within the application. You can decide to do this for the same reasoning you would create a custom UI rather than expect the end users to utilize solely the standard UI (as using your objects directly requires them to understand the application's object schema in more detail).

Providing Apex application APIs

If your Service layer is developed and tested as robustly as possible following the guidelines discussed in the earlier chapter, it is worth considering exposing it to Developer X by simply updating the class, methods, members, properties, and any custom Apex types such as global. This part of the...

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 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 for definition and behavior versioning of your components. If this information is not present, the currently installed package version is assumed.

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

Extending Process Builder and Visualflow

The Process Builder or Visualflow 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 for building 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(
         Label='Season Id'
         Description='Season to update the standings for'
         Required=True...

Alignment with Force.com extensibility features

Here are some platform features that can help ensure your application 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 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.

• Field Sets: As described in earlier chapters, be sure to leverage this feature as often as possible on your Visualforce pages to ensure that regions and tables can be extended with subscriber added fields. These can also be used with JavaScript frameworks if...

Extending the 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, since you can declare the callouts your package supports by packaging records. Then, by making certain fields...

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 representative and ideally actual users of it.

When defining your API strategy, keep in mind the benefits of the standard Salesforce APIs and how to evangelize those 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 Lighting App Builder, Lightning Process Builder, and Visualflow can be extended with embedded functionality from your package that can be accessed without the need for code.

When needed, leverage your Service layer to create application APIs either on-and/or off-platform using Apex and REST as delivery mechanisms. Keep in mind that REST requires additional design considerations...