外部システムとの連携では、相手側にも検証環境が用意されているとは限りません。
私がアプリSEとして関わった案件でも、HULFT、FTP、RESTによる連携で、相手側に検証用のサーバー自体がないケースを何度も経験しました。
その場合でも、IPアドレスやポート、ファイアウォールの申請内容、設定値など、本番前に確認できることはあります。
一方で、実際に稼働後に使用する送信先へファイルやデータを送るところまでは、確認できないまま本番を迎えることもありました。
この記事では、相手側に検証環境がないときに、どこまで事前確認し、何が最後まで確認できずに残ったのかを実務経験から紹介します。
HULFT・FTP・RESTで検証環境がないケースがあった
こうしたケースは一度だけではなく、複数の案件で経験しています。
相手側に検証サーバーがない場合、私が関わった案件では、本番と同じ送信先を使ってすべての連携を事前確認することはできませんでした。
そのため、事前に確認できる部分と、本番近くまで確認できない部分を分けて進めていました。
総合テストで外部システムとの連携をどのように確認していたかは、総合テストで確認していたことでも紹介しています。
IP・ポート・接続方向などは事前に確認していた
実際のデータ連携までできなくても、確認できる項目はあります。
私が事前に確認していたのは、たとえば次のような内容です。
- 送信元IPアドレス
- 接続先IPアドレス
- ポート
- プロトコル
- 送受信方向
- 実施時期
- UTF-8などの文字コード
- ファイアウォール申請内容
- 各種設定値
これらについて相手先とも認識を合わせ、申請内容や設定値に食い違いがないか確認していました。
また、手順書を作成した後には、実際の作業を想定した机上確認も行っていました。
実通信できない部分が残る場合でも、設定値や前提条件について事前に確認できるところは確認しておくという進め方です。
複数社が関わるとファイルやデータの数まで違うことがあった
外部システム連携では、設定値だけでなく、相手先との認識そのものも確認していました。
特に複数社が関わる案件では、
「こちらが想定しているファイルやデータの数と、相手側が想定している数が違う」
ということもありました。
一社とのやり取りだけであれば比較的整理しやすいのですが、複数社が間に入ると、どこかで認識がずれていることがあります。
そのため、
- どのファイル・データをやり取りするのか
- どちらからどちらへ送るのか
- いくつやり取りするのか
- 実施によってどこへ影響するのか
といった点についても確認していました。
通信設定が正しくても、連携対象そのものの認識が違えば問題になるため、ここはかなり注意していました。
Test-NetConnectionでポートまで到達できるか確認していた
相手側が問題ない場合には、本番環境に対してポートまで通信できるかを確認することもありました。
Windows環境では、たとえば次のように Test-NetConnection を使っていました。
Test-NetConnection [接続先] -Port [ポート番号]
Microsoftの公式資料でも、-Portは指定したリモートコンピューターのTCPポートへの接続性を確認するためのパラメーターとして説明されています。
Microsoft Learn「Test-NetConnection」
ただし、ここで確認できるのは、そのポートへ通信できるかという部分です。
ファイル転送やRESTの処理が最後まで正常に成立するかまで確認できるわけではありません。
私の場合も、まず通信経路として相手側のポートまで到達できるかを見るための確認として使っていました。
本番環境のテスト用フォルダやURLへ送ることもあった
相手側に検証サーバーがない場合でも、相手先と調整したうえで、本番環境内にテスト用の送信先を用意できることがありました。
たとえば、
- テスト用フォルダ
- テスト用URL
などです。
そこへ疎通確認用のファイルやデータを送信します。
送信する内容も、本番データではなくテスト用でした。
これによって、ファイアウォールやポートを含めて、実際に相手側まで通信できるかを確認していました。
ただし、テスト用の場所へ到達できたからといって、稼働後に使用する実際の送信先まで確認できたわけではありません。
実際に使う送信先までは確認できないことも多かった
実際に稼働後に使用するフォルダやURLへ、本番と同じ形でファイルやデータを送る確認までは、私が経験した案件では本番前にできないことが多くありました。
一方、システムリプレースの場合には、新しい本番環境がまだ稼働前であれば確認できるケースもありました。
現行システム側に影響せず、相手側を含めて問題ないと判断された場合には、稼働前の環境で実際の送信先への送信まで確認することもありました。
これは私が経験した案件での進め方であり、本番環境を使った事前テストを一般的な方法として勧めるものではありません。
実際にはポートやファイアウォールでつながらないこともあった
事前に申請や設定値を確認していても、実際に通信すると接続できないことはありました。
私の経験では、
- ポートが開いていない
- Windowsファイアウォールで通信できない
- AWS側の通信制御設定で通信できない
といったことがありました。
また、接続そのものはできても、データ量が多いときに処理に時間がかかり、タイムアウトで通信が途中で切れたこともありました。
そのため、疎通が取れたことと、実際のファイル・データ連携が最後まで正常に終わることは別として考えていました。
一番怖かったのはテストではつながったのに本番でつながらないこと
外部システムとの連携で特に怖かったのは、
「以前テストしたときはつながっていたのに、本番ではつながらない」
というケースです。
実際に、事前の確認では通信できていたにもかかわらず、本番稼働時に接続できなくなることがありました。
そこで再度疎通を確認すると、以前は通っていたはずの通信が通らなくなっていることもあります。
こうなると、
「何が変わったのか」
というところから、ファイアウォールやポート、相手側の設定などを改めて確認することになります。
私にとっては、一度テストでつながったことだけでは、本番時の接続まで安心できないという点が、外部システム連携で特に怖いところでした。
まとめ：確認できない部分を把握したまま本番へ進むこともあった
相手側に検証環境がない場合でも、IPアドレス、ポート、送受信方向、ファイアウォール申請、設定値など、事前に確認できることはあります。
さらに、条件が整えば、本番環境のテスト用フォルダやURLを使って、通信経路まで確認することもありました。
それでも、実際に稼働後に使用する送信先への通信など、本番まで確認できない部分が残ることがあります。
私が経験した案件では、確認できる範囲を事前にできるだけ確認し、確認できていない部分を把握した状態で本番へ進むという形になっていました。
