HULFTによるファイル伝送の詳細設計の基本〜HULFT基本設定〜

2019年3月20日

サーバー間でファイルをやりとりする方法はFTPやSFTP、SCPなど様々な方法をとることができるが、今回はセゾン情報システムズが販売しているHULFTについて紹介しようと思う。

実際にHULFTを使うまでに必要な設定についても詳しく記載して残していくので、設計の際には参考にしてもらえると幸いだ。

HULFTとはサーバー間のファイル伝送ソフト

HULFTの設定に触れる前にHULFTとはなんぞや?と言うとセゾン情報システムズが提供しているシステム間ファイル伝送ソフトの事。

サーバー間のファイルのやりとりをスムースに実現してくれるソフトウエアだ。

よくサーバー間のファイルのやりとりはFTPやRCP、SFTPやSCPといったOSに標準搭載されているファイル転送プログラムを利用しがちだが、相手との接続方式や認証方法、利用できるコマンドの決定、サーバークライアントの決定など様々な設計が必要で、実際に企業間とかシステム間で実装しようと思うとハードルが高い場合がある。

そういった悩みを一気に解決してくれるのがHULFTというファイル伝送ソフトの強み。

実際に使ってみるとかなり便利で、ファイルの転送はHULFTに集約したいというぐらい簡単なため、本ページでは基本的な設定方法や設計で注意すべきことをまとめておこうと思う。

HULFT設計のポイント

HULFT設計を行う上でポイントとなるのは、相手側とどの値を合わせておかないといけないか?という事だ。

もちろん障害発生時の運用だったり、ファイルの中身だったりと決めることは多々あるのだが、本ページではHULFTが持つ設定値に特化して説明するため割愛する。

さて、HULFT導入におけるポイントだが、大きく分けると以下の5つに分類される設定を決めなければならない。

その5つと言うのが以下に当たる。

    1. HULFT基本設定
    2. HULFT詳細ホスト情報
    3. HULFT転送グループ情報
    4. HULFT集配信情報
    5. HULFTジョブ情報

上記の5つの項目に分けられる設定の内、HULFT基本設定に関してはHULFTプロダクト全体に関わる設定。

その他の設定は相手先や伝送業務に合わせて設定を作っていく項目になる。

以下で1つずつ説明していこうと思う。

HULFT基本設定の設定項目と設計ポイント

まずHULFTの基本設定として抑えておかなければならないのがHULFTインストール後の初期設定に必要となる基本設定。

いわゆるシステム動作環境設定としてHULFTサービスが動くための基本設定だ。

この基本設定ではインストールフォルダだったり転送する際の文字コード、HULFTホスト名といったものが設定されることとなり、ほとんどの設定項目がインストールした後の基本設定で設定することとなる。

設定値自体はHULFTプロダクトをインストールしたフォルダの配下にetcというフォルダがあり、その配下にhulenv.confというファイルが出来上がり、記載される項目となるため覚えておくと便利だ。(windows版ではhulenv.cnf)

ちなみにhulenv.conf(hulenv.cnf)に記載されている内容を読み込むのはHULFTサービスの起動時となるため、設定を変更した場合はHULFTサービスの再起動が必要となる且つHULFTプロダクト全体に影響する値ばかりなので、基本的には初期インストール時に決めてしまった後は変更しないという前提で設計する必要がある。

またインストール時に指定できる値は「ワークファイル作成パス」「fifoパス」「pidファイル作成パス」「転送コードセット」「自ホスト名」「HULFT言語動作」「日付形式」といった値のみで、その他の設定値はほとんどデフォルト値が設定される。

そのため、コード変換関連の設定や集配信時の動作、セキュリティといった設定についてはインストール後に設定を見ながら変更していく必要があるため気を付けたい。

インストールは簡単だが、設計を反映しようと思うとひと手間いるのがHULFTを導入する上で気を付けたい事とも言える。

基本設定で押さえておきたい自ホスト名~hulenv.confのmyhostnameを確認~

HULFTの基本設定で一番に押さえておきたい値がある。

それがmyhostnameという値。

この値、HULFTが独自にホスト名を持つための設定値となり、デフォルトではOSのホスト名を持ってくる。

自ホスト名という設定値としてHULFTのマニュアルでも説明されているのだが、この事実を知らないと接続相手とホスト名の話になったときにトラブルに繋がることもあるので気をつけたい。

通常はHULFTのホスト名としては上述したmyhostnameに設定されている値はOSホスト名だが、今まで触れたことないシステムの場合、誰かが上述した値を書き換えている可能性がゼロではないからだ。

そしてこのmyhostnameがどういった役割を持つかと言うと、相手先とのHULFT伝送をやりとりする際に認証に使っているという重要な役割を担っている。

HULFTを利用している人も意外にこの事実を認識していない場合があり、システムリプレースの際に考慮していなかったことから新システムで相手先との通信がうまくいかないといったトラブルを引き起こすこともあるので要注意だ。

先日筆者が担当した案件でも相手先が上述のmyhostnameの事を知らずに危うく変更せずにテストを迎えるところだった。

myhostnameの使われ方はHULFTのマニュアルにも明示的に記載がなく、お互いのホスト名を認識するといった記載しかないため要注意である。

更にmyhostnameを取り扱う上での注意点を以下にまとめておこうと思う。

hulenv.conf(hulenv.cnf)のmyhostnameを相手側HULFTの詳細ホスト情報へ記載してもらう

HULFTの自ホスト名は相手先のHULFTへ通知されるが、それをどこで認証しているのかと言うと

HULFTの詳細ホスト情報

という定義情報になる。

HULFT集配信定義を作成する際に必要となる情報だが、相手先のHULFT詳細ホスト情報に記載がないと集配信エラーとなるので要注意だ。

また詳細ホスト情報に記載する場合は大文字小文字を意識する為、相手先と自ホスト名が大文字小文字どちらなのかまで合わせるようにしよう。

HULFTメインフレーム版を扱う相手に対する自ホスト名のやりとりの注意点

上記でHULFTの自ホスト名は大文字小文字を意識すると記載したが、メインフレーム版の場合は大文字指定しかできず全て大文字で解釈される。

その為、自ホスト名が小文字だろうが大文字だろうがメインフレーム版では大文字として解釈する為、メインフレーム版HULFTの詳細ホスト情報への記載も大文字で記載する必要がある。

メインフレーム版の制約として覚えておこう。

メインフレームのhulenv.cnfにはホスト名の通知設定がある

更に注意をしておきたいのがメインフレーム版のhulenv.cnfにおける自ホスト名の取り扱い。

メインフレーム版の場合、大文字でしか登録ができないと上述したが、メインフレーム版HULFTが配信側になる際には、相手先へ自ホスト名を通知する際の大文字小文字を選択するオプションが存在している。

それが

HSTCHAパラメータ

HSTCHAがLだったら小文字、Uだったら大文字での通知となる為、相手先と合わせる必要がある。

大文字か小文字かを決定した上で相手先の詳細ホスト情報にホスト名を記載してもらうようにしよう。

コード変換の要件がないならコード変換関連設定はデフォルトのままでいい

HULFTを利用して伝送する際に気を付けたいのがコード変換の要件があるのかどうか。

もしHULFTを利用する際にコード変換を行う要件がないのなら、コード変換関連設定は一切無視してデフォルトのままにしておいていい。

その代わり、集配信定義を設計する際にはバイナリ転送となるように設定し、相手先にもバイナリ転送の設定で送ってもらうように設計することをおススメする。

そうすればデータの中身にHULFTが触れる事はなく、OSの違いを考慮する必要もなくなるため格段に設計、テストが楽になるのでおすすめだ。

集配信関連設定は集配信時の動作に違いが出てくるので要検討

集配信関連設定については設計時に決めた内容を反映する項目がいくつも設定されている。

例えば「転送グループチェック」の値では転送グループに指定された詳細ホスト情報に紐づいたホストからしか集信を受け付けないようにする設定ができたり、「暗号化方式」ではHULFTプロダクトを利用した暗号化をどの方式で実装するかどうかを指定できたり、「配信転送後異常時の処理」では配信転送が完了した後の動作を指定できる。

「転送グループチェック」の値では集信定義の中で転送グループが指定されていた場合に転送グループの設定を読み込んでチェックする場合には設定変更しなければならない。デフォルトでは集信定義の転送グループの値は一切有効にはならないため、指定していなくても動作する値となっているのだ。

「配信転送後異常時の処理」では配信完了後にデータを削除することができなかった場合にエラーとするかどうかを変更できる為、設計上エラーとしたいなら変更しなければならない。

上記のような意味で設計をよく理解し設定変更を行わなければならない項目の有無を確認する必要がある為、覚えておきたい項目だ。

通信関連設定は異常時の動作に関わるので障害設計をしっかりと!

通信関連設定では「ソケット接続リトライ回数」や「ソケット接続リトライ待ち時間」「自動再配信リトライ回数」などといった項目を設定できる。

当然上記の値というのはリトライ回数を超えたらエラーとなるし、待ち時間を超えないと次のソケット接続を行ってくれなかったりする。

デフォルトの設定値のままでも使えない事はないのだが、気を付けたいのはソケット通信応答待ち時間要求受付応答待ち時間の2つだ。

この2つの値、それぞれ以下を意味するのだがデフォルトの設定値がちょっと信じがたい数値となって設定されている。

こんなに待てない事がほとんどだと思うので、業務にあわせてしっかりと変更したい値でもある。

ソケット通信応答待ち時間はソケット通信中に相手先ホストから応答がない場合のタイムアウト時間を秒単位で指定するというもの。このデフォルト値が3600秒と実に1時間とられているが、ソケット通信中ということは相手先と伝送を開始するタイミングとなるため、1時間も待たなくてもほぼネットワークがおかしいかサーバがおかしい状態となっていると思う。

よって、ソケット通信応答待ち時間については長くても10分程度で十分な判断ができるだろう。

要求受付応答待ち時間は要求受付処理で要求に対する応答のタイムアウト時間を秒単位でしているうというもの。こちらはデフォルト値が86400秒ともはや1日待つといったカオスな状態が出来上がってしまう。しかもその間エラーを上げないのだから、めちゃくちゃに待たされることとなるわけだ。

1日待っていたら正直言って業務が終わっている。

ということでソケット通信応答待ち時間要求受付応答待ち時間についてはデフォルト値から変更することを推奨したい。

セキュリティ関連設定のデフォルト値はずぶずぶなので強化したいなら設定変更を!

セキュリティ関連設定については管理画面のセキュリティや要求受付ホストのチェック、HULFT Managerのパスワードチェックなどの指定を行う事ができる。

が、これらの値はデフォルト値だとほぼ無効!

何をしているんだ?とも思われるがデフォルト値なので仕方がないと言えば仕方がないのだろう。

その為、セキュリティ面で言えばかなり緩い状態となっているため、強化したい場合は必ず変更したい値だ。

テスト時にのみ有効は転送テスト関連設定

転送テスト関連設定という一見すると便利そうな機能を持っているのだが、これが曲者。

基本動作設定の中で「テストモード」を指定すると様々なテスト用の設定値が有効となり、一部のジョブは動かさないといった設定も有効となるのだが、すべてのファイルIDに適用されるという鬼畜仕様のため、初期導入のテスト時以外には実際に使うのは困難かと思われる。

特に相手企業と接続している場合、複数の企業と接続している事が困難な為、あえてテストモードに変更するという調整をしてまで使いたい人は皆無かと思われる。

ただ、テストモードにするとテスト用の設定値として後続ジョブを動かさないとかファイル転送を実際には行わないといった設定もできるので、使える場合は有効に使って頂きたい。

まとめ

本ページではHULFTの基本動作設定で気を付けたい受けたいポイントをまとめてみた。

デフォルト値でも問題なく動くのがHULFTの凄さであり、頼りすぎると大けがするポイントもあるのがHULFTの怖さでもあるので基本動作設定についてはしっかりと設計を行い、業務要件を満たした状態で本番稼働を迎えるようにしたいところだ。

次回はHULFTのファイルIDに関連する集配信設定や転送グループ、詳細ホスト設定などに触れていきたいと思う。

スポンサーリンク