You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/best-practices/business-logic/avoid-batch-requests-plugin.md
+22-21Lines changed: 22 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -1,26 +1,15 @@
1
1
---
2
-
title: "Do not use batch request types in plug-ins and workflow activities | MicrosoftDocs"
2
+
title: "Don't use batch request types in plug-ins and workflow activities | MicrosoftDocs"
3
3
description: "You shouldn't use ExecuteMultipleRequest or ExecuteTransactionRequest message request classes within the context of a plug-in or workflow activity."
4
-
services: ''
5
4
suite: powerapps
6
-
documentationcenter: na
7
5
author: jowells
8
-
editor: ''
9
-
tags: ''
10
-
11
-
ms.devlang: na
12
-
ms.topic: article
13
-
ms.tgt_pltfrm: na
14
-
ms.workload: na
15
-
ms.date: 12/06/2019
6
+
ms.date: 02/08/2024
16
7
ms.subservice: dataverse-developer
17
8
ms.author: jowells
18
9
search.audienceType:
19
10
- developer
20
11
---
21
-
# Do not use batch request types in plug-ins and workflow activities
22
-
23
-
12
+
# Don't use batch request types in plug-ins and workflow activities
24
13
25
14
**Category**: Usage, Reliability, Performance
26
15
@@ -30,28 +19,38 @@ search.audienceType:
30
19
31
20
## Symptoms
32
21
33
-
Due to their long-running nature, using <xref:Microsoft.Xrm.Sdk.Messages.ExecuteMultipleRequest>, <xref:Microsoft.Xrm.Sdk.Messages.ExecuteTransactionRequest>, <xref:Microsoft.Xrm.Sdk.Messages.CreateMultipleRequest>, <xref:Microsoft.Xrm.Sdk.Messages.UpdateMultipleRequest>, or <xref:Microsoft.Xrm.Sdk.Messages.UpsertMultipleRequest> message request classes within the context of a plug-in or workflow activity expose sandbox-isolated plug-in types to the two-minute (120000ms) channel timeout exception and can degrade the user experience for synchronous plug-in step registrations.
22
+
User experiences are degraded and time out errors might occur when you use *batch request types* in plug-ins and workflow activities that occur within synchronous operations.
23
+
24
+
The following message request classes are considered *batch request types* because they perform operations on multiple records within a single request:
Use these batch messages where code is being executed outside of the platform execution pipeline, such as integration scenarios where network latency would likely reduce the throughput and increase the duration of larger, bulk operations.
37
+
Use these batch messages in client applications to perform operations on multiple records. Don't use these messages within code that Dataverse invokes during the execution of another operation: a plug-in or workflow activity registered for a synchronous step.
41
38
42
39
More specifically, use them in the following scenarios:
43
40
44
41
- Use <xref:Microsoft.Xrm.Sdk.Messages.ExecuteMultipleRequest> to bulk load data or external processes that are intentional about executing long-running operations (greater than two minutes).
45
42
46
-
- Use <xref:Microsoft.Xrm.Sdk.Messages.ExecuteMultipleRequest> to minimize the round trips between custom client and Dynamics 365 servers, thereby reducing the cumulative latency incurred.
43
+
- Use <xref:Microsoft.Xrm.Sdk.Messages.ExecuteMultipleRequest> to minimize the round trips between custom client and Dataverse servers, to reduce the cumulative latency incurred.
44
+
45
+
- Use <xref:Microsoft.Xrm.Sdk.Messages.ExecuteTransactionRequest> for external clients that require the batch of operations to be committed as a single, atomic database transaction or rollback if any exception is encountered. Be aware of the potential for database blocking during the long-running transaction.
47
46
48
-
- Use <xref:Microsoft.Xrm.Sdk.Messages.ExecuteTransactionRequest> for external clients that require the batch of operations to be committed as a single, atomic database transaction or rollback if any exception is encountered. Be aware of the potential for database blocking for the duration of the long-running transaction.
47
+
-[Use bulk operation messages](../../bulk-operations.md) (<xref:Microsoft.Xrm.Sdk.Messages.CreateMultipleRequest>, <xref:Microsoft.Xrm.Sdk.Messages.UpdateMultipleRequest>, and <xref:Microsoft.Xrm.Sdk.Messages.UpsertMultipleRequest>) for the same scenarios and to achieve a higher level of throughput.
49
48
50
49
<aname='problem'></a>
51
50
52
51
## Problematic patterns
53
52
54
-
Below is an example usage of<xref:Microsoft.Xrm.Sdk.Messages.ExecuteMultipleRequest> in the context of a plug-in.
53
+
The following example shows using<xref:Microsoft.Xrm.Sdk.Messages.ExecuteMultipleRequest> in the context of a plug-in.
55
54
56
55
> [!WARNING]
57
56
> This scenario should be avoided.
@@ -100,11 +99,13 @@ This example includes usage of the type directly with the `Execute` method. The
100
99
101
100
## Additional information
102
101
103
-
`ExecuteMultiple` and `ExecuteTransaction` messages are considered batch request messages. Their purpose is to minimize round trips between client and server over high-latency connections. Plug-ins either execute directly within the application process or in close proximity when sandbox-isolated, meaning latency is rarely an issue. Plug-in code should be very focused operations that execute quickly and minimize blocking to avoid exceeding timeout thresholds and ensure a responsive system for synchronous scenarios. Simply submit each request directly instead of batching them and submitting as a single request.
102
+
The purpose of the `ExecuteMultiple` message is to minimize round trips between client and server over high-latency connections. Plug-ins either execute directly within the application process or in close proximity when sandbox-isolated, meaning latency is rarely an issue. Plug-in code should be focused operations that execute quickly and minimize blocking to avoid exceeding timeout thresholds and ensure a responsive system for synchronous scenarios. Submit each request directly instead of batching them and submitting as a single request.
104
103
105
104
For example: `foreach (request in requests) service.Execute(request)`
106
105
107
-
On the server side, the operations included in a batch request are executed sequentially and aren't done in parallel. This is the case even if the <xref:Microsoft.Xrm.Sdk.ExecuteMultipleSettings>.<xref:Microsoft.Xrm.Sdk.ExecuteMultipleSettings.ReturnResponses> property is set to false. Developers tend to use batch requests in this manner assuming that it will allow for parallel processing. Batch requests won't accomplish this objective. Another common motivator is an attempt to ensure that each operation is included in a transaction. This is unnecessary because the plug-in is often already being executed within the context of a database transaction, negating the need to use the `ExecuteTransaction` message.
106
+
On the server side, the operations included in a batch request are executed sequentially and aren't done in parallel. This is the case even if the <xref:Microsoft.Xrm.Sdk.ExecuteMultipleSettings>.<xref:Microsoft.Xrm.Sdk.ExecuteMultipleSettings.ReturnResponses> property is set to false. Developers tend to use batch requests in this manner assuming that it allows for parallel processing. Batch requests don't accomplish this objective.
107
+
108
+
People use <xref:Microsoft.Xrm.Sdk.Messages.ExecuteTransactionRequest> to ensure that each operation is included in a transaction. This is unnecessary within a synchronous plug-in step because the plug-in already being executed within the context of a database transaction, negating the need to use the `ExecuteTransaction` message.
0 commit comments