バッチのドメイン言語

このセクションでは、バッチジョブの概念に関連するステレオタイプについて説明します。Job は、バッチプロセス全体をカプセル化するエンティティです。他の Spring プロジェクトと同様に、Job は XML 構成ファイルまたは Java ベースの構成と一緒に接続されます。この構成は、「ジョブ構成」と呼ばれることがあります。ただし、次の図に示すように、Job は階層全体の最上位にすぎません。

Spring Batch では、Job は単に Step インスタンスのコンテナーです。これは、フロー内で論理的に一緒に属する複数のステップを結合し、再開可能性など、すべてのステップにグローバルなプロパティの構成を可能にします。ジョブ構成には次が含まれます。

Step は、バッチジョブの独立した順次フェーズをカプセル化するドメインオブジェクトです。すべての Job は完全に 1 つまたは複数のステップで構成されます。Step には、実際のバッチ処理を定義および制御するために必要なすべての情報が含まれています。任意の Step の内容は Job を作成する開発者の裁量に任されているため、これは必然的に曖昧な説明です。Step は、開発者の希望に応じて単純にも複雑にもできます。単純な Step は、ファイルからデータベースにデータをロードする可能性があり、コードはほとんどまたはまったく必要ありません (使用される実装によって異なります)。より複雑な Step には、処理の一部として適用される複雑なビジネスルールがある場合があります。Job と同様に、Step には、次の図に示すように、一意の JobExecution と相関する個別の StepExecution があります。

ExecutionContext は、StepExecution オブジェクトまたは JobExecution オブジェクトにスコープされた永続状態を格納する場所を開発者に提供するために、フレームワークによって永続化および制御されるキーと値のペアのコレクションを表します。( Quartz に精通している方にとっては、JobDataMap と非常によく似ています) 最適な使用例は、再起動を容易にすることです。例としてフラットファイル入力を使用すると、個々の行を処理している間、フレームワークは定期的にコミットポイントで ExecutionContext を永続化します。そうすることで、実行中に致命的なエラーが発生した場合や電源が切れた場合でも、ItemReader はその状態を保存できます。次の例に示すように、必要なのは現在の行数をコンテキストに入れることだけで、あとはフレームワークが行います。

Job ステレオタイプセクションの EndOfDay の例を例として使用し、ファイルをデータベースにロードする loadData という 1 つのステップがあるとします。最初の失敗した実行の後、メタデータテーブルは次の例のようになります。

前のケースでは、Step は 30 分間実行され、このシナリオではファイル内の行を表す 40,321 の「断片」を処理しました。この値は、フレームワークによる各コミットの直前に更新され、ExecutionContext 内のエントリに対応する複数の行を含めることができます。コミット前に通知を受けるには、さまざまな StepListener 実装 (または ItemStream) のいずれかが必要です。これについては、このガイドの後半で詳しく説明します。前の例と同様に、Job は翌日再始動されると想定されています。再起動すると、最後の実行の ExecutionContext の値がデータベースから再構成されます。ItemReader が開かれると、次の例に示すように、コンテキストに格納された状態があるかどうかを確認し、そこから自身を初期化できます。

この場合、前のコードが実行された後、現在の行は 40,322 であり、Step は中断したところから再開されます。ExecutionContext は、実行自体について永続化する必要がある統計に使用することもできます。例: フラットファイルに複数の行にわたって存在する処理のオーダーが含まれている場合、処理されたオーダーの数 (読み取られた行数とは大きく異なります) を保存する必要がある場合があります。本体で処理されたオーダーの総数を含む Step の末尾。フレームワークは、開発者のためにこれを保存して、個々の JobInstance で正しくスコープを設定します。既存の ExecutionContext を使用する必要があるかどうかを判断するのは非常に難しい場合があります。例: 上記の EndOfDay の例を使用すると、01-01 の実行が 2 回目に再び開始されると、フレームワークはそれが同じ JobInstance であり、個々の Step ベースであることを認識し、データベースから ExecutionContext を引き出し、それを (一部として) 渡します。StepExecution の) を Step 自体に接続します。逆に、01-02 の実行では、フレームワークはそれが別のインスタンスであることを認識するため、空のコンテキストを Step に渡す必要があります。適切なタイミングで状態が与えられるようにするために、フレームワークが開発者のために行うこれらの種類の決定の多くがあります。また、常に StepExecution ごとに 1 つの ExecutionContext が存在することに注意することも重要です。これにより共有キースペースが作成されるため、ExecutionContext のクライアントは注意が必要です。そのため、データが上書きされないように、値を入れるときは注意が必要です。ただし、Step はコンテキストにデータをまったく保存しないため、フレームワークに悪影響を与える方法はありません。

JobExecution ごとに少なくとも 1 つの ExecutionContext と StepExecution ごとに 1 つの ExecutionContext があることに注意してください。例: 次のコードスニペットを検討してください。

コメントで記述されていたように、ecStep は ecJob と等しくありません。それらは 2 つの異なる ExecutionContexts です。Step を対象とするものは Step のすべてのコミットポイントで保存されますが、ジョブを対象とするものは Step の実行のたびに保存されます。

JobRepository は、前述のすべてのステレオタイプの持続メカニズムです。JobLauncher、Job、Step 実装に CRUD 操作を提供します。Job が最初に起動されると、リポジトリから JobExecution が取得されます。また、実行の過程で、StepExecution および JobExecution の実装は、リポジトリに渡すことによって永続化されます。

JobLauncher は、次の例に示すように、特定のセットの JobParameters で Job を起動するための単純なインターフェースを表します。

実装が JobRepository から有効な JobExecution を取得し、Job を実行することが期待されます。

ItemReader は、Step の入力を一度に 1 つずつ取得することを表す抽象化です。ItemReader が提供できるアイテムを使い果たすと、null を返すことでこれを示します。ItemReader インターフェースとそのさまざまな実装の詳細については、リーダーとライターを参照してください。

ItemWriter は、Step の出力、一度に 1 つのバッチまたはアイテムのチャンクを表す抽象化です。一般に、ItemWriter は、次に受信する必要がある入力を認識しておらず、現在の呼び出しで渡されたアイテムのみを認識しています。ItemWriter インターフェースとそのさまざまな実装の詳細については、リーダーとライターを参照してください。

ItemProcessor は、アイテムのビジネス処理を表す抽象化です。ItemReader は 1 つの項目を読み取り、ItemWriter は 1 つの項目を書き込みますが、ItemProcessor は他のビジネス処理を変換または適用するためのアクセスポイントを提供します。アイテムの処理中にアイテムが有効でないと判断された場合、null を返すと、アイテムを書き出す必要がないことが示されます。リーダーとライターで ItemProcessor インターフェースの詳細を確認できます。