WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #62: The Admin Center Batch Tool – Part 2

By David Follis posted Wed October 09, 2019 07:52 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

Last time we talked about using the Liberty Admin Center’s Batch Tool to browse through a list of jobs and dig into what went on in those jobs.  We can look at the results of each step in a job and even call up the joblog.  There are a lot of search and filter capabilities to make it easier to find the job you’re looking for.

All those are basically “read” operations.  Are there any “write” operations you can perform with the Admin Center?  Well sure.  As we’ve noted before, the Admin Center is really just a pretty client that uses the batch REST interface.  And the Admin Center has taken advantage of a few different “write” operations that act on jobs in the Job Repository.

The first of those is “stop”.  As we’ve noted in our discussions about the JSR-352 specification there is an option to try to stop a running job via the JobOperator interface (and via the Liberty Batch REST interface).  This will stop a job in a chunk step if/when it progresses through a read/process cycle and the batch container code can check to see if the job is stopped.  For a batchlet it will drive the stop method which informs the batchlet about the stop request and it is up to the batchlet to try to stop itself.  The Admin Center allows you to select a running job and drive a stop request against it.

If a job has failed and you want to restart it, you can also do that through the Admin Center Batch Tool.  Just select the job and then select the Restart operation.  You’ll be given an opportunity to specify new Job Parameters to be used when the job is restarted.  In a production environment a failed job might get restarted by automation, but you’ll want to test that out before production and using the Admin Center to drive the restart is a handy way to do it.

Finally, you will eventually end up with jobs in the Job Repository that you just don’t care about anymore and you want to purge them.  It is likely in a production environment that will be done with some automation driving a script that uses the command line interface.  But there might be cases where you just need to purge a job or two and, again, the Admin Center Batch Tool is a handy way to do that.