SchedulerAdapter

The SchedulerAdapter forms the interface between the world of the administration tools and the management layer of the batch program.

The basic features of the scheduler adapter interface are:

• Create jobs and determine job parameters
• Start and monitor jobs, and deliver exit and reason codes as well as reason text
• Keep track of current job state and progress

In the development environment, the triggering of the job occurs manually, in the test environment, testdriver are used and in production, the control is most likely assured by the enterprise scheduler.

The enterprise scheduler is a component, which is independent from the batch framework and controls the chronological and local dependency for the job execution in a way, that an optimal load balancing across several platforms can be assured and control within the batch environment can be guaranteed.

JobController

The JobControllers task is the direct control of the batch jobs.

The Job-Controller is a JMX Bean or a Servlet, which receives the commands from the scheduler via the scheduler adapter. In return, the controller provides the schedulerAdapter with status- and progress information.

If there is a batch repository, the job-controller will get information necessary for planning, e.g. the job parameters, from the repository and writes status information to the repository in return.

Coupler

The coupler allows for the communication of the processing components with the management layer.

On the one hand, the coupler receives runtime Artifacts like technical error messages or recap-information from the processing components and transfers the runtime artifacts to the JobController & repository. On the other hand, it transfers management commands , e.g. an abort request, to the processing layer.

In a JEE environment, the coupler is responsible for ensuring transaction control with the repository, if runtime Artifacts need to be written to the repository.

Repository

The Repository provides the persistence layer of the batch framework.

It contains planned jobs on the one hand and persists on the other hand the runtime artifacts during program execution.

The access for the planning as well as the analysis of the jobs takes place per Webadmin GUI. More information on this is available at Xinventa .

BusinessLogicService

The BusinessLogicService is not part of the actual batch framework anymore, but it is the part of the BusinessLogic, on which the BTP Architecture is based on (refer to fundamentals ).

Non performance sensitive applications can directly use the functions intended for OLTP. However, as soon as the performance becomes a decisive factor, the BusinessLogic layer most likely has to be extended by features for mass selection and mass update.

It might be useful for simple batch programs to directly access the functions of the Persistence layer for the sake of efficiency without encapsulation by a BusinessLogic Layer.

WorkManager

The Workmanager takes over a central role in the WorkManager-Only Pattern by executing the data selection and delegating work to the record processor.

In a Java EE environment, the WorkManager with advantage is a Stateless Session Bean, which usually runs without a transaction to avoid potential problems with possible transaction-timeouts, if longer durations are expected or the batch program needs to be turned "suspendable".

With the help of the BusinessLogic the WorkManager selects the records that need to be processed and calls the RecordProcessor with the optimal number of records.

RecordProcessor

The recordProcessor processes one or more records using functions of the BusinessLogic layer.

Like the WorkManager, the RecordProcessor is a Stateless Session Bean, thus ensuring data consistency with transactions.

If only simple manipulations are to be performed on the records, in many cases no explicit RecordProcessor is required, but the BusinessLogic or Persistence layer is accessed directly from the WorkManager.