OmniWeb Architecture

This page explains how OmniWeb is put together and how a single browser session reaches every network function, Grafana, and Loki. If you only read one page to understand the system, read this one.

← Back to Operations Guide

Components

OmniWeb has three moving parts:

Component	Role
Frontend SPA	The user interface. A single-page web application that renders element pages, topology, logs, traces, and embedded dashboards.
Backend	The security and integration layer. It authenticates users, enforces RBAC, and reverse-proxies every request to the correct element API, Loki, or Grafana.
Targets	The things being managed and observed: the network elements' own management APIs, plus Grafana, Loki, and Homer.

Request Flow

Every operational request follows the same path. Nothing in the browser talks to an element directly — it always goes through the backend so that authentication, authorisation, and auditing are enforced centrally.

The proxy path encodes the instance ID, so OmniWeb can manage many instances of the same element type (e.g. several HSS nodes) and route each request to the right backend.

The Configuration Model

OmniWeb is configuration-driven. The set of elements, their instances, and where their APIs live is declared in a single file: public/config/omniweb.json. The backend loads it at startup and the frontend uses it to build the sidebar, topology, and proxy targets.

{
  "elements": [
    {
      "type": "hss",
      "displayName": "HSS",
      "description": "Home Subscriber Server",
      "instances": [
        {
          "id": "my-hss-01",
          "name": "my-hss-01",
          "baseUrl": "https://10.0.0.1:8443",
          "tags": ["primary"]
        }
      ],
      "defaults": {
        "pollIntervalMs": 5000,
        "timeoutMs": 10000
      }
    }
  ]
}

Parameter	Type	Required	Default	Description
type	String	Yes	-	Element type. Determines which UI module renders the element. See supported types.
displayName	String	Yes	-	Human-readable name shown in the sidebar and topology.
description	String	No	-	Longer description shown in tooltips and overview pages.
instances	List	Yes	-	One entry per deployed node of this type. See instance parameters below.
defaults.pollIntervalMs	Integer	No	5000	How often operational pages auto-refresh, in milliseconds.
defaults.timeoutMs	Integer	No	10000	Proxy timeout for this element type. Slow APIs (e.g. OCS) use a larger value.

Instance parameters:

Parameter	Type	Required	Default	Description
id	String	Yes	-	Unique instance identifier. Used in URLs (/hss/<id>) and in the proxy path (/proxy/<id>/...).
name	String	Yes	-	Display name for the instance.
baseUrl	String	Yes	-	The element's management API base URL. The proxy forwards requests here. Self-signed TLS is accepted.
tags	List	No	[]	Free-form labels (e.g. primary, geo-redundant) shown as chips.

Supported Element Types

hss, mme, sgw-c, pgw-c, upf, pcscf, icscf, scscf, tas, epdg, entitlement, smsc, smsc-smpp, ipsmgw, msc, stp, hlr, camel-gw, dra, ocs, twag, ran-monitor, license.

Each type maps to a UI module with its own set of tabs, but all are operated through the same generic patterns — see Common Operations.

How OmniWeb Talks to Each NF

The backend proxy is element-agnostic — it forwards whatever the frontend module asks for to the element's baseUrl. The shape of those calls depends on the element's native API:

API style	Elements	Notes
Element API	All network functions	The element's own management API, proxied verbatim under /proxy/<instance-id>/.... OmniWeb forwards GET/POST/PUT/PATCH/DELETE as the element expects; the request/response shape is whatever that element defines.
Log query (LogQL)	All (Logs tab)	Routed through /proxy/loki/... to Loki. See Logs & Tracing.

Because everything is proxied, adding an instance is purely a configuration change in omniweb.json — no code change is required to manage another node.

API reference (OpenAPI)

A consolidated OpenAPI/Swagger document (swagger-doc.json) ships with OmniWeb and describes the backend and element schemas (for example SMSC frontend registrations and IMS subscriber locations). It is a reference artifact rather than a live API server.

Proxy Timeouts

Each element type has a configurable proxy timeout (defaults.timeoutMs). Most elements respond well within the 10-second default. Elements with heavier queries are given more headroom:

Element	Default Timeout	Why
Most elements	10 seconds	Standard API response time
OCS	180 seconds	Rating/CDR queries over large datasets

Monitoring Integration

OmniWeb does not reimplement Grafana, Loki, or Homer — it integrates them so a single login spans the whole stack:

• Grafana is served behind the authenticated gateway and embedded as an iframe. Each request is authorised against your OmniWeb login, so there is no second password. See Grafana.
• Loki is reached through the backend's /proxy/loki/* gateway, which runs LogQL queries on the operator's behalf. See Logs & Tracing.
• Homer (SIP capture) is auto-detected at startup (/api/homer/status) and, when present, opens in a new tab — also authorised against your OmniWeb login.

Environment Reference

Backend integration endpoints are configured via environment variables:

Variable	Default	Description
GRAFANA_URL	http://localhost:3000	Base URL of the Grafana instance OmniWeb proxies to.
LOKI_URL	http://localhost:3100	Base URL of the Loki instance used for logs and tracing.
LDAP_URI	ldap://localhost:389	OpenLDAP server for user/SSH-key sync (optional).
LDAP_BASE_DN	dc=omniweb,dc=local	LDAP base DN.
LDAP_ADMIN_DN	cn=admin,dc=omniweb,dc=local	Bind DN for LDAP writes.
LDAP_ADMIN_PASSWORD	omniweb-admin	LDAP bind password (change this).
AUDIT_API_KEY	omniweb-audit-key	Shared secret for SSH-login audit callbacks (change this).

See Authentication & Access Control for the LDAP/SSH and audit details.