在我的插件中,我有一个检查执行上下文深度的代码,以避免在插件更新自身/实体时出现无限循环,但在某些情况下,实体是从其他插件或深度为2、3或4的工作流中更新的,对于特定的调用,我希望从该特定插件处理调用,即使深度大于1也不会停止。
发布于 2012-12-04 17:28:04
也许一种不同的方法可能更好?我从来不需要在我的插件中考虑Depth。我听说过其他人和你做同样的事情(检查深度以避免代码运行两次或更多),但我通常通过在Pre Operation阶段对底层实体进行任何更改来避免这种情况。
例如,如果我的代码每当机会更新时更改机会的名称,通过将我的代码放入更新的后期操作阶段,我的代码将通过向平台发回单独的Update请求来应用更改,从而对用户更改值做出反应。这个新的Update本身会导致我的插件再次触发-无限循环。
如果我把我的逻辑放在Pre-Operation阶段,我会做不同的事情:用户的更改触发插件。在用户的更改提交到平台之前,我的代码会被调用。这一次,我可以查看在InputParameters中发送给Update消息的Target。如果name属性在Target中不存在(即它没有更新),那么我可以将一个名为name的属性和所需的值附加到Target中,这个值将传递到平台。换句话说,我在提交记录之前将我的值注入到记录中,从而避免发出另一个Update请求。因此,我所做的更改不会触发更多插件。
显然,我假设你的场景更复杂,但如果它不能符合同样的模式,我会非常惊讶。
发布于 2012-12-06 06:48:07
我将首先同意Greg上面所说的一切-如果可能的话,重构设计以避免这种情况。
如果这是不可能的,您将需要使用IPluginExecutionContext.SharedVariables在插件之间通信。
在插件的开头检查SharedVariable,然后根据需要设置/更新它。您将使用的具体设计将根据您需要管理的复杂性而有所不同。我总是得到一个带有消息和实体ID的字符串--很容易序列化和反序列化。然后,我总是知道我是否已经对特定记录的特定消息执行了。
https://stackoverflow.com/questions/13695509
复制相似问题