SOAP連携、
よく分からないまま
既存コードを追った。

Windchill案件で SOAPによる外部連携を触りました。

ただ、 プロジェクトの中心は SOAPそのものではありませんでした。

Windchill上のデータを扱ったり、 条件によって処理を分けたり、 業務ロジックを組んだりする方が 自分の担当としては重要でした。

その処理の一部に、 外部システムとの連携があって、 そこでSOAPが出てきた。

「SOAPをやる案件」ではなく、
「必要な処理の中にSOAPもあった」

自分の中では、 そのくらいの位置づけでした。

SOAPの処理を見ても、 最初は何をしているのか きれいには理解できませんでした。

XMLっぽいものがある。

外部に何かを送っている。

戻り値もある。

でも、 SOAPの仕様を一から理解して 全体像を整理したわけではありません。

それより先に、 実装しなければならない処理がありました。

幸い、 既に動いているSOAP連携の 元コードがありました。

なので、 まずその処理を追いました。

どの値を渡しているのか。

どこで連携処理を呼んでいるのか。

何が返ってくるのか。

返ってきた値を その後どう使っているのか。

「この形で呼べばいいのね」

必要な部分だけ分かれば、 今回の実装は進められます。

そのため、 元コードの使い方を真似しながら 対応しました。

もちろん、 SOAPの仕組みを全部理解した方が 技術的にはきれいです。

でも現場では、 それだけに時間を使えるとは限りません。

今回変更する場所はどこか。

どの値を渡せばいいか。

どの処理を呼べばいいか。

戻ってきた値を どう扱えばいいか。

そこを確認して、 必要な処理を作る。

理解していないものを、
分かったふりはしない。
でも必要なところまでは追う。

当時は、 そんな触り方でした。

この経験で SOAPに詳しくなったかと言われると、 そうでもありません。

今でも、 SOAPの細かい仕様を きれいに説明しろと言われると怪しいです。

ただ、 既存コードを追って、 必要な値の流れを確認して、 同じ形で連携処理を組むことはできました。

実務では、 こういう進め方になることもあります。

技術を全部理解してから 実装を始められるとは限らない。

既存処理を手掛かりに、 必要な範囲だけ理解して 先へ進むこともあります。

Windchill案件を思い返すと、 SOAPを触ったことより、 業務ロジックを追った記憶の方が強いです。

どこから値が来るのか。

どの条件で処理が変わるのか。

どのデータを使うのか。

どこへ渡すのか。

SOAPは、 その流れの途中にあった 外部連携の一つでした。

だから、 SOAP単体の知識よりも、 処理全体の中でどこに連携があるのか を見る方が重要でした。