Batch programming model

Batch applications are EJB based Java EE applications. These applications conform to a few well-defined interfaces that allow the batch runtime environment to manage the start of batch jobs destined for the application.

Batch job steps

A batch job can be composed of one or more batch steps. All steps in a job are processed sequentially. Dividing a batch application into steps allows for separation of distinct tasks in a batch application. We can create batch steps by implementing the com.ibm.websphere.batch.BatchJobStepInterface interface. This interface provides the business logic of the batch step that the batch run time starts to run the batch application.

Batch controller bean

A batch application includes a stateless session bean that the product run time provides. This stateless session bean acts as a job step controller. The controller stateless session bean is declared in the application deployment descriptor once per batch application.

Batch data streams

Methods on the BatchDataStream interface allow the batch runtime environment to manage the data stream being used by a batch step. For example, one of the methods retrieves current cursor information from the stream to track how much data has been processed by the batch step.

Checkpoint algorithms

The batch runtime environment uses checkpoint algorithms to decide how often to commit global transactions under which batch steps are started. The XML Job Control Language (xJCL) definition of a batch job defines the checkpoint algorithms to be used. Properties specified for checkpoint algorithms in xJCL allow for checkpoint behavior, such as transaction timeouts and checkpoint intervals, to be customized for batch steps. The product provides time-based and record-based checkpoint algorithms. A checkpoint algorithm SPI is also provided for building additional custom checkpoint algorithms.

Results algorithm

Results algorithms are an optional feature of the batch programming model. Results algorithms are applied to batch steps through XML Job Control Language (xJCL). The algorithms are used to manipulate the return codes of batch jobs. Additionally, these algorithms are place holders for triggers based on step return codes.

Batch job return codes

Batch job return codes fall into two groups named system and user. System return codes are defined as negative integers. User application return codes are defined as positive integers. Both system and user ranges include the return code of zero (0). If a user application return code is specified in the system return code range, a warning message is posted in the job and system logs.

Even though an application can set a value for the job return code, that value is only returned when the job completes normally. If the job fails with a status of either execution fails or restartable the value returned is one of the runtime-set negative return codes described in the preceding table.

Subtopics

• Batch job steps
  We can separate tasks of a batch application into batch steps. Batch steps are implemented as Plain Old Java Object (POJO) classes that implement the interface, com.ibm.websphere.batch.BatchJobStepInterfance. Batch job steps are performed sequentially.

• Batch return codes
  The batch job return code is retrieved using the getBatchJobRC EJB interface, the get BatchJobRC web services interface, or the lrcmd getBatchJobRC command option.

• Batch controller bean
  In its deployment descriptor, a batch application is required to declare a special stateless session bean. This bean acts as a batch job controller.

• Batch data streams
  Batch data streams (BDS) are Java objects that provide an abstraction for the data stream processed by a batch step. A batch step can have one or more BDS objects associated with it. The grid endpoints make the BDS associated with the batch step available at run time. The grid endpoints also manages the life cycle of a BDS by invoking batch-specific callbacks.

• Checkpoint algorithms
  The grid endpoints use checkpoint algorithms to determine when to commit global transactions under which batch steps are invoked. These algorithms are applied to a batch job through the XML Job Control Language (xJCL) definition. Properties specified for checkpoint algorithms in xJCL allow for checkpoint behavior, such as transaction timeouts and checkpoint intervals, to be customized for batch steps. The product provides both a time-based checkpoint algorithm and a record-based algorithm, and defines a service provider interface (SPI) for building additional custom checkpoint algorithms.

• Results algorithms
  Results algorithms are an optional feature of the batch programming model.

Related concepts

Components of a batch application