Making an HTTP callout after rolling back DML Operations

-

You can now make an HTTP callout after rolling back DML operations by releasing savepoints with Database.releaseSavepoint.

The introduction of the Database.releaseSavepoint method in Salesforce Apex is a significant development because traditionally, once you rolled back a transaction to a savepoint, you couldn't make any future DML operations or callouts in that transaction. This limitation poses a challenge in complex transactional scenarios where you may need to perform a callout after a conditional rollback.

Here's an example of how Database.releaseSavepoint can be used:

Savepoint sp = Database.setSavepoint();

try 
{ 
// Perform DML operations 
Account a = new Account(Name='Test'); 
insert a;

// ... some logic that may fail

} catch (Exception ex) { 

// Exception handling if needed 

Database.rollback(sp); 

Database.releaseSavepoint(sp); // Also releases any savepoints created after 'sp'

// Since savepoint is released, you can now make a callout
Http http = new Http();
HttpRequest request = new HttpRequest();

request.setHeader('Content-Type', 'application/json;charset=UTF-8');

request.setBody({"Application": "Salesforce B2B","Status": "Failed " + "" + ex.getMessage()});

request.setEndpoint('https://api.example.com');
request.setMethod('POST');
HttpResponse response = http.send(request);

}

In this code snippet, we set a savepoint at the beginning of the transaction and then perform some DML operations. If a specific condition is met, we roll back to the savepoint to undo the DML changes before the introduction of the Database.releaseSavepoint, you would be unable to perform an HTTP callout after the rollback due to Salesforce's restriction on callouts after DML operations in the same transaction context. However, with the release of the releaseSavepoint method, you can release the savepoint, clearing the way for a callout to be made.

This feature increases the flexibility and power of transaction control in Apex, allowing developers to write more effective and robust error-handling and recovery processes.

As part of this feature, Database.rollback(Savepoint) and Database.setSavepoint() don’t count against the DML row limit, but still count toward the DML statement limit. This change applies to all API versions. Before Spring ’24, both the calls incremented the DML row usage limit.

When Database.releaseSavepoint() is called, SAVEPOINT_RELEASE is logged if savepoints are found and released.

For Apex tests with API version 60.0 or later, all savepoints are released when Test.startTest() and Test.stopTest() are called. A SAVEPOINT_RESET event is logged if any savepoints are reset.

Resources 

releaseSavepoint

Make Callouts After Rolling Back DML and Releasing Savepoints

Comments

Post a Comment

Popular posts from this blog

Introduction to Salesforce Agent Script: Build Predictable AI Agents

-
Image
Please visit here for more details - https://ayaninsights.com/guestblogs/introduction-to-agent-script/ In my latest blog, I introduce Salesforce Agent Script and explain how it helps teams build AI agents that are more predictable, controlled, and aligned with business processes. Large language models are flexible, but relying only on natural-language instructions can sometimes produce inconsistent results. Agent Script addresses this challenge by combining the conversational capabilities of an LLM with structured business logic. The blog explains how developers can use conditions, variables, actions, topics, and transitions to control how an Agentforce agent behaves. Agent Script supports familiar logic such as if/else conditions, value comparisons, sequential actions, and checks for missing data. I also cover its core structure, including system settings, configuration, global variables, languages, connections, and topic blocks. The start_agent topic acts as the entry point for each...
Read more

Anti-Patterns in Salesforce Agentforce: What to Avoid When Building AI Agents

-
Image
Salesforce Agentforce is powerful because it allows teams to build AI agents that can understand user intent, retrieve grounded information, execute actions, and support business workflows across Salesforce. But like any powerful platform, the quality of the implementation matters. A good Agentforce implementation does not start with “How many things can the agent do?" It starts with “What problem should the agent solve reliably?” That is where anti-patterns come in. Anti-patterns are common implementation habits that look useful at first but eventually create confusion, poor user experience, inconsistent answers, or hard-to-maintain agents. Below are some of the most common Agentforce anti-patterns and how to avoid them. 1. Trying to Build One Agent That Does Everything One of the biggest mistakes is designing a single agent to handle every business process, every department, and every possible customer question. At first, this feels efficient. One agent, many use cases. Bu...
Read more

MCP vs. Traditional APIs: Choosing the Right Integration Approach

-
Image
Enterprise integration has traditionally been built around APIs. Applications send structured requests, services process them, and predictable responses are returned. This model has supported everything from payment processing and customer portals to mobile applications and large-scale system integrations. The rise of AI agents introduces a different integration challenge. An AI agent does not always follow a fixed sequence designed in advance. It may need to determine which system to use, discover the operations available to it, gather relevant context, and select the appropriate action based on a user’s request. This is where the Model Context Protocol, or MCP, becomes relevant. MCP and traditional APIs are related, but they solve different problems. APIs expose system capabilities. MCP provides a standardized way for AI applications to discover and use those capabilities as tools and contextual resources. Understanding this distinction is important when designing enterprise AI solut...
Read more