Entity updates using change tracker

Scope

When working with entity records in plugins and tools, we almost always need to update the records.

For updating records, it is a best practice to only send diff updates.

There a many reasons to do this, some of them being:

  1. Keeping the audit history tidy
  2. Preventing circular updates (mostly in mapping scenarios, where children might update parents as well)
  3. Preventing plugins to fire when values did not change
  4. Keeping the transactions as small as possible

 

In this post im going to show, how updating diffs only can be done easily using Xrm-Update-Context, a library that I created for tracking state on entity objects.

 

Getting it

Since I wanted to be able to use it everywhere, in plugins as well as in external applications, I published it as Nuget Source package.

That means that the source code (one file) is added directly to your project, so that it is completely native to your application.

You can install it from NuGet.

 

Using it

Using the update context is rather simple: Initiate it with a using statement and pass the record that you want to track changes for as constructor parameter.

At this point, the update context will clone the initial state internally. You can then change or even remove values inside your tracked record and use `updateContext.Update` for sending the diff update automatically, or use `updateContext.GetUpdateObject` for getting a cloned snapshot of the diff object.

There is also support for getting UpdateRequests as well, using `updateContext.GetUpdateRequest`.

using(var updateContext = new UpdateContext<Contact>(contact))
{
    contact.FirstName = "Bilbo";
    
    bool updateSent = updateContext.Update(service);
}

In above example, we initiate the update context with a contact record. For late binding, you can just pass Entity as type.

We set the first name directly in our record, when using updateContext.Update, the update context automatically creates a diff object with the same Id and logical name, containing only the first name and sends it as update using the passed OrganizationService.

The above example seems very easy and you might think, that you could just create an update object yourself as well.

This is correct, but imagine that you pass your record through a multitude of functions, which all might alter the state of multiple fields or not.

Now it becomes very difficult to ensure to send diff updates only.

Xrm-Update-Context takes care of this for you all on its own, just initialize it, pass the records to your functions and send the update using update context, it’s as easy as this!

Remarks

When setting values to null, ensure that the initial state of your entity object contained the key, for example by including all columns that you might want to update in your retrieve column set.

Xrm-Update-Context will treat values that were missing inside the initial state and that are going to be set null as no operation, so they wouldn’t be included in the diff.

This was needed to prevent some issues that occured because of this behaviour.

Summary

I hope that I managed to show you, which problems Xrm-Update-Context is able to solve.

In addition to that I showed you, how easy it is to set up and use Xrm-Update-Context.

For feedback and issue reports, which are both always welcome, please use GitHub.

Leave a Reply

Your email address will not be published.

RELATED POST

Writing fluent OrganizationService queries

Scope Programming in the Dynamics environment is often very data driven by its nature. Because of this, most applications and…