[システム開発ネタ]システムの『鬼は外』（２）

前回に引き続き、バッチ処理について、思うところを。

（１）バッチジョブにて使用する「処理基準日付」としての「日付」
　　バッチ処理は、大量のデータを纏めて処理するものの、その処理に於ける
　　基準日付の考え方を整理しておく必要があります。
　　今のシステムを作るエンジニアは、何となくシステム（機械）が保有している
　　システム日付（Linuxコマンドでいうところの、dateコマンドで取得できる日付）を
　　利用しているものを多く見られます。
　　コマンドを介して、前日・翌日などを任意のフォーマットで取得できるし、
　　プログラム内でどこでもコーディングできるので便利だと思います。

　　また、出力される各種のログのタイムスタンプと基準があうので、
　　何か調査する場合にも有用な方法です。

　　でも、ちょっと考えてみてください。

　　バッチ処理で１つのファイルの処理中に、２４時を超えてしまったら？
　　　・受付の日付が利用されるのか？
　　　・処理が完了した日付が利用されるのか？
　　　・ファイルの先頭で日付を設定すると、、、？
　　　・処理の都度、日付を取得すると？
　　プログラムの作りに依存したデータ処理日付となりますね。

　　システムテストを計画する場合にも、ちょっと困ることになります。

　　曜日での処理の検証(平日と休日、祝日）や日跨がり処理などを行うにも
　　実日付・実時間がその条件に合うように設定しなければなります。
　　例え、毎日同じ処理だとしても、同じ日数を投入しなければ、確認できません。

　　そこで、昔ホスト機環境で実装していたのは、処理日付のコントロール・カード
　　（JCLで言うところの //SYSIN DD 文）での指示（指定）です。

　　今風で言えば、環境変数の設定、若しくは、データベースの共通テーブルでの実装に
　　なるでしょか？

　　又、（処理日付を）遡ったリカバリー処理ができるようにするためには、上記の
　　環境変数やテーブルなどは、複数種類を用意する必要があります。

　　バッチ処理全体の設計に関わる内容ですので、設計の早い段階で実現方法を
　　確定しておく必要があります。


　　データ量の増加に伴う日跨がり処理が発生した時や、
　　処理日付を遡及したリカバリーが必要となってから悔やんでも遅いのです。