Installation

Steps:

1. Add case-engine-scheduler-quartz The scheduler will be automatically available if the

   Include Page
   _ProfileCaseEngine _ProfileCaseEngine

   profile is added to the list of spring active profiles in the bootstrap.properties.  The case-engine profile should also be enabled. More information on how to configure the application using Spring Profiles can be found here: External application configuration with Spring Profiles.
2. Add the application-case-engine-scheduler-quartz.properties file in the configuration location if it does not yet exist. This properties file is added in the 

   Include Page
   _ConfigLocation _ConfigLocation

   directory when using the installer. Otherwise, please create this according to the documentation belowBlueriq installer.
3. Run the provided scripts for creating the quartz tables in the database: msssql.sql, pgsql.sql or oracle.sql. The scripts are located in the release zip in \Runtime\Java\Webapp\DBScripts\blueriq-case-engine-scheduler-quartz
4. Define quartz database connection in the application-externaldatasources.properties

   Include Page
   _PropertiesExternalDatasources _PropertiesExternalDatasources

   file.

Configuration

In order to tune resources for job execution we provided a few details about the Thread Pool.

Quartz is configured using a set of properties. Quartz uses a job store in order to persist jobs details, triggers and other job related information. We support two types of job stores:

• Memory (default) ^{for demo's and standalone development}
• Case Engine Scheduler [Editor]Database ^recommended 

Memory (default)

By default memory mode is enabled which should not be used unless for demo's should be used only for demos and standalone development. For recommended settings please check the database settingsthe Database section. For memory the following setting should appear in the application-case-engine-scheduler-quartz.propertiesbe set in the 

spring.quartz.job-store-type = memory

Database

Scripts to create the required database content are provided for the following databases:

• SQL Server
• Oracle

There are two types of connection that are supported:

• Case Engine Scheduler [Editor]
• Case Engine Scheduler [Editor]

Generate the Quartz Database

JDBC Connection

To enable the JDBC Connection the externaldatasources profile must enabled and the following properties have to be usedFor database mode, which is required for production, specify the following in

spring.quartz.job-store-type=jdbc
spring.quartz.properties.org.quartz.jobStore.tablePrefix=QRTZ_

blueriq.datasource.scheduler-quartz.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
blueriq.dataSource.scheduler-quartz.url=jdbc:sqlserver://<server_url>:<port>;databaseName=<database_name>;instance=<instance_name>
blueriq.datasource.scheduler-quartz.username=<user>
blueriq.datasource.scheduler-quartz.password=<password>

blueriq.datasource.scheduler-quartz.driverClassName=oracle.jdbc.driver.OracleDriver
blueriq.dataSource.scheduler-quartz.url=jdbc:oracle:thin:@<server_url>:<port>:xe
blueriq.datasource.scheduler-quartz.username=<user>
blueriq.datasource.scheduler-quartz.password=<password>

# Enable the delegate for the specific database
#spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.MSSQLDelegate
#spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
#spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.oracle.OracleDelegate

# when using a JDBC datasource enable tx
#spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX

# when using a JNDI datasource enable CMT
#spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT

JDBCJobStore’s “table prefix” property is a string equal to the prefix given to Quartz’s tables that were created in your database. You can have multiple sets of Quartz’s tables within the same database if they use different table prefixes.

JNDI Connection

To enable JNDI Connection jndidatasources profile must be activated and the following properties have to be used:

spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT
spring.quartz.properties.org.quartz.jobStore.tablePrefix=QRTZ_

// JBoss Example provided that the jndi name is set to java:jboss/jdbc/quartzdb
blueriq.datasource.scheduler-quartz.jndiName=java:jboss/jdbc/quartzdb

// Tomcat Example provided that the jndi name is set to jdbc/quartzdb
blueriq.datasource.scheduler-quartz.jndiName=java:/comp/env/jdbc/quartzdb

JobStoreCMT relies upon transactions being managed by the application which is using Quartz. 

Thread Pool

If the Database configuration is chosen we recommend to also add the thread pool with the following default values:

The quartz documentation suggests the following configuration: provided that the database allows X connections, then the threadCount must be set to X - 3.

Thread Pool

When the database is configured, we recommend to also configure the thread pool. Each DCM project gets its Each DCM project gets it's own trigger. It is recommended to have a thread per DCM project. For example if you have 3 DCM projects you should set the threadCount to 3.

Please check that the threadCount does not exceed the number of available database connections (or connections in the database connection pool).  The quartz documentation suggests the following: provided that the database allows X connections, then the threadCount must be set to X - 3.

Below are the default thread Pool propertiesThread Pool properties are the following:

spring.quartz.properties.org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
spring.quartz.properties.org.quartz.threadPool.threadCount=2

Cluster

In order to run the Quartz Scheduler on multiple Runtime instances in a cluster, every Runtime instance has to be identical and have the same projects installed.
Each instance in the cluster needs to have the same  application-scheduler-quartz.properties files. You may set different thread pool size on each node.

To read more about quartz clustered environment visit Quartz in Cluster.

Clustering

There are many configuration properties for clustering, see the Quartz documentation. To enable clustering, specify at least these properties:

spring.quartz.properties.org.quartz.jobStore.isClustered=true

Cluster properties example

spring.quartz.properties.org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
spring.quartz.properties.org.quartz.threadPool.threadCount=2

spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
spring.quartz.properties.org.quartz.jobStorescheduler.tablePrefixinstanceName=QRTZ_

spring.quartz.properties.org.quartz.jobStore.isClustered = true
spring.quartz.properties.org.quartz.jobStore.clusterCheckinInterval = 90000
spring.quartz.properties.org.quartz.scheduler.instanceName = MyClusteredScheduler
spring.quartz.properties.org.quartz.scheduler.instanceId = AUTO
spring.quartz.properties.org.quartz.scheduler.skipUpdateCheck = true

Scheduler Maintenance Properties

Used to enable updates on tasks and jobs when model changes.

For more information about this property visit Handle Model Changes.

Examples

Default configuration file:

blueriq.scheduler-quartz.enable-task-migration=false
blueriq.scheduler-quartz.retryInterval=30

Retry Interval

If the case is locked when a timer job or expiring job is fired a new quartz job will be scheduled. The reschedule interval for this job can be configured in minutes, with a property in application-scheduler-quartz.properties file. The default value is 30 minutes.

blueriq.scheduler-quartz.retryInterval=30

Setup Quartz

Various spring configurations

Using spring cloud config

Actions

1. Place your scheduler properties in application-scheduler-quartz.properties (Check here for example) in the searchLocations you specified for spring cloud.
2. Place application-externaldatasources.properties or application-jndidasarouces.properties files in the searchLocations you specified for spring cloud.

Not using spring config additional location

Default quartz properties will be used because application-scheduler-quartz.properties file is not present. The default setup is in-memory configuration.

Scheduler properties can be personalized via JVM arguments:

-Dblueriq.scheduler-quartz.enable-task-migration=false
-Dblueriq.scheduler-quartz.retryInterval=30

If no property is defined, the default ones will be used.

Using spring config additional location

1. In spring.config.additional-location folder place the application-scheduler-quartz.properties (Check here for example) file.
2. In spring.config.additional-location folder place the application-externaldatasources.properties or application-jndidasarouces.properties files

Using existing scheduled tasks

In order for the already scheduled tasks to be executed in time, you need to do a migration to the scheduler.

Before running the migration you need to create the following files and place them in your spring.config.additional-location folder:

MyClusteredScheduler
# Have Quartz generate an instanceId for each node in the cluster
spring.quartz.properties.org.quartz.scheduler.instanceId=AUTO

Anchor
Troubleshooting Troubleshooting

Troubleshooting

Setup quartz in cluster

Overview

Basic Scheduler

The quartz evaluation of time dependent tasks (timer nodes, tasks with priority algorithms, expiration tasks, automatic recovery tasks) is done per Process Engine per Project installed on the Runtime. A quartz job is created for every single project which uses a process engine in the cluster. The number of jobs in Quartz equals with the number of initialized projects from the cluster which are using a process engine. The number of jobs in quartz does not depend on the number of runtime instances available in the cluster.

An interval is defined in the application.properties file which marks the triggering and execution of the job. If the interval is MINUTE, the quartz job will be triggered and executed every minute. The execution consists in finding and evaluating all the timer tasks, expiration tasks, tasks with priority which should fire in that period.
The Runtime instances are selected for execution almost randomly, more busy servers have a lower chance to be selected for the execution.The main advantage for this is that:  As multiple runtime instances are available in cluster, the execution of the jobs might be done in parallel.

The quartz job is created in the cluster when the project which uses a process engine is initialized. This means whenever a project is published and the process engine is initialized in a Runtime, that Runtime will try to start the job for the project if the job is not already created.

The execution of quartz jobs is being done on any Runtime in the cluster as soon as the Runtime is started. This might happen even though in that Runtime no projects are published yet. 

Advanced Scheduler

-Dcom.atomikos.icatch.log_base_dir=C:/tmlogs/tmlog-development/