0

在我的插件中,我有一个代码来检查执行上下文深度以避免插件更新自身/实体后的无限循环,但在某些情况下,实体正在从其他插件或深度为 2,3 或 4 的工作流更新,并且针对该特定调用,从那个特定的插件我想处理调用并且即使深度大于 1 也不会停止。

4

2 回答 2

2

也许不同的方法可能会更好?我从来不需要Depth在我的插件中考虑。我听说其他人和你做同样的事情(检查深度以避免代码运行两次或更多次),但我通常通过在 Pre Operation 阶段对底层实体进行任何更改来避免这种情况。

例如,如果我的代码在机会更新时更改机会的名称,通过将我的代码置于更新的后期操作阶段,我的代码将通过发送单独的Update请求来响应用户更改值到平台以应用更改。这个新的Update本身导致我的插件再次触发 - 无限循环。

如果我将我的逻辑放在 Pre-Operation 阶段,我会采取不同的做法:用户的更改会触发插件。在用户的更改提交到平台之前,我的代码被调用。这次我可以看一下在to消息Target中发送的那个。如果该属性在 中不存在(即它没有更新),那么我可以将一个使用所需值调用的属性附加到该属性中,并且该值将传递到平台。换句话说,我在提交之前将我的值注入到记录中,从而避免发出另一个请求。因此,我的更改不会导致进一步的插件触发。InputParametersUpdatenameTargetnameTargetUpdate

显然,我认为您的情况更复杂,但如果它不符合相同的模式,我会感到非常惊讶。

于 2012-12-04T09:28:04.280 回答
0

我首先同意 Greg 上面所说的一切——如果可能的话,重构设计以避免这种情况。

如果这不可能,您将需要使用IPluginExecutionContext.SharedVariables在插件之间进行通信。

在插件开始时检查 SharedVariable,然后根据需要设置/更新它。您将使用的具体设计将根据您需要管理的复杂性而有所不同。我总是使用带有消息和实体 ID 的字符串 - 很容易序列化和反序列化。然后我总是知道我是否已经针对特定记录执行特定消息。

于 2012-12-05T22:48:07.243 回答