Platform administration

The Platform Administration section provides control over the main runtime components of IoTRoutes.
It allows administrators to supervise system servers, manage communication brokers, control caching, and access live API documentation.

The Platform Administration menu includes the following items:

1- Application servers

The Application Servers section lists all AOS instances currently registered in the platform.
Each server hosts one or more services (data processing, workflows, API, UI gateway) depending on its assigned roles.

Administrators can:

• View status and roles of each AOS
• Enable or disable specific roles
• Check health indicators

By clicking the actions button for a row in the table, the following context menu 

is displayed to give the user the power to enable or disable processing services for a given AOS. This allows loads to be distributed across the platform's various servers, allowing servers to be reserved for workers, servers for jobs, and servers to interact with client applications.  When the server is not marked as a Batch server, it never runs any workflows or scheduled tasks.

2- MQTT Brokers

IoTRoutes brokers are based on the MQTTnet framework — a high-performance, .NET-native MQTT implementation fully integrated with the AOS runtime.

Brokers handle all device communication, message acquisition, and data routing toward the processing pipeline.

The MQTT Servers menu, shown in this screenshot, provides access to the list of MQTT brokers installed on each AOS. Clicking the "Generate New" button brings up a screen allowing the administrator to create a new broker and select the server on which it will run. A new port is assigned automatically. For on-premise platforms, the port range is reserved when configuring the AOS in the MQTTEndPoints.json file. (see On-premise deployment)  .

By clicking on a broker, the detail screen is displayed allowing the administrator to adjust the parameters and options related to the operation of the broker..

Among the modifiable parameters we find:

• Endpoint Configuration
  Defines the network access information for the broker, such as IP address, domain name, and listening port.
  These parameters determine how IoT devices connect to the platform.

• Authentication (Login / Password)
  Credentials used by MQTT clients (devices or gateways) to authenticate with the broker.
  Administrators can update these credentials to enforce stronger access control policies.

• Encryption (TLS / X.509 Certificates)
  Option to enable TLS encryption using X.509 certificates, ensuring secure transmission of all MQTT messages between devices and the platform.

• Device Approval Policy
  Specifies whether newly registered devices are allowed to publish messages immediately or must first be approved by an administrator before communication is accepted.

  Triggered workflows can be used to notify user to approve pending devices.

• Topic Structure Enforcement
  Defines the minimum topic hierarchy that devices must follow when publishing messages.
  This ensures consistent topic organization across all tenants and prevents misrouted or malformed topics.

• Message Queue Processing Frequency
  Sets the maximum delay (in seconds) that a message can remain in the broker’s internal queue before being processed in batch jobs.
  This parameter helps balance throughput and latency for high-volume message handling.

3- Server Cache

The Server Cache section provides control over runtime caching for the platform configuration.

By default, IoTRoutes caches various settings and runtime metadata for performance optimization.
This includes:

• Application settings

• Device profiles and templates

• Broker parameters

• Workflow definitions

Administrators can manually clear the server cache using this option.
Clearing the cache forces all AOS nodes to reload configuration from the database immediately — instead of waiting for the periodic automatic refresh.

⚙️ The automatic cache refresh interval is defined in the Application Settings configuration parameters.

Use case:
When an administrator updates a configuration (e.g., device template or workflow) and wants the system to apply changes instantly across all nodes.

4- Server APIs

The Server API menu provides a quick, integrated way to view and test IoTRoutes REST APIs directly within the application.

This section embeds the Swagger UI of the currently connected server inside an application frame.
It allows administrators and developers to:

• Explore available API endpoints.

• Review input and output schemas.

• Execute test requests directly within the interface.

Next : System administration