WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #67: Accessing Joblogs Using the REST Interface

By David Follis posted Wed November 13, 2019 11:50 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

Getting a joblog through a REST interface sounds like it should be a pretty simple thing.  You just need the right REST URL to ask for a joblog and some parameters to tell the REST service which job you care about. 

As we saw last time, it isn’t that simple.  A job log can easily consist of a whole set of log files written by the main job thread itself as well as logs written by various pieces of the job that run concurrent to the main job thread (partitions, split/flows).  When you ask the REST interface for the log for a particular job, which of these files do you want? 

The easiest way to get the job log you want is to first know the execution identifier of the job execution for the job you care about.  Use the jobexecutions REST interface specifying that id in that path followed by ‘joblogs’ (see the Liberty Knowledge Center for syntax specifics).  That tells the REST service that you want the entire log (all the parts) for the job execution you specified.

Under the covers the REST interface will find all the various files that make up the log and concatenate them together and return it as a single text response.  Looking at the merged log you can easily tell where the different log files that went into it start and stop.  That’s probably the best thing to do if you are retrieving it to display it somewhere. 

But if you just want it back to archive it someplace, it might be handy to zip it up.  To help with that, the REST interface also supports specifying type=zip (vs. type=text which is the default).  That will return a binary zip file consisting of the entire log file tree for the job execution you specified.  That’s less handy for immediate use, but if you are just archiving it might save some bandwidth carrying large logs around. 

That’s all great, but it is possible you know exactly which part of the log you care about.  Maybe it is just the flow called “flow2” that is part of a split called “MainSplit” in the main job thread.  Knowing that it is also possible to specify a part keyword that gives the specific path to the part of the log you care about within the particular job execution and just retrieve that one log part. 

Of course, this is all only interesting if you are working with the REST interface directly.  Remember that the Command Line Interface (batchManager), the Eclipse plugin (WDT), and the Admin Center Batch tool all use the REST interface for you and make the job logs readily available.