SoapUI は便利です。SOAP 連携がそもそも通るのかを確かめるには、かなり強い道具です。
ただし、SoapUI で通ったリクエストをそのまま本番コードへ貼り続けるのは、別の話です。
ありがちな流れ
よくあるのは次の流れです。
- 誰かが WSDL を SoapUI に読み込む
- なんとか 1 本だけ通るリクエストを作る
- その XML をアプリ、バッチ、補助スクリプトへ貼る
最初の数日は速く見えますが、その後の保守コストが急に重くなります。
後から効いてくる問題
SoapUI のリクエストには、見落としやすい契約依存の前提がたくさん含まれます。
- namespace の書き方
- どの binding と SOAP version を使ったか
- 認証ヘッダーの形
- operation wrapper の形
- その環境だけで通る endpoint 前提
これが複数の repo やジョブに散ると、小さな変更でも一気に面倒になります。
問題は XML が読みにくいことだけではない
本質は責任の置き方です。
本番コードがコピーした envelope に依存している時点で、各チームが SOAP 契約の一部を手作業で保守している状態になります。
だから、現場では次のような会話が起きがちです。
- 「SoapUI では通るのにアプリだと落ちる」
- 「夜間バッチだけ古い wrapper のまま」
- 「staging と production で XML が違う」
SoapUI をどう使うのが健全か
SoapUI が強いのは次の用途です。
- WSDL をすばやく読む
- サービスが生きているか確かめる
- 既知の正常リクエストを 1 本取る
- デバッグ時に生 XML を比較する
つまり、契約の確認や切り分けには強いですが、すべての利用側に配る本番インターフェースとしては向いていません。
もっとましな境界
まず SoapUI で契約を確認し、その後は契約依存の処理を 1 つの連携境界へ寄せる方が健全です。
そうすると、利用側には次を渡せます。
- REST JSON の入口
- 認証や binding の癖を吸収する場所
- OpenAPI
- ダッシュボード上のテスト導線
これでようやく、「SOAP が一度通った」から「連携を保守できる形にした」へ進めます。