WebSphere Application Server & Liberty

 View Only

JSR-352 (Java Batch) Post #151: How-To: Using Exit Status to Influence Job Flow

By David Follis posted Thu August 26, 2021 08:20 AM

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.

This series is also available as a podcast on iTunesGoogle PlayStitcher, or use the link to the RSS feed

We’re going to start out our series of ‘how to’ posts with a simple one.  How do you set the exit status from a step and use that to influence the flow of control within the job?

If you’re coming from a mainframe JCL-based background, this is a pretty familiar concept.  You set the return code from the step and that turns into a condition code in the JCL.  Flow control statements in JCL can be used to direct the job to whatever step is next based on the value of the return code / condition code.

In Java Batch we have a similar concept in that the program can set an exit status for the step and that value can be used to influence the flow of control within a job.  In our case the exit status is NOT the return value from the step.  For a batchlet step the returned String becomes the exit status, but for a chunk step, well, which batch artifact would set the return value?  Instead the step has a context that can be accessed from any artifact that runs as part of the step, including any listeners you might define.  The exit status is an attribute of the StepContext and there is, naturally, a setter method you can use to set a value.

Of course, being able to set the exit status from different places means the setting of the value might not all be contained within a single part.  You might set it normally from the batchlet, but have a step-end listener that might also set a value. 

This is important because you need to coordinate between what value the application sets and what values the JSL is looking for to do flow control.  Which brings us to the next thing that might feel a little odd.  The exit status value is a string.  If you are used to numeric return codes and condition codes you might be comfortable setting an exit status value to 0, 4, 8, or 12.  You can still do that, but the value will really be a string that is “0”, “4”, “8”, or “12”.  It can just as easily be “OK”, “Warning”, “Error”, or “Failure”. 

It doesn’t really matter, but the value you choose has to match the value specified in the flow control statements in the JSL.  If your code sets the exit status to “OK” in the code, but the JSL is looking for “ok” it won’t match.

So what does the code actually look like?  In github have a look at the SetExitStatusOk batchlet implementation.  It does nothing but set the exit status to “OK”.  The ExitStatusFlowControl JSL looks for that value and passes control of the job to Step1.  If the value isn’t “OK” then no next step is set and the job ends. 

The sample parts are here:  https://github.com/follisd/batch-samples