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.
In an earlier post we talked about how to set the Exit Status for a step and how that status can be used to control the flow of the job from one step to another based on how the current step completed.
But what about the job itself? We need an answer to the question: Did the job work? Whether you are running a single instance of a particular job, or if it is a recurring job run on some controlled schedule, you need to know if the job worked or not. You might want to restart the job if it failed in some way that a restart might fix. Knowing that might drive some automation (or an Enterprise Scheduler) to restart the job. Or someone in management might be interested in how an important job completed.
The result of a job is contained in the Exit Status for the job. Like the Exit Status for a step, this value is a String and can, therefore, be anything you like. It can just be a traditional numeric value (0, 4, 8, 12) or something readable (SUCCESS!) or some clever encoding that tells you something specific. Whatever it is, if there is some automation looking at the job result, you need to set that string to something it can handle.
The final Job Exit Status is extracted from the Job Context. If a batch application wants to set the Job Exit Status, it can use the setter method that is part of the context to set it. The Job Exit Status can be set over and over again by different parts of the batch application, if your application does that. The last value set is the final value for the job.
What if the application doesn’t set the Job Exit Status? Then the final Batch Status value for the job will be used as the Exit Status. That means the Exit Status will be one of STOPPED, FAILED, or COMPLETED. Which might be all you need.
But if it isn’t, you can have the application set the status using the Job Context but think about where you might get control that you would know enough to set it. Any individual step might not be able to know enough about what went on in the whole job to have an opinion about the whole job. Of course, if the final step can only be reached if all previously executed steps were successful….
Probably the best place for an application to set the final Job Exit Status is to have some code in the afterJob method of the Job Listener. This is a job-level artifact that is the final bit of application code that will get control before the job ends.
Or just leave it alone and let the Batch Status value become the Exit Status.
>>Next article in this series
<<Previous article in this series