WebSphere Extended Deployment Compute Grid, Version 6.1.1
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Building a batch application using POJO

This topic describes the steps required to build and package a batch application using the Plain Old Java Object (POJO) programming model.

Before you begin

Building a POJO-based batch application is the preferred method for building a batch application. Refer to The batch programming model and POJO programming model for additional information.

As an option, you can use the following scripts to replace steps 3 - 5 located in the following Procedure section:

Set the Java virtual machine custom propertycom.ibm.websphere.ejbcontainer.expandCMPCFJNDIName. See Java virtual machine custom properties .

WSBatchPackager.sh
                 -properties=<properties file name>
                 [-debug]

or

WSBatchPackager.sh
		-appname=<application name>
		-jobsteps="{{<ejb name>, <jndi name>, <POJO step class> [, jar file, utility jars]}, ...}"
		-jarfile=<jarfile containing POJO step classes>
		-earfile=<output ear file name>
		[-utilityjars=<semicolon separated utility jars>]
		[-epjndiname=<endpoint/checkpoint datasource jndi name>]
		[-nonxadsjndiname=<non-xa datasource JNDI name for CursorHoldableJDBCReader>;<non XA datasource JNDI name 2>;...]
		[-debug]

Alternatively, packager can be invoked as shown below:

  java -jar batchpackager.jar 
                 -properties=<properties file name>
                 [-debug]

or

  java -jar batchpackager.jar
                 -appname=<application name>
                 -jobsteps="{{<ejb name>, <jndi name>, <POJO step class> [, jar file, utility jars]}, ...}"
                 -jarfile=<jarfile containing POJO step classes>
                 -earfile=<output ear file name>
                 [-utilityjars=<semicolon separated utility jars>]
                 [-epjndiname=<endpoint/checkpoint datasource jndi name>]
                 [-nonxadsjndiname=<non-xa datasource JNDI name for CursorHoldableJDBCReader>;<non XA datasource JNDI name 2>;...]
                 [-debug]

Procedure

  1. Create batch job steps. Create a new Java class that implements the interface com.ibm.websphere.BatchJobStepInterface. Implement business logic.

    If your step has exactly one input and one output stream you could alternatively use the Generic batch step (GenericXDBatchStep) .

  2. Create batch data streams. Create a new Java Class that implements the interface com.ibm.websphere.batch.BatchDataStream. Batch data streams are accessed from the business logic (i.e. from the batch job steps) by calling BatchDataStreamMgr with jobID and stepID. JobID and stepID are retrieved from the step bean properties list using keys BatchConstants.JOB_ID and BatchConstants.STEP_ID. Map BatchConstants.JOB_ID to com.ibm.websphere.batch.JobID and map BatchConstants.STEP_ID to com.ibm.websphere.batch.StepID. You should already have access to the BatchConstants class.
    The batch datastream framework provides several ready-to-use patterns to work with different types of datastreams. For example, file, database, and so on. To use the batch datastream framework:
    • Identify the data stream type you want to operate with (TextFile, ByteFile, JDBC, z/OS stream),
    • Identify whether you would be reading or writing data from/to this stream.
    • Refer to the table in Batch data stream framework and patterns , and select the class from the supporting classes column that matches your data stream type and operation. For example, if you want to read data from a text file then you would choose TextFileReader.
    • Implement the interface listed in the pattern name column that corresponds to the supporting class you selected in the previous step. The supporting class handles all the book keeping activities related to the stream and the batch programming model, allowing the implementation class to focus on the stream processing logic.
    • Declare the supporting class and your implementation class in the xJCL.
    • Repeat this procedure for each datastream required in your step.
    <batch-data-streams>		
       <bds>
    	<logical-name>inputStream</logical-name>
     	<props>
     	    <prop name="PATTERN_IMPL_CLASS" value="MyBDSStreamImplementationClass"/>
                <prop name="file.encoding" value="8859_1"/>
                <prop name="FILENAME" value="${inputDataStream}" />
                <prop name="PROCESS_HEADER" value="true"/>
                <prop name="AppendJobIdToFileName" value="true"/>
            </props>
    	<impl-class>com.ibm.websphere.batch.devframework.datastreams.patterns.FileByteReader</impl-class>
       </bds>
    Note: The PATTERN_IMPL_CLASS denotes the user's implementation of the BDS framework pattern and the impl-class property denotes the supporting class.
  3. Declare a batch job controller.
    1. Add a stateless session bean to your deployment descriptor and point to the implementation class provided byWebSphere® Extended Deployment by specifying com.ibm.ws.batch.BatchJobControllerBean as the bean class. Do this only once per batch application.
    2. Use com.ibm.ws.batch.BatchJobControllerHome for the remote home interface class and com.ibm.ws.batch.BatchJobController for the remote interface class.
  4. Declare the batch job step wrapper for POJO batch steps.
    1. Add a CMP Entity bean as a wrapper for the batch step to your deployment descriptor and point to the implementation class provided by WebSphere XD by specifying com.ibm.ws.batch.DefaultBatchJobStepBean as the bean class. Do this once per discrete batch step in your application.
    2. Use com.ibm.ws.batch.BatchJobStepLocalHomeInterface for the local home interface class and com.ibm.ws.batch.BatchJobStepLocalInterface for the local interface class.
    3. Specify com.ibm.websphere.batch.BatchJobStepKey for the key class and add two CMP attributes jobID and stepID of type java.lang.String
    4. Define an environment entry in the EJB deployment descriptor to associate the POJO batch step implementation to the wrapper. Specify POJOclass for the environment entry name and the class name of the POJO batch job step for the environment entry value. Use java.lang.String for the environment entry type.
  5. Configure the EJB deployment descriptor.
    1. EJB Resource Reference: Add a reference for each batch step to the Batch Job Controller bean.
    2. WorkManager: Configure a resource reference on the Controller bean to the default WorkManager wm/BatchWorkManager of the type commonj.work.WorkManager.
    3. Cache: For the Job Step wrappers set the bean cache to Activate at ONCE and Load at ACTIVATION.
    4. Transactions: To ensure job steps are run under the scope of a global transaction, set the transaction-attribute as REQUIRED.

Example

appname=testBatchApp
jarfile=c:\\websphere\\appserver\\temp\\pojoclasses.jar
earfile=TestBatchAppEAR

ejbname.1=POJOStep1
jndiname.1=ejb/POJOStep1
jobstepclass.1=com.ibm.ws.batch.sample.POJOStep1.class

ejbname.2=POJOStep2
jndiname.2=ejb/POJOStep2
jobstepclass.2=com.ibm.ws.batch.sample.POJOStep2.class



Related concepts
POJO programming model
Related tasks
Developing a simple batch application
Related information
Java virtual machine custom properties
Task topic    

Terms of Use | Feedback

Last updated: Oct 30, 2009 1:38:02 PM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.gridmgr.doc/info/scheduler/tcgbuildbatch.html