Scheduler
A job is HCL Commerce command that is scheduled to run on behalf of a site or
store at a specified time or interval. The three types of jobs are: site level jobs, store
level jobs, and broadcast jobs.
Note: Scheduler has new capability to list all the jobs that are
scheduled.
- You can search a job by entering Command.
- Jobs can also be filtered by enabling Show filter. It
provides various filters listed below to search a job:
- Store filter
- Application type
- State filter
- Status filter
- Start date
- End date
- Site level jobs
- Commands that are designed to run automatically at a specified start time. They do not check a business logic task command before they run. Only Site Administrators can schedule this type of job. When a regular job is scheduled, a new entry in the SCHACTIVE table is created with a state of I. When the job is run, a new entry in the SCHSTATUS table is created. The new entry contains the state and status information about the execution of the scheduled job. Examples of site level jobs include: SendMarketingTriggers, and SendTransactedMsg.
- Store level jobs
- Similar to regular jobs, but they contain a task command that checks the business logic to determine whether the job needs to be run. This filtering process allows the scheduler to run only necessary jobs, minimizing its workload. When a store level job is scheduled, a new entry in the SCHACTIVE table is created with a state of W. Store level jobs are associated with a particular store and can be scheduled by Site Administrators. When the job is run, a new entry in the SCHSTATUS table is created. The new entry contains the state and status information about the execution of the scheduled job. Examples of store level jobs include: order jobs such as ProcessBackorders, and OrderClose.
- Broadcast jobs
- Apply all clones to run them immediately, or as soon as the scheduler can arrange. They run one time on all clones or Transaction servers that are connected to the same database. A broadcast job start time is always the current time. They expire after a time period specified in the configuration file. The default expiry time period is 30 minutes. Broadcast job status is logged in the SCHBRDCST database table and displayed in the Scheduler Status Display page. Examples of broadcast jobs include: RefreshLocalRegistry, and SaveMarketingStatistics.
Each job runs as a separate thread, and multiple jobs can be scheduled to run simultaneously. A fixed number of threads are assigned to each application group. To avoid overloading the default application pool, the Schedule Job window allows for application partitioning. The application type is entered into the SCHCONFIG table with the number of threads that are assigned to run the job.
The Schedule Job window can also be used to specify the start time for a job. Job tracking information, including start time, end time, and status is maintained in the SCHSTATUS table and displayed on the Scheduler Status Display page.
Note: A warning is printed to the SystemOut.log if a thread runs long. For
example,
ThreadMonitor W WSVR0605W: Thread "WorkManager.default : 12" (00000029) has been active for 764118 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung.If a thread is active for more than 30 minutes, HCL Commerce considers it hung. You can ignore these warnings if some scheduler jobs are running on these threads and are expected to run for more than 30 minutes. If necessary, configure WebSphere Application Server's hang detection policy to more appropriate values.
When
jobs that are not expected to run for more than 30 minutes, but the warning statement still appears
in the SystemOut.log file, further investigation might be required. Typically,
the trace specification, com.ibm.websphere.commerce.WC_SERVER=all, can be used to
determine what job was run on this thread ID, for example, 00000029.
The following table shows the jobs that are scheduled to run on the scheduler by default.
| Job | Description | For more information |
|---|---|---|
| ActivityCleanUp | Cleans up the activities data that is stored in the CTXMGMT and CTXDATA tables. | ActivityCleanUp URL |
| CleanECEvent | Deletes up to the specified maximum number of business events from the BUSEVENT database table. These business events are either in purge state or older than the specified expiration time (by default, 30 minutes). Database records for the business events are deleted and committed in batches of 5000. The default maximum number of business events is 500, 000. By default, this scheduled job runs every 30 minutes. | Scheduling the CleanECEvent job |
| DynaCacheInvalidation | Invalidates entries in the WebSphere Application Server dynamic cache. | DynaCacheInvalidation URL |
| EvaluateRuleBasedCategories | Reapplies the rules for rule-based sales categories on a configured time interval. | Creating the rule-based sales category evaluation scheduled job |
| EventProcessor | Processes events in the -10 state. Analytics events are sent to an external analytics system and then updated to the -20 state and non-analytics events are updated to the -20 state. By default, this scheduled job runs every hour. | Scheduling the EventProcessor job |
| RaiseECEvent | Processes pending base ECEvents. For more information, see | RaiseECEvent URL |
| RefreshLocalRegistry | Refreshes the local registry. | |
| SaveMarketingStatistics | Saves accumulated statistics to the database. | Scheduling the SaveMarketingStatistics job |
| SchedCoupon | Processes current coupons to check for expiration. | SchedCoupon URL |
| SendMarketingTriggers | Schedules the sending of marketing email activities. This job also processes triggers in dialog activities and generates top-browsed and best-seller lists in web activities. | Scheduling the SendMarketingTriggers job |
| SendTransactedMsg | Sends all outstanding messages by using the Send Transacted Sending services. | SendTransactedMsg URL |
| TicklerUnlockMonitor | Unlocks ticklers that are locked for more than a specified time. | TicklerUnlockMonitor URL |
| UpdateSearchIndex | Synchronizes quick publish catalog changes with the search index in production. | Creating and scheduling the UpdateSearchIndex job |