ScheduleTask table

The ScheduleTask table links tasks to schedules and defines an N:N relationship between rows in the Schedule and SendEmailTask tables. When a task in the Schedule table comes due, one or more tasks can be performed. A single task can be initiated by multiple Schedules. Task scripts can use this table to easily check if there are pending tasks.

After the scheduled script finishes with the task, it checks whether another task exists and processes it. When no further tasks are ready for processing, the script exits.

The RecurrenceInterval is the time between tasks (in minutes) and does not support complicated schedules (such as “Send 10,000 emails every 2 hours from 10am to 6pm on weekdays”). These types of schedules need to be broken up into multiple rows in the task table.

A task stays in the database until the associated project is deleted. TheScheduleTask table does not contain audit information. Information regarding who submitted or updated a task (and the task details) is logged in the standardLogs directory.

A foreign key to an Id column in a task table that represents the task to perform. The specific task table is determined by the TaskTable field.

A foreign key to the Id column in the Schedule table. This determines when the task needs to be executed.

The current scheduled task status (for example, active, processing, completed, stopped).

The number of times the task is executed. The value is initialized to 0 when the task is created.

The last time the task accessed the table. The task periodically updates this time stamp to prove it is still alive and working on the task. When the task does not update the task for a sufficiently large interval, it is be assumed that the task process has terminated abnormally. The field is set to NULL when the task is not currently running.

A free-form field that can be used to store any information associated with the task. The field is not read or processed.

The Email object model implements the following rules:

▪A scheduled task is available for processing between the StartTime and the EndTime. After the EndTime condition is reached, the task is marked as Complete. An EndTime is not required. When an EndTime is not specified, the task continues until the project is deleted.

▪The method that retrieves the next scheduled task from the table prohibits multiple callers from retrieving the same task.

▪After the method retrieves the task, it sets NextDueTime = NextDueTime + RecurrenceInterval, thus ensuring that NextDueTime is set when the task is updated by the user interface (or if the task gets stuck).

▪A task can check for validity. For example, a scheduled send email task verifies that the project is in the specified state.

▪After a task verifies that there is work to do, it creates the initial SendEmailHistory record, that includes setting ScheduledBatchStartTime to the original NextDueTime.

▪When the task completes, it must update the ScheduledTaskStatus and compare NextDueTime against the EndTime (if it exists). Set ScheduledTaskStatus to <Complete> when NextDueTime is past the EndTime. Otherwise, set ScheduledTaskStatus to <Waiting>.

NextDueTime can be in the past if the task took longer than the RecurrenceInterval to process (allows the next batch to be processed immediately).

▪The task regularly updates the SendEmailHistory record to provide user interface status and to track instances when the task ends unexpectedly. The task also updates the LastKeepAliveTime in the ScheduledTasks table.

▪When tasks are retrieved, the object model looks for and handles Active records with an older LastKeepAliveTime.