Hello everyone and welcome back to this Microsoft Dynamics 365 planning development course. This is module number two that is fundamentals of plug in development and in this video under understand event execution pipeline. In the previous video we have understood what is an event framework in dynamics 365 in this video we will understand what is event execution pipeline in dynamics 365 as we have already seen that with dynamics 365 for customer engagement apps you have the ability to extend or customize the functionality of the server through integration of your custom business logic and in previous video we have seen that dynamic 365 platform gives you only three places where you can register your custom business logic B that is Pre Validation stage and prove your presence there. And lastly after the core operation at post operation stage in elements 365 so let us know understand how we can reduce it by playing so whenever you perform an action on dynamics 360 supported claims that we in turn subscribe to an event and that will be handled by a Web service called organization web service which is part of the mix 365 server and even pipeline allows you to configure then in the even plugin code we execute. So let us know understand this within helpful background. So what happens on the server when you perform an operation on dynamics 365 planes. So whenever you take an action on dynamics 365 client then it will subscribe to an event event will be handled by organization web service. Observers will create and or organization Web Service Request object that will be passed to a pre validation stage and in privileges and stage the dynamics 365 server first will check. Are there any plugin registered in previous editions that that matches the context message type an entity for which the event has been raised. If the server does not find any such plugins then it will update the organization web service request method and and passes that updated request method to the next stage. But let us suppose if there are any plugin register that matches message type and entity for which David has been raised then it will first execute that plugin code under the user context for which the plugin is registered and after its execution is completed. Then again it will update the organization web service request message and that update request message will be passed on to next stage. And once your pre relegation stage is completed then your database transaction starts on dynamics 365. So the first stage in database transaction is pre operation stage so pre operation stage will receive that updated Web service request message then it again it will first check. Are there any plugin registered on your present stage which matches the context that is next step. An entity for which that event has been raised. If the server does not find any such plugin then it again updates the organization web service request message and passes that updated request method to the next stage. But if the server finds there are such plugins registered in your presence did that the entity date then it will first execute that plugin under the user context for which the plugin is registered and then if the context do here is having all the required access on the data all the attributes that are present in your custom code. If user does not have access to any one of the attributes or the field that is being utilized in your plugin code and the context entity then it will raise an insufficient privileged exception and that exception will be passed in the response data and that response discovered in the exception along with any profiling data and passes that response data along with the exception back to the dynamics 365 Clint. Let us suppose if user is having all required access to the entity and attributes then it will update the organization web service and passes that updated with web service request. Message to the next stage. So here you need to understand that the first time when the security check is performed is pre operation stage. While on revaluation stage there are no set security where it isn’t carried out. This is simply because of the fact that all your required access and privileges information are stored in a database. So it is why the first time when the user security related checks out from the pre operation stage not in the pre validations took what happens next. So the determination of observers request messages passed on to the main or pressing stage where it will check if there are any impersonation already in place. That means impersonation concept. We are going to see no relevance to plug in concept but just for your understanding. I’m making it very simple that whenever the logged in user has granted some other user who act on his behalf those kind of permissions you can send in denim exclusive to print. So if the logged in user has set any such permissions then it will it will apply the impersonation and then the impersonated user then the platform will check the impersonated user has access to all the required entities and attributes within the scope of plugin. Then if user does not have adequate access to all the entities and attributes then it will again raise the insufficient privilege exception and that exception will be passed in the response message along with the exception details and profiling that I if any and that will response message will be sent to the beta 6 different link. The user has all required access to the entity and its attribute. Then the system will process on the organization request message and in turn it will generate a response out of it. The main or present stage is where the platform will process the organization web service request and then written response out of it. So now that the response message will be passed to the next day. That is post operation state yes. The platform will first check what is the type of the plugin. If the plugin is asynchronous then that response message will be passed to the asynchronous queue and it will create a system job in the dynamic 360 for instance and that system will be handled by the asynchronous service of the dynamics 360 server. If the plugin is think runner then again the platform will project are there any plugin registered in post operation state which matches the message type an entity for which the event has been raised. If the platform does not find any such plugins then it will update the organization website with response message and that updated response message will be possible to the dynamics 365 web service client. But if there are such plugins found in the system then it will execute that plugin code under the user’s context for which the plugin is restored and then it will check if the user is having access to all required and it is in attributes that are in the scope of that plugin. If user does not have such privileges then again the platform we raise in insufficient privilege exception and that exception details will be passed into the response date along with the profiling data and that will be sent back to the client. But if user is having all required access to the entity and attributes within the scope then it will again update the organization web service response message and that updated response message will be passed back to the dynamics through six different plaint. And this is what happens actually on the dynamic 365 server whenever an event has been raised in dynamics 365 plan. Now you got the complete picture. What is an event execution pipelines and what happens on the server whenever an event has been raised in dynamics 365 or that is all about this video. I thank you for watching it and in your next video we will start with the plugin basics theory we’ll see you all in the next week.