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