Nablarchシステム開発ガイド

Nablarchバッチ処理パターン

起動方法による分類

Nablarchバッチでは、主に以下の2つの起動方法を使用します。

• 都度起動バッチ
  • プロセスを都度起動して、バッチ処理を実行します
  • 日次や月次など、定期的にバッチ処理を実行するような場合に使用します
• テーブルをキューとして使ったメッセージング
  • プロセスを起動しておき、定期的にデータベース上のテーブルを監視し未処理のレコードを順次処理します
  • オンライン処理で処理要求を受け付け、非同期でバッチ処理を実行したいような場合に使用します

入出力による分類

この切り口とは別に、主となる入力、出力の組み合わせにより、 以下の3パターンに分けることができます。

• FILE to DB
• DB to DB
• DB to FILE

組み合わせは以下の通りとなります。

• ○：使用する
• △：仕組み上は可能だが普通は使わない
• ✕：使わない

（常駐バッチは、通常データベースを監視するため、FILE to DBとの組み合わせはありません）

■FILE to DB

• 外部から受け取ったファイルをシステムに取り込む際に使用します。
• ファイル取り込み用のバッチプログラムを作成します。
• 取り込み先は、業務用のテーブルではなく、一時保存用のテーブル（テンポラリテーブル）になります
• テンポラリテーブルはファイルのレイアウトと１対１のカラムを持ちます

FILE to DBバッチでは、できるだけ業務処理を加えず、ファイルをテンポラリテーブルにINSERTしていくようにします。 これにより、以下のようなメリットが得られます。

• 一度DBに取り込むことによって、RDBの強力な機能が使用できる。
  • トランザクション
  • SQL
    • 従来のマッチング処理は、SQLのJOINで代替できます
    • 従来のコントロールブレイク処理は、GROUP BYで代替できるケースがあります
• Nablarchのファイル取り込み機能が使用できる（任意）
  • ファイル取り込み時に障害が発生した場合、途中から取り込みを再開できる

■DB to DB

• 入力はSELECT文の結果セットの各レコードになります。
• 1レコード分のデータを受け取って、DBを更新します。
• 1レコードの処理中に行われる更新は全て同一トランザクション下で実行されるため、障害発生時でも不整合が発生しません

■DB to FILE

• 入力はSELECT文の結果セットの各レコードになります。
• 1レコード分のデータを受け取って、ファイルを書き出します(普通は1行分)

DBはトランザクション管理されますが、ファイル書き出しは管理外なので、 障害発生時に、不整合がありえます。

上記以外の組み合わせ(FILE to FILE)

例えば、よくあるバッチ処理として「2つのファイルをマッチングしながら、1つのファイルを出力する」というものがあります。 この場合は、FILE to FILEということになりますが、Nablarchバッチではこの形態は使用しません。 それぞれのファイルをDBに取り込んだ後、SQLでJOINすることで同等の処理ができます。

マッチングやコントロールブレイクといったメインフレームのバッチでよくあるようなファイル処理をNablarchバッチで実現することは可能ですが、バッチプログラムが複雑になる、どこまでをファイルでどこまでをDBで扱うかという切り分けが難しい、というような問題があります。 それよりも、前述のパターンの組み合わせで実現したほうが、各バッチがシンプルになり設計もしやすく、バグも埋め込みにくくなります。

注意点

ファイルの移動、コピー

FILE to DBないしDB to FILEを行う場合、そのバッチ処理にはファイルの移動やコピーは含めないようにします。

仮に以下のようなバッチ処理を実装したとします。

1. ファイルを所定のディレクトリに移動（初期化処理）
2. 1で移動したファイルを読み込んでDBに登録（本処理）

2で処理が失敗した場合、再実行する前に入力ファイルを元のディレクトリに戻すというオペレーションが必要となってしまいます。

ファイルの移動、コピーを別出ししておくことで、以下のようなメリットがあります。

• 再実行がやりやすくなる
• ファイル取り込みバッチの単体テストがやりやすくなる
• ファイルの移動、コピーを自分で実装しないので、移動、コピーに対する単体テストが不要になる