Salesforce API Integration Solutions and Design Patterns
Salesforce API Integration Solutions and Design Patterns
There are several Integration Design patterns offered by Salesforce to help businesses integrate data between Salesforce and other API Interfaces that they use. Thus, ensuring that they will be able to access the data they need on Salesforce and the other system when they need it without having to manually enter the data. By using Salesforce API integration solutions and Design pattern, it will reduce errors and the duplication of data and increase the reliability of the data between the two interfaces.
The API Integration solutions allows developers to connect to the external API no matter the Protocol or Data Format used. Here is a list of several API Integration solutions that Salesforce’s offers:
Rest API
SOAP API
Chatter REST API
User Interface API
Bulk API
Metadata API
Streaming API
Apex REST API
Apex SOAP API
Tooling API
Each of the API Integration solutions can be used in junction with an Integration pattern. When used with an Integration Pattern, the solution will be easily scalable, maintainable, and reliable. It will also reduce the amount of time that it will take to develop a solution.
The following is list of Integration Patterns:
Remote Process Invocation – Request and Reply
Remote Process Invocation – Fire and Forget
Batch Data Synchronization
Remote Call-In
UI Update Based on Data Changes
Data Virtualization
There are three Integration pattern types offered by Salesforce that allow developers to synchronize data between Salesforce and an external API Interface. When there needs to be continuously synchronization of data between two systems without any delays, use the Data Integration Pattern. The second type of Integration patterns is the Process Integration pattern; use this pattern when there are two or more interfaces that are used to complete a process. The last pattern type is Virtual Integration Pattern, which allows for data from an external system to be accessed and changed in Salesforce. The situation is appropriate when Salesforce is interacting with an external Interface in real time and the user will have access to the current version of the data. Each of these pattern types offers different Integration patterns to solve different business problems.
The Integration Pattern Types
Data Integration Patterns
The four Data Integration patterns that Salesforce offers are Remote Process Invocation – Request and Reply, UI Update Based on Data Changes, Batch Data Synchronization, and Remote Call In. Data Integration Patterns offers real time or near real time processing of data. The data is either from Salesforce to the external API or vice versa.
Process Integration Patterns
For Process Integration patterns there are three patterns, Remote Process Invocation – Request and Reply, Remote Process Invocation – Fire and Forget, and Remote Call In. These three patterns are used when you have numerous external systems that need to be integrated when send and receiving data from Salesforce’s API. Request and Reply is good for when Salesforce can wait for the data to be received back from the external system. Fire and Forget should be used when Salesforce cannot wait. In this situation an event can be created on salesforce to listen for the external event to return with a response. Process Integration patterns offer both Synchronous (near real time) and Asynchronous (real time) synchronizing of data.
Virtual Integration Patterns
The last Integration Pattern is the Virtual Integration Patterns which is used when the data needed is in an external system for it to be displayed in Salesforce. In this category of Integration Patterns there is only one pattern that can be used, Data Virtualization. This pattern allows for data to be retrieved in real time. The benefit of this is that it removes data duplicate between Salesforce and the external system. The data will only exist in the external system and Salesforce retrieves that data when it is needed. Virtual Integration Patterns offer only Asynchronous syncing of data.
The Integration Patterns
Remote Process Invocation – Request and Reply
Remote Process Invocation – Request and Reply pattern is a good for allowing data to be sent out to an external system to perform some operation and sent back to Salesforce for it to be updated. This is to ensure that the data has successfully been retrieved and process on the other end but to get any response on which further processing can occur in Salesforce. The Salesforce API will do the first callout while waiting on the external system to complete it before making progress.
There are three recommend approaches that are best to use when using this pattern. External Services offers a Restful no code solution to send over primitive data types to and from the External REST APIs using a lightning flow. When using a lightning component making REST/SOAP calls or a custom Visualforce page with SOAP using APEX Rest or SOAP. This will allow the External Interface to access your APEX class and methods to perform REST/SOAP operations on them. When you want to access an External Interface use Apex HTTP callout classes. Both APEX Rest/SOAP and APEX HTTP callout can be used injunction with either. APEX Rest/SOAP will allow you write out the classes to allow the external system to consume data from salesforce and use APEX HTTP callout to make a SOAP/REST call to the external API. These two solutions involve coding the solution and can handle complex data types that External Services cannot. These three solutions are the best recommended solutions to use when synchronously sending and making callouts.
UI Update based on Data Changes
When you need the user to be informed that data has arrived, use a UI Update Based on Data Change pattern. This will allow the user to receive any updates that occur in another system and have the data updated in salesforce. The only solution offered in this pattern is the Streaming API. How this API works is that a Push Topic is created in Apex to specify which data the client receives, and it is what the client subscribes to. An Emp connector is used to subscribe the external client to the Push Topic. This can be setup to be used within a Visual Force or Lightning page. In this pattern Salesforce’s API waits for the external system publish event in which salesforce uses to notify the user in the Visualforce or Lightning page. The benefit of implementing this pattern is that it eliminates the need to write custom polling mechanism and user feedback loops. There are limitations in that there is no guarantee for the Delivery and Order of notifications. The notifications are not generated from the bulk API.
Data Virtualization
Data Virtualization pattern is used when there an external system that performs operations that are not handled by or contains data that is not in salesforce. This integration patterns allows for users to use the Salesforce platform to access that data without having to learn the external system. It allows for real-time access to the latest version of data from an external system without having to store the data in Salesforce. The best solution to use is Salesforce connect with this pattern. Enables real-time data integration between Salesforce and the external system. It maps external data using an external object in salesforce that displays the data retrieved to the user without storing it in the org.
Remote Process Invocation – Fire and Forget
Remote Process Invocation – Fire and Forget is used when the sent request does not need to wait for a response. With this Integration Pattern, it has several solutions that can be used to solve the problem. There are three Driven Platform Event that can be used since it allows your salesforce org to be either a subscriber or publisher of an event. This approach simplifies the process by offering both a no code and low code approach. There are two no code approaches. One is a Process – Driven Platform Event using a process builder to define a Platform event. This can be done by using the create record action and selecting the Platform event as the record type. Workflow – Driven Platform Event uses a flow to publish the event and has similar steps to publish the event with a process builder. It uses the create record element and select the platform event as the record type. Customized –Driven Platform Event is the low code approach which involves using an Apex Class to publish the event using the EventBus class. Then once the event has been published the external application can subscribe to the event using CometD. Other than using CometD the event can be subscribed from a Process Trigger, the pause Event in a workflow, or an Apex Trigger. The next solution is Outbound Messaging and callbacks which uses triggered workflows to send an outbound message to the external system when an insert or update happens. This allows you to select the object that you want to be sent; define the endpoint and the fields from the object to be sent.
Remote Call-In
When there is a remote system making updates on a Salesforce org a Remote Call-In pattern would be used. This allows for the remote API to connect to Salesforce to make changes to the data that has changed and notify Salesforce of external events. There are three solutions that would be the best to use depending on the situation. Only thing that must be done on the Salesforce side for these three solutions is enabling the API permission on the Org. On the external API the code will have to be created to connect to the Salesforce Org. The first solution is the REST API, it takes in both JSON and XML responses. It only supports synchronous transaction, meaning that the external application will have to wait for a response from the Salesforce Org. The REST API is much simpler to work with, easier to integrate, and more flexible then the SOAP API. The next solution is SOAP API, it is like the REST API but uses only XML and is not as flexible. It requires the creation of WSDL contracts to be imported into the external code. When there are substantial amounts of data that needs to be sent over to a Salesforce Org, the BULK API is used. It uses the principle of the REST API, allowing to have the same capabilities but performing its operations asynchronously. This allows the creation of Bulk jobs from the external API to be able to perform the necessary CRUD on the data in the Salesforce Org.
Batch Data Synchronization
There are Organizations that have data that will needs to be synchronized between two different systems, for them to do this they need ensure that the syncing of this data does not interfere with their daily operations. The best pattern to handle this situation is the Batch Data Synchronization pattern, it allows data to be imported and exported from Salesforce. It allows organizations to create a schedule that would be the best time for them to synchronize their data. When synchronizing data between Salesforce and the external system use Salesforce Change Data Capture. It publishes change events that occur in Salesforce such as creation, update, deletion, and undeletion of data. It’s able to do near real-time synchronizing of data in the external system. Its available for all custom objects and subset of standard objects, but it only allows for five objects to be selected. Buying a license through Salesforce will allow more objects to selected. When synchronizing data from the external system to Salesforce, Replication via third-party ETL tools would be the best way. The tool is used to capture data from the external system to send to Salesforce. The bulk API is then used to process the received data to make the DML commands to store it in Salesforce.
The exploration of the six Integration Patterns used in the three pattern types show that there are variety of options Salesforce offers when integrating data between a Salesforce Org and an external system. These solutions used in these patterns offer a variety of ways to connect two systems through code and/or no code. This gives the developer or admin options on how to connect these systems together, no matter how complex.
