Salesforce integration Pattern: Remote Process Invocation—Request and Reply

Problem

When an event occurs in Salesforce, how do you initiate a process in a remote system, pass the required information to that process, receive a response from the remote system, and then use that response data to make updates within Salesforce?

Considerations
Does the call to the remote system require Salesforce to wait for a response before continuing processing? Is the call to the remote system a synchronous request-reply or an asynchronous request?
If the call to the remote system is synchronous, does Salesforce have to process the response as part of the same transaction as the initial call?
Is the message size small or large?

Is the integration based on the occurrence of a specific event, such as a button click in the Salesforce user interface, or DML-based events?

Solution

The following table contains solutions to this integration problem.

Solution	Fit	Comments
A custom Visualforce page or button initiates an Apex SOAP callout in a synchronous manner.	Best	Salesforce enables you to consume a WSDL and generate a resulting proxy Apex class. This class provides the necessary logic to call the remote service. A user-initiated action on a Visualforce page then calls an Apex controller action that then executes this proxy Apex class to perform the remote call. Visualforce pages require customization of the Salesforce application.
A custom Visualforce page or button initiates an Apex HTTP callout in a synchronous manner.	Best	Salesforce enables you to invoke HTTP services using standard GET, POST, PUT, and DELETE methods. You can use several HTTP classes to integrate with RESTful services. It’s also possible to integrate to SOAP-based services by manually constructing the SOAP message. The latter is not recommended because it’s possible for Salesforce to consume WSDLs to generate proxy classes. A user-initiated action on a Visualforce page then calls an Apex controller action that then executes this proxy Apex class to perform the remote call. Visualforce pages require customization of the Salesforce application.

The following diagram illustrates a synchronous remote process invocation using Apex calls.

Calling Mechanisms

The calling mechanism depends on the solution chosen to implement this pattern.

Calling Mechanism	Description
Visualforce and Apex controllers	Used when the remote process is triggered as part of an end-to-end process involving the user interface, and the result must be displayed or updated in a Salesforce record. For example, the submission of a credit card payment to an external payment gateway and the payment results are immediately returned and displayed to the user. Integration that’s triggered from user interface events usually requires the creation of custom Visualforce pages.
Apex triggers	Used primarily for invocation of remote processes using Apex callouts from DML-initiated events. For more information about this calling mechanism, see pattern Remote Process Invocation—Fire and Forget.
Apex batch classes	Used for invocation of remote processes in batch. For more information about this calling mechanism, see pattern Remote Process Invocation—Fire and Forget.

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.

Idempotent Design Considerations

Idempotent capabilities guarantee that repeated invocations are safe. If idempotency isn’t implemented, repeated invocations of the same message can have different results, potentially resulting in data integrity issues. Potential issues include the creation of duplicate records or duplicate processing of transactions.

It’s important to ensure that the remote procedure being called is idempotent. It’s almost impossible to guarantee that Salesforce only calls once, especially if the call is triggered from a user interface event. Even if Salesforce makes a single call, there’s no guarantee that other processes (for example, middleware) do the same.

The most typical method of building an idempotent receiver is for it to track duplicates based on unique message identifiers sent by the consumer. Apex web service or REST calls must be customized to send a unique message ID.

In addition, operations that create records in the remote system must check for duplicates before inserting. Check by passing a unique record ID from Salesforce. If the record exists in the remote system, update the record. In most systems, this operation is termed as an upsert 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, 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.

See Security Considerations.

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.

Endpoint Capability and Standards Support

The capability and standards support for the endpoint depends on the solution that you choose.

Solution	Endpoint Considerations
Apex SOAP callouts	The endpoint must be able to receive a web service call via HTTP. Salesforce must be able to access the endpoint over the public Internet. This solution requires that the remote system is compatible with the standards supported by Salesforce. At the time of writing, the web service standards supported by Salesforce for Apex SOAP callouts are: WSDL 1.1 SOAP 1.1 WSI-Basic Profile 1.1 HTTP
Apex HTTP callouts	The endpoint must be able to receive HTTP calls. Salesforce must be able to access the endpoint over the public Internet. You can use Apex HTTP callouts to call RESTful services using the standard GET, POST, PUT, and DELETE methods.

State Management

When integrating systems, keys are important for ongoing state tracking. There are two options.

• Salesforce stores the remote system’s primary or unique surrogate key for the remote record.

• The remote system stores the Salesforce unique record ID or some other unique surrogate key.

There are specific considerations for handling integration keys, depending on which system contains the master record, as shown in the following table.

Master System	Description
Salesforce	The remote system stores either the Salesforce RecordId or some other unique surrogate key from the record.
Remote system	The call to the remote process returns the unique key from the application, and Salesforce stores that key value in a unique record field.

Complex Integration Scenarios

In certain cases, the solution prescribed by this pattern can require the implementation of several complex integration scenarios. This is best served by using middleware or having Salesforce call a composite service. These scenarios include:

• Orchestration of business processes and rules involving complex flow logic

• Aggregation of calls and their results across calls to multiple systems

• Transformation of both inbound and outbound messages

• Maintaining transactional integrity across calls to multiple systems

  Source : http://www.saasanalogy.com/salesforce-integration-pattern-remote-process-invocation-request-and-reply/