Processing
A processing is one planned run of a Scenario for a specific processing date, and optionally a specific iteration within that date. Where a scenario describes what should run, a processing is a concrete instance of it actually running.
A scenario processed daily produces a new processing each day, whose date is the effective processing date — usually the previous calendar day.
Which tasks are included is decided when the processing is planned. It takes into account the Enabled flag on both the Group and the Task, and the task's schedule type — daily, weekly, and so on. Tasks created or enabled afterwards are not part of a processing that has already been planned; they can be added to it explicitly, see Controlling a processing.
Contents
Attributes
| Attribute | Description |
|---|---|
| ID | Internal identifier, assigned when the processing is planned. |
| Scenario | The scenario it was planned from. |
| Date | The processing date — the date the run relates to, not the date it executes. Available to tasks as a placeholder. |
| Iteration | Optional code distinguishing several runs within one date. |
| Name | Optional label shown in the GUI instead of the default scenario/date/iteration. |
| Status | See Task and processing statuses. |
| Invoked by | The user who started it, or System when planned automatically. |
| Started / Finished | Timestamps of the run. |
The Show processing details action in the Monitor displays these along with the parameter values resolved for the processing.
Iteration
The iteration code distinguishes multiple runs of the same scenario on the same date. It is used where part of the processing must run repeatedly — for example loading a section of the warehouse every hour — or to separate a corrective run from the regular one.
It is not intended as a mechanism for looping within a processing.
The attribute is optional. When it is not filled in, it is ignored.
Iteration codes are compared as text
This matters more than it appears. Comparison of iteration codes is purely a string comparison, so the codes must be written such that their alphabetical order matches their intended order:
- numeric iterations must be padded: use 09 and 10, not 9 and 10
- dates or times used as iteration codes must be written most-significant-part first: 20170301 and 20170102, not 1.3.2017 and 2.1.2017
Getting this wrong causes the ordering checks described below to behave unexpectedly — typically a scenario that refuses to plan a run because a previous code sorts higher than it should.
Identity and ordering
Two processings are identical when they have the same processing date and the same iteration code, where one is used.
One processing is before another when:
- its processing date is earlier, or
- the dates are equal and its iteration code is lower by string comparison
Before a processing is started, Dafne checks that it has not already run, and — depending on the scenario's check type — that no later processing has already been started. The comparison is hierarchical: the date first, then the iteration code where present. See Scenario for the check types.
In the Monitor, processings are ordered with active ones first, then by descending date, then by iteration.
Lifecycle
A processing moves through the states listed in Task and processing statuses. In outline:
- it is Waiting until the scenario triggers
- it becomes Running once tasks start
- it can be Paused and resumed by an operator, independently of other processings
- it becomes Finished when all its tasks have reached a terminal state
- a finished processing can be reopened, which returns it to the active set for corrections
Reopening is described in Controlling a processing. It keeps the work attached to the original date and iteration, which is the difference between reopening and creating a new run through reprocessing.
