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.
-----
We’ve been talking about the batch REST API and ways to exploit it, so that seemed like a good segue into talking about WebSphere Developer Tools. WDT (as it is known to its friends) is a plugin you can install into Eclipse. It provides a lot of tooling and wizards to help you interact with Liberty. It can guide you through creating a complex server.xml configuration for Liberty, and it puts all the close brackets and quotation marks in the right places (which is better than I do).
As part of that, WDT also understands Java Batch. We’ll save most of that for another day, but for now I wanted to talk about the interactions with the batch REST interface. If you create a Liberty server inside Eclipse, then WDT knows about it. And you can create a Run Configuration to run a Java Batch job.
If you have installed an application into the server, then WDT knows about it and knows about the JSL files that are in that application. The Java Batch Run Configuration template allows you to pick an application and JSL from selection lists. Then just specify a valid userid/password for the target server (to pass authentication/authorization checks) and you’re ready to go.
But wait, there’s more! WDT has read through the JSL and spotted any job parameters that are mentioned. You can add a parameter to be supplied over the REST interface (along with a value for the parameter, of course). Since WDT knows the parameter names, it can provide a selection list which prevents you from spelling the parameter name worng and then wondering why it didn’t do what you wanted.
WDT can also query a list of jobs known to the Job Repository (remember that can be in-memory or in a database, depending on configuration – so jobs might disappear if you restart the server). And from the job list you can select a job and WDT will use the REST interface to fetch the job log. Of course, you can just go look at the log in the file system on your laptop where you’re running all this, but it can be handy to see it in Eclipse along with the application code and the JSL.
So, for Liberty servers running inside Eclipse, WDT provides a nice way to submit and observe jobs running in that server, all right there in your development environment.