Modern Java-based batching in WebSphere application Server (iv)

Integration with Enterprise Scheduler

Brief introduction

IBM WebSphere Application Server V8.5 and later provides a platform for Java-based batch processing applications. In addition to providing a rich programming model and advanced features such as parallel processing, skip record processing, retry step processing, and COBOL support, it also provides enterprise-level "quality" for batch programs, such as availability, recoverability, and performance. Combined with WebSphere application Server support, WebSphere Batch can be an attractive choice for enterprise batch solutions.

Batch processing frameworks simplify the development of different batch jobs, but they do not provide any choreography functionality between the various jobs. This enterprise-class job choreography function is traditionally performed using enterprise schedulers, such as IBM Tivoli workload Scheduler, control-m, or Asg-zeke. The Enterprise Scheduler provides centralized management for batch jobs running on different operating system platforms and manages advanced features such as job dependencies, job monitoring and warning mechanisms, automated job restarts, and restores. Therefore, the Enterprise Scheduler and the batch processing framework provide complementary features that together provide a complete enterprise batch solution.

The WebSphere Batch is essentially an endpoint that the enterprise Scheduler can schedule for the batch job on this endpoint. This article describes how to seamlessly integrate WebSphere Batch with Enterprise schedulers with details and examples. This integration enables the Enterprise Scheduler to become a meta scheduler that provides input for the WebSphere Batch job scheduler. The job scheduler then informs the Enterprise scheduler about the status of the job and updates the execution log.

For simplicity's sake, this article does not cover security aspects or integration with the z/OS environment.

Integrated WebSphere Batch and Enterprise Scheduler

To enable WebSphere Batch to work seamlessly with Enterprise schedulers, WebSphere Batch provides the following features:

Multi-platform support, which enables dispatchers running on different platforms to use it.

Ability to submit and cancel jobs from the Enterprise scheduler.

Continuous feedback and eventually return the status to the Enterprise scheduler.

As described in previous articles in this series, the WebSphere Batch feature provides Web, EJB, and Web service interfaces to perform job management. However, to meet these integration requirements, the WebSphere Batch (on the Distributed platform) provides Wsgrid, a JMS-based integration solution.

The enterprise scheduler interacts with the WebSphere Batch through an Wsgrid client that is a platform-specific batch program, Wsgrid.bat on Windows, and wsgrid.sh on UNIX platforms. The Wsgrid client is essentially a JMS program that makes a request to the WebSphere application Server job scheduler. Job Scheduler server (enhanced by an MDB application) listens for job requests on preconfigured SIBus queues. The MDB application then passes the request to the WebSphere application Server Job Scheduler, which then processes the request normally. The job scheduler continues to issue logs in a predetermined queue. The Wsgrid client constantly updates the Enterprise scheduler as it communicates between queues on the Enterprise scheduler and the WebSphere Application Server Job Scheduler machine. Using Wsgrid greatly simplifies this integration by simply invoking a shell program from the Enterprise scheduler. Figure 1 illustrates this integration.

Figure 1. Integration of Enterprise Scheduler with WebSphere Batch

The sequence of activities in a typical Wsgrid integration is:

The Enterprise scheduler invokes the Wsgrid client batch file.

The Wsgrid client places a JMS Request message on the predefined queues of the WebSphere job scheduler.

The MDB application listens for the request queue, gets the request message, and uses it to submit the job.

The job is then executed on the server endpoint, just as it would normally be committed from the job Management Console.

Output from the server is returned to the enterprise scheduler through a response queue.

When the job is completed, the final status is sent to Wsgrid, and the connection to the WebSphere job scheduler server is turned off. In the process of job processing, Wsgrid continuously gets the output, which is then used by the Enterprise scheduler

Set Wsgrid

Using the infrastructure settings and projects developed in part 3rd of this series, you will follow these steps to set up Wsgrid:

Use the MDB application to enhance the WebSphere Scheduler server and create the JMS infrastructure. This can be done using the wsgridconfig.py script:

Wsadmin.sh-f wsgridconfig.py-install-node <nodeName>-server <serverName>-providers <providerList>

where <providerList> means "hostname,portnumber", PortNumber is the sib_endpoint_address port of the scheduler server.

Listing 1 shows the output of a sample run.

Listing 1

Wsadmin-f wsgridconfig.py-install-providers "anish-pc,7276"-node anish-pcnode01-server Server1 WASX7209I
: Connected to process "dmgr" on node Anish-pccellmanager01 using SOAP 
connector;  The type of process Is:deploymentmanager ...   
wsgridconfig.py is performing install using
  target cluster or server:/node:anish-pcnode01/server:server1/
  MDI Application name     : Jobschedulermdi
  JMS Connection factory   : Com.ibm.ws.grid.ConnectionFactory
  JMS activation spec      : Com.ibm.ws.grid.ActivationSpec
  JMS Input queue name     : Com.ibm.ws.grid.InputQueue
  JMS Output Queue name    : com.ibm.ws.grid.OutputQueue
  installing Wsgrid
  JMS File Store root      :/ Tmp\jobschedulerbus
  SIB identifier           : Jobschedulerbus
  Endpoint provider list   : anish-pc:7276

Back to the column page: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/