During a recent Dynamics CRM 2011 code review engagement, I noticed a pattern being implemented repeatedly throughout the customer's plug-in library. This library was in desperate need of a refactor in the form of a method that encapsulated the repeated pattern. In my assessment report, I provided them a suggested method refactor which could eliminated hundreds of lines of redundant plug-in code. Keep reading and I'll provide you this same method to put in your coding arsenal.
The pattern I identified sought to incorporate the values from pre-event entity image snapshots when evaluating the primary entity's attribute values. We most often see this scenario for pre-event Update message plug-in code. The need for such a pattern is dictated by the nature of the Update message where the entity submitted only contains the attributes to be updated. Makes perfect sense…until you are executing within the event pipeline and need to evaluate a condition based on another attribute of the entity that may or may not have been submitted with the update.
Enter pre (and post) event image registrations. Event images provide a snapshot of the primary entity prior to (or after) the requested operation. This capability allows you to have broader context about the entity state without having to incur unnecessary retrieval of the primary entity from within your plug-in operation. Nevertheless, having this additional context means that you have two potential sources for the value of an entity attribute. Handling this unique situation requires additional logic to determine the appropriate value. The logic goes something like this:
First, let's take a look at how this logic is often implemented in code.
Next, we'll take the logic implemented above and encapsulate it in a method. I chose an extension method in this case to provide fluent companion to the standard Entity.GetAttributeValue<T>(string attributeLogicalName) method.
How does incorporating our new extension method impact the original code? As shown below, each instance of executing this logic has been reduced to a single line of code. Implement this logic even a few times in a single plug-in and the reductions add up quickly.
Remember, if logic is worth repeating, it’s worth implementing once as a method!
Please let us know if the timing is right to explore a Code Review service engagement for your CRM solution or if you’re interested in becoming a Microsoft Premier Services customer.
Microsoft Premier Field Engineer
For me as a newcomer this would a good article to learn. Thanks.
Clever! Nice article!
It was a nice article any good response from every one. Instead if 4 to 5 lines we can check the attribute is exists or not by using extension method.
I have a question. Why it is not providing the entire form values instead of the changing attribute.
Raju, it only provides the changed attributes for each target to reduce the message size and it reduces certain data conflicts (there's really no need to pass that data anyhow). And this is exactly why the plugin images exist - to allow you as the developer to take control and keep the right data coming into your plugin no matter what data was changed (if needed). Also keep in mind you can set the ForceSubmit for fields on the form if you need the value to be submitted down from the form every time (versus every single time the platform message is fired no matter where the source is).
Let us know if you have any more questions on this. Thanks!
looks like CRM online doesnt like T
@qq - Can you clarify what you're experiencing?