Getting Attribute Values in Plugin Execution Best Practice: Use Pre/Post Images

January 16, 2015 Andre MargonoBest Practice, Lesson Learned, Microsoft CRMBest Practice, Plugin

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.

Real Time Workflow and Plugin, Which One is Executed First?

October 14, 2014October 14, 2014 Andre MargonoCRM 2013, Dynamics CRM 2013, Microsoft CRMExperiment, First Come First Serve, Plugin, Workflow

Last weekend when I was preparing my presentation slide for the upcoming Dynamics CRM User Group regarding some gotchas in plugin development and with a short discussion regarding Real Time Workflow, there is a question in mind: If there is a Plugin and Real Time Workflow that registered on the same event, for example on update of field A on Contact entity, which one that triggered first? I’ve tried to find Microsoft’s documentation and could not find it, so in case anyone could point out the article/documentation, please let me know.

So to answer my own question, I setup a simple Real Time Workflow to update ‘jobtitle’ field to ‘Workflow’ on Contact entity every time I change the first name. And a plugin to update ‘jobtitle’ field to ‘Plugin’ on Contact entity every time I change the first name. To test this method, I did a bulk edit on contact record to change all their first name. And the result is… Plugins are executed first, then the Real Time Workflow. This is a conclusion of the test, as all of the records that I just bulk-edited has the value of Workflow, which mean the value specified will be the one that executed later.

I hope this help us in designing the solution with multiple event-based processes. And to manage these execution order there’s a plugin for the famous XrmToolbox here: http://mscrmtools.blogspot.com.au/2014/04/new-xrmtoolbox-plugin-synchronous.html

Note: I personally would prefer not to mix Plugin and Real Time Workflow together to avoid confusion by putting the custom process that handled by the plugin to custom workflow activity and execute that custom workflow activity within the Real Time Workflow. However, there might be a case where the solutions are developed by multiple vendors and this kind of scenario could happened.

Set Filter Attributes – Update Plugin – Dynamics CRM 2013 Upgrade Gotcha

May 1, 2014 Andre MargonoUncategorizedBest Practice, Dynamics CRM, Plugin, TIPS, Upgrade

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: