SOAPless
無料で始める
ブログへ戻る
soapdebuggingtoolsweb-services

SOAP リクエストのデバッグ方法: Fiddler、Wireshark、curl を使った XML 検査ガイド

SOAPless Team11 min read

SOAP サービスはサイレントに失敗し、難解な XML フォールトを返し、WSDL の記述とは異なる動作をすることがあります。REST API であればブラウザの DevTools で JSON ペイロードを簡単に確認できますが、SOAP のデバッグには HTTP リクエストに包まれた XML エンベロープをキャプチャ・解析するための専用ツールが必要です。本記事では、SOAP デバッグに不可欠な 4 つのツールと、それぞれの使い分けを解説します。

ツールの選び方

各ツールの特徴を把握し、状況に応じて使い分けることが重要です。

ツール最適な用途難易度HTTPS 対応
curlリクエストの簡易テスト、スクリプト化初級ネイティブ
FiddlerHTTP レベルのトラフィック検査、リクエスト改変中級プロキシ経由の復号
SoapUIWSDL 対応テスト、アサーション、負荷テスト中級ネイティブ
WiresharkTCP レベル分析、ネットワーク問題、非 HTTP SOAP上級鍵/SSLKEYLOGFILE が必要

curl によるデバッグ

curl は SOAP リクエストの送信と生レスポンスの確認を最速で行えるツールです。GUI もセットアップも不要で、ターミナルがあればすぐに使えます。

基本的な SOAP リクエスト

curl -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ord="http://example.com/orders">
  <soap:Header/>
  <soap:Body>
    <ord:GetOrder>
      <ord:OrderId>12345</ord:OrderId>
    </ord:GetOrder>
  </soap:Body>
</soap:Envelope>'

HTTP ヘッダーの完全表示

-v フラグで HTTP 通信の全容が確認でき、SOAPAction の不一致や Content-Type の問題の診断に重要です:

curl -v -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d @request.xml

リクエストとレスポンスの両方のヘッダーが出力されます:

> POST /OrderService HTTP/1.1
> Content-Type: text/xml; charset=utf-8
> SOAPAction: http://example.com/GetOrder
>
< HTTP/1.1 200 OK
< Content-Type: text/xml; charset=utf-8
< Content-Length: 847

XML レスポンスの整形

SOAP のレスポンスは通常、改行やインデントのない XML の塊です。xmllint にパイプして読みやすくします:

curl -s -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d @request.xml | xmllint --format -

リクエストとレスポンスの保存

# HTTP ヘッダー付きでレスポンスを保存
curl -v -X POST https://api.example.com/OrderService \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/GetOrder" \
  -d @request.xml \
  -o response.xml \
  2> headers.txt

# レスポンスの差分比較
diff <(xmllint --format response-before.xml) \
     <(xmllint --format response-after.xml)

SOAP 1.1 と 1.2 の違い

SOAP 1.2 では Content-Type が変わり、SOAPAction ヘッダーが action パラメータに置き換わります:

# SOAP 1.1
curl -X POST https://api.example.com/Service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: http://example.com/DoSomething" \
  -d @request.xml

# SOAP 1.2
curl -X POST https://api.example.com/Service \
  -H "Content-Type: application/soap+xml; charset=utf-8; action=http://example.com/DoSomething" \
  -d @request.xml

Fiddler によるデバッグ

Fiddler は HTTP プロキシとして動作し、アプリケーションと SOAP サービス間のすべてのトラフィックをキャプチャします。手動リクエストだけでなく、実際のアプリケーションからの本番同等のトラフィックを検査できる点が強みです。

SOAP トラフィックキャプチャの設定

  1. Fiddler Classic (Windows) または Fiddler Everywhere (クロスプラットフォーム) をインストール
  2. アプリケーションが Fiddler のプロキシ (デフォルト: 127.0.0.1:8888) を使用するよう設定
  3. Java アプリケーションの場合、JVM プロキシを設定:
java -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=8888 \
     -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=8888 \
     -jar your-app.jar

.NET の場合、app.config に追加:

<system.net>
  <defaultProxy>
    <proxy proxyaddress="http://127.0.0.1:8888" bypassonlocal="False"/>
  </defaultProxy>
</system.net>

HTTPS トラフィックの復号

多くの SOAP サービスは HTTPS を使用しています。Fiddler は中間者プロキシとして動作し、HTTPS トラフィックを復号できます:

  1. Tools > Options > HTTPS を開く
  2. Decrypt HTTPS traffic にチェックを入れる
  3. プロンプトが表示されたら Fiddler のルート証明書を信頼する
  4. Java アプリケーションの場合、Fiddler の証明書を Java キーストアにインポート:
# Fiddler のルート証明書をエクスポート
# (Fiddler: Tools > Options > HTTPS > Actions > Export Root Certificate)
keytool -import -trustcacerts -alias fiddler \
  -file FiddlerRoot.cer \
  -keystore "$JAVA_HOME/lib/security/cacerts" \
  -storepass changeit

Fiddler での SOAP エンベロープ検査

トラフィックをキャプチャした後、セッションを選択して以下のインスペクターを使用します:

  • Raw タブ: ヘッダーを含む完全な HTTP リクエスト/レスポンス
  • XML タブ: パースされ整形された SOAP エンベロープ (読みやすい)
  • Headers タブ: SOAPAction、Content-Type、認証ヘッダーの確認

リクエストの改変と再送

Fiddler の Composer タブでは、キャプチャしたリクエストを修正して再送できます。アプリケーションコードを変更せずに異なるパラメータ値やヘッダーの組み合わせをテストでき、非常に有用です。

  1. キャプチャした SOAP リクエストを右クリック
  2. Replay > Reissue and Edit を選択
  3. SOAP ボディやヘッダーを修正
  4. 実行してレスポンスを比較

Wireshark によるデバッグ

Wireshark は HTTP より下のネットワークパケットレベルで動作します。TCP レベルの問題を診断する必要がある場合や、Fiddler の HTTP プロキシ方式が使えない場合 (非 HTTP SOAP トランスポートや組み込みデバイスなど) に使用します。

SOAP トラフィックのキャプチャ

  1. Wireshark を起動し、正しいネットワークインターフェースを選択
  2. キャプチャフィルターでトラフィックを限定:
# 宛先ホストでフィルタ
host api.example.com

# ポートでフィルタ
tcp port 8080
  1. キャプチャ後にディスプレイフィルターで SOAP を抽出:
# SOAP を含む HTTP トラフィックのみ表示
http contains "Envelope"

# 特定のエンドポイントでフィルタ
http.request.uri contains "OrderService"

# SOAP フォールトのみ表示
http contains "soap:Fault"

TCP レベルの問題分析

Wireshark は HTTP レベルでは見えない問題を明らかにします:

  • TCP 再送信: ネットワークの不安定さを示す (フィルタ: tcp.analysis.retransmission)
  • RST パケット: 接続が強制切断された (フィルタ: tcp.flags.reset == 1)
  • Window size zero: サーバーまたはクライアントのバッファが満杯 (フィルタ: tcp.window_size == 0)

これらの TCP 問題は SOAP クライアント側ではタイムアウトや間欠的な障害として現れますが、HTTP レベルのツールでは診断が不可能です。

Wireshark での HTTPS 復号

HTTPS トラフィックの復号には、アプリケーション起動前に SSLKEYLOGFILE 環境変数を設定します:

# Linux/macOS
export SSLKEYLOGFILE=/tmp/ssl-keys.log

# Windows
set SSLKEYLOGFILE=C:\temp\ssl-keys.log

Wireshark 側の設定:

  1. Edit > Preferences > Protocols > TLS を開く
  2. (Pre)-Master-Secret log filename に上記のパスを設定
  3. キャプチャを再開始すると HTTPS トラフィックが復号される

SoapUI によるデバッグ

SoapUI は SOAP テスト専用に設計されたツールです。WSDL を読み込み、リクエストテンプレートを生成し、スキーマに基づいてレスポンスを検証します。

WSDL ベースの迅速なデバッグ

  1. 新しい SOAP プロジェクトを作成し、WSDL URL を貼り付ける
  2. SoapUI がすべてのオペレーションのリクエストテンプレートを生成
  3. パラメータを入力し、リクエストを送信してレスポンスを検査

SoapUI の主なデバッグ機能

Raw メッセージビュー: HTTP ヘッダーを含む送受信された実際の XML を表示。

SOAP Fault 分析: SOAP フォールトをハイライトし、fault code、fault string、detail 要素を個別に表示。

アサーションベースのテスト: 期待値を定義し、明確な合格/不合格の結果を取得:

Contains アサーション: レスポンスに "OrderId" が含まれる
XPath Match: //ord:Status = "Confirmed"
Not SOAP Fault: レスポンスが SOAP フォールトでない

モックサービス: 実際のエンドポイントに接続せずにテストするための SOAP サービスのローカルモックを作成。問題の再現を隔離環境で行う際に有用。

よくある問題のデバッグパターン

パターン 1: 「The Server Did Not Recognize the HTTP Header SOAPAction」

curl でのデバッグ:

# WSDL から正しい SOAPAction を確認
curl -s "https://api.example.com/Service?wsdl" | grep -i "soapaction"

# 正しい値でテスト
curl -v -X POST https://api.example.com/Service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H 'SOAPAction: "http://example.com/IService/GetOrder"' \
  -d @request.xml

SOAPAction ヘッダー内のダブルクォートに注意してください。一部のサーバーではダブルクォートが必須です。

パターン 2: XML の代わりに HTML が返される

SOAP レスポンスの代わりに HTML エラーページを受け取る場合:

# レスポンスの Content-Type を確認
curl -v -X POST https://api.example.com/Service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -d @request.xml 2>&1 | grep "< Content-Type"

# text/html が返される場合、ロードバランサーやエラーページに
# 到達している可能性が高い

パターン 3: 間欠的なタイムアウト

Wireshark で TCP 再送信を確認します:

tcp.analysis.retransmission && ip.addr == <service-ip>

再送信が確認できれば、問題はアプリケーションレベルではなくネットワークレベルにあります。

SOAPless による解決

SOAP リクエストのデバッグが困難なのは、冗長な XML、名前空間だらけのエンベロープ、不透明なエラーメッセージを扱わなければならないためです。SOAPless は SOAP サービスを REST JSON API に変換することで、このデバッグの負担を大幅に軽減します。

XML エンベロープの組み立てや生の SOAP レスポンスの解析の代わりに、クリーンな JSON を送受信できます。エラーが発生した場合も、エラーメッセージは明確なエラータイプとコード付きの JSON 形式で返されます。XML フォールトのパースは不要です。SOAPless のダッシュボードから直接オペレーションをテストでき、送信した JSON リクエストと生成された SOAP XML の両方が確認できるため、Fiddler や Wireshark なしでも完全な可視性が得られます。

また、登録されたすべての WSDL に対して OpenAPI 3.0 ドキュメントが自動生成されるため、Postman やブラウザの DevTools など、標準的な REST ツールでデバッグが可能になります。

ブログへ戻る