はじめに

　FRAMEWORK 紹介の第1弾として、「業務日付」を取り上げます。非常にシンプルなFRAMEWORK なんですが、すごく有効なものです。そもそも、「業務日付」って何？と思われる方も多いと思います。そのあたりも含めて書いていこうと思います。

業務日付とは

　暦上の日付は、TIMEZONEが同じなら、ある時点の日付は決まっています。当たり前ですね。一方、業務日付は、TIMEZONEが同じでも、業務用途が異なればある時点の日付が異なることがあります。

　定義付けるならば、「暦上の日付の変わり目とは異なり、特定の業務において一定のルールに基づく変わり目を持つ日付であり、特定の業務における日を特定するための日付」と表現できます。

　SYSTEM DATE、 BUSINESS DATE、SYSTEM CONTROL DATEなどと呼ぶこともあります。

業務日付の例① 営業日のみの申込受付日

　サービス約款などで、契約事項の申込は営業日の受付のみに限っているケースがあります。ですが、実際は土日などの非営業日にお申込をいただくことがあります。このケースでも、お申込をいただいたら速やかにシステムに登録しておきたいというのがニーズとして存在します。

　このようなニーズを満たすために「申込受付日」という業務日付を用います。土日に入力しても、データベースに格納する申込受付日は翌月曜日の日付とします。

業務日付の例② バッチ基準日

　日中の業務が完了した後、バッチ処理で大量のデータ処理を行うのが一般的です。夜間バッチ処理と呼ぶケースが多いと思います。処理量が多いと、深夜0:00を過ぎても処理が終わらないケースがあり、暦上の日付は翌日になってしまいます。ですが、夜間バッチ処理としては、暦上翌日になる前の元の日付のデータとして処理しなければなりません。

　暦上翌日になってしまっても、変わることなく何日のデータなのかを示す日付として、「バッチ基準日」という業務日付を導入して利用します。

DBを用いた業務日付の管理

　我々は業務日付をDBで管理し、FRAMEWORK化しています。OS等からシステム日時を取得し、業務日付を算出するロジックを実装する方式だと下記のような欠点があるからです。

1. 実装するための工数とテスト工数が発生する

2. 業務日付の更新タイミングが変わるとプログラム修正とテストが必要になる

3. 特定の日付でテストするためには、OS等のシステム日時を変える必要がある

業務日付の更新

　我々は、上記の通り業務日付をDBで管理しており、その更新用のバッチプログラムを用意しています。そのバッチプログラムは、「どの業務日付かとそれを何日にするか」をパラメータとして受け取り更新する仕様となっています。

　このバッチプログラムを適切なタイミングで実行することによって業務日付を更新しています。

　業務日付は翌営業日に更新するケースが多く、翌営業日を算出するFRAMEWORK (BUSINESS CALENDAR FRAMEWORK)も別途用意しています。これについては、今後、記事として投稿しようと思っています。　

業務日付のデータ構造

　我々は、下記のようなデータ構造で業務日付を管理しています。

　PRIMARY KEYである「MAIN_SYSTEM_ID」と「SUB_SYSTEM_ID」の組み合わせで業務日付を特定する方式を採用しています。下記のように利用します。

　一つのカラムで、業務日付を特定してもいいのですが、グルーピングしやすいように2つのカラムで特定するようにしています。これは、あくまでも把握のしやすさだけを目的としたもので、他の目的はありません。

最後に

　業務日付FRAMEWORK は極めてシンプルなものですが、実装・修正およびそれに伴うテスト等のコスト削減、テスト容易性向上などプロジェクトにおける寄与度は大きいです。一度使うとやめられません。

関連記事

概要 Vol.0 - SIOS Technology FRAMEWORK
Vol.1 業務日付 - SIOS Technology FRAMEWORK (当記事)
Vol.2 営業日カレンダー - SIOS Technology FRAMEWORK

今後、追記していきます。