Salesforce Integration Design Pattern

Remote Process Invocation—Request and Reply

Imagine we 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

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:-

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. So this option is best for Fire and Forget
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.

Remote Process Invocation—Fire and Forget

You use Salesforce to track leads, manage your pipeline, create opportunities, and capture order details that convert leads to customers. However, Salesforce isn’t the system that holds or processes orders. After the order details are captured in Salesforce, an order must be created in the remote system, which manages the order through to its conclusion.

When you implement this pattern, Salesforce calls the remote system to create the order, but doesn’t wait for the call’s successful completion. The remote system can optionally update Salesforce with the new order number and status in a separate transaction.

Solution Approach:-

BEST==>>Process-driven platform events

No customization is required in Salesforce to implement platform events. The recommended solution is when the remote process is invoked from an insert or update event.

Platform events are event messages (or notifications) that your apps send and receive to take further action. Platform events simplify the process of communicating changes and responding to them without writing complex logic. One or more subscribers can listen to the same event and carry out actions.

For example, a software system can send events containing information about printer ink cartridges. Subscribers can subscribe to the events to monitor printer ink levels and place orders to replace cartridges with low ink levels.

External apps can listen to event messages by subscribing to a channel through CometD. Platform apps, such as Visualforce pages and Lightning components, can subscribe to event messages with CometD as well.

GOOD==>> Customization-driven platform events

Similar to process-driven platform events, but the events are created by Apex triggers or classes. You can publish and consume platform events by using Apex or an API.

Platform events integrate with the Salesforce platform through Apex triggers. Triggers are the event consumers on the Salesforce platform that listen to event messages.

When an external app uses the API or a native Salesforce app uses Apex to publish the event message, a trigger on that event is fired. Triggers run the actions in response to the event notifications.

GOOD==>> Workflow-driven outbound messaging

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.

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. 

In this scenario:

1. A remote system subscribes to the platform event.
2. A update or insert occurs on a given set of records in Salesforce.
3. A Salesforce Process triggers when a set of conditions is met.
4. This process creates a platform event.
5. The remote listener receives the event message, and places the message on a local queue.
6. The queuing application forwards the message to the remote application for processing.

In this scenario:

1. A remote system subscribes to the platform event.
2. A update or insert occurs on a given set of records in Salesforce.
3. A Salesforce Process triggers when a set of conditions is met.
4. This process creates a platform event.
5. The remote listener receives the event message, and places the message on a local queue.
6. The queuing application forwards the message to the remote application for processing.

In the case where the remote system must perform operations against Salesforce, you can implement an optional callback operation.

Example:-

A telecommunications company wants to use Salesforce as a front end for creating accounts using the lead-to-opportunity process. An order is created in Salesforce when the opportunity is closed and won, but the back-end ERP system is the data master. The order must be saved to the Salesforce opportunity record, and the opportunity status changed to indicate that the order was created.The following constraints apply.

• No custom development in Salesforce.
• You don’t require immediate notification of the order number after the opportunity converts to an order.
• The organization has an ESB that supports the CometD protocol and is able to subscribe to platform events.

This example is best implemented using Salesforce platform events, but does require that the ESB subscribes to the platform event..On the Salesforce side:

• Create a Process Builder process to initiate the platform event (for example, when the opportunity status changes to Close-Won).
• Create a new platform event which publishes the opportunity details.

On the remote system side:

• The ESB subscribes to the Salesforce platform event using the CometD protocol.
• The ESB receives one or more notifications indicating that the opportunity is to be converted to an order.
• The ESB forwards the message to the back-end ERP system so that the order can be created.
• After the order is created in the ERP system, a separate thread calls back to Salesforce using the SessionId as the authentication token. The callback updates the opportunity with the order number and status. You can do this callback using documented pattern solutions, such as Salesforce platform events, Salesforce SOAP API, REST API, or an Apex web service.

This example demonstrates the following.

• Implementation of a remote process invoked asynchronously
• End-to-end guaranteed delivery
• Subsequent callback to Salesforce to update the state of the record

Batch Data Synchronization

You’re moving your CRM implementation to Salesforce and want to:

• Extract and transform accounts, contacts, and opportunities from the current CRM system and load the data into Salesforce (initial data import).
• Extract, transform, and load customer billing data into Salesforce from a remote system on a weekly basis (ongoing).
• Extract customer activity information from Salesforce and import it into an on-premises data warehouse on a weekly basis (ongoing).

Solution:-

BEST==>>Salesforce Change Data Capture

Salesforce Change Data Capture publishes change events, which represent changes to Salesforce records. Changes include creation of a new record, updates to an existing record, deletion of a record, and undeletion of a record.

With Change Data Capture, you can receive near-real-time changes of Salesforce records, and synchronize corresponding records in an external data store.

Change Data Capture takes care of the continuous synchronization part of replication. It publishes the deltas of Salesforce data for new and changed records. Change Data Capture requires an integration app for receiving events and performing updates in the external system.

BEST==>>Replication via third-party ETL tool

Leverage a third-party ETL tool that allows you to run change data capture against source data.

The tool reacts to changes in the source data set, transforms the data, and then calls Salesforce Bulk API to issue DML statements. This can also be implemented using the Salesforce SOAP API.

Remote Call-In

You use Salesforce to track leads, manage your pipeline, create opportunities, and capture order details that convert leads to customers. But, Salesforce isn’t the system that contains or processes orders. Orders are managed by an external (remote) system. That remote system needs to update the order status in Salesforce as the order passes through its processing stages.

BEST==>> SOAP API

BEST==>> REST API

A printing supplies and services company uses Salesforce as a front end to create and manage printer supplies and orders. Salesforce asset records representing printers are periodically updated with printing usage statistics (ink status, paper level) from the on-premises Printer Management System (PMS), which regularly monitors printers on client sites. Upon reaching a set threshold value (for example, low ink status or low/empty paper level of less than 30%), multiple apps/processes (variable) interested in the event are notified, email or Chatter alerts are sent, and an Order record is created. The PMS stores the Salesforce ID (Salesforce is the asset record master).The following constraints apply:

• The PMS can participate in a contract-first integration, where Salesforce provides the contract and the PMS acts as a client (consumer) of the Salesforce service (defined via the Enterprise or Partner WSDL).
• There should be no custom development in Salesforce.

This example is best implemented using the Salesforce SOAP API or REST API to publish events, and declarative automation (Process Builder) in Salesforce. The primary reason to use platform events is the variable and non-finite number of subscribers; however, for simple updates to a finite list of records such as orders, then use SOAP or REST API to update the records.In Salesforce:

• Define a platform event in Salesforce to contain the notification data coming from the PMS.
• Create a Process Builder process that’s triggered by the printer event notification. The process updates the printer asset and creates an order (using an auto-launched Flow).
• Download the Enterprise or Partner WSDL and provide it to the remote system.

In the remote system:

• Create a client stub from the Enterprise or Partner WSDL.
• Authenticate to Salesforce (via OAuth web server or bearer token flow) using the integration user’s credentials.
• Upon printer status event, the PMS calls the API to create the printer status platform event (with printer usage statistics). The Salesforce event bus notifies Process Builder subscriber and all other subscribers.

When you use platform events, the event bus lets you replay events for 72 hours for high-volume platform events. Publishing those events using a middleware solution can help incorporate error handling on the publishing side. However, you can implement error handling on the subscribing side if you need higher reliability.

Salesforce link

uniquesymbol