Appearance
Example workflows
The following scenarios illustrate how NOOSAdmin capabilities can participate in an equipment-monitoring application. They describe conceptual arrangements, with application-specific names and choices. They are not tested tutorials or descriptions of an existing deployment.
Each scenario identifies a purpose, the participating features and the information flow. Their execution details depend on the configured integrations, triggers and permissions.
Collecting and exploring operational data
Purpose: bring equipment measurements into the application and make them available for inspection and recurring presentation.
The application uses Equipment and Measurements tables. Measurements refer to the equipment they describe and contain the information needed to interpret each reading, such as its type, value, unit and observation time.
| Part of the workflow | Illustrative arrangement |
|---|---|
| Define the data | Establish equipment records and associated measurements. |
| Collect readings | Use push ingress for a source that submits data, or pull ingress for a source that publishes data for retrieval. |
| Inspect records | Use an explorer to narrow measurements by equipment and other relevant fields. |
| Present information | Configure a dashboard query and make its page available to the appropriate group. |
For a submitting source, the push endpoint can require authentication, preprocess incoming information and validate it before storage. For a file-based source, pull ingress can retrieve the data on a recurring rule and use its documented retrieval controls.
The resulting user experience supports both investigation and recurring consultation. Users can inspect the collected records in an explorer, while a dashboard provides a configured presentation of queried information.
The collection choice should follow the source's capabilities. The application's handling of repeated records and the mapping from source values to fields are integration decisions.
Preparing data for external analysis
Purpose: use an independently developed model to analyse application data and make its results available to users.
The application already contains measurements. If the model requires derived information, a TypeScript processor can calculate it and store it in a table. The runner integration defines which information is supplied to the Docker-packaged component.
- Define the model's required inputs and the meaning of its outputs.
- Prepare any derived data through a processor, if the application requires it.
- Invoke the runner through a configured trigger, supplying the agreed input.
- Store output in an Analysis results table associated with the relevant equipment.
- Present the stored results through an explorer or dashboard.
These steps describe the intended information flow. They do not imply an automatic processor-to-runner hand-off. The application must arrange when the runner starts and which input it uses.
An analyst's portal could provide the runner trigger and access to result presentations. The result labels should explain what the model returned and which equipment or period the analysis concerns.
For remote runners, the documented functionality covers gathering required data, exporting it, compressing it and uploading it to a remote server. A complete remote-analysis scenario also needs an agreed execution and result-return arrangement, which is outside the supplied detail.
Presenting information to different audiences
Purpose: organise an application experience around the responsibilities of its users.
The team defines user groups for analysts and operational users. It plans the relevant entity permissions, then creates portal content suited to each audience.
| Audience | Illustrative portal content | Intended work |
|---|---|---|
| Analysts | Measurement explorer, runner trigger and result dashboard. | Inspect data, initiate configured analysis and review results. |
| Operational users | Summary dashboard and relevant record explorer. | Consult recurring information and inspect supporting records. |
Each portal has its own menu, pages and branding information. Its group access and underlying resource permissions are arranged together.
This scenario uses presentation and access capabilities; it does not require changing what the measurements or results mean. Both audiences can work with information from the application's data model through views selected for their responsibilities.
Choosing the relevant components
| Need | Relevant guide |
|---|---|
| Establish the structure of records | Databases and data modelling |
| Receive data from a submitting source | Push ingress |
| Retrieve data from an external source | Pull ingress |
| Initiate supported operations | Triggers and scheduled workflows |
| Calculate derived information in TypeScript | Data processors |
| Execute packaged external computation | Data runners |
| Inspect individual records | Data explorers |
| Present queried information | Dashboards and information pages |
| Arrange an audience's application experience | Branded portals |
| Plan membership and resource access | Organisations, users and access |
Start with the information the application needs and the work its users should perform. Choose the collection, computation and presentation capabilities that support those needs, then define how they connect.