6

Microsoft Dynamics CRM 4.0 でプラグインを作成する場合、以下を使用して、プラグインが起動する原因となったイベントの発生源を確認できます。

public void Execute(IPluginExecutionContext context)
    {
        if (context.CallerOrigin.GetType() == CallerOrigin.WebServiceApi.GetType())
        {
            return;
        }
        plugin code here...
     }

これにより、アクションがフォーム内のユーザーによって引き起こされたのか、Web サービスまたはワークフローなどによって引き起こされたのかを確認できます...

WCF を介してエンティティを作成および更新する同期アプリがあり、これが発生したときにプラグインを実行したくありません。ユーザーがエンティティを編集するときのみ (同期プロセスでの無限ループを防ぐため)。

IExecutionContext.CallerOriginは MS Dynamics CRM 2011 で削除されましたが、これを行う新しい方法は何ですか?

WCF 呼び出しを設定IExecutionContext.CorrelationIdして、プラグインの特定の Guid を確認する方法があるのではないかと考えていましたが、まだうまくいきませんでした。

4

4 に答える 4

12

これはしばらく前に尋ねられたようですが（そして、OPは今までに彼の解決策を見つけたと思います！）最近、同様の答えを探していました。必要なものを見つけるにはさらに調査が必要だったので、この理由から、他の人のためにここにも追加します.

まず、お探しの場合、このプロパティは廃止されました。信頼性が低いためと思われますが、MSCRM 4.0 で CallerOrigin が必要になったのにはいくつかの理由がありました。一方、これが時代遅れになるのを回避する方法もあります。

無限ループを防ぐ (2 プラグイン以上)

これが、私が CallerOrigin を探していた理由であり、この質問に出くわした方法です。別のプラグイン (つまり、非同期プロセス/Web サービス) からではなく、フォーム上のユーザーからのものである場合にのみ、プラグインを起動したかったのです。私の場合、問題を解決するために InputParameters を使用できないため、「2 つ以上のプラグイン」であるという区別は非常に重要です。私の例は次のようになりました。

  • 「親」エンティティのプラグインを更新します。親エンティティの「ステータス」というオプションセットが「承認済み」に設定されている場合、すべての子エンティティのステータスも「承認済み」に設定したいと思いました。

  • 「子」エンティティのプラグインを更新します。子エンティティの「ステータス」というオプションセットが「承認済み」に設定されていて、同じ親の他のすべての子が「承認済み」に設定されている場合、親のステータスも承認済みに更新する必要がありました。

これは、自分自身を保護しないと無限ループを引き起こします。また、InputParameters を使用して解決することもできません。基本的な解決策の 1 つは、深度チェックを使用することです。

context.PluginExecutionContext.Depth

これが 1 より大きい場合は、別のプラグイン/ワークフローによって呼び出されています。注: 初期更新をトリガーするワークフローがある場合は、確認する値に注意する必要があります。

オフライン クライアントからの同期の問題を防止する

これらを区別するために、さまざまなプロパティが与えられています。代わりにこれらを使用してください:

context.PluginExecutionContext.IsExecutingOffline
context.PluginExecutionContext.IsOfflinePlayback

由来によって反応が違う

これは、CallerOrigin が本当に必要な唯一のシナリオです。これを行うことができる唯一の方法は、PluginExecutionContext 自体のタイプを確認することです。私は非同期のタイプであることを知っています：

Microsoft.Crm.Asynchronous.AsyncExecutionContext

プラグインの場合は次のようになります。

Microsoft.Crm.Extensibility.PipelineExecutionContext

外部ソースから来た場合はどうなるかわかりませんが、残念ながら、現時点ではこれをテストして理解するためのコードがありません。あなたがおそらくチェックしなければならないすべての外に：

PluginExecutionContext.ParentContext

更新がどこから来たのかを検出するために私が遭遇した唯一の他の方法は、フォームでカスタムフラグを使用することです. したがって、オプションを使用して「OriginOfChange」（または同様のもの）と呼ばれるOptionSetを作成できます

  • CRM フォーム (JavaScript onsave)
  • ワークフロー
  • プラグイン
  • 等

その後、エンティティを更新すると、更新中にこのフィールドが設定されます。このようにして、毎回入力パラメーターをチェックして、更新がどこから来たのかを確認できます。

ソースに応じて異なる対応が必要な場合は、この最後の方法が最も安全です。

于 2012-03-13T16:16:12.517 に答える
3

このスレッドの解決策は、「context.depth プロパティをチェックするだけです。1 よりも大きい場合は戻ります」

プラグイン内のエンティティを更新していた更新プラグインでは完全に正常に機能し、プラグインが 2 回起動されましたが、2 回目は深さをチェックして終了しました。

アップデート

ただし、最も安全な方法は、プラグインの深さではなく、共有変数を使用することです。チェックされているのがプラグインの深さだけである場合、別のプラグインが別のプラグインをトリガーするときはいつでも、深さが 2 であるため、プラグインが Update イベントに対して起動したのは初めてであっても実行されません。

于 2012-08-02T15:13:10.210 に答える
2

IPluginExecutionContext.InputParameters の中を見たことがありますか?

もう 1 つのオプションは、変更がない場合は何も更新しないようにプラグインを変更することです。これにより、無限ループの可能性を防ぐことができます。

于 2011-05-17T16:31:18.317 に答える