Evaluate an Integration Pattern
Learning Objectives
After completing this unit, you’ll be able to:
- Identify a solution associated with the Remote Process Invocation—Request and Reply integration pattern.
- Explain the benefits of the Remote Process Invocation—Request and Reply integration pattern.
The Remote Process Invocation—Request and Reply is a common Salesforce Lightning Platform integration pattern. It's also known as Request and Reply, or Request and Response. In this unit, you learn how to evaluate the pattern and optional solutions for the example scenario.
Example Scenario
Imagine you use Salesforce to manage leads, create opportunities, and manage contacts. Your integration solution requires that Salesforce includes order information, but you use an external system to manage your orders. Your integration goal is to connect your external system to Salesforce to manage your orders.
You review the Request and Reply pattern to determine which solution is ideal to solve your integration problem.
Remote Process Invocation—Request and Reply
Layer: Business Logic
Timing: Synchronous
Direction: Salesforce → System
Volume: Ideal for small transactions (real-time activities)
The Remote Process Invocation—Request and Reply pattern is ideal for designs that send a request from Salesforce to an external system and require a response back.
How Does the Remote Process Invocation—Request and Reply Pattern Work?
An event-initiated process originates from Salesforce and makes a call to an external system. The request is triggered in response by the UI. This includes clicking a button on a page or a Lighting web component (LWC) invoking an Apex class. The external system completes the request and sends a synchronous reply to Salesforce. The reply is then processed by Salesforce, and Salesforce updates the data as needed.
Solution Options
This table identifies solutions you might consider to implement this pattern.
Solution |
Considerations |
|---|---|
|
Enhanced external service embedded in a Lightning Flow, or Lightning web component, or Visualforce and Apex controllers |
This solution is used when the remote process is triggered as part of an event-driven end-to-end process. The example scenario requires the result to be displayed or updated in a Salesforce record. Because the user-initiated action calls an Apex class that performs the remote call needed, this solution is the best option to achieve the integration goal. |
Apex triggers |
This solution is restricted to the Apex governor limits and allocations on the org. It’s not ideal for the example scenario because all calls from the trigger are executed asynchronously. |
Apex batch classes |
This solution allows for batch remote processing from Salesforce; however, it’s held to the limited maximum number of batch calls. For that reason, this solution is not ideal for the example scenario. |
Integration Example
In the following diagram, an LWC invokes synchronous remote processing using Apex calls. An Apex controller creates a connection and sends out a call to the remote web service. The remote system responds to Salesforce, and the Apex class processes the data. Once processed, the results display on the Lightning page.
Here is a step-by-step summary of what the diagram shows.
- The user interacts with an LWC, such as clicking a button that initiates an action.
- The browser performs an HTTP POST that performs an action on the Apex controller.
- This activity then invokes the Apex controller to make a call to the remote web service.
- The size of the message is small and is in real time. The message is returned back to Salesforce synchronously.
- The Apex controller receives and processes the response.
- The system then updates data in Salesforce as required and re-renders the page.
Idempotent Design Considerations
The term “idempotent” in mathematics describes a function that produces the same result when applied to itself. If a user clicks the same button multiple times, Salesforce sends a message to the external system multiple times. Because you can’t control how many times Salesforce sends a message or an impatient user clicks a button, the receiver must be designed for idempotency.
Design an idempotent receiver with these tips.
- Add a unique message ID to the request message. This helps the receiver recognize duplicate requests.
- Check for duplicate records before inserting data into the external system.
Without an idempotent receiver checking for duplicate requests, you process the same transaction multiple times. This leads to performance issues and prevents future requests from processing—which further leads to needless consumption of resources and poor data integrity.
Explore More Integration Patterns
You can find more Salesforce Lightning Platform integration patterns in the Integration Patterns Overview guide. In this guide, you learn more about solution options for the integration use case and additional considerations to incorporate into your integration design.
Resources
