IT dashboard
The IT dashboard is the IT team's view of NomaUBL. It reads top-down like a checklist: is everything up? (a health strip), what is there to do? (four action cards with their bulk action), how did processing go over the last 14 days?, what is running right now?, and the recent errors. The detailed technical cards — system, filesystem, JVM, configuration check, database tables — are folded at the bottom and open from the health strip. It complements the Operations dashboard, which follows the invoices rather than the server.
The page applies regardless of source system — JD Edwards, SAP, NetSuite or a custom ERP. The cards read host-level metrics and the NomaUBL processing log.
Opening the page
- Menu → Navigation → IT dashboard, after Operations.
At a glance
A Refresh button in the page header reloads every card.
Health strip
The Is everything up? strip gives six tiles, each with a green, orange or red dot. A click on a tile scrolls to its detail and, except for Scheduler, opens the folded technical details:
| Tile | Shows | Opens |
|---|---|---|
| Application | The release and up for …. | System Health |
| Database | The ping in ms, or Unreachable. | System Health |
| Disk | … % free on the fullest disk. | Filesystem |
| Memory | Heap use in %. | JVM · threads + GC |
| Scheduler | Running, … paused or … job(s) failed, and the next run. | The Scheduler card in Right now |
| Configuration | No issue or … issue(s). | Configuration check |
To do
Four cards count the invoices waiting for an IT action, each with a button that handles them all at once through the shared progress window. The manual one-click retry of Send failed and the scheduled overnight sweep of the Auto-Retry page call the same replay path.
Send failed (9904)
A single big-number card showing how many invoices are currently in Send failed (status 9904). When the count is non-zero, a Resend all N button below the number replays every matching invoice to the Plateforme Agréée. Clicking it opens the shared progress window — live counters, a Cancel button and a Run in background button that hides the window while the work keeps going server-side. The resend is throttled at 100 ms per call so the PA stays inside its rate budget.
| Element | Behaviour |
|---|---|
| Count | Live total — refreshed by the page's Refresh button and at every dashboard mount. Coloured red when non-zero. |
| Resend all N button | Disabled when the count is zero. Click to replay every status-9904 invoice; opens the progress window. |
| Progress window | Live counters (processed / succeeded / failed), a Cancel button and a Run in background button — same component as every long-running operation on the platform. |
| Throttle | 100 ms between calls — fixed in code; not operator-tunable here. The Auto-Retry schedule exposes its own throttle for the scheduled equivalent. |
Use the manual button for a one-shot replay during business hours (a brief PA outage that cleared, a small batch you want resent now). For unattended overnight retries, schedule a row on the Auto-Retry page — same code path, no operator action required.
Waiting for review
A big-number card that counts the invoices held before sending — the ones whose document type carries the W (Waiting) send flag on the Document Types page. These invoices were generated and validated but deliberately not transmitted, so a user can check them first. When the count is non-zero, a Send all N button releases every held invoice to the Plateforme Agréée in one action, through the same progress window as Send Failed. It mirrors the Send Failed card — same big number, same one-click bulk action — but for the review queue rather than the failure queue.
To reprocess
A big-number card that counts the invoices eligible for reprocessing — those the platform deposited but did not transmit (status 200, reason NON_TRANSMISE), on a template with Allow reprocess enabled. When the count is non-zero, a Reprocess all N button reprints every eligible invoice from its archived source — readable PDF / XML and UBL file regenerated, no database change, no new validation — through the same progress window. Reprocessing keeps each invoice's status, records a Retraitement history entry and never re-sends to the platform — see Documents → Allow reprocess for the per-template switch and Invoices for the same action on selected rows.
To reprocess in full
The counterpart of the previous card for validation-failed invoices (9905) on a template with Allow full reprocess enabled. Once the data was corrected at the source, a Reprocess all N button reprocesses every eligible invoice in full from its archived source: the enrichment is queried again, the UBL regenerated, validated and sent to the PA when the template and document type say so. The status history is kept and a reprocess marker opens a new cycle, so the statuses that follow are recorded as new.
Both cards run one batch per template, in the background with its live log: the sources are staged in a working folder, the Max threads setting of the global settings bounds the parallelism, and an invoice is never processed twice.
Processing · last 14 days
One card with four tabs: Volume, Errors, Retries, Time per document.
Volume
Documents processed per day over the last 14 days, as stacked bars: Processed and In technical error; the subtitle gives the totals and the time they were loaded. This card is kept on the server for every user for the dashboard cache delay; Refresh reads it again. Click a bar to open E-Invoicing on that day, by archive date — a quick path from "today's column is short" to "show me what was processed".
Errors
The Error rate · 14d card: 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.
Retries
The Retry rate · 14d card: a 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).
Time per document
The Template processing time · 14d card: 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.
Per-step breakdown when debugProfile is on
When the debugProfile toggle on the global template is set to Y, every processing run writes one row per pipeline stage to F564237 — header parsing, lines parsing, validation, UBL emit, PA send. The Template processing time card surfaces them as a stacked breakdown under the per-template totals, so a slow stage is visible at a glance without digging into the runtime log.
The Live process events tail below also tags the rows with the step name so a slow batch can be triaged in real time. Leave debugProfile at N in production; flip it to Y for the duration of a batch run when triaging a slow pipeline — the extra rows inflate F564237 quickly under load.
Right now
What is running on the server at this moment: the running processes, the live process events, the scheduler and the active sessions.
Running processes
The processing JVMs alive on the host, polled every 5 s: those started by this server, with the last line each printed, and the detached ones left by a previous instance, a cron or a manual run (output not captured). Each row shows the mode (-process, -watch-folders, -import), the arguments, the elapsed time and a Stop button, which terminates that JVM and its own child processes only — invoices in progress stay in their current state and input files are left in place. Stopping requires the integration-run grant. Nothing is stopped when the server restarts, so a batch can run through an upgrade.
Live process events
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.
Scheduler
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. - Per-row Auto-Retry sweeps — one row per saved entry on the Auto-Retry page, with the scheduled hour and the matched status list as the cadence.
- Daily lifecycle checks — one row per scheduled entry on the Lifecycle checks page, next to the digests and auto-retries, with its time and last run.
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; the Open Scheduled jobs button opens Scheduled jobs, where every job is run, paused and edited.
The PA import poll and PA status retrieve jobs carry a pause / resume button — effective on the next tick and deliberately runtime-only, so a server restart always resumes and a pause can't be forgotten. The daily quiet window (fetchQuietFrom / fetchQuietTo) is shown here too, highlighted while active — during it both pollers skip their runs automatically.
Active sessions / Active clients · 15m
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.
Recent errors
The Recent errors card lists the 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 tied to an invoice opens the Integration Errors view of Diagnostics narrowed to that invoice; a processing row opens the Processing Log view. Open Integration Errors → opens the view unfiltered.
Technical details
A folded section — system, filesystem, JVM, configuration check, database tables, links — that opens by itself when a tile of the health strip is clicked.
System Health
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
Static shortcut list — the IT operator's most-used pages, opened directly: Processing Log and Integration Errors (both views of Diagnostics), Notifications, Process Document, File Versions and Settings.
Filesystem
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.
JVM · threads + GC
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.
Configuration check
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. |
| Statuses | Every PA status code received but not mapped in the status catalogue: the warning gives the number of events skipped since the server started and an example invoice. Add the code to the catalogue to record these events. |
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
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).
Shared progress window
Every long-running operation in the platform — Resend All from this page, the Auto-Retry sweep, the Detailed view export on Integration Errors, the upcoming bulk re-imports — opens the same modal. One component, one set of habits.
The window stays open by default while the operation runs; closing it is a deliberate action.
| Element | What it does |
|---|---|
| Progress bar | Visual counter of processed-vs-total. Updates every ~250 ms as the server pushes increments. |
| Live counters | Three numbers: Processed (total touched so far), Succeeded, Failed. Each is clickable when non-zero and opens a small drawer with the per-invoice triplets, so a failure on invoice 12345 / RI / 00070 is one click away from its log entry. |
| Cancel | Stops the operation cleanly between two invoices. Already-processed invoices keep their new state; the rest are left untouched. The button is replaced by Cancelled (greyed) once the signal lands. |
| Run in background | Hides the modal without stopping the operation. The work continues server-side; a small persistent banner at the top of the page surfaces the count + a Show progress link. Click the link to reopen the modal at any time. |
| Done | Replaces Cancel / Run in background when the operation finishes. A summary line shows total / succeeded / failed and the elapsed time. |
Multiple operations can run side by side — each gets its own banner when sent to the background. Closing the browser tab does not cancel the work; the server-side run keeps going. Reopening the page surfaces the banner again until the run completes.
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 | Volume, Errors, Retries, Time per document, 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 reads GET /api/scheduler/status. 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.
- Processing-time spikes pair with volume dips. When you see a tall bar in the Volume tab 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.