According to the Cambridge Advanced Learner's Dictionary, a batch is a group of things or people dealt with at the same time or considered similar in type. And a process is a series of actions that you take in order to achieve a result. Based on these two definitions, we can say that batch processing is a series of repetitive actions on a large amount of data in order to achieve a result. Given the large amounts of data that it has to deal with, batch processing is often used for end of day, month, period, and year processing.

The following is a short list of domains where you can use batch processing:

After having an idea about batch processing, some people might ask themselves: Why not just set a foreach loop that launches many threads? First of all, you have to know that batch processing is not only concerned with the execution speed. Indeed, the processing of large amounts of data is often affected by many exceptions, which could generate a number of preoccupations: What action should be taken in case of exceptions? Should we cancel the whole process for any exception? If not, what action should be canceled? For which type of exception? If you only need to cancel a certain number of transactions, how do you recognize them? And at the end of a batch processing, it is always important to know how many treatments have been canceled. How many have been registered successfully? How many have been ignored?

As you can see, we have not finished identifying questions that batch processing can raise, but we discover that this is already a great deal. Trying to build such a tool on your own may not only complicate your application but also introduce new bugs.

The Batch Applications API for the Java Platform 1.0 was developed to provide a solution to the different needs listed in the earlier bullet items. It targets both Java SE and Java EE applications and requires at least the 6th Version of JVM.

The features offered by this API can be summarized as follows:

To do this, the Batch Applications API for the Java Platform 1.0 is based on a solid architecture that can be outlined by the following diagram. A Job is managed by a JobOperator and has one or many steps, which can be either chunk or batchlet. During its lifecycle, information (metadata) about a job is stored in JobRepository, as shown in the following diagram:

<job id="inscription-validator-Job" version="1.0"xmlns="http://xmlns.jcp.org/xml/ns/javaee">  
  
  <step id="step1" >        
    ... 
  </step>    
  <step id="step2" >        
    ...   
  </step>
</job>

<job id="inscription-validator-Job" version="1.0"xmlns="http://xmlns.jcp.org/xml/ns/javaee">
  <step id="validate-notify" >        
    <chunk>
       <reader ref="InscriptionReader" />
       <processor ref="InscriptionProcessor" />
       <writer ref="StudentNotifier" />
    </chunk>     
  </step>    
</job>

<job id="inscription-validator-Job" version="1.0" 
  xmlns="http://xmlns.jcp.org/xml/ns/javaee">   
  <step id="validate-notify" >        
    <chunk item-count="15" checkpoint-policy="item" 
      skip-limit="30">
      <reader ref="InscriptionReader" />
      <processor ref="InscriptionProcessor" />
      <writer ref="StudentNotifier" />
    </chunk>     
  </step>    
</job>

public class InscriptionReader extends AbstractItemReader {
  @Override
  public Object readItem() throws Exception {
    //Read data and return the item
  }
}

public class InscriptionProcessor implements ItemProcessor{
  @Override
  public Object processItem(Object o) throws Exception {
    //Receive item from the reader, process and return the result
  }    
}

public class StudentNotifier extends AbstractItemWriter {
  @Override
  public void writeItems(List<Object> items) throws Exception {
    //Receive items from the processor then write it out
  }
}
public class InscriptionCheckpoint implements Serializable {
  private int lineNumber;
  
  public void incrementLineNumber(){
    lineNumber++;
  }

  public int getLineNumber() {
    return lineNumber;
  }        
}

public class StudentInformation extends AbstractBatchlet{
  
  @Override
  public String process() throws Exception {
    // process 
    return "COMPLETED";
  }    
}

The batch.xml file is an XML file that contains the batch artifacts of the batch application. It establishes a correspondence between the batch artifact implementation and the reference name that is used in the Job XML file. The batch.xml file must be stored in the META-INF directory for a portable application. The following code gives us the contents of the batch.xml file for the inscription-validator-Job Job shown in the preceding code.

The following code is an example of batch.xml:

<batch-artifacts xmlns="http://xmlns.jcp.org/xml/ns/javaee"> 
  <ref id="InscriptionReader" 
  class="com.packt.ch02.batchprocessing.chunk.InscriptionReader" /> 
  <ref id="StudentNotifier" 
  class="com.packt.ch02.batchprocessing.chunk.StudentNotifier" /> 
  <ref id="InscriptionProcessor" 
  class="com.packt.ch02.batchprocessing.chunk.InscriptionProcessor" /> 
</batch-artifacts>

The JobOperator instance is accessible through the getJobOperator() method of the BatchRuntime class. It provides a set of operations to manage (start, stop, restart and so on) a job and access JobRepository (getJobNames, getJobInstances, getStepExecutions, and so on). The following code shows how to start the inscription-validator-Job Job shown earlier without any specific property. It is important to note that the inscriptionJob value that is specified in the JobOperator.start command is the name of the Job XML file (not the ID of the job). In the Servlet ChunkStepBatchProcessing, you will see how to retrieve the status and how to monitor information about batch processing from the JobOperator instance.

The following code is an example of code to start a Job:

JobOperator jobOperator = BatchRuntime.getJobOperator();
if(jobOperator != null)
  jobOperator.start("inscriptionJob", null);