4

IIS 6.0 でホストされている .net Web サービスがあり、クライアントが wsdl と一致しないデータで接続するため、定期的に http 500 で失敗します。

メソッドで int 型として指定された要素があり、受信 xml 要素に 10 進数が含まれているようなものです。

WSDL 要素の定義:

<s:element minOccurs="1" 
    maxOccurs="1" 
    form="unqualified" name="ItemCount" type="s:int" >

提供された要素:

<ItemCount>1.0</ItemCount>

これにより、iis ログに 500 エラーが残りますが、ソープ エラーの情報やエラーの原因となった入力データは返されません。

現在、wireshark を使用してすべてをキャプチャすることによって提供されるデータに関するいくつかの問題を診断しましたが、おそらくそれほど邪魔にならない他のオプションを知りたいです。

500 エラーの原因となっている送信中のデータをキャプチャする方法はありますか (できれば、500 エラーが発生したときにのみデータをキャプチャします)。おそらく次の方法で：

  • IIS の構成
  • Web サービスの構成
  • Web サービスのコードを変更する

tbreffniによって提供された回答をテストした後に編集

tbreffni の後の私に最もよく合った答え - 他にもいくつかの良い応答がありましたが、その答えにより、fiddler や wireshark などを実行しなくても、デシリアライゼーション エラーを引き起こすペイロードをキャプチャできます。

SOAP 拡張機能を実際に実行するための情報は少し軽いので、必要な手順を以下に示します。

  • MSDNの記事 に従って、SOAP 拡張機能を .dll としてビルドします。
  • トレースするサービスの bin ディレクトリに .dll を追加します。

  • トレースするサービスの web.config で、次を webServices セクションに追加し、SOAPTraceExtension.TraceExtension と SOAPTraceExtension を拡張機能に一致するように置き換えます。

    <webServices>
      <soapExtensionTypes>
        <add type="SOAPTraceExtension.TraceExtension, SOAPTraceExtension" priority="1" group="0"/>
      </soapExtensionTypes>
    </webServices>

4

6 に答える 6

3

私はfiddlerまたはhereを試してみます。特に Web サービス向けではなく、通常はクライアント側向けですが、リバースプロキシとして使用できます。

非常にスクリプト可能で、「リクエスト/レスポンス」に対応しているため、500 個のエラーしかキャプチャできない可能性が高いと思います。

于 2008-10-16T21:54:10.200 に答える
2

発生した例外の詳細をログに記録するグローバル例外ハンドラーを Web サービスに実装できます。これは、現在の問題に役立ちます。さらに、スローされた例外の数とコードによって洞察が得られるため、運用環境で非常に役立ちます。

.Net Web サービスの例外ハンドラーを実装するには、SOAP 拡張機能を作成する必要があります。例については、次のMSDN 記事を参照してください。私はこのアプローチをいくつかの実稼働 Web サービスで使用してきましたが、どのような問題がどこで発生しているかを判断するのに非常に役立ちました。

于 2008-10-20T23:45:19.787 に答える
1

IIS Request-Based Tracing をご覧になりましたか?: http://technet.microsoft.com/en-us/library/cc786920.aspx

于 2008-10-21T00:00:30.910 に答える
1

私はこれを自分で使用したことはありませんが、MSDN でこれを見つけました: ASP.NET Web サービスでのトレースの有効化

于 2008-10-16T22:34:50.150 に答える
0

ツールを使用する場合は、WireShark を使用します。

それ以外の場合、「すべて」をキャプチャする最も簡単な方法 (ASMX を使用していると仮定) は、system.net でトレースを有効にすることです。

http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

WCF を使用している場合、優れたトレース サポートがあり、svctraceviewer を使用してトレース ログを表示できます。ただし、WCFを使用しているようには聞こえません。

于 2008-10-20T23:57:06.987 に答える
0

自分なりに考えた結果、現時点で最良の解決策は、xml ブロブを入力として受け入れる軽量のファサード Web サービスをまとめることです。

次に、クライアントから提供された入力データを使用して、ファサード サービスで実際のサービスを呼び出すことができます。

  • エラーを処理し、ソース データと返された SOAP エラーをログに記録します
  • 適切なデータからの応答をクライアントに返す

これは一時的な手段にすぎません (受け入れられる XML について明示的でない Web サービスには強く反対します) が、おそらく、このようなエラーを診断するという困難を乗り越えるためにより多くのレバレッジが得られるでしょう。 Web サービスへの接続が wsdl を尊重していないか、返された SOAP エラーを読み取ることができません。

ありがたいことに、この場合、Web サービスに投稿する当事者は 1 人だけです。パケット スニファーの方法 (フィドラーまたはワイヤーシャーク) は実行可能ですが、500 エラーのログ記録がないため、「他にどのような良いオプションがあるのか​​?」と考えさせられました。

于 2008-10-16T22:14:08.380 に答える