DEV Community

Cover image for ApidogでSOAPとWSDLウェブサービスをテストする方法
Akira
Akira

Posted on • Originally published at apidog.com

ApidogでSOAPとWSDLウェブサービスをテストする方法

SOAPエンドポイントを手渡されたとします。経理チームが使い続けている通貨換算ツールや、パートナーが.NETで運用する注文管理Webサービスかもしれません。必要なのは、呼び出しが成功することだけではありません。契約どおりのレスポンスが返ることを確認し、周辺コードの変更後もその動作を継続的に検証できる状態にすることです。SOAPでは、完全なXMLエンベロープ、適切なContent-Type、操作を定義するWSDLを扱う必要があるため、REST向けツールだけでは作業しにくい場合があります。

今すぐApidogを試す

Apidogでは、REST、GraphQL、gRPCと同じワークスペースでSOAPおよびWebServiceリクエストを扱えます。この記事では、次の2つの方法を実装手順として解説します。

  1. SOAPリクエストを手動で作成・送信する
  2. WSDLをインポートして操作と環境を生成する

プロトコルごとの使い分けは、REST、GraphQL、gRPC、およびSOAPの比較を参照してください。SOAPエンベロープの正式な仕様はW3C SOAP仕様で確認できます。

SOAPとは何か、なぜ別の扱いが必要なのか

SOAP（Simple Object Access Protocol）は、異なるプラットフォームや言語間で通信するためのXMLベースのプロトコルです。たとえば、Javaクライアントと.NETサービスは、実装の詳細を共有しなくても、同じサービス契約を通じて通信できます。

SOAPテストでは、次の3点を押さえます。

  • リクエストとレスポンスはJSONではなくXMLドキュメントである
  • 通常はHTTPまたはHTTPS経由で送信する
  • XML構造、名前空間、検証ルールが厳格である

XMLの構文を確認したい場合は、MDNのXMLリファレンスが役立ちます。

SOAPが現在も使われる代表的な場面は、クロスプラットフォーム統合、レガシーシステム連携、WS-Securityを使う認証・暗号化付きメッセージングです。そのため、RESTのようにURLとJSONだけを送るのではなく、以下を正しく組み立てる必要があります。

  • 正しいContent-Type
  • SOAPエンベロープでラップしたXMLボディ
  • サービスが要求する名前空間と操作名
  • XMLレスポンスを検証するアサーション

SOAPエンベロープとXMLの関係は、SOAP APIとXMLの解説も参照してください。

始める前に

SOAPまたはWebServiceリクエストを送るには、Apidog 2.1.31以降が必要です。古いバージョンではサポートされていないため、まずApidogを開いてバージョンを確認し、必要に応じて更新してください。

実行前に、次の情報を用意します。

  • サービスのエンドポイントURL
  • 呼び出す操作名
  • 操作に必要なパラメーター
  • WSDLファイル（ある場合）

WSDLを持っている場合は、後述する方法で.wsdlまたは.xmlファイルとしてインポートします。WSDLの仕様についてはWSDL 2.0を確認できます。

パスA: SOAPリクエストを手動で送信する

この方法は、エンドポイントURLと操作名が分かっていて、特定のSOAP操作をすぐに試したい場合に向いています。

ステップ1: Content-Typeを設定する

SOAPリクエストでは、Content-Typeを明示的に設定します。代表的な値は次の2つです。

Content-Type: text/xml; charset=utf-8
Enter fullscreen mode Exit fullscreen mode 
Content-Type: application/soap+xml
Enter fullscreen mode Exit fullscreen mode

一般的には、SOAP 1.1ではtext/xml; charset=utf-8、SOAP 1.2ではapplication/soap+xmlが使われます。ただし、最終的には対象サービスのWSDLまたはドキュメントに従ってください。

Apidogでは、リクエストのHeadersセクションで次のように追加します。

Header Value
Content-Type text/xml; charset=utf-8

コンテンツタイプに関するエラーが返る場合は、サービス仕様を確認したうえで、もう一方の値に切り替えます。

ステップ2: ボディ形式をXMLに設定してエンベロープを入力する

リクエストのボディ形式をxmlに設定し、SOAPエンベロープを入力します。

以下は、公開されている数値変換サービスのNumberToWords操作を呼び出す例です。ubiNumに1234を渡します。

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:web="http://www.dataaccess.com/webservicesserver/">
  <soap:Body>
    <web:NumberToWords>
      <web:ubiNum>1234</web:ubiNum>
    </web:NumberToWords>
  </soap:Body>
</soap:Envelope>
Enter fullscreen mode Exit fullscreen mode

ここで確認するポイントは次のとおりです。

  • soap:EnvelopeがSOAPメッセージ全体をラップする
  • soap:Bodyに実際の呼び出しを含める
  • web:NumberToWordsが操作名である
  • web:ubiNumが操作に渡す入力値である
  • xmlns:webの名前空間がサービス定義と一致している

名前空間は推測せず、WSDLまたはサービスドキュメントから確認してください。

ステップ3: リクエストを送信し、XMLレスポンスを確認する

リクエストを送信すると、レスポンスもSOAPエンベロープとして返されます。

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>
Enter fullscreen mode Exit fullscreen mode

このレスポンスでは、次を検証します。

  1. SOAPエンベロープが返っている
  2. NumberToWordsResponseノードが存在する
  3. NumberToWordsResultが期待値と一致する

実際のテストでは、レスポンス構造だけでなく、結果値にもアサーションを追加します。たとえば、通貨換算サービスなら換算結果が期待値または許容範囲に入ること、注文サービスならステータスが許可された値であることを検証します。

追加のSOAPサンプルはwebservice.apidog.ioでも確認できます。

手動リクエストの実用例

通貨換算サービスを呼び出す場合、NumberToWordsをConvertCurrencyに置き換え、必要な値をネストした要素で渡します。

<soap:Body>
  <svc:ConvertCurrency>
    <svc:fromCurrency>JPY</svc:fromCurrency>
    <svc:toCurrency>USD</svc:toCurrency>
    <svc:amount>10000</svc:amount>
  </svc:ConvertCurrency>
</soap:Body>
Enter fullscreen mode Exit fullscreen mode

注文管理サービスなら、GetOrderStatusに注文IDを渡します。

<soap:Body>
  <svc:GetOrderStatus>
    <svc:orderId>ORD-12345</svc:orderId>
  </svc:GetOrderStatus>
</soap:Body>
Enter fullscreen mode Exit fullscreen mode

手順は共通です。

  1. Content-Typeを設定する
  2. XMLエンベロープを作成する
  3. リクエストを送信する
  4. レスポンスXMLのノードと値を検証する

パスB: WSDLをインポートしてエンドポイントを生成する

複数の操作を持つSOAPサービスでは、手動でエンベロープを作り続けるより、WSDLをインポートする方が効率的です。

WSDLには通常、次の情報が含まれています。

  • 操作名
  • 入力・出力の構造
  • サービスのアドレス
  • バインディング情報

Apidogでのインポート手順は次のとおりです。

  1. Settingsを開く
  2. Data Importを選択する
  3. WSDLを選択する
  4. .wsdlまたは.xmlファイルをアップロードする
  5. 解析されたAPIエンドポイントのプレビューを確認する
  6. Environmentsタブでサービスアドレスを確認する
  7. Confirmをクリックする
  8. 右上からインポートされた環境を選択する
  9. リクエストを送信する

インポート時に確認すべき2点

1. サービスアドレス

WSDLに書かれたサービスアドレスがステージング環境や古いホストを指している場合、すべてのリクエストが誤った環境へ送られます。

Confirmをクリックする前に、Environmentsタブで以下を確認してください。

  • ホスト名
  • プロトコル（HTTP/HTTPS）
  • ポート番号
  • パス
  • ステージング・本番などの環境差分

2. インポートした環境の選択

WSDLインポート後、ベースURLは自動作成された環境に設定されます。右上でその環境を選択しないと、ベースURLが適用されずリクエストが失敗する可能性があります。

インポート完了後は、各SOAP操作が呼び出し可能なエンドポイントとして表示されます。手動でエンベロープを書く場合と同様に、XMLレスポンスに対してアサーションを設定できます。

SOAPプロジェクトを移行する場合は、SOAPプロジェクトのインポートに関するガイドも参照してください。

WSDLインポートでは、.wsdlまたは.xmlファイルのアップロードが文書化されています。URL指定やWSDL本文の貼り付けは文書化されていないため、ファイルをアップロードしてください。

SoapUIからの移行

既存のSOAPテストがSoapUIにある場合でも、すべてを手作業で再構築する必要はありません。保持しているWSDLをApidogにインポートすれば、同じ操作を呼び出し可能なエンドポイントとして扱えます。

移行後は、SOAP操作だけでなく、REST API、テストシナリオ、ドキュメントを同じプロジェクトで管理できます。

  • SOAPサービスをテストする
  • RESTエンドポイントをテストする
  • 複数リクエストをシナリオで連結する
  • APIドキュメントを管理する

SoapUIとの違いや移行時の観点は、Apidog対SoapUIで確認できます。

アサーションとテストシナリオ

1回の成功レスポンスは、サービスが応答したことを示すだけです。テストでは、レスポンスが契約を満たしていることを確認します。

SOAPレスポンスに対して、少なくとも次の項目を検証してください。

  • 期待するレスポンス操作ノードが存在する
  • 結果要素が存在する
  • 結果値が期待値、許容範囲、または許可リストに一致する
  • SOAP Faultが返っていない

たとえば、注文ステータスのレスポンスでは、statusが想定した値に含まれることを確認します。

PENDING
PROCESSING
SHIPPED
CANCELLED
Enter fullscreen mode Exit fullscreen mode

さらに、複数の呼び出しをテストシナリオとして連結できます。

  1. 注文を作成する
  2. 作成された注文IDを抽出する
  3. GetOrderStatusへ注文IDを渡す
  4. 返却されたステータスを検証する

Apidogでテストシナリオを作成する方法では、レスポンスから抽出した値を後続リクエストへ渡す方法を確認できます。

このパターンはSOAP専用ではありません。たとえば、SOAPで注文状態を取得し、REST APIで内部データを確認する、といった混在シナリオも構成できます。

WS-Securityを使う場合

セキュリティ保護されたSOAPエンドポイントでは、WS-Securityヘッダーを使うことがあります。この場合、wsseセキュリティブロックをSOAPエンベロープのヘッダーに含めます。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
  <soap:Header>
    <wsse:Security>
      <!-- サービス仕様に従った認証情報を設定 -->
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <!-- 操作 -->
  </soap:Body>
</soap:Envelope>
Enter fullscreen mode Exit fullscreen mode

送信手順は変わりません。

  1. 適切なContent-Typeを設定する
  2. WS-Securityヘッダーを含むXMLエンベロープを作る
  3. XMLボディとして送信する
  4. レスポンスまたはSOAP Faultを確認する

Apidog CLIでワークフローを自動化する

SOAPまたはWSDLから作成したリクエストをテストシナリオとして保存したら、Apidog CLIでコマンドラインから実行できます。

Node.js v16以降を用意し、CLIをインストールして認証します。

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Enter fullscreen mode Exit fullscreen mode

保存済みシナリオを環境ID指定で実行する例です。

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

主なオプションは次のとおりです。

オプション 内容
-t テストシナリオID
-e 環境ID
-r レポーター。cli、html、junitを指定可能

複数のレポーターを指定する場合はカンマ区切りで指定します。

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli,junit
Enter fullscreen mode Exit fullscreen mode

ドキュメントでは、CLIランナーが保存済みテストシナリオとスイートを実行すると説明されています。一方で、SOAPステップを含むシナリオのヘッドレス実行については明記されていません。そのため、CI導入前に対象シナリオで実行結果を確認してください。

CI/CDパイプラインへの組み込みは、Apidog CLI CI/CDガイドを参照してください。

よくある質問

SOAPリクエストにはどのContent-Typeを使用すべきですか？

text/xml; charset=utf-8またはapplication/soap+xmlを使用します。

一般に、SOAP 1.1では前者、SOAP 1.2では後者が使われます。ただし、サービスのWSDLまたは仕様を優先してください。コンテンツタイプエラーが発生した場合は、設定値とSOAPバージョンを見直します。

ApidogでSOAPをテストするために有料プランは必要ですか？

文書化されている要件はApidog 2.1.31以降であることです。SOAPまたはWSDLサポートについて、ティアやセルフホスト環境に関する制限は記載されていません。

URLからWSDLをインポートできますか？

文書化されているのは、.wsdlまたは.xmlファイルのアップロードです。URL指定やWSDL本文の貼り付けは文書化されていないため、ファイルを用意してアップロードしてください。

同じプロジェクトでSOAPとREST APIをテストできますか？

できます。ApidogではSOAP、REST、GraphQLなどを同じワークスペースで管理できます。テストシナリオでは、SOAP呼び出しとREST API呼び出しを連結できます。

GraphQLも扱う場合は、ApidogでのGraphQL APIテストを参照してください。

WSDLでインポートしたリクエストが間違ったサーバーへ送られます

主な原因は次の2つです。

  1. インポート時にEnvironmentsタブのサービスアドレスを確認しなかった
  2. 送信前に右上からインポート済み環境を選択していない

WSDLを再インポートするか、環境設定を確認し、正しいベースURLが適用されていることを確認してください。

まとめ

SOAPテストのためだけに別のレガシーツールを追加する必要はありません。Apidogでは、次の2つの方法でSOAPサービスを検証できます。

  • Content-Type、XMLボディ、SOAPエンベロープを手動で設定して送信する
  • WSDLをインポートして操作と環境を生成する

手動送信は単一操作の確認に向き、WSDLインポートは複数操作を持つサービスのテストと管理に向いています。どちらの場合も、XMLレスポンスにアサーションを追加し、サービス契約が維持されていることを継続的に検証してください。

Apidogをダウンロードして、WSDLをインポートし、SOAPサービスをRESTやGraphQLを含む他のAPIと同じテストワークフローに組み込みましょう。

Top comments (0)