本文介紹了Microsoft Dynamics 365（以下簡稱D365）中的兩個概念，事件框架（Event Framework）與事件執行管道（Event execution pipeline）。
本文適用於：Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
注意：本文的一些內容可能已經不適用於最新的D365，翻譯只為參考、學習。
本文鏈接：https://www.cnblogs.com/hhelibeb/p/11086723.html
事件框架（Event Framework）
在D365中你可以通過集成自定義業務邏輯（代碼）來擴展或自定義服務器的功能。你可以自定義產品來支持自己公司的業務，可以向產品添加新的特性。事件框架技術允許你將自開發代碼集成到D365系統中。
事件框架允許你創建豐富的垂直和水平解決方案，它通過支持可靠、便攜的開發與集成自定義業務邏輯實現這點。你的自定義邏輯在集成到系統中后，可以作為D365主要執行路徑的一部分被同步執行，也可以在一個托管隊列中異步執行。業務數據可以傳輸到你的自定義代碼中，可以根據數據的性質執行相應的action，或者直接修改數據。
事件框架提供以下關鍵特性：
- 一個改進的業務處理子系統。該子系統提供了執行plugin和workflow的統一方法，改善了了可靠性、提供了增強的特性集和plugin的可移植性。
- 事件框架API。可以以plugin和workflow的形式擴展D365平台。
- 一個用於部署plugin和workflow到數據庫的API。它使你可以將plugin和workflow自動分發到數據中心的所有相關服務器上。
- 同步和異步的plugin執行。同步plugin作為主要的D365事件處理的一部分以預定義的順序執行，異步plugin被隊列化並獨立執行。
只有D365 server和Outlook客戶端支持事件框架。有關擴展D365 Web應用的信息，可以參考Customize Microsoft Dynamics 365 applications
事件執行管道（Event execution pipeline）
D365的事件處理子系統會基於消息管道處理模型執行plugin。由plugin或其它應用調用的用戶action、SDK方法會產生一個消息，發送給organization Web Service。消息包含業務實體信息和核心操作信息。消息被傳遞給事件執行管道，通過管道，消息可以被平台核心和其它任何注冊的plugin讀取。
注意：雖然D365平台托管了多個Web Service，只有由organization和OData端觸發的事件會導致plugin執行。
架構和相關組件
下圖是D365平台中有關異步和同步事件處理的整體架構，
事件執行管道要么同步處理事件，要么異步處理事件。平台核心操作和同步執行的plugin會立即執行。同步的plugin以定義好的順序執行。異步執行的插件由異步隊列代理（Asynchronous Queue Agent）隊列化，並在晚些時候由異步服務執行。
注意：不管是異步還是同步執行的plugin，都有一個2分鍾的執行時間限制。如果執行超時，就會產生System.TimeoutException異常。對於需要超過2分鍾的執行時間的情況，考慮使用workflow或其它后台處理方式實現。2分鍾限制只對在部分信任下注冊的的plugin有效，也就是只對被部署到沙箱的plugin有效。更多信息： Plug-in isolation, trusts, and statistics
管道階段 (Pipeline stages)
管道分為4個階段，其中3個可以用於自定義開發或者第三方plugin。在階段內注冊的多個plugin可以進一步在階段內排序。
| Event |
Stage name |
Stage number |
Description |
||
|---|---|---|---|---|---|
| Pre-Event |
Pre-validation |
10 |
在主系統操作前執行的階段。有可能在數據庫事務外執行。
|
||
| Pre-Event |
Pre-operation |
20 |
在主系統操作前執行的階段。在數據庫事務內執行。 |
||
| Platform Core Operation |
MainOperation |
30 |
系統主操作事務，比如創建更新刪除等等。自定義plugin無法使用這個階段。它只用於內部使用。 |
||
| Post-Event |
Post-operation |
40 |
在主系統操作后執行的階段。在數據庫事務內執行。 |
安全注意事項消息處理
無論何時，當應用代碼或workflow調用D365 Web service方法的時候，系統中會發生狀態變化，觸發一個事件。信息作為參數傳輸給web service方法，會在內部被包裝到一個OrganizationRequest消息，由管道處理。在OrganizationRequest消息中的信息被傳輸到第一個為當前事件注冊的plugin，可以被讀取和修改，然后再傳輸給第二個，以此類推...plugin以傳遞給它的Execute方法中的context的形式接收消息信息。消息也會傳遞給平台核心操作。
Plugin注冊
Plugin可以被注冊為在核心平台操作前/后運行。Pre-event plugin可以首先接收OrganizationRequest，並在它傳輸到核心核心操作前對其進行修改。核心平台操作完成后的消息被稱為OrganizationResponse。Response被傳遞給post-event plugin。 Post-event plugin可以在消息副本被傳遞給異步plugin前修改消息。最終，響應返回給調用原始web service方法的應用或workflow。
數據庫事務
Plugin有可能在數據庫事務內執行，也有可能不在，這取決於管道如何處理消息請求。你可以通過讀取 IsInTransaction屬性來檢查這點。IsInTransaction繼承自IPluginExecutionContext，會被傳遞給plugin。如果plugin在數據庫事務內執行，並傳輸異常給平台，整個事務將回滾。階段20和40保證是數據庫事務的一部分，而10有可能是其一部分。
任何在數據庫事務內執行的注冊的plugin返回異常的時候，平台會取消核心操作，導致核心操作回滾。此外，任何注冊到pre-event或post event的plugin都將不運行，任何被相同事件觸發的workflow亦然。
參考：http://ashishmahajancrm.blogspot.com/2012/07/microsoft-dynamics-crm-2011-event.html