BPM Scheduling with Job Scheduler

Transcription

1 Document: BPM Scheduling with Job Scheduler Author: Neil Kolban Date: 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 IBM s 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

2 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: 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 isn t 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

3 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

4 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

5 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

6 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 public boolean spooler_process() throws Exception { spooler_log.info("web Service Job Starting"); // Called when the scheduler wishes this job to run Page 6

7 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

8 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

9 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_ 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

10 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

11 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 In the Jobs page, we can see the Job we have just defined. Page 11

12 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

13 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

14 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

15 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