Understanding Database Allows Callout in Salesforce Apex

Blog
Spread the love

In Salesforce, the Database.AllowsCallouts interface is used to enable Apex classes to perform HTTP callouts or web service callouts in asynchronous processes like Batch Apex or Queueable Apex. Callouts are requests made to external systems, such as HTTP requests or SOAP/REST web service calls defined with the webService keyword.

While most developers are familiar with @future(callout=true) or making synchronous HTTP callouts in Apex, there’s a lesser-known, powerful tool that Salesforce provides for this: Database.AllowsCallouts.

What Is Database.AllowsCallouts?

  • Purpose: Database.AllowsCallouts is a marker interface in Apex. It doesn’t require any method implementations but acts as a flag to let Salesforce know that your asynchronous class (like a batch or queueable job) is allowed to make HTTP or web service callouts. Without implementing this interface, Salesforce restricts callouts in certain contexts (e.g., Queueable Apex) to prevent governor limit violations or performance issues.
  • Context: It is primarily used in Batch Apex and Queueable Apex to integrate Salesforce with external systems, such as APIs, web services, or third-party servers.
  • Callout Types: HTTP Callouts via HttpRequest and Http classes (e.g., REST APIs). SOAP Web Services via webService keyword in Apex.

How to Use Database.AllowsCallouts

To enable callouts, the Apex class must implement the Database.AllowsCallouts interface alongside other interfaces like Database.Batchable or Queueable. Below are examples for both contexts.

  1. Batch Apex Example
  2. Queueable Apex Example

Key Features and Behavior

  1. Enables External Integration
    • Allows Salesforce to communicate with external systems, such as APIs (e.g., REST, SOAP), third-party services (e.g., RazorSync, Skedulo), or other servers.
  2. Marker Interface
    • Database.AllowsCallouts is a marker interface, meaning it has no methods to implement. It simply informs the Salesforce runtime that the class is allowed to make callouts.
    • It does not introduce performance overhead, even if included in classes that don’t make callouts.
  3. Asynchronous Context:
    • Designed for asynchronous processes like Batch Apex and Queueable Apex, where long-running operations (e.g., callouts) won’t block database transactions.
  4. Governor Limits:
    • Callout Limit: A single Apex transaction can make up to 100 callouts (HTTP requests or web service calls).
    • Batch Size: To avoid hitting the 100-callout limit, the batch size should be set to 100 or lower if each record requires one callout.
    • Callout Size: The maximum size of a callout request or response is 6 MB for synchronous Apex and 12 MB for asynchronous Apex.
    • Timeout: Callouts can take up to 120 seconds per request, but the total transaction time is also governed by Salesforce limits.
  5. Error Handling
    • Callouts can fail due to network issues, timeouts, or external server errors. Robust error handling is critical:

Limitations and Constraints

  1. Not Supported in Triggers:
    • Direct callouts from triggers are not allowed because they could delay database transactions (up to 120 seconds).
  2. Constructor Limitation:
    • Callouts in the constructor of a Batch Apex class are not supported, even with Database.AllowsCallouts. This is because the constructor runs outside the start, execute, or finish methods, where the interface’s effect is applied.
  3. Scheduled Apex:
    • Callouts from Scheduled Apex classes are not supported, even with Database.AllowsCallouts, if the callout is made directly in the execute method of the Schedulable interface.
  4. Future Methods:
    • Methods annotated with @future cannot be called from Batch Apex, as they are not compatible with batch processing.
    • Use Queueable Apex instead for callout-heavy logic that needs to be chained or invoked from Batch Apex.
  5. Callout Limits in Batch Apex:
    • Each start, execute, and finish method can make up to 100 callouts. If each record in the execute method requires one callout, the batch size must be 100 or less to avoid the System.LimitException: Too many callouts: 101 error.
  6. Testing Challenges
    • Callouts cannot be made in Apex unit tests directly. You must use mock callouts with the Test.setMock method:

Conclusion

Database.Callout might not be the first tool Apex developers learn, but it’s a powerful enabler for real-world, scalable integrations, especially when working with large datasets and external systems.

If you’re looking to handle callouts efficiently in batch jobs, understanding this interface is a must. It’s a hidden gem that makes Apex integration more enterprise-ready

bluethinkinc_blog

bluethinkinc_blog

2025-05-07

0

Leave a Reply

Your email address will not be published. Required fields are marked *

Find More Blogs

Understanding Database Allows Callout in Salesforce Apex

Spread the love In Salesforce, the Database.AllowsCallouts

PODMAN

Spread the love 1.Introduction Podman: The Modern Container

Running Your Java Program (JAR) 24/7 on AWS EC2 Automatically

Spread the love Introduction Running a Java application

Building a REST API with Spring Boot

Spread the love Introduction REST (Representational State

Custom API to Fetch Customer Data by Customer ID in Spryker

Spread the love Introduction In this blog post, we will

Creating a Custom Module for a Custom Frontend Page in Spryker

Spread the love To create a custom module for a custom

How to create custom module api get category list without access token in Spryker

Spread the love To create a custom API for fetching a

Creating a Custom Glue API in Spryker

Spread the love Spryker’s Glue API is a powerful tool

Get AI Generated 360-Degree View of Account Summary in Dynamics 365 Sales

Spread the love Navigating the demanding landscape of sales

Enhancing Productivity with Dynamics 365: The Power of Session Restore

Spread the love Enhancing Productivity with Dynamics 365:

bluethinkinc Blogs