WebSphere Application Server

JSR-352 (Java Batch) Post #4: Introducing the Step Context

By David Follis posted Tue July 10, 2018 02:17 PM


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.
Each step that executes in a Java Batch job has a context associated with it.  From the context you can get information about the step and even set a few things into it.  In this and the next few posts we’ll take a closer look.

First, we need to understand how you get to the Step Context.  Like many things in JSR-352, it is accessed via injection.  The actual injection technology can vary depending on the implementation of JSR-352, but from an application perspective you probably don’t care very much.  Any batch artifact that runs as part of a step (Batchlet, Item Reader/Processor/Writer, various listeners) can get the Step Context.  You’ll get to it by putting this into your batch artifact:


private StepContext stepContext;


That will result in the local variable stepContext being set to the StepContext object for this step.  You can then use it to call any of the defined step context methods. 

We’ll take a look at a few of the simpler ones now.  The step name and step execution id can be retrieved from getter methods on the step context.  These aren’t really much use to you, but if you are logging messages it might be helpful to include that information, especially if this piece of Java code gets used in several different places. 

You can also get metric values for the step.  The metrics are all related to a chunk step and include the number of items read, processed, etc.  This is, again, mostly useful for logging or perhaps for some sort of chargeback processing.  I suppose you might also use it in a custom checkpoint algorithm to help make a decision about when it is time to checkpoint. 

For today we’ll just look at one more use for the Step Context, accessing the step properties.  Every artifact you can specify in the JSL for a job can have properties associated with it.  But you can also associate properties with the step itself.  These properties are those you might want to be able to access from any artifact that is part of the step, including listeners.  Properties specified at the step level can be accessed from any artifact that is part of the step by injecting the StepContext as shown above and using the getProperties method. 

One final word of caution…each step has its own, unique StepContext object, but a partitioned step gets a separate StepContext object for each partition. 

 >>Next article in this series
<<Previous article in this series