本文介紹了Microsoft Dynamics 365（以下簡稱D365）中的兩個概念，事件框架（Event Framework）與事件執(zhí)行管道（Event execution pipeline）。

本文適用于：Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

注意：本文的一些內(nèi)容可能已經(jīng)不適用于最新的D365，翻譯只為參考、學習。

本文鏈接：https://www.cnblogs.com/hhelibeb/p/11086723.html 

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

事件框架（Event Framework）

在D365中你可以通過集成自定義業(yè)務邏輯（代碼）來擴展或自定義服務器的功能。你可以自定義產(chǎn)品來支持自己公司的業(yè)務，可以向產(chǎn)品添加新的特性。事件框架技術允許你將自開發(fā)代碼集成到D365系統(tǒng)中。

事件框架允許你創(chuàng)建豐富的垂直和水平解決方案，它通過支持可靠、便攜的開發(fā)與集成自定義業(yè)務邏輯實現(xiàn)這點。你的自定義邏輯在集成到系統(tǒng)中后，可以作為D365主要執(zhí)行路徑的一部分被同步執(zhí)行，也可以在一個托管隊列中異步執(zhí)行。業(yè)務數(shù)據(jù)可以傳輸?shù)侥愕淖远x代碼中，可以根據(jù)數(shù)據(jù)的性質(zhì)執(zhí)行相應的action，或者直接修改數(shù)據(jù)。

事件框架提供以下關鍵特性：

• 一個改進的業(yè)務處理子系統(tǒng)。該子系統(tǒng)提供了執(zhí)行plugin和workflow的統(tǒng)一方法，改善了了可靠性、提供了增強的特性集和plugin的可移植性。
• 事件框架API?？梢砸詐lugin和workflow的形式擴展D365平臺。
• 一個用于部署plugin和workflow到數(shù)據(jù)庫的API。它使你可以將plugin和workflow自動分發(fā)到數(shù)據(jù)中心的所有相關服務器上。
• 同步和異步的plugin執(zhí)行。同步plugin作為主要的D365事件處理的一部分以預定義的順序執(zhí)行，異步plugin被隊列化并獨立執(zhí)行。

只有D365 server和Outlook客戶端支持事件框架。有關擴展D365 Web應用的信息，可以參考Customize Microsoft Dynamics 365 applications

事件執(zhí)行管道（Event execution pipeline）

D365的事件處理子系統(tǒng)會基于消息管道處理模型執(zhí)行plugin。由plugin或其它應用調(diào)用的用戶action、SDK方法會產(chǎn)生一個消息，發(fā)送給organization Web Service。消息包含業(yè)務實體信息和核心操作信息。消息被傳遞給事件執(zhí)行管道，通過管道，消息可以被平臺核心和其它任何注冊的plugin讀取。

注意：雖然D365平臺托管了多個Web Service，只有由organization和OData端觸發(fā)的事件會導致plugin執(zhí)行。

架構和相關組件

 下圖是D365平臺中有關異步和同步事件處理的整體架構，

事件執(zhí)行管道要么同步處理事件，要么異步處理事件。平臺核心操作和同步執(zhí)行的plugin會立即執(zhí)行。同步的plugin以定義好的順序執(zhí)行。異步執(zhí)行的插件由異步隊列代理（Asynchronous Queue Agent）隊列化，并在晚些時候由異步服務執(zhí)行。

注意：不管是異步還是同步執(zhí)行的plugin，都有一個2分鐘的執(zhí)行時間限制。如果執(zhí)行超時，就會產(chǎn)生System.TimeoutException異常。對于需要超過2分鐘的執(zhí)行時間的情況，考慮使用workflow或其它后臺處理方式實現(xiàn)。2分鐘限制只對在部分信任下注冊的的plugin有效，也就是只對被部署到沙箱的plugin有效。更多信息： Plug-in isolation, trusts, and statistics

管道階段 (Pipeline stages)

管道分為4個階段，其中3個可以用于自定義開發(fā)或者第三方plugin。在階段內(nèi)注冊的多個plugin可以進一步在階段內(nèi)排序。

Event	Stage name	Stage number	Description
Pre-Event	Pre-validation	10	在主系統(tǒng)操作前執(zhí)行的階段。有可能在數(shù)據(jù)庫事務外執(zhí)行。  安全注意事項 這個階段比安全檢查要早，安全檢查是指對調(diào)用的檢驗或用戶執(zhí)行權限檢查日志。
Pre-Event	Pre-operation	20	在主系統(tǒng)操作前執(zhí)行的階段。在數(shù)據(jù)庫事務內(nèi)執(zhí)行。
Platform Core Operation	MainOperation	30	系統(tǒng)主操作事務，比如創(chuàng)建更新刪除等等。自定義plugin無法使用這個階段。它只用于內(nèi)部使用。
Post-Event	Post-operation	40	在主系統(tǒng)操作后執(zhí)行的階段。在數(shù)據(jù)庫事務內(nèi)執(zhí)行。

消息處理

無論何時，當應用代碼或workflow調(diào)用D365 Web service方法的時候，系統(tǒng)中會發(fā)生狀態(tài)變化，觸發(fā)一個事件。信息作為參數(shù)傳輸給web service方法，會在內(nèi)部被包裝到一個OrganizationRequest消息，由管道處理。在OrganizationRequest消息中的信息被傳輸?shù)降谝粋€為當前事件注冊的plugin，可以被讀取和修改，然后再傳輸給第二個，以此類推...plugin以傳遞給它的Execute方法中的context的形式接收消息信息。消息也會傳遞給平臺核心操作。

Plugin注冊

Plugin可以被注冊為在核心平臺操作前/后運行。Pre-event plugin可以首先接收OrganizationRequest，并在它傳輸?shù)胶诵暮诵牟僮髑皩ζ溥M行修改。核心平臺操作完成后的消息被稱為OrganizationResponse。Response被傳遞給post-event plugin。 Post-event plugin可以在消息副本被傳遞給異步plugin前修改消息。最終，響應返回給調(diào)用原始web service方法的應用或workflow。

數(shù)據(jù)庫事務

Plugin有可能在數(shù)據(jù)庫事務內(nèi)執(zhí)行，也有可能不在，這取決于管道如何處理消息請求。你可以通過讀取 IsInTransaction屬性來檢查這點。IsInTransaction繼承自IPluginExecutionContext，會被傳遞給plugin。如果plugin在數(shù)據(jù)庫事務內(nèi)執(zhí)行，并傳輸異常給平臺，整個事務將回滾。階段20和40保證是數(shù)據(jù)庫事務的一部分，而10有可能是其一部分。

任何在數(shù)據(jù)庫事務內(nèi)執(zhí)行的注冊的plugin返回異常的時候，平臺會取消核心操作，導致核心操作回滾。此外，任何注冊到pre-event或post event的plugin都將不運行，任何被相同事件觸發(fā)的workflow亦然。

參考：http://ashishmahajancrm./2012/07/microsoft-dynamics-crm-2011-event.html