Task
A task is the basic unit of execution. It represents a single call — a database statement or procedure, a shell command, an ETL job, or a cloud service invocation — and is executed synchronously in its own thread.
Every task belongs to exactly one Group, and through the group to exactly one Scenario. Every task has exactly one Connection, through which it is executed.
A task is a definition. When a scenario is planned, each valid task produces a scheduled task — one instance of it within a Processing. The scheduled task carries the status; see Task and processing statuses.
Contents
Attributes
Identification
| Attribute | Description |
|---|---|
| Name | Must be unique within the group. Maximum 100 characters. |
| Description | Free text. |
| Enabled | Whether the task is included when a processing is planned. A disabled task is not planned at all. |
| Group | The group the task belongs to. |
| Connection | The connection used to execute it. |
| Tags | Informative labels; see Tag. |
Execution
| Attribute | Description |
|---|---|
| Query | The statement or command to execute. See The command below. |
| Repeat count | How many further attempts are made after a failure. Default 1. |
| Repeat timeout | Minutes to wait between attempts. Default 10. |
| Not before / Not after | An optional time window within the day during which the task may run. Shown in the Info tab of the Monitor when set. |
Scheduling
| Attribute | Description |
|---|---|
| Schedule type | Daily, Weekly, Monthly, Quarterly or Yearly. Determines whether the task is included in a given processing. Only meaningful for tasks that do not run every day. |
| Weekdays | For weekly scheduling, the days on which the task runs. |
| Valid from / Valid to | The period during which the task is planned. |
| Multiday mode | How the task behaves when several processing dates are active at once. See below. |
| Execution mode | Workflow or Schedule — how the task participates in the flow. |
For Monthly, Quarterly and Yearly scheduling the day within the period is given as a number, with a reversed option that counts from the end of the period instead of the start. That is how "last day of the month" is expressed.
Prioritisation and load
| Attribute | Description |
|---|---|
| Priority | A lower number means the task is selected earlier. Default 20. |
| Inherits priority | Whether the task takes the priority of a dependent task when that priority is higher. Enabled by default. Inheritance works through task dependencies only, never through group dependencies. See Prioritization. |
| Weight | A number expressing how much load the task places on its group and connection. Default 10. See Resource management. |
Dependencies
| Attribute | Description |
|---|---|
| Dependencies | The tasks this one waits for. See Dependencies. |
| Dependency mode | All dependencies — wait for every dependency to be satisfied. First dependency — proceed as soon as the first is satisfied. The default is All dependencies. |
First dependency mode is used where several equivalent tasks are created and it is meaningful to continue as soon as any one of them reports.
A dependency may also be inter-scenario — pointing at a task in a different scenario. Such dependencies are marked with a distinct icon in the task editor. They should be used sparingly, because they couple two planning events that were intended to be independent. See edit-task.
Notification and monitoring
| Attribute | Description |
|---|---|
| Operators | Who is notified when the task fails. Notification is sent only after the last automatic attempt has been exhausted. See Operator. |
| Milestone | Marks the task as a milestone, tracked on the Dashboard. See Analysing processing performance. |
| SLA time | The time by which the task is expected to complete. |
| Warn on max repeat | Report a warning when the retry count is exhausted. |
| Warning return value | A return value treated as a warning rather than an error. Used mainly with shell connections; see shell-script-connection. |
Multiday mode
When several processing dates are active at once, the multiday mode determines whether this task may run for more than one date at a time.
| Mode | Behaviour |
|---|---|
| Group setting | Inherit the setting from the group. This is the default. |
| Parallel | Instances planned for different dates or iterations may run in parallel. Typical for snapshot data that does not depend on the previous day, and for multi-tenant configurations. |
| Serial | The task may start only once all its own instances for earlier processing dates have finished. |
| Consumed | As Serial, and in addition all dependent tasks — the consumers of its output — must have finished for the earlier dates. Used in producer/consumer setups, such as a transformation and historisation relationship. |
| Fully processed | The task may start only once the previous processings of the whole scenario are complete. The most conservative mode. |
Choosing a stricter mode than necessary is the most common reason a catch-up run is slower than expected. See Parallelism and Recovery after an outage.
The command
What belongs in the Query field depends on the connection:
- Database — a valid SQL statement. It may be a procedure call, DML or DDL. If the statement returns a result set, the data is ignored.
- Shell — the command line to execute. See shell-script-connection.
- ODI — the name of the scenario or load plan to invoke. See etl-tool-connection.
- Cloud service — the service-specific invocation. See cloud-services-connection.
Before execution, placeholders in the command are replaced with their current values. The Query tab in the Monitor shows both the definition and the executed query — the text after substitution — which is the reliable way to check what was actually sent.
Task notes
Notes can be recorded against a task definition and are visible from the Monitor, where the button shows how many exist. A note can later be marked as resolved. Notes are the appropriate place for operational context — a known quirk, a workaround, a reference to a ticket — that would otherwise live only in someone's memory.
Editing and locking
A task can be locked for editing, which prevents two people changing the same definition at once. A lock can be released if it has been left behind.
Changes made through the assignment controls — adding or removing a tag, an operator or a dependency — take effect immediately and are not part of the Save action.
