梅雨もあけ、暑い日が続いています。
私は関西の出身なのですが、関西の暑さは湿気が多くて、東京の暑さは日差しが強い感じですね。
私には東京の暑さのほうがつらいです・・・
皆さま、こまめな水分補給で熱中症にはくれぐれもお気を付け下さいね。

さて、先月から連載をはじめたHULFTの使い方、使われ方をご紹介する「HULFT小話」。
ファイル転送の運用でよくある課題をHULFTだとどのように解決するのか、そのヒントをお伝えしてまいります！！

皆さん、ファイル転送基盤を構築したら、運用設計を行いますよね。正常に処理が終了することはもちろんですが、エラーが発生する場合を想定しますよね。
ファイル転送時にエラーが発生した場合、確実なエラー検知はもちろん、運用に応じたリカバリ処理の実行が必要です。
例えば、破損ファイルはきちんと削除して、何回かは自動でリトライしてほしいとかありますよね。
あと、リトライが成功しなかったら、エラーが起こったことを運用者にメールで通知したいという運用もよくあります。
夜間の処理でエラーが起こった場合、朝まで気がつかなかった！なんてことがあったらもう大変です。

ファイル転送基盤をFTPで構築した場合、エラー検知、リカバリ処理の実装は大変工数がかかってしまうんです。
クライアント側であれば、コマンドの戻り値を確認してエラーの検知はなんとかできます。
一方サーバ側は、ファイルがきちんと到着しているかは自分から見に行かないと分かりません。
なので、まずは監視の仕組みを作らないといけません。常駐プログラムを作って、監視をさせて次にエラーハンドリングの仕組みを考えます。
それからさらにリトライなどのリカバリ処理を作っていくことになります。
また、業務によって考慮点やリカバリの運用って違うので、仕様固めから大変ですね。
大変な作業だなということは想像がつきますよね・・・

ではHULFTの場合はどうでしょう。
HULFTは監視の仕組みや常駐プログラムを別で作っていただく必要はありません。
エラー検知はもちろんのこと、リカバリ処理もHULFTがもともと持っている機能です。
履歴は出力される完了コードによって体系化されていますので、ただファイルの送達確認ができるだけではなく、どこで、どんなエラーが発生しているのかがすぐにわかります。

また、エラーを検知したときもネットワークのエラーであれば自動的にリトライするように設定できます。
ネットワークの瞬断で、一時的に不通になることはよくあることなんですが、そんなときもHULFTは勝手にリトライをして正常終了してくれます。
ファイル転送に失敗した場合のファイルは、そのまま残しておくことも、不正なデータとして自動削除することもできます。
運用者へのメール通知も、HULFTのオプション製品HULFT Scriptを使えば、GUIでフローを描くことで簡単に行えます。

このようにHULFTなら、ほとんど工数をかけずに設定だけでエラーの検知、リカバリ処理を行うことが出来るのです。

HULFTのエラー時処理についてご紹介してきましたが、これからファイル転送の仕組みをご提案されたり、ご担当になるお客様がセミナーにいらっしゃると、 FTPとHULFTの比較、課題の解決ポイントをよくご質問いただきます。少しでも参考になればうれしいです。

また次回もHULFTの活用ポイントをお届けしていきます。
次回の配信は、9月第二週の予定です。ぜひ、お楽しみに！！