- v1.0.0-latest-prod
The following data shows the key tables and persisted JSON structures used by the ScheduledJob Service.
A ScheduledJob contains all of the necessary information about a job, including how it will be scheduled and its execution status.
The 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 TYPE.
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 "CUSTOM_DATA_PURGE".
In this way, a service can support handling specific types of events and reject events it does not care about.
The TIMING_TYPE field is a discriminator that determines whether a job runs at a specified TARGET_DATE, or recurs as dictated by a CRON expression.
The TARGET_DATE and CRON fields hold the configuration for their respective types.
Despite being stored in a separate table, ScheduledJobDetail is conceptually a nested collection on ScheduledJob.
A 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.
Leverages BLC_NOTIFICATION_STATE table for message send acknowledgement.
Resource Locking - Employs ResourceLockRepository for message consumption idempotency checking.
Leverages BLC_RESOURCE_LOCK table.