Workflows as Automation

Models have actions, and actions have workflows. These workflows are fired when an action takes place. An additional type of workflow can be fired at specific times or days of the week. These are time-based workflows.

Time-based workflows are very similar to engines except much lighter weight. Essentially they are just a grid task (no parent grid job) that has a special property in that it knows how to reschedule itself.

The DVC Schedule Entry table stores the information about the time-based workflow and how to schedule/reschedule the task in the grid task table.

There will always be one entry in the grid task table with a start date (i.e. not run until that date is reached) in the future. This is the next scheduled time to run.

Being a workflow, there is a class associated with (defined in dvc sched entry) to run when the listener picks up the task at the start time.

That one class then executes the work needed to be done by the workflow.

This is neither horizontal nor vertically scalable. It is one thread on one server.

The dvce schedule entry will have a name like OrderForecast~OMS.OrderForecastAlertWorkflow (Model ~ Module Prefix that defined workflow . Name of workflow).

The grid task will be of type DTBScheduler (that's the listener – all workflows are handled by this one listener) and the params will contain the name of the workflow.

select * from grid_tasks where task_type like 'DTBScheduler' and params like
'%OrderForecast~OMS.OrderForecastAlertWorkflow%';