# Overview of the Spring Batch Environment

## Overview of the Spring Batch Simple Batch Execution Environment

The diagram below provides an overview of the high level components, technical services, and basic operations required by a batch architecture. This architecture framework is a blueprint that has been proven through decades of implementations on the last several generations of platforms (COBOL/Mainframe, C++/Unix, and now Java/anywhere). The Simple Batch Execution Environment provides a physical implementation of the layers, components and technical services commonly found in robust, maintainable systems used to address the creation of simple to complex batch applications, with the infrastructure and extensions to address very complex processing needs. The materials below will walk through the details of the diagram.

## Simple Batch Execution Environment high level flow and interaction of the architecture.

Figure 1: Batch Execution Environment

Tiers The application style is organized into four logical tiers, which include Run, Job, Application, and Data tiers. The primary goal for organizing an application according to the tiers is to embed what is known as "separation of concerns" within the system. Effective separation of concerns results in reducing the impact of change to the system.

- Run Tier: The Run Tier is concerned with the scheduling and launching of the application. A vendor product is typically used in this tier to allow time-based and interdependent scheduling of batch jobs as well as providing parallel processing capabilities.

- Job Tier: The Job Tier is responsible for the overall execution of a batch job. It sequentially executes batch steps, ensuring that all steps are in the correct state and all appropriate policies are enforced.

- Application Tier: The Application Tier contains components required to execute the program. It contains specific tasklets that address the required batch functionality and enforces policies around a tasklet execution (e.g., commit intervals, capture of statistics, etc.)

- Data Tier: The Data Tier provides the integration with the physical data sources that might include databases, files, or queues. Note : In some cases the Job tier can be completely missing and in other cases one Job Script can start several Batch Job instances.

## High Level Processing Flow

The diagram above illustrates the flow and architecture components in a typical batch run execution.

Standard interaction is described as follows:

1. In the Run tier, a Scheduler starts a batch application by invoking a Job Script. The Scheduler identifies what batch process it wants to run by passing the name of the batch process and any required additional parameters to the Job Script.

2. The Job Script initializes the program and executes any job specific scripts prior to calling the Batch Launcher.

3. The Batch Launcher starts the Batch Execution Environment based upon any environment settings established in the script.

3.1 The Batch Environment starts and controls the batch execution. It initializes the Job execution environment with static configuration items such as database settings, logging levels and creates a Job based on the Job Configuration created by a Batch Developer.

4 Based on configuration provided by a Batch Developer, the Job sequentially executes steps after checking policies to ensure that each step should be started. The status of the job and step (start time, end time, status such as "started" or "completed") is stored at various points during the process.

5.1 In order to maintain data integrity, at the application tier, the Step acts as a controller to ensure that either an entire group of actions completes successfully or that none of the actions completes. This group of actions is referred to as a logical unit of work (LUW). The Step controls the overall execution of the Tasklet, ensuring that transaction are committed at the appropriate time, and restart and statistics information is stored appropriately. The first thing the Step is responsible for is the initialization of the data required to begin processing. The Step will interact with other architecture components, such as the Input Source, to setup the data required to be processed.

5.1.1 The Input Source provides services to access various data sources. It provides location transparency to the Batch Tasklet and hides the physical location details of the data.

5.2 Once the data is initialized by the Input Source, the Step will call into the Tasklet to begin processing. The Tasklet contains the business logic to define the LUW and the Step repeatedly calls the Tasklets LUW to finish the business function. The Step does this by first invoking the execute method on the Tasklet in order to acquire a single record/set of data for processing.

5.2.1 Before a record is returned to the Tasklet, it may be validated by any number of validation Frameworks that can be provided to an input source. A single record/set of data is gathered by interacting with the Input Source.

5.3 Once a record/set has been obtained, the step calls the tasklet to begin processing.

5.3.1 The Tasklet executes its internal business logic by calling other Business Logic components as necessary. Based on the business service, it requests or persists objects from the data access components.

5.3.3 Data Access components can be leveraged retrieve or persist domain objects.

5.3.4 Once the business logic has been executed, the resulting output record is written out by utilizing the Output Source interface. The Step will repeatedly call steps 5.2 -> 5.3 for every record provided by the Input Source.

5.4 Once all of the records are processed, the Step calls the Tasklet to perform any clean up activities such as closing connections, exporting files, etc.

5.4.1 The Step is responsible for committing data associated with the remaining logical units of work as well as performing any finalization and administrative functions (e.g. closing database connections).

Once the Step has completed finalization the control is passed back to the Job, where any necessary logging or clean up is executed for application termination and wrap-up -- provided there are no additional Steps to execute.