WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #6: Setting Step Exit Status Values

By David Follis posted Wed July 25, 2018 12:14 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.
The exit status for a step is your chance to communicate between the running application code and the batch container that is using the JSL to determine the flow through the job.  We’ll talk more about options for flow control in another post, but today I wanted to look at setting exit status.

First of all, how do you set it?  The step exit status is accessible through the StepContext.  That means that from any artifact running as part of the step (reader, processor, batchlet, various listeners, etc) you can access the exit status.

What can you set the exit status to?  Well, it is a string so you can set it to any string value you like.  But remember, the most likely use of the exit status is to control flow within the JSL, so whatever value you set is likely to show up in the JSL.  You can wildcard in the JSL with ‘*’ and ‘?’, but you still might want to put a little thought into establishing some sort of standard.  An exit status of “I am so happy this step worked” might be fun, but looks a bit silly in the JSL to branch on successful execution of the step.

Which brings us to, what sort of status are you trying to convey with the exit status?  The most obvious is whether what you are doing in the step worked or not.  A basic successful/failure indicator.  You might just use “0” and “1” for that, or maybe “SUCCESS” and “FAIL” is more clear.  If you’ve got shades of success (or failure) you might want to go with the somewhat traditional numeric values:  0, 4, 8, 12. 

But it is possible you might need to communicate something more complex.  Perhaps the step is checking for the existence of a row in a table.  Now you need to convey both that you were (or were not) successful in reading the table, but whether the row was found or not.  You might encode that in a number as above, but it might be better to take advantage of having a string to communicate both things clearly.  Perhaps “SUCCESSFUL:YES”, “SUCCESSFUL:NO”, or simply “FAILED” could convey all three possibilities. 

Two last things to ponder.  First of all, the StepContext allows you to both set AND get the exit status.  Why would you want to get it?  Because it might already be set!  You might normally set the exit status from the afterStep method in the StepListener, but a chunk step might have had an error and already set the status from some other bit of application code running as part of the step.  Do you want to override that error status or not?  Being able to get the exit status allows you to check and make a decision.

And finally, remember that the exit status from the last step executed as part of the job is NOT the exit status from the job itself.  The exit status from the job is an entirely separate thing and needs to be set using the JobContext.  We’ll talk about that more in a later post.

 >>Next article in this series

<<Previous article in this series