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

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

Step は、バッチジョブの独立したシーケンシャルフェーズをカプセル化するドメインオブジェクトです。すべてのジョブは 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 実装の 1 つ（または ItemStream）が必要です。これについては、このガイドで後ほど詳しく説明します。前の例と同様に、Job は翌日に再起動されると想定されています。再起動すると、最後の実行の ExecutionContext の値がデータベースから再構成されます。ItemReader を開くと、次の例に示すように、コンテキストに保存された状態があるかどうかを確認し、そこから自身を初期化できます。

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

JobExecution ごとに少なくとも 1 つの ExecutionContext があり、各 StepExecution に 1 つあることに注意することも重要です。例: 次のコードスニペットを検討します。

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

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

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

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

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

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

ItemProcessor は、アイテムのビジネス処理を表す抽象概念です。ItemReader は 1 つのアイテムを読み取り、ItemWriter はそれらを書き込みますが、ItemProcessor は他のビジネス処理を変換または適用するためのアクセスポイントを提供します。アイテムの処理中に、アイテムが無効であると判断された場合、null を返すことは、アイテムを書き出すべきではないことを示します。ItemProcessor インターフェースの詳細については、リーダーとライターを参照してください。