Workflow
Note
Workflow Scope within CDS Framework
The workflow is within the scope of the micro provisioning and configuration management in controller domain and does NOT account for the MACRO service orchestration workflow which is covered by the SO Project.
A workflow defines an overall action to be taken on the service, hence is an entry-point for the run-time execution of the CBA Package.
A workflow also defines inputs and outputs that will defined the payload contract of the request and response (see Dynamic Payload)
A workflow can be composed of one or multiple sub-actions to execute.
A CBA package can have as many workflows as needed.
Single action
The workflow is directly backed by a component (see Node type -> Component).
In the example bellow, the target of the workflow’s steps resource-assignment is resource-assignment
which actually is the name of the node_template defined after, of type component-resource-resolution.
"topology_template": {
"workflows": {
"resource-assignment": {
"steps": {
"resource-assignment": {
"description": "Resource Assign Workflow",
"target": "resource-assignment"
}
}
},
"inputs": {
"resource-assignment-properties": {
"description": "Dynamic PropertyDefinition for workflow(resource-assignment).",
"required": true,
"type": "dt-resource-assignment-properties"
}
},
"outputs": {
"meshed-template": {
"type": "json",
"value": {
"get_attribute": [
"resource-assignment",
"assignment-params"
]
}
}
}
},
"node_templates": {
"resource-assignment": {
"type": "component-resource-resolution",
"interfaces": {
"ResourceResolutionComponent": {
"operations": {
"process": {
"inputs": {
"artifact-prefix-names": [
"vf-module-1"
]
}
}
}
}
},
"artifacts": {
"vf-module-1-template": {
"type": "artifact-template-velocity",
"file": "Templates/vf-module-1-template.vtl"
},
"vf-module-1-mapping": {
"type": "artifact-mapping-resource",
"file": "Templates/vf-module-1-mapping.json"
}
}
}
}
}
Multiple sub-actions
The workflow is backed by a Directed Graph engine, dg-generic (see Node type -> DG, and is an imperative workflow.
A DG used as workflow for CDS is composed of multiple execute nodes; each individual execute node refers to an modelled Component (see Node type -> Component) instance.
In the example above, you can see the target of the workflow’s steps execute-script is
execute-remote-ansible-process, which is a node_template of type dg_generic
"topology_template": {
"workflows": {
"execute-remote-ansible": {
"steps": {
"execute-script": {
"description": "Execute Remote Ansible Script",
"target": "execute-remote-ansible-process"
}
}
},
"inputs": {
"ip": {
"required": false,
"type": "string"
},
"username": {
"required": false,
"type": "string"
},
"password": {
"required": false,
"type": "string"
},
"execute-remote-ansible-properties": {
"description": "Dynamic PropertyDefinition for workflow(execute-remote-ansible).",
"required": true,
"type": "dt-execute-remote-ansible-properties"
}
},
"outputs": {
"ansible-variable-resolution": {
"type": "json",
"value": {
"get_attribute": [
"resolve-ansible-vars",
"assignment-params"
]
}
},
"prepare-environment-logs": {
"type": "string",
"value": {
"get_attribute": [
"execute-remote-ansible",
"prepare-environment-logs"
]
}
},
"execute-command-logs": {
"type": "string",
"value": {
"get_attribute": [
"execute-remote-ansible",
"execute-command-logs"
]
}
}
},
"node_templates": {
"execute-remote-ansible-process": {
"type": "dg-generic",
"properties": {
"content": {
"get_artifact": [
"SELF",
"dg-execute-remote-ansible-process"
]
},
"dependency-node-templates": [
"resolve-ansible-vars",
"execute-remote-ansible"
]
},
"artifacts": {
"dg-execute-remote-ansible-process": {
"type": "artifact-directed-graph",
"file": "Plans/CONFIG_ExecAnsiblePlaybook.xml"
}
}
}
}
}
}
Properties of a workflow
Property |
Description |
||||||
|---|---|---|---|---|---|---|---|
workflow-name |
Defines the name of the action that can be triggered by external system |
||||||
inputs |
They are two types of inputs, the dynamic ones, and the static one.
Specified at workflow level
These will end up under Represent the resources defined as input (see Node type -> Source -> Input) within mapping definition files (see Artifact Type -> Mapping). The enrichment process will (see Enrichment)
Example for workflow named resource-assignment: dynamic input
"resource-assignment-properties": {
"required": true,
"type": "dt-resource-assignment-properties"
}
|
||||||
outputs |
Defines the outputs of the execution; there can be as many output as needed.
Depending on the Component (see Node type -> Component) of use, some attribute might be retrievable.
|
||||||
steps |
Defines the actual step to execute as part of the workflow
|
Example:
{
"workflow": {
"resource-assignment": { <- workflow-name
"inputs": {
"vnf-id": { <- static inputs
"required": true,
"type": "string"
},
"resource-assignment-properties": { <- dynamic inputs
"required": true,
"type": "dt-resource-assignment-properties"
}
},
"steps": {
"call-resource-assignment": { <- step-name
"description": "Resource Assignment Workflow",
"target": "resource-assignment-process" <- node_template targeted by the step
}
},
"outputs": {
"template-properties": { <- output
"type": "json", <- complex type
"value": {
"get_attribute": [ <- uses expression to retrieve attribute from context
"resource-assignment",
"assignment-params"
]
}
}
}
}
}
}