Scheduled jobs are a concept that allow execution of a custom task either at a specific point in the future or as a recurring activity.
The primary goal of the scheduled job service is to manage the lifecycle of these jobs themselves. Jobs can be created and persisted in the service via its REST API or through messaging channels. Based on how each job is configured, the service will emit messages at the appropriate time(s) representing the "triggering" of that job. Interested microservices can then listen for these trigger events and execute custom logic as needed. To be clear, the scheduled job service’s role in the flow ends with the emission of trigger events - it is not responsible for execution of the actual tasks nor responsible for tracking their success/failure.
A notable use-case for scheduled jobs is scheduling of sandbox deployments, as discussed in the Sandbox Services documentation.
ScheduledJob and ScheduledJobDetail DomainScheduledJob is the primary domain the scheduled job service is centered around.
It contains the persisted description and configuration information about a particular job, such as timing type and execution status.
Within each ScheduledJob, there is also a nested collection of ScheduledJobDetail.
These details can be thought of as "arguments" for the task that the ultimate triggered event listener will utilize.
The Quartz library is used to actually schedule and trigger jobs.
The scheduled job service periodically scans through the ScheduledJob datastore and builds a Quartz JobDetail/Trigger for each job based on its configuration, which is then scheduled in the JobStore.
These are then automatically executed by Quartz at the right time, and result in the emission of trigger event messages.
In a microservices environment, you may have several instances (nodes) of the scheduled job service running concurrently. To ensure a trigger event is only emitted once, the scheduled job service is configured by default to operate as a singleton (or "active-passive") cluster. In other words, at any given time, only one instance of the scheduled job service will be responsible for scheduling and emitting trigger events. This is accomplished by leveraging Apache Camel’s clustering with JGroups as the cluster provider.
At the time of this writing, there’s no sandboxable entities in this service. If a sandboxable entity is introduced in this service, the following configurations should be added:
spring:
cloud:
stream:
bindings:
persistenceOutput:
triggeredJobEventInputPurgeSandbox:
group: scheduled-job-purge-sandbox
destination: triggeredJobEvent
broadleaf:
transitionrequest:
enabled: true
changesummary:
notification:
active: true
tracking:
sandbox:
purge:
enabled: trueSee Sandboxing In Detail for more details.
|
Note
|
These configurations typically only affect the
Granular Deployment model. For Min and Balanced deployements, these configurations are likely already added at the flexpackage-level configuration.
|