In many applications the need arises to perform a certain action at a given time without any user interaction, usually to perform some administrative tasks. These tasks need to be scheduled, say to perform a job in the early hours of the morning before the start of business. This functionality is provided by using job scheduling software. Quartz.NET is an excellent open source job scheduler that can be used for these purposes. It provides a wealth of features, such as persistent jobs and clustering. To find out more about Quartz.NET visit their web site. Spring integration allows you to use Spring to configure Quartz jobs, triggers, and schedulers and also provides integration with Spring's transaction management features.

The full details of Quartz are outside the scope of this quickstart but here is 'quick tour for the impatient' of the main classes and interfaces used in Quartz so you can get your sea legs. A Quartz IJob interface represents the task you would like to execute. You either directly implement Quartz's IJob interface or a convenience base class. The Quartz Trigger controls when a job is executed, for example in the wee hours of the morning every weekday . This would be done using Quartz's CronTrigger implementation. Instances of your job are created every time the trigger fires. As such, in order to pass information between different job instances you stash data away in a hashtable that gets passed to the each Job instance upon its creation. Quartz's JobDetail class combines the IJob and this hashtable of data. Instead of the standard System.Collections.Hashtable the class JobDataMap is used. Triggers are registered with a Quartz IScheduler implementation that manages the overall execution of the triggers and jobs. The StdSchedulerFactory implementation is generally used.

The sample application has two types of Jobs. One that inherits from Spring's convenience base class QuartzJobObject and another which does not inherit from any base class. The latter class is adapted by Spring to be a Job. Two triggers, one for each of the jobs, are created. These triggers are in turn registered with a scheduler. In each case the job implementation will write information to the console when it is executed.

The Spring base class QuartzJobObject implements IJob and allows for your object's properties to be set via values that are stored inside Quartz's JobDataMap that is passed along each time your job is instantiated due a trigger firing. This class is shown below

    public class ExampleJob : QuartzJobObject
    {

        private string userName;

        public string UserName
        {
            set { userName = value; }
        }

        protected override void ExecuteInternal(JobExecutionContext context)
        {
            Console.WriteLine("{0}: ExecuteInternal called, user name: {1}, next fire time {2}", 
                DateTime.Now, userName, context.NextFireTimeUtc.Value.ToLocalTime());
        }

    }

The method ExecuteInternal is called when the trigger fires and is where you would put your business logic. The JobExecutionContext passed in lets you access various pieces of information about the current job execution, such as the JobDataMap or information on when the next time the trigger will fire. The ExampleJob is configured by creating a JobDetail object as shown below in the following XML snippet taken from spring-objects.xml

  <object name="exampleJob" type="Spring.Scheduling.Quartz.JobDetailObject, Spring.Scheduling.Quartz">
    <property name="JobType" value="Spring.Scheduling.Quartz.Example.ExampleJob, Spring.Scheduling.Quartz.Example" />
    <!-- We can inject values through JobDataMap -->
    <property name="JobDataAsMap">
      <dictionary>
        <entry key="UserName" value="Alexandre" />
      </dictionary>
    </property>
  </object>

The dictionary property of the JobDetailObject, JobDataAsMap, is used to set the values of the ExampleJob's properties. This will result in the ExampleJob being instantiated with it's UserName property value set to 'Alexandre' the first time the trigger fires.

We then will schedule this job to be executed on 20 second increments of every minute as shown below using Spring's CronTriggerObject which creates a Quartz CronTrigger.

  <object id="cronTrigger" type="Spring.Scheduling.Quartz.CronTriggerObject, Spring.Scheduling.Quartz">
    <property name="jobDetail" ref="exampleJob" />
    <!-- run every 20 second of minute -->
    <property name="cronExpressionString" value="0/20 * * * * ?" />
  </object>

Lastly, we schedule this trigger with the scheduler as shown below

  <object type="Spring.Scheduling.Quartz.SchedulerFactoryObject, Spring.Scheduling.Quartz">
    <property name="triggers">
      <list>
        <ref object="cronTrigger" />
      </list>
    </property>
  </object>

Running this configuration will produce the following output

8/8/2008 1:29:40 PM: ExecuteInternal called, user name: Alexandre, next fire time 8/8/2008 1:30:00 PM
8/8/2008 1:30:00 PM: ExecuteInternal called, user name: Alexandre, next fire time 8/8/2008 1:30:20 PM
8/8/2008 1:30:20 PM: ExecuteInternal called, user name: Alexandre, next fire time 8/8/2008 1:30:40 PM

It is very convenient to schedule the execution of method as a job. The AdminService class in the example demonstrates this functionality and is listed below.

    public class AdminService
    {
        private string userName;

        public string UserName
        {
            set { userName = value; }
        }

        public void DoAdminWork()
        {
            Console.WriteLine("{0}: DoAdminWork called, user name: {1}", DateTime.Now, userName);
        }
    }

Note that it does not inherit from any base class. To instruct Spring to create a JobDetail object for this method we use Spring's factory object class MethodInvokingJobDetailFactoryObject as shown below

  <object id="adminService" type="Spring.Scheduling.Quartz.Example.AdminService, Spring.Scheduling.Quartz.Example">
    <!-- we inject straight to target object -->
    <property name="UserName" value="admin-service" />
  </object>
  
  <object id="jobDetail" type="Spring.Scheduling.Quartz.MethodInvokingJobDetailFactoryObject, Spring.Scheduling.Quartz">
    <!-- We don't actually need to implement IJob as we can use delegation -->
    <property name="TargetObject" ref="adminService" />
    <property name="TargetMethod" value="DoAdminWork" />
  </object>

Note that AdminService object is configured using Spring as you would do normally, without consideration for Quartz. The trigger associated with the jobDetail object is listed below. Also note that when using MethodInvokingJobDetailFactoryObject you can't use database persistence for Jobs. See the class documentation for additional details.

  <object id="simpleTrigger" type="Spring.Scheduling.Quartz.SimpleTriggerObject, Spring.Scheduling.Quartz">
    <!-- see the example of method invoking job above -->
    <property name="jobDetail" ref="jobDetail" />
    <!-- 5 seconds -->
    <property name="startDelay" value="5s" />
    <!-- repeat every 5 seconds -->
    <property name="repeatInterval" value="5s" />
  </object>

This creates an instances of Quartz's SimpleTrigger class (as compared to its CronTrigger class used in the previous section). StartDelay and RepeatInterval properties are TimeSpan objects than can be set using the convenient strings such as 10s, 1h, etc, as supported by Spring's custom TypeConverter for TimeSpans.

This trigger can then be added to the scheduler's list of registered triggers as shown below.

  <object type="Spring.Scheduling.Quartz.SchedulerFactoryObject, Spring.Scheduling.Quartz">
    <property name="triggers">
      <list>
        <ref object="cronTrigger" />
        <ref object="simpleTrigger" />
      </list>
    </property>
  </object>

The interleaved output of both these jobs being triggered is shown below.

8/8/2008 1:40:18 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:20 PM: ExecuteInternal called, user name: Alexandre, next fire time 8/8/2008 1:40:40 PM
8/8/2008 1:40:23 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:28 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:33 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:38 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:40 PM: ExecuteInternal called, user name: Alexandre, next fire time 8/8/2008 1:41:00 PM
8/8/2008 1:40:43 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:48 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:53 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:40:58 PM: DoAdminWork called, user name: Gabriel
8/8/2008 1:41:00 PM: ExecuteInternal called, user name: Alexandre, next fire time 8/8/2008 1:41:20 PM
8/8/2008 1:41:03 PM: DoAdminWork called, user name: Gabriel