在MS CRM 2011的自定義和開發（8）——擴展框架以及擴展點介紹中介紹了擴展點，在MS CRM 2011的自定義開發（10）的幾篇文章中介紹了Microsof Dynamics CRM 2011中的發現服務DiscoveryService以及組織服務OrganizationService，從而完成了開發方面基礎知識的准備工作，在本章，以及后續的幾章將會介紹如何利用這些服務，在擴展點上進行擴展開發。本章介紹插件開發內容。
插件，Plugin，在之前的版本也被稱作Callout，中文也可以稱作是業務邏輯擴展。在SDK中，對插件的定義是：插件是可與 Microsoft Dynamics CRM 2011 和 Microsoft Dynamics CRM Online 集成的自定義業務邏輯（代碼），用於修改或增加平台的標准行為。也可以將插件認為是針對 Microsoft Dynamics CRM 平台觸發的事件的處理程序。您可以讓插件訂閱（也稱為注冊）已知事件集，以便在事件發生時運行您的代碼。
個人的理解，插件，可以和數據庫中的觸發器，面向對象編程中的事件處理函數進行類比。觸發器，可以由對數據表進行Update、Insert或Delete的操作觸發，從而開始執行。事件處理函數，基於消息而執行。而插件，會根據注冊時訂閱的消息而觸發執行。而且，可以被訂閱的消息非常之多，除了CRUD操作，還包括有其他分派、共享等等MS CRM系統中具有業務語義的消息。此外，插件也可以有類似於觸發器中Before、After等處理階段的概念，被稱為事件管道階段。
在介紹插件開發之前，首先要了解微軟CRM的事件處理框架。
MS CRM的事件處理框架包括以下一些內容：
事件處理子系統：該子系統提供執行插件、工作流的統一的方法，從而保障了可靠性、功能集以及靈活性；
事件框架API：允許以插件、工作流活動的形式開發自定義業務邏輯，從而擴展系統的功能；
部署API：完成插件以及自定義工作流活動程序集的部署操作，尤其是可以將插件、工作流程序集部署到CRM的數據庫中，在集群環境下非常有意義，避免了服務器之間的文件拷貝工作；
向后兼容性：允許V4版本的插件運行於CRM2011中；
同步/異步：可以作為主CRM流程的一個組成部分被執行，也可以放入異步隊列，被異步執行；
Microsoft Dynamics CRM 事件處理子系統根據消息管道執行模型執行插件。MS CRM Web應用程序中的用戶操作或者插件或其他應用程序執行的 SDK 方法調用會導致將消息發送到組織服務。被傳遞給組織服務的消息包含業務實體信息和核心操作信息，該消息是通過事件執行管道傳遞的，平台核心操作和任何注冊的插件都可以在事件執行管道中讀取或修改它。
事件處理體系架構如下圖所示。
事件執行管道可以使用同步或者異步兩種方式處理事件。平台核心操作以及注冊為同步執行的插件會立即執行，而對於注冊為異步執行的插件，CRM系統會把事件處理放入到異步隊列中，而后，由MS CRM的異步處理服務進行管理控制。
事件管道階段，事件執行管道分為多個階段，以平台核心操作作為分界，在平台核心操作之前執行的階段被稱為前置事件（前期事件、Pre-Event），在平台核心操作之后執行的階段被成為后置事件（后期事件、Post-Event）。下表是事件管道階段的詳細信息：
| 事件 |
階段名稱 |
階段編號 |
說明 |
| 前期事件 |
前期驗證 |
10 |
管道中的一個階段，其中的插件在主系統操作之前執行。在此階段注冊的插件可能會在數據庫事務外部執行。 |
| 前期事件 |
前期操作 |
20 |
管道中的一個階段，其中的插件在主系統操作之前執行。在此階段注冊的插件將在數據庫事務內部執行。 |
| 平台核心操作 |
主操作 |
30 |
系統的事務內主操作，例如創建、更新和刪除等等。在該階段中不可以注冊自定義插件。僅供內部使用。 |
| 后期事件 |
后期操作 |
40 |
管道中的一個階段，其中的插件在主系統操作之后執行。在此階段注冊的插件將在數據庫事務內部執行。 |
| 后期事件 |
后期操作（已棄用） |
50 |
管道中的一個階段，其中的插件在主系統操作之后執行。在此階段注冊的插件可能會在數據庫事務外部執行。此階段僅支持基於 Microsoft Dynamics CRM 4.0 的插件。 |
由於可以在一個階段注冊多個插件，換言之，多個插件可以訂閱一個事件，那么在實際運行中，當調用了CRM組織服務的方法時，作為參數傳遞給方法的消息會被打包為OrganizationRequest消息，並交由管道進行處理。管道會將消息傳遞給訂閱了該事件的第一個插件，第一個插件執行過程中，會對消息進行讀取、修改等操作，該插件執行完成后，被處理后的消息將會繼續在管道中執行——被管道傳遞給下一個插件，以此類推。
在MS CRM 2011中，新增加的一個特性就是，在編號20至編號40三個階段是處於數據庫事務中的，從而在一定程度上保證了數據操作的完整性。假設插件處於階段20或者階段40，如果插件拋出了異常，那么將會回滾整個事務。