Develop your first Plugin from Scratch| Dynamics Customer Engagement (CRM)2016
In this article, we will explain how to develop plugins in Dynamics Customer Engagement(CRM) 2016. Plugins are basically used to extend the standard behaviour of Dynamics Customer Engagement(CRM) application. The next article Register Plugin using Plugin Registration tool explains how to register plugin assemblies using Plugin registration tool.
This video attached demonstrates how to develop your first plugin from scratch step-by-step.
Lets first have a look at what plugins are:
Basics of Plugins in Dynamics Customer Engagement(CRM) 2016
A plug-in is basically a custom business logic (code) that you can integrate with Dynamics Customer Engagement(CRM) to modify or augment the standard behaviour of the platform. Or in other words, Plugins are event handlers for the events fired by Microsoft Dynamics Customer Engagement(CRM).
You can register plug-in code against events using Plugin registration tool or using Solutions.The plug-in runs in Customer Engagement(CRM) server(s) synchronously or asynchronously depends on how they are registered with the Customer Engagement(CRM) server.
When to use plugins
Let’s have a comparison between Plugins and JScript.
Plugins vs. JScript
When Server-side execution of business logic is needed.
Plugins vs. Workflows
- Workflows can be used trigger only for a limited number of messages( events).
- Plugins can be executed for almost all of the messages of Customer Engagement(CRM) system and can be synchronous and Asynchronous.
- When performance is a consideration.
Event Execution Pipeline
Dynamics Customer Engagement(CRM) event processing subsystem executes plug-ins based on a message pipeline execution model.A user action in Dynamics Customer Engagement(CRM) application or an SDK method call results in a message being sent to the organization Web service.
The message contains business entity information and core operation information. The message is passed through the event execution pipeline where it can be read or modified by the platform core operation and any registered plug-ins.
Event Execution Pipeline Stages
Event pipeline allows configuring when in the event the plug-in code will execute.
The event pipeline is divided into the following events and stages:
- Platform Core Operation
Event Execution Pipeline Stages in Detail
- This stage executes before the basic validation.
- Therefore, it would be possible to trigger the plug-in code even without the user actually having permission to do so.
- Also, execution in this stage might not be part of the database transaction.
- This stage executes after validation, but before the changes have been committed to the database.
- This is one of the most commonly used stages.
Platform Core Operation
- This stage is the in-transaction main operation of the system, such as create, update, delete, and so on.
- No custom plug-ins can be registered at this stage. It is meant for internal use only.
- This stage executed after changes have been committed to the database.
- This is one of the most used stages.
Plug-in Message is the triggering event, such as Update or Create. There are hundreds of these. The Customer Engagement(CRM) SDK has a list of them all in SDK/message-entity support for plug-ins.xlsx.
Here are some of the most commonly used messages:
Triggered when the record is created. All set attribute values are included in the target entity.
Triggered when the record is updated. You can define which attribute updates trigger the plug-in, by defining the filtering attributes. Also, only the updated attribute values are included in the target entity (see images)
Triggered when the record is deleted.
Triggered when the record is retrieved, for example when the user opens a record on a form.
Triggered when a recordset is retrieved using RetrieveMultiple, for example showing a view.
Let’s get into the development of plugins now. Basically plugin development includes the following steps.
- Plugin Development
- Plugin Deployment and Registration
- Debug Plugin
Plug-ins are custom classes that implement the Plugin interface.You can write a plug-in in any .NET Framework compliant languages such as C# and VB.NET.
You must add Microsoft.Xrm.Sdk.dll and Microsoft.Crm.Sdk.Proxy.dll assembly references to your project. These assemblies can be found in the SDK\Bin folder of the SDK.
IServiceProvider parameter of the Execute method is a container for several service objects that can be accessed within a plug-in. The service provider contains instance references to the execution context, IOrganizationServiceFactory, ITracingService and more.
The execution context contains information about the event that caused the plug-in to execute and the data contained in the message that is currently being processed by the pipeline.
Data context passed to a plug-in
When a plug-in is run for a pipeline event for which it is registered, the plug-in’s Execute method is called.
That method passes an IServiceProvider object as a parameter, which contains a number of useful objects.
IPluginExecutionContext contains information that describes the run-time environment that the plug-in executes, information related to the execution pipeline, and business entity information.
The context is contained in the System.IServiceProvider parameter that is passed at runtime to a plug-in through its Execute method.
To access the Microsoft Dynamics Customer Engagement(CRM) organization service, it is required that plug-in code create an instance of the service through the ServiceProvider.GetService method.
InputParameters contains data that is in currently being processed by the event execution pipeline. Your plug-in code
One property of CreateRequest is named Target, which is of type Entity. This is the entity currently being operated upon by the platform.
Also Read: Register Plugin using Plugin Registration Tool