Workflows, Sessions, Tasks and Scheduling
Workflow Manager turns mappings into executable jobs: workflows contain tasks connected by links, sessions bind a mapping to connections and runtime settings, and the scheduler decides when a workflow runs.
Structure
A workflow starts with a Start task and contains tasks joined by links. Task types worth knowing: Session, Command, Email, Timer, Decision, Assignment, Control (Stop, Fail, Abort), Event Wait, Event Raise, and Worklet (a reusable group of tasks). A session is the executable instance of one mapping version.
Links and conditions
Links can be unconditional, conditional on an expression, or based on the preceding task's status (succeeded, failed). A Decision task has two outgoing links for the true and false outcomes. If a session fails and no FAILED link exists, the workflow fails.
Session properties
Connections for sources and targets, commit interval, error handling (stop on errors after N errors), tracing level, Treat Source Rows As (Data Driven, Insert, Update, Delete, Update as Update), and recovery settings. Sessions also read values from a parameter file using $$name and $Param.
Scheduling
Run options are Run once, Run on demand, Run continuously, and Run every N seconds. The scheduler page adds start date and time, repeat interval, days of the week, and an end date. Workflows can also be started manually or triggered by an event.
Worked example
A nightly load should email support on failure: session, then a conditional link evaluated when status is FAILED, then an Email task, then a Control task that fails the workflow. The success path continues to the next session, so both branches are explicit.
Traps
- Expecting a downstream task to run when its incoming link condition is false.
- Confusing a worklet with a workflow - a worklet cannot be scheduled on its own.
- Changing a session's mapping without re-validating the session.