Manage Long-Running Integration Procedures
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the settings to use for long-running Integration Procedures.
- Discuss limits for chainable and queueable chainable configurations.
Introduction
In addition to individual healthcare consumers, ClearLight serves medium- and large-group customers. Larger groups are organizations or companies with at least 100 employees. The ClearLight sales team often works with large volumes of data for these sizable clients, for example, to manage large quotes and contracts with many policies. This requires some heavy-duty processing for their Sales Cloud solution.
Salesforce governor limits are usage caps that help ensure efficient processing and use of resources on the Salesforce platform. Limits can present challenges to teams using OmniScripts when a transaction in an Integration Procedure exceeds a governor limit. Once the limit is reached, Salesforce ends the transaction, and the Integration Procedure fails.
Sometimes, the sales team hits limits during high-volume-transaction scenarios, which can delay the sales process. Whom do they call for help? You guessed it - Robert, our OmniStudio developer.
Robert accepts the challenge to help ClearLight with open arms. He’s committed to ensuring their OmniScripts can support high-volume transactions and long-running Integration Procedures. This way, the sales team can run with sales and meet targets.
Welcome to Chaining
An Apex transaction represents a set of operations that run as a single unit. Robert knows all actions in an Integration Procedure run in the same transaction by default. He reads up in the Salesforce Developer Documentation to learn more and decides to focus on chaining and limits, as it's excessive and potentially confusing.
Chaining is useful for sequential processing, so Robert can chain one job to another job by starting a subsequent job from a running job. He also needs to set governor limits to trigger chaining when specific transaction limits are reached. Chaining settings include:
- Chainable: Use this setting for synchronous Apex governor limits.
- Queueable Chainable: Use this setting for asynchronous Apex governor limits.
- Chain On Step: Enable this setting if you want the next step of an action to always run in a new transaction.
Chaining can impact Integration Procedure performance. This is because the transaction breaks up the execution into chunks of data, and the platform must store interim results. For more information, see Settings for Long-Running Integration Procedures.
Chainable Setting
With chaining enabled, if an Integration Procedure step exceeds the configured limits, the interim results are saved, and the step continues in a new transaction. This way, the step doesn’t compete for resources with other steps in the Integration Procedure. To maximize performance, an Integration Procedure only chains steps once a transaction exceeds the configured limits. If no limits are exceeded, all the steps in the Integration Procedure run in a single transaction.
Before proposing the solution to the customer, Robert wants to experiment with the chainable and queueable chainable settings using an existing auto insurance quoting OmniScript. First, he needs to find out exactly where to improve OmniScript performance, so he picks a suspect long-running Integration Procedure for testing. Next, he opens his handy OmniStudio IDX Workbench and uses the Process Profiler to determine the number of SOQL queries in one of the Calculation Actions. The number is around 70 queries.
Robert decides to enable chaining.
First, in OmniScript, he accesses the Integration Procedure Action Properties (1) and selects Chainable (2).
Next, he accesses the Integration Procedure. In the Structure Panel, Robert selects Procedure Configuration and expands the Chainable Configuration section (1). He keeps 70 as the Chainable Queries Limit (2).
With these settings, once the queries reach 70, the Integration Procedure runs the next Action as a new transaction.
Robert tests his configuration. After the Calculation Action completes, chaining takes place, because the total number of queries in the Action is 71, which exceeds the limit of 70.
Once an Action makes 70 queries, the Integration Procedure saves the interim results and starts a second Calculation Action. The next Calculation Action makes 73 queries, which again exceeds the limit of 70. This triggers a new transaction to keep the Integration Procedure running. No chaining takes place in DataRaptor Transform Actions and the Response Action, because the total queries are within the limit.
Queueable Chainable Setting
You can increase governor limits by allowing a chainable step to start a queueable job, which runs as an asynchronous Apex job. Queueable Chainable settings override their Chainable equivalents if both are set.
To configure queueable chaining, open the OmniScript, access the Integration Procedure Action Properties (1), and select the Queueable Chainable option (2).
How is Queueable Chainable different from Chainable? With Queueable Chainable set, each chaining Integration Procedure execution becomes a queueable, asynchronous Apex job. Some governor limits are higher than for synchronous Apex, such as SOQL query limits.
Robert selects the Queueable Chainable option in the OmniScript. In the Integration Procedure, under Procedure Configuration, he expands the Queueable Chainable Limits section (1) and sets the Queueable Chainable Queries Limit (2) to 140.
Let’s see what happens with these settings configured.
In this example, the total number of queries in the Calculation Action for Multi-Automobiles rating reaches 144, which exceeds the limit of 140. Therefore, chaining takes place in this calculation action.
Chain On Step
To configure chaining in a specific Action, use the Chain On Step setting with either Chainable or Queueable Chainable enabled. When an OmniScript calls an Integration Procedure Action with Chain on Step enabled, the next step of the action always runs in its own transaction. Let’s see how this works.
The Salesforce platform prohibits Data Manipulation Language (DML) operations before HTTP external callouts. Therefore, if an HTTP Action follows a DataRaptor Post Action, you can enable Chain On Step for the DataRaptor Post Action. Do this to avoid the Salesforce error indicating you have uncommitted work pending.
Let’s follow an example procedure to configure Chain On Step for this type of scenario.
- In the Integration Procedure | Structure panel, select DataRaptorPostUpdateAccountInfo (1).
- Notice Chain On Step (2) isn’t enabled.
3. Show the Preview tab (1), and click Execute (2) to view the result. The Response pane (3) shows that the Integration Procedure fails, and the error message provides guidance on the next steps.
To avoid this error, let’s enable Chain On Step and test it out.
- In the DataRaptorPostUpdateAccountInfo Action (1), select Chain On Step (2).
- Show the Preview tab, and expand the Options section.
3. Change the value for Chainable from false (1) to true (2).
4. Click Execute (1) to run the process and see the Response (2). Now the Response shows success and the Account gets updated.
Limit Settings
To configure limits, you need to edit the Chainable Configuration and Queueable Chainable Limits settings in the Procedure Configuration section of the Integration Procedure. To disable limit checking, leave the settings blank. Just remember, if you disable limit checking, and a step exceeds a Salesforce governor limit, the Integration Procedure fails.
Configuration Limits for Chainable Settings
| Setting | Description | Default Maximum Value |
|---|---|---|
|
Chainable Heap Size Limit |
Maximum memory used to store data during transaction processing |
6 MB |
|
Chainable Query Rows Limit |
Maximum number of rows that a SOQL query is allowed to retrieve |
50,000 |
|
Chainable DML Rows Limit |
Maximum number of records that can be processed as a result of DML statements |
10,000 |
|
Chainable SOSL Queries Limit |
Maximum number of SOSL queries that can run |
20 |
|
Chainable SOQL Queries Limit |
Maximum number of SOQL queries that can run |
100 |
|
Chainable DML Statements Limit |
Maximum number of DML statements that can run |
150 |
|
Chainable CPU Limit |
Maximum CPU time on the Salesforce servers |
10,000 milliseconds |
|
Chainable Actual Time |
Number of seconds an Integration Procedure can run before chaining occurs to avoid reaching the Salesforce Concurrent Request Limit |
Depends on the Integration Procedure |
Configuration Limits for Queueable Chainable Settings
|
Setting |
Description |
Default Maximum Value |
|---|---|---|
|
Queueable Chainable Heap Size Limit |
Memory used to store data during transaction processing |
12 MB |
|
Queueable Chainable Queries Limit |
Maximum number of SOQL queries that can run |
200 |
|
Queueable Chainable CPU Limit |
Maximum CPU time on the Salesforce servers |
60,000 milliseconds |
Excellent! Now Robert is ready to propose his solution to ClearLight. He’s learned how to manage long-running Integration Procedures using Chainable, Chainable Queueable, and Chain On Step. These settings help Integration Procedures run smoothly and avoid those necessary but pesky governor limits. ClearLight is super happy after reviewing Robert’s solution. He’s already dreaming of his promotion and pay hike.
