... | ... | @@ -48,7 +48,7 @@ In CMB 5 this would be the heart of the system. A workflow would coordinate bet |
|
|
### So What is a Workflow?
|
|
|
A workflow is a sequence if tasks. Some tasks are simple, others composed of sub-tasks (or sub-workflows). A task potentially have a beginning and end. Meaning a set of conditions that must be met before a task can start, and a set of conditions that must be met before a task is considered completed.
|
|
|
|
|
|
### Some Exmaple Tasks
|
|
|
### Some Example Tasks
|
|
|
* View a model - starting condition we need a model, ending condition none
|
|
|
* Construct a Surface Water Model from scratch - starting condition none ending condition a polygonal model
|
|
|
* Export an ADH Surface Water Simulation - starting condition, have a discrete model, mesh, a well defined attribute system end condition - job submitted
|
... | ... | @@ -123,4 +123,17 @@ Lets seem hypothetically how the proposed managers might be used to process part |
|
|
* Once the meshing workflow has been completed and we have a mesh the last task in this workflow becomes available and once done this workflow can now be completed and the original top-level workflow resumed.
|
|
|
|
|
|
## Driving a CMB Application Externally
|
|
|
The above discussion assumes that the entire workflow of the user is being managed entirely by the CMB application. In the case of external workflow system like Sextant, it will be possible to drive the application in a command line mode where the Task or Sub-Workflow is specified as an argument. In this case the Task Manager would process the task normally and return control to the external workflow manager when the task is completed. |
|
|
\ No newline at end of file |
|
|
The above discussion assumes that the entire workflow of the user is being managed entirely by the CMB application. In the case of external workflow system like Sextant, it will be possible to drive the application in a command line mode where the Task or Sub-Workflow is specified as an argument. In this case the Task Manager would process the task normally and return control to the external workflow manager when the task is completed.
|
|
|
|
|
|
## johnt comments 07-Nov-2016
|
|
|
|
|
|
This is a good enumeration of CMB modules for performing workflows. And the extension to external workflow execution is great.
|
|
|
|
|
|
* Is the thinking that each "single task" is specified with declarative syntax? That would still be my recommendation -- using the same general approach as provisioning systems like Ansible.
|
|
|
* The choice of a single flow sequence (with hierarchy) versus a directed graph -- was that a keep-it-simple decision? It will limit the granularity at which workflows can be specified (which might be a good thing). In the AdH simulation, for example, I would typically consider the meshing and simulation-attribute tasks to be independent and not done serially.
|
|
|
* I like the ideal of task hierarchy, however, encapsulation could quickly break down for things like "selector" and "parallel" tasks, when the input requirements are different among the various sub-tasks. So there will be situations were some parts of a selector or parallel task can be performed but not others, so the readiness of the parent task is not a binary yes or no.
|
|
|
* You don't mention whether feedback is supported or not, but I am presuming that a workflow can be started/restarted at any point in the sequence.
|
|
|
* I'll add my usual comment that we should support workflow tasks that are executed by "external" processing, that is, scripts or other non-CMB executables.
|
|
|
* I suspect it will be hard to avoid duplication of workflow specifications from different projects, but that is something we should try to minimize.
|
|
|
|
|
|
|