Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel2

Overview

SDC is a Design platform, as such, we want to create an easy way to add new design capabilities to SDC.

...

The SDC design capabilities are provided by the main design tools, onboarding (VNF design), VF design/import and the service design. In addition to the main

...

designe capabilities, SDC also provides the DCAE-DS blueprint design studio.

At the

...

current state, SDC does not have a standard for adding new designers. because of this, any new integration requires the SDC team to create a specific logic in the SDC code base to support such an integration.

The code changes needed are

...

mostly found in the UI since

...

until now we had to create a designer specific logic to support

...

each integration


Solution concept

 We want to create a way where the integration of a new designer is seamless

...

to the SDC

...

and will allow new designers

...

integration without requiring any code addition on the SDC side.

The solution will provide several options for showing the designer as part of SDC. The communication between the SDC and the designers on the UI side will be event based and on the back-end side

...

It will be based on the external API’s that SDC exposes.


Designer

...

Configuration

As part of the integration between SDC and the different plugins, we uphold the concept that SDC can function without any of the different plugins.

The designers enhance the capabilities of SDC they do not prohibit the SDC core functionality.

As a result, we want to create a mechanize that is configured based to decide what designers are shown in the SDC.

Solution

The availability will be based on a REST

...

HEAD call to the plugin UI server to check the availability of the server.

If the server response successfully a relevant flag will be updated to true and the plugin info will be returned in the response if not the flag will be set to false.

...

The SDC UI will execute the call when accessing the plugin page. This way we're making sure that only when the user wants to access the plugin page in the UI the actual online state of this particular plugin will be checked.

High-level overview

The solution will position SDC as a hosting application providing a platform for plugins to enhance the existing capabilities. Each plugin will be treated as a separate service in the eyes of SDC. From the SDC perspective, the plugin can be position anywhere. Because SDC is a multi-tier application we expect the different plugins to uphold the same architecture. There should be a separation between the FE server which is in the DMZ and serves UI pages to the BE server which is in the Protected network, that handles the DB access and the Businesses logic operations. The designer service is loosely integrated with SDC. The two integration points are the plugin  UI server location, which is configurable in the FE server configuration and a rest based communication between the plugins backend and SDC backend.

 


Flow diagram fix

...

TBD

The diagram describes the discovery process from the point when a user access SDC.

 

Rest endpoint

Request (GET)

...

Header Name

Mandatory?

Description

X-ECOMP-RequestID

N

According to the general agreement the  "X-ECOMP-RequestID"  header with the transaction UUID should be published by component calling an exposed by other component API in order to make possible the transaction traceability across ECOMP.  If it is not sent it will be automatically generated by SDC on request receipt.

Accept

N

Determines the format of the body of the response. Valid values are :  “application/json”

Request Body

N/A

...

Request Sample


Info
iconfalse
titleRequest Sample

GET  sdc1/config/ui/plugins  HTTP/1.1

Accept : application/json

X-ECOMP-RequestID: AA97B177-9383-4934-8543-0F91A7A02836

...

Parameter Name

Parameter Type

Description

pluginsList

List of objects

List describing each plugin location and configuration for the UI integration.

...

connectionTimoutIntegerTime in milliseconds for trying to establish a connection to when executing an HEAD request to each plugin


Plugins list:

Parameter Name

Parameter Type

Description

pluginId

String

The id of the plugin

pluginDiscoveryUrl

String

The URL which will be used to check the plugin availability

pluginSourceUrl

String

The URL which will be used to load the plugin pageto load the plugin page

pluginStateUrlStringThe state URL for the UI router

pluginDisplayOptions

Map of objects

An map of object representing the plugin options, the currently supported options are tab and context.

isOnline

Boolean

This value indicates to the SDC UI if the plugin is currently online. If the plugin is down an attempt to open the plugin will result in an error screen.


PluginDisplayOptions tab:

...

Parameter Name

Parameter Type

Description

displayName

String

The name to show for this plugin in the context area.

displayRoles

List of string

The user roles for which this plugin will be shown.

Supported roles are ADMIN, DESIGNER, TESTER, OPS, GOVERNOR.

displayContext

List of string

A list of contexts in which the plugin will be shown:

VFC, VL, CP, VF, PNF, SERVICE.


Response Sample 

Info
iconfalse
titleResponse Sample

[  {    "pluginId": "DCAE",

    "pluginDiscoveryUrl": "http://<ip>:8702/openoui/vnfmarketdcae/#!/marketplaceindex",

    "pluginSourceUrl": "http:// <ip>:8702/openoui/vnfmarketdcae/#!/marketplaceindex",

    "pluginStateUrl": "dcae",

    "pluginDisplayOptions": {

      "tab": {

        "displayName": "DCAE",

        "displayRoles": [ "TESTER" ]

      },

      "context": {

        "displayName": "Monitor",

        "displayContext": [ "VF", "SERVICE" ],

        "displayRoles": ["DESIGNER" ]

      }

    }

  },  {

    "pluginId": "WORKFLOW",

    "pluginDiscoveryUrl": "http://<ip>:9527/",

    "pluginSourceUrl": "http:// <ip>:9527/",

    "pluginStateUrl": "workflowDesigner",

    "pluginDisplayOptions": {

      "tab": {

        "displayName": "WORKFLOW",

        "displayRoles": ["DESIGNER","TESTER" ]

      },

      "context": {

        "displayName": "Workflow Designer",

        "displayContext": ["VF"],

        "displayRoles": ["DESIGNER", "TESTER" ]

      }

    }

  }]

...

The configuration allows SDC to control where the plugin UI will be displayed, tab mode or context mode.

...


Configuration fields

The designer configuration is located under {app base}/config/catalog-fe/plugin-configuration.yaml

Field

Type

Description

connectionTimeout

Integer

This is the number of milliseconds, for the head request to wait for a response from the plugin.

pluginsList

List of objects

A list of plugins’s configurations.

pluginId

String

The name of the plugin.

pluginHostpluginId

String

The host where the designer is locatedname of the plugin.

pluginSourceUrl

String

The plugin URL passed to the UI to retrieve the page.

pluginDiscoveryUrl

String

The plugin URL used for the availability check.

pluginStateUrl

String

The plugin state for UI router.

pluginerDisplayOptions

String

We currently support two work modes for plugins:

  1. tab – opens the designer as a tab, for this type we need to set displayName field to define what the tab text and the display roles which define what roles will see the plugin.
    example:
    tab:

displayName: "Workflow Designer"

displayRole: [“TESTER”]

  1. context – opens the designer as a context, for this type we need to set displayName field, displayRole and define the displayContext in which the plugin will open, options VF/SERVICE/CP/VL/VFC.
    example:
    context:

            displayName: "monitor"

                               displayRole: [“TESTER”]

            displayContext: ["VF", "SERVICE"]

...

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-1568


UI Integration

SDC need needs to onboard plugins in a way that will be decoupled from the SDC UI implication.

...

Param

Description

userId

The id of the user logged into SDC.

userRole

The role of the connected user, options ADMIN, DESIGNER, TESTER, OPS, GOVERNOR.

displayType

The type of view the plugin is opened in tab/context.

contextType

The type of the context where the plugin is opened: VF/CP/VL/VFC/SERVICE

uuid

Unique id of the context the designer plugin is opened in.

lifecycleState

The state the context /resource or service are currently in:
                                READY_FOR_CERTIFICATION/                CERTIFICATION_IN_PROGRESS/

                CERTIFIED/          NOT_CERTIFIED_CHECKIN/

NOT_CERTIFIED_CHECKOUT;

isOwner

A Boolean value describing if the logged user is the owner/lastUpdator of the resource/service.

version

The version of the item displayed.

parentUrl

The URL of the SDC the plugin is opened in. used to subscribe to the event bus in SDC.

eventsClientId

The name with which the plugin needs to register with to the event bus.

...

before you can integrate with SDC you will need to add our pubsub librery in to your aplicationapplication.

SDC will expose a base class in JS as part of the SDC UI project. Any plugin will be able to communicate with SDC after they instantiate this class.

...

Info
iconfalse
titleUsing the librery

Loading It Up

CommonJS

import {PluginPubSub} from 'sdc-pubsub'

Global Variable

<!-- index.html -->
<script src="./node_Modulesmodules/sdc-pubsub/dist/sdc-pubsub.js"></script>

// script.js
var pubsub = window.sdcPubSub.PluginPubSub;

Plugin registration

SDC will expose a base class in JS as part of the SDC UI project. Any plugin will be able to communicate with SDC after they instantiate this class.

...

.PluginPubSub;



BasePubSub API

Base class holding all the basic operations needed for using the event hub.

...

Code Block
languagejs
titleExample with events to wait for
eventsClientId=<received from query params>
parentUrl=<received from query params>
eventsToWaitFor = [ “CHECK_IN” ]
PluginPubSub client = new PluginPubSub(eventsClientId, parentUrl, eventsToWaitFor)

...



Send ready event

As part of the plugin flow, the plugin will need to send the ready event to SDC so that SDC will know the plugin has loaded successfully.

...

Info
iconfalse

{

       type: XXX"eventType"

       originIddata: YYY{}

       data:{}originId: "originName"

}

SDC generated events

Name

Type

When

Data

UI state

Description

Window out

WINDOW_OUT

Before SDC closes plugin,

The event is sent on all events below except VERSION_CHANGE and check out

none

Moves out of the plugin scope

The event is posted by SDC once the plugin window is going to be closed because of user action.

Version change

VERSION_CHANGE

After SDC retrieves item

New item version and UUID

The plugin is displayed on screen.

The event is posted by SDC once context version is changed by the user.

Check in

CHECK_IN

Before SDC closes plugin

none

SDC opens the catalog.

The event is posted by SDC once the context is being checked by the user.

Check out

CHECK_OUT

After SDC successful checkout the item

New item version and UUID

The plugin is displayed on screen.

The event is posted by SDC once the context is being check out by the user.

Submit for testing

SUBMIT_FOR_TESTING

Before submitting for testing is executed

none

SDC opens the catalog.

The event is posted by SDC once the context is being submitted for testing by the user.

Undo check out

UNDO_CHECK_OUT

After SDC executed the undo check out.

item version and UUID

SDC opens the catalog.

The event is posted by SDC once the context is being submitted for testing undone by the user.Undo check

Window out

...

UNDO_CHECK_OUT

...

After SDC executed the undo check out.

...

item version and UUID

...

SDC opens the catalog.

...

The event is posted by SDC once the context is being undone by the user.

Window out event example


Info
iconfalse

{

    type: "WINDOW_OUT"

    data:

    originId: "sdc-hub"

}


 

Version change event example


Info
iconfalse

{

    type: "VERSION_CHANGE"

    data: {

         uuid: a21af8a1daa948f78e30f9b269a253ba ,

         version:1.1

    }

    originId: "sdc-hub"

}

Check in event example


Info
iconfalse

{

    type: WINDOW"CHECK_OUTIN"

    origiondata:

originId: "sdc-hub    data:"

}

 

...

Check out event example


Info
iconfalse

{

    type: VERSION_CHANGE

    origion:sdc-hub

    "_CHECK_OUT"

    data: {

         uuid: a21af8a1daa948f78e30f9b269a253ba ,

         version:1.1

    } }

Check in even example

Info
iconfalse

{

    type: CHECK_IN

    origion:    originId: "sdc-hub    data:"

}

Submit for testing

...

event example


Info
iconfalse

{

type: "SUBMIT_FOR_TESTING"

data:

origion originId: "sdc-hub"

data:

}


Undo check out

...

event example


Info
iconfalse

{

    type: SUBMIT"UNDO_FORCHECK_TESTINGOUT"

    origion:sdc-hub    data: {

         uuid: a21af8a1daa948f78e30f9b269a253ba ,

         version:1.1

    }

    originId: "sdc-hub"

}

...



Designer events

Name

Type

Description

Ready

READY

The event is posted by the plugin once it is ready.

Action completed

ACTION_COMPLETED

The event is sent by the plugin after receiving an event from SDC that the plugin added to notify the event passed to the plugin has be completed and SDC can continue the eventsToWait list in order to notify SDC to continue with its flow.

...


Ready event example

Info
iconfalse

{

    type: "READY"

...

    data:

...

originId: "pluginName"

}

...


Action completed event example


Info
iconfalse

{

    type: "ACTION_COMPLETED"

origion:plugin

data:

}

 

3.8      Security TBD

Need to add solution for the iframe authorization and authentication.

...

    data:

originId: "pluginName"

}


Security TBD

Need to add solution for the iframe authorization and authentication.

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDC-1569

SDC-UI

to allow a single look and feel in SDC we need to create a single design style definition.

The user using the system should not distinguish between the different designer studios in SDC, the experience should be unified across the different design activities.

...

SDC UI Style and component library

SDC developed a UI library include the style guide fonts and components used in SDC.

The library components were developed in angular 2 and react to allow easy integration of the component in different design application.

The library allows the different designers to align their style to the SDC to create a single look and feel.


The library is located here:

...

the library is in the process of moving to LF.


SDC Designer infra structure

SDC will aim to provide a robust infrastructure to allow new designers to easily integrate with SDC. SDC will to create a generic way for designers to add them self’s to SDC without the need to add designer specific code to SDC

...

.

...

SDC external API’s

Designer will leverage the existing external API’s provided by SDC. The API’s are protected by basic authentication.

Any new designer will need to request

...

a user for their designer to interact with the SDC external API’s.

3.10.1.1  SDC external API guide

3.10.2   SDC persistency layer TBD

...

more information in the Appendix.


Appendix A – References

...

SDC external API’s

https://wiki.onap.org/display/DW/SDC+API

...

SDC consumer definition

...