Dynamics CRM 2011 · Plugin

CRM 2011: Event Execution Pipeline and Target Input Parameters

Often time I write plugins and wonder why it didn’t work without understanding how plugins are executed.

This MSDN article explains the Event Execution Pipeline pretty well.

 

Pre-Validation vs Pre-Operation

In CRM 2011, there is a new operation stage pre-validation. In the article, pre-validation stage is described as:

Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage may execute outside the database transaction. The pre-validation stage occurs prior to security checks being performed to verify the calling or logged on user has the correct permissions to perform the intended operation.

What is useful to know about this stage is that, the pre-operation operations that CRM will do will not be carried out in pre-validation stage.

For example:
If you are deleting a record that has many-to-many relationship records with another entity; these relationship records will still be available in pre-validation stage, but not in pre-operation stage.
The same thing happens when deleting a record that has one-to-many relationship with another entity; the lookup field on the other entity will be set to null. So if you query the database to retrieve all records that reference record-to-be-deleted at pre-operation stage, CRM will return 0 result.
For many-to-one relationships however, record-to-be-deleted will still have references to them as they are not the ones being deleted.

 

InputParameters[“Target”]

Target is the entity record that the plugin is executed against. It is late bound, but you can use ToEntity() to convert it into early bound instance. One thing useful to know about this instance is that it only contains “dirty” attributes. Unchanged fields will simply not be there, if you converted to early bound, the value of the attribute will be null.

Please note that setting an attribute to null (removing the value) will result a null valued attribute in the late bound instance, but there is no way to differentiate this in early bound instance.

NB: Markus brought up a very good point that you can treat an early bound entity as a late bound entity by accessing it’s Attribute collection as properties in early bound entities are just helper method. However, keep in mind that treating it as a late bound instance will not generate compile error if you misspelled the attribute name.

Cheers – Sy

Advertisements

4 thoughts on “CRM 2011: Event Execution Pipeline and Target Input Parameters

  1. Hello Sy,

    nice Post, thanks.

    Setting an attribute to null or removing the whole keyvaluepair can be differentiated by working on the AttributeCollection of the early bound instance.

    [TestMethod]
    public void SetEarlyBoundAttributesToNullTest() {
    Account act = new Account();
    act.Name = “helloworld”;
    Assert.IsTrue(act.Attributes.Count == 1);
    Assert.AreEqual(“helloworld”, act.Attributes[“name”]);

    //Clear the value
    act.Name = null;
    Assert.IsTrue(act.Attributes.Count == 1);
    Assert.IsNull(act.Attributes[“name”]);

    //Remove the KeyValuePair
    act.Attributes.Remove(“name”);
    Assert.IsTrue(act.Attributes.Count == 0);
    Assert.IsNull(act.Name);
    }

    1. Hi Markus, Thank you for your post. I think I may have forgotten that you do that when I wrote the post. However, doing that means treating the early bound instance as a late bound instance which has its disadvantages such as no compile check error as the attribute name is hardcoded string.

      I will update my post.

      Cheers – Sy

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s