Introduction
The Scheduler service in WebSphere® Business Integration Server Foundation Version 5.1 (formerly WebSphere Application Server Enterprise) is a full-featured timer service that enables high performance, high availability, persistence and transactional scheduling of J2EE operations.
The Scheduler is comprised of two components:
• Scheduler resource
• Scheduler API.
The Scheduler resource represents a Scheduler instance that is available in the WebSphere Application Server Java™ Naming and Directory Interface (JNDI). Each Scheduler resource has unique properties that govern its behavior; for example, in which database to store the persistent schedules. The Scheduler resource is configured using the standard WebSphere Application Server administrative console (admin console) or the AdminControl scripting object.
The Scheduler API is a Java interface that enables creating and administering tasks. The API is accessible from any J2EE server application (Enterprise Java Beans and servlets).
The Scheduler enables the execution of two types of tasks:
• Calling stateless session Enterprise Java Beans (EJBs). (This approach is shown here).
• Sending Java Message Service (JMS) Messages.
The Scheduler stores its data in any database that WebSphere Application Server supports and uses the WebSphere Application Server Transaction Manager. All Scheduler operations are therefore transactional and persistent; each task is guaranteed to run successfully one time. If a task fails for any reason, the entire operation is rolled back.
The Scheduler enables application developers to create their own stateless session EJBs to receive event notifications during a task's life cycle, allowing the plugging-in of custom logging utilities or workflow applications. Stateless session EJBs are also used to provide generic calendaring. Developers can either use the supplied calendar bean or create their own for their existing business calendars.
Configuring schedulers using the administrative console
Schedulers can be created or configured using the administrative console.
Procedure
1. Start the administrative console.
2. Select Resources > Schedulers.
3. Click New.
4. Specify configuration settings.
5. Click OK or Apply to save the changes.
6. Save the changes to the configuration repository.
Here is an example .
1. Scheduler Name : MySchedular
2. JNDI Name : sched/MyScheduler
3. Data Source JNDI Name : DataSource should be created using jdbc->Data Source and list box will list that data source.
4. Data Source Alias: Alias should be create using Secure administration, applications, and infrastructure > JAAS - J2C authentication data >
Step Wise Images of from Admin console to create Scheduler,J2C Authentication Alias and Data Source.
StepWise Example with Images
JAAS - J2C authentication data
Data Source Creation Part One
DataSource Creation Part two
Creating Tables For Scheduler
1. Verify that the database to be used for this scheduler is available and accessible by the application server. Review the Creating scheduler databases and tables topic for instructions on creating a database. The remaining steps describe how to create scheduler tables in an existing database. We will be using DB2 Database here.
2. Start the administrative console.
3. Create a JDBC data source that refers to the scheduler database.
4. Test the data source connection.
5. Create a scheduler. This configuration object contains the desired table prefix and the JNDI name of the JDBC data source. Verify that you save the new Scheduler to the configuration repository before you proceed to the next step.
6. Click Resources > Schedulers to view all defined schedulers.
7. Select one or more schedulers.
8. Click Create Tables to create the tables for the selected schedulers in their associated database. The tables and indices you created reflect the table prefixes and data sources specified in each scheduler configuration.
9. Restart the server or start the poll daemon to run scheduler tasks.
Accessing schedulers
Each configured scheduler is available using the Scheduler API from a J2EE server application, such as a servlet or EJB module. Use a JNDI name or resource reference to access schedulers. Each scheduler is also available using the JMX API, using its associated WASScheduler MBean. However we will use the first one here.
StartUpBeans
We have used A startUpBeans here to fire the Scheduler. An application startup bean is a session bean that is loaded when an application starts. Application startup beans enable Java 2 Platform Enterprise Edition (J2EE) applications to run business logic automatically, whenever an application starts or stops normally.
A. Startup beans are especially useful when used with asynchronous bean features. For example, a startup bean might create an alarm object that uses the Java Message Service (JMS) to periodically publish heartbeat messages on a well-known topic. This enables clients or other server applications to determine whether the application is available.
B. For Application startup beans, use the home interface, com.ibm.websphere.startupservice.AppStartUpHome, to designate a bean as an Application startup bean and use the remote interface, com.ibm.websphere.startupservice.AppStartUp, to define start() and stop() methods on the bean.
C. The startup bean start() method is called when the module or application starts and contains business logic to be run at module or application start time.
D. The start() method returns a boolean value. True indicates that the business logic within the start() method ran successfully. Conversely, False indicates that the business logic within the start() method failed to run completely. A return value of False also indicates to the Application server that application startup is aborted.
E. The startup bean stop() methods are called when the module or application stops and contains business logic to be run at module or application stop time. Any exception thrown by a stop() method is logged only. No other action is taken.
F. The start() and stop() methods must never use the TX_MANDATORY transaction attribute. A global transaction does not exist on the thread when the start() or stop() methods are invoked. Any other TX_* attribute can be used. If TX_MANDATORY is used, an exception is logged, and the application start is aborted.
G. The start() and stop() methods on the remote interface use Run-As mode. Run-As mode specifies the credential information to be used by the security service to determine the permissions that a principal has on various resources. If security is on, the Run-As mode needs to be defined on all of the methods called. The identity of the bean without this setting is undefined.
H. There are no restrictions on what code the start() and stop() methods can run, since the full Application Server programming model is available to these methods.
An Example of Start method in StartUp Bean.
Developing a TaskHandler Session Bean
This topic describes how to create a task to call a method on a TaskHandler session bean. We will use EJB Session Beans to fire the Job.
Procedure
1. Create a new enterprise application with an EJB module. This application hosts the TaskHandler EJB module.
2. Create a stateless session bean in the EJB Module that implements the process() method in the com.ibm.websphere.scheduler.TaskHandler remote interface. Place the business logic you want created in the process() method. The process() method is called when the task runs. The process method should contain the actual business method that should be fired by the Scheduler. The Home and Remote interfaces must be set as follows in the deployment descriptor bean:
o com.ibm.websphere.scheduler.TaskHandlerHome
o com.ibm.websphere.scheduler.TaskHandler
3. Create an instance of the BeanTaskInfo interface by using the following example factory method. Using a JavaServer Pages (JSP) file, servlet or EJB component, create the instance as shown in the following code example (Example is above used and Stateless EJB to call TaskHandler). This code should coexist in the same application as the previously created TaskHandler EJB module:
4. // Assume that a scheduler has already been looked-up in JNDI.
5. BeanTaskInfo taskInfo = (BeanTaskInfo) scheduler.createTaskInfo(BeanTaskInfo.class).
Startup beans service settings
Use this page to enable startup beans that control whether application-defined startup beans function on this server. Startup beans are session beans that run business logic through the invocation of start and stop methods when applications start and stop. If the startup beans service is disabled, then the automatic invocation of the start and stop methods does not occur for deployed startup beans when the parent application starts or stops. This service is disabled by default. Enable this service only when you want to use startup beans. Startup beans are especially useful when used with asynchronous beans.
To view this administrative console page, click Servers > Application servers >server_name > Container services > Startup beans service.
Summary
In this way we can schedule a task or any business logic inside Websphere Application Server. The moment Server is up and Application starts up Start Up Beans will start firing the Scheduler using TaskHandler process method.
For API/Resources about
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.javadoc.doc/public_html/api/com/ibm/websphere/scheduler/TaskHandler.html
