Workflow

A workflow defines an overall action to be taken for the service; it can be composed of a set of sub-actions to execute. Currently, workflows are backed by Directed Graph engine.

A CBA can have as many workflow as needed.

Required workflows

The following workflows are contracts established between SO, SDNC and CDS to cover the instantiation and the post-instantiation use cases.

resource-assignment

This action is meant to assign resources needed to instantiate the service. The goal is to resolved all the HEAT environment variables.

This action is triggered by Generic-Resource-API (GR-API) within SDNC as part of the AssignBB orchestrated by SO. Hence it will be triggered for each VNF(s) and VF-Module(s).

In order to know for which entity the action is triggered, one input is required, that is the artifact prefix (see bellow for explanation).

artifacts

For each VNF and VF-Module comprising the service, a combinaison of a template and mapping is needed.

The requirement is as `follow` for VNF:

${vnf-name}-template
${vnf-name}-mapping

and as follow for VF-Module, where the vf-module-label is actually the name of the HEAT template file.

${vf-module-label}-template
${vf-module-label}-mapping

${vnf-name} and ${vf-module-label} is what we call the artifact prefix.

template

The template has to be a resource accumulator template; that be composed of the following sections:

• resource-accumulator-resolved-data: defines all the resources that can be resolved directly from the context. It expresses a direct mapping between the name of the resource and its value.

  RA resolved data Expand source

    "resource-accumulator-resolved-data": [
      {
        "param-name": "service-instance-id",
        "param-value": "${service-instance-id}"
      },
      {
        "param-name": "vnf_id",
        "param-value": "${vnf-id}"
      }
    ]

• capability-data: defines what capability to use to create a specific resource, along with the ingredients required to invoke the capability and the output mapping.

  RA capability payload Expand source

      {
        "capability-name": "netbox-ip-assign",
        "key-mapping": [
          {
            "payload": [
              {
                "param-name": "service-instance-id",
                "param-value": "${service-instance-id}"
              },
              {
                "param-name": "prefix-id",
                "param-value": "${private-prefix-id}"
              },
              {
                "param-name": "vf-module-id",
                "param-value": "${vf-module-id}"
              },
              {
                "param-name": "external_key",
                "param-value": "${vf-module-id}-vpg_private_ip_1"
              }
            ],
            "output-key-mapping": [
              {
                "resource-name": "vpg_private_ip_1",
                "resource-value": "${vpg_private_ip_1}"
              }
            ]
          }
        ]
      }

scripts

If any of the mapping uses a source capabbility to resolve a parameters.

config-assign

This action is meant to assign all the resources and mesh the templates needed for the configuration to apply post-instantiation.

This action is triggered by SO during after the AssignBB has been executed for Service, VNF and VF-Module.

artifacts

Combinaison of templates with respective mappings

Scripts if needed

config-deploy

This action is meant to push the configuration templates defined during the config-assign step for the post-instantiation.

This action is triggered by SO during after the CreateBB has been executed for all the VF-Modules.

artifacts

Combinaison of templates with respective mappings

Scripts using Netconf or Restconf to push configure the network element.