Data Sources and Refresh
Every widget that shows live or sample data needs a data source and a refresh strategy. Dashboard Hub keeps credentials and analytical query execution on the service side whenever possible.
Supported data source types
| Source | Label | Typical use |
|---|---|---|
mock | Mock / Direct Data | Static JSON for layout development and demos |
api | API Data Source | REST responses from external or platform APIs |
database | Database Query | SQL against registered analytical stores (for example via CrateDB proxy) |
bizops | BizOps | Business operations platforms and workflow-oriented metrics |
service_catalogue | Service Catalogue | Internal service registry / catalogue feeds |
Default Hub authoring commonly includes mock/direct data as a baseline source so new dashboards can be composed before live integrations are ready.
Choosing a source
| Situation | Recommended source |
|---|---|
| Designing layout and widget mix | Mock / Direct Data |
| Existing JSON HTTP API | API Data Source |
| Time-series or warehouse SQL | Database Query |
| Business workflow / BizOps metrics | BizOps |
| Service inventory style data | Service Catalogue |
Start with mock data to prove the story of the dashboard, then swap sources without rebuilding the entire layout.
Database and analytics path
For SQL-backed widgets, Omega Watch Service can act as a secure proxy (for example to CrateDB):
- The client sends a query request to the service.
- The service authenticates and executes against the analytical store.
- Results return to the widget for mapping and render.
This keeps database credentials off the browser and centralizes retry/error handling.
Field mapping and preview
During widget configuration:
- Fetch or sample a payload from the chosen source.
- Map fields to the widget's required roles (value, category, series, columns, and so on).
- Use live preview to confirm formatting (prefixes, units, chart axes).
- Save the mapping with the widget definition.
AI-assisted query generation may be available in some builds for natural-language to SQL — treat generated SQL as a draft and validate before publishing.
Refresh strategies
| Strategy | Behavior | Good for |
|---|---|---|
| Polling | Fetch on an interval | Most KPI and chart boards |
| WebSocket | Push updates from a stream URL | Near-real-time operations walls |
| Manual | Refresh only when the user or global refresh triggers | Expensive queries and investigative boards |
Common refresh options include:
| Option | Purpose |
|---|---|
interval | Polling period in milliseconds |
pauseOnHidden | Pause updates when the browser tab is hidden |
retryOnError | Retry failed fetches |
maxRetries | Cap automatic retries |
Global refresh actions in the dashboard chrome can trigger a coordinated refresh across widgets.
Error and empty states
Design for failure before publish:
| State | Operator expectation |
|---|---|
| Empty result | Clear empty illustration or zeroed KPI, not a blank tile |
| Auth / permission error | Actionable message; hide raw secrets |
| Transient network error | Retry with backoff when configured |
| Query timeout | Visible error on the widget without blocking the whole dashboard |