Salesforce Integration Design Patterns

There are many scenarios where integrating salesforce with external system becomes crucial for businesses. For example,

ABC ltd uses Salesforce for capture cases. However, Salesforce isn’t the system that processes cases. After the case details are captured in Salesforce, a case must be created in the remote system, which manages the case’s lifecycle.This scenario requires a integration of salesforce with remote system.

Integrating with external system comes with additional concern of security as well as scalability. Hence, Salesforce has following integration design pattern which guides designers or architects who wants to integrate salesforce with external systems.

1. Request And Reply
2. Fire And Forget
3. Batch Data Synchronisation
4. Remote Call-In
5. Data Virtualisation

Architect must consider below point before deciding on the integration pattern,

• Does the required integration is synchronous or asynchronous?
• In case integration is synchronous, does salesforce needs to process response as a part of the same transaction as initial call.
• Size of message small or large?
• Event causing integration. for example, a button click in the Salesforce user interface, or DML-based events
• Is the remote endpoint able to respond to the request with low latency
• Number of user to be executing this transaction during a peak period?

Request and Reply:

This pattern support synchronous transaction where salesforce invokes a process from external remote system and wait for its response and, then depending on the response subsequent actions are performed.

This pattern provide real time integration where user gets response from external system real time.

Request and Reply pattern can be recommended when,

1. Synchronous transaction is needed. Meaning salesforce needs the response of external process being called in same transaction which invoked the process to perform further processing.
2. If integration request needs to be initiated from UI.
3. Preferable for small data volume and real time activities because of small timeout values.
4. If solution is based on Apex SOAP or REST callouts are being, then endpoints must be able to receive callouts via HTTP.

There are multiple solutions by which ‘Request and Reply’ pattern can be implemented.

1. Enhanced External Services invokes REST API
2. Salesforce classic or LWC initiate synchronous apex REST or SOAP API
3. Visualforce page/button initiate synchronous HTTP callout
4. Apex trigger initiates asynchronous apex SOAP or HTTP callout
5. A batch Apex job performs a synchronous Apex SOAP or HTTP callout.

Error handling and Recovery:

When invoked external process encounters error, it send error code or exception. As this pattern most likely be used from UI, it is necessary to handle the errors and show user friendly message to user.

Furthermore, As response is required to perform further processing in same transaction, It is wise to commit the changes only after receiving successful response.

What happens when repeated invocations happens?

Repeated invocation of same message can create issues related to data integrity, like duplicate record creation or duplicate processing of transactions.

As it is not possible to restrict the invocation of the process only once, It becomes viable to handle scenarios where repeated callouts are made.

This can be achieved by using unique identifiers. Apex web service or REST calls must send unique message identifier which then can be used by external remote process to identify the duplicates.

Fire and Forget:

This pattern support asynchronous transaction where salesforce invokes a process from external remote system and does not wait for its acknowledgement or response. External system then can send the acknowledgemen or response.

Most common use case is, Salesforce gathers information regarding orders and send the data to the external order processing system but doesn't wait for response, Instead it completes the transaction. Order processing system can then send the order number to salesforce after completion of order creation.

This pattern is best suited when,

1. Asynchronous transaction is required.
2. Integration request needs to be initiated from UI or as a result of DML event.
3. Data volumes can be smaller or larger depending on the solution.

Solutions:

1. Process-driven Platform events
2. Customisation driven Platform events
3. Workflow-driven Platform messaging
4. Outbound Messaging and callbacks
5. Custom LWC or VF page invoking APEX SOAP or REST asynchronous callouts
6. Apex Triggers invoking APEX REST or SOAP asynchronous callouts
7. Batch Apex jobs which performs APEX REST or SOAP asynchronous callouts

Error Handling and Recovery:

Error handling and recovery mechanism varies depending on the solution chosen. for example,

• Apex Callout:

Error occurred during initial invocation of remote service like request timeout can be handled from salesforce because of asynchronous transaction. However, error encounter while processing the request should be handled by remote system.

Recovery is complex in this scenario. One can implement custom retry mechanism.

• Outbound Message:

Remote system handles errors handling.

Timeout period for outbound message is 24 hours. hence, salesforce retries after timeout period if no positive response received.The timeout period can be extended to 7 days by requesting salesforce support.However, the automatic retries are limited to 24 hours..

The retry interval increases exponentially over time.The retry interval starts with 15-second interval and ends with 60-minute interval.

All failed messages after 24 hours are placed in a queue and administrators must monitor this queue for any messages exceeding the 24-hour delivery period and retry manually, if necessary.

Platform Events:

Remote system handles message queuing, processing ,and error handling this pattern is asynchronous.

Published platform events can’t be rolled back within a transaction, because platform events are not processed within database transactions.

Idempotency:

What happens when repeated invocations happens?

Implication of repeated invocation of remote service depend chosen solution.

Platform events:As platform events are only published to the bus once,Salesforce can not send same platform event repetitively. ESB can request replay of the event using replay ID.

Outbound Message: Due to asynchronous nature of outbound messages, It is crucial to handle duplicate messages in case retries from salesforce. This can be done using unique ID send with each outbound message.

Batch Data Synchronisation:

This pattern deals with import and export of large data volume in salesforce at predefined intervals using batches. This pattern supports asynchronous transaction.

This pattern is best suited when it is required to extract and transport of large amount of data from current CRM system/remote system and load the data in to salesforce or vice versa.

Remote Call-In:

This pattern comes in picture when external data source /Remote Process needs to access salesforce to read, update or insert records in salesforce.

External data source or remote process can use below solutions to perform the actions on salesforce,

1. SOAP API:
2. REST API
3. Apex REST Service:
4. Apex Web service
5. Bulk API 2.0

Data Virtualisation:

This pattern is useful when data stored on external data source needed to be accessed in salesforce in real time without having to copy it in salesforce.

This can be achieved using salesforce Connect.

Salesforce connects maps external tables into external objects in salesforce org. These external objects are similar to custom objects in salesforce, except that they map data from external system. Salesforce keeps the data from external objects up to date by using live connection.

Use Salesforce Connect to access data from external sources, along with your Salesforce data. Pull data from legacy systems such as SAP, Microsoft, and Oracle in real time without making a copy of the data in Salesforce.

Following adapters are supported by salesforce connect,

• OData 2.0 adapter or OData 4.0 adapter
• Cross-org adapter — used to connect two salesforce orgs.
• Custom adapter created via Apex —Apex connector framework can be used to create your own custom adapter if nneeded.

References:

Remote Process Invocation-Request and Reply