2021.04.22

• クラウド・マルチクラウド
• 内製化支援

• バッチ処理一覧
  
• 外部インターフェース設計
  
• データフロー設計
  
• データモデル定義
  

対象バッチの一覧と処理概要を実行単位に整理します。
本検証ではあらかじめ対象のバッチ処理が定まっているため省略しました。

バッチ処理における入出力方式を検討します。

Asakusa Frameworkでは、Direct I/Oと呼ばれる、分散ファイルシステム上のファイルを読み込み、書き出しを行う方式と、WindGate と呼ばれる外部システム連携ツールを選択可能です。WindGateを使用することで、RDBMSなどの外部システムと柔軟に連携することが可能ですが、Direct I/Oに比べて速度が上がりづらいというデメリットがあります。

本検証で対象にしたバッチ処理においては、処理内で使用するデータサイズが大きく速度面に不安があったこと、前後のバッチ処理とのデータ連携を考えた際に、ファイルでの入出力で問題がなかったことから、Direct I/Oを採用しました。

検証対象のバッチ処理の流れを整理し、それぞれの処理での入力データ、処理内容、出力データを詳細に定義します。

Asakusa Frameworkの処理ではあらかじめ用意された「演算子」と呼ばれるAPIを使用します。演算子には複数の種類があり、データの更新を行う演算子や、結合・集計処理を行う演算子などを組みあわせてバッチ処理の流れを定義していきます。そのため、データフロー設計の中でどの演算子を使って処理を行うかも含めて整理しました。

データフロー定義で整理した入力データ、出力データに対して、項目の整理を行います。

バッチ処理の中では、処理対象レコードに対してデータの追加が必要となることがあります。その場合には、中間モデルとして追加データを定義したモデルを別途用意する必要があるため、中間モデルについてもあわせて整理しました。

上記4つのポイントに沿ってバッチ処理設計を進めましたが、今回対象としたCOBOLバッチ処理では、Asakusa Frameworkで直接対応することができないファイル形式を扱っていたため、本処理の前後に以下の処理を追加しています。

• 参照マスタデータをファイルとしてエクスポート
  Direct I/Oでは処理に使用するデータはローカルファイルとして保存している必要があるため、事前にDBからエクスポートしています。
• ファイル形式変換（固定長→CSV）
  一般的なCOBOLプログラムで扱うデータは固定長データの例が多くありますが、Asakusa FrameworkはCSVまたはTSVなどの区切り文字がないと処理できません。そのため、固定長ファイルである処理対象データをCSV形式へ変換しています。

続いて、後処理について説明します。

• ファイル形式変換（CSV→固定長）
  前処理と同様、Asakusa FrameworkからはCSVとして結果ファイルを出力し、後処理の中で固定長ファイルに変換しています。
• 出力ファイルの結合およびソート処理
  対象バッチで出力するファイルは、マルチレイアウトファイルでしたが、Asakusa Frameworkではマルチレイアウトファイルの出力に対応していませんでした。そのため、ファイルをレイアウト別に分割して出力し、後処理内で結合しています。また、出力順も保持されないため、後続バッチ処理でレコード順番が重要となるファイルについては別途ソート処理を行っています。

本記事では、Asakusa Frameworkでの設計のポイントについてご説明しました。処理設計の際にはAsakusa Framework内で対応できる範囲とできない範囲を見極め、対応できない場合は前後処理の中で対応することを含めて柔軟に検討していく必要があります。

次回は、Visual COBOLを用いて実装をしていく中で注意すべきポイントと、Asakusa Frameworkの処理のチューニング内容についてご紹介します。

• Asakusa Framework™は、株式会社ノーチラス・テクノロジーズの登録商標です。
• Visual COBOL は、英国、米国、およびその他の国における Micro Focus、その子会社、関連会社の商標です。