Dynamics 365中的事件框架與事件執行管道（Event execution pipeline）

本文介紹了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，翻譯只爲參考、學習。

 

本文連接：http://www.javashuo.com/article/p-deiyafhr-eh.html 

原文連接：https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/gg334361(v=crm.8)

事件框架（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