Common Salesforce Integration Patterns for Integrations is part of the is part of the blog post series: Integrating Salesforce With Other Apps – A Series!
Understanding what Salesforce Integration Pattern to use is vital to a successful Salesforce implementation. Choosing the wrong pattern can result in a really weak architecture that fails regularly, or costs a lot.
When I first started working with the Salesforce / Force.com platform I thought the easiest and best integration was making a callout to Salesforce or having Salesforce make a callout to the remote system or that I could use an extract transform load (ETL) tool.
Five Types of Salesforce Integration Patterns
At a very high level, there are five different types of integration patterns that can be done in Salesforce.
- Fire and Forget
- Request & Reply
- Batch Data Synchronization
- Remote Call In
- Data Virtualization
The pattern you choose really depends on the context you are operating in and the system that you are connecting to Salesforce. In a lot of cases, choosing the wrong pattern can have adverse impacts against limits or scaling.
Changing from one pattern to another can be really challenging to do.
Fire & Forget
Salesforce defines this as “Salesforce invokes a process in a remote system but doesn’t wait for the completion of the process. Instead the remote process receives and acknowledges the request and then hands off control back to Salesforce”.
When we think of “Fire and Forget” patterns, we can think of tools like any of the following:
- Process-driven platform events
- Customization-driven platform events
- Workflow-driven outbound messaging
- Outbound messaging and callbacks
- Batch Apex job that performs an Apex SOAP or HTTP asynchronous callout
- Trigger that’s invoked from Salesforce data changes that perform a SOAP or HTTP asynchronous callout
- Custom Lightning component or Visualforce page that initiates an Apex SOAP or HTTP Asynchronous callout
In the fire and forget pattern, you might consider using technologies like an enterprise service bus. My blog post, What is An Enterprise Service Bus provides more details on what they are and how to use them.
To encourage scalability when we use Process-driven platform events, we should ensure we are following standard enterprise integration patterns. Gregor Hohpe has documented an incredible list of Enterprise Integration Patterns.
Platform events and outbound messaging can be ideal for a lot of reasons, the main reasons being:
- No need to write Apex code
- No need to write test classes
- Outbound messaging keeps trying.
Request & Reply
Salesforce defines this as “Salesforce invokes a process on a remote system, waits for completion of that process, and then tracks state based on the response from the remote system.”
- REST API Calls
- Salesforce Lightning – lightning components or pages initiating a SOAP or REST callout in a synchronous manner.
- A custom Visualforce page or button that initiates an Apex HTTP callout in a synchronous manner.
- A trigger invoked from Salesforce data changes that performs a SOAP or HTTP callout in a synchronous manner
- A batch Apex job that performs SOAP or HTTP callouts in a synchronous manner.
Triggers and Batch Apex Invoking External services should be done as a last resort because they can really slow down the user interface and hit governor limits pretty quickly. Triggers must be asynchronous and generally use a future method which really isn’t a good practice.
Salesforce has call out limits for every single transaction, these call out limits are the total number of calls and the time of call outs.
Batch Data Synchronization
Salesforce defines this as “Data stored in Lightning Platform is created or refreshed to reflect updates from an external system, and when changes from Lightning Platform are sent to an external system. Updates in either direction are done in a batch manner.”
An example situation where this could make sense is a billing run, a lot of companies bill on a weekly or monthly basis and would only import the data into Salesforce on a weekly basis.
Remote Call In
Salesforce defines this as “Data stored in Lightning Platform is created, retrieved, updated, or deleted by a remote system.”
In these situations, you are most likely going to build something to directly call the Salesforce APIs. See my blog post Understanding the Different Salesforce APIs for details about the specific APIs.
In general, you probably would want use the SOAP API, REST API or Bulk API.
Data Virtualization
Salesforce defines this as “Salesforce accesses external data in real-time. This removes the need to persist data in Salesforce and then reconcile the data between Salesforce and the external system.”
