Salesforce Integration Patterns

Many a times there is a need to interact with an external system while implementing Salesforce. Though, there are some practices which are followed for almost every type of integration, but, one must always be aware as to which practice/pattern should be followed so as to ascertain the coming uncertainties that might occur.

Each integration scenario is unique in its own way, but, there are common requirements and issues that developers must resolve in order to have an uninterrupted flow of data. Each pattern describes the design and strategy for a particular scenario rather than a specific implementation.

This blog is for people who need to integrate the Salesforce Lightning Platform with other applications in their organization. One must always be always be familiar with the integration patterns and the options they provide, especially when Lightning is concerned.

Remote Process Invocation – Request and Reply

Suppose, Salesforce invokes a process on an external system to create an Order and waits for process to complete. If it is successful, then the external system synchronously replies with the order status and order number and Salesforce updates the order number and status internally. The order number is used as a foreign key for sub sequentially updating the external system.

In another example, if the integration occurred due to a specific event, such as a button click in the Salesforce user interface, or DML-based events, then we can use SOAP and REST API Callouts from Salesforce.

By using an Apex SOAP callout in a synchronous manner, Salesforce enables you to consume a WSDL and generate a resulting proxy Apex class. This class provides the logic to call the remote service.

By using an Apex HTTP callout in a synchronous manner, Salesforce enables you to invoke HTTP services using standard GET, POST, PUT, and DELETE methods. You can use HTTP classes to integrate with RESTful services.

Calling Mechanism – You can use below stated Salesforce components to call external system to implement this pattern:

  • Visualforce and Apex controllers
  • Apex triggers and Apex batch classes

Error Handling and Recovery

  • Error Handling – When an error occurs (exceptions or error codes are returned to the caller), error handling is managed by the caller.
  • Recovery – Changes aren’t committed to Salesforce until a successful response is received by the caller. If necessary, the caller can retry the operation.

Governor Limits

  • Only 10 callouts can be made in a given execution context
  • A maximum of 60 seconds invocation time for a given callout and 120 seconds of invocation time for all callouts in a given execution context
  • A maximum message size of 3 MB for a given callout request or response

Idempotent Design Considerations

  • It’s important to ensure that the remote procedure being called is idempotent, otherwise, repeatedly calling the same message can have different results and can result in data integrity issues.
  • Tracking duplicates based on unique message identifiers sent by the consumer is the most typical method of building an idempotent receiver.
  • Also, duplicates before inserting must be checked if an operation create records on the external system.

Security Considerations

Any call to a remote system must maintain the confidentiality, integrity, and availability of the request. Below are some security considerations:

  • Two-way SSL can be used to maintain authenticity of both the client and server.
  • Consider using digital signatures using the Apex Crypto class methods to ensure request integrity.
  • Appropriate firewall mechanisms should always be implemented to protect the external system.

Remote Process – Fire and Forget

When using this pattern implementation, Salesforce doesn’t wait for the completion of the process. Suppose, Salesforce calls the remote system to create the order, the remote system can optionally update Salesforce with the new order number and status in a separate transaction.

For handling such type of scenarios, Salesforce has provided us the Outbound Messaging through Workflow. The most important advantage of implementing this approach is that no customization is required from user’s end, but, this approach is only suitable when insert or update event is occurred. It allows sending SOAP messages to remote systems which are sent asynchronously and are independent of the Salesforce user interface. The outbound message is sent to a specific remote endpoint and if the remote service doesn’t respond with a positive acknowledgment, Salesforce retries sending the message, until and unless the delivery is guaranteed.

Calling Mechanism – Though Outbound Messaging through Workflow is the best approach, you can also use below stated Salesforce components to call external system to attain this pattern:

  • Visualforce and Apex controllers
  • Apex triggers and
  • Apex batch classes

Error Handling and Recovery

  • Error handling – The remote system handles error handling as the pattern is asynchronous and the message is effectively handed off to the remote system in a “fire-and-forget” manner.
  • Recovery – The Salesforce initiates a retry operation for up to 24 hours if no positive acknowledgment is received within the timeout period.

Idempotent Design Considerations

The remote system can track duplicate messages based on a unique ID that is sent by outbound messaging and this ID remains the same for all the retries (if, any). To prevent duplicate record creation, the unique record ID can be used which is sent for each record being updated.

Security Considerations

  • Two-way SSL can be used together with the Salesforce outbound messaging certificate though, one-way SSL is enabled by default.
  • Whitelist Salesforce server IP ranges for remote integration servers.
  • Appropriate firewall mechanisms should be implemented to protect the remote system.

Batch Data Synchronization

Data stored in Lightning Platform should be created or refreshed to reflect updates from an external system, and when changes from Lightning Platform should be sent to an external system. Updates in either direction are done in a batch manner.

But, while doing the data migration to and fro, there might be a case that the import/export process interferes with end-user operations during business hours, and involve large amounts of data.

For the above stated scenario, we can leverage a CLI data Loader or third-party ETL (extract, transform, load) tool that allows you to run change data capture against ERP and Salesforce data sets.

Error Handling and Recovery

  • Error handling – If an error occurs during a read operation, standard processing using control tables/error tables should be implemented in the context of an ETL operation. Most of the ETL tools provide error and success files.
  • Recovery– Perform manual reload or restart the ETL process to recover from a failed read operation.

Idempotent Design Considerations

  • ETL tool should keep track of success and failure records and avoid duplicate insertion of records, in case of insert or Upsert batch job failures.
  • Update batch job failures can be restarted as it will not impact the data consistency.

Security Considerations

  • A Lightning Platform license is required to allow authenticated API access to the Salesforce API.
  • Keep password access secure by using standard encryption
  • Use the HTTPS protocol when making calls to the Salesforce APIs.

 

Remote Call-In

Data stored in Lightning Platform is created, retrieved, updated, or deleted by a remote system.

Suppose, an air-conditioner supplies and services company uses Salesforce as a front-end to create and manage accounts and opportunities. Opportunities on existing accounts are updated from the on-premises AC Management System (ACMS), which regularly monitors AC’s on client sites.

Solutions to above stated integration problem are stated below:

SOAP API – Salesforce provides a SOAP API that remote systems can use to Query, Create, Update, Delete data, along with, obtaining metadata about your organization. SOAP web services, such as JAX-WS, are useful for asynchronous processing and invocation. SOAP supports several protocols and technologies, including WSDL, XSDs and WS-Addressing.

REST API – REST exposes resources (entities/objects) as URIs and uses HTTP verbs to define CRUD operations on these resources. REST API is lightweight and provides a simple method for interacting with Salesforce. Its advantages include ease of integration and development which makes it suitable for mobile applications and Web 2.0 projects.

Error Handling and Recovery

An error handling and recovery strategy must be considered as part of the overall solution.

  • Error handling— Middleware can be used to provide the logic for error handling and recovery, but the remote system will handle any subsequent errors, such as timeouts and the management of retries.
  • Recovery— A custom retry mechanism needs to be created if quality of service requirements dictate it. In this case, it’s important to ensure idempotent design characteristics.

Idempotent Design Considerations

  • In the case of errors or timeouts, the remote system must manage multiple (duplicate) calls, to avoid duplicate inserts and redundant.
  • While it’s possible to manage some of these situations within Salesforce, it is recommended that the remote system (or middleware) manages error handling and idempotent design.

Security Considerations

  • Salesforce supports Secure Sockets Layer v3 (SSL) and the Transport Layer Security (TLS) protocols. Ciphers must have a key length of at least 128 bits.
  • Establish an OAuth trust for authorization.
  • Call the REST API cache and reuse the session ID to maximize performance.

 

UI Update Based on Data Changes

When changes to Salesforce data is made, the Salesforce user interface must be automatically updated.

Suppose, the customer service managers of a telecommunications company want to be notified automatically when a case is successfully closed by one of their customer service reps uses who uses Salesforce to manage customer cases.

Above stated integration pattern can be handled by Salesforce Streaming API which uses “PushTopics” that represents a query that is the basis for notifying listeners of changes to records in an org. The advantage of using this pattern is it eliminates the need for a user-initiated feedback loop.

Error Handling and Recovery

  • Error Handling – It will require the remote system to handle errors generated during streaming API integration.
  • Recovery- A custom retry mechanism needs to be created.

Idempotent Design Considerations

  • Consistent and reliable delivery of notifications is not guaranteed using Streaming API’s
  • Streaming servers don’t maintain any client state and don’t keep track of what’s delivered.
  • Some events may be dropped if the system is being heavily used.

Security Considerations

  • Standard Salesforce organization-level security should be followed.
  • It’s recommended to use the HTTPS protocol for connecting to Streaming API’s.

 

Pattern Selection Matrix

The selection matrix table lists the patterns, along with key aspects, to determine the pattern that best fits business integration requirements.

NOTE:

All applications must be created and integrated with relevant security mechanisms.

While integrating cloud-to-cloud services typically focuses on Web services and associated authorization, connecting on-premises and cloud services often introduces increased complexity.

2 thoughts on “Salesforce Integration Patterns

Leave a Reply

Your email address will not be published. Required fields are marked *