Process Scheduling with Job Scheduler

On occasion it may be required to start an IBPM process at configurable times of the day or week. To automate this task, a scheduler must be employed. Scheduling is the ability to set up recurring dates and times and have work kicked off at those times. An item of work that is to be executed is termed a job.

IBPM has an in-built ability to schedule work (see: Schedule initiated UCAs). In this section we will look at some alternatives that may add additional function.

Although WebSphere Application Server (WAS) has a built in scheduler, it is designed primarily for programmers to code against and does not easily lend itself to a generic business level job scheduling mechanism.

Examining the Open Source offerings, an Open Source product called Job Scheduler is available that provides a powerful and rich framework for job scheduling. This includes a rich user interface to perform administration of the majority of scheduling tasks at a very high level. Job Scheduler can be combined with IBM’s IBPM solutions to provide a variety of techniques to allow IBPM based jobs to be scheduled and initiated.

Job Scheduler can be download from:

Job Scheduler is particularly flexible in the kinds of application types it can start. Using the product you can configure a Job and then when the start time is reached, that Job is initiated. The choices of application types that can be started include Java classes, native commands, scripts and much more.

The goal of this section is not to document Job Scheduler; the documentation available at the product web site seems more than sufficient for that task. Instead, this paper focuses on using Job Scheduler to initiate IBPM based activities.

The nature of a IBPM Job

When we look at IBPM and ask “what is it that we wish to periodically start?” the answer is a IBPM General Service. If this interface is exposed through a Web Service, then the nature of the Job that is to be started from the Job Scheduler will be the invocation of that interface through a SOAP/HTTP request call.

Other bindings between Job Scheduler and IBPM can also be employed including REST, JMS, MQ and others.

The Job Scheduler Java API

Job Scheduler exposes a set of Java classes that can be used to build a custom Java program that is tailored to call IBPM. Key amongst these classes is one called sos.spooler.Job_impl. This class can be extended by a custom user written class. In the custom class, one can then implement a method called spooler_process(). When Job Scheduler wishes to invoke a Java based Job, the result will be a call to this method. In the body of this method, one can then code arbitrary Java calls to achieve the function that the Job is to perform. In our case, this will result in the invocation of a IBPM process through a Web Service binding.

An illustrative solution

To demonstrate how these tasks can be achieved, we will work through a simple scenario. We will assume that you have downloaded and installed the latest version of Job Scheduler. This can be found at the Job Scheduler web site:

We start by creating a General Service in PD that exposes the input to the process that we may want. The General Service looks like:

with variables defined as:

This service does nothing more than log it was called but in reality could invoke a UCA to start a BPD instance.

Next we define a Web Service resource to expose starting the General Service as a Web Service. This also defines the operation associated with the service. In our example, the operation is called "startProcess".

So far, we have done nothing special relating to Job Scheduler. Everything described up to this point has been basic IBPM oriented activities but what we have achieved is to set the stage by building and describing a simple test environment. Our goal now is to invoke the Generic Service called "Start Process" at scheduled intervals through the Job Scheduler environment.

The overall schematic is shown in the following image.

Job Scheduler will be configured with Job definitions that say what needs to happen and when. When a Job that is to be executed on IBPM is ready to be executed, custom Java code will be called in the context of Job Scheduler which will make a Web Services call to IBPM which will in turn execute the process when the request is received.

The next step in our solution is to build the Java Job code. We will start by building a simple Java Project in WID (we could also use RAD). We called our project SampleJavaJob.

Since this code needs to make a Web Service call to IBPM, it is now time to build the Web Service client caller function. WID has the ability to take a WSDL file and generate all the Java code needed to invoke the service described by this WSDL. This makes calling a Web Service from Java a very easy proposition. The generated code will eventually be invoked by the Job Scheduler.

Right click the new project and select New > Other.

Within the Web Services folder, select Web Service Client:

In the next page of the Wizard, enter the URL show in the Web Services definition in IBPM PD.

On the next page, set the Target package to be a meaningful name (for example, wle.webservice).

All the other settings can remain with their default settings. At the conclusion of this wizard activity, Java code will have been generated that will invoke the process as a Web Service. It is this code that we wish to invoke from within the Job Scheduler. Our next steps will be the creation of the Job Scheduler wrapper class.

Modify the build path of the Java profile within WID to include the com.sos.spooler-<version>.jar that is supplied with Job Scheduler and found in the <Scheduler>/lib folder. This Jar contains classes that we will need in our custom code. It provides the contract between Job Scheduler and the custom Job we are writing.

Create a new Java class that extends sos.spooler.Job_impl. We named this class SampleJavaJob. By extending the Job Scheduler supplied class, we inherit the necessary contracts and framework for Job Scheduler to invoke our own custom code.

The implementation of the class must implement/override a method called spooler_process() . This method is called to invoke an instance of the job. In our implementation we wish this to invoke a Web Service which in turn will invoke the BPD process. The following code shows our implementation.

package scheduler.test; import sos.spooler.Job_impl; import wle.webservice.WS1; import wle.webservice.WS1PortType; public class SampleJavaJob extends Job_impl { @Override public boolean spooler_process() throws Exception {"Web Service Job Starting"); // Called when the scheduler wishes this job to run WS1 ws1 = new WS1(); WS1PortType ws1PT = ws1.getWS1Soap(); ws1PT.startProcess("Hello World");"Web Service Job Ending"); return false; } }

The code for the Java class is very simple. It creates an instance of the Service and then asks for the interface from that Service. Once in possession of the Interface, we are able to invoke the operation described within. We have hard-coded the parameter for the interface but this could also be dynamically supplied if required.

With the coding complete for the Job, what remains is to make Job Scheduler aware of the new class so that we can define a scheduled Job to invoke it. First we export the SampleJavaJob project as a JAR file. This will include the code we just created.

Job Scheduler has a configuration file called factory.ini that is located in<scheduler>/config directory. This file can be edited with notepad or a similar text editor. Within the file is a section called [java]. This contains an entry called class_path. We must now modify this entry.

First we must add the JAR file we just exported.

Next we must add a second jar file which is the IBM supplied set of libraries for making Web Services calls for JAX-WS. This jar is called and is provided with a WAS 6.1 server. Within WID, this can be found in the <WLE>/AppServer/runtimes directory.

An example entry for factory.ini may look like:

[java] class_path = C:\IBM\Lombardi7\AppServer\runtimes\;C:\Projects\WLE\Scheduler\MyJob.jar;C:\Program Files\scheduler\lib\*.jar

With these changes made, we are now ready to start Job Scheduler. If Job Scheduler is already started, shut it down first

From a DOS window and located in the <scheduler>/bin directory, we run the command:

jobscheduler.cmd start

The program runs and holds the DOS Window open. In production, it would be started from the Windows Services.

We are now ready to define the Job to the scheduler. Launch the Job Scheduler editor by running the command jobeditor.cmd.

Create a new job from the menu

File ► New ► Hot Folder Element ► Job

Give the new Job a meaningful name, for example “IBPM Process”.

Next within the Execute section define how the Job will run. Define the job to be a script and written in Java. In the Classname field, enter the full name of the Java Job class including its package name. Remember that in a previous set of steps we exported the implementation of this class as a Jar file and then added the Jar into the class path of Job Scheduler.

Save the result in the <scheduler>/config/live folder.

Launch the Web based dashboard for Job Scheduler. This can be achieved by opening a browser to http://localhost:4444/.

In the Jobs page, we can see the Job we have just defined.

Make sure that the IBPM Process Application we are about to call is installed and running in the IBPM server. In the next step we are about to execute it. Clicking on the Job definition shows us details of that Job. In the Job menu, we find and select an entry called “Start task immediately". This will cause Job Scheduler to run an instance of the job immediately. This will prove to us that Job Scheduler is able to invoke the process.

After completion and clicking on the Last Activities button, the result will be:

If we examine the history in the console log of IBPM, we will have found that the process will have executed. What remains is to schedule the work to be executed at configured times in the future, for our testing purposes; we will have the process run every 15 seconds.

From the Job menu, select “Set run time”.

Click on the “run time editor” button to launch the assistance window for creating run time specifications.

In the assistance window, enter a value of 15 seconds in the “Repeat Time” field.

Complete the changes and then watch the results. After a short period of time we will find that the General Service has executed every 15 seconds.

Obviously Job Scheduler has a lot of features and we have barely scratched the surface on how to use it but what this section has shown is how to expose a Business Process as a Web Service, how to write a Java Job wrapper to call that Web Service, how to define the Java Job to Job Scheduler and finally how to run a simple test to ensure that Job Scheduler can correctly call the process.

Page 5

No Comments
Back to top