Salesforce integration Pattern:Remote Process Invocation—Fire and Forget
Problem
When an event occurs in Salesforce, how do you initiate a process in a remote system and pass the required information to that process without waiting for a response from the remote system?
Solution
The following table contains solutions to this integration problem.
Solution | Fit | Comments |
---|---|---|
Workflow-driven outbound messaging | Best | No
customization is required in Salesforce to implement outbound messaging.
The recommended solution for this type 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. When using middleware,
this solution becomes a “first-mile” guarantee of delivery.
|
Outbound messaging and callbacks | Best | Callbacks provide a way to mitigate the impacts of out-of-sequence messaging. In addition, they handle these scenarios.
The outbound message provides a unique SessionId that can
be used as the authentication token. You can use the token to
authenticate and authorize a callback using 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
is used to update the original Salesforce record with the unique key of
the record created in the remote system.
|
Custom Visualforce page that initiates an Apex SOAP or HTTP asynchronous callout | Good | This
solution is typically used in user interface-based scenarios, but does
require customization. In addition, the solution must handle guaranteed
delivery of the message in the code.
In this pattern, Salesforce doesn’t wait for the request to complete before handing off control to the user.
After receiving the message, the remote system responds and
indicates receipt of the message, then asynchronously processes the
message. The remote system hands control back to Salesforce before it
begins to process the message; therefore, Salesforce doesn’t have to
wait for processing to complete.
|
A trigger that’s invoked from Salesforce data changes performs an Apex SOAP or HTTP asynchronous callout | Suboptimal | You can use Apex triggers to perform automation based on record data changes.
An Apex proxy class can be executed as the result of a DML
operation by using an Apex trigger. However, all calls made from within
the trigger context must be executed asynchronously.
|
A batchApex job that performs an Apex SOAP or HTTP asynchronous callout | Suboptimal | Calls to a remote system can be performed from a batch job. This solution allows for batch remote process execution and for processing of the response from the remote system in Salesforce. However, there are limits to the number of calls for a given batch context. |
Sketch
The following diagram illustrates a call from Salesforce to
a remote system in which create or update operations on a record
trigger the call.
Thank you for this post!! I have just discovered your blog recently and I really like it! I will definitely try some of your insights.
ReplyDeleteSalesforce Developer 501 Training in Chennai
Salesforce Developer 502 Training in Chennai