HLD for SDC Workflow Designer

Target release

Casablanca

Epic



Document status

DRAFT

Document owner

@Shuki Yulzari

Designer

Developers

QA

Purpose and Scope

Purpose

As a Designer, I should be able to

  1. Create Workflow

  2. Edit the Workflow Details

  3. Collaborate with other users

  4. Submit the workflow for Certification.

  5. Distribute the workflow

We want to create a way where the integration of a new designer is seamless from the SDC perspective, we want to create a generic way where we can onboard new designers without needing to add specific code.

Scope

Workflow designer will be built as a pluggable designer with SDC as the host application.

The solution will provide several options for showing the designer as part of SDC.

The communication between the SDC and back-end side will be based on the external API’s SDC exposes.

Assumptions

In order to integrate between SDC and external workflow designer, the integrated external workflow has to be pre-configured at least with the following parameters:

  1. SSL: the traffic should be SSL traffic

  2. The communication between the application will be done based on RestAPI

  3. External Workflow designer system must support iFrame.

  4. Correlation between both SDC and external workflow based on ID's

  5. External workflow designer system should be highly available

  6. The workflow designer service is loosely integrated with SDC

  7. The workflow designer service should come with version management built-in

Deployment

Workflow Frontend

The frontend will be deployed separately from the backend, particularly due to architectural constraints related to security.

Workflow Backend

Workflow designer backends will be maintained separately in the code base but deployed as a single deployment unit.

Workflow Versioning

An only major version is supported.

Lifecycle Behavior

The lifecycle of the workflow begins with the creation of the workflow.

Once the creator finishes the updates – he should check-in the asset.

An iterative flow of checkout-update-checkin can be performed until the workflow is ready to be certified.

Every checkout of the resource increases the minor version of it. Certification of the resource increases the major version.

Limitation

  • once you certify the model, you cannot change or edit the model.

  • when the model is certified and a new major version is created, all the minor versions are deleted from SDC

Use Cases

Workflow as a first-class citizen

  1. Create new workflow

  2. Save workflow

  3. Versioning workflow

  4. Createnewworkflowversion

  5. Edit workflow

  6. Associate workflow

Workflow in context of VF

  1. Create Workflow Context in of VF based on Operation.

  2. Launch workflow Designer

  3. Submit VNF – Include Workflow Artifacts in CSAR.

  4. Edit Operations – Update Workflow Context

  5. Delete Operations – Update Workflow Context

  6. New VNF Version Operations – Update Workflow Context

Collaborate Workflow

  1. Versioning workflow

  2. Createnewworkflowversion

Submit the workflow for Certification

  1. Certify workflow

Distribution Workflow as part of

  1. Tosca – Adding the input

  2. Distribute WF as a separate artifact in the context of VF CSAR OOS

Operation on VF

  1. Associate workflow to operation

  2. Change to associated workflow

  3. Adding inputs to the operation

  4. Assign inputs to the operation

  5. Save workflow artifact in SDC

Solution Overview

The solution will position SDC as a hosting application providing a design platform for workflows.

Each Workflow designer studio will be treated as an external service/application/system in the eyes of SDC.

SDC will call API’s forget, search for the external workflow application, assigned to the service/VF operations with the workflow artifacts.

Generic Workflow Logical Model



SDC extensibility

SDC provides extensibility framework architecture to achieve micro-service. 

Each external workflow studio must have a set of a micro-service with its own Front-End(UI) Back-End (Business logic) and Repository (Database)

Because SDC is a multi-tier application we expect external different workflows to uphold the same architecture.

Functional Specifications

Workflow Designer

Architecture Overview

  1. SDC is a container

  2. Workflow Designer is a set of micro-services supplying both UI (editor) and business logic backend.

    1. for BPMN.io (a.k.a ZTE) there is only FE without BE and the communication is with the Workflow Designer BE (CRUD API's)

    2. for Other Designer, Other providing their own FE and BE and the communication is with Other BE with Workflow Designer BE (CRUD API's)

  3. The Editor exposes an operational API’s (CRUD) which will be invoked by the Workflow Manager (Save, Check-in, Check-out etc).

  4. The Repository is optional and the external workflow can use the Workflow designer BE repository

Workflow Designer - Integrated Solution with ONAP

Workflow Designer - BPMN.io Editor

API's exposed by External Workflow BE

Functional Specification

Workflow Designer BE will expose API’stosupportoperationsoftheworkflow such as ‘get’ and 'search'.

Protocol

The protocol is RESTful GET API directly.

Format

The format is JSON object



Operational SDC API’s

  1. Get Workflow Content by WF versionId that are in 'CERTIFIED' state

  2. List Workflow Content that are in 'CERTIFIED' state

  3. Search Workflow Content

  4. Create New Workflow

  5. Create New Version of existing Workflow

  6. Copy Workflow

  7. Update Workflow

  8. Save Workflow into SDC

API’s exposed by External Workflow

Functional Flows

Create workflow (first-class citizen)

Sequence diagram

Limitations:

  1. until the workflow is not in status "CERTIFY" it editable - the workflow system must be able to save intermediate state for the workflow.

  2. once the workflow is in "CERTIFY" mode it cannot be edit

  3. there are no mentions for versioning management and the assumption is that the workflow application has version management OOB.

Create workflow (from Operation in context of VF)

Sequence diagram

High-level flow

#

flow

Context

Description

#

flow

Context

Description

1

Browser-->SDC_FE



Create Workflow in context of VF+Operation

2

SDC_FE–>WF_FE

{VF_ID,

Operation_ID,

Inputs/Outputs}

SDC_FE POST WF_FE the I/O of the VF+Operation context

3

WF_FE -->WF_BE

none

WF_FE send a request to WF_BE to create a new WF+WF version









4

WF_BE-->WF_BE

none

WF_BE creates a new WF and generates new WF_ID+WF_VER_ID

5

WF_BE -->WF_Repo

{WF_ID,

WF_VER_ID,

artifact_file}

WF BE store new WF+WF_version+artifact into the WF Repository

6

WF_BE-->WF_FE

{WF_ID,

WF_VER_ID}

WF_BE returen to WF_FE the new WF_ID+WF_

7

WF_BE-->SDC_BE

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

artifact_file}

WF BE send (PUT) by the given VF context the artifact to WF BE for storing the WF artifact

6

SDC_BE-->SDC_Repo

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

artifact_file}

SDC_BE store the WF artifact file into SDC_Repo by the given VF+Opertaion context

Associate workflow to an Operation and Save Artifact

Sequence diagram

High-level flow

#

flow

Context

Description

#

flow

Context

Description

1

SDC_FE --> WF_FE

{WF_ID,

WF_VER_ID}

SDC FE send an event to WF EF that the association of the workflow to the operation is done with VF+Operation+WF context

2

WF_FE -->WF_BE

{WF_ID,

WF_VER_ID}

WF FE send an event to WF BE to fetch the WF artifact by the given WF_ID

3

WF_BE -->WF_Repo

{WF_ID,

WF_VER_ID}

WF_Repo fetch the WF artifact by the given WF_ID from WF repository

4

WF_BE -->SDC_BE

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID

artifact_file}

WF BE send (PUT) by the given VF_ID the artifact to SDC BE for storing the WF artifact

5

SDC_BE-->SDC_Repo

{VF_ID,

Operation_ID,

Artifact_ID,

artifact_file}

SDC_BE store the WF artifact file into SDC_Repo by the given VF+Opertaion context

related API's

API URI

Direction

Description

API URI

Direction

Description

PUT /workflows/{id}/versions/{versionId}/artifact

--> SDC BE

Save artifact into SDC BE

GET http://ip:port/wf/workflows/{id}/versions/{versionId}/artifact

--> WF_FE

Get Artifact From WF Designer

Save Operation and Save Artifact (Download) (deprecated)

Sequence diagram

High-level flow

#

flow

Context

Description

#

flow

Context

Description

1

Browser --> SDC_FE

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID}

Browser call SDC_FE to create/save the operation

2

SDC_FE -->WF_FE

{WF_ID,WF_VER_ID}

SDC FE call WF BE to download the artifact by the given WF_VER_ID

3

WF_FE -->WF_BE

{WF_VER_ID}

WF_FE call WF_BE to fetch the artifact from the repository

4

WF_BE -->WF_Repo

{WF_VER_ID}

WF_Repo fetch the WF artifact by the given WF_ID from WF repository

5

WF_BE -->WF_FE

{WF_VER_ID,artifact_file}

<Response> WF_BE return to WF_FE on the response the artifact file

6

WF_FT -->SDC_FE

{WF_ID,

WF_VER_ID

artifact_file}

<Response> WF BE return to SDC_FE on the response the artifact as a file

7

SDC_FE -->SDC_BE

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

artifact_file}

SDC_FE call SDC_BE to create\save the opertaion

8

SDC_BE-->SDC_Repo

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID}

SDC_BE store the the operation with the VF context

9

SDC_FE -->SDC_BE

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

artifact_file}

DC_FE call SDC_BE to save the WF artifact file

10

SDC_BE-->SDC_Repo

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

Artifact_ID,

artifact_file}

SDC_BE store the WF artifact file into SDC_Repo by the given VF+Opertaion+Artifact_ID context

Related API's

related API's

API URI

Direction

Description

API URI

Direction

Description

PUT /workflows/{id}/versions/{versionId}/artifact

--> SDC BE

Save artifact into SDC BE

GET /workflows/{id}/versions/{versionId}/artifact

--> WF_FE

Get Artifact From WF Designer

Certify (Submit) VF/Operation

Sequence diagram

Edit Operations – Update Workflow from the VF/Operation

The user has created an operation, worked on the workflow, went back to the operation and changed inputs/outputs.worked on workflow and submitted VNF

Multiple changes to operation in a version of VNF

Sequence diagram

New VNF Version Operations – Update Workflow Context from the VF/Operation

The user created a new version of VNF and started to edit a previously existing operation change inputs/outputs. update workflow and submit VNF.

Changing an operation in a different version of VNF

Sequence diagram

High-level flow

#

flow

Context

Description

#

flow

Context

Description

1

Browser-->SDC_FE

 

Createnewbersionofthe VF + Operation

2

Browser-->SDC_FE

 

Edit Workflow

3

Browser–>WF_FE

{VF_ID,

Operation_ID,

WF_ID,

SDC_BE_URL}

Browser send an event to WF_FE to that operation been updated by WF_ID + VF context

4

WF_FE -->WF_BE

{WF_VER_ID}

WF_FE send an event to WF_BE notifying the update by WF+WF version + VF context

5

WF_BE -->WF_Repo

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

artifact_file}

WF BE update the WF artifact by WF+WF_version+artifact

6

WF_BE-->SDC_BE

{VF_ID,

Operation_ID,

WF_ID,

WF_VER_ID,

artifact_file}

WF BE send (PUT) by the given SDC_BE_URL the artifact to WF BE for storing/update the WF artifact by the given WF_ID

Workflow Data Model Metadata

Field

Description

DataType

Validations 

Field

Description

DataType

Validations 

id

Identifier generated by SDC per each Workflow. Remains same across various versions of Workflow.

Used by SDC and ONAP components to identify Workflow. Not human readable.

string

 

2

versionId

UUID generated by SDC per each version of the Workflow.

Used by SDC and ONAP componentstoidentifyspecificversionofWorkflow. Not human readable.

string

 

version 

Humanreadableversionwithamajorandminor versions. Generated by SDC.

Firstversion created will be 1.0.

<major>.<minor>

e.g., 1.0, 1,3, 2.0, 4.5

string 

 

3

name

Name of the Workflow. Auser friendlyname specified by the user while creating the workflow.

string

Allow only capital Alphabets [A-Z] and underscore[_].

NameshouldbeUnique(casein-sensitive) across workflows that are in Draft or Distributed state.

Minimum length of 6 characters.

Maximumlengthof 30 characters.

Note: Validationsshouldbeconfigurableregularexpression.

 

4

description

Description of Workflow.

string 

Similar to Description of VF or Service

category 

Categories of the workflow.

Configurable valid values

e.g.,

Service

  • SD-WAN

  • VoIP

  • Consider upto 10

Resource

  • VNF

  • PNF

  • Network

string[] 

 

6

inputs

Inputs of the Workflow

parameter[] 

Similar to Inputs of Operation

7

outputs 

Outputs of the Workflow

parameter[] 

Similar to Inputs of Operation 

workflow 

Composition of the workflow 

 

9

status 

Status of worklow 

string 

 

10 

created date 

Date on which the workflow is created 

date 

 

11 

create user 

user-id of the user who created the workflow 

 

12

last modified date 

Date on which the workflow is last modified. Default creation date

date 

 

13 

last modify user 

user-id of the user who last modified the workflow. Default create user

 

14 

artifacts

Artifact representing the workflow. Default empty BPMN

?

 





 
Name

 

Data Type

Required

Description

 
Name

 

Data Type

Required

Description

id

String

Y

 

versionId

String

Y

 

name

String

Y

 

description

String

Y

 

category 

String

N

 

inputs

String

N

 

outputs 

String

N

 

workflow 

String

N

 

status 

String

Y

 

created date 

String

N

 

create user 

String

N

 

last modified date 

String

N

 

last modify user 

String

Y

 

artifact references

String

N