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 controls the data selection and ensures that lots created by the BatchIterator are transferred to the LotSlicer.

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".

The BatchIterator is called by the WorkManager for as long as it takes to subdivide the whole batch into lots and slices. The WorkManager calls the LotSlicer for every lot it receives from the BatchIterator. Additionally, progress information and status updates are being returned to the management layer.

BatchIterator

The BatchIterator subdivides the whole batch into lots and slices.

The BatchIterator is a Java SE POJO that is called by the WorkManager in a stateful way. Following the initialization, the WorkManager calls up a lot for as long as it takes for the batch to be completely subdivided.

The data selection takes place via the BusinessLogic or Persistence layer.

LotSlicer

The LotSlicer sends the the slices contained in a lots to the message queue and thus creates a JMS based slice-message for each slice.

The LotSlicer is a Java EE Stateless Session Bean with a REQUIRES_NEW transaction-attribute, as it has to be guaranteed, that all slices of a given lot are written in one transaction.

MessageQueue

The JMS MessageQueue stores the slice-messages until they are processed by the MessageListener.

The JMS Standard defines the interfaces, the queue itself is provided by a manufacturer specific JMS Provider .

As part of an applications server, a JMS-provider-specific message consumer reads a slice-message and subsequently sends it to the MessageListener in a transaction.

MessageListener

The MessageListener removes the JMS "coat" of the SliceMessage and calls up the SliceWorker with the included SliceContext.

The MessageListener is a Java EE Message Driven Bean (MDB) which also takes over several control features like logging of slice-runs or control of the ConsumeOnException-behavior.

Slice Worker

The SliceWorker is responsible for the processing of a whole slice.

The SliceWorker is a Java EE Stateless Session Bean and assures the data consistency of the records of the slice with the correct transaction control.

To achieve this, the SliceWorker sends every record contained in the slice to the RecordProcessor. If problems occur during processing, the SliceWorker defines the ConsumeOnException behavior.

The SliceWorker can be replaced by a SliceProcessor, if the processing takes place without a RecordProcessor.

RecordProcessor

The actual processing of a record for a batch program takes place in the RecordProcessor.

Here, too, a Java EE Stateless Session Bean is used, as this allows for certain behaviors to be achieved in case of processing errors. If transaction attributes are chosen smartly, this can be achieved without damaging the data consistency.

The RecordProcessor processes one or more records using features of the BusinessLogic or the Persistence layer.

Processing Varianten

As already described in the fundamentals of robustness , the idempotence of a batch program takes an important role in daily operations. If a program can be restarted automatically by ensuring data consistency in case of a break-down or if even a All-Or-Nothing strategy was implemented, then it might be the best solution to fail the processing of faulty slices.

For the Consume-On-Exception strategy, the JMS message is not returned to the JMS queue in case of an error, but the message is consciously consumed. This fact and the resulting determining factors are being logged in the job protocol accordingly. The information in the job protocol allows for adjustment procedures to be performed which in turn correct the technical data. Afterwards, a so called "follow-up" can be planned and executed, if necessary.

A special case of the Consume-On-Exception strategy is the Max-Worker-Run strategy. For this strategy the JMS message is consumed directly after the start of the MDB (meaning, without an exception occurring beforehand) if the slice to be processed has exceeded a specific number of worker-runs.