Dynamics CRM Product. Plugin strategy.

Plugin strategy. Managed Steps Concept.

          Most of modern products (managed solutions) for Dynamics crm, those we import into our environments, have some ways to be configured. By creating “setting” entity, Azure configuration for marketing solutions, changing templates or workflows. If we deal with off-line then workflow is not an option any more, but plugins are. In case of plugin we deal with hardly configurable component and have not many options to work around. Disable step, use unsecure/secure configuration (if vendor gives us such option), ask vendor for patch. This sort of workarounds.

          Managed Steps Concept is an approach for dynamics crm plugins architecting and coding. Vendors can utilize it to improve products maintenance and make it more client friendly.

          The proposed design is useful for any organization making products for Dynamics Crm (no version limitations). This approach is also good for fast fixes/reconfiguration in projects. Level of configurability depends on the way you implement the concept.

          The idea is to set flags on in first plugin step in pre-create stage of an entity via PluginExecutionContext’s Shared Variables property. It is “… a parameter collection of custom data values in the execution context that is passed through the pipeline and shared among registered plug-ins, even from different 3rd party developers.” (https://msdn.microsoft.com/en-us/library/gg328579.aspx ). The collection can help to manage registered plugin’s steps execution order, execution logic and parameters.

     Originally I’ve created Managed Steps Concept (MSC) once we needed a manageable chain of plugin steps for a new product. Later, thinking about the limitation of configuring plugins in third party solutions, the idea of “manager plugin step” (setter) and its “heirs” or “followers” came up.   

Let’s have a look on the chain of plugin steps from pre-validation or pre-create to post-update with Managed Steps Concept implementation.

       1.       First step. 

    It’s a “dry run” plugin on pre-validation or pre-operation. This step will set flags/parameters/logic dependencies via Shared Variables for all steps those are involved and listening to the commands.

Here a few options how set up the logic: 

         -          Validation or calculation based on entity/crm data

         -          Hard coded

         -          Passing parameters via plugin constructor, secure/unsecure parameters (PluginRegistration Tool)

         -          Dynamic Parameters. Most promising way from generic development perspective.

         The primary entity should have parameter holder/s (dedicated fields).

         The fields value can be set/changed with JavaScript, workflow, manually etc.

         This approach allows make plugin steps execution record specific.

 -         Create a custom entity holding logic details per entity, step, message ...

        2.       Sub steps. 

    Each step execution starts by parsing and analyses of Shared Variables. Then code acts based on programmed logic or passes to next step.

Sub steps could change logic too based on various conditions. Up to me, changing the logical schema on fly is a dangerous scenario due to possible logical collisions and complex maintenance. In the other hand, Microsoft created Shared Variables to solve complex logic scenarios.

The next diagram shows how architect and developer can override or change logic after product was deployed to customer. The change will not affect original code.

Here are some considerations you might have selecting this design to implement:

Advantages	Disadvantages
Most important from Product perspective is ability to override original plugins logic with logic that customer need. Or change/override the logic partially. Or add your logic to plugin steps chain.	Number of classes (and steps) gets at least doubled.High level of code specification is required. For instance, registering of same plugin class to a few stages or messages is not allowed. To reduce code duplication have only logic in plugin class and all processing in generic classes.
Easy maintenance of customer changes. The concept does not require to unregister or change original steps hence vendor updates will never harm customer’s logic.	Action logic that provided by Shared Variables must be very good described and documented. Otherwise you or your customer might have a hard time to change or reconfigure it.
Depend on implementation, you can configure your plugin same way you configure processes
A supported solution. Share Variables exist since first crm version
Cheap, easy to implement