WebSphere Application Server & Liberty

 View Only

JSR-352 (Java Batch) Post #7: Basic Step Flow Control

By David Follis posted Tue July 31, 2018 06:50 PM


This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.

To start at the beginning, follow the link to the first post.

The next post in the series is here.
There are two very simple rules for flow control through a job.  The first rule is that the first step is always the first step.  Whatever step is found first in the JSL file is the first step to be executed.  Ok, technically the first thing in the JSL might be a ‘split’ in which case the split executes first and the first step inside all the flows inside the split are the first step, all at the same time.  But you get the idea…the first thing found is the first thing to execute.  No starting in the middle somewhere.

The second rule is that if you want the job to go somewhere, you have to tell it where to go.  If a step completes without any direction being given about which step is next, the job is done.  A JSR-352 Batch job will never just fall through the JSL file one step to the next in the order they appear.  Every step has to indicate a next step in some way, or we’re done. 

There are some fancy options to do conditional flow of control through the job, but we’ll save those for another day.  The easy case is for a step to simply indicate what step should run next when this step finishes, regardless how things turn out in the step.  You do that by including the ‘next’ keyword in the ‘step’ element.  The value of ‘next’ has to be the ID of another step somewhere in the JSL.  Every step, flow, split, or decision can have an id, and so the next attribute can indicate that element should execute after the current one. 

The only place this gets really tricky is with a split/flow.  Remember that you can group a set of steps together as a flow and then nest multiple flows within a split.  All the flows within a split can execute concurrently.  If your flow has multiple steps, you still need to indicate where each step should go when it finishes.  Control will not flow sequentially down through the flow steps in the order they appear.  When a step in a flow completes that has no indicated next step, the flow ends.

What happens when all the flows within a split end?  The job ends, unless…the split element that wraps the flows indicates a ‘next’.  That’s often a decision element.

One more rule…if you are executing steps within a flow, any next step indicated must be contained within the same flow.  You can’t jump across to other flows or out of the split entirely. 

So go with the flow, and we’ll see you next time…

 >>Next article in this series

<<Previous article in this series