You can package an existing batch application as an OSGi application. You then deploy the package so that you can expose batch artifacts as services, making those artifacts visible to the batch container.
Package an OSGi batch application, modify the Blueprint xml file to describe batch artifacts as services, and export the OSGi batch application as an enterprise bundle archive (EBA). Then create the xJCL. Finally, deploy the OSGi batch application.
You package the OSGi batch application as an EBA. The EBA contains at least your batch bundle, which is a Blueprint bundle. The API bundle and the dispatcher bundles are installed once into the internal bundle repository.
Read the topic on creating a client bundle and follow the steps to package your OSGi application.
You must declare the job steps and batch data streams as services so that the scheduler can invoke them. If your OSGi batch application implements a checkpoint policy algorithm or a results algorithm, then you must also declare as a service each algorithm that the application implements.
Compute intensive step example:
<bean id="IVTStep1" class="com.ibm.websphere.batch.samples.tests.steps.GenerateDataStep" scope="prototype"/>
<service ref="IVTStep1" interface="com.ibm.websphere.ci.CIWork" id="step1">
<service-properties>
<entry key="xjcl:classname" value="com.ibm.websphere.batch.samples.tests.steps.GenerateDataStep"/>
</service-properties>
</service>
Transactional batch step example:
<bean id="EchoStep2" class="com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep" scope="prototype"/>
<service ref="EchoStep2" interface="com.ibm.websphere.batch.BatchJobStepInterface" id="echostep1">
<service-properties>
<entry key="xjcl:classname" value="com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep"/>
</service-properties>
</service>
Batch data stream example:
<bean id="output" class="com.ibm.websphere.batch.samples.tests.bds.TestOutputBatchDataStream" scope="prototype"/>
<service ref="output" interface="com.ibm.websphere.batch.BatchDataStream" id="out1">
<service-properties>
<entry key="xjcl:impl-class" value="com.ibm.websphere.batch.samples.tests.bds.TestOutputBatchDataStream"/>
</service-properties>
</service>
If your OSGi batch application implements a checkpoint policy algorithm, then declare the algorithm as a Blueprint service. Otherwise, skip this step.
Checkpoint policy algorithm example:
<bean id="chkpt" class="com.ibm.websphere.batch.samples.MyCheckpointAlgorithm" scope="prototype"/>
<service ref="chkpt" interface="com.ibm.wsspi.batch.CheckpointPolicyAlgorithm" id="ck1">
<service-properties>
<entry key="xjcl:impl-class" value="com.ibm.websphere.batch.samples.MyCheckpointAlgorithm"/>
</service-properties>
</service>
If your OSGi batch application implements a results algorithm, then declare the algorithm as a Blueprint service. Otherwise, skip this step.
Results algorithm example:
<bean id="myres" class="com.ibm.websphere.batch.samples.MyResultsAlgorithm" scope="prototype"/>
<service ref="myres" interface="com.ibm.wsspi.batch.ResultsAlgorithm" id="r1">
<service-properties>
<entry key="xjcl:impl-class" value="com.ibm.websphere.batch.samples.MyResultsAlgorithm"/>
</service-properties>
</service>
<step id=”step1”>
<classname> com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep</classname>
</step>
Read the topic on deploying an OSGi application as a business-level application and follow the steps.
You packaged an OSGi batch application, modified the Blueprint xml to describe batch artifacts as services, and exported the OSGi batch application as an enterprise bundle archive (EBA). Then you created the xJCL. Finally, you deployed the OSGi batch application.