Gateway administration
This section is for the people who run a gateway: administrators, and the engineers who set up what runs on it. It describes the administration pages of the dashboard, the role each one needs, and the API behind each.
The Gateway area
The dashboard's rail is grouped by domain. Administration lives in the Gateway area at its foot, which only administrators see, plus a few admin-only entries in other areas:
| Area | Entry | Page |
|---|---|---|
| Gateway | Diagnostics | Logs and diagnostics |
| Gateway | Clients | Clients |
| Gateway › System | Gateway settings, Project | Settings |
| Gateway › System | Modules | Modules |
| Gateway › System | Modes | Modes |
| Gateway › System | Storage | Databases and storage |
| Gateway › System | Backup & restore | Backup and restore |
| Gateway › Security | Users | Users and roles |
| Gateway › Security | Sign-in providers | Identity providers |
| Gateway › Security | API keys | API keys |
| Gateway › Security | Audit | Audit log |
| Gateway | Logs | Logs and diagnostics |
| Connections | Databases | Databases and storage |
| Alarms | Pipelines | Alarm pipelines |
| Automation | Event streams | Event streams |
| Automation | Script console | Script console |
| Tags › History | Reports | Reports |
| Settings | Appearance, Sidebar, Logo | Settings |
The dashboard hides what a role cannot use, but only as a courtesy: every API route names the role it needs, and a route that names none is closed.
Who may do what
| Task | Role |
|---|---|
| Read tags, alarms, screens, modes and reports; change own preferences | viewer |
| Write to tags, acknowledge alarms | operator |
| Configure tags, types, screens, connections and reports; start, stop and read the logs of modules | engineer |
| Manage users, API keys and sign-in providers; read the audit log and the gateway log; databases and storage; event streams and alarm pipelines; modes; backup and restore; the project directory; install and remove modules; the script console | admin |
An API key can hold any role up to engineer. Administering the gateway stays with people signed in with a session. Users and roles has the full model, and Security the reasoning.
What makes the gateway call out
Three features make the gateway send requests to other systems, so all three are admin only: event streams (tag changes to a webhook), alarm pipelines (alarm changes to a webhook) and database connections (records to PostgreSQL, SQL Server or MySQL). Identity providers make it read from one, the OpenID Connect provider, at sign-in.
What is stored where
- The gateway database,
DATA_DIR/scadex.db: everything configured in the dashboard, the audit log, alarm history, module state. Backup and restore copies it. DATA_DIR/keys: the keys that encrypt passwords and secrets in the database. Back them up with it.- Each module's own data (the historian's history, the cron module's runs) and its log files under
DATA_DIR/logs/modules. - Memory only, gone at restart: the gateway log, event stream retries and delivery log, client statistics, the
@gatewaydiagnostic tags other than@gateway.performance.
Pages in this section
- Users and roles
- API keys
- Identity providers
- Databases and storage
- Audit log
- Event streams
- Alarm pipelines
- Modes
- Reports
- Clients
- Logs and diagnostics
- Backup and restore
- Settings
Configuration keys such as DATA_DIR, AUTH_BASE_URL and AUTH_TRUSTED_ORIGINS are in Configuration. The REST reference is under API.