ジョブを実行する
少なくとも、バッチジョブを起動するには、起動する Job と JobOperator の 2 つが必要です。どちらも同じコンテキストまたは異なるコンテキストに含めることができます。例: コマンドラインからジョブを起動すると、新しい JVM が各 Job に対してインスタンス化されます。すべてのジョブには独自の JobOperator があります。ただし、HttpRequest のスコープ内にある Web コンテナー内から実行する場合、通常、複数のリクエストがジョブを起動するために呼び出す 1 つの JobOperator (非同期ジョブ起動用に構成) があります。
コマンドラインからジョブを実行する
エンタープライズスケジューラからジョブを実行する場合は、コマンドラインが主要なインターフェースになります。これは、ほとんどのスケジューラ ( Quartz を除き、NativeJob を使用しない場合) が、主にシェルスクリプトで開始されるオペレーティングシステムプロセスと直接連携するためです。Perl や Ruby などのシェルスクリプトや、Ant や Maven などのビルドツール以外にも、Java プロセスを起動する方法は多数あります。ただし、ほとんどの人はシェルスクリプトに精通しているため、この例ではシェルスクリプトに焦点を当てています。
CommandLineJobOperator
ジョブを起動するスクリプトは Java 仮想マシンを起動する必要があるため、プライマリエントリポイントとして機能する main メソッドを持つクラスが必要です。Spring Batch は、この目的に役立つ実装を提供します: CommandLineJobOperator。これは、アプリケーションをブートストラップする 1 つの方法にすぎないことに注意してください。Java プロセスを起動する方法は多数ありますが、このクラスを決定的なものと見なすべきではありません。CommandLineJobOperator は次の 4 つのタスクを実行します。
適切な
ApplicationContextをロードします。コマンドライン引数を
JobParametersに解析します。引数に基づいて適切なジョブを見つけます。
アプリケーションコンテキストで提供される
JobOperatorを使用して、ジョブを起動します。
これらのタスクはすべて、渡された引数のみで実行されます。次の表に、必要な引数を示します。
|
|
| ジョブで実行する操作の名前。[ |
| 操作に応じて、これは開始するジョブの名前、または停止、再開、中止、回復するジョブの実行 ID になります。 |
ジョブを開始する際、これ以降の引数はすべてジョブパラメーターとみなされ、JobParameters オブジェクトに変換されます。name=value,type,identifying の形式である必要があります。ジョブを停止、再開、中止、回復する場合、jobExecutionId は 4 番目の引数として期待され、残りの引数はすべて無視されます。
次の例は、Java で定義されたジョブにジョブパラメーターとして渡された日付を示しています。
<bash$ java CommandLineJobOperator io.spring.EndOfDayJobConfiguration start endOfDay schedule.date=2007-05-05,java.time.LocalDate デフォルトでは、CommandLineJobOperator は DefaultJobParametersConverter を使用します。この DefaultJobParametersConverter は、キーと値のペアを識別ジョブパラメーターに暗黙的に変換します。ただし、それぞれ true または false の接尾辞を付けることで、識別するジョブパラメーターと識別しないジョブパラメーターを明示的に指定できます。
次の例では、schedule.date は識別ジョブパラメーターですが、vendor.id はそうではありません。
<bash$ java CommandLineJobOperator io.spring.EndOfDayJobConfiguration start endOfDay \
schedule.date=2007-05-05,java.time.LocalDate,true \
vendor.id=123,java.lang.Long,falseCommandLineJobOperator にカスタム JobParametersConverter を設定することで、この動作をオーバーライドできます。
終了コード
コマンドラインからバッチジョブを起動する場合、エンタープライズスケジューラがよく使用されます。ほとんどのスケジューラはかなり馬鹿げており、プロセスレベルでしか機能しません。これは、一部のオペレーティングシステムプロセス (呼び出したシェルスクリプトなど) しか認識していないことを意味します。このシナリオでは、ジョブの成功または失敗についてスケジューラに返信する唯一の方法は、リターンコードを使用することです。リターンコードは、実行の結果を示すためにプロセスによってスケジューラに返される番号です。最も単純なケースでは、0 は成功、1 は失敗です。ただし、「ジョブ A が 4 を返す場合はジョブ B を開始し、5 を返す場合はジョブ C を開始する」など、より複雑なシナリオが存在する場合もあります。この型の動作はスケジューラレベルで構成されますが、Spring Batch などの処理フレームワークが特定のバッチジョブの終了コードの数値表現を返す方法を提供することが重要です。Spring Batch では、これは ExitStatus 内にカプセル化されます。これについては、第 5 章で詳しく説明します。終了コードについて説明する目的で知っておくべき唯一の重要なことは、ExitStatus にはフレームワークによって設定される終了コードプロパティがあることです (または開発者) であり、JobOperator から返される JobExecution の一部として返されます。CommandLineJobOperator は、ExitCodeMapper インターフェースを使用して、この文字列値を数値に変換します。
public interface ExitCodeMapper {
int intValue(String exitCode);
}ExitCodeMapper の基本的な規約は、文字列の終了コードを指定すると、数値表現が返されることです。ジョブランナーが使用するデフォルトの実装は SimpleJvmExitCodeMapper で、完了の場合は 0、一般的なエラーの場合は 1、指定されたコンテキストで Job が見つからないなどのジョブランナーエラーの場合は 2 を返します。上記の 3 つの値よりも複雑な値が必要な場合は、CommandLineJobOperator に設定することで、ExitCodeMapper インターフェースのカスタム実装を提供する必要があります。
Web コンテナー内からのジョブの実行
以前は、前述のように、オフライン処理 (バッチジョブなど) はコマンドラインから起動されていました。ただし、HttpRequest からの起動がより適切なオプションである場合が多くあります。このようなユースケースの多くには、レポート、アドホックジョブの実行、および Web アプリケーションのサポートが含まれます。バッチジョブは (定義上) 長時間実行されるため、最も重要な関心事は、ジョブを非同期で起動することです。

この場合のコントローラーは Spring MVC コントローラーです。Spring MVC の詳細については、Spring Framework リファレンスガイドを参照してください。コントローラーは、非同期で起動するように構成された JobOperator を使用して Job を起動し、すぐに JobExecution を返します。Job はまだ実行されている可能性があります。ただし、この非ブロック動作により、コントローラーはすぐに戻ることができます。これは、HttpRequest を処理するときに必要です。次のリストは例を示しています。
@Controller
public class JobOperatorController {
@Autowired
JobOperator jobOperator;
@Autowired
Job job;
@RequestMapping("/jobOperator.html")
public void handle() throws Exception{
jobOperator.start(job, new JobParameters());
}
}