Yet another IT blog. Focusing mostly on MS CRM.: Top 8 errors made by Dynamics CRM developers - Part 1

Having spend some time working as a CRM focused developer I often see the same development issues reappearing again and again. The root of the problem is that CRM programming is kind of special and previous experience from working with SQL databases or Web Development, although very precious and desired, can cause certain aspects of the code to be developed not exactly how it should have been.
In this series of posts I’ll try to summarize the most common mistakes or misconceptions I often see. As a matter of fact, because of my previous SQL and Web experience, I made some of them myself when starting my work with CRM several years ago.
To keep this a blog I have decided to split it up in a series of posts. The subjects I intend to cover are:

Not facilitating the pre-event plugins (this post)
Choosing the right query method: FetchXML vs QueryExpression vs LINQ
Querying for all columns
No or invalid plugin filters
Unsupported DOM manipulation
Getting the true value of an attribute inside a plugin
Not understanding how solutions work
Putting business logic client side

Issue #1 – Not facilitating the pre-event plugins

This is probably the most common issue I see, and also the one causing the most problems when it comes to performance.

Simple rule is:
If you want to update the record that triggered the plugin, update the values directly in the target entity, using a pre-operation plugin. Do not use the .Update() method of the CRM web service.

A good example would be filling in a “full name” based on the first and last names. There are off course several ways of doing this, but let’s assume we use a plugin (which is probably also the best choice – see Issue #8).

Let’s see a short reminder on how the Dynamic CRM plugin execution pipeline looks like:

Fig 1 – Dynamics CRM plugin execution pipeline

As we can see it start with an event, like a certain field being updated or a record being created.
Next we have the place to register pre-validation plugins. Pre-validation means that even if we, for example, decide to limit an integer field to the 0-100 range and a user types in 1000, this plugin will still get executed. We can correct the value in code, without the user seeing an error message.
Right after the pre-validation plugins the “platform” performs the validation, like throwing errors when values are not in expected range.

Now the pre-operation plugins get executed, and this is where it gets interesting. We are still before the core database operation, so nothing has been stored yet. On the other hand we have access to the data that will be passed over to SQL and can freely modify it. This is the place where all changes to the current record should be done. Whatever we change here will modify the state of the object passed to SQL.

In the above example we fill in the full name. See how the value we filled in is then later passed to SQL and stored in the DB. This is the correct way of doing it. No further plugins will be triggered.

The anti-pattern looks like this:

Fig 2 – Update anti-pattern

What happens here is that we execute and completely unnecessary update, causing the whole pipeline to execute two times instead of once. In the worse case scenario we have setup our plugins to trigger on change of all attributes and then check the execution depth to avoid infinite loops… That is a no no no…

Some code examples

Let’s say we want to have a plugin that changes the last name of a contact to upper case. This should be performed on each update of the last name.

This is how it should not be done:

// Post-update plugin

// Registered on update of LastName

public class LastNameToUpperPlugin : IPlugin

{

public void Execute(IServiceProvider serviceProvider)

{

// Get context

IPluginExecutionContext context = (IPluginExecutionContext)

serviceProvider.GetService(typeof(IPluginExecutionContext));

// AVOID INFINITE LOOP

if(context.Depth > 1)

{

return;

}

// Get target contact

Entity entity = (Entity)context.InputParameters["Target"];

Contact targetContact = entity.ToEntity<Contact>();

// Get organization service

IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)

serviceProvider.GetService(typeof(IOrganizationServiceFactory));

IOrganizationService orgService = serviceFactory.CreateOrganizationService(context.UserId);

// Business logic

string lastNameUpper = (targetContact.LastName ?? "").ToUpper(CultureInfo.InvariantCulture);

Contact updateContact = new Contact()

{

ContactId = targetContact.Id,

LastName = lastNameUpper

};

// !! Here we call the .Update()

// This will cause an INFINITE LOOP

orgService.Update(updateContact);

}

In general, whenever you see checking the execution depth, with 99,99% probability there is something wrong with the code.

What would be a much better solution is:

// Pre-update plugin