Plugins in Dynamics 365 : Part 2

Hello Guys,

In my previous blogs i have shown basics of plugins and how you can create a plugin using Visual Studio 2017.Today we are going to learn plugin execution pipeline.But before if you are new to our blog then do follow us to know more about Dynamics and Power Platform. Also if you like our blog then please comment and share this blog with your friends.

The entire plugin pipeline is divided in multiple stages on which you can register your custom business logic.The pipeline stage indicates at which stage of the plugin execution cycle, your plugin code runs.

Out of all the specified pipeline stages in the above picture, you can register your custom plugins only on Pre and Post events. You can't register plugins on platform core main operations.

When you register a step using the Plug-in registration tool you must also choose the Event Pipeline Stage of Execution. Each message is processed in a series of 4 stages as described below:

Pre-Validation:- Stage in the pipeline for plugins that are to execute before the main operation. Plugins registered in this stage may execute outside the database transaction. You can use this stage if you want to implement validation on the data which we will be sending to the database. For example you can check email or phone number is correctly provided or not.This provides an opportunity to include logic to cancel the operation before the database transaction.

Pre-Operation:- Stage in the pipeline for plugins that are to execute before the main system operation. Plugin registered in this stage are executed within the database transaction. If you want to change any values for an entity included in the message, we can do it here. 

Main Operation:- In transaction, the main operation of the system, such as create,update,delete and so on. No custom plugins can be registered in this stage.

Post-Operation:- Stage in the pipeline for plugins which are to execute after the main operation. Plugins registered in this stage are executed within the database transaction. You can use this stage to modify any properties of the message before it is returned to the caller. Don't apply changes to an entity included in the message because this will trigger a new Update event.

Whenever the CRM application invokes an event like saving,updating or deleting a record, following sequence of actions takes place:

• The event triggers a web service call and the execution is passed through the event pipeline stages(Pre-Event,Platform core operation,Post-Event).
• The information is internally packaged as an Organization Request message and finally sent to the internal CRM Web Service methods and platform core operations.
• The Organization Request message is first received by Pre-event plugins, which can modify the information before passing it to the platform core operations.
• After the platform core operations, the message is packaged as Organization Response and passed to the post operation plugins. The post operations plugins can optionally modify this information before passing it to the async  plugin.
• The plugin receive this information in the form of context object that is passed to the execute method after which the further processing happens.
• After all the plugin processing completes, the execution is passed back to the application which triggered the event. 

Plugins are registered through Plugin Registration Tool on Messages or event. For example you can register a plugin on Create message or event of the Contact entity. This would fire the business logic whenever a new contact record is created.

Other messages are Assign,Delete,Retrieve,Retrieve Multiple,Update etc.For default out of the box entities , there are more than 100 supported messages. Some of them are applicable for all the entities while some of them are specific to certain entities.

Hope it helps...