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 iTunes, Google Play, Stitcher, or use the link to the RSS feed.
One approach to integrating Liberty Java Batch applications with an Enterprise Scheduler is to have the scheduler execute a script that, in turn, uses the
batchManager (or on z/OS
batchManagerZos) Command Line Interface to submit a job.
That seems simple enough, but there are a few things you’ll want to consider. First of all, you should be sure to specify that you want the CLI to wait for the job to complete. Otherwise the CLI will submit the job and return and the script will end. To the Enterprise Scheduler that looks like the job finished and it will be free to go do whatever comes next when, in fact, the job is still running over in Liberty somewhere.
You also want to consider whether or not you want the job output in the output from the script. We haven’t talked about joblog processing yet, but for now just know that it is possible to get the output from the job back from the invocation of the CLI, if you want it. If you do, then it will end up in the output from the script (the CLI basically prints whatever log it gets back). That will make the job output available as part of the script output and thus available to the Enterprise Scheduler, if that helps. Otherwise it still exists and is accessible later but having it where the scheduler expects it to be might make things simpler for operations.
Another consideration is restart processing. If the job fails, you might want your scheduler to know about that and automatically restart the job. How does that work? The CLI has a parameter that allows you to specify a restart file. The CLI will write information (the job instance ID) into that file when it initially submits the job. On the other hand, if the CLI finds a job instance ID in the file already, it will assume you want that job restarted and will perform a restart operation instead.
That means the name of that restart file needs to be associated with this particular job instance as known by the Enterprise Scheduler. For example, if the scheduler runs a particular job every Tuesday, then you’d want the date of THIS Tuesday to be part of the file name. If the job fails and needs to be restarted, you want the scheduler to use the file with that date and not a new file, so the failed job gets restarted. Successful completion of a job will clear out the restart file.
On z/OS there is some weirdness with return code handling from BPXBATCH (the utility you’d likely use to launch a script). I won’t go into the details here, but you need to take some special care.
There are samples of using both
batchManagerZos from scripts in GitHub in the