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 from the SDC perspective and to allow new designers onboarding without adding a specific code.

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 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).

Plugin list:

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 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

SDC-1568 - Getting issue details... STATUS

UI Integration

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

The solution needs to be agnostic to the language in which the plugin UI is developed.

The communication between the hosted and the hosting applications needs to be language agnostic and extendable to allow the addition of more functionality and logic on top of this communication method.

Solution

The solution chosen was to use IFrame to host the plugins. The iFrame provides a 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.

The communication between the application will be done based on events.

SDC will hold an event bus in the application, we will define events for operations done in SDC that the plugins need to be notified about. On each defined operation, an event will be placed on the event bus for the plugins to consume.

Supported use cases

Based on the current plugin in SDC we identified two main use cases of how the plugins are used. The first is the presentation of the plugin as a tab on SDC top bar, this mode is used for Plugin that wants to design an object that can later be reused across different SDC elements, the second use case is opening the plugin as part of the service or resource where the designer will model objects in the context and using the properties of that resource/service.

Standalone use case

Use in a context of a service or resource

Iframe initiation

When the 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.

The information will be passed as part of the designer URL as a query param.

Plugin tab mod

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:

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.

The plugin can be enhanced so that in the future different plugins can communicate between them using the event bus. The event bus will use javascript for its implementation so that any UI language used will be able to use it.

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

SDC-pubsub library

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

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.

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;

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.

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

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.

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 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.

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

Window out event example

Version change even example

Check in even example

Submit for testing even example

Undo check out even example

Designer events

Ready event example

Action completed event example

Security TBD

Need to add solution for the iframe authorization and authentication.

SDC-1569 - Getting issue details... STATUS

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.

more information in the Appendix.

Appendix A – References

SDC external API’s

SDC consumer definition