Plug-in related topics

A plugin is a physical dll and it contains a .Net class. To create a plugin, we register a step (Configuration which identifies what action will take place). After registering the step we select an image (copy of data on which we will run our business logic), which can be pre-image or post-image.

Sandbox Mode:

• If a plugin is registered in Sandbox mode then it  runs in a restricted environment or in .Net terms we can say partial-trust model.
• It makes sure that if due to some reason plugin crashes then it does not bring entire server or service (in case of IIS) down.
• In CRM online, plugins can be deployed in sandbox mode only.
• In On-premise deployment, only user with deployment manager role can deploy plugin in non-sandbox mode.

Synchronous and Asynchronous mode:

If any error occurs in sync mode then it will show error to user. However if any error occurs in async mode then it will log error into system job.

Pre-Image: You select this option when you wish to do operation before data has been sent to database, ex: in process of update and delete.

Post-Image: You select this option when you wish to do operation after data has been sent to database and it has been modified, ex: in process of create and update.

Plugin Messages: These messages can be found in SDK in: “message-entity support for plug-ins.xlsx“.

ex: Create, Update, Delete, Assign etc.

Plugin Stages:

Plugin Depth:

Depth is the number of times a plugin/custom workflow has been called in one transaction.

It is often used to stop infinite loops where a plugin updates a value which triggers the plugin to run again. When a plugin/custom workflow triggers another plugin/trigger then the depth property is incremented by one. The depth value has a maximum value called WorkflowSettings.MaxDepth.  This is set to maximum depth of 8 within one hour.

ParentContext:

When a plugin is triggered by another workflow/plugin then ParentContext has value otherwise it would be null. This can be useful if you want to know if your plugin was triggered by a CRM form update or triggered from another plugin.

Infinite looping in plugins:

• A post plugin triggered on update of contact name.
• Plugin retrieves target entity
• plugin updates name field on target entity field to name + 1234
• plugin does CrmService.Update (target entity)
• Plugin has updated field value which triggers plugin again

This calling of plugin again and again is called the infinite looping. So to avoid infinite looping due to bad code practice and recursive calling of plugin can be resolved by following sample:

The code above is checking to see if the context.Depth is greater than one. If a plugin is triggered from a record being saved then the context.Depth = 1 (it has been run once). If the plugin called itself again the depth would then be incremented to 2.

Passing data between plug-ins:

“SharedVariables” is the name of variable which is used to pass information between plugins. This is a collection of key\value pairs. At run time, plug-ins can add, read, or modify properties in the SharedVariables collection.

This feature is to communicate information between a plug-in registered for a pre-event and a plug-in registered for a post-event. It is also important that any type of data added to the shared variables collection be serializable otherwise the server will not know how to serialize the data and plug-in execution will fail.

• In the pre-event you can add data to SharedVariables:

context.SharedVariables.Add("PrimaryContact", "xxxxxxxxxxxxxxxxxxx");

• In the post-event you can fetch the SharedVariables data as follows:

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