Manage WebSphere Application Server Scheduler Tables from Java

Theory

WebSphere is a cool application server, with a bunch of goodies, but how IBM diligently hides all this from the masses of curious developers is very surprising. This article covers the process of monitoring tables of the internal task scheduler directly from the code of the java-application.

There is information on the Internet about the deployment of a sheduler and the basics of working with him. But I needed to control the integrity of the tables right from the program. That's where the fun began. I did not find information on this process on the Internet. Although of course there is documentation, but within the framework of solving administrative problems, examples are given in JACL and Jython languages. To transfer the algorithm to Java, this is clearly not enough, since The approaches are slightly different.

WebSphere has an internal task scheduling mechanism. And this is great. For its work, it is required to deploy in the database tables of the scheduler, where it will store its tasks. The structure of these tables is sufficiently covered in the corresponding ddl scripts that come with the WebSphere (AppServer \ Scheduler \ *. Ddl). Moreover, you can not even care about these tablets and store them in the internal server Derby-database, which comes with the application server from version 6.1 in one set. How to control the scheduler tables after all?

I solved this problem using the IBM classes library com.ibm.ws.runtime_6.1.0.jar (AppServer \ plugins \ com.ibm.ws.runtime_6.1.0.jar). I also did not find documentation on these classes, therefore, having armed myself with a decompiler, I began my ruthless analysis.
')

Practice

We assume that the scheduler is deployed and we can refer to it via the JNDI path (for example, java: comp / env / scheduler / ReportScheduler):

     Context initialContext = null;
     Scheduler scheduler = null;

     try {
         initialContext = new InitialContext ();
         scheduler = (Scheduler) initialContext.lookup (SCHEDULER_JNDI_NAME);
     } catch (NamingException e) {
         throw new SchedulerException ("Error initialization:" + e.getMessage (), e);
     } finally {
         if (initialContext! = null) {
             try {
                 initialContext.close ();
             } catch (NamingException e) {
                 logger.log (Level.SEVERE, e.getMessage (), e);
             }
         }
     }

The class that implements the management logic of the Scheduler tables - WASSchedulerCfgHelper , implements the SchedulerConfigHelper interface. The main functions that we need:

Checking the availability of tables:
public void verifyTables(SchedulerConfiguration paramSchedulerConfiguration)
throws SchedulerDataStoreException;

Creating tables:
public Boolean createTables(SchedulerConfiguration paramSchedulerConfiguration)
throws SchedulerDataStoreException;

Deleting tables:
public Boolean dropTables(SchedulerConfiguration paramSchedulerConfiguration)
throws SchedulerDataStoreException;

Create an instance of the Scheduler Configuration Assistant:

SchedulerConfigHelper schedulerHelper = new WASSchedulerCfgHelper(SchedulerConfigServiceImpl.getInstance());

As you can see, SchedulerConfigHelper in the constructor takes a required argument - SchedulerConfigService . With its help, Helper gets access to WebSphere resources and local variables, but in this implementation, this object, roughly speaking, is a stub and does not affect the process of working with tables.

So, we get the parameters of our sheduler - information on which the helper can find the necessary sheduler.

SchedulerConfiguration schedulerConfig = scheduler.getSchedulerConfiguration();

Well, then everything is simple:

     if (schedulerHelper.createTables (schedulerConfig)) {
         // Scheduler tables created!
         doSomething ();
     } 

It should be borne in mind that if the tables have already been created, the method will only leave the corresponding message in the logs and end by returning false. The verifyTables method returns no value, and in the absence of the necessary tables throws a SchedulerDataStoreException .

By the way, of course, you can create tables using ddl scripts. This is exactly what I did before, but in the WebSphere API there are mechanisms that allow us to abstract from such subtleties as the name of the ddl script, paths, creating connections, etc. This is the approach used within the administrative console of the server.

Used java-decompiler: Java Decompiler

Thanks for attention!