Table of Contents | ||
---|---|---|
|
Overview
SDC is a Design platform, as such, we want to create an easy way to add new design capabilities to SDC.
In 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 designee designe capabilities, SDC also provides the DCAE-DS blueprint design studio.
At the presentcurrent 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 usefully mostly found in the UI since up until now we had to create a designer specific logic to support the each integration
Solution concept
We want to create a way where the integration of a new designer is seamless from to the SDC perspective, we want to create a generic why where we can onboard and will allow new designers without needing to add specific codeintegration 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 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 availability will be based on a REST head 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 refreshThe 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.
...
Parameter Name | Parameter Type | Description |
pluginsList | List of objects | List describing each plugin location and configuration for the UI integration. |
connectionTimout | Integer | Time in milliseconds for trying to establish a connection to when executing an HEAD request to each plugin |
Plugins Plugin 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 |
pluginStateUrl | String | The 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 | ||||
---|---|---|---|---|
| ||||
[ { "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:
displayName: "Workflow Designer" displayRole: [“TESTER”]
displayName: "monitor" displayRole: [“TESTER”] displayContext: ["VF", "SERVICE"] |
...
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
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: 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 | ||||
---|---|---|---|---|
| ||||
Loading It UpCommonJS
Global Variable
|
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.
...
|
BasePubSub API
Base class holding all the basic operations needed for using the event hub.
...
Code Block | ||||
---|---|---|---|---|
| ||||
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 | ||
---|---|---|
| ||
{ 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 UUIDnone | 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.
event example
Info | ||
---|---|---|
| ||
{ type: "WINDOW_OUT" data: originId: "sdc-hub" } |
Version change event example
Info | ||
---|---|---|
| ||
{ type: "VERSION_CHANGE" data: { uuid: a21af8a1daa948f78e30f9b269a253ba , version:1.1 } originId: "sdc-hub" } |
Check in
...
event example
Info | ||
---|---|---|
| ||
{ type: WINDOW_OUT"CHECK_IN" data: originId: " origion:sdc-hub" data: } |
...
Check out event example
Info | ||
---|---|---|
| ||
{ type: VERSION_CHANGE origion:sdc-hub"_CHECK_OUT" data: { uuid: a21af8a1daa948f78e30f9b269a253ba , version:1.1 } } |
Check in even example
Info | ||
---|---|---|
| ||
{ type: CHECK_IN origion: originId: "sdc-hub" data: } |
Submit for testing
...
event example
Info | ||
---|---|---|
| ||
{ type: "SUBMIT_FOR_TESTING" data: originIdorigion: "sdc-hubdata:" } |
Undo check out
...
event example
Info | ||
---|---|---|
| ||
{ 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 | ||
---|---|---|
| ||
{ type: "READY" origiondata:plugin data originId: "pluginName" } |
Action completed event example
Info | ||
---|---|---|
| ||
{ type: "ACTION_COMPLETED" origiondata:plugin data originId: "pluginName" } |
...
Security TBD
Need to add solution for the iframe authorization and authentication.
...