WildFly ships with the subsystem batch-jberet which is the administration side of JSR 352, also known as Batch API for Java applications. This JSR specifies a programming model for batch applications and a runtime for scheduling and executing jobs.
WildFly Batch Job Repository configuration
Out of the box, the following configuration defines the batch-jberet subsystem:
<subsystem xmlns="urn:jboss:domain:batch-jberet:3.0"> <default-job-repository name="in-memory"/> <default-thread-pool name="batch"/> <job-repository name="in-memory"> <in-memory/> </job-repository> <thread-pool name="batch"> <max-threads count="10"/> <keepalive-time time="30" unit="seconds"/> </thread-pool> </subsystem>
As you can see from the above configurations, batch-jberet fires Job executions in a repository, which enables querying of current and historical job status. The default location of the job repository is in-memory which means that you can query the repository programmatically using the Batch API.
On the other hand, if you want to inspect the Job Repository using typical administration tools, then you can opt for using a JDBC Repository which can then be queried using standard SQL commands.
Another important advantage of using a JDBC Job Repository is that you will be able to restart your jobs from the point they left off, in case of application server failure.
Setting the job repository to use JDBC is just a matter of executing a couple of CLI commands:
As you can see, the jdbc-repository points to the datasource PostgrePool. Therefore, you need to have in your datasource configuration a resource with that name:
<datasource jndi-name="java:/PostGreDS" pool-name="PostgrePool"> <connection-url>jdbc:postgresql://localhost:5432/jbpm</connection-url> <driver>postgres</driver> <security> <user-name>postgres</user-name> <password>jbpm</password> </security> </datasource> <drivers> <driver name="postgres" module="org.postgres"> <driver-class>org.postgresql.Driver</driver-class> </driver> </drivers>
Once that initialize the Batch API with some jobs, the tables will be automatically created:
You can query for the Jobs which have been executed by a particular application through the JOB_INSTANCE table:
On the other hand if you want some execution details about jobs, then you can query the JOB_EXECUTION table: