Document Properties
Kbid285E05
Last Modified22-Jun-2020
Added to KB13-Nov-2017
Public AccessEveryone
StatusOnline
Doc TypeGuidelines, Concepts & Cookbooks
Product
  • IOM 2.2
  • IOM 2.9
  • IOM 2.15
  • IOM 2.16
  • IOM 2.17
  • IOM 3.0

Guide - IOM Job Scheduling

1 Introduction

This guide gives an overview about the job scheduling in IOM. It shows concepts, components of the IOM job scheduling and possibilities to add custom jobs.

This guide is mainly intended to be read by developers. It also gives architectural insights into IOM.

1.1 Glossary

WordingDescription
IOM

The abbreviation for Intershop Order Management.

JDBCJava Database Connectivity
OMSThe abbreviation for Order Management System, the technical name of IOM.

1.2 References

2 Types of Jobs

The IOM uses the following two types of jobs:

  • Local jobs
  • Cluster jobs

2.1 Local jobs

Local jobs are jobs that do local tasks (e.g., clear the Java cache). These jobs have to be run on every application server (frontend/ backend).

The IOM runs on an JEE 7 compliant application server, so it is possible to use the EJB Timer to invoke methods periodical. There is no registration or configuration needed.

2.1.1 Jobs

Job ClassJob Description
bakery.logic.bean.caching.CheckCacheStatusJobChecks and processes a requested cache clear

2.1.2 Customization

Example: The method execute() will be invoked every 10 seconds.

@Singleton
public class TimerService {
    @EJB
    CustomizedService customService;
  
    @Schedule(second="*/10", minute="*",hour="*", persistent=false)
    public void execute(){
        customService.doWork();
    }
}

 

2.2 Clustered Jobs

Clustered jobs are jobs that do cluster-wide/system-wide tasks (e.g., jobs of the control artifact).
It must be ensured that such jobs do not run in parallel.
This is guaranteed as all IOM cluster jobs belong to the backend server that can only have one live instance.


2.2.1 Configuration

The default configuration uses a local RAM store to manage the jobs.
An alternate configuration using a JDBC store is commented out and should not be required as long as all cluster jobs are located on the single backend instance.

Time-Sync for clustered Jobs

Quartz clustered features would require that the involved hosts have to use some form of time-sync service (daemon) that runs very regularly (the clocks must be within a second of each other).

Configuration of clustered job store
#============================================================================
# Configure JobStore  
#============================================================================

org.quartz.jobStore.misfireThreshold = 60000

#RAM JobStore
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

# JDBC store: example to use the database for the quartz JobStore
# org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
# org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
# org.quartz.jobStore.useProperties = true
# org.quartz.jobStore.dataSource = PostgresDS
# org.quartz.jobStore.tablePrefix = system.qrtz223_
# org.quartz.jobStore.isClustered = true
# org.quartz.jobStore.clusterCheckinInterval = 20000

# Configure Datasources  
# org.quartz.dataSource.PostgresDS.jndiURL=java:/OmsDB

For further details please see Configuration Reference - Configure Clustering with JDBC-JobStore and the configuration of the job store in OMS_ETC/quartz-cluster.properties.

2.2.2 Jobs

All clustered jobs with their descriptions can be found in OMS_ETC/quartz-jobs-cluster.xml.

2.2.3 Customization

The existing configuration in OMS_ETC/quartz-cluster.properties can be used to add further jobs/triggers to the existing scheduler by adding further files to the org.quartz.plugin.jobInitializer.fileNames list of the XMLSchedulingDataProcessorPlugin (Cookbook - Initializing Job Data With Scheduler Initialization).

Note

Within the property-file, the variable ${is.oms.dir.etc} can be used to reference further configuration files. The value of ${is.oms.dir.etc} is replaced by a SchedulerBean at startup with the value of system-property is.oms.dir.etc.

Configuration of job / trigger loading
#============================================================================
# Configure Job / Trigger Loading
#============================================================================

...
# ${is.oms.dir.etc} could be used in the path in order to dynamically reference the folder, where installation specific properties are located
org.quartz.plugin.jobInitializer.fileNames = ${is.oms.dir.etc}/quartz-jobs-cluster.xml,${is.oms.dir.etc}/my-custom-clustered-quartz-jobs.xml
...
...

Another possibility is to customize the existing job file OMS_ETC/quartz-jobs-cluster.xml.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets