Run A Batch Job On Open Liberty Application Server

Okay, let’s walk through setting up and running a Jakarta Batch (formerly Java Batch, JSR 352) job on the Open Liberty application server.

1. Prerequisites:

Open Liberty Server: You need an installation of Open Liberty. You can download it from the Open Liberty website.
Java Development Kit (JDK): Ensure a compatible JDK is installed (check Open Liberty documentation for supported versions).
Build Tool (Recommended): Maven or Gradle makes managing dependencies and packaging easier.
Basic Knowledge: Familiarity with Java, Jakarta EE concepts, and ideally the Jakarta Batch specification.

2. Server Configuration (server.xml):

You need to enable the batch feature and configure persistence for job repository data (status, history, etc.).

Enable Batch Feature: Add the batch-3.0 feature (for Jakarta Batch 2.0, part of Jakarta EE 9.1/10) or batch-2.0 (for Jakarta Batch 1.0, part of Jakarta EE 8) to your server.xml‘s <featureManager> section. Using a convenience feature like jakartaee-10.0-webProfile often includes batch already.
Configure Batch Persistence: Define how Liberty stores job data.
- Default (Derby): By default, Liberty uses an embedded Derby database within the server’s workarea. This is fine for testing but not recommended for production or clustered environments.
- Using a Database: For production, configure a dataSource in server.xml pointing to your preferred database (DB2, Oracle, PostgreSQL, MySQL, etc.) and tell the batch facility to use it.

Example server.xml Snippets:

<server description="My Batch Server">

    <featureManager>
        <feature>jakartaee-10.0-webProfile</feature>
        <feature>restfulWS-3.1</feature> <feature>batchManagement-1.0</feature> </featureManager>

    <httpEndpoint httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint" host="*"/>

    <applicationManager autoExpand="true"/>

</server>

<server description="My Batch Server with DB Persistence">

    <featureManager>
        <feature>jakartaee-10.0-webProfile</feature>
        <feature>batch-3.0</feature>
        <feature>jdbc-4.3</feature> <feature>batchManagement-1.0</feature>
    </featureManager>

    <httpEndpoint httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint" host="*"/>

    <library id="db2Lib">
        <fileset dir="${shared.resource.dir}/db2" includes="db2jcc4.jar db2jcc_license_cu.jar"/>
    </library>

    <dataSource id="batchDB" jndiName="jdbc/batchDB">
        <jdbcDriver libraryRef="db2Lib"/>
        <properties.db2.jcc databaseName="BATCHDB" serverName="localhost" portNumber="50000"
                             user="db2user" password="password"/>
    </dataSource>

    <batchPersistence>
        <dataSourceRef ref="batchDB"/>
    </batchPersistence>

    <applicationManager autoExpand="true"/>

</server>

(Remember to replace the dataSource config with details for your specific database and driver)

3. Implement the Batch Job:

A batch job consists of:

Job Specification Language (JSL) XML: Defines the structure of the job (steps, flow, properties). Place this XML file in the META-INF/batch-jobs/ directory of your application archive (e.g., .war file).
Batch Artifacts (Java Classes): Implement the business logic for your job’s steps. Common artifacts include:
- Batchlet: For simple, task-oriented steps (implement jakarta.batch.api.Batchlet).
- ItemReader: Reads items for chunk processing (implement jakarta.batch.api.chunk.ItemReader).
- ItemProcessor: Processes items read by the reader (optional) (implement jakarta.batch.api.chunk.ItemProcessor).
- ItemWriter: Writes processed items (implement jakarta.batch.api.chunk.ItemWriter).
- Listeners: Job/Step/Chunk listeners for lifecycle events.
- Decider: For conditional step execution.

Example:

META-INF/batch-jobs/mySimpleJob.xml:

<?xml version="1.0" encoding="UTF-8"?>
<job id="mySimpleJob" xmlns="https://jakarta.ee/xml/ns/jakartaee" version="2.0">
    <step id="step1">
        <batchlet ref="com.example.batch.MySimpleBatchlet"/>
    </step>
</job>

com/example/batch/MySimpleBatchlet.java:

package com.example.batch;

import jakarta.batch.api.AbstractBatchlet;
import jakarta.batch.runtime.context.JobContext;
import jakarta.inject.Inject;
import jakarta.inject.Named;

@Named // Make it a CDI bean so it can be referenced by the JSL
public class MySimpleBatchlet extends AbstractBatchlet {

    @Inject
    JobContext jobCtx; // Example of injecting batch context

    @Override
    public String process() throws Exception {
        System.out.println("Running MySimpleBatchlet for job: " + jobCtx.getJobName());
        System.out.println("Job Execution ID: " + jobCtx.getExecutionId());

        // Your batch logic here...
        System.out.println("Batchlet finished processing.");

        return "COMPLETED"; // Exit status
    }

    @Override
    public void stop() throws Exception {
        System.out.println("MySimpleBatchlet stopping...");
        // Cleanup logic if needed
    }
}

4. Package the Application:

Package your JSL XML files (in META-INF/batch-jobs/) and your compiled Java batch artifact classes into a standard Jakarta EE application archive, typically a .war or .ear file. Ensure any required dependencies are included or provided by Liberty.

If using Maven, include the Batch API dependency (usually provided scope):

<dependency>
    <groupId>jakarta.batch</groupId>
    <artifactId>jakarta.batch-api</artifactId>
    <version>2.1.1</version> <scope>provided</scope>
</dependency>

5. Deploy the Application:

Deploy your application archive (.war or .ear) to Open Liberty:

Dropins: Copy the archive file to the server_directory/dropins/ folder. Liberty will detect and deploy it automatically.
Server Configuration: Define the application explicitly in server.xml:
xml <application location="myBatchApp.war" type="war" contextRoot="/mybatchapp"/>

6. Running the Batch Job:

You typically start batch jobs programmatically:

Using JobOperator: Inject the jakarta.batch.runtime.JobOperator into another component (like a Servlet, JAX-RS endpoint, EJB) and call its start method.

import jakarta.batch.runtime.BatchRuntime;
import jakarta.batch.runtime.JobOperator;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import java.util.Properties;

@Path("/batch")
public class BatchStarterResource {

    @GET
    @Path("/startSimpleJob")
    @Produces(MediaType.TEXT_PLAIN)
    public String startJob() {
        try {
            JobOperator jobOperator = BatchRuntime.getJobOperator();
            Properties jobParameters = new Properties(); // Optional parameters
            // jobParameters.setProperty("myParam", "myValue");
            long executionId = jobOperator.start("mySimpleJob", jobParameters); // "mySimpleJob" matches the XML file name (or job ID)
            return "Successfully started job mySimpleJob with execution ID: " + executionId;
        } catch (Exception e) {
            return "Error starting job: " + e.getMessage();
        }
    }
}

(This example uses JAX-RS. You’d access it via http://localhost:9080/mybatchapp/batch/startSimpleJob if the app context root is /mybatchapp)

Using Batch Management REST API (Requires batchManagement-1.0 feature):
- POST to /ibm/api/batch/jobinstances
- Headers: Content-Type: application/json
- Body:
  json { "jobXMLName": "mySimpleJob", "jobParameters": { "myParam": "myValue" // Add other parameters here } }
- This is useful for triggering jobs from external systems or scripts.

7. Monitoring and Managing Jobs:

JobOperator: Provides methods like:
- getJobExecution(long executionId): Get details about a specific execution.
- getStepExecutions(long executionId): Get details about steps in an execution.
- stop(long executionId): Attempt to stop a running job.
- restart(long executionId, Properties restartParameters): Restart a failed or stopped job.
- abandon(long executionId): Mark a job execution as abandoned (won’t be restartable).
Batch Management REST API: Provides various GET endpoints to query job instances, executions, steps, and logs, and DELETE endpoints to stop/abandon jobs. Check the Open Liberty documentation for the specific API endpoints.
Logs: Job logs are typically written to the Liberty logs directory (server_directory/logs/) within subdirectories corresponding to the job instance and execution IDs. Check the messages.log and potentially specific job log files.

Remember to consult the specific Open Liberty Jakarta Batch documentation for detailed configuration options and API usage.

Leave a Comment Cancel Reply