Job Management

The bmap4j framework provides a standardized interface, which is based on JMX and in turn provides technologies to control and monitor status information on batch jobs.

This interface can be used for job management by different management applications and tools which support JMX (e.g. JConsole, JMX for Ant, bmap4j Admin Client, WebSphere wsadmin, JBoss twiddle, ...). Enterprise schedulers which do not support JMX directly (e.g. Control-M) can use specific scripts provided by the framework to connect to the JMX interface of the different application servers.

The "Batch Management" part of the framework contains the following features used to control batch jobs as well as monitor information about programs and jobs:

• Set up batch jobs
• Setting of job parameters
• Validation of job parameters
• Start, stop and abort jobs
• Pause and restart jobs
• Monitor jobs status and progress

Parameter Management

Normally batch programs are controlled by parameters. Depending on the job to run these parameters have different value-vectors which define the jobs mode of operation. The job specific value-vector is set at job start.

If bmap4j is used without the repository, the definition of the value-vectors occurs outside of the bmap4j frameworks. - e.g. in the scheduler as command line parameters of the above mentioned JMX scripts. In the case of functional parameters, changes of the parameter values have to be made in the scheduler, which means that to some extent complex an error-prone processes have to be initiated.

On the other hand if the Batch Repository is used the parameter management takes place centrally using the Batchrepo Webadmin GUI. This is where the different required parameter-value vectors can centrally be defined using the so called parameter templates. At the start of a job the JobController subsequently retrieves the values through the template id from the repository and delivers them to the program, without involving any additional components.

Only the template id must be referenced in the scheduler. In this case changes to the parameter values can also be performed by non-technical operations if adequate privileges are set up. Furthermore the changes will be logged and thus ensures traceability.

Job Protocoll

Together with the processing, the management layer is responsible for the appropriate log creation. By default the logging occurs in a special job log file.

Together with the Batch Repository this information turns into a persistent job protocol. The Batchrepo Webadmin GUI allows for the creation of a detailed analysis regarding job and program.

Error Lists

Usually, a batch program does not have to halt its execution if individual errors on the application level occur. However, those errors have to be collected and passed on to allow for the appropriate corrections to be implemented. In this case, the bmap4j framework provides support features for the creation of error lists and assures, that the errors are, if necessary, logged in the appropriate transaction.

Java EE Program Deployment

Like any other EE application, batch programs with bmap4j support are deployed as EAR in a Java EE environment. The management part of the framework can therefore directly benefit from the deployment service of the applications server for the deployment of the batch program. This is why the deployment of the batch programs integrates seamlessly in the deployment process of your company.

Depending on the used applications server, more or less application server specific features are required to register/deregister management components like the JobController. However, when the architecture was first designed, it was taken into consideration that as many standardized technologies as possible are being used.

Because the control of the batch jobs takes place in the management layer, no Java EE application clients are required to run batch jobs. This means, EE applications client environments do not need to be maintained in order to use the BTP functions.

Java SE Program Deployment

Batch programs, that do not necessarily require Java EE Services like the transactions service, can be run in the InProcess server provided by the framework for testing and debugging purposes. The productive deployment of the batch program in a SE environment is possible, but is not recommended due to the availability of open-source applications servers.

JMX

Since Java SE version 1.4 available and in version 1.5 integrated in the JVM as standard component, JMX provides the ideal basis to control batch programs due to the following reasons:

• Expandable interface, allowing for the realization of specific features.
• Open standard, allowing accessibility of even non java based management tools.

Integration of the Enterprise Scheduler

One of the reasons to implement accruing tasks as batches is the desire to use the processing performance of the server outside of online times of interactive programs. This means, the batch programs oftentimes have to be monitored outside of the regular hours of operation. This usually occurs automatically with the help of scheduling programs.

Smaller companies oftentimes use platform specific tools (e.g. cron, at). If those are not adequate for the respective requirements, cross platform enterprise schedulers (e.g. BMC Software Control-M, CA Workload Automation, arvato Systems Bagjas, etc.) are being used.

The management functions provided by the bmap4j framework via JMX allow for an efficient integration of the batch programs with the scheduler components.