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.
  

Push Past the Limits

In addition to individual healthcare consumers, ClearLight serves medium- and large-group customers 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 transactions, which can delay the sales process. Whom do they call for help? You guessed it—Robert, the hero technical architect. 

Robert’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.

In this unit, you follow along to see how he does just that.

Meet Chaining

An Apex transaction represents a set of operations that run as a unit. All actions in an Integration Procedure run in the same transaction by default.

So Robert reads up on the Salesforce Developer Documentation to learn more. He decides to focus on chaining and limits.

Chaining is useful for sequential processing, so you can chain one job to another job by starting a subsequent job from a running job. You also need to set governor limits to trigger chaining when specific transaction limits are reached.

Chaining settings include:

• Chainable, for synchronous Apex governor limits.
  
• Queueable Chainable, for asynchronous Apex governor limits.
  
• Chain On Step, for situations where 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.

Let’s explore each of these settings in more depth to help Robert solve his team’s problem.

The 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 when 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. He determines that the Integration Procedure runs about 70 SOQL queries in one of the Calculation Actions.

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 Data Mapper Transform Actions and the Response Action, because the total queries are within the limit.

The Queueable Chainable Setting

You can increase governor limits by telling a chainable step to start a queueable job, which runs as an asynchronous Apex job. Some governor limits are higher than for synchronous Apex, such as SOQL query limits. 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 Queueable Chainable(2).

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. 

The Chain On Step Setting

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.

Salesforce prohibits Data Manipulation Language (DML) operations before HTTP external callouts. Therefore, if an HTTP Action follows a Data Mapper Post Action, you can turn on Chain On Step for the Data Mapper 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 a Data Mapper Post Action(1). Notice Chain On Step (2) isn’t enabled.

Show the Preview tab (1), and select 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, enable Chain On Step and test it out.

In the Data Mapper Post Action (1), select Chain On Step (2). Show the Preview tab, and expand the Options section.

Change the value for chainable from false (1) to true (2).

Select 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, 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

Configuration Limits for Queueable Chainable Settings

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.

But there’s still work to do! In the next unit, you follow along with Robert as he learns how to handle exceptions and rollback on errors to complete another project.

Resources

• Salesforce Developers: Execution Governors and Limits
• Salesforce Help: Settings for Long-Running Integration Procedures (Omnistudio for Managed Packages)