5

タイトルが示すように、コードまたは基本的な CRM 機能によって発生したエラーと、クライアント システムにインストールされているカスタム プラグインによってスローされたエラーを区別する方法を探しています。

私たちが絶えず犠牲になっているのは、クライアントが社内で作成したか、別の ISV から購入したカスタムのサードパーティ プラグインです。彼らは、私たちが触れるCRMエンティティ、または最新のケースでは私たち自身のエンティティの1つにさえそれを登録します. 私たちが何かをしようとすると、プラグインはそのことをしようとして失敗します。最新の例では、CRM に挿入した後、プラグインは ' を正しくエンコードしていませんでした。プラグインがエラーをスローし、CRM がエラーを返します。

調査に何時間も費やすことなく、プラグインが犯人であることをどのように判断できますか? これまでのところ、プラグインのスタック トレースをエラー メッセージとしてスローすることで簡単に判別できるようにしている企業は 1 社しか見たことがありません。

明確にするための編集：

  • 問題がカスタム プラグインであり、Azure から CRM と対話するコードではないことを特定するのにかかる時間を短縮するためのプログラム ソリューションを探しています。
  • エラーのログ記録/処理を強化して、違いを見分けるのに十分なほどスマートにしようとしています。
  • コードが 100% 動作しているにもかかわらず、同期プラグインがトリガーされ、そのプラグインが失敗した場合でも、CRM から例外が発生します。
  • 私たちが行うことはすべて、SDK を介したプログラムです。
4

4 に答える 4

2

頭に浮かぶ唯一のことは、CRM トレースを有効にすることです。以下のリンクは、Microsoft Dynamics CRM でこれを行う方法を説明する必要があります。

http://support.microsoft.com/kb/907490

于 2013-04-15T14:05:00.790 に答える
1

サービスによって返される例外のDetail.TraceTextプロパティを見てください。完全なスタック トレースを取得することはできませんでしたが、どこで問題が発生したかを示す情報が返されました。

Mario.CRM.TestOrg.Plugins: Mario.CRM.TestOrg.Plugins.ContactPreUpdate

[5ee31a9e-3558-e211-adeb-00155d014401: Mario.CRM.TestOrg.Plugins.ContactPreUpdate: 連絡先の更新]

サンプル コード スニペット

try
{
  //create service proxy and call service
}
catch (Exception ex)
{
  Console.WriteLine(((System.ServiceModel.FaultException<Microsoft.Xrm.Sdk.OrganizationServiceFault>)(ex)).Detail.TraceText);
}
于 2013-04-16T19:08:01.500 に答える
1

この図のように、プラグインが原因で例外が発生した場合: ここに画像の説明を入力

ログファイルをダウンロードできます。内部で、例外の原因となったプラグインを簡単に見つけることができます。たとえば、次のログを確認してください。

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: StupidPluginDetail: 
// ... other details
[StupidPlugin: StupidPlugin.ExamplePlugin]
[bda9ad85-c4a5-e211-bc00-78e7d162ee67: StupidPlugin.ExamplePlugin: Create of orderclose]
</TraceText>
</OrganizationServiceFault>
于 2013-04-15T14:10:26.670 に答える