A job is a WebSphere Commerce command that is scheduled to run on behalf of a site or store at a specified time or interval. There are three types of jobs.

Regular 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 executed, 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 regular jobs include: Auction jobs, SendMarketingTriggers, and SendTransactedMsg.
Store level jobs
Similar to regular jobs, but they contain a task command that checks the business logic to determine if 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 executed, 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; payment jobs such as BalancePayment, and PaymentSummaryGenerate.
Broadcast jobs
Apply all clones to run them immediately, or as soon as the scheduler can arrange. They run once on all clones or WebSphere Commerce 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 execute 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, WebSphere Commerce considers it hung. You can ignore these warnings if some scheduler jobs are running on these threads and are expected to execute for more than 30 minutes. If necessary, configure WebSphere Application Server's hang detection policy to more appropriate values.

When there are 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,, can be used to determine what job was executed on this thread ID, for example, 00000029.

Scheduler jobs

The list of default scheduler jobs are as follows.
  • ActivityCleanUp - The ActivityCleanUp is a scheduler command that is used for cleaning up the activities data that is stored in the CTXMGMT and CTXDATA tables. For more information about ActivityCleanUp, see ActivityCleanUp URL.
  • CleanECEvent - The CleanECEvent job 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. For more information about CleanECEvent, see Scheduling the CleanECEvent job.
  • DynaCacheInvalidation - The DynaCacheInvalidation command is a scheduled command that can be invoked on a URL to invalidate entries in the WebSphere Application Server dynamic cache. For more information about DynaCacheInvalidation, see DynaCacheInvalidation URL.
  • EvaluateRuleBasedCategories - You can create the EvaluateRuleBasedCategories job command to reapply the rules for rule-based sales categories on a configured time interval. For more information about EvaluateRuleBasedCategories, see Creating the rule-based sales category evaluation scheduled job.
  • EventProcessor - The EventProcessor job further 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 simply updated to the -20 state. By default, this scheduled job runs every hour. For more information about EventProcessor, see Scheduling the EventProcessor job.
  • ExperimentCheckExpiry - The ExperimentCheckExpiry job compares the expiration date specified in the experiment to the current system date. For more information about ExperimentCheckExpiry, see Experiments considerations.
  • PaySynchronizePM - The PaySynchronizePM command finds orders that are sent to WebSphere Commerce Payments for processing that are in state 'I' (Inventory Update Pending) or state 'M' (Authorization Pending). Once the Order is authorized, this command changes the Order status to 'C' (Complete) and does not track its status any further. This command is only used with WebSphere Commerce Payments; it is not used if you use the Payments subsystem.
  • RaiseECEvent - The RaiseECEvent is invoked by the WebSphere Commerce scheduler to process pending base ECEvents. For more information about RaiseECEvent, see RaiseECEvent URL.
  • RefreshLocalRegistry - The RefreshLocalRegistry is the broadcast job. It refreshes the local registry.
  • SaveMarketingStatistics - The SaveMarketingStatistics command saves the accumulated statistics to the database. For more information about SaveMarketingStatistics, see Scheduling the SaveMarketingStatistics job.
  • SchedCoupon - The SchedCoupon is invoked by the WebSphere Commerce scheduler to process current coupons to check for expiration. For more information about SchedCoupon, see SchedCoupon URL.
  • ScheduledContentManagedFileEARUpdate - The ScheduledContentManagedFileEARUpdate scheduled job copies the file from the WebSphere Commerce database to the WebSphere Commerce EAR file. For more information about ScheduledContentManagedFileEARUpdate, see Changing managed file WebSphere Commerce EAR updater parameters.
  • SendMarketingTriggers - The SendMarketingTriggers job 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. For more information about SendMarketingTriggers, see Scheduling the SendMarketingTriggers job.
  • SendTransactedMsg - The SendTransactedMsg URL sends all outstanding messages by using the Send Transacted Sending services. For more information about SendTransactedMsg, see SendTransactedMsg URL.
  • TicklerUnlockMonitor - The TicklerUnlockMonitor unlocks ticklers that are locked for more than a specified time. For more information about TicklerUnlockMonitor, see TicklerUnlockMonitor URL.
  • UpdateSearchIndex - The UpdateSearchIndex job command is used for synchronizing Quick Publish catalog changes with the search index in production. For more information about TicklerUnlockMonitor, see ../../