Using Bulk Operations messages – #01 (Plugins)

Well, this could be a very interesting post as we talk about optimizing the Dataverse performance using bulk operation messages and too using Dataverse plugin customizations but wait, this post is not complete because of an issue which I will talk later in the blog. First let’s dig into this feature by actually trying out. Generally, every business wants improved performance for any logic tagged out to out of box messages and so developers try to optimize their code in various ways when using Dataverse messages.

Firstly, before diving deeper into this article, let’s first understand the differences between Standard and Elastic tables, if you want to know a bit of introduction to elastic tables which were newly introduced last year, you can refer to my previous post on elastic tables here.

The type of table you choose to store your data has the greatest impact on how much throughput you can expect with bulk operations. You can choose out of two types of tables in Dataverse, below are some key differences you can refer to: 

	Standard Tables	Elastic Tables
Data Structure	Defined Schema	Flexible Schema
	Stores data in Azure SQL	Stores data in Azure Cosmos DB
Data Integrity	Ensured	Less Strict
Relationship model	Supported	Limited
Performance	Predictable	Variable, preferred for unpredictable and spiky workloads
Agility	Limited	High
Personalization	Limited	Extensive

Plugins:

With Bulk Operation messages, the APIs being introduced are Create Multiple, UpdateMultiple,DeleteMultiple (only for Elastic tables), Upsert Request(preview). As of now you’re not required to migrate your plug-ins to use CreateMultiple and Update Multiple instead of Create and Update messages. Your logic for Create and Update continues to be applied when applications use CreateMultiple or UpdateMultiple. 

This is mainly done to prevent two separate business logics for short running and long duration activities. So, it means Microsoft have merged the message processing pipelines for these messages (Create, Create Multiple; Update, Update Multiple) that means Create, Update messages continue to trigger for your existing implemented scenarios, when you update to use Create Multiple, Update Multiple still the Create, Update will behave.

Few points for consideration:

1. While I have tested and still could see IPluginExecutionContext only provides the information and still I have noted Microsoft Documentation suggests using IPluginExecutionContext4 for Bulk Messages in Plugins where it is being shown as null yet.
2. While you were working with Create, Update, Delete, you could have used Target property to get the input parameters collection, while working with Bulk Operation messages, you need to use Targets instead of Target.
3. Instead of checking whether the target is Entity you need to use Entity Collection, we need to loop through and perform our desired business logic
4. Coming to Images in plugin, these will be retrieved only when you have used IPluginExecutionContext4.

Below is the image from Plugin Registration Tool to refer(e.g. I have taken UpdateMultiple as reference, you can utilize any of the bulk operation messages)

Sample:

Below is the sample, how your Bulk operation message plugin can look like…you don’t need to use all the contexts, I have used to just check that out.

	using System;
	using System.Collections.Generic;
	using System.Linq;
	using System.Text;
	using System.Threading.Tasks;
	using Microsoft.Crm.Sdk;
	using Microsoft.Xrm.Sdk;
	using Microsoft.Xrm.Sdk.Query;
	namespace Plugin_Sample
	{
	public class BulkMessagePlugin : IPlugin
	{
	public void Execute(IServiceProvider serviceProvider)
	{
	IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
	IPluginExecutionContext2 context2 = (IPluginExecutionContext2)serviceProvider.GetService(typeof(IPluginExecutionContext2));
	IPluginExecutionContext3 context3 = (IPluginExecutionContext4)serviceProvider.GetService(typeof(IPluginExecutionContext3));
	IPluginExecutionContext4 context4 = (IPluginExecutionContext4)serviceProvider.GetService(typeof(IPluginExecutionContext4));
	ITracingService trace = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
	// Verify input parameters
	if (context4.InputParameters.Contains("Targets") && context.InputParameters["Targets"] is EntityCollection entityCollection)
	{
	// Verify expected entity images from step registration
	if (context4.PreEntityImagesCollection.Length == entityCollection.Entities.Count)
	{
	int count = 0;
	foreach (Entity entity in entityCollection.Entities)
	{
	EntityImageCollection entityImages = context4.PreEntityImagesCollection[count];
	// Verify expected entity image from step registration
	if (entityImages.TryGetValue("preimage", out Entity preImage))
	{
	bool entityContainsSampleName = entity.Contains("fieldname");
	bool entityImageContainsSampleName = preImage.Contains("fieldname");
	if (entityContainsSampleName && entityImageContainsSampleName)
	{
	// Verify that the entity 'sample_name' values are different
	if (entity["fieldname"] != preImage["fieldname"])
	{
	string newName = (string)entity["fieldname"];
	string oldName = (string)preImage["fieldname"];
	string message = $"\\r\\n – 'sample_name' changed from '{oldName}' to '{newName}'.";
	// If the 'sample_description' is included in the update, do not overwrite it, just append to it.
	if (entity.Contains("sample_description"))
	{
	entity["sample_description"] = entity["sample_description"] += message;
	}
	else // The sample description is not included in the update, overwrite with current value + addition.
	{
	entity["sample_description"] = preImage["sample_description"] += message;
	}
	}
	}
	}
	}
	}
	}
	}
	}
	}

view raw UpdateMultipleSample.cs hosted with ❤ by GitHub

I have posted this question to Microsoft regarding the same to know more details on this why the IPluginExecutionContext4 is null , while still I am not sure if this is not deployed to my region, my environment is in India.

Recommendations for Plugins:

• Don’t try to introduce CreateMultiple, UpdateMultiple, UpsertMultiple in a separate step as it would trigger the logic to be fired twice one for Create operation and another for CreateMultiple.
• Don’t use batch request types such as ExecuteMultipleRequest, ExecuteTransactionRequest, CreateMultipleRequest, UpdateMultipleRequest, UpsertMultipleRequest in Plugins as user experiences are degraded and timeout errors can occur.
• Instead use Bulk operation messages like CreateMultipleRequest, UpdateMultipleRequest, UpsertMultipleRequest

• No need to use ExecuteTransactionRequest in Synchronous Plugins as already they will be executed in the transaction.

Hope this guidance will help someone trying to customize their Power Platform solutions using Plugins.

I will write another blog post on using Bulk operation messages for Client Applications…

Cheers,

PMDY