Integration Patterns and Best Practices for Salesforce - Part 1

Whenever you have to integrate Salesforce with remote system, then you need to consider different integration scenarios and API’s availability. Integration patterns helps you identify the correct pattern or API to build robust framework for integration.

If you are planning to appear for "SALESFORCE CERTIFIED INTEGRATION ARCHITECTURE DESIGNER" exam then below information will be helpful.

In complex integration scenarios, mix of integration patterns is used by weighing pros and cons accordingly.

Today I am going to cover below patterns. For remaining patterns, refer below blog:
Integration Patterns and Best Practices for Salesforce - Part 2

Remote Process Invocation—Request and Reply

This pattern is used when you need to call remote system and wait for response. After getting response you want to update something in SFDC in synchronous manner. This pattern is used when you want to complete request and process the response in same transaction.

Different Scenarios:

• Onclick of button in UI :- In VF page, onclick of button you want to call remote system to get order information and display it to user on VF page without storing it in salesforce. You can implement this with Apex SOAP or REST callouts.

• Apex triggers :-You can use Apex triggers to perform callouts based on record data changes. All calls made from within the trigger context must execute asynchronously from the initiating event. Therefore, apex triggers isn’t recommended for this pattern.

• Batch Class :- You can make calls to a remote system from a batch job. This solution allows batch remote process execution and processing of the response from the remote system in Salesforce. However, a given batch has limits to the number of calls. So, batch class is also not recommended for this pattern.

Error Handling and Recovery

It’s important to include an error handling and recovery strategy as part of the overall solution.

• Error handling—When an error occurs (exceptions or error codes are returned to the caller), the caller manages error handling. For example, an error message displayed on the end-user’s page or logged to a table requiring further action.
• Recovery—Changes aren’t committed to Salesforce until the caller receives a successful response. For example, the order status isn’t updated in the database until a response that indicates success is received. If necessary, the caller can retry the operation.

Security Considerations

Any call to a remote system must maintain the confidentiality, integrity, and availability of the request. The following security considerations are specific to using Apex SOAP and HTTP calls in this pattern.

• One-way SSL is enabled by default (for apex callout and outbound messages), but two-way SSL is supported with both self-signed and CA-signed certificates to maintain authenticity of both the client and server.
• Salesforce does not currently support WS-Security.
• Where necessary, consider using one-way hashes or digital signatures using the Apex Crypto class methods to ensure request integrity.
• The remote system must be protected by implementing the appropriate firewall mechanisms.

Timeliness

Timeliness is of significant importance in this pattern. Usually:

• The request is typically invoked from the user interface, so the process must not keep the user waiting.
• Salesforce has a configurable timeout of up to 60 seconds for calls from Apex.
• Completion of the remote process is executed in a timely manner to conclude within the Salesforce timeout limit and within user expectations.

Data Volumes

This pattern is used primarily for small volume, real-time activities, due to the small timeout values and maximum size of the request or response for the Apex call solution. Do not use this pattern in batch processing activities in which the data payload is contained in the message.

Remote Process Invocation—Fire and Forget

This pattern is utilized when you want to send some information to remote system and don’t want wait for response. Consider the scenario in which order is created in salesforce and then order information is send to order fulfillment system (outside salesforce) which will process the order.
Best example for this pattern utilization is Outbound messages.

Different Scenarios:

• Outbound messages and call back

No customization is required in Salesforce to implement outbound messaging. The recommended solution for this type Workflow-driven outbound messaging Good of integration is when the remote process is invoked from an insert or update event. Salesforce provides a workflow-driven outbound messaging capability that allows sending SOAP messages to remote systems triggered by an insert or update operation in Salesforce. These messages are sent asynchronously and are independent of the Salesforce user interface. The outbound message is sent to a specific remote endpoint. The remote service must be able to participate in a contract-first integration where Salesforce provides the contract. On receipt of the message, if the remote service doesn’t respond with a positive acknowledgment, Salesforce retries sending the message, providing a form of guaranteed delivery.

A single outbound message can send data only for a single object. A callback can be used to retrieve data from other related records, such as related lists associated with the parent object. The outbound message provides a unique SessionId that you can use as an authentication token to authenticate and authorize a callback with either the SOAP API or the REST API. The system performing the callback isn’t required to separately authenticate to Salesforce. The standard methods of either API can then be used to perform the desired business functions. A typical use of this variant is the scenario in which Salesforce sends an outbound message to a remote system to create a record. The callback updates the original Salesforce record with the unique key of the record created in the remote system.

This is best use case for this pattern as information will be send from salesforce using outbound message without any customization. If other system is unavailable then, outbound has in-built retry mechanism for 24 hours.

Also we can pass session id of user so that remote system can perform callback to SFDC to update records providing confirmation that request have been successfully received by remote system.

Given the static, declarative nature of the outbound message, no complex integration such as aggregation, orchestration, or transformation, can be performed in Salesforce. The remotesystem or middleware must handle these types of operations .

• VF and custom controllers

You can utilize VF page and controllers to send information to remote system but it involves customization to grantee delivery of messages as remote system can be have downtime when request is send.

• Apex triggers/Batch Class

You can use Apex triggers to perform callouts based on record data changes. All calls made from within the trigger context must execute asynchronously from the initiating event. Batch and triggers also have API call limits

Error Handling and Recovery

An error handling and recovery strategy must be considered as part of the overall solution. The best method depends on the solution you choose.

• Apex Callout – We need to maintain logic for retry and error handling if we didn’t get acknowledgement from remote or gets timeout error. Recovery mechanism is complex in this scenario
• Outbound messages – Outbound has inbuilt retry mechanism.

Security Considerations

A call to a remote system must maintain the confidentiality, integrity, and availability of the request.For Outbound message, Whitelist Salesforce server IP ranges for remote integration servers as all Outbound messages are delivered from Salesforce IP addresses.

Timeliness

Timeliness is less of a factor with the fire-and-forget pattern. Control is handed back to the client either immediately or after positive acknowledgment of a successful hand-off in the remote system. With Salesforce outbound messaging, the acknowledgment must occur within 24 hours; otherwise, the message expires.

Data Volumes

Data volume considerations depend on which solution you choose. There is no limit on number of outbound messages sent but limits are there for apex callouts.

Note:- I have summarized the information provided in Integration Patterns and Practices documentation provided by salesforce in this blog.

Hope this will help!!!