すべてのアプリケーションにおいて実行ログは非常に重要なものですが、特にバッチアプリケーションではエラー発生時の原因を究明するうえで必要不可欠な情報です。
オンラインアプリケーションでエラーが発生した場合、エラー情報は画面を通してユーザーに直接見える形でフィードバックされます。一方、バッチ処理はジョブ管理システムによってバックグラウンドで実行されることが多いので、エラー情報がユーザーに直接フィードバックされません。すなわち、処理の実行結果がブラックボックスになってしまうのです。
エラーが発生した場合に実行ログがなかったら、「処理のどこでエラーが発生したのか」も「エラーの原因は何か」も分からないままになってしまいます。このため、一般的なバッチアプリケーションでは、処理経過やエラー内容に関するログを必ず出力します。
また、オープンシステムにおけるバッチ処理では、OSコマンドやシステム製品のユーティリティなどの組み合わせによって処理をつないでいくのが一般的です。
従って、一口に実行ログといっても、OSが出力するログもあればシステム製品によって出力されるログもあります。それぞれのログは異なるフォーマットで別々の場所に出力されるので、1つのバッチ処理から出力された実行ログであるにもかかわらず関連性が分からなくなってしまいます。よって、これらの個別ログの内容を集約したログを、各バッチ処理の実行単位で生成する必要があります。
さらに、実行ログの出力フォーマットについても注意が必要です。実行ログのフォーマットはプロジェクトごとに独自で設計しているケースをよく見ますが、オープンシステムでは独自のフォーマットを極力避けることをお勧めします。つまり、OSやシステム製品が出力するログをそのまま利用して、さらに必要な情報を追加で出力するのです。
独自フォーマットとして設計する部分は、バッチアプリケーションの開始日時や終了日時などの共通情報に限った方がよいでしょう。独自のフォーマットでログを生成してしまうと、限られた運用担当者しかログを解読できなくなってしまいます。
担当者が変わる際には、ログの見方などを次の担当者に引き継ぐ必要があります。このような独自色は、オープンシステムを利用するメリットを自ら削ってしまうことになります。
今回は、バッチアプリケーションを設計するうえで考慮するべき4つのポイントについて解説しました。
次回は、バッチアプリケーションの実装テクニックについて解説する予定です。
Copyright © ITmedia, Inc. All Rights Reserved.