In our last post we covered the general construction of the new batch module of NixMash Spring and its initial demo Job. As a quick review, our batch module will contain all Spring Batch jobs supporting NixMash Spring. We run the module at the command line and pass it the job we want to run as a –job=[jobname] parameter.
Determining Which Job to Run, a Spring Conditional
Our BatchLauncher class converts any Command Line parameters into Spring Property Values (see previous post) which each of our JobRunner Conditional classes will evaluate. A Condtional Class implements Condition and contains a single matches() method.
We’ll apply that to our DemoJobRunner Spring Bean. If the “job” parameter passed into the app is “demojob” the DemoJob launches.
The JobRunner, Properties and the Repeating Job
The DemoJobRunner class is shown in its entirety below. Notice at the top the use of @Conditional on whether or not to create the bean. We’re retrieving our job parameters from our external properties file in (1). The @Scheduled annotation at (2) is interesting for several reasons. The first is the use of SPeL to set the fixedDelayString from an external property. (We use fixedDelayString instead of fixedDelay for that reason.) It’s also important to note that since DemoJob is a Scheduled Job we have to set the @Conditional on the class. I suppose this is by design, but if you use @Scheduled that job is going to run no matter what. If the Bean exists that job will fire on application startup! Thus the @Conditional at the class level.
We’ll end Spring Batch Concepts, Part II here and move onto Part III where we’ll focus on the execution of the job itself to see job parameters in action, conditional decision making on job steps, and passing job data properties among multiple processes.