Document: BPM Scheduling with Job Scheduler

Author: Neil Kolban

Date: 2009-03-26
Version: 0.1

BPM Scheduling with Job Scheduler

On occasion it may be desired to start BPM processes at configured 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. 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 IBMs BPM solutions to
provide a variety of techniques to allow BPM based jobs to be scheduled and initiated.
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 paper 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 WPS based activities.

The nature of a WPS Job

When we look at WPS and ask what is it that we wish to periodically start? the answer
is an SCA Module. These modules can contain BPEL processes, Business Rules,
State machines and a variety of other BPM artifacts. One of the cleanest ways to start
an SCA Module is through an SCA Export component that publishes an externally
callable interface. 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 WPS can also be employed including
REST, JMS, MQ and others.

The Job Scheduler Java API

Job Scheduler exposes set of Java classes that can be used to build a custom Java
program that is tailored to call WPS. 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().
Page | 1

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 an
SCA module 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:
http://jobscheduler.sourceforge.net/

An Interface was created in WebSphere Integration Developer (WID) that describes

how the SCA Module looks to the outside world.

Figure 1 Our sample interface

The operation that is defined is very simple and configured to be one-way. When a Job
is started, it isnt clear what it would mean to return a response. There is nothing to
prevent request/response calls being made but the process would have to be relatively
short running which may not be the case. It is suspected that Job Scheduler can
examine the response from preceding jobs and based on the results; determine whether
or not to proceed to subsequent jobs.
The BPEL Process itself is also trivial. It looks as follows:

Figure 2 Our sample BPEL process

When invoked, it merely logs to the console that it has been called. Obviously this
could be an arbitrarily complex process that performs any amount of business
processing but our primary goal here is to illustrate that a process can be started by the
Job Scheduler. If we see a message in the console, we will know the process ran. If
this type of process can be started, we should be able to happily assume any process
could be started.
Page | 2

In the SCA Assembly diagram, the process is exposed as a Web Service through an
SCA Export component with Web Service bindings.

Figure 3 Assembly diagram with Web Services Export

So far, we have done nothing special relating to Job Scheduler. Everything described
up to this point has been basic WPS 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 BPEL process called MyProcess at scheduled intervals through the Job
Scheduler environment.
The overall schematic is shown in the following image.

Figure 4 Overall schematic

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 WPS is ready to be executed, custom
Java code will be called which will make a Web Services call to WPS which will in turn
execute the process when the request is received.

Page | 3

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 called our project SampleJavaJob. Since this code
needs to make a Web Service call to WPS, 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.
Expand the Business Integration View module and Web Service Ports. There you will
find a Web Service definition for the export from the SCA Module. Right click on this
entry and select Web Services Generate Client.
Change the Web service runtime to be IBM WebSphere JAX-WS and change the
client project to be SampleJavaJob. This is the Java project we created earlier and is
where the generated Java classes that call the Web Service are to be stored.

Figure 5 Generating a Web Services client

Page | 4

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 sos.spooler.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.

Figure 6 Adding the Job Scheduler Jar file to the build path

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.

Page | 5

Figure 7 Creating the Job class

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 BPEL
process. The following code shows our implementation.
public class SampleJavaJob extends Job_impl {
@Override
public boolean spooler_process() throws Exception {
spooler_log.info("Web Service Job Starting");
// Called when the scheduler wishes this job to run
Page | 6

MyProcessMyInterfaceHttpService webService = new

MyProcessMyInterfaceHttpService();
MyInterface myInterface =
webService.getMyProcessMyInterfaceHttpPort();
// Invoke the operation
myInterface.myOperation("Hello World!");
spooler_log.info("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.

Page | 7

Figure 8 Exporting the code as a JAR file

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. This jar is called
com.ibm.jaxws.thinclient_6.1.0.jar and is provided with a WAS 6.1 server.
Within WID, this can be found in the <WID>/runtimes/base_v61_stub/runtimes
directory.
Page | 8

An example entry for factory.ini may look like:

[java]
class_path = C:\Program
Files\IBM\WID62\runtimes\base_v61_stub\runtimes\com.ibm.jaxws.thinclient_6.1.
0.jar;C:\Projects\Schedulers\JobScheduler\MyJars\MyJob.jar;C:\Program
Files\scheduler\lib\*.jar

One final change must be made to the Job Scheduler configuration. This change is a
little more subtle. In order to invoke the IBM Web Services calls, the Java runtime of
Job Scheduler must use the IBM Java Runtime (JVM). It is not sufficient to simply run
Job Scheduler with this JVM in the program path. Job Scheduler provides a second
configuration file called sos.ini which is again found in the <scheduler>/config
folder. This file should be edited and an entry under [java] should be added. An
entry called vm should be added which points to the jvm.dll file provided by the IBM
Java runtime. In our example we used the WPS runtime JVM file found in
<WPS>/java/jre/bin/j9vm.
The resulting entry in sos.ini looks as follows:
[java]
;vm = C:\Program Files\Java\jre6\bin\client\jvm.dll
vm = C:\Program Files\IBM\WID62\runtimes\bi_v62\java\jre\bin\j9vm\jvm.dll

With these changes made, we are now ready to start Job Scheduler.
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

Page | 9

Figure 9 Creating a new Job definition

Give the new Job a meaningful name, for example BPEL Process.

Figure 10 Naming the new Job

Next click on the Execute element in the left pane to 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.

Page | 10

Figure 11 Defining the details of the Job

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.

Page | 11

Figure 12 The primary scheduler console

Make sure that the SCA Module we are about to call is installed and running in the WPS
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 unforced now. 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.

Figure 13 Starting the Job immediately

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

Page | 12

Figure 14 Viewing the results

If we examine the history in the console log of WPS, 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.

Figure 15 Setting the run times for the Job

Page | 13

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

Figure 16 Defining the run times

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

Figure 17 Setting the Repeat Times

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

Page | 14

Figure 18 Scheduled Results

Obviously Job Scheduler has a lot of features and we have barely scratched the surface
on how to use it but what this paper 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 | 15