When you implement Salesforce, you frequently need to integrate it with other applications. Although each integration scenario is unique, there are common requirements and issues that developers must resolve. This document describes one of the patterns (and others coming soon!!) for these common integration scenarios.
Each pattern describes the design and approach for a particular scenario rather than a specific implementation. This pattern, called Remote Process Invocation – Continuations, takes the common usecase of having an external system that is used to contain and process orders. In this scenario, you use Salesforce to track leads, manage your pipeline, create opportunities, and capture order details that convert leads to customers. After the order details are captured in Salesforce, an order needs to be created in the remote system, and the remote system manages the order to its conclusion.
When you implement this pattern, Salesforce makes a call to the remote system to create the order, and then waits for successful completion of that call. To signify successful completion of the call, the remote system synchronously replies with the order status and order number. As part of the same transaction, Salesforce updates the order number and status internally. The order number is used as a foreign key for any subsequent updates to the remote system.
The multitenant Force.com platform uses governor limits to ensure that system resources are available to all customers, and to prevent any one customer from monopolizing them. One limit that customers frequently reach is the concurrent request limit. When a synchronous Apex request runs longer than five seconds, it counts against this limit. Each org is allowed 10 concurrent long-running requests.
The most common causes of limit errors are synchronous web service callouts. Often the long-running transactions are identified late in the process of the project during performance testing, giving limited room for change. How do you design your system to handle long-running services?
There are various forces to consider when applying solutions based on this pattern:
The Apex Asynchronous Callout Framework enables you to make callouts from a Visualforce page to an external web service, and get responses asynchronously. By making asynchronous callouts, your org is no longer restricted by the limit of 10 synchronous requests lasting longer than five seconds. Your asynchronous callouts do not consume unnecessary platform resources while the system is waiting for a response. As a result, you can make more callouts than when using synchronous callouts.
The order of operations goes like this:
The following diagram illustrates an Apex asynchronous process invocation using Apex calls.
In this scenario:
A typical Salesforce application that benefits from asynchronous callouts is one with a Visualforce page where users click a button to get data from an external web service.
For example, the Visualforce page might get warranty information for a certain product. This page can be used by thousands of agents in the org. One hundred agents might simultaneously click the same button to process warranty information for products. These hundred simultaneous actions exceed the limit of concurrent long-running requests of 10. But with asynchronous callouts, the requests aren’t subject to this limit and can all be executed.
Not everybody has a use for this pattern. You may not want or need the overhead of using the continuation object and the Asynchronous Callouts framework. If your web service calls return quickly, you’re calling them serially, and you don’t have thousands of concurrent users, an inline synchronous callout is still a valid approach to integration.
The ideal consumer is a Visualforce page being used by lots of users that is integrating real-time to a heavyweight external system.
An error handling and recovery strategy is part of a sound overall solution.
Description | Limit |
Maximum number of parallel Apex callouts in a single continuation | 3 |
Maximum number of chained Apex callouts | 3 |
Maximum timeout for a single continuation | 120 seconds |
Maximum Visualforce controller-state size | 80 KB |
Maximum HTTP response size | 1 MB |
Maximum HTTP POST form size—the size of all keys and values in the form | 1 MB |
Maximum number of keys in the HTTP POST form 3 | 500 |
You can make up to three asynchronous callouts in a single continuation. Add these callout requests to the same continuation by using the addHttpRequest method of the Continuation class. The callouts run in parallel and suspend the Visualforce request. Only after all callouts are returned by the external service does the Visualforce process resume.
If the order of the callouts matters, or when a callout is conditional on the response of another callout, you can chain callout requests. Chaining callouts means that the next callout is made only after the response of the previous callout returns. For instance, you can chain a callout to get warranty extension information after the warranty service response indicates that the warranty expired. You can chain up to three callouts.
Synchronous callouts are supported only through Visualforce pages. Making an asynchronous callout by invoking the action method outside a Visualforce page, as in the Developer Console, isn’t supported. Asynchronous callouts are available for Apex controllers and Visualforce pages saved in version 30.0 and later. If JavaScript remoting is used, version 31.0 or later is required.
To learn more about integration patterns and practices, see Integration Patterns and Practices.
To learn more about asynchronous processing, see the Trailhead module on Asynchronous Apex.
Additional great resource, see Avoiding Apex Speeding Tickets .
Karishma is a Architect Director in Advisory Services specializing in enterprise-wide systems integration of Salesforce technology across industries such as Insurance, Telecom, Utilities, Financial Services, Supply Chain, Biotech and Public Sector. She has 10+ years of international experience in the areas of Enterprise Application Integration (EAI), Technical Architecture, Application Development and Deployment. She is also a Salesforce Certified Technical Architect and is passionate about solving complex problems through simple solutions.