Java Reference
In-Depth Information
<beans:bean id="successTasklet"
<beans:property name="message" value="The step succeeded!"/>
<beans:bean id="failTasklet"
<beans:property name="message" value="The step failed!"/>
<job id="conditionalStepLogicJob">
<step id="step1">
<tasklet ref="passTasklet"/>
<next on="*" to="step2a"/>
<stop on="FAILED" restart="step2a"/>
<step id="step2a">
<tasklet ref="successTasklet"/>
Executing conditionalStepLogicJob with this final configuration, as in Listing 4-45, allows you to
rerun the job with the same parameters. However, this time, if the FAILURE path is chosen, when the job
is restarted execution begins at step2a .
The flow from one step to the next isn't just another layer of configuration you're adding to
potentially complex job configurations; it's also configurable in a reusable component. The next section
discusses how to encapsulate flows of steps into reusable components.
Externalizing Flows
You've already identified that a step doesn't need to be configured within a job tag in your XML. This lets
you extract the definition of your steps from a given job into reusable components. The same goes for
the order of steps. In Spring Batch, there are three options for how to externalize the order of steps. The
first is to create a flow, which is an independent sequence of steps. The second is to use the flow step;
although the configuration is very similar, the state persistence in the JobRepository is slightly different.
The last way is to actually call another job from within your job. This section covers how all three of
these options work.
A flow looks a lot like a job. It's configured the same way, but with a flow tag instead of a job tag.
Listing 4-46 shows how to define a flow using the flow tag, giving it an id and then referencing it in your
job using the flow tag.
Listing 4-46. Defining a Flow
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns=""
Search WWH ::

Custom Search