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 on UI bootstrap. The mechanize will not support automatic refreshed as such, to update the UI with a new designer or to pick up a designer’s new state the user will need to refresh.

High-level overview

...

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)

The used resource is:

https://{serverRoot}/sdc1/config/ui/plugins

...

Special Request Headers

...

Request Body

N/A

...

Request Sample

...

Response

...

Special Response Headers

...

Response body

Response body is returned as JSON object (Content-Type: application/json).

...

Plugins list:

PluginDisplayOptions tab:

PluginDisplayOptions tab:

...

PluginDisplayOptions context:

...

Response Sample 

...

...

...

...

...

...

...

...

HTTP response codes

...

Fe server configuration definition

The plugin configuration is used to define the location where the plugin Front-end server is located.

Based on the defined configuration SDC will execute a discovery of the available plugins and provide their information to the SDC UI.

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

...

Example

...

Health Check Integration - TBD

UI Integration

...

UI Integration

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

...

The solution chosen was to use IFrame to host the plugins. The iFrame provides a decupled decoupled window that can load any UI content as a separate window. The window contains the Html JS and CSS in such a way that they will not interfere with the hosting and hosted application.

...

Iframe initiation

When the iframe Iframe is initiated SDC pass initial information to the Iframe so that the correct plugin screen will be presented. The information will assist the iframe to define the context in which it is currently being opened.

...

In case of a TAB mode, SDC will pass the logged in user.

Plugin context mod

In case of context mod SDC will pass the following info:

Example

...

UI communication

UI communication is based on event processing. SDC creates an event bus, any plugin in the system and SDC itself will subscribe to this event bus. Events will be generated according to pre-defined events in the system. Any plugin can subscribe to events that are relevant to them.

...

SDC provides a mechanism to define if there is a need to wait for a response from a plugin or not.

SDC-pubsub library

befor before you can integrate with SDC you will need to add our pubsub librery intop 

...

in

...

The class will define a set of method that will allow the communication with SDC.

Plugin registration

to your application.

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.

The class will define a set of method that will allow the communication with SDC.

3.5.1     BasePubSub API

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

3.5.2     Call back definition

Each callback function that will be added to the eventsCallbacks map should have the following signature – callback(eventData, event).

eventData

NPM Repository:

https://www.npmjs.com/package/sdc-pubsub

import {PluginPubSub} from 'sdc-pubsub'

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

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

BasePubSub API

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

Call back definition

Each callback function that will be added to the eventsCallbacks map should have the following signature – callback(eventData, event).

eventData – The actual data the will be passed into the callback (The data that will be created in the notify function).

event – The JavaScript event object that was received in the onMessage function.

...

PluginPubSub API

the client class for communicating with the hub.

...

EventBusService API

...

Plugin API Usage examples

This is an example of how plugin should use the API’s defined in SDC event bus.

3.6.1     PluginPubSub class consumption.

...

Plugin initialization

As part of the SDC-UI. To consume it request SDC does to the plugin to retrieve the index.html we pass query prams.

From the query prams you will need to add the SDC-UI to your ui package.json so that NPM will be able to pull the package.

Consider refining the import if you do not need all the SDC-UI and just add this class.

3.6.2     Plugin initialization

As part of the request SDC does to the plugin to retrieve the index.html we pass query prams.

From the query prams you will need to use eventsClientId this is the id defined which will be passed to the contractor of the class for registration, this allows SDC to understand what plugin is sending the events and parentUrl which is the URL of SDC which is needed to send massages to SDC in a system working cross site.

The seconed example shows hoe to set the event the plugin wants sdc to wait for a response.

In this case SDC will continue the flow only after the ACTION_COMPLETED event is recived

Example:

eventsClientId=<received from query params>

parentUrl=<received from query params>

PluginPubSub client = new PluginPubSub(eventsClientId, parentUrl)

use eventsClientId this is the id defined which will be passed to the contractor of the class for registration, this allows SDC to understand what plugin is sending the events and parentUrl which is the URL of SDC which is needed to send massages to SDC in a system working cross site.

The second example shows how to set the event the plugin wants sdc to wait for a response.

In this case SDC will continue the flow only after the ACTION_COMPLETED event is received.

eventsClientId=<received from query params>
parentUrl=<received from query params>
PluginPubSub client = new PluginPubSub(eventsClientId, parentUrl)

...

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.

For example:

client.notify(“READY”)

3.6.4     Listen to events

The plugin will need to define a call back that will be called when an event is triggered in SDC.

The plugin call back can decide using the event type what and if any logic needs to be executed.

For example:

client.on((eventData,event) => {

      if(eventData.type == ”WINDOW_OUT”) {

                                             //do logic

       }

   }

)

3.7      Event Types

The events used in the communication will have the same structure to allow easy use.

Each event will include its type the generating entity and a body.

In this way, new events can be easily added to the system and the event originator can be tracked.

3.7.1     Event structure

{

type:XXX

originId:YYY

data:{}

}

3.7.2     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

...

know the plugin has loaded successfully.

client.notify(“READY”)

Listen to events

The plugin will need to define a call back that will be called when an event is triggered in SDC.

The plugin call back can decide using the event type what and if any logic needs to be executed.

For example:

client.on((eventData,event) => {
      if(eventData.type == ”WINDOW_OUT”) {
            //do logic
       }
   }
)

Event Types

The events used in the communication will have the same structure to allow easy use.

Each event will include its type the generating entity and a body.

In this way, new events can be easily added to the system and the event originator can be tracked.

Event structure

SDC generated events

3.7.2.1     Window out event example

{

type:WINDOW_OUT

origion:sdc-hub

data:

}

3.7.2.2     Version change even example

{

type: VERSION_CHANGE

origion:sdc-hub

data:{

     uuid: a21af8a1daa948f78e30f9b269a253ba ,

     version:1.1

}

}

3.7.2.3     Check in even example

{

type: CHECK_IN

origion:sdc-hub

data:

}

3.7.2.4     Submit for testing even example

{

type: SUBMIT_FOR_TESTING

origion:sdc-hub

data:

}

3.7.2.5     Undo check out even example

{

type: SUBMIT_FOR_TESTING

origion:sdc-hub

data: {

     uuid: a21af8a1daa948f78e30f9b269a253ba ,

     version:1.1

}

}

...

Window out event example

Version change event example

Check in event example

Check out event example

Submit for testing event example

Undo check out event example

Designer events

...

Ready event example

...

...

...

Action completed event example

origion:plugin

data:

}

3.8      Security TBD

Need to add solution for the iframe authorization and authentication.

...

Security TBD

Need to add solution for the iframe authorization and authentication.

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

...