Quartz Component

http://camel.apache.org/quartz.html

Quartz Component

The quartz: component provides a scheduled delivery of messages using theQuartz scheduler.
Each endpoint represents a different timer (in Quartz terms, a Trigger and JobDetail).

Maven users will need to add the following dependency to their pom.xml for this component:

<dependency>

    <groupId>org.apache.camel</groupId>

    <artifactId>camel-quartz</artifactId>

    <version>x.x.x</version>

    <!-- use the same version as your Camel core version -->

</dependency>

URI format

quartz://timerName?options

quartz://groupName/timerName?options

quartz://groupName/timerName?cron=expression

quartz://timerName?cron=expression

The component uses either a CronTrigger or a SimpleTrigger. If no cron expression is provided, the component uses a simple trigger. If nogroupName is provided, the quartz component uses the Camel group name.

You can append query options to the URI in the following format, ?option=value&option=value&...

Options

ParameterDefaultDescriptioncronNoneSpecifies a cron expression (not compatible with thetrigger.* or job.* options).trigger.repeatCount0SimpleTrigger: How many times should the timer repeat?trigger.repeatInterval0SimpleTrigger: The amount of time in milliseconds between repeated triggers.job.namenullSets the job name.job.XXXnullSets the job option with the XXX setter name.trigger.XXXnullSets the trigger option with the XXX setter name.statefulfalseUses a Quartz StatefulJob instead of the default job.fireNowfalseNew to Camel 2.2.0, if it is true will fire the trigger when the route is start when using SimpleTrigger.

For example, the following routing rule will fire two timer events to the mock:results endpoint:

from("quartz://myGroup/myTimerName?trigger.repeatInterval=2&trigger.repeatCount=1").routeId("myRoute").to("mock:result");

When using a StatefulJob, the JobDataMap is re-persisted after every execution of the job, thus preserving state for the next execution.

Running in OSGi and having multiple bundles with quartz routes
If you run in OSGi such as Apache ServiceMix, or Apache Karaf, and have multiple bundles with Camel routes that start fromQuartz endpoints, then make sure if you assign
an id to the <camelContext> that this id is unique, as this is required by theQuartzScheduler in the OSGi container. If you do not set any id on <camelContext> then
a unique id is auto assigned, and there is no problem.

Configuring quartz.properties file

By default Quartz will look for a quartz.properties file in the org/quartz directory of the classpath. If you are using WAR deployments this means just drop the quartz.properties inWEB-INF/classes/org/quartz.

However the Camel Quartz component also allows you to configure properties:

ParameterDefaultTypeDescriptionpropertiesnullPropertiesCamel 2.4: You can configure a java.util.Properties instance.propertiesFilenullStringCamel 2.4: File name of the properties to load from the classpath

To do this you can configure this in Spring XML as follows

<beanid="quartz"class="org.apache.camel.component.quartz.QuartzComponent">

    <propertyname="propertiesFile"value="com/mycompany/myquartz.properties"/>

</bean>

Starting the Quartz scheduler

Available as of Camel 2.4

The Quartz component offers an option to let the Quartz scheduler be started delayed, or not auto started at all.

ParameterDefaultTypeDescriptionstartDelayedSeconds0intCamel 2.4: Seconds to wait before starting the quartz scheduler.autoStartSchedulertruebooleanCamel 2.4: Whether or not the scheduler should be auto started.

To do this you can configure this in Spring XML as follows

<beanid="quartz"class="org.apache.camel.component.quartz.QuartzComponent">

    <propertyname="startDelayedSeconds"value="5"/>

</bean>

Clustering

Available as of Camel 2.4

If you use Quartz in clustered mode, e.g. the JobStore is clustered. Then from Camel 2.4 onwards theQuartz component willnot pause/remove triggers when a node is being stopped/shutdown. This allows the trigger to keep running on the other nodes in the cluster.

Note: When running in clustered node no checking is done to ensure unique job name/group for endpoints.

Message Headers

Camel adds the getters from the Quartz Execution Context as header values. The following headers are added:
calendar, fireTime, jobDetail, jobInstance, jobRuntTime, mergedJobDataMap, nextFireTime, previousFireTime,refireCount, result, scheduledFireTime, scheduler,trigger, triggerName, triggerGroup.

The fireTime header contains the java.util.Date of when the exchange was fired.

Using Cron Triggers

Quartz supports Cron-like expressions for specifying timers in a handy format. You can use these expressions in thecron URI parameter; though to preserve valid URI encoding we allow + to be used instead of spaces. Quartz provides alittle tutorial on how to use cron expressions.

For example, the following will fire a message every five minutes starting at 12pm (noon) to 6pm on weekdays:

from("quartz://myGroup/myTimerName?cron=0+0/5+12-18+?+*+MON-FRI").to("activemq:Totally.Rocks");

which is equivalent to using the cron expression

0 0/5 12-18 ? * MON-FRI

The following table shows the URI character encodings we use to preserve valid URI syntax:

URI CharacterCron character+Space

Specifying time zone

Available as of Camel 2.8.1
The Quartz Scheduler allows you to configure time zone per trigger. For example to use a timezone of your country, then you can do as follows:

quartz://groupName/timerName?cron=0+0/5+12-18+?+*+MON-FRI&trigger.timeZone=Europe/Stockholm

The timeZone value is the values accepted by java.util.TimeZone.

In Camel 2.8.0 or older versions you would have to provide your custom String tojava.util.TimeZone Type Converter to be able configure this from the endpoint uri.
From Camel 2.8.1 onwards we have included such a Type Converter in the camel-core.