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.
You have a Java Batch job running inside a Liberty server, but what it is doing? You can use the REST interface to find out what step it is executing and fetch the job log. But what if you want to log job activity somewhere? What if you want to react when something important happens to the job (like a step fails)? What if you have an executive who always wants to know about the status of some important job? How can you monitor the job?
Batch Events! The Liberty implementation of JSR-352 has the ability to publish messages (events) to a messaging topic tree whenever interesting things happen to the job. In subsequent posts we’ll look at some of the different types of events that generate messages and what you might do with them.
At a high level, there is a topic tree consisting of different events in the life of the job (from the submission of the job through the completion) and downward in granularity through steps and even checkpoints for a chunk step.
Messages about all the jobs running in an environment are published into the same topic tree. You can configure a different topic root for different batch environments (e.g. prod and test, or maybe separate by lines of business).
Messages contain information about the job or step, similar to what you would get from the REST interface if asking about the status of the job or step.
More importantly, all the messages have two (sometimes three) message properties. The two you always get are the job instance and execution identifiers. If the message relates to a step, you get the step execution id also. The job instance and execution identifiers allow you to separate messages for different jobs from each other.
If you know the identifier for the job you are interested in (because you submitted it) then you can subscribe and filter to just receive messages from particular topics (completed, failed, etc) about the job you care about.
All this allows you to build a central monitor watching all the jobs or build a particular monitor that watches for events within a specific job. You might do this with Message Driven Beans running in some Liberty server that is subscribed to the topic tree.
In the coming weeks, we’ll traverse the topic tree and have a look at all the different event types.