...
Note that through the properties we can indicate to the workflow which schedule triggered it—we could also pass arbitrary other properties.
Managing Schedules
Schedules Lifecycle
These actions can be performed on a schedule:
Create: This happens either as part of application deployment or through the Lifecycle HTTP RESTful API. After creating a schedule, it is initially disabled and will not execute any jobs.
Disable: Disabling a schedule will delete all pending jobs for the schedule from the job queue, and prevent new jobs from being created. This action will not suspend or abort any current execution of the workflow.
Enable: This action will put the schedule back into an active state, after a Disable action. Note that if the schedule was previously disabled, that aborted all pending jobs for the schedule. Therefore new triggers have to create new jobs for this schedule before its workflow is executed again.
Delete: This first disables the schedule and then permanently deletes it.
Update: This is equivalant to deleting the current schedule and creating a new one. It happens either when an application which contains a schedule is redeployed in CDAP, or through the Lifecycle HTTP RESTful API.
Application Deployment and Schedules
Schedules can be defined as part of application deployment, by calling schedule() in the application's configure() method; or they can be managed separately from application deployment through the HTTP RESTful API. This can create a dilemma: After modifiying schedules through REST, redeploying the application, which may happen for reasons unrelated to the schedules, would undo all those changes and reinstate the schedules defined by the configure() method. Because that is undesired, CDAP provides an option to configure whether schedules are controlled by the configure() method or not. This option is called app.deploy.update.schedules and is given as a field of the application deployment request.
If this option is true, then application deployment will replace all schedules for the application with the schedules given by the
configure()method;if it is false, application deployment will not change any schedules, except that if the application is updated, all schedules for programs that do not exist any longer after the update are deleted.
Special Runtime Arguments
When a schedule with a time trigger executes a workflow it passes in the logicalStartTime runtime argument: this is the timestamp, in milliseconds, at which the schedule's cron expression was fulfilled and triggered the job.