前提

SpringBatchを使おうとして、挫折しそうor挫折済みの人向け
この後出てくるSpringBatchの用語が分からない人は、まず本家のイントロダクションと用語を説明したページを読んでからの方が良い
上記を雑に読んだあと、実際に使ってみて感じた結果をまとめているので、本家で説明していることと違うことがあるかもしれない。

なぜSpringBatchを使おうとしたのか

非同期処理をしたいから

例えば、Web経由でリクエストを受け付けて、必要なロジックは裏でやるとか。
わりと、思いつきでもやりたくなっちゃうことがあると思う。（反省）

SpringBatchなら、
このBeanを定義して、

@Bean
public JobLauncher jobLauncher(JobRepository jobRepository) {
        SimpleJobLauncher jobLauncher = new SimpleJobLauncher();
        jobLauncher.setJobRepository(jobRepository);
        // 非同期処理を定義、並列数は３
	SimpleAsyncTaskExecutor taskExecutor = new SimpleAsyncTaskExecutor();
	taskExecutor.setConcurrencyLimit(3);
	jobLauncher.setTaskExecutor(taskExecutor);
        return jobLauncher;
}

実行する。

/** 非同期処理するようにしたJobLuncher */
@Autowired
JobLauncher jobLauncher;

/** 処理を定義したジョブ */
@Autowired
Job job;

public void execute(Long orderId) throws Exception{
    // 引数を定義する
    JobParameters jobParameters = new JobParametersBuilder().addLong(
         "order.id", orderId, true).toJobParameters();
    // 非同期処理　開始！
    jobLauncher.run(job, new JobParameters());
}

SpringBatchで困る人は、ここで詰まることはないと思う。
辛いのは、Jobの作り方だと思う。

自分で非同期処理の仕組みを作りたくないから

非同期処理を動かすだけなら、RunnableインターフェースかCallableインターフェースを実装し、Exetutorクラスたちに渡せばよい。

だが、複数人数で同じく非同期処理を作り始めたら、どうなるだろう。
リソースは枯渇し、GC連発で遅くなったり、OutOfMemoryErrorに悩まされるのではないかと思う。
これを防ぐなら、仕組みを作ることになるが、やりたくない。

SpringBatchなら、
そのような仕組みを自分で作らず、上記のような使い方を共有すれば良い。
Google先生に聞ける、ということは、とても強みだと思う。

かつ、自分でつくるよりもSpringBatchのほうが、高機能だ。
例えば、JobParameterなどの情報を使って分かる範囲で、多重実行抑止などをやってくれる。
上記の例では、order.idの値をみて、一度実行完了したJobを実行しないようにしてくれる。
トランザクション等も利用されているため、自分で考慮はしなくてよい。
　（この辺の挙動は、SpringBatchが嫌いになりそうにもなるけど）

大げさにはしたくないから

非同期処理を作ることが前提なら、RabbitMQやKafkaなど、Queueプロセスを立てることもあると思う。

だが、それらを立てるとなると運用が大変になる。
Queueプロセスが死んだら？NWが死んだら？監視は？

これらを考える手間を超えるほど、非同期処理をするメリット出るのは、処理件数がよっぽど多く、
ケースとしてはわりと少ないのではないかと思う。

SpringBatchなら、
いわゆるJava(Spring)プロセス＋RDBを使った普通の構成で作れる。
RDBを使っておらず、システム通じてプロセス１人だけなら、H2DBのような組み込みでも良い。

Chunk？Tasklet？どっち使えば良いの？

とりあえず、`Tasklet`１つで`Job`をつくればよい。

感覚的には、アドホックに、たまに動く非同期処理を想定している。
Chunkとか、StepやFlowでの分岐、Retry/Skipは全部忘れてよし。

DB１レコードにつきJobを１つ動かすイメージで、シンプルにJobを作ろう。

引数なしの関数を呼び出す

xxxService#execute()の処理を実行するだけ。簡単でしょ。


 @Configuration
 @EnableBatchProcessing
 public class BatchConfiguration {

	@Autowired
	private JobBuilderFactory jobBuilderFactory;

	@Autowired
	private StepBuilderFactory stepBuilderFactory;

	@Autowired
	private OrderService orderService;

	@Bean
	public JobLauncher jobLauncher(JobRepository jobRepository) {
		SimpleJobLauncher jobLauncher = new SimpleJobLauncher();
		jobLauncher.setJobRepository(jobRepository);
		jobLauncher.setTaskExecutor(new SimpleAsyncTaskExecutor());
		return jobLauncher;
	}

	@Bean
	public Job job(Step step1) throws Exception {
		return jobBuilderFactory.get("job1").incrementer(new RunIdIncrementer()).start(step1).build();
	}

	@Bean
	public Step step1(Tasklet tasklet1) {
		return stepBuilderFactory.get("step1").tasklet(tasklet1).build();
	}

	@Bean
	public Tasklet tasklet1() {
		// xxxService#execute()を実行する
		MethodInvokingTaskletAdapter tasklet = new MethodInvokingTaskletAdapter();
		tasklet.setTargetObject(orderService);
		tasklet.setTargetMethod("execute");
		return tasklet;
	}
 }

引数ありの関数を呼び出す

引数ありなら、こうなる。


	@StepScope
	@Bean
	public Tasklet tasklet1(@Value("#{jobParameters['order.id']}") Long orderId) {
		// xxxService#execute()を実行する
		MethodInvokingTaskletAdapter tasklet = new MethodInvokingTaskletAdapter();
		tasklet.setTargetObject(orderService);
		tasklet.setTargetMethod("execute");
		tasklet.setArguments(new Object[] { orderId });
		return tasklet;
	}
 }

例外があれば異常終了、Jobの再実行は可能な状態で終了する

例えば、業務上入れてはいけない数値がやってきたとか、DBアクセスエラーが起きたなど、
失敗とみなして、あとからやり直しをすることになる場合、とにかく例外を発生させればよい。

そうすれば、SpringBatchはJobの実行に失敗した、という情報を持ち、再実行を許してくれる。
かつロールバックも発生して、DBの書き込みもなくなる。

逆に、呼び出した関数が例外を発生させなければ、正常終了する。

異常終了したけど、ロールバックはさせないようにする

Jobは失敗だけどロールバックさせないようにもできる。
業務上の処理に失敗した時、失敗した状態にDBを更新することなどに使える。

	@Bean
	public Step step1(Tasklet tasklet1) {
		return stepBuilderFactory.get("step1").tasklet(tasklet1)
		        .exceptionHandler(exceptionHandler()).build();
	}

	private ExceptionHandler exceptionHandler() {
		return new ExceptionHandler() {
			
			@Override
			public void handleException(RepeatContext context, Throwable throwable) throws Throwable {
				// 例外を投げず、終了する
				context.setTerminateOnly();
			}
		};
	}

上記のように、ExceptionHandlerを実装すれば良い。
かつその中で、失敗とみなす場合に呼び出すRepeatContext#setTerminateOnly()を使う。

トランザクション境界を意識して、Tasklet(Step)を複数に分ける

SpringBatchはTasklet(Step)の開始から終了までの間で、特に設定せずともトランザクションを有効にしてくれている。
そのため大変ありがたいことに、Taskletで実行した処理が例外を出力して異常終了した場合でも、その間に更新したレコードをロールバックしてくる。

しかし逆にいえば、１つのTasklet中で行われるDBの更新は、そのTaskletが終了するまでコミットされない。

だから、１つのTasklet中で行われるDBの更新をちゃんとコミットしたいなら、コミットしたい単位でTaskletを分割すればよい。


	@Bean
	public Job job(Step beforeStep1, Step inProgressStep2, Step afterStep3) throws Exception {
		return jobBuilderFactory.get("job1").incrementer(new RunIdIncrementer())
			.start(beforeStep1)
			.next(inProgressStep2)
			.next(afterStep3)
			.build();
	}

Job実行待ちが多いようなら、Chunkを使うかな

Job実行回数が多いなら、Job１回でまとめて処理できるようにする（つもり）。

例えば、
Taskletを使った場合は、DB１レコードにつきJobを１つ動かすイメージで作っていたのを、
Chunkを使った場合は、DB１レコードにつきChunkを１つ作るイメージで、
かつDBレコードを複数束ねた１リクエストにつきJobを１つ動かす。

ただ私の場合、使わなかったため、予想になっている。
使うとしたらどうなるかは、別途まとめたいと思う。

前提