Features

Features

Besides being an attractive and user-friendly GUI, QuartzDesk provides many unique features that we think you should know about when evaluating and considering QuartzDesk. These features are summarized on this page.

 

Support For All Quartz Versions

QuartzDesk transparently supports applications using all popular Quartz scheduler 1.8.x, 2.0.x, 2.1.x and 2.2.x versions thus completely shielding users from all Quartz scheduler cross-version API incompatibilities. This implies that a single QuartzDesk installation can connect to, manage and monitor Quartz scheduler instances of all aforementioned versions. In general, we recommend to our users to always use the latest Quartz 1.8.x and 2.x.x version available on the quartz-scheduler.org website.

This feature is available in all QuartzDesk editions.

 

JMX Protocols

QuartzDesk provides seamless supports for all popular JMX protocols such as the RMI, JMXMP and REMOTING-JMX (JBoss).

This feature is available in all QuartzDesk editions.

 

Management Operations

Schedulers

QuartzDesk can manage multiple local and remote Quartz schedulers. Quartz scheduler connections can be organized using drag-and-drop into folders within the Schedulers tree panel. QuartzDesk provides an easy way to discover, test and register new scheduler connections.

This feature is available in all QuartzDesk editions.


Jobs

QuartzDesk supports all common job management operations such as:

  • Ad-hoc job triggering.
  • Adding new jobs.
  • Editing of existing jobs.
  • Cloning of existing jobs.
  • Removing existing jobs.
  • Viewing the list of currently executing jobs.
  • Real-time viewing of intercepted log messages of a currently executing job. (Only Standard and Enterprise edition and Quartz >= 2.1.0)
  • Interrupting of currently executing jobs. (Only Quartz >= 2.1.1)
  • Resuming and pausing of job groups.

This feature is available in all QuartzDesk editions unless stated otherwise.


Triggers

QuartzDesk supports all common trigger management operations such as:

  • Viewing all registered triggers.
  • Viewing triggers of a selected job.
  • Viewing extended trigger attributes. (Only QuartzDesk Standard and Enterprise editions)
  • Adding new triggers. (Only QuartzDesk Standard and Enterprise editions)
  • Editing of existing triggers. (Only QuartzDesk Standard and Enterprise editions)
  • Cloning of existing triggers. (Only QuartzDesk Standard and Enterprise editions)
  • Removing existing triggers.
  • Pausing and resuming of individual triggers.
  • Pausing and resuming of trigger groups.

This feature is available in all QuartzDesk editions unless noted otherwise.

 

Execution History

QuartzDesk records individual job executions and vetoes. For each job execution, more then 30 runtime parameters are recorded. The collected data can then be easily accessed through the QuartzDesk GUI in the Execution History table. In the Execution History table you can quickly identify all successful, failed and vetoed executions because these are shown with distinct row background colors.

If the executed job produced a result, you can view its textual representation by clicking on the icon in the Result column. If the job execution failed, you can view the execution exception by clicking on the icon in the Exception column.

The Execution History table is available at the job, trigger and scheduler level. Therefore you can easily obtain the execution history for the selected job, or trigger. Execution history on the scheduler level provides access to the complete execution history for the given scheduler across all of its jobs and triggers.

This feature is available only in the QuartzDesk Standard and Enterprise editions.

 

Job Execution Logs

QuartzDesk can intercept log messages produced by executed jobs. The intercepted log messages are recorded and can be viewed by clicking on the icon in the Execution History table's Log column in the QuartzDesk GUI.

Log message interception is currently supported for all popular Java logging frameworks, such as the Java Utility Logging (JUL), Log4j, Log4j 2 and Logback.

This feature is available only in the QuartzDesk Standard and Enterprise editions.

 

Execution Statistics

With the help of 12 Execution Statistics provided by QuartzDesk you can get a complete picture of what is going on inside the managed Quartz schedulers. For example, the Execution Statistics allow you to easily identify the most frequently failing jobs/triggers, the slowest jobs/triggers and more. If you find a problem, you can then use the Execution History to drill-down and find out further details (e.g. job execution exceptions). You can easily set up your SLAs for individual jobs and triggers and then use Execution Statistics to verify whether these SLAs have been met.

Execution Statistics are available at the job, trigger and scheduler level for the following time periods and granularities:

PeriodGranularity
Day Hourly
Week Daily
Month Daily
Quarter Monthly
Year Monthly

 

This feature is available only in the QuartzDesk Enterprise edition.

 

Notification Rules

Notification Rules provide a very effective way of monitoring job executions following the Hollywood principle. Whenever a job gets executed by any of the managed Quartz schedulers, all associated notification rules are evaluated. If the notification rule condition evaluates to true, a configured message is enqueued for delivery through the selected message delivery channel and sent to the specified list of recipients.

QuartzDesk notification rules keep you informed about all non-standard job execution-related issues before they turn into a problem that impacts your business and customers

QuartzDesk supports the following notification rule condition types:

Condition TypeUsage
Execution Status Suitable for simple notifications based on the job execution status (Success, Veto, Error).
Max Duration Suitable for monitoring of job executions exceeding the specified number of milliseconds.
Expression

The most powerful type of all execution conditions that uses an arbitrary JavaScript expression. This condition can be used to implement any notification logic.

Besides standard JavaScript objects you can use more then 70 scripting objects exposed by the QuartzDesk runtime. Please note that the list of available scripting objects includes the textual representation of the job execution log that can be easily parsed and analyzed.

 

The following table presents examples of some of the typical JavaScript expressions that can be used in notification rules.

ExpressionDescription
true
Always notify.
execHistory.jobName == 'MyJob'
Notify of all 'MyJob' job executions.
execHistory.duration > 5000
Notify of all job executions exceeding 5 seconds.
execHistory.execStatus == 'ERROR'
Notify of all job execution failures.
precedingExecHistory != null
&& precedingExecHistory.execStatus != execHistory.execStatus
Notify of a job execution status change.
( preceedingExecHistory == null || precedingExecHistory.execStatus == 'SUCCESS' )
&& execHistory.execStatus == 'ERROR'
Notify of a job execution status change SUCCESS->ERROR (first error notification).
( precedingExecHistory != null && precedingExecHistory.execStatus == 'ERROR' )
&& execHistory.execStatus == 'SUCCESS'
Notify of a job execution status change ERROR->SUCCESS (recovery notification).
execHistory.log != null && execHistory.log.match( /Some Text/ ) != null
Notify of the 'Some Text' text appearing in the intercepted job execution log.
function isSuccess( result ) 
{ 
  log.info( 'Job exec result is: ' + result ); 
  return result == '0'; 
} 

isSuccess( execHistory.result );

Notify of the '0' job execution result set by the executed job.

Please note the use of a JavaScript function. Functions can improve readability and logic reuse when called from cycles, other functions etc.

Please note the use of a log statement. Log statements help debug created JavaScript expressions. Their output is available in the QuartzDesk JVM Agent log.

 

QuartDesk supports the following notification message delivery channels:

  • AIM
  • GTalk
  • Email
  • ICQ
  • SNMPv1, SNMPv2c, SNMPv3
  • Jabber/XMPP
  • Yahoo
  • Web Service

 

For further details on the message delivery channels please refer to the Message Channel Profiles section below.

Each notification rule defines a message that is enqueued and delivered to the defined recipients. When composing a notification message you can make use of more then 50 available message subject and body macros that get automatically expanded before the message is enqueued and delivered. Some notification channels allow for adding message attachments. The following message attachments can be added:

  • Log
  • Result
  • Exception
  • User Data

 

In the QuartzDesk GUI it is possible for individual notification rules to view the history of enqueued notification messages with their delivery status. You can also display the message body and attachments.

Notification rules can be defined at the job, trigger and scheduler level.

This feature is available only in the QuartzDesk Enterprise edition.

 

Message Channel Profiles

The Message Channel Profile is a reusable message delivery channel configuration. It typically defines the sender, target server and authentication properties. For instance, the Email message channel profiles define the sender email address, SMTP server, SMTP port and SMTP authentication credentials. Message channel profiles are currently used by the notification rules described in the preceding section. QuartzDesk currently supports the following message channel profile types:

  • AIM
  • GTalk
  • Email
  • ICQ
  • SNMPv1, SNMPv2c, SNMPv3
  • Jabber/XMPP
  • Yahoo
  • Web Service

 

The Web service message channel profile is a special type of a profile that used to deliver messages to a MessageReceiverService implementation that customers are expected to implement if they wish to consume and possibly process notification messages produced by QuartzDesk. The WSDL of the MessageReceiver web-service for the latest QuartzDesk release can be obtained here.

QuartzDesk provides a trivial test implementation of the MessageReceiverService at the following URL:

http(s)://<host>:<port>/<context>/services/<version>/MessageReceiverService

where:

<host>
The name of the host the QuartzDesk application has been deployed on.
<port>
The HTTP/S port the QuartzDesk application is available at.
<context>
The web-context root of the deployed QuartzDesk application.
<version>
The MessageReceiver web-service version (e.g. v1_0, v2_0,...).

This feature is available only in the QuartzDesk Enterprise edition.

 

Monitoring

QuartzDesk exposes a REST API to monitor individual managed schedulers, jobs and triggers. This API is primarily intended to be integrated into various system / network monitoring solutions, such as Nagios, Cacti, etc. that provide URL monitoring capabilities.

The monitoring REST API is available at the following URLs.

Scheduler Monitoring

http(s)://<host>:<port>/<context>/monitor/quartz/scheduler/<scheduler_id>

Job Monitoring

http(s)://<host>:<port>/<context>/monitor/quartz/job/<scheduler_id>/<job_group_name>/<job_name>

Trigger Monitoring

http(s)://<host>:<port>/<context>/monitor/quartz/trigger/<scheduler_id>/<trigger_group_name>/<trigger_name>

where:

<host>
The name of the host the QuartzDesk application has been deployed on.
<port>
The HTTP/S port the QuartzDesk application is available at.
<context>
The web-context root of the deployed QuartzDesk application.
<scheduler_id>
The managed Quartz scheduler ID.
<job_group_name>
A Quartz job group name.
<job_name>
A Quartz job name.
<trigger_group_name>
A Quartz trigger group name.
<trigger_name>
A Quartz trigger name.

The monitoring URLs are shown in the QuartzDesk GUI from which they can be easily copied. The screenshot gallery below shows where these URLs are available in the application and the results that individual monitoring URLs return.

When using this type of monitoring, please note that its reliability depends entirely on the frequency used to poll data from the REST API. For example, if the polling frequency is lower than the job execution frequency you may easily miss some important job execution status changes. On the other hand, if the polling frequency is too high, it may unnecessarily increase load on the server hosting the QuartzDesk application, as well as on the servers the queried schedulers / jobs / triggers are running on.

For these reasons we recommend using this monitoring API primarily for scheduler monitoring where the expected frequency of state changes is typically very low, or for monitoring of jobs / triggers with low execution frequency (e.g. jobs executed few times a day). For all other use-cases we strongly recommend using the Notification Rules that offer a robust, flexible and reliable job execution monitoring framework.

 

The scheduler, job and trigger monitoring operations are also exposed through the QuartzAnywhere web service described further below in this document.

This feature is available only in the QuartzDesk Standard and Enterprise editions.

 

QuartzAnywhere Web Service

The QuartzAnywhere web service works as a single endpoint interface through which you can perform all common scheduler, job and trigger operations on all managed schedulers. This web service is provided by the QuartzDesk application at the following URL:

http(s)://<host>:<port>/<context>/services/<version>/QuartzService

where:

<host>
The name of the host the QuartzDesk application has been deployed on.
<port>
The HTTP/S port the QuartzDesk application is available at.
<context>
The web-context root of the deployed QuartzDesk application. 
<version>
The QuartzAnywhere web-service version (v1_0, v2_0,...).

The WSDL of the QuartzAnywhere web-service for the latest QuartzDesk release can be obtained here.

This feature is available only in the QuartzDesk Enterprise edition.

 

OEM Customization Framework

The OEM Customization Framework is a simple to use, yet powerful framework provided by the QuartzDesk Web-Application component. It allows our OEM partners to externalize changes they make to the QuartzDesk Web-Application component. The changes typically include modifications to localized resources (i18n*.properties files), icons/logos (*.png files), CSS stylesheets (*.css files) and JavaScript resources (*.js files).

The OEM partner prepares their changes inside the ${quartzdesk.work.dir}/oem directory, where ${quartzdesk.work.dir} refers to the configured QuartzDesk Web-Application work directory. Once the changes have been finalized, the OEM partner moves the contents of the ${quartzdesk.work.dir}/oem directory to the oem directory in the root of the quartzdesk-web-.x.y.z.war file. This modified WAR files is then ready to be distributed the OEM partner's customers.

The OEM Customization Framework completely eliminates QuartzDesk Web-Application redeploys and servlet container / application server restarts during the development phase on the OEM partner's side because all changes are automatically applied upon reloading the QuartzDesk Web-Application browser window. Therefore the framework greatly reduces the development time to implement and test the OEM partner specific changes.

The OEM Customization Framework is enabled by a special type of a license key (OEM license key) that cannot be downloaded on our web-site. OEM license keys are provided upon request only. If you ware interested in QuartzDesk OEM partnership, please contact us at  This email address is being protected from spambots. You need JavaScript enabled to view it. . OEM license conditions are customized for each OEM partner.

This feature is available only in the QuartzDesk Standard and Enterprise edition and it requires an OEM license key.