CRM 2015: Enhance Your Plugins by Using Shared Variables

Printer-friendly version

While it is commonly suggested that IExecutionContext.Depth should be used to prevent infinite loops in your plugins, IExecutionContext.SharedVariables can give you finer control over what your plugins are doing, in certain cases. Even better, Shared Variables provide a way to pass values from one plugin to another, as long as they’re in the same sequence of steps for a particular message. For instance, the example below (from the MSDN article, Pass data between plug-ins) shows how to set a Shared Variable in the pre-event step and access it in the post-event.

    public class PreEventPlugin : IPlugin

    {

        public void Execute(IServiceProvider serviceProvider)

        {

            // Obtain the execution context from the service provider.

            Microsoft.Xrm.Sdk.IPluginExecutionContext context = (Microsoft.Xrm.Sdk.IPluginExecutionContext)

                serviceProvider.GetService(typeof(Microsoft.Xrm.Sdk.IPluginExecutionContext));

 

            // Create or retrieve some data that will be needed by the post event

            // plug-in. You could run a query, create an entity, or perform a calculation.

            //In this sample, the data to be passed to the post plug-in is

            // represented by a GUID.

            Guid contact = new Guid("{74882D5C-381A-4863-A5B9-B8604615C2D0}");

 

            // Pass the data to the post event plug-in in an execution context shared

            // variable named PrimaryContact.

            context.SharedVariables.Add("PrimaryContact", (Object)contact.ToString());

        }

    }

 

    public class PostEventPlugin : IPlugin

    {

        public void Execute(IServiceProvider serviceProvider)

        {

            // Obtain the execution context from the service provider.

            Microsoft.Xrm.Sdk.IPluginExecutionContext context = (Microsoft.Xrm.Sdk.IPluginExecutionContext)

                serviceProvider.GetService(typeof(Microsoft.Xrm.Sdk.IPluginExecutionContext));

 

            // Obtain the contact from the execution context shared variables.

            if (context.SharedVariables.Contains("PrimaryContact"))

            {

                Guid contact =

                    new Guid((string)context.SharedVariables["PrimaryContact"]);

 

                // Do something with the contact.

            }

        }

    }

One catch, however, is that the way you access the stored Shared Variable can change, depending on which stages are used, as described in the same article:

“For a plug-in registered in stage 20 or 40, to access the shared variables from a stage 10 registered plug-in that executes on create, update, delete or by a RetrieveExchangeRateRequest, you must access the ParentContext.SharedVariables collection. For all other cases, IPluginExecutionContext.SharedVariables contains the collection.”

What this means is that if the Shared Variable is being set during Pre-Validation, you need to look at the Parent Context to find it when retrieving it in a Pre-Operation or Post-Operation step. It may not be in the immediate Parent Context either; you may need to check each parent’s parent to find where the Shared Variable has been stored. 

Finally, you cannot currently share variables between steps using different messages and/or entities, even if one triggers the other. For instance, let’s say that we have a plugin that executes when an Account is updated and that this plugin updates associated Contacts. Let’s also say that we have another plugin that gets triggered when the Contact is updated, so we have a case where the Account update plugin triggers this Contact update plugin. You’d see that the IExecutionContext.Depth for the Contact plugin is set to 2, but the Shared Variables you set in the Account plugin will not be available to the Contact plugin.

About the Author:

TopLine Strategies delivers the complete integration and development of sales, marketing and customer service technologies that enable corporate clientele to improve revenue streams and strengthen customer interactions. Our project management and consulting is designed to achieve timely delivery, 100 percent user adoption of the technologies we implement and deliver measurable returns on investments for our clients.

Comments (0)

Related Blogs

TheReact Native Open Source roadmap was announced in Q4 2018 after they decided to invest more in the React Native open source community.

October is not just about pumpkins, fall foliage, and cooler temps anymore. October 2018 also means the exciting introduction of Microsoft Dynamics 365 for Customer Engagement.

Back in 2016, Microsoft introduced its intentions to refresh its CRM and ERP strategy with Dynamics 365. At the heart of its services was the Common Data Model (CDM).