| Mohsin Ahmed
In this blog, we will be learning about the event framework of Microsoft Dataverse as well as the event execution pipeline and how it relates to plugins.
If we want to extend the default functionality of Microsoft Dataverse or Dynamics 365, then we need to attach our custom code on events triggered through Dataverse operations. The Event Framework enables us to achieve this.
‘Events’ or ‘Messages’ (used interchangeably) are the building blocks of all data operations performed in Dataverse. Each data operation in Dataverse is based on a specific message. Some common messages include Create, Retrieve, Update, Delete, Associate and Disassociate. Some other messages are also available for advanced operations and custom actions such as qualifying a lead or closing an opportunity.
Now that we know the messages upon which we can register our custom code plugin, thus we should also learn about the message execution pipeline and its stages. Whenever we register a plugin on any message and entity combination, then we also need to specify the stage of message execution at which we want to bind our custom code execution. There are 4 stages in the event execution pipeline which are as follows:
- Pre-Validation This stage occurs before the main system operation and outside the database transaction. This stage is ideal to perform any validation and provides an opportunity to cancel the main system operation in case of validation failure. We can cancel the system operation by throwing InvalidPluginExecutionException in code while providing a relevant message to the user explaining the cause of operation validation failure. One important detail to keep in mind is that this stage of execution occurs before the system performs security checks to verify if the calling user has the required role and permissions to perform the desired operation.
- Pre-Operation This stage also occurs before the main system operation but is part of the database transaction. Any uncaught exceptions in this stage of execution will result in rollback of the database transaction which includes the main system operation. This stage of execution is ideal to make any field changes to the entity object received in the message. It is strongly advised that the main system operation should not be cancelled at this stage of execution or any subsequent stages as this will result in rollback of database transaction and have significant performance penalty.
- Main-Operation This stage contains the main system operation and is part of the database transaction. This stage is for internal use only. Avoid including any custom code in this stage unless one is dealing with custom API and custom virtual data providers.
- Post-Operation This stage occurs after the main system operation but is still part of the database transaction. Any uncaught exceptions in this stage of execution will result in rollback of the database transaction which includes the main system operation. This stage of execution is ideal to modify any properties of the message that is returned to the caller after the main system operation. It is strongly recommended to not make any changes to the calling entity at this stage of execution as this will trigger a new update event which will have its own event execution pipeline. This stage also provides an opportunity to register custom code steps which run in an asynchronous fashion using the asynchronous service. The main advantage of having asynchronous steps is that those steps are carried out outside of the database transaction and will not interfere with the main system operation.
And that is all for the event execution pipeline. The choice of any stage of event execution pipeline to register your plugin steps depends totally on the business logic and use-case. So, make a wise choice!
Join us next time, as we continue our journey of learning canvas apps.Click here to learn more about Imperium's Power Apps Services. We hope this information was useful, and we look forward to sharing more insights into the Power Platform world.
