The following data shows the key tables and persisted JSON structures used by the ScheduledJob Service.
ScheduledJob contains all of the necessary information about a job, including how it will be scheduled and its execution status.
TYPE field is intended to help identify and organize jobs with a similar purpose/origin.
This is especially useful for microservices that are listening for triggered scheduled job events, since their message handlers can determine whether or not to handle an event based on its
For example, a data-purging service may submit a scheduled job of type
"CUSTOM_DATA_PURGE", and configure its message handler to listen for triggered job events and only handle them if the payload has a type of
In this way, a service can support handling specific types of events and reject events it does not care about.
TIMING_TYPE field is a discriminator that determines whether a job runs at a specified
TARGET_DATE, or recurs as dictated by a
CRON fields hold the configuration for their respective types.
EXECUTED is a simple flag that reports whether or not a job has been successfully triggered.
LAST_EXECUTED field is a timestamp describing when the job was last triggered.
Despite being stored in a separate table,
ScheduledJobDetail is conceptually a nested collection on
ScheduledJob may have zero or more details.
Functionally, these enable a scheduled job to contain "arguments" for the ultimate consumer/handler of the triggered event. The scheduled job service itself does not make use of them - they are simply passed along.
For example, a data-purging job may need to specify criteria that data must match to be purged.
It could add details where each
name was a field on the data, and each
value was the value the field needed to match.
The triggered event handler would receive this information and use it to build the right query.
In all cases, the structure/content of these details should always match whatever structure the ultimate handler will expect.
ScheduledJob Services uses the following Common Data Features which create additional tables within the ScheduledJob Services data schema.
Durable Messaging - Employs
DefaultNotificationHandler for sending triggered job messages
with durable retry.
BLC_NOTIFICATION_STATE table for message send acknowledgement.
Resource Locking - Employs
ResourceLockRepository for message consumption idempotency checking.