ここに情報のせすぎると、だんだんマジメに中身見なくなったりしがちなので、あくまでも検知用途として最低限に留めます。いう後悔はありがちなことです。拙作タイムシフトロガーを使えば、遡って原因を特定することができるかもしれません。前述のとおりログを出力し分けるには、例外の種類をリカバリ可能なものと、そうでないものに分類するのが簡単です。これを防ぐために、業務的にリカバリ手順を定めることができるものだけを業務例外として設計し、ハンドリングしメッセージを出すのがよいかと思います。そのため業務例外は検査例外にしておくとハンドリング漏れがなくなってよいのではないでしょうか。recoveryLog.warn(e);}エラーを全部同じようにハンドリングすれば、本質的でないテストケースが増えます。これは、仕事が増える以上の悪影響があって、さもケースを上げきったかのような錯覚に陥りやすくなる、という問題があるので、業務としてのバッチ実装は予期できる例外のみハンドリングします。1例外の分類例を以下に示します。(業務例外)入力フォーマットが不正である。インタフェースファイルが届いてない。終了予定時刻に、処理が終わらなかった。(システム例外)Oracleに接続できない。ファイルがコピーできない。設定ファイルが見つからない。これは運用者ではリカバリ不能であるため、エスカレーションルートにのせます。差分にこだわる「多い日も安心」するには、そもそものデータ処理対象を減らすことが重要です。仕様が複雑になりすぎて破綻するのでない限り、執拗に差分更新にこだわります。「XXマスタデータ取り込み」みたいな、バッチは前回の取り込み成功したファイルとの差分をとり、異なる部分だけ取り込み対象とする。月別集計で、当月分のデータの途中集計は、その月分を計算し直すのではなく、その日分だけ集計して足しこむ。viewの高速リフレッシュを活用する。一括処理にこだわる差分にこだわり抜いて対象データを極限まで減らしたら、それに対してできるだけ一括処理することを考えます。処理速度の面で大きなメリットになります。SELECTでの一文で処理できないか。ダイレクトインサートが使えるなら使う。コミット間隔を可能な限り長めにとる。Java側にデータ持ってきても、必ずJDBCのバッチ更新を使うようにする。引数の数が1つ増えると、リランのミスの確率が2倍になるとかならないとか。バッチのリラン時のミスはなんとしても防がなくてはなりません。リラン時の引数として、よく渡したくなるのは、処理対象の日付を渡すパターンです。これは通常のリカバリ、未処理分の日のデータを取り込む、という目的であれば、引数を渡すのではなく、バッチの未処理日付を管理するテーブルを作っておけばそこからデータを取得して実行することが可能です。ファイルパス(の一部)を引数与えるのは、次のようなことがおこるのでやめたほうがよいです。ファイル操作は1箇所にまとめる。ファイルの操作は慎重にやらないと痛い目にあいます。リカーシブに消すようなインタフェースの削除機能があり、設定ファイルに書かれたベースディレクトリをスキャンしてファイルを消す、なんて設計にすると、設定ファイルから取得できなくて、ファイルシステムのルートから削除しにいく恐怖のバッチの一丁あがりです。これを防ぐには、いろんな人にファイル操作をさせるのをやめるようにすべきです。以下のような、ファイルの管理をする基盤を提供するとよいでしょう。作業台と倉庫バッチの中でファイルをあつかう場所(ディレクトリ)を、以下のように決めます。作業台はバッチの開始時に作り、バッチの終了時にディレクトリごと削除します。したがって、必要なものは倉庫に格納しておきます(受領ファイルを一定期間保管しておく、など)。不要なファイルは、プログラミング言語のファイル削除APIを使うのではなく、「ゴミ箱に捨てる」機能を提供します。10);と、ゴミ箱の保管期間を引数にゴミ箱に移動するようにします。}このときファイル名に、削除してよい日付を入れておきます。ゴミ箱クリーニングあとは、ゴミ箱の中の保管期間を過ぎたファイルを消す日次バッチを作っておけば、各バッチアプリケーションでファイル削除をしなくてもよくなります。まとめ多い日でも安心して眠れる人々が増えることを、心よりお祈り申し上げます。テストケースも分けて管理した方がよいです。業務例外は通常の機能テストとしてテストケースをあげ、それ以外の例外は障害テストとして、発生した場合にシステムやデータが不整合な状態にならないか確認する観点でテストケースをあげるようにします。↩データモデルがイミュータブルである必要があります。Kawashima@kawasimaClojure関連のことをブログがわりに書き綴ります。※ここでの発言はシステムエンジニアを代表するものであって、所属する組織は二の次です。upLoginユーザーは見つかりませんでした。