Best Practice

Yesterday I just discovered from a discussion of a question, what I’ve known in a couple of years is not the best practice. The question was about how to get the entity attribute values from the record where the plugin was fired. Based on my previous knowledge, it should part of the plugin execution context. Yes, it is true for some operations such as Create and Update (based on the fields that updated). However, my next approach: if I could not find it in the plugin context: get it through retrieve request, is completely wrong. It adds server overhead when I add another request just to get the entity attribute details.

After reading this MSDN article: “Understanding the data context passed to a plug-in“, there is a line under Pre/Post Entity Image section that mentioned: “Registering for pre or post images to access entity attribute values results in improved plug-in performance as compared to obtaining entity attributes in plug-in code through RetrieveRequest or RetrieveMultipleRequest requests.”

I’ve used the pre and post image to tackle some situational requirements, but now I know that what I’ve done was not right. It is probably an obvious or a well-known knowledge for most of the developers, but in case there are others that still using bad pattern as I do (I learned it from others’ sample as well), I hope this could change the development pattern and deliver the most efficient way in plugin development.

Recently I upgraded one of my virtual machine with Dynamics CRM 2011 to Dynamics CRM 2013. That instance contains my old solutions from previous learning and testing. One of the solution contains several plugins to be triggered on Update request.

With the new auto-save feature in Dynamics CRM 2013, any modification to the form will be automatically saved every 30 seconds or when the user navigated away from the from (click other records or navigate to different page).

There was an unexpected performance issue every a couple seconds (30 seconds to be exact) when I was working with the new CRM 2013 form. After I traced the source of the problem, it was coming from the plugin that triggered every 30 seconds by the auto-save. The new auto-save functionality will trigger the plugin because I was not filtered the plugin on the required fields (attributes). This problem never happened on CRM 2011 as the update request will only be triggered through “Save” button with manual user interaction.

I think it is a best practice to filter the update plugin to only be triggered on the related attributes, to achieve that:

Method 1: through Plugin Registration Tool, on the step registered: