本文介紹了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，也叫做沙箱。更多資訊： Plug-in isolation, trusts, and statistics
管道階段 (Pipeline stages)
管道被分為多個階段，有4個可以用於自定義開發或者第三方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以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有可能是其一部分。
任何在資料庫事務內執行的註冊的plugin返回異常的時候，平臺會取消核心操作，導致核心操作回滾。此外，任何任何註冊到pre-event或post event的plugin都不執行，任何被相同事件觸發的workflow亦然。
參考：http://ashishmahajancrm.blogspot.com/2012/07/microsoft-dynamics-crm-2011-event.html