Are you looking for best practices in plug-in development? Are you seeing data inconsistency and slow performance issues in the plug-in intermittently? Are you having problems with CRM 3.0 plug-in showing inconsistent/unknown Data after upgrade? If the answer is YES, please continue reading this article.
A CRM 4 Plug-in is an implementation of the IPlugin interface, which means you need to implement the Execute method, which will be called by CRM when the action gets triggered. Although this may appear straight forward, plug-in performance and thread safety plays a vital role based on our implementation of the plugin infrastructure.
How CRM instantiates the plug-in?
CRM instantiates the Plug-in class on the first activation of the plug-in. CRM will call plug-in’s constructor. Once the object is instantiated, CRM calls the Execute method on the object. For performance reasons, CRM DOES NOT dispose of the object after it completes execution. So CRM caches the object and calls Execute on the same object instance on the next activation of the plug-in. CRM will flush its cache when any properties are changed on the pluginassembly, plugintype, sdkmessageprocessingstep, sdkmessageprocessingstepimage entities for registration. This means that you need to be very careful when defining class-level variables in the plug-in class as multiple threads can execute the code at one time.
Let me explain this with a MyCounter plugin example and show the State-full behavior of the plug-in. Register the following plugin on Account update so that you get a task created on every update of account.
1. Register the Plug-in to trigger on Update of the Account entity
2. Create 2 accounts with last name “Account1” , “Account2”
3. Update Account1 and look at the task that is created. It will show the subject as “Counter Value = 1”
4. Update Account2 and look at the task that is created. It will show the subject as “Counter Value = 2” instead of “Counter Value = 1” for the second task
5. If you update both at the same time, two tasks may potentially be created with same counter value
6. The description of the task will always be “This value is not corrupted” even though the description will have incorrect InputParams if 2 threads fire at the same time.
This proves that CRM only maintains one object in memory and re-uses it every time CRM calls Execute method instead of creating a new instance of the object each time.
CRM 3.0 Callouts: Upgrade issue and data inconsistency (Thread safety)
In CRM 3.0, callouts were instantiated every time for every activation, which means that class-level variables defined in the callout would not be shared across multiple instances of the callout class, since CRM would allocate memory for each instance of the callout and dispose it after execution completed.
For example, the above callout will NOT see data corruption on the EntityXml variable in CRM 3.0. As soon as the callout is upgraded to CRM 4.0, the variable data will be unpredictable. There are a couple of ways to work around this issue.
1. Change the CRM 3.0 callout code NOT to use class-level variables, instead pass the information via method parameters.
2. If it is harder to make these code changes, you can implement a Proxy class that will make the callout stateless. Once you have created the Proxy class, remember to change the callout.config.xml to point to the new Proxy class.
The same Proxy class workaround can be used for the CRM 4.0 Plugins if you really want to use the class level variables to store instance data.
1. Do NOT use Member variables to store instance data.
2. Do NOT use the Member variables as Data Caches as we recycle them based on the load and it might be less efficient if your cache loaders are expensive operations.
3. ONLY read data from class-level during the execution of the plug-in, setting the values in the Constructor..
4. Static Variables are OK as they will be disposed only with the AppDomain.
5. Use Proxy classes if you need to read and write to class-level variables outside of constructor of the plug-in/callout.
6. DO NOT make any assumptions on the plugin instance being cached / not cached
7. Above behavior is for CRM 4
Please add your comments on your experience changing the code and suggestions for improving this in CRM 5.
We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!