Managing tables of the WebSphere Appplication Server scheduler from Java

Posted by eugene as Websphere


WebSphere is a cool application server with a lot of benefits but it wonders very much how accurately IBM conceals all this from the masses of curious developers. This article highlights the internal control process of the tables control of the internal tasks scheduler directly from the java-application code.

The information about work with the scheduler and its deployment is available in Internet.But once I needed to control the tables integrity directly from applicaiton. And from that moment I had some fun. I haven’t found any information about this process in the internet. Though documentation is for sure available but in scopes of the administration tasks resolution and the examples are given in JACL and Jython languages. In order to move the algorithm into Java it’s clearly not enough as the approaches are a little different.

WebSphere posesses with the internal mechanism of tasks planning. And this is wonderful. For its work you need to deploy the scheduler tables in the database where it will store its tasks. The structure of these tables is represented clearly in the corresponding ddl scripts provided together with WebSphere (AppServer\Scheduler\*.ddl). Moreover, you can even not take care of these tables and to store them in the internal server Derby-base which is provided with the application server of 6.1 version the only package. How is it still possible to control the table scheduler?

I’ve resolved this problem by using the classes of IBM com.ibm.ws.runtime_6.1.0.jar (AppServer\plugins\com.ibm.ws.runtime_6.1.0.jar) library. I haven’t found the documentation about these classes either, that’s why I started my ruthless analysis armored with the help of decompiler.


Let’s consider the scheduler is deployed and we can refer to it by the JNDI path (for example, java:comp/env/scheduler/ReportScheduler):

    Context initialContext = null;
    Scheduler scheduler = null;
        initialContext = new InitialContext();
        scheduler = (Scheduler) initialContext.lookup(SCHEDULER_JNDI_NAME);
    }  catch (NamingException e) {
        throw new SchedulerException("Ошибка инициализации: " + e.getMessage(), e);
    } finally {
        if (initialContext != null) {
            try {
            } catch (NamingException e) {
                logger.log(Level.SEVERE, e.getMessage(), e);

The class which implements the scheduler tables management logics is WASSchedulerCfgHelper which performs the SchedulerConfigHelper interface. The main functions which we need are as follows:

Verification of tables availability

public void verifyTables(SchedulerConfiguration paramSchedulerConfiguration)
throws SchedulerDataStoreException;

Tables creation:

public Boolean createTables(SchedulerConfiguration paramSchedulerConfiguration)
throws SchedulerDataStoreException;

Tables deletion

public Boolean dropTables(SchedulerConfiguration paramSchedulerConfiguration)
throws SchedulerDataStoreException;

Let’s create an instance of the scheduler configuration helper:

SchedulerConfigHelper schedulerHelper = new 

As you can see SchedulerConfigHelper applies the obligatory argument in the constructor – SchedulerConfigService. By means of it Helper gets access to the WebSphere resources and to the local variables, but this is an object in the given implementation, frankly speaking, it represents a cap and it does not affect the working process with the tables.

Hence, we receive the parameters of our scheduler – information by means of which helper will be able to find the required scheduler.

SchedulerConfiguration schedulerConfig = scheduler.getSchedulerConfiguration();

And then everything is simple:

if (schedulerHelper.createTables(schedulerConfig)) {
        // Таблицы для шедулера созданы!

You should take into the account that if the tables have been already created then the method will only leave the corresponding message in the logs and will complete by returning false. The verifyTables method doesn’t return any values and in case of absense of the required tables it throws SchedulerDataStoreException.

By the way you can surely create tables by using the ddl scripts. That’s what I did before but WebSphere API has mechanisms which allow us to abstract from such subtleties as naming of ddl script, path, creating of connection and so on. This is the approach used with the administrative server console.

The used java-decompiler: Java Decompiler

Thank you for attention!


How to install WebSphere 6.1 on Windows 7

Posted by anton as Websphere

Windows 7 is not officially supported by WebSphere 6.1 and the installation wizard normally breaks. However, you can still install Websphere 6.1 on Windows 7 if you use the silent installer. Follow these steps:

1. Download WAS 6.1 and unpack to C:\WAS_61 (if you unpack it elsewhere, adjust the paths in the rest of this tutorial accordingly)

2. Create a file C:\WAS_61\myoptionsfile.txt with the following contents:

-OPT silentInstallLicenseAcceptance=”true”
-OPT disableOSPrereqChecking=”true”
-OPT installType=”installNew”
-OPT feature=”noFeature”
-OPT installLocation=”C:\IBM\WebSphere 6.1\AppServer”
-OPT PROF_enableAdminSecurity=”true”
-OPT PROF_adminUserName=admin
-OPT PROF_adminPassword=admin

Modify these settings if needed. I would imagine that the installLocation will vary for most people.

3. Go to Start, search your programs and files for cmd, in the search results right-click the cmd and select Run as Administrator. This will bring up the command prompt. It is crucial to run it as administrator.

4. In command prompt, execute this command:

C:\> C:\WAS_61\WAS\install.exe -options “C:\WAS_61\myoptionsfile.txt” -silent

5. Wait until the installation finishes. Since it runs silently, it won’t notify you with a popup window or anything like that. The only two ways to check on the progress are (1) to use the Task Manager and (2) to view the log file at C:\IBM\WebSphere 6.1\AppServer\logs\install\log.txt. If you see that the last line contains the code INSTCONFSUCCESS – the installation has completed successfully.

Note: if the installation wizard fails to even start, its log file with the error message will be stored here: C:\Documents and Settings\<User>\waslogs