私のプラグインには、実行コンテキストの深さをチェックして、プラグインがそれ自体/エンティティを更新すると無限ループを回避するコードがありますが、エンティティが深さ 2、3、または 4 の他のプラグインまたはワークフローから更新されている場合があります。呼び出し、その特定のプラグインから呼び出しを処理し、深さが 1 より大きい場合でも停止しません。
2 に答える
おそらく、別のアプローチの方が良いのではないでしょうか?Depth
プラグインを考慮する必要はありません。他の人があなたと同じことをしていると聞いたことがありますが (コードが 2 回以上実行されないように深さをチェックしています)、私は通常、操作前の段階で基になるエンティティに変更を加えることでこれを回避しています。
たとえば、オポチュニティが更新されるたびにオポチュニティの名前を変更するコードがある場合、自分のコードを Update の操作後の段階に置くことで、別のUpdate
リクエストを送り返すことでユーザーが値を変更すると、コードが反応します。プラットフォームに変更を適用します。この新しいものUpdate
自体が、プラグインを再び起動させます - 無限ループ。
ロジックを操作前の段階に置く場合は、別の方法で行います。ユーザーの変更によってプラグインが起動します。ユーザーの変更がプラットフォームにコミットされる前に、コードが呼び出されます。今回は、メッセージTarget
で送信された を確認できます。属性が に存在しない(つまり、更新されていない) 場合は、目的の値で呼び出された属性を に追加すると、この値がプラットフォームに引き継がれます。つまり、レコードがコミットされる前に自分の値をレコードに注入しているため、別のリクエストを発行する必要がありません。したがって、私の変更により、それ以上プラグインが起動することはありません。InputParameters
Update
name
Target
name
Target
Update
明らかに、あなたのシナリオはもっと複雑だと思いますが、同じパターンに当てはまらない場合は非常に驚くでしょう.
Greg が上記で述べたことすべてに同意することから始めます。可能であれば、この状況を回避するために設計をリファクタリングします。
それが不可能な場合は、IPluginExecutionContext.SharedVariablesを使用してプラグイン間で通信する必要があります。
プラグインの開始時に SharedVariable を確認し、必要に応じて設定/更新します。使用する特定の設計は、管理する必要がある複雑さに応じて異なります。メッセージとエンティティ ID を含む文字列を常に使用します。シリアル化と逆シリアル化は簡単です。次に、特定のレコードの特定のメッセージに対して既に実行しているかどうかを常に確認します。