|
2 | 2 |
|
3 | 3 | A module that provides workflow validation at levels beyond the schema. A workflow
|
4 | 4 | definition is a complex structure, and not all of its content can be checked using
|
5 |
| -a JSON/YAML schema alone. This module provides various 'levels' of workflow |
6 |
| -inspection of the workflow in increasing levels of validation: - |
| 5 | +a JSON/YAML schema alone. This module provides a number of validation levels |
| 6 | +with increasing levels of 'inspection'. The levels are called CREATE, RUN, and |
| 7 | +TAG. |
7 | 8 |
|
8 |
| -- CREATE |
9 |
| -- RUN |
10 |
| -- TAG |
| 9 | + CREATE level validation simply checks that the workflow complies with the schema. |
| 10 | + Workflows are permitted in the DM that do not comply with the schema. This is |
| 11 | + becuase the DM is also used as a persistent store for Wwrfklows while editing - this |
| 12 | + allows a user to 'save' a workflow that is incomplete with the intention of |
| 13 | + adjusting it at a later date prior to execution. |
11 | 14 |
|
12 |
| -CREATE level validation simply checks that the workflow complies with the schema. |
13 |
| -Workflows are permitted in the DM that do not comply with the schema. This is becuase |
14 |
| -the DM is also used as a persistent store for Wwrfklows while editing - this |
15 |
| -allows a user to 'save' a workflow that is incomplete with the intention of adjusting |
16 |
| -it at a later date prior to execution. |
| 15 | + TAG level validation takes things a little further. In 'production' mode |
| 16 | + tagging is required prior to exeution. TAG level validatioin ensures that a workflow |
| 17 | + _should_ run if it is run - for examplke variable names are all correctly defined |
| 18 | + and there are no duplicates. |
17 | 19 |
|
18 |
| -TAG level validation takes things a little further. In 'production' mode |
19 |
| -tagging is required prior to exeution. TAG level validatioin ensures that a workflow |
20 |
| -_should_ run if it is run - for examplke variable names are all correctly defined |
21 |
| -and there are no duplicates. |
22 |
| -
|
23 |
| -RUN level extends TAG level validation by ensuring, for example, all the |
24 |
| -workflow variables are defined. |
| 20 | + RUN level extends TAG level validation by ensuring, for example, all the |
| 21 | + workflow variables are defined. |
25 | 22 |
|
26 | 23 | Validation is designed to allow a more relaxed engine implementation, negating the
|
27 | 24 | need for the engine to 'check', for example, that variables exist - the validator
|
28 |
| -ensures they do. |
| 25 | +ensures they do so that the engine can concentrate on laucnhing steps rather than |
| 26 | +implementing swatchs of lines of logic to protect against mal-use. |
| 27 | +
|
| 28 | +It is the Data Manager that is responsible for invoking the validator. It does this |
| 29 | +prior to allowing a user to run a workflow. When the engine receives a 'Workflow Start' |
| 30 | +message it can be sure that the chosen workflow can run. |
29 | 31 |
|
30 | 32 | Module philosophy
|
31 | 33 | -----------------
|
|
0 commit comments