Import a new Module

The Import Module wizard allows you to bring in new modules from internal or external container registries. Since modules are essentially Docker containers, they can come from public registries (such as Docker Hub), or your own internal container registry. This enables you to easily extend the Nexus platform with custom functionality, analytics, or third-party services.

Step-by-Step: Import New Module Wizard

To import a new Module into the Nexus Module store, you must naviagte to teh Module Store and click the Import Module button.

Step 1 – Select Registry

Choose the registry where the module is stored. Options include:

• Platform Registry– Internal Nexus docker registry for exsisting available modules. All Docker Registries configured in Platform Settings are listed as available options.

• Public Docker Regsitry – Any publicly available Docker Hub image.

• Custom Registry (+) – Add your own container registry (Currently only Azure Container Registry is supported)

Step 2 – Select Repository

Browse and select the repository that contains your desired module.

• A Container Registry can contain thousands of Docker containers stored in Repositories. You must select the Repository (Image name) to import from.

• For example, choosing qualitymodel repository will prepare the import of that specific container.

Step 3 – Select Version

Pick the Version (Docker Tag) of the module you want to import.

• Each docker repository can contain multiple versions of the docker image (or module). You must select the version you want to import.

• Select the version to import by checking the module version. This ensures you control exactly which release (e.g., 2.1.0-rc-1) is brought into Nexus.

Step 4a – Define Specifications (Platform Registry)

Under Specifications Tab, you must provide metadata to describe your module:

• Module Name & Description – Human-readable details for easier identification.

• Image Tag – Pre-filled based on the selected repository and version.

• Vendor – Define the provider of the module.

• Category – Classify the category and defining the functional purpose of the module.

  • General Module - General modules category includes modules that extend the functionality like third party containers imported from docker hub or other repositories. General modules can provide miscellaneous functionalities such as data transformation, custom analytics, or device management features tailored to specific use cases.

  • Nexus Data Connector - Nexus data connector modules are responsible for collecting data from various sensors, devices, or external systems in the field. They acquire, preprocess, and transmit data to the edge or cloud for further processing and analysis. Nexus data connector modules can be configured on an area in a hierarchy.

  • Hub/Orchestrator - Hub/Orchestrator modules act as a central point of communication and coordination between different edge modules. They manage the flow of data and control between modules, ensuring proper execution of tasks and overall system performance. Examples of such modules are MQTT Broker, Kafka or NodeRed.

  • Data Storage - Data Storage modules provide local storage capabilities on the edge device. They store the data collected from data connector modules for short or long term retention, enabling faster data access and reducing data transfer costs to the cloud. Examples of such modules are SQLServer, BlobStorage, RedisCache etc.

  • Analytical Model - Analytical modules can contain analytical models (machine learning, AI models or other types) that have been trained in the cloud or on-premises. They perform inferencing or predictions on the edge device, making real-time decisions based on the data collected by Nexus data connector modules. Models can be configured on an asset in an asset hierarchy.

• Logo – Upload a logo to visually identify the module in the store, or set a URL to a logo online. If you do set a logo the container will get a default logo.

• Nexus SDK – Enable this if the module has been implemented using Nexus SDK to unlock advanced features such as commands, logs capture and streaming of logs.

Step 4b – Define Specifications (Public Docker Registry)

Under Specifications Tab, you must provide metadata to describe your module:

• Module Name & Description – Human-readable details for easier identification.

• Image Tag – Enter the Image Tag as it appears on the public docker repository. Please use Image Tags that uses a specific version of the docker image. In most cases the Image tag has the following form: <repository_name>/<container_name>: <version_info>-<additional_tag> Here are some valid examples: grafana/grafana:11.4.0-ubuntu

  • apache/kafka:3.9.0

    timescale/timescaledb:2.17.2-pg16

• Vendor – Define the provider of the module.

• Category – Classify the category and defining the functional purpose of the module.

  • General Module - General modules category includes modules that extend the functionality like third party containers imported from docker hub or other repositories. General modules can provide miscellaneous functionalities such as data transformation, custom analytics, or device management features tailored to specific use cases.

  • Nexus Data Connector - Nexus data connector modules are responsible for collecting data from various sensors, devices, or external systems in the field. They acquire, preprocess, and transmit data to the edge or cloud for further processing and analysis. Nexus data connector modules can be configured on an area in a hierarchy.

  • Hub/Orchestrator - Hub/Orchestrator modules act as a central point of communication and coordination between different edge modules. They manage the flow of data and control between modules, ensuring proper execution of tasks and overall system performance. Examples of such modules are MQTT Broker, Kafka or NodeRed.

  • Data Storage - Data Storage modules provide local storage capabilities on the edge device. They store the data collected from data connector modules for short or long term retention, enabling faster data access and reducing data transfer costs to the cloud. Examples of such modules are SQLServer, BlobStorage, RedisCache etc.

  • Analytical Model - Analytical modules can contain analytical models (machine learning, AI models or other types) that have been trained in the cloud or on-premises. They perform inferencing or predictions on the edge device, making real-time decisions based on the data collected by Nexus data connector modules. Models can be configured on an asset in an asset hierarchy.

• Logo – Upload a logo to visually identify the module in the store, or set a URL to a logo online. If you do set a logo the container will get a default logo.

• Nexus SDK – Enable this if the module has been implemented using Nexus SDK to unlock advanced features such as commands, logs capture and streaming of logs. Usually this setting would be false for public docker containers.

Step 5 – Configure Parameters

Nearly any application requires some sort of configuration to be able to run. This is no different to Modules or Containers. The Parameters Tab allows you to specify the Configuration required by the module, and even set default values for these settings. In Nexus Module Parameters can be provided in 2 ways:

• Twin - The configuration parameter is set in the Twin of the module, and provided at module startup as a Twin.

• Environment (Variables) - The configuration parameter is stored as an environment variable, and can be accessed by th Module or container as such.

Example of Parameters include Database connection string, activation date, link to dashboard, detection mode, etc. You can define configurable parameters by click the Add Parameter button and specifying the following properties for each parameter:

• Parameter Type – Specify the type of the parameter e.g. String, Int, Decimal, Bool, DateTime, Uri(URL), Secret, SingleSelect, MultiSelect, List.

• Name – The Name that the parameter will get in the Twin or Environment Variable.

• Display Name - User friendly name of the parameter, only used in Nexus to provide better context for users.

• Default Value - Optionally specify a default value for the Parameter. This value will be used, if the Paramter value is not changed when the module is used as an Application or by a Device Configuration.

• Parameters can be marked as Required and exposed to either Environment Variables (Env) or Digital Twin (Twin).

Step 6a – Preview & Confirm (Platform Registry)

On the last page of the Import wizard, you can review all the information you have provided in the previous steps.

Review the full configuration before finalizing:

• Module details (name, description, type, category, location). This is shown as the Module Card would appear in the Module Store.

• Configured parameters with default values. This is shown as the UI for configuring the Module would appear elsewhere in Nexus.

Once confirmed, click Done to import the module into the Nexus Module Store.

Step 6b – Preview & Confirm (Public Docker Registry)

On the last page of the Import wizard, you can review all the information you have provided in the previous steps.

Review the full configuration before finalizing:

• Module details (name, description, type, category, location). This is shown as the Module Card would appear in the Module Store.

• Configured parameters with default values. This is shown as the UI for configuring the Module would appear elsewhere in Nexus.

Once confirmed, click Done to import the module into the Nexus Module Store.

Next Steps After Import

Once a module is imported:

• It will appear in the Module Store with its metadata.

• You can define additional Module Settings to fine-tune behavior

• The module can be used as part of an Application

• You can use the Import new version wizrd, to import new versions for the module