Legal notes

Copyright 2022 by TECHNIA AB

All rights reserved.

Preface

Widget as a Service (WaaS) is a configurable widget framework for the 3DEXPERIENCE platform and is a cost-efficient solution to raise productivity and user acceptance.

WaaS allows configuration of tailored 3DDASHBOARD widgets presenting data from standard OOTB services in any preferred way making users more efficient and willing to accept using the platform. The framework contains many different building blocks, such as tables and forms, that could be configured individually into simple or together into more complex apps, all integrating well with OOTB functionality such as 6WSearch.

The widget framework and definition is hosted on TECHNIA.cloud. Access controlled by subscription and token it can be added to any 3DEXPERIENCE environment, including cloud tenants. The widget is added by pasting a link into the administration dialog “Create Additional App“. The dialog allows adding widgets without any customization to the target environment just by adding the metadata of the whereabouts of the widget that is kept fully outside.

Widget as a Service consume all 3DEXPERIENCE data locally, between the 3DEXPERIENCE platform and the client browser. No 3DEXPERIENCE data, except user information for usage audit purposes (see agreement for details), is passed elsewhere or to the TECHNIA.cloud.

Basics

Supported platforms

3DEXPERIENCE 2019x or higher

Subscription & access

Widget configuration is controlled by a subscription and access token. Subscriptions have an end date and a user count. As the subscription runs out or the user count is exceeded, the widget is no longer accessible.

Hosting

Widgets are hosted on TECHNIA.cloud (currently on AWS). For more detail please refer to the agreement.

The following resources are hosted on TECHNIA.cloud

• Widget Framework (.html, .css, .js)

• Widget Definition

  • Configuration (e.g. columns, datasets etc .json)

  • Code (e.g. custom rendering, data calculations etc .js)

• Subscription detail and usage data

Setup (adding a widget in 3DEXPERIENCE)

Updates

The widget framework is evergreen and updates at least every 11 weeks. Updates could include improvements to existing functionality or new functionality enabled by configuration.

Deployment & administration

Customers or customer representatives (consultants) sometimes control widget definitions themselves (depending on the agreement). Widget definition is currently managed over https://curl.se/ using basic authentication (you can use git bash or similar terminal).

• Configurations

  • List configurations

  • Create configuration

  • Update configuration

• Code Resources

  • Create & update code resource

Configuration administration

List configurations

The following cURL will list the id and name of all configurations related to the admin user.

export SERVER=https://waas.technia.cloud
export USER=
export PASSWORD=
curl ${SERVER}/api/v1/configs -u "${USER}:${PASSWORD}" -k 

Create configuration

The following cURL template will create a new widget definition.

export SERVER=https://waas.technia.cloud
export CONFIG_NAME=
export CONFIG_FILE=
export USER=
export PASSWORD=
export CONTENT_TYPE='Content-Type: multipart/form-data'
curl -XPOST ${SERVER}/api/v1/configs -H "${CONTENT_TYPE}" -F "name=${CONFIG_NAME}" -F "config=@${CONFIG_FILE}" -u "${USER}:${PASSWORD}" -k 

Update configuration

The following cURL template will update the widget definition and/or its name (used referring from 3DX).

export SERVER=https://waas.technia.cloud
export CONFIG_ID=
export CONFIG_NAME=
export CONFIG_FILE=
export USER=
export PASSWORD=
export CONTENT_TYPE='Content-Type: multipart/form-data'
curl -XPUT ${SERVER}/api/v1/configs/${CONFIG_ID} -H "${CONTENT_TYPE}" -F "name=${CONFIG_NAME}" -F "config=@${CONFIG_FILE}" -u "${USER}:${PASSWORD}" -k 

Code Resource administration

Create & update code resource

To add a custom js resource to use in configurations (e.g. custom dataHandlers) you can push a js file to the server using the following cURL.

export SERVER=https://waas.technia.cloud
export COMPANY_ID=
export FILE=
export USER=
export PASSWORD=
export CONTENT_TYPE='Content-Type: multipart/form-data'
curl -XPOST ${SERVER}/api/v1/companies/${COMPANY_ID}/resources -H "${CONTENT_TYPE}" -F "file=@${FILE}" -u "${USER}:${PASSWORD}" -k 

UI Framework & configuration

Common concepts

To make configuration independent of service detail, and to hide complexity from the developer, the framework comes with a technical concept common to all components.

All services loads data to a common in memory data store. Query statements and other configuration is applied to populate UI components, all from the data store. This allows a compact and standardized cross component configuration format independent of service details. There is no direct dependency between any UI component configuration and the service layer, on top of that all components share the same data store and reflect data changed by other components.

Data store

The client (browser) data store is in memory and temporary, the purpose is to track cross component state, provide data to the UI rendering and to provide a common format to avoid service dependency in configuration. A data store is common practice in many modern UI frameworks e.g. https://redux.js.org/ and should not be confused with a data base.

https://js.cytoscape.org/, a “Graph theory (network) library for visualisation and analysis“, is used as data store. The graph capabilities enables complex data store selection and structure traversal (similar to mql). The cytoscape.js selectors is similar to css selectors and is used in configuration. Normally cytoscape runs in headless mode without any visualizations. Visual graphs can be enabled in development mode and provides a live view of the data store but comes with a performance cost. Developers can also query the data store graph using developers console.

Nomenclature

Colours

TODO

Widget

A top level configuration. Defines a 3DDASHBOARD widget app that could be added to the compass.

{
  "$schema": "./schema/waas.schema.json",
  "title": "Widget Example",
  "resources": ["my-plugin.js"],
  "components": [{}],
  "table_definitions": [{}],
  "tableColumn_definitions": [{}],
  "toolbar_definitions": [{}],
  "command_definitions": [{}],
  "datasets": [{},{}],
  "services": [{}],
  "mode": {}
}

Component

Defines a UI component used by the widget.

Remove this? Move requiresContext and root def to root widget conf?

{
    "name": "??neverUsed??",
    "type": "table",
    "definition": "ups-roots-example",
    "root": true,
    "requiresContext": true
}

Data set

A data set is used when you need to define a subset of the data store to use somewhere in the UI components. Could be related to some other specific data or global, automatically picking up the context it is applied to.

Example use:

• When expanding a table row, what related data should display as child rows? (e.g. product structure)

• In a related data column, which nodes should be presented? (e.g. specifications)

• Loading the root nodes of a table, should all data nodes go there or just with a certain state or type?

Chained data sets

Data sets could be chained together (e.g. give me all project nodes related to me → out of those fully expand their folder structures → out of that result give me all in work documentation). To chain simply use the datasets property and point out the data sets to apply on the result set of the first data set before returning.

Data set selectors statements

It is common to use statements to filter by some specific property. Data sets uses https://js.cytoscape.org/#selectors selectors and https://js.cytoscape.org/#collection/traversing traversing API’s, the selector statements are directly used by administrators in configuration and is good to refer to for detail (API’s are used internally and only of interest when writing Plugin code extensions).

Data set definition

Common data set properties

The following properties applies to all data set configuration

Expand

Traverses the graph (similar to mql expand) the given number of levels applying the edge and node statements (selectors) on each every level independently (it require match for each level and not the result set, which cold give a different result). You can control the number of levels, the direction and what selectors to apply for edges and for nodes. There is an option to retain leaf nodes of that expand only.

{
    "name": "ups-roots-example",
    "type": "expand",
    "edgeStatement": "[type='VPMInstance']",
    "nodeStatement": "[type='VPMReference']",
    "predecessors": true,
    "leavesOnly": true,
    "levels": 100
}

Filter

Filters out all eles matching a given cytoscape selector statement.

{
    "name": "vpm-structure",
    "type": "filter",
    "statement": "[type='VPMInstance'],[type='VPMReference']"
}

Nodes

Filters out all nodes matching a given cytoscape selector statement.

{
    "name": "vpm-instances",
    "type": "nodes",
    "statement": "[type='VPMInstance']"
}

Edges

Filters out all edges matching a given cytoscape selector statement.

{
    "name": "vpm-references",
    "type": "edges",
    "statement": "[type='VPMReference']"
}

Successors

Fully expands all eles in the collection recursively then applies a given cytoscape selector statement on the result set of both edges and nodes.

{
    "name": "vpm-structure",
    "type": "successors",
    "statement": "[type='VPMReference'],[type='VPMInstance']"
}

Predecessors

Fully expands all eles in the collection recursively in the upwards direction (where used) then applies a given cytoscape selector statement on the result set of both edges and nodes.

{
    "name": "vpm-parent-structure",
    "type": "predecessors",
    "statement": "[type='VPMReference'],[type='VPMInstance']"
}

Sources

Gets the source nodes connected with the edges of the collection then applies a given cytoscape selector statement on the result set.

{
    "name": "vpm-parent-nodes",
    "type": "sources",
    "statement": "[type='VPMReference']"
}

Targets

Gets the target nodes connected with the edges of the collection then applies a given cytoscape selector statement on the result set.

{
    "name": "vpm-child-nodes",
    "type": "targets",
    "statement": "[type='VPMReference']"
}

Outgoers

Get edges and their target nodes coming out of the nodes in the collection, then applies a given cytoscape selector statement on the result set.

{
    "name": "vpm-children",
    "type": "outgoers",
    "statement": "[type='VPMReference'],[type='VPMInstance']"
}

Incomers

Get edges and their source nodes coming in to the nodes in the collection, then applies a given cytoscape selector statement on the result set.

{
    "name": "vpm-parents",
    "type": "incomers",
    "statement": "[type='VPMReference'],[type='VPMInstance']"
}

Roots

Get nodes with no incoming edges in the collection, then applies a given cytoscape selector statement on the result set.

{
    "name": "vpm-true-roots",
    "type": "roots",
    "statement": "[type='VPMReference']"
}

Leaves

Get nodes with no outgoing edges in the collection, then applies a given cytoscape selector statement on the result set.

{
    "name": "vpm-true-leaves",
    "type": "leaves",
    "statement": "[type='VPMReference']"
}

Service

Services are configured globally and independently from each UI component, please refer to Concept & cytoscape.jsfor better understanding of the high level solution and how services fits the overall picture.

Transformer

To populate the client data store (graph), a transformer is applied. The transformer parses the service response payload into nodes and edges and populates the graph data store. To facilitate standard and documented services, built-in transformers are included. It is possible to register you own transformers to parse any undocumented or external service into the data store, and use the UI components just as usual for any data. See https://technia.jira.com/wiki/spaces/WAAS/pages/4151148639/Widget+definition+administration#Code-Resources for detail on how to deploy plugin code. Refer to https://technia.jira.com/wiki/spaces/WAAS/pages/4151017680/Plugin+code+extensions#Transformer for transformer coding details. To use an extension point it out in your widget definition https://technia.jira.com/wiki/spaces/WAAS/pages/3985244652/Product+Documentation#Widget.

The framework comes with several built-in transformers.

Built-in transformers

3DEXPERIENCE Services

Best practice is using the documented and supported services listed on Dassault Systèmes Developer Assistance (3ds.com). Widget configuration based on documented services is most stable over time and require the least possible maintenance.

There are other undocumented platform services used by many of the OOTB Widget apps. Using such service could be beneficial and enable better performance or other capabilities, with the risk of change and more maintenance over time. It is possible to configure such services, often a custom transformer plugin is required to parse the data to the data store (graph).

Authentication

All service calls uses the 3DEXPERIENCE platform authenticated API’s.

Chained services

It is quite common that data is a combination of multiple chained services e.g. first call a service get all the instances (relationships), then based on that result get all references (objects). To chain services use the services property. A chained service will use the eles that the transformer of the parent service returns.

Macros

All service configuration support macros. A macros is typically a physical id or similar. A macro is identified with double curly brackets e.g. {{contextId}}.

Service configuration

{
    "name": "example1",
    "uri": "/resources/v1/modeler/dseng/dseng:EngItem/{{contextId}}/dslc:changeControl",
    "transformer": "relatedChange",
    "relationType": "controllingChange",
    "services": ["changeAction"]
}

{
    "name": "example2",
    "uri": "/resources/enorelnav/navigate/getecosystem?tenant=OnPremise",
    "transformer": "customEcoSystem",
    "relationType": "example",
    "method": "POST",
    "payload": {
        "debug": false,
        "ecoSystemWithDetail": true,
        "id": "{{contextId}}",
        "widgetId": "a-widget-id"
    }
}

Table

The table component is a highly configurable, feature rich and navigable data grid. It allows for presentation of data in many different ways, and it is often possible fulfil business requests, just by configuration. The table implements the common framework concept and uses https://js.cytoscape.org/#cy.data eles data select keys to configure data into cells. Read Concept & cytoscape.js to learn more about the high level concept.

• Advanced implementations

• Table

  • Expand

• Column

  • Column data

  • Column Settings

    • Cell renderer props

    • Date format options

    • Number format

  • Column types

Advanced implementations

The table component allows advanced implementations such as custom rendering or data calculations using the plugin architecture. Lear more about plugins in Plugin code extensions.

Table

{
    "name": "example",
    "datasets": ["rootNodesInitalLoadData"],
    "columns": [
        "title",
        "owner",
        "state",
        "DEFAULT_SEPARATOR",
        "related_docs"
    ],
    "services": ["initialLoadService"],
    "expand": {
        "services": ["expandService"],
        "datasets": ["expandData"]
    }
}

Expand

Column

The column definition controls the specifics of each cell.

{
    "name": "columnExample",
    "label": "Title",
    "data": "title",
    "href": "ups-whereused-drill",
    "settings": {
        "cellRenderer": "AUTO_COLOR_RENDERER"
    }
}

{
    "name": "relatedDataColumnExample",
    "label": "Documents",
    "data": {
        "datasets": ["relatedDocs"],
        "select": "title"
    },
    "services": ["relatedDocs"],
    "settings": {
        "usesAlternateOid": true
    }
}

Column data

Column Settings

Cell renderer props

Date format options

Number format

Column types

Built in …

Plugin code extensions

To enable custom logic (e.g. calculated values) the framework comes with a plugin architecture.

TODO