Scenario

A scenario is a set of related tasks planned together by a common event — for example the availability of source data, or the completion of a system close. It is the unit of Planning: tasks are always planned one scenario at a time.

A scenario should contain all the tasks that are processed in sequence with one another. Typical practice is to make the warehouse load one scenario, intra-day and near-real-time work a separate scenario, and database or server maintenance a third. Tasks that have nothing to do with each other do not belong in the same scenario, because they would then be forced to share a planning event.

Each Group belongs to exactly one scenario, and therefore so does each Task.

Planning modes

The planning type determines what triggers the scenario.

Planning types

Type	Trigger
Standard daily	Simple planning on a daily basis.
File-based	The processing date and iteration are parsed from a file name matching a regular expression in a defined folder.
SQL defined	Advanced planning driven by an SQL statement that returns the dataset currently available.
REST polling	Periodic polling of a REST endpoint for a starting event, such as data availability or file arrival.
Manual	Planning only on request, from the GUI or through the REST API.

The modes themselves, and the fields each one uses, are described in Planning.

Attributes

General

Attribute	Description
Name	Unique name of the scenario.
Description	Free text.
Enabled	Whether the scenario is planned. Disabling stops further instances being planned; instances already planned run to completion.
Connection	The connection used to run the planning query. Required for SQL-based planning; only database-type providers are allowed.

Validity and time window

Attribute	Description
Valid from / Valid to	The period in which the scenario may be planned at all.
Not before	Planning is delayed until this time of day.
Not after	Planning does not start after this time; it waits until midnight.

These are the generic constraints and apply to all planning modes.

Daily planning

Attribute	Description
Schedule base	Determines which date is planned next. Previous run plans the day following the last completed one, leaving no gaps. Calendar/realtime plans the current day, which allows gaps. This setting decides how the scenario behaves after an interruption — see Recovery after an outage.
Workdays only	Planning skips non-working days according to the Calendar.
Lag	A delay in days between the processing date and its execution. A lag of 1 means processing for 2 January starts no earlier than 3 January.
Iteration prefix	Used as the iteration code for daily planning.

Concurrency and load

Attribute	Description
Max parallel	The maximum number of instances of this scenario that may be active at once — in other words, how many processing dates may run concurrently. See Parallelism.
Parallel limit	The maximum number of tasks running simultaneously within the scenario.
Load limit	The maximum combined weight of tasks running within the scenario. See Resource management.

SQL-based planning

Attribute	Description
Query	The SQL statement evaluated to decide whether to plan. Only the first row of the result is used.
Polling frequency	Interval in minutes between evaluations of the query.
Check type	Whether planned dates must follow an order — see below.

The query result is read positionally:

• date — mandatory. A native date type, a YYYY-MM-DD string, or a numeric YYYYMMDD.
• iteration — optional. Distinguishes intra-day or special runs from the standard daily run.
• name — optional. When present, it replaces the default scenario/date/iteration label shown in the GUI.

Check types

Type	Constraint
None	No constraint on date or iteration. Any combination returned is planned unless it is already in progress.
Date	The new processing date cannot be earlier than the latest processing date of the same scenario.
Iteration	As Date, and within the same date the iteration code cannot be lower than the highest iteration code already used for that scenario.

The query may contain placeholders.

File-based planning

Attribute	Description
Base directory	The directory checked for files. Local to the Dafne executor, or mounted into its filesystem.
File name regexp	A regular expression matching the file name. Named groups year, month, day and optionally iteration supply the processing date.

Notification

Operators may be assigned to be notified when the scenario starts and when it finishes. See Operator.

Placeholders available in the planning query

Placeholder	Meaning
%scenarioid%	Scenario ID
%scenarioname%	Scenario name
%maxdate%	Latest finished processing date. Defaults to 1970-01-01 on the first run.
%maxprocessingID%	ID of the last finished processing. Defaults to 0 on the first run.
%maxIteration%	Iteration code of the last finished processing.
%maxIterationAll%	Iteration code of the last started processing.
%maxProcessingName%	Name of the last finished processing.
%maxProcessingStatus%	Status of the last started processing. Defaults to F on the first run.

Note the distinction between %maxIteration%, which refers to the last finished processing, and %maxIterationAll%, which refers to the last started one. Using the wrong one is a common cause of a scenario either re-planning a date or refusing to plan the next.

See Placeholders for the general syntax.

See also

• Planning
• Processing
• Group
• Parallelism