6月に入り、本格的な暑さの到来です。
合わせて期初のせわしない状況も落ち着き、ほっと一息つける頃ではないでしょうか?
皆様、熱中症など体調にはくれぐれもお気を付け下さいね。

今回のHULFT小話は、前回に引き続きHULFTによるファイル転送課題の解決事例をご紹介します。
FTPで行っていたファイル転送業務をHULFTに置き換え、ファイル転送時間の大幅な短縮、業務リスクの低減を実現した事例です。
それでは、お客様の課題からその解決方法を見ていきましょう！

こちらのお客様では、業務システムと倉庫管理システムとのファイル転送をFTPにより行っていました。
FTPによるファイル転送ではポーリングの待ち時間が重なってしまうと、場合によっては１回のデータ転送に30分程度もかかってしまうことがあり、入庫・出荷指示が完了するまでにタイムラグが発生して、スムーズに業務が遂行できないという問題がありました。
倉庫管理の課題として、在庫の出入庫管理はよくあがりますよね。
リアルタイムに状況が更新されないと、不要な仕入れや在庫の移動といった“ムダ”を発生させてしまうことになるので、正確な管理が求められます。

また、FTPだとファイル転送は正常に終了していても、データの中身が欠落していたりと正しいデータとして届いていないこともありました。
当コラムでも何度が紹介しましたが、FTPはファイルの送信した内容が正しいか（一致しているか）を保証してくれません。
送ることはできたけど内容が間違っていて、その誤った情報をもとに荷物を出荷してしまうとお客さまに迷惑がかかってしまい、会社としても信用問題になってしまいます。
さらに、ファイル転送にトラブルが発生すると、後続処理にも影響が出てしまい、その復旧作業に多くの手間と時間がかかっていました。
間違ったデータで連携してしまうと、在庫管理DBなど関連する情報をロールバックしたり出荷指示の取り消しを行ったり、出荷してしまった後になるとお客様へご迷惑をおかけすることになりますよね。
このようにFTPではファイルを送ることはできるけど、確実性や信頼性で不安定になる運用を、改善する必要がありました。

HULFTは接続クライアントごと（転送ファイル単位）にIDを割り振り振ることで、ID単位でファイル転送開始のタイミングをコントロールすることができ、ポーリングの順番待ちをすることなくファイルを送り始めることができます。

ポーリングを行わないので接続単位の待ち合わせをなくし、ネットワークトラフィックも軽減できます。
HULFTであれば同時ファイル転送数も多重度設定で調整できるので、ネットワークの状態に合わせて、負荷を分散させることができます。

さらに、ファイルトリガ機能やHULFT Scriptはファイルの状態を監視し、ファイルが更新されたタイミングで、自動的にファイル転送を行うこともできるため、ファイル転送業務の最適化に効果がでます。

送り元のタイミングで配信可能。データが作成でき次第配信処理を実行。

受け取り側のタイミングでリトライ可能。ポーリングのように常時ネットワークトラフィックが流れることがない。

ファイルトリガー機能を使って、配信処理の自動化と配信タイミングのコントロールと実行管理をHULFTによる一元管理

スケジュール機能を使って、要求発行のスケジューリングと自動化。スケジュール実行は配信側からでも、集信側からでもよい

HULFTには、送ったデータが正しく受信できているかどうかをチェックする整合性検証の機能が備わっています。
配信側のデータと集信側のデータの不一致が検知されるとエラーを通知します。
エラーの通知は配信側、集信側の両方に通知されるので、問題の検知を即座に行うことができ、エラー個所の特定やリカバリも短時間で行うことができます。

今回の事例のお客様は、問題があるたびに不具合箇所を特定するために、品番から突合せを行って修正後に再送信を行っていましたが、例えばHULFTのレコート件数でチェックしている場合は、何レコード目でエラーになったかがファイル転送の履歴からすぐにわかるので、問題のある個所の特定がとても速くなります。

倉庫管理業務では、出荷情報を更新すると同時に、出荷指示、在庫DB更新、売り上げDB更新など、さまざまなデータやシステムと連携することがありますよね。
これらの処理は自動化されていることが多く、ファイル転送、データ連携に不具合があると、多大な影響が発生してしまいます。

HULFTはファイル転送と後続システムとの連携のための仕組みとして、ジョブ連携機能を持っています。
ジョブ連携機能は、ファイル転送の正常、異常で起動するジョブを分けて登録できるため、簡単なシステム連携フローを作ることができます。

今回の事例のお客様は、データの欠落など転送にトラブルが発生した場合、転送後の後続処理を自動でストップするような仕組みにしたので、トラブル時の業務への影響を最小限に抑えることができました。

ファイル転送にトラブルが発生した場合、後続の処理をストップさせたいという時は、正常時ジョブに処理を設定しておけば、転送に異常が発生した場合は後続処理は起動しないという仕組みを作ることができます。
もっと細かく条件を分けたい場合は、HULFT Scriptを使って連携フローを描くこともできます。

FTPによるポーリングの待ち時間がなくなったため、ファイル転送時間が最大でも3分に短縮され、入出庫情報がタイムリーに同期できるようになりました。

データの整合性検証により、データの不具合によるトラブル箇所の特定や復旧作業の手間を大幅に削減することができました。
またトラブル発生時は、後続の処理を自動でストップさせることで、トラブルの影響範囲を最小限に抑えることができました。
そのため結果的にシステムの保守費用も減り、コストの削減にもつながりました。

前回の小話に引き続きHULFTの導入事例をご紹介しました。
FTPでのファイル転送、HULFTのファイル転送、それぞれ利用シーンによってメリットはあります。
FTPは初期費用はタダですし、何か分からないことがあればネット上にもノウハウがたくさんありますよね。
しかし、確実にデータを送信したい、トラブル発生時にはできるだけ効率的に復旧したいなど、業務を効率化したい場合はHULFTによるメリットも実感することができます。

他にも、ファイル転送だけでなく、システム連携やデータ連携の課題解決に関する事例をご紹介しているのでご興味のある方はぜひ「HULFT.com」をご覧ください。

全11回連載したHULFT小話は、今回で最終回となります。
ファイル転送にまつわる課題やHULFTの機能、事例などちょっとした小話を掲載してきました。
ファイル転送は一見シンプルな処理に見えますが、業務で使用する場合は、タイミングやログの管理、万が一エラーが起こった時の対処など気にしておくべき点は意外と多く、奥が深い処理でもあります。
ファイル連携の方法はいくつかありますが、どんな環境で、どんな要件があるのかに応じて最適な方法がありますよね。
このHULFT小話が、ファイル転送の課題解決のお役に立てていたら嬉しいです。


今後も製品紹介や課題解決型のセミナーやイベントを開催してまいりますのでファイル転送、データ連携に関して困ったこと知りたいことがあればお気軽にご参加ください。