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，翻译只为参考、学习。

 

本文链接：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中你可以通过集成自定义业务逻辑（代码）来扩展或自定义服务器的功能。你可以自定义产品来支持自己公司的业务，可以向产品添加新的特性。事件框架技术允许你将自开发代码集成到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