Skip to main content
Version: 2.4

2.4.x - April 2023

We are excited to announce the release of version 2.4.0 of platform. This update includes several new features and improvements that enhance user experience and developer’s efficiency. Here are some of the key updates:

🧩 Components version / Dependencies​

  • Olympe DRAW v2.4.0 / CODE v9.4.0 / Orchestrator v7.1.0

If you are using coded bricks, see the corresponding package.json updates below.

Major Features​

  • Refactoring tools: When creating and editing bricks, functions, actions or visual component, it is now possible to select objects and manipulate them easily:

    • Move multiple components
    • Copy - paste / duplicate / delete selection
    • Promote/Factorise selection of bricks and optionally replace it with the promoted brick;

    new

  • Global search: Open a search bar anywhere in your project and look for any use of a component to then jump to the usage. That search feature also look for static string in any function, for example set as input of bricks. Use the keyboard shortcut CTRL + ⇧ + F (Windows / Linux) or ⌘ + ⇧ + F (Mac) or click on the search bar on the top right of Draw interface to open the search bar.

    new

  • Multi data sources support: A new kind of brick is available from the marketplace: DB Connector. It allows the developers to create connectors between the Olympe Data Cloud API and any kind of data source. A connector to PostgreSQL databases has been implemented and is available on @olympeio/core package. DB Connectors are use in service apps to create Data Sources. In the project spec&doc editor, it is then possible to define the default data source to be used for user Data Types and/or select the data source by data type. Learn how to use here.

    new

Improvements and other new features​

  • Support of the latest NodeJS versions (≥ 18): Olympe now requires at least NodeJS 18 to run. This allows developers to use the latest JS language standards (ecmascript 2022). CI/CD pipelines as well as running environments are now based on latest NodeJS LTS version.

  • SQL Connector reviewed: the original SQL Connector was a beta version to test the principles, only available for specific instances. Now it has been made available for anybody that want to store business data in SQL database instead of the embedded graph database, where the compositions (code as data) is already stored. However, it requires some changes in the configurations:

    • Refer to the Use a second data source page to know how to configure the environment properly.

The SQL Connector is compatible with inheritance and handle workflows.

  • Data Types vs Config Data Types: We have separated classical data types from config data types. Both can be created in Draw, but have different purpose:
    • Data types: user defined data types created in Data Model folders, used in applications as the definitions of business data. They can be manipulated by the applications’ users. Those data types can be associated to a specific data source (e.g.: SQL Connector) to be stored elsewhere than the application compositions (code as data). Objects of these types can be explored and updated using the *Runtime Data Set* tab of your projects.
    • Config data types: user defined data types created in Config Data Model folders, mainly designed to be used in bricks to make them configurable (e.g.: Core library defines the Theme config data type, used by visual components to be themed). Instances of config data types are manipulated from Draw only and stored in Config Data Set. They are considered are part of the code of your projects (part of code as data), therefore the user cannot change data sources of these data types.
  • Code as data cache for production: it is now possible to configure the production environments to make the runtime loading code as data from browser cache or Nginx cache using the sc.production: true parameter in the oConfig.json. It uses the application version coming from version.json file loaded by the runtime.
tip

You must configure the application builder (i.e., webpack) to update the version number when deploying a new version of the application.

  • Dependency checks improved: Copy and Move of items from a project to another place (e.g.: other project) will lead to a check of dependencies first. It will prevent the user to move items to a destination place where that component should not have been created.
  • Data Set editor reviewed:
    • Runtime data set compatible with any data sources created from a DB Connector
    • Pagination instead of displaying all the instances
    • Sort of rows by property
    • New interface to link instances together + handle inheritance
    • Config data sets: now possible to filter out data types with no instance in that folder from the left-side column.
  • Keyboard Tabulation in forms fixed: when building forms, it is now possible to switch from one form item to the next one using the TAB key properly. By default, it follows the order of the components as declared in the Visual Editor in Draw.
  • Copy tag simplified: Everywhere tags of items were accessible in Draw, it is now possible to copy it to the clipboard with a simple click.
  • Improvements on Query class:
    • back() method to create non-linear queries.
    • static followRule() method to make implicit queries that follow the rules of the relations. This is useful when we need to do operations on the code as data.
    • The data source is automatically set when building a query, based on the data type of the query’s root object.
  • Retrieve the full user token: The brick Get User Token from Core as well as the public API Auth.getUserToken() method has been updated to return the full user token, not only the Olympe nonce. This simplifies the access to user information and resource access token when using an SSO, especially OAuth2.
  • FontAwesome fonts updated: FontAwesomeSolid and FontAwesomeRegular are now updated to version 6.3.0
  • Local dev simplified: when using local code with dev servers, there is no need to override all the server and bus parameters, default values are new dynamic and based on server.host value. Example: https://localhost:8888/?server.host=test.olympe.io will use your local code and connect to the environment test.olympe.io and to the bus with the test vhost.

New bricks​

  • Core includes additional bricks to create queries, compatible with any data source:
    • Query Object
    • Query Filter Equals Null
    • Query Filter Contains
    • Query Filter Regexp
    • Query Follow Back
    • Query Filter In
  • New Kafka library: set of bricks to connect to a Kafka bus and stream messages and push messages from/to the bus.
  • New Rabbitmq library: set of bricks to connect to a RabbitMQ bus to stream of push messages from/to the bus.
  • Azure calendar bricks: bricks to handle calendar data based on the Microsoft Azure Graph API.

Brick deprecation​

  • Original Get Object List brick has been deprecated and should be replaced either by the new Get Object List of Fetch Object List . New bricks both use queries instead of the old ListDef API and give the opportunity to the developer to choose if he needs a subscription to data or not.
  • Bricks related to ListDefs have been deprecated too. Please check their documentation to know which brick to use instead:
    • Get Related Objects and Get Recursive Related
    • List Follow Relation and List Follow Relation Recusively

Breaking changes​

  • DRAW behavior
    • Config Data Sets (previously named Static Data Folders) cannot contain business data anymore (i.e.: instances of Data Types).
  • CODE API
    • RelatedTo predicate used in Query has been deleted. It should be replaced by a path in the query, ended by a filter(Predicate.in(<destination>).
  • Deployed projects configuration
    • Add empty string value for "bus.path": "" in oConfig.json of your backend deployed on Olympe infrastructure.
    • Coming with the update of knex to 2.4.2, the webpack config must be updated: change the name @vscode/sqlite3 to sqlite3 in the config of the IgnorePlugin.

CODE update​

If you are using coded bricks, please update your package.json file with the following dependencies:

// Dev dependencies:
"@olympeio/dev-tools": "2.4.0",
"@olympeio/draw": "2.4.0",

// Dependencies
"@olympeio/runtime-web": "9.4.0",
"@olympeio/runtime-node": "9.4.0",
"@olympeio/core": "2.4.0"

Other dependencies updates​

We have updated some dependencies packages used in version 2.4.0 of the platform. These updates include:

// RxJS used in the Olympe API to be event driven
rxjs: 7.8.0

// Used for SQL Connector mainly
knex: 2.4.2
pg: 8.10.0

// For MUI visual components
@mui/material: 5.11.13
@mui/styles: 5.11.13

Review these updates and make any necessary changes to your code to ensure compatibility with the new versions.

Without being mandatory, we also highly recommend to update DevDependencies of your projects with the following versions:

// Babel dependencies (JSX compilation)
@babel/core: 7.21.4
@babel/preset-env: 7.21.4
@babel/preset-react: 7.18.6
babel-loader: 9.1.2

// Webpack and plugins
clean-webpack-plugin: 4.0.0
copy-webpack-plugin: 11.0.0
generate-json-webpack-plugin: 2.0.0
source-map-loader: 4.0.1
webpack: 5.80.0
webpack-cli: 5.0.2
webpack-dev-server: 4.13.3
webpack-import-glob-loader: 1.6.3
webpack-merge: 5.8.0
webpack-node-externals: 3.0.0

// Jasmine and Karma for unit tests
jasmine: 4.5.0
karma-jasmine: 5.1.0
karma-webpack: 5.0.0
karma: 6.4.1
karma-chrome-launcher: 3.1.1
karma-spec-reporter: 0.0.36

// Typescript compiler
ts-loader: 9.4.2
typescript: 5.0.2

Migration guide for on premise deployments​

Upgrading the instance​

In order to use the smooth upgrade pipeline, you will have to take care of these:

  1. Update the gitlab-ci.yaml of the upgrade branch to support run Node18.
  2. In the upgrade-config.json file, ensure that you specify the right upgradeTooling image: lts-bullseye

Fix the oConfig of service apps (backends)​

For each service app deployed on the Olympe infrastructure, ensure that the bus.path entry of the oConfig is defined to "" (empty string).

Indeed, the default value of that parameter is based on the bus[.](http://server.host)host value. If it is different than [localhost](http://localhost) it takes the value /mqtt .

Configuration of the SQL Connector​

The backend in charge of running the SQL Connector must have the following configuration in its oConfig.json file:

{
  "data.<data_source_name>": {
    "host": "<db_host>",
    "port": <db_port>,
    "user": "<db_user>",
    "password": "<db_password>",
    "database": "<db_name>",
    "schema": "<sql_schema>"
  }
}

Multi-backends configuration for SQL Connector​

If you have multiple backends that use the same SQL Connector, for example:

  • mainBackend with data.<data_source_name> configured
  • secondaryBackend which will query on the source <data_source_name>

You need to add these lines in the oConfig.json file of secondaryBackend:

{
  "data": {
    "<data_source_name>": {
      "httpHost": "<namespace>-mainBackend",
      "httpPort": 3141,
      "httpSSL": false
    }
  }
}

Deprecated parameters​

The following parameters from oConfigs are not used anymore:

- composer.defaultBackend
- composer.useDBConnector

Config Data Types automatically upgraded​

The migration automatically transformed some data types into Config Data Types. This decision is made by the engine by checking if there exist instances of the data types in Config Data Set or not. It there exists some, then it considers that this data type must be migrated to a Config Data Type.

caution

Ensure that all data types linked with relations have the same nature (data types / config data types) !

If the automatic decision was wrong, here are the Neo4j Cypher queries to change them back:

  • Config Data Type ⇒ Data Type:
MATCH (dt:I {t: '<config_data_type_tag>'}), (dm:I {t: '<data_model_tag>'}), (dt)<-[containsRel:`ff02200000000000000f`]-(), (dt)<-[itemRel:`016a697ef00ce7554692`]-(), (dataType:I {t: '016324fde11a836f76c2'}), (dt)-[modelRel:`ff022000000000000000`]->(), (dt)-[configProjectRel:`016324fde11a836088d3`]->(project:I)
CREATE (dm)-[:`016a697ef00ce7554692`]->(dt), (dm)-[:`ff02200000000000000f`]->(dt), (dt)-[:`ff022000000000000000`]->(dataType), (dt)-[:`016324fde11a836087c2`]->(project)
DELETE containsRel, itemRel, modelRel, configProjectRel
RETURN dt, dm

Replace <config_data_type_tag> with the tag of the config data type to change and <data_model_tag> with the tag of the data model where to move the data type.

In case you had static data set containing instances of config data types that you are willing to change to data types, please also run the following cypher query to move them out of the config data set and put them into the runtime data set:

MATCH (dt:I {t: '<config_data_type_tag>'}), (dataset:I {t: '<config_data_set_tag>'}), 
(dt)<-[:`ff022000000000000000`]-(idt:I)<-[dataRel:`017ed8ac775f48d4d589`]-(dataset), (dt)-[:`016324fde11a836088d3`]->(project)<-[:`017b3aa8fd1659291b92`]-(businessContainer),
(idt:I)<-[primordialRel:`ff02200000000000002a`]-(),
(idt:I)<-[containsRel:`ff02200000000000000f`]-()
DELETE dataRel, primordialRel, containsRel
CREATE (idt)<-[:`017b3aa8fe7ec3fd52f2`]-(businessContainer) 
RETURN businessContainer

Replace <config_data_type_tag> with the tag of the config data type that is to change to a data type and <config_data_set_tag> with the tag of the data set from which move the instances.

  • Data Type ⇒ Config Data Type:
MATCH (cdt:I {t: '<data_type_tag>'}), (cdm:I {t: '<config_data_model_tag>'}), (cdt)<-[containsRel:`ff02200000000000000f`]-(), (cdt)<-[itemRel:`016a697ef00ce7554692`]-(), (dataType:I {t: '016324fde11a836f77d3'}), (cdt)-[modelRel:`ff022000000000000000`]->(), (cdt)-[dataTypeProjectRel:`016324fde11a836087c2`]->(project:I)
CREATE (cdm)-[:`016a697ef00ce7554692`]->(cdt), (cdm)-[:`ff02200000000000000f`]->(cdt), (cdt)-[:`ff022000000000000000`]->(dataType), (cdt)-[:`016324fde11a836088d3`]->(project)
DELETE containsRel, itemRel, modelRel, dataTypeProjectRel
RETURN cdt, cdm

Replace <data_type_tag> with the tag of the config data type to change and <config_data_model_tag> with the tag of the data model where to move the data type.