8.8.x

Scheduling Jobs Using Quartz Scheduler

Self-Managed Commerce uses the Quartz Scheduler to execute scheduled jobs. Quartz is an open source job scheduling service embedded within Spring. It can also be used as a standalone service with any Java application. Scheduled jobs are configured in Spring via the quartz.xml configuration files. There is one Quartz configuration for the Search Server web application and another for the Commerce Manager web application.

In Quartz, Jobs can be any Java class that implements the Quartz Job interface. To execute a job, you must set Triggers that detail when the job is to occur. When a trigger activates, the scheduler will trigger corresponding listeners that will execute the job. As Jobs are completed, they return a JobCompletionCode which informs the scheduler of success or failure. The JobCompletionCode also instructs the scheduler of any further action to perform depending on the job’s results.

Quartz has built in JMX support. By using JMX, you can monitor and control your Quartz jobs.

Adding a new scheduled job

To add a scheduled job to either the Batch Server or the Search Server, do the following:

  1. Open the appropriate quartz.xml file:

    • The Batch Server quartz.xml file is located at commerce-engine/batch/ep-batch/src/main/resources/spring/scheduling/quartz.xml
    • The Search Server quartz.xml file is located at commerce-engine/search/ep-search/src/main/resources/spring/scheduling/quartz.xml

  2. In quartz.xml, define a job bean as shown below:

    <bean id="newJob" class="com.elasticpath.batch.hds.HDSMethodInvokingJobDetailFactoryBean">
    <property name="targetObject" ref="newJobService"/>
    <property name="targetMethod" value="executeMethod"/>
    <property name="concurrent" value="false"/>
    <property name="jobPauseService" ref="jobPauseService"/>
    <property name="jobName" value="newJob"/>
</bean>

  3. Replace the following values:

    • newJob - the name of the bean. Use the same value for the jobName property.
    • newJobService - the class that contains the logic for the scheduled job.
    • executeMethod - the name of the method to execute in the class.
    note

    The example above is for the Batch Server, where every job bean sets jobPauseService and jobName so that the job can participate in job pausing. On the Search Server, use org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean and omit those two properties.

  4. In quartz.xml, define a trigger bean as shown below:

    <bean id="newJobTrigger" class="org.springframework.scheduling.quartz.CronTriggerFactoryBean">
    <property name="jobDetail" ref="newJob"/>
    <property name="cronExpression" value="${ep.batch.job.newJob.cronExpression:0 0 0/1 * * ?}"/>
    <property name="timeZone" value="#{systemProperties['quartz.timezone']}"/>
</bean>

  5. Replace the following properties:

    • newJob - the name of the job bean.
    • cronExpression - the cron expression that sets how often the job should be executed. For more information on cron expressions, see Quartz Cron Configuration.

    Writing the value as ${property.key:default} lets operators change the schedule from ep.properties without editing quartz.xml. Built-in Batch Server jobs use the key format ep.batch.job.<jobName>.cronExpression. For more information, see Overriding Cron Expressions.

    To run the job at a fixed interval instead of on a cron schedule, use org.springframework.scheduling.quartz.SimpleTriggerFactoryBean with startDelay and repeatInterval properties, both in milliseconds.

  6. Open the appropriate quartz-setup.xml file:

    • The Batch Server quartz-setup.xml file is located at commerce-engine/batch/ep-batch/src/main/filtered-resources/spring/scheduling/quartz-setup.xml
    • The Search Server quartz-setup.xml file is located at commerce-engine/search/ep-search/src/main/filtered-resources/spring/scheduling/quartz-setup.xml

  7. Add the new trigger to the appropriate list of triggers. A trigger does not run until it is referenced from one of these lists. For the Batch Server, add it to schedulingTriggers:

    <util:list id="schedulingTriggers">
    <ref bean="cleanupOrderLocksTrigger"/>
    <ref bean="cleanupAbandonedCartsTrigger"/>
    <ref bean="cleanupFailedOrdersTrigger"/>
    <!-- remaining triggers omitted -->

    <!-- add the reference to the new trigger here -->
    <ref bean="newJobTrigger"/>
</util:list>

    The Search Server has several lists instead of one. Add an index build trigger to indexBuildTriggers, and any other trigger to searchTriggers.

  8. For a Batch Server job, decide whether the job can be paused during peak transactional events. In commerce-engine/batch/ep-batch/src/main/resources/spring/service/serviceBatch.xml, declare the job name and add it to one of the two lists:

    <bean id="jobName.newJob" class="java.lang.String">
    <constructor-arg value="newJob"/>
</bean>
    • Add the reference to nonCriticalPausableJobNames to let the job be paused.
    • Add it to criticalJobNames, or leave it out of both lists, to make sure the job always runs.

    A job is paused only when its name appears in nonCriticalPausableJobNames and does not appear in criticalJobNames, and only while pausing is active. Pausing is controlled by the COMMERCE/SYSTEM/JOBS/PAUSENONCRITICAL/enabled, startsAt, and expiresAt system settings.

Configuring Quartz

Quartz File Structure

Scheduled jobs are split across two files per web application:

  • quartz.xml defines the job beans and the trigger beans.

    Each job has one job bean definition and one trigger bean definition.

  • quartz-setup.xml defines the schedulerFactory bean and the lists of triggers that it executes.

    A trigger only runs if it appears in one of these lists, so a new job is not scheduled until its trigger is added here.

The job beans (xxxJob) specify the class and method that will be called for each job, as well as any arguments that need to be passed. The Batch Server uses com.elasticpath.batch.hds.HDSMethodInvokingJobDetailFactoryBean, which extends Spring's MethodInvokingJobDetailFactoryBean to add high-availability data source support and job pausing. The Search Server uses MethodInvokingJobDetailFactoryBean directly.

The trigger beans (xxxTrigger) configure when each job runs. A trigger is one of the following:

  • org.springframework.scheduling.quartz.SimpleTriggerFactoryBean

    Runs a job repeatedly at a fixed interval, configured with a startDelay and a repeatInterval in milliseconds. All Search Server triggers are of this type.

  • org.springframework.scheduling.quartz.CronTriggerFactoryBean

    Runs a job every time the current time matches its cronExpression. Most Batch Server triggers are of this type. For more information, see Quartz Cron Configuration.

The schedulerFactory bean differs between the two web applications:

  • The Batch Server uses org.springframework.scheduling.quartz.SchedulerFactoryBean and takes its trigger list from the allBatchTriggers alias.
  • The Search Server uses com.elasticpath.search.impl.SearchIndexSchedulerImpl, a subclass of SchedulerFactoryBean that selects a trigger list based on whether the node is a primary or a replica. For more information, see Search Server Clustering.
note

For more information about Quartz see the Quartz website.

Quartz Cron Configuration

The time/trigger to execute the scheduled job can be set with the cronExpression property. The cron expression contains six required components and one optional component. A cron expression is written on a single line and each component is separated from the next by space. Only the last, or rightmost, component is optional. The table below describes the cron components in detail.

Components of a Cron Expression:

PositionMeaningAllowed Special Characters
1Seconds (0-59), - * /
2Minutes (0-59), - * /
3Hours (0-23), - * /
4Day of month (1-31), - * / ? L W
5Month (either JAN-DEC or 1-12), - * /
6Day of week (either SUN-SAT or 1-7, where 1 is Sunday), - * / ? L #
7Year (optional), when empty, full range is assumed, - * /

Quartz does not compute fire times more than 100 years into the future, so a year component beyond that horizon parses successfully but never fires.

Each component accepts the typical range of values that you would expect, such as 0-59 for seconds and minutes and 1-31 for day of the month. For the month and day of the week components, you can use numbers, such as 1-7 for day of the week, or text such as SUN-SAT.

The following expression is used as the example throughout this section. It fires at 30 seconds past every minute, every day:

30 0/1 * * * ?
important

Quartz does not support specifying both a day of month and a day of week in the same expression. One of the two components must be ?. An expression such as 0 0 12 1 * MON is rejected with Support for specifying both a day-of-week AND a day-of-month parameter is not implemented.

Each field also accepts a given set of special symbols, so placing a * in the hours component means every hour, and using an expression such as 6L in the day of week component means last Friday of the month. The list below describes cron wildcards and special symbols in detail.

  • *

    Any value. This special character can be used in any field to indicate that the value should not be checked. In the example expression, * in the hours, day of month, and month components means the trigger fires during any hour, on any day of the month, in any month.

  • ?

    No specific value. This character is allowed only in the day of month and day of week components, and marks whichever of the two is not driving the schedule. In the example expression, ? in the day of week component means the schedule is driven by the day of month component instead.

  • -

    Range. For example 10-12 in the Hours field means hours 10, 11, and 12.

  • ,

    List separator. Allows you to specify a list of values, such as MON, TUE, WED in the Day of week field.

  • /

    Increments. This character specifies increments of a value. For example 0/1 in the Minute field in the example expression means every 1-minute increment of the minute field, starting from 0.

  • L

    L is an abbreviation for Last.

    The meaning is a bit different in Day of month and Day of week. When used in the Day of month field, it means the last day of the month (31st of March, 28th or 29th of February, and so on). L-3 means the third-to-last day of the month, and LW means the last weekday of the month.

    When used in Day of week, it has the same value as 7 (Saturday). The L special character is most useful when you use it with a specific Day of week value. For example, 6L in the Day of week field means the last Friday of each month.

  • W

    Nearest weekday. This character is allowed only in the Day of month field and fires on the weekday nearest to the given day, without crossing into another month. For example, 15W fires on the 15th when the 15th is a weekday.

  • #

    Nth day of week. This character is allowed only in the Day of week field, and is written as <day of week>#<nth>, where <nth> is a value between 1 and 5. Because day of week is numbered with 1 as Sunday, 2#1 means the first Monday of each month and 1#2 means the second Sunday of each month.

note

Some Quartz documentation and third-party guides describe a C (calendar) special character for the Day of month and Day of week fields. Quartz does not implement it. A C in either field is silently ignored, so 20C behaves exactly like 20 and 6C behaves exactly like 6. Do not use it.

Overriding Cron Expressions

Most Batch Server cron triggers read their expression from a property with a built-in default, so you can change a job's schedule without modifying quartz.xml. For example, the order locks cleanup trigger is defined as:

<bean id="cleanupOrderLocksTrigger" class="org.springframework.scheduling.quartz.CronTriggerFactoryBean">
    <property name="jobDetail" ref="cleanupOrderLocksJob"/>
    <property name="cronExpression" value="${ep.batch.job.cleanupOrderLocks.cronExpression:0 0 * * * ?}"/>
    <property name="timeZone" value="#{systemProperties['quartz.timezone']}"/>
</bean>

The value after the colon is the default that applies when the property is not set. To run the job at 3:00am instead of hourly, add the following to ep.properties:

ep.batch.job.cleanupOrderLocks.cronExpression=0 0 3 * * ?

Properties are read at startup, so restart the Batch Server after changing them. The Cron Property entry for each job in Batch Server Quartz Jobs gives the property name and its default. For the ep.properties file locations, the property placeholder syntax, and the full property list, see Spring Configuration.

Some Batch Server jobs are scheduled differently:

  • orderHoldNotificationJob takes its cron expression from the COMMERCE/SYSTEM/ONHOLD/holdNotificationInterval system setting rather than from a property. For more information, see Configuring System Settings.
  • importJobCleanupProcessorJob, staleImportJobProcessorJob, inventoryJournalRollupJob, and searchTermsAggregatorJob use SimpleTriggerFactoryBean instead of a cron trigger, so they are configured with a start delay and a repeat interval in milliseconds.

Search Server jobs are also interval-based rather than cron-based. They read their start delay and repeat interval from properties such as ep.index.build.delay and ep.index.build.interval. For more information, see Search Server Properties.

Elastic Path Quartz Jobs

Self-Managed Commerce provides a number of Quartz jobs out of the box for both the Batch Server and the Search Server. They are configurable from a number of different locations. For more information on configuring Quartz jobs, see the following:

Batch Server Quartz Jobs

important

All batch jobs are configured in the commerce-engine/ep-batch module, in the quartz.xml file.

abandonedCartEventsJob

Triggers the abandoned shopping cart events.

  • Default Recurrence: Daily at midnight.

  • Cron Property: ep.batch.job.abandonedCartEvents.cronExpression. Default: 0 0 0 * * ? (run every day at midnight).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ABANDONEDCARTEVENTS/maxHistory controls how many days since the shopping cart was last updated before it will be cleared. Defaults to 60.
    • COMMERCE/SYSTEM/ABANDONEDCARTEVENTS/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupAbandonedCartsJob

Purges abandoned shopping carts. Removes TSHOPPINGCART and dependent records.

  • Default Recurrence: Once an hour, at the 30 minute mark.

  • Cron Property: ep.batch.job.cleanupAbandonedCarts.cronExpression. Default: 0 30 * * * ? (run every hour at 30 minutes past the hour).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ABANDONEDCARTCLEANUP/maxHistory controls how many days since the shopping cart was last updated before it will be cleared. Defaults to 60.
    • COMMERCE/SYSTEM/ABANDONEDCARTCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupAnonymousCustomerJob

Purges anonymous customers. Removes TCUSTOMER and dependent records that are anonymous and have no associated orders.

  • Default Recurrence: Once an hour, at the 5 minute mark.

  • Cron Property: ep.batch.job.cleanupAnonymousCustomers.cronExpression. Default: 0 5 * * * ? (run every hour at 5 minutes past the hour).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ANONYMOUSCUSTOMERCLEANUP/maxHistory controls how many days since the customer was last updated before it will be cleared. Defaults to 60.
    • COMMERCE/SYSTEM/ANONYMOUSCUSTOMERCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupExpiredOAuth2TokensJob

Purges expired OAuth tokens. Removes TOAUTHACCESSTOKEN records that have expired.

  • Default Recurrence: Daily at midnight

  • Cron Property: ep.batch.job.cleanupExpiredOAuth2Tokens.cronExpression. Default: 0 0 0 * * ? (run every day at midnight).

  • Configuration Locations: COMMERCE/SYSTEM/EXPIREDOAUTHTOKENCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupFailedOrdersJob

Purges failed orders. Removes TORDER and dependent records with status of FAILED.

  • Default Recurrence: Once an hour, at the 45 minute mark

  • Cron Property: ep.batch.job.cleanupFailedOrders.cronExpression. Default: 0 45 * * * ? (run every hour at 45 minutes past the hour).

  • Configuration Locations:

    • COMMERCE/SYSTEM/FAILEDORDERCLEANUP/maxHistory controls how many days since the order was created before it will be cleared. Defaults to 60.
    • COMMERCE/SYSTEM/FAILEDORDERCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupInactiveCartsJob

Cleans up inactive carts. Removes TSHOPPINGCART and dependent records in INACTIVE state, when the cart has been purchased.

  • Default Recurrence: Once an hour, at the 15 minute mark.

  • Cron Property: ep.batch.job.cleanupInactiveCarts.cronExpression. Default: 0 15 * * * ? (run every hour at 15 minutes past the hour).

  • Configuration Locations:

    • COMMERCE/SYSTEM/INACTIVECARTSCLEANUPJOB/minAge controls the minimum number of minutes since the shopping cart was last updated before it will be cleared. Defaults to 60.
    • COMMERCE/SYSTEM/ABANDONEDCARTCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupInactiveCartItemsJob

Purges removed cart items. Removes soft-deleted TCARTITEM records, that is, line items with the removed flag set.

  • Default Recurrence: Once an hour, at the 20 minute mark.

  • Cron Property: ep.batch.job.cleanupInactiveCartItems.cronExpression. Default: 0 20 * * * ? (run every hour at 20 minutes past the hour).

  • Configuration Locations:

    • COMMERCE/SYSTEM/INACTIVECARTSCLEANUPJOB/minAge controls the minimum number of minutes since the cart item was last updated before it will be cleared. Defaults to 60.
    • COMMERCE/SYSTEM/ABANDONEDCARTCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupOrderLocksJob

Cleans up order locks. This job removes TORDERLOCK records created by Commerce Manager when an order is edited.

  • Default Recurrence: Once an hour, at the start of the hour (i.e. 1:00pm)

  • Cron Property: ep.batch.job.cleanupOrderLocks.cronExpression. Default: 0 0 * * * ? (run every hour).

cleanupOrphanedOrderPaymentGuidsJob

Searches for order payment records on orders older than a configured age, and sets the payment instrument GUID reference to null (UPDATE TORDERPAYMENT SET PAYMENT_INSTRUMENT_GUID = null WHERE UIDPK IN <list>). This reference is only used for showing the "display name" (usually last 4 digits of the card number) when viewing order history in Commerce Manager.

  • Default Recurrence: Daily at midnight (if enabled).

  • Cron Property: ep.batch.job.cleanupOrphanedOrderPaymentGuids.cronExpression. Default: 0 0 0 * * ? (run every day at midnight).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ORDERPAYMENTCLEANUP/enable controls whether this job is enabled. Defaults to false.
    • COMMERCE/SYSTEM/ORDERPAYMENTCLEANUP/maxHistory controls how many days old an order should be before its order payment references to payment instruments should be cleared. Defaults to 365.
    • COMMERCE/SYSTEM/ORDERPAYMENTCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupOrphanedOrderPaymentInstrumentsJob

Deletes order payment instrument records on orders older than a configured age (DELETE TORDERPAYMENTINSTRUMENT WHERE UIDPK IN <list>). These records are only needed for operations that require doing a payment reservation using the existing payment method, such as order modification.

  • Default Recurrence: Daily at midnight (if enabled).

  • Cron Property: ep.batch.job.cleanupOrphanedOrderPaymentInstruments.cronExpression. Default: 0 0 0 * * ? (run every day at midnight).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ORDERPAYMENTCLEANUP/enable controls whether this job is enabled. Defaults to false.
    • COMMERCE/SYSTEM/ORDERPAYMENTCLEANUP/maxHistory controls how many days old an order should be before its order payment references to payment instruments should be cleared. Defaults to 365.
    • COMMERCE/SYSTEM/ORDERPAYMENTCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupOrphanedPaymentInstrumentsJob

Deletes payment instrument records that are orphaned (have no incoming references from TORDERPAYMENTINSTRUMENT, TORDERPAYMENT, TCARTORDERPAYMENTINSTRUMENT, and TCUSTOMERPAYMENTINSTRUMENT).

  • Default Recurrence: Daily at midnight.

  • Cron Property: ep.batch.job.cleanupOrphanedPaymentInstruments.cronExpression. Default: 0 0 0 * * ? (run every day at midnight).

  • Configuration Locations:

    • COMMERCE/SYSTEM/PAYMENTINSTRUMENTCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution.

cleanupChangesetsJob

Deletes changesets that are in the FINALIZED state and published more than a configured number of days ago.

  • Default Recurrence: Daily at midnight (if enabled).

  • Cron Property: ep.batch.job.cleanupChangesets.cronExpression. Default: 0 0 0 * * ? (run every day at midnight).

  • Configuration Locations:

    • COMMERCE/SYSTEM/CHANGESETCLEANUP/enable controls whether this job is enabled. Defaults to false.
    • COMMERCE/SYSTEM/CHANGESETCLEANUP/maxHistory controls the minimum number of days to consider a changeset since it was published. Defaults to 60.
    • COMMERCE/SYSTEM/CHANGESETCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

cleanupCompletedOrdersJob

Removes completed orders that were last modified more than a configured number of days ago.

  • Default Recurrence: Every hour, at 30 minutes past the hour (if enabled).

  • Cron Property: ep.batch.job.cleanupCompletedOrders.cronExpression. Default: 0 30 * * * ? (run every hour at 30 minutes past the hour).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ORDERCLEANUP/enable controls whether this job is enabled. Defaults to false.
    • COMMERCE/SYSTEM/ORDERCLEANUP/maxHistory controls the minimum number of days to consider an order since it last updated. Defaults to 730 days (2 years).
    • COMMERCE/SYSTEM/ORDERCLEANUP/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

dataPointRevokedConsentsJob

Removes data point values for which consent is revoked.

  • Default Recurrence: Once an hour, at the start of the hour.

  • Cron Property: ep.batch.job.dataPointRevokedConsentsJobProcessor.cronExpression. Default: 0 0 * * * ? (run every hour).

encryptCustomerPasswordsJob

Ensures that all registered customer records are upgraded from SHA256 password hashing to BCRYPT password hashing. Looks at the TCUSTOMERAUTHENTICATION.ENCRYPTION_TYPE field to determine the current encryption mechanism, and if it's set to SHA-256, then the existing hash is re-hashed using BCRYPT.

  • Default Recurrence: Daily at 2:00am (if enabled).

  • Cron Property: ep.batch.job.encryptCustomerPasswords.cronExpression. Default: 0 0 2 * * ? (run every day at 2 am).

  • Configuration Locations:

    • COMMERCE/SYSTEM/ENCRYPTCUSTOMERPASSWORDS/enabled controls whether this job is enabled. Defaults to true.
    • COMMERCE/SYSTEM/ENCRYPTCUSTOMERPASSWORDS/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

expiredDataPointValuesJob

Removes data point values for which the retention period is expired.

  • Default Recurrence: Daily at 1:00am.

  • Cron Property: ep.batch.job.expiredDataPointValuesJobProcessor.cronExpression. Default: 0 0 1 * * ? (run every day at 1 am).

importJobCleanupProcessorJob

Removes completed import jobs from the database based on their age. This job removes the TIMPORTNOTIFICATION records in the PROCESSED or QUEUED_FOR_VALIDATION state.

  • Default timeout: 5 minutes.

  • Default Recurrence: Every 72 hours, with a 30 second delay at startup.

  • Configuration Locations:

    • COMMERCE/SYSTEM/IMPORT/importJobMaxAge controls maximum age (in seconds) a completed import job will remain in the database before it is deleted. Defaults to 172800 seconds (48 hours).
    • COMMERCE/SYSTEM/IMPORT/staleImportJobTimeout controls period of time (in minutes) before an import job is considered stale. Defaults to 5 minutes.

inventoryJournalRollupJob

Rolls up inventory journal. Sums allocated quantity delta and quantity on hand delta in TINVENTORYJOURNAL table for the given InventoryKey, then deletes records TINVENTORYJOURNAL.

  • Default Recurrence: Daily with a 30 second delay at startup.

orderHoldNotificationJob

Checks for outstanding held orders and publishes hold notification events.

  • Default Recurrence: Every 4 hours.

  • Configuration Locations: COMMERCE/SYSTEM/ONHOLD/holdNotificationInterval sets the interval as a Quartz cron expression. Defaults to 0 0 /4 * * ?. This job does not read its schedule from ep.properties.

processImportJob

Processes import jobs.

  • Default Recurrence: Every 5 seconds, with a 10 second delay at startup.

  • Configuration Locations: commerce-manager-client/com.elasticpath.cmclient.core module: import-jobs.xml file

relayOutboxMessagesJob

Relays outbox records to JMS. Retrieves events from the TOUTBOXMESSAGE table, sends them to JMS, and removes them from the table.

  • Default Recurrence: Every second, with a 30 second delay at startup.

  • Cron Property: ep.batch.job.relayOutboxMessages.cronExpression. Default: * * * * * ? (run every second).

  • Configuration Locations:

    • COMMERCE/SYSTEM/OUTBOXRELAY/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 100.

releaseShipmentsJob

Moves physical shipments from the INVENTORY_ASSIGNED state to the RELEASED state once the warehouse pick delay has passed. This allows customer service representatives to modify the physical shipment for a short period of time before the shipment is sent to fulfillment. Once all shipments are released, the order will change to the IN_PROGRESS state.

  • Default Recurrence: Every minute.

  • Cron Property: ep.batch.job.releaseShipment.cronExpression. Default: 0 * * * * ? (run every minute).

  • Configuration Locations:

    • COMMERCE/SYSTEM/RELEASESHIPMENTSJOB/batchSize controls the maximum number of records that should be processed in each job execution. Defaults to 1000.

searchTermsAggregatorJob

Aggregates search term activity into the TSEARCHTERMSACTIVITYSUMMARY table.

  • Default Recurrence: Every 30 seconds, with a 30 second delay at startup.

  • Configuration Locations:

    • commerce-engine module: pom.xml file. searchTermsAggregatorJob properties are generally set during the build process, not runtime.

staleImportJobProcessorJob

Processing stale import jobs. This job removes the TIMPORTNOTIFICATION records in the IN_PROCESS state.

  • Default Recurrence: Every minute, with a 30 second delay at startup.

Search Server Quartz Jobs

catalogPromoMonitorJob

Checks for changes to catalog promotion rules and notifies the search server if any are found.

  • Default Recurrence: Every second, with a 15 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.promo.monitor.delay and ep.index.build.interval properties in the ep.properties file

categoryIndexBuildJob

Rebuilds the category index.

  • Default Recurrence: Every second, with a 10 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.index.build.delay and ep.index.build.interval properties in the ep.properties file

cmUserIndexBuildJob

Rebuilds the Commerce Manager user index.

  • Default Recurrence: Every second, with a 10 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.index.build.delay and ep.index.build.interval properties in the ep.properties file

optimizeSearchIndicesJob

Optimizes the search indices.

  • Default Recurrence: Every 5 minutes, with a 2 minute delay at startup. This job's trigger is hard-coded in quartz.xml and is not property-driven.

  • Configuration Locations: commerce-engine/ep-search module: quartz.xml file. For more information on optimizing search indices, see Search Index Optimization Job

productIndexBuildJob

Rebuilds the product index.

  • Default Recurrence: Every second, with a 10 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.index.build.delay and ep.index.build.interval properties in the ep.properties file

promotionIndexBuildJob

Rebuilds the promotion index.

  • Default Recurrence: Every second, with a 10 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.index.build.delay and ep.index.build.interval properties in the ep.properties file

rulebaseCompileJob

Recompiles the rule base, and stores it in the database.

  • Default Recurrence: Every 10 seconds, with a 10 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.rule.compilation.delay and ep.rule.compilation.interval properties in the ep.properties file

skuIndexBuildJob

Rebuilds the SKU index.

  • Default Recurrence: Every second, with a 10 second delay at startup.

  • Configuration Locations:

    • commerce-engine/ep-search module: quartz.xml file
    • ep.index.build.delay and ep.index.build.interval properties in the ep.properties file

Batch Job Implementation

Each future batch job must extend the AbstractBatchJob class to implement the correct workflow and achieve optimal performance. Future batch jobs need to implement only a few methods in the AbstractBatchJob contract.

Batch Java Persistence Query Language (JPQL) queries will be stored in separate Object Relational Mapping (ORM) files (per job) in the ep-batch module.

The AbstractBatchProcessor class is a transactional unit responsible for processing one batch of records. This class implements the logic for the optimal processing of a single batch and provides the abstract methods to be implemented by extensions.

The extension classes must implement the executeBulkOperations method. The preProcessBatch method is optional and is only required if a batch needs to be pre-processed. For example, some entries are filtered out or additionally modified:

    if (shipment.getCreatedDate().before(warehousePickDelayTimestamp)) {
                shipment.getOrder().setModifiedBy(eventOriginatorHelper.getSystemOriginator());
            }
  • Only shipments that meet certain datetime criteria are processed in executeBulkOperations.
Last updated on 9/4/2026
← LoggingShopping Carts →