At the moment I’m in the middle of writing a series of articles about Document Integration. One of the perks of writing articles is that you have to do a lot of technical research.
This afternoon was such a joyful moment. On my surface I was drawing a sketch of how my solution should be implemented.
Image may be NSFW.
Clik here to view.
Somehow my mind made a wrong turn…. For some reason I was in the assumption that I had to do automatic provisioning of plugin steps. For each entity that was going to be selected to offer document support, I was about to register a new plugin step.
One of the cool things of CRM is that everything is stored inside the database. Plugins, plugin steps, data… everything! With that knowledge in the back of my mind I started to do some investigation.
My goal was to find out if Dynamics CRM supports dynamic (de)provisioning of plugin steps. To make a long story short.. Yes CRM 2015 supports dynamic provisioning of plugin steps (tested in sandbox mode).
Eventually it turned out that my Document Integration solution does not need this kind of goodness. Nevertheless, I want to share this with you….
Instead of having to reinvent the wheel, I browsed the internet to see if someone nailed this problem before. Fortunately on the Dynamics Communities someone wrote a really fancy class to (un)register plugin steps.
I decided to use that code and I wrote a small sample around it.
What I did, was writing two plugins. In the first plugin (I implemented it on Account) I wanted the new plugin step to be registered. I also created a second plugin (PluginRegistration.TestPlugin). Then I took it a bit further, and decided that I wanted the first plugin to register the same plugin step on multiple entities. At the end of the article I’ll provide a download link, containing all sources.
In the plugin I wrote the following code. In this example I use the base class that I developed in the “Plug-ins 101: Simplifying plug-in development” series.
Image may be NSFW.
Clik here to view.
The second plugin I wrote was a bogus plugin. Just to find out if the magic was happening. Once compiled, it was time to register the new plugin.
Image may be NSFW.
Clik here to view.
On the PluginRegistration.AccountPlugin I register a plugin step that fires on the post create event. The plugin “pluginRegistration.TestPlugin” does not get any steps to process.
Image may be NSFW.
Clik here to view.
In the initial run, I added a new account. Forcing the “PluginRegistration. AccountPlugin” to fire. In that plugin event I registered a step on the second plugin. In the image below you see the dynamic created plugin step.
Image may be NSFW.
Clik here to view.
I changed my code a bit, dropped all plugin steps on the “PluginRegistration. TestPlugin”, updated the plugin and added a new account. This time, not one, but two plugin steps were created on the “PluginRegistration.TestPlugin”. Amazing!
Image may be NSFW.
Clik here to view.
I decided to find out if the dynamic added plugin step would fire as well. As the new plugin step was created on Contact, I decided to add a new contact. As soon as I saved the new contact, a breakpoint kicked in.
Wow! The dynamicly added plugin step works like a charm.
Image may be NSFW.
Clik here to view.
Too bad I don’t need this code for my Document Integration project. However I thought it was too cool to throw it away.
I put up the sourcecode of this sample for your convenience… File Attachment: PluginRegistration.zip (13 KB)
Sometimes it is quiet fun to get on the wrong track. Testing the code I realized that for the Document Integration solution, I need to (de)provision the ribbon button dynamically. A challenging task.
No time to waste.