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

Start ithe import wizard by clicking the Import module button

### **Step 1 – Select Registry**

Select Container Registry to import from

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](/management-portal/platform-settings/container-registries.md) 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** {% hint style="info" %} The 'Select Repository' step below, is only available if you selected a Platform Registry (Azure Container Registry) in Step 1. {% endhint %}

Select the Reposity to import from

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** {% hint style="info" %} The 'Select Version' step below, is only available if you selected a Platform Repository (Azure Container Registry) in Step 1. {% endhint %}

Select the Version to import

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.

Tip: If there are many versions, you can use the Limit and Refresh or Search box to limit amount of versions shown

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

Provide Metadata information for the Module

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 ](/management-portal/designer/assets/data-connectors.md)modules can be configured on an [area](/management-portal/designer/assets/asset-hierarchies/areas.md) 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](/management-portal/designer/assets/asset-hierarchies/assets.md) in an [asset hierarchy](/management-portal/designer/assets/asset-hierarchies.md). * **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)**

Example of importing MySQL Docker Container from DockerHub as Module in Nexus

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:\ \ \/\: \-\\ \ Here are some valid examples:\ `grafana/grafana:11.4.0-ubuntu` * `apache/kafka:3.9.0` `timescale/timescaledb:2.17.2-pg16` {% hint style="warning" %} Please avoid using any Tag that references the "latest" version of a docker module, example grafana/grafana:**latest**-ubuntu.\ The nexus platform will not be able to track the exact version being deployed to devices, and therefore a module\ with the latest tag cannot be updated using the [Update Center](/management-portal/management/update-center.md). {% endhint %} * **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 ](/management-portal/designer/assets/data-connectors.md)modules can be configured on an [area](/management-portal/designer/assets/asset-hierarchies/areas.md) 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](/management-portal/designer/assets/asset-hierarchies/assets.md) in an [asset hierarchy](/management-portal/designer/assets/asset-hierarchies.md). * **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**

Example of setting Parameters required by a Custom Module called 'qualitymodule'

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](/management-portal/operations/monitoring/module-details/twin.md), 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. {% hint style="info" %} When a Parameter has the type "Secret" any information entrered here will be encrypted and stored in a secure keyvault. When a deployment is made, the secret will be retrieved from the keyvault. {% endhint %} * **Name** – The Name that the parameter will get in the Twin or Environment Variable.

Example of setting the environment variables expected by MySQL Docker Container as Parameters

* **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](/management-portal/designer/applications.md) or by a [Device Configuration](/management-portal/management/device-configuration.md). * Parameters can be marked as *Required* and exposed to either **Environment Variables (Env)** or **Digital Twin (Twin)**. *** ### **Step 6a – Preview & Confirm (Platform Registry)**

Preview the Module Card and its Settings (Parameters)

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.

Quality Module has been successfully imported

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

Preview Tab for a public docker module

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.

The public Docker module was successfully imported

*** ### Next Steps After Import Once a module is imported: * It will appear in the [Module Store](/management-portal/designer/modules/module-store.md) with its metadata. * You can define additional [Module Settings](/management-portal/designer/modules/module-settings.md) to fine-tune behavior * The module can be used as part of an [Application](/management-portal/designer/applications.md) * You can use the Import new version wizrd, to [import new versions for the module](/management-portal/designer/modules/import-new-version-of-module.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tricloudnexus.io/management-portal/designer/modules/import-a-new-module.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.