Tech Dashboard
The Tech Dashboard is the IT team's operational view of NomaUBL — a single page bundling 14 widgets that cover the JVM, the database, the filesystem, the processing pipeline, the scheduler and a live feed of running jobs. It complements the business Dashboard: the business audience sees invoice volumes and PA round-trip times, the IT team sees heap pressure, scheduler-driven START / END events and disk usage.
Every refresh hits four backend endpoints in parallel — /api/system, /api/dashboard/tech, /api/dashboard/log-tail, /api/dashboard/config-check — so the page lands in one round-trip and stays light on the database.
The page applies regardless of source system — JD Edwards, SAP, NetSuite or a custom ERP. The widgets read host-level metrics and the NomaUBL processing log; the source format is transparent here.
The Tech Dashboard is brand new. The Scheduler widget that used to sit on the business Dashboard moved here, and the in-memory ActivityTracker introduced in the same release fills in the Active sessions card when authentication is disabled.
Opening the page
- Sidebar → Documentation → Tech Dashboard.
- The page renders even without authentication — the System Health block reports the JVM, the build, the OS and the PA mode regardless. Database-backed widgets show Not configured until a connector is set up.
At a glance
The grid uses align-items: stretch and each card grows with flex: 1 inside its column span — cards in the same row align bottoms, regardless of their internal content height.
Layout
The 12-column grid is laid out as seven rows:
| Row | Layout | Widgets |
|---|---|---|
| 1 | 8 + 4 | System Health · Quick links |
| 2 | 4 + 4 + 4 | Scheduler · Error trend · 14d · Retry rate · 14d |
| 3 | 4 + 4 + 4 | JVM · threads + GC · Throughput · 14d · Active sessions / clients |
| 4 | 8 + 4 | Filesystem · Template processing time · 14d |
| 5 | 12 | Live process events |
| 6 | 12 | Configuration check |
| 7 | 5 + 7 | Database tables · Recent errors |
A Refresh button in the page header re-runs all four endpoints in parallel.
Widgets
System Health (row 1, span 8)
JVM, database and host metrics. The most-watched values are colour-coded:
| Stat | Source | Tone rules |
|---|---|---|
| Java | Runtime.version() | neutral. |
| Heap | MemoryMXBean.getHeapMemoryUsage() | green < 60 %, orange < 85 %, red ≥ 85 %. |
| Uptime | RuntimeMXBean.getUptime() | neutral, formatted as Xd Yh / Xh Ym. |
| CPU cores | Runtime.availableProcessors() | neutral. |
| Database | dialect.ping() | green < 100 ms, orange < 500 ms, red beyond or on error. |
| Schema | db-nomaubl config | neutral. |
| OS | os.name + os.arch | neutral. |
| PA mode | paUseMock flag | green when Live, orange when Mock. |
The card subtitle on the right shows the build version + build date baked into nomaubl-version.properties.
Quick links (row 1, span 4)
Static shortcut list — the IT operator's most-used pages. Each link uses the same onNavigate mechanism as the sidebar so it lands on the target page directly. Default targets: Settings, Processing Log, File Versions, Cross-Reference.
Scheduler (row 2, span 4)
Lists every active scheduler job:
- Built-ins —
retrieve-statuses,notif-purge,clean-archive, etc. — driven byBackgroundSchedulerpolling intervals. - Per-template
fetch-all— one row per template that has a scheduled extract / sync.
Each row shows the job name, the cadence, and a status pill (green active, blue scheduled-soon, orange paused). The card subtitle reports the active count.
Error trend · 14d (row 2, span 4)
A 14-day sparkline of error events recorded in F564237 (level ERROR or FATAL). Hovering a point reveals the day and count; the subtitle shows the daily average plus today's running count.
Retry rate · 14d (row 2, span 4)
Single big number: ratio of runs that succeeded only after one or more retries over total runs in the trailing 14 days. The subtitle gives the absolute counts and the delta against the previous 14-day window (green when down, orange when up).
JVM · threads + GC (row 3, span 4)
Companion card to System Health for deeper JVM diagnostics:
- Threads — current count + peak.
- Daemon threads — running daemons.
- GC — collector name + total time spent in GC.
- Loaded classes — class-loader counter, useful for spotting metaspace leaks.
Throughput · 14d (row 3, span 4)
Daily processed-document bar chart over the last 14 days. Click a bar to jump to Processing Log pre-filtered on that day — a quick path from "today's column is short" to "show me what actually ran".
Active sessions / Active clients · 15m (row 3, span 4)
Two modes:
- Auth enabled — title reads Active sessions. Lists every session present in
F564252whoseSSETDTIMis within the last hour. - Auth disabled — title reads Active clients · 15m. Lists every IP touched by
WebServer.handle()in the last 15 minutes, sourced from the new in-memoryActivityTracker(noF564252rows exist when auth is off).
Either way, each row shows IP / user, the last-seen timestamp, and the running hit count.
Filesystem (row 4, span 8)
For each configured path (appHome, processHome, dirInput, singleOutput, burstOutput, dirArchive, dirError):
- Free / total disk space on the underlying volume.
- File count of a recursive walk through the path, capped at 5000 files to keep the call cheap.
Path values that contain runtime placeholders (%TEMPLATE%, %FILE_NAME%) are truncated at the first placeholder, and the report runs against the deepest existing-by-shape directory above it. dirOutput is excluded because it is always covered by processHome.
Template processing time · 14d (row 4, span 4)
Average end-to-end processing time per template, in seconds, over the last 14 days. The card pulls flat START / END events from F564237 and pairs them in Java keyed on (FEWDS1|FEUPMJ) — the prior implementation used a self-join SQL with ambiguous FETMPL and incorrect e.FEUPMT - s.FEUPMT math, which is now fixed.
Live process events (row 5, span 12)
A live feed of jobs starting and finishing in real time — most of them launched by the background scheduler. Polls F564237 every 5 seconds with an incremental since= cursor; each row carries a coloured method badge:
| Badge | Meaning |
|---|---|
| START (green) | A job has just started — fetch-all, retrieve-statuses, an inbound process, etc. |
| END (blue) | The matching END event for a previously-started job, with the elapsed time when available. |
| ERROR (red) | An inline error emitted while the job ran — ERROR, FATAL, FAILED keywords promote any row to this kind, even when its method was START or END. |
| INFO (muted) | Anything else the runtime logger wrote during the job. |
Each row shows the badge, the template + mode + source file when present, the message, and the timestamp. A pulsing green dot appears next to the title when an event has been observed in the last 30 seconds (a job is running right now); it switches to grey when the feed has been idle longer.
The feed is deduplicated on FEUKID so the same row never appears twice across polls, even when the clock jitters. A Pause / Resume button on the right of the title freezes polling — useful when reading a long line without it scrolling away.
The scrollable list is capped at the latest 100 events; older rows fall off the bottom as new ones come in. For deeper investigation use the Processing Log page, which keeps the full history with grouped-job views.
Configuration check (row 6, span 12)
Validates the connector-style configuration the application uses today. Issues are listed by area with severity (red error, orange warning, blue info). The check runs against:
| Area | Validates |
|---|---|
| PA connector | baseUrl; authType; credentials per auth type — OAUTH2 (clientId/secret/token endpoint), BASIC (username/password), BEARER (token); presence of an endpoint named import (warns when import-status is missing). |
| e-Directory | baseUrl and directory-check endpoint when checkDirectory=Y. |
| e-Reporting | issuerSiren, frequency, flux when sendToPA=Y. |
Old checks against paApiBaseUrl / paApiUsername / ublXsdPath / ublSchematronPath are gone — those properties no longer exist on the connector schema. The validation assets (XSD / Schematron) are bundled in the JAR.
A clean check renders as ✔ 0 issues in green; otherwise the card lists the issues in order of severity.
Database tables (row 7, span 5)
Per-table row count for every NomaUBL table — invoices (F564231), lifecycle (F564235), validation (F564236), runtime log (F564237), notifications (F564253), e-Reporting (F564260–F564262), auth (F564250–F564252, F564254). Useful for spotting unexpected growth (e.g. a notifications table that should be ~hundreds of rows but holds millions).
Recent errors (row 7, span 7)
Last 8 events from F564237 filtered on level IN ('ERROR', 'FATAL'). Each row shows the level badge, the lifecycle code and triplet, the message, and a relative timestamp (2m ago, 1h ago). Clicking a row opens the corresponding entry in Processing Log, where the full stack and replay options live.
How widgets refresh
The Refresh button (or page mount) calls four endpoints in parallel:
| Endpoint | Feeds |
|---|---|
GET /api/system | System Health, JVM extras, Filesystem |
GET /api/dashboard/tech | Throughput, Error trend, Retry rate, Template stats, Active sessions, Database tables, Recent errors |
GET /api/dashboard/log-tail | Live process events (incremental, polled every 5 s with since=) |
GET /api/dashboard/config-check | Configuration check |
The Scheduler card consumes the existing GET /api/scheduler/status so it shares the data already loaded by the business Dashboard during a same-session navigation. Each call fails independently — a misconfigured database returns Not configured on the data card without breaking System Health or the live tail.
Tips & best practices
- Watch Heap, Database ping and Filesystem free space. The three early-warning signals — heap drift before an OOM, database latency before a stall, archive volume before disk fills.
- Live process events beats
tail -f. It shows scheduler jobs starting and ending in real time, errors stand out in red, and the feed survives an SSH disconnect. Keep it open during a release window or a batch import — most regressions surface here within seconds, and the green pulsing dot tells you whether anything is actually running right now. - Configuration check should always read green. A non-zero issue count after a deploy is the fastest path to "what changed". Run it on every environment after every config edit.
- Recent errors over Database tables. When triaging an incident the recent-errors feed is denser per pixel; the table stats card is for trend-watching across days.
- Empty Active clients does not mean nobody is using the app. With auth enabled, sessions older than an hour drop off the list — the database lifecycle still records them. The card shows who is on right now, not who was on this morning.
- Template processing time spikes pair with Throughput dips. When you see a tall blue bar in Throughput followed by a slow template the next day, expect the queue to back up — the IT team can pre-empt by adjusting the scheduler cadence.