問題タブ [faultcontract]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1028 参照

wcf - 送信する FaultException の SOAP エンベロープ ヘッダーにデータ コントラクトを書き込みますか?

私は現在のプロジェクトで少し困っています。コントラクトへの準拠を拒否している統合パートナーがいます。彼らは、同じヘッダーと契約上有効なメッセージ本文を含む WSDL 定義のメッセージ コントラクトではなく、カスタム ヘッダーを使用したフォルト コントラクトを期待しています。単純に をスローできるため、WCF で SOAP エラーを送信しても問題ありませんFaultException。実際のバインドは、フォールトにカスタム ヘッダーが含まれているという要件です。を使用してカスタム ヘッダーをシリアル化できましたがOperationContext、統合パートナーが必要とする方法ではシリアル化されません。

を使用OperationContext.Current.OutgoingMessageHeadersすると、ヘッダーに含めるオブジェクトを含むカスタムを作成できMessageHeader<T>ます... POCO、DataContract、または MessageContract にすることができます。メッセージ コントラクトを使用すると、名前空間が無視されるように見え、シリアル化されたメッセージには、メッセージの各メンバーに無効な xmlns= 属性が多数含まれます。これも問題です。MessageHeader が作成されると、.GetUntypedHeader(name, namespace)メソッドを呼び出すMessageHeaderと、OperationContext の OutgoingMessageHeaders に追加できる が生成されます。問題は、ヘッダーにオブジェクトを直接追加できないことです... GetUntypedHeader メソッドにはラッパー要素名と名前空間が必要なため、それらは常にラップする必要があるようです。

必要なヘッダーは次のとおりです。

imsx_syncResponsHeaderInfoヘッダー に3 つの子要素があるという事実がなければ、私たちはおそらく仕事をしていたでしょう。ただし、3 つの個別のオブジェクトをラップするメッセージ ヘッダーを直接作成することは不可能であり、MessageContract を で使用するとIsWrapped=false、要素のすべての直接の子要素が、正しくない名前空間を定義する属性でimsx_syncResponseHeaderInfoシリアル化されます (xmlnsサービス契約)。これにより、契約上のスキーマに従ってヘッダーが無効になり、コンシューマーはヘッダーを逆シリアル化できなくなります。

WCF 配信の SOAP フォールトの送信メッセージ ヘッダーに MessageContract を追加する方法はありますか?契約する?

0 投票する
2 に答える
4731 参照

wcf - System.Exception.Data は DataContract でシリアル化されませんか?

dataContracts を使用する WCF サービスがいくつかあり、Data プロパティでカスタム Dictionary< string , object > data を使用して例外を渡したいと思っていましたが、スローする前にこの配列にデータを追加すると、次のエラーが表示されますカスタム ServiceBehavior の ErrorHandler:

データ コントラクト名 'ArrayOfKeyValueOfanyTypeanyType:http://schemas.microsoft.com/2003/10/Serialization/Arrays' は想定されていません。たとえば、KnownTypeAttribute 属性を使用するか、DataContractSerializer に渡される既知の型のリストにそれらを追加することにより、静的に認識されていない型を既知の型のリストに追加します。

DataContract として注釈が付けられた Dictionary プロパティを使用してカスタム例外を常に作成し、それをスローする必要がありますか? ErrorHandler を使用するという考えは、各サービス メソッドで例外を処理することを回避することですが、メソッドにさらに注釈を追加する必要がありますか? 私は何が欠けていますか?

参考までに、これは私の FaultErrorHandler クラスです。

私の典型的なサービスインターフェースは次のようになります:

0 投票する
1 に答える
7408 参照

c# - クライアントは一般的なFaultException<T>をキャッチせず、FaultExceptionのみをキャッチします

私はこれについて読むためにそこにあるすべてを読みました、しかし多分私は何かを逃しています(まあ、確かに私は何かを逃しています、さもなければそれはすでに働いているでしょう)

サーバービジネスレイヤー内でいくつかの例外エラーをスローしています:

これはサービスでは未処理のままですが、IErrorHandlerキャッチして作成する必要がありますFaultMessage

尋ねる必要はありません。デバッガーでパーツif (error is RfcException)部分に入るのを確認しました。そのコードをステップスルーして、問題なく最後まで到達しました。そのerrorHandlerはメッセージをラップしFaultException<RfcServiceFault>ます、RfcServiceFaultメッセージはこれです

このサービスには、faultContractを含むwcfサービスに必要なすべてのアノテーションがあります。

今:クライアントでのテスト、次のような簡単なテスト:

私はこの同様の問題に関する多くの投稿を読みました:

しかし、これまでのところ何も役に立たないようです。web.configでWCFトレースを設定してみました。

そこにsvclogファイルを取得し、WCFトレースビューアーで開きますが、一連のメッセージのみが表示され、黄色のメッセージは例外を示しますが、クライアントがすでに表示しているもの、つまり受信されているものを確認するだけSystem.ServiceModel.FaultExceptionであり、一般的なもの

これを理解する方法はありますか?

編集は言及するのを忘れました、私はこのように設定で私のエラーハンドラを有効にしました:

0 投票する
1 に答える
620 参照

c# - 特殊なFaultExceptionサブクラスまたはFaultException

WCFサービスがいくつかの既知の障害を返すことができるようにしたいと思います。つまり、定義されたFaultContract

自分のFaultExceptionサブクラスを派生させるべきか、それとも詳細クラスを作成してを使用するべきかについて、少し混乱していFaultException<TDetail>ます。

両方の例が散らばっているように見えますが、私は一般的なコンセンサスが何であるか疑問に思いました。

MyExceptionクライアントコードはWCF中心ではなく、よりクリーンに見えると思うので、私は派生に傾いていますFaultException<MyExceptionDetail>が、私はそれについて強い感情を持っていません。

0 投票する
0 に答える
338 参照

c# - Enterprise Library 例外ブロック、System.Exception タイプのハンドラーが他の例外タイプのハンドラーをオーバーライドする

Enterprise Library 例外処理ブロックを使用しています。

次の問題があります。

optimisticconcurencyexception2 つの例外タイプ (および)を持つポリシーが必要ですsystem.exceptions。そのためoptimisticconcurencyexceptionに、障害ハンドラーを追加します。別のsystem.exceptions障害ハンドラーとログ ハンドラーを追加します。

optimisticconcurencyexception ここで、ライブラリをキャッチするsystem.exceptionsと、割り当てた障害ハンドラーだけでなく、障害ハンドラーとログ ハンドラーが実行されます。optimisticconcurencyexception

例外マネージャーがスローするメソッドを処理するデバッガーにブレークポイントを設定し、optimisticconcurencyexceptionコードでは、正しい を取得しますfaultexception

私は理解できますか?この問題について何か考えはありますか?

編集

私の質問は、エンタープライズ ライブラリ サポート フォーラムで回答されました。

ここにリンクがあります http://entlib.codeplex.com/discussions/349033

0 投票する
1 に答える
425 参照

c# - svcutil.exe クライアント プロキシとフォールト コントラクト

svcutil.exe で生成されたクライアント C# プロキシ コードにフォールト コントラクト情報を含めることはできますか?
つまり、Web サービス メソッドが でマークされている場合、そのFaultContractAttribute型引数をクライアント プロキシのメソッドへのコメントで言及して、それを使用するときにどの例外をキャッチする必要があるかを確認できるようにします。
ありがとうございました。

0 投票する
2 に答える
829 参照

wcf - WCF とビジネス ロジック層のシナリオによる例外処理

私のサービスは、ビジネス ロジック全体が配置されている BusinessLogicLayer メソッドを呼び出すだけです。BL によって発生した例外を処理するためのベスト プラクティスは何ですか? (致命的な例外だけでなく、ユーザーが見つからないときに BL がスローする UserNotFoundException のような「論理的な」ApplicationExceptions も知りたいです)。

これらの例外を、クライアントが表示する FaultExceptions にどこで変換する必要がありますか?

BL からビジネス例外をスローし、それらをサービス呼び出しにキャッチして FaultException に変換し、クライアントに返す必要がありますか? または BL は、すでに「クライアントに優しい」FaultExceptions を発生させる必要がありますか?

前もって感謝します :)

0 投票する
1 に答える
1168 参照

wcf - Castle Dynamic Proxy Generation を使用して WCF フォールト コントラクトを挿入する

現在、WCF バックエンドを使用して WPF アプリケーションに取り組んでいます。例外処理用にクライアント ロギング ソリューションとサーバー ロギング ソリューションを実装しましたが、それらはうまく機能しますが、多くの場合、ネットワーク上で情報を結び付けるのは困難です。サーバーで例外が発生した場合、例外トークンをネットワーク経由で返す方法が必要でした。これにより、例外をクライアントに記録できるようになります。そうすれば、クライアント エラーのトラブルシューティングを行っているときに、それをサーバーの例外と簡単に関連付けることができます。

私たちのアーキテクチャについてもう少し情報を提供したいと思います。それから私の問題を述べます。

私たちの WCF 実装は、サービス参照を設定するためのすぐに使える方法よりも少し堅牢です。クライアントに動的プロキシ生成を実装しました。クライアントとサーバーで共有される Web サービス インターフェイスを作成し、Castle.DynamicProxy.ProxyGenerator クラスと CreateInterfaceProxyWithoutTarget メソッドを使用してプロキシを作成することで、これを実現しました。さらに、CreateInterfaceProxyWithoutTarget メソッドを呼び出すときに、IInterceptor 実装を指定します。サーバーには、トレースと障害の動作に使用される 3 つの主要なクラスがあります。

FaultOperationInvoker (IOperationInvoker を実装): IOperationInvoker.Invoke を使用してサービス メソッドの呼び出しを試みます。フォールト例外タイプの場合は再スローし、例外の場合は、特定の詳細タイプを持つフォールト コントラクトがあるかどうかを判断しようとし、存在する場合はラップしてから、詳細情報を使用して新しいフォールト例外を発生させます。

FaultOperationBehavior (Implements IOperationBehavior) は、ディスパッチ操作の呼び出し元を上記の障害操作の呼び出し元にポイントします。

IServiceBehavior を実装する例外を処理するための ExceptionTraceBehavior (属性を継承、IServiceBehavior を実装)。クラス(FaultOperationBehavior)もあります

すべてのサービス インターフェイスには、具体的な実装があります。すべてのサービスは、ExceptionTrace 属性で装飾された基本サービス クラスも継承します。

さて、背景情報を踏まえて、ここに問題があります。すべてのサービス操作に詳細型 WCFServiceFaultDetail のエラー コントラクトを持たせたいのですが、すべてのサービス操作に FaultContract 属性を設定したくありません。ExceptionTraceBehavior でわかるように、障害コントラクトをプログラムで追加する方法を理解しました。これは、操作に障害を追加するのに最適です。通常の古い例外がオペレーション インボーカーでキャッチされると、適切なフォールト コントラクトがあることがわかり、新しい FaultExcption がスローされます。ただし、例外がクライアントにキャッチされると、catch (FaultException fe) コードではなく、catch (FaultExcection fe) コードに分類されます。

ただし、プログラムでフォールト コントラクトに追加するコードを削除すると、すべてのサービス操作を [FaultContract(typeof(WcfServiceFaultDetail))] で装飾すると、クライアントは期待どおりに例外をキャッチします。

私が把握できる唯一のことは、プロキシが WSDL やその他のメタデータからではなくインターフェイスから動的に生成されており、インターフェイスにフォルト コントラクトの装飾がないため、プログラムによるフォルト コントラクトが尊重されていないことです。

その考えを念頭に置いて、IInterceptor 実装にフォールト コントラクトを追加する方法を見つけようとしましたが、成功しませんでした。

したがって、誰かがすでにこれを行っており、詳細を提供できることを願っています。どんな助けでも大歓迎です。

0 投票する
5 に答える
16581 参照

c# - WCF FaultException 応答から詳細を抽出する

私はサードパーティのソープ サービスとうまく連携しています。クラスを自動生成した SOAP Web サービスへのサービス参照を追加しました。

エラーが発生すると、次のような SOAP 応答が返されます。

エラーをキャッチできますが、詳細を抽出できません。私は次のコードを試しました:

ただし、詳細ノードはオブジェクトではないため、次のエラーが発生します。

これはサード パーティの API であるため、応答を変更することはできません。