We covered the general design of our Spring Batch module in Part I, looked at the logic we used to run a particular Job from the command line in Part II, and in Part III looked at sharing data throughout the processes of our DemoJob. In this post we will look at Job Execution Flow and how we can control which Steps to execute dynamically.
We’ll begin by looking at the Job Log Output. We have two Steps, Step1 which we will always perform and Optional Step we will run a set number of times determined by an Job Parameter we loaded from an External Property File in our DemoJobRunner. (See Part II.) Notice the lines “ITERATING…” and “REPEATED 2X’s…” Those are generated from a Spring JobExecutionDecider Bean, which returns a FlowExecutionStatus Comparable Object we’ll use to determine if we run our Optional Step. The Optional Step, by the way, does nothing more than print “IN OPTIONAL STEP…” in the output log which you can see below in the first two iterations.
Job Execution Layout
Let’s look at our JobBuilder DemoJob construction. We execute step1, decide if we want to continue and if so execute optionalStep. We’ll cover c(NO) and c(YES) in a bit.
The Job Execution Decider
Here’s is our JobExecutionDecider Bean. As we discussed, we want to execute optionalStep for the number of times defined in a Job Property demo.job.param.iterations, which is “2”. For kicks we’re displaying the PostId value from our JobExecutionContext because we can.
Final tidbits to cover when using the JobExecutionDecider include setting FlowExecutionStatus…
…with an optional little helper method to simplify using it in the JobBuilder.