Fork me on GitHub

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

在主系统操作前执行的阶段。有可能在数据库事务外执行。

System_CAPS_security 安全注意事项

这个阶段比安全检查要早,安全检查是指对调用的检验或用户执行权限检查日志。

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

posted @ 2019-06-27 21:20  氢氦  阅读(...)  评论(... 编辑 收藏