Enterprise-ready production-ready Java batch applications powered by Spring Boot - ...

:

This post introduces a new project we set up – our own Spring Boot starter for Spring Batch: spring-boot-starter-batch-web.
Spring Boot is the new kid on the Spring block helping you build Spring applications in a fast convention-over-configuration way, and we think it’s awesome. You pull in those starters as dependencies, and you get a lot of stuff configured automatically.
Speaking about starters, yes, there is already a starter for Spring Batch, and it’s good if you want to run Spring Batch jobs standalone. However, our experience tells us that in distributed enterprise environments some kind of batch server exposing an http endpoint for communication is more suitable than running jobs standalone. Luckily Spring Boot is easy to use AND easy to extend, and that’s what we’re doing. This ain’t a pet project, we’re gonna use it in production, and so can you!

Let’s take a look at the goals we have with this project:

  1. Support our favorite architecture / enterprise integration out of the box.
  2. Extremely easy to use. No need for doing ANYTHING but implementing jobs.
  3. Offer common functionality we re-implemented at every customer.

Our favorite architecture / enterprise integration

In enterprise environments you often have external scheduling systems integrating both the mainframe and the distributed world. Our favorite way to connect those worlds is using http in a RESTful, synchronous way, and we prefer small batch applications with at the most a handful of jobs. We’ll elaborate these architectural topics further in a following post. spring-boot-starter-batch-web offers an operational http endpoint with the ability to start jobs, stop jobs, ask for the current status of a job and the job’s log file, and a monitoring endpoint telling you which jobs are deployed, which jobs are running and detailed information on any JobExecution. It’ll seldom be the case that you need more.

Easy usage

Every developer should be able to concentrate on the business – writing jobs. There’s no need for setting up a Spring Batch infrastructure configuration, no need for inheriting code from somewhere, no need to set up a server – yes, you heard right, Spring Boot brings its own embedded servlet container. When setting up a project, basically all you have to do is specify your database connection via properties (or don’t, and you’ll get an in-memory database), add a simple log configuration to the classpath, add the Spring Boot Maven plugin to your pom.xml and create a Spring Boot main class. Then you may write your jobs in xml or JavaConfig, place them in special locations on the classpath (overridable via properties) und get a Spring Boot fat jar via mvn package. Start up the application via java -jar xxx.jar. That’s it, and you have your batch server up and running, including all the batch infrastructure, the http endpoints, and, of course, your jobs. Take a look at our Getting started page!

Common functionality

There are some things we tend to re-implement at every customer in the same way, and we thought there must be a way to do better. Here it is, automatically included and configured without having to do anything in your job, no inheriting, no configuration.
Beside the http endpoints the most important thing is log file separation. When we run jobs, we don’t want everything to end up in a common big log file, all mixed up, no way to assign log statements to specific job runs. We want one log file for each job run, we want a nice header telling us about the job and the used job parameters, we want a nice protocol at the end telling us about the status and the numbers, and we want it to be easily accessible so that it can be picked up by external systems and users.

What’s there to come?

We already released a version 1.0.0.RELEASE, and it’s downloadable via Maven Central.
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-starter-batch-web</artifactId>
<version>1.0.0.RELEASE</version>

So we encourage you to take a look and tell us what you think, and we encourage you to use it, because we’ll surely do. We chose Apache 2.0 as license, so you can do with it whatever you want.
And, of course, there’s still more in the pipeline, as we are planning to support the JSR-352 out-of-the-box as soon as Spring Batch 3.0 is released, and we are planning transaction safe support for counting and metrics in the near future. So stay tuned!