Optimizing Performance with ExecuteMultipleRequest

1. The Problem: The Cost of Sequential Operations

Imagine you have a list of 5,000 contact records to create or update. Your most straightforward approach, using the IOrganizationService interface you're familiar with, would be to loop through the collection and call the service for each record.

// The naive approach
foreach (var entity in collectionOfEntitiesToUpdate)
{
    // Each call is a separate network round-trip
    service.Update(entity); 
}

While this works, it's slow. Each Update call is a separate HTTP request to the Dataverse server. The total execution time is dominated not by the server's processing, but by the cumulative network latency of thousands of round-trips.

2. The Solution: Batching with ExecuteMultipleRequest

The ExecuteMultipleRequest message is the classic solution to this problem. It acts as a container, allowing you to bundle a collection of individual OrganizationRequest objects (like CreateRequest, UpdateRequest, DeleteRequest, or even calls to your custom APIs) and send them to the server in a single network call.

The server unpacks the batch and executes each request sequentially. This dramatically improves throughput, especially in high-latency environments.

Let's dive into the official documentation to understand the structure of this request.

Core Implementation

As you saw in the documentation, the core pattern involves three steps:

1. Construct the Request: Create an ExecuteMultipleRequest object, populate its Requests collection, and configure its Settings.
2. Execute the Batch: Call service.Execute() with your batch request.
3. Process the Response: Loop through the ExecuteMultipleResponse.Responses collection to check for the success or failure of each individual operation.

Here's the essential code structure from the Microsoft example:

// 1. Construct the request
var executeMultipleRequest = new ExecuteMultipleRequest()
{
    Settings = new ExecuteMultipleSettings()
    {
        ContinueOnError = true, // Or false
        ReturnResponses = true // Or false
    },
    Requests = new OrganizationRequestCollection()
};

// Add individual requests to the batch
foreach (var entityToCreate in myEntityCollection.Entities)
{
    CreateRequest createRequest = new CreateRequest { Target = entityToCreate };
    executeMultipleRequest.Requests.Add(createRequest);
}

// 2. Execute the batch
var executeMultipleResponse = 
    (ExecuteMultipleResponse)service.Execute(executeMultipleRequest);

// 3. Process the response
foreach (var responseItem in executeMultipleResponse.Responses)
{
    if (responseItem.Fault != null)
    {
        // A fault occurred for this specific request
        // You can get the original request index via responseItem.RequestIndex
    }
    else
    {
        // This request was successful
    }
}

3. Controlling Execution and Handling Failures

The real power and flexibility of ExecuteMultipleRequest come from the ExecuteMultipleSettings. These settings are crucial for building robust data integration processes.

The combination of these settings determines the contents of the response you get back, which is a common topic for exam questions.

4. Real-World Best Practices

In a production scenario, you can't just throw 50,000 requests into a single ExecuteMultipleRequest. You need to handle server-side limits and process the work in manageable chunks.

Batching and Throttling

Dataverse imposes a limit on the number of requests you can include in a single ExecuteMultipleRequest batch (typically 1000). Exceeding this limit will cause the entire batch to fail before it even starts.

The standard professional practice is to break your large collection of operations into smaller "mini-batches" and execute them sequentially or in parallel.

Handling the MaxBatchSize Fault

What if the server's batch size limit changes? A robust application shouldn't hard-code the limit. Instead, you can wrap your Execute call in a try-catch block to specifically handle the fault that occurs when the batch size is exceeded. The server helpfully includes the MaxBatchSize in the fault details, allowing your code to adjust dynamically.

5. Important Caveats and Modern Alternatives

Do Not Use in Synchronous Plugins

A critical rule for PL-400 and real-world development is to avoid using ExecuteMultipleRequest inside a synchronous plugin. Doing so can easily exceed the 2-minute plugin timeout and creates complex transaction rollback scenarios. This is considered a bad practice and will be flagged by the Solution Checker.

Modern, Specialized Alternatives

In recent years, Microsoft has introduced more specialized and even more performant messages for specific bulk operations: CreateMultipleRequest and UpdateMultipleRequest.

• Use CreateMultiple / UpdateMultiple when all your operations are of the same type (all creates or all updates). They offer better performance for these specific scenarios.
• Use ExecuteMultiple when you need to mix different types of operations (e.g., creating some records, updating others, and deleting a few, all in the same batch) or when calling actions/custom APIs.

Conclusion

You have now learned the cornerstone pattern for performing bulk data operations in Dataverse. By batching requests with ExecuteMultipleRequest, you can build highly performant and scalable integrations and data management tools.

Key Takeaways:

• ExecuteMultipleRequest dramatically improves performance by reducing network round-trips.
• Each operation within a batch runs in its own separate transaction. It is not an "all-or-nothing" operation.
• The ContinueOnError and ReturnResponses settings give you fine-grained control over execution flow and result handling.
• Always break large workloads into smaller batches to stay under the server's MaxBatchSize limit.
• Never use ExecuteMultipleRequest in a synchronous plugin.
• For pure create or update scenarios, consider the newer CreateMultipleRequest and UpdateMultipleRequest for even better performance.

Up Next:
We've focused entirely on performance, where each part of a batch succeeds or fails independently. But what if you need to guarantee that a series of operations either all succeed or all fail together, as a single atomic unit? In our next lesson, we will explore the other side of this coin: ExecuteTransactionRequest, which is designed for data consistency rather than raw throughput.