WebSphere Application Server & Liberty

JSR-352 (Java Batch) Post #23: Substitution Syntax - More Realistic Samples

By David Follis posted Wed December 05, 2018 08:01 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.

First, the answers to last week’s problem:


ABC is MM because the Job Parameter XX isn’t set.

DEF is therefore ABCMM.



I hope.


This is all very clever and hopefully you’re more comfortable with the syntax by now, but what good is all this?  Suppose you have a job with several steps that all produce output and you want that output to go into a common directory.  You’ve got a directory in mind where you want it to go, but you’d like to be able to override that in some situations.


As an added twist, you have two different versions of the application and you’d like to use a single JSL to run both with the version controllable by the submitter of the job.  The java class names are ‘Scan’ and ‘Reduce’ and they are either in the com.ibm.xapp1 or com.ibm.xapp2 package depending on which version you want.


I’ve kept the names of things terse to try to make this readable in a reasonable width.


<job id=”job1” >


        <property name=”OutDir” value=”#{jobParameters[‘OutDir’]}?:/u/xapp/output/;” />

        <property name=”Version” value=”#{jobParameters[‘Version’]}?:1;”/>



    <step id=”step1” next=”step2”>


            <property name=”OutFile” value=”#{jobProperties[‘OutDir’]}scanout.txt”/>


        <batchlet ref=”com.ibm.xapp#{jobProperites[‘Version’]}.Scan”/>



    <step id=”step2” >


            <property name=”OutFile” value=”#{jobProperties[‘OutDir’]}reduceout.txt”/>


        <batchlet ref=”com.ibm.xapp#{jobProperites[‘Version’]}.Reduce”/>



Some observations…

  • The Job Property names are the same as the Job Parameter names. This isn’t required but makes it a lot easier to keep track of things
  • The use of the Job Properties later in the job don’t have a default because they don’t need one. The default is set in the Job Property.  We could have skipped the Property entirely, but having the default in one place at the top makes it easier to see what’s going on (and avoid accidently having different defaults in different places, unless that’s what you want!)
  • We used substitution right there in the package name of the batchlet, right in the middle. That’s actually ok, and pretty cool.
  • Output goes into a common directory, but two different file names. Remember that the value of OutFile is just injected into the batchlet.  It is up to the application to actually use the property as the location for whatever it writes. 
  • If you just run this job as-is twice, the output from the second run will use the same files as the first one unless the application code notices (or that’s what you want).

Hopefully all this has helped you understand how to use substitution in your JSL.  Enjoy!