This article describes the Microsoft Dynamics 365 (hereinafter referred to as D365) of two concepts, event framework (Event Framework) and event execution pipeline (Event execution pipeline).
This applies to: Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
Note: some of the content of this article may not apply to have the latest D365, translation only for reference and learning.
This link: https://www.cnblogs.com/hhelibeb/p/11086723.html
Original link: https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/gg334361(v=crm.8)
Event framework (Event Framework)
You can extend or customize server functionality by D365 by integrating custom business logic (the code). You can customize the product to support their company's business, you can add new features to the product. Event framework technology allows you to self-development code integrated into the D365 system.
Event framework allows you to create rich vertical and horizontal solutions, by supporting reliable, portable and integrated development of custom business logic to achieve this. Your custom logic integrated into the system, can be performed as part of the main path D365 is executed synchronously or asynchronously in a managed execution queue. The traffic data may be transmitted to your custom code may be performed corresponding action according to the nature of the data, or directly modify the data.
Operational framework provides the following key features:
- An improved business processing subsystem. This subsystem provides a unified approach to the implementation of plugin and workflow, improved reliability, enhanced feature set and plugin portability.
- Event framework API. D365 platform can be extended in the form of plugin and workflow.
- And workflow for deploying a plugin API to the database. It allows you to plugin and workflow automatically distributed to all relevant server data center.
- Synchronous and asynchronous execution of the plugin. D365 plugin synchronous event processing as the main part of a predefined order of execution of the asynchronous queue and plugin is performed independently.
Only D365 server and Outlook client support event framework . For information about D365 Web application extension, refer to Customize Microsoft Dynamics 365 applications
Event execution pipeline (Event execution pipeline)
D365 event processing subsystem performs plugin message pipeline processing model. Called by a user action or other plugin applications, the SDK method yields a message, sent to the organization Web Service. The message contains the service entity information and operation information of the core. The message is passed to the event execution pipeline, through the pipeline, the message can be read by any other platform's core and registered plugin.
Note: Although the D365 platform hosting multiple Web Service, only the events triggered by the organization and OData end will lead to plugin execution.
Architecture and related components
The figure is the overall architecture D365 platform about asynchronous and synchronous event handling,
The event execution pipeline or synchronization events, or asynchronous processing events. Core operating platform and plugin synchronous execution of immediate execution, synchronization plugin to define the good order of execution. Plug asynchronous execution asynchronous queue by the agent (Asynchronous Queue Agent), and executed by the asynchronous service at a later date.
Note: Whether plugin asynchronous or synchronous execution, there is a 2-minute execution time limit. If the timeout, it will have System.TimeoutException exception. For those cases where more than 2 minutes of execution time, consider workflow or other background processing manner. 2 minutes limit only plugin registered under partial trust, also known as the sandbox. For more information: the Plug-in Isolation, Trusts, and statistics
Stage pipeline (Pipeline stages)
Is divided into a plurality of pipeline stages, there may be four or third-party developers to customize plugin. Multiple plugin can be registered in a further stage in the sorting stage.
| Event |
Stage name |
Stage number |
Description |
||
|---|---|---|---|---|---|
| Pre-Event |
Pre-validation |
10 |
In the primary stage of the system before performing the operation. There may be executed outside the database transaction.
|
||
| Pre-Event |
Pre-operation |
20 |
In the primary stage of the system before performing the operation. Executed within a database transaction. |
||
| Platform Core Operation |
MainOperation |
30 |
The main operating system services, such as creating update delete and so on. Custom plugin is not available at this stage. For internal use only. |
||
| Post-Event |
Post-operation |
40 |
Operation performed at the stage after the main system. Executed within a database transaction. |
Safety PrecautionsMessaging
无论何时，当应用代码或workflow调用D365 Web service方法的时候，系统中会发生状态变化，触发一个事件。信息作为参数传输给web service方法，会在内部被包装到一个OrganizationRequest消息，由管道处理。在OrganizationRequest消息中的信息被传输到第一个为当前事件注册的plugin，可以被读取和修改，然后再传输给第二个，以此类推...plugin以context的形式接收消息信息，context被传输到它们的Execute方法中。消息也会传输给平台核心操作。
Plugin注册
Plugin可以注册为在核心平台操作前或后运行。Pre-event注册plugin可以首先接收OrganizationRequest，并在它传输到核心核心操作前对其进行修改。在核心平台操作完成后的消息称为OrganizationResponse。Response被传递给post-event plugin。 Post-event plugin有机会在消息副本被传递给异步plugin前修改消息。最终，响应返回给调用原始web service方法的应用或workflow。
数据库事务
Plugin有可能在也有可能不在数据库事务内执行，这取决于管道如何处理消息请求。你可以通过读取 IsInTransaction属性来检查这点，它继承自IPluginExecutionContext，被传递给plugin。如果plugin在数据库事务内执行，并允许传输异常给平台，整个事务将回滚。阶段20和40保证是数据库事务的一部分，而10有可能是其一部分。
Any registered plugin execution of a transaction in the database returns an exception when the core operating platform will be canceled, resulting in the core operating rollback. In addition, any plugin registration to any pre-event or post event do not run any workflow is triggered by the same event versa.
Reference: http://ashishmahajancrm.blogspot.com/2012/07/microsoft-dynamics-crm-2011-event.html