本文介绍了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
在D365中你可以通过集成自定义业务逻辑(代码)来扩展或自定义服务器的功能。你可以自定义产品来支持自己公司的业务,可以向产品添加新的特性。事件框架技术允许你将自开发代码集成到D365系统中。
事件框架允许你创建丰富的垂直和水平解决方案,它通过支持可靠、便携的开发与集成自定义业务逻辑实现这点。你的自定义逻辑在集成到系统中后,可以作为D365主要执行路径的一部分被同步执行,也可以在一个托管队列中异步执行。业务数据可以传输到你的自定义代码中,可以根据数据的性质执行相应的action,或者直接修改数据。
事件框架提供以下关键特性:
只有D365 server和Outlook客户端支持事件框架。有关扩展D365 Web应用的信息,可以参考Customize Microsoft Dynamics 365 applications
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
管道分为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可以被注册为在核心平台操作前/后运行。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
联系客服