Appearance
Data runners and external computation
Data runners bring external computation into a NOOSAdmin application. Each runner is based on a Docker image with defined inputs and outputs and is invoked by a trigger. Results can be stored in application tables or provided as inline output.
This is useful when a project includes an independently developed model or processing component. For example, an analytical team can supply computation packaged for execution, while NOOSAdmin provides the surrounding application capabilities for working with data and presenting stored results.
Packaging computation with Docker
A Docker image packages executable code with the software it requires. In NOOSAdmin, that image supplies the computation performed by the runner.
The runner's purpose depends on the packaged code. It might perform an AI inference task, calculate an analytical result or run another application-specific computation. These are illustrative uses of the external-code facility; the platform does not define the model's behaviour or the meaning of its answers.
The team providing the component is responsible for its computational logic. Integrating it into the application requires an agreement about the data it receives and the results it produces.
Defined inputs and outputs
A runner has a specific input and output. These define the boundary between the application's data and the external computation.
Before integrating a runner, establish what information it needs, how that information is represented and how its output will be interpreted. For a measurement-analysis model, this could include the equipment reference, the selected readings and the measurement units. The actual structure depends on the component.
| Integration question | Why it matters |
|---|---|
| What data does the component require? | Determines which application information must be supplied. |
| What period or collection of records is being analysed? | Establishes the scope of the computation. |
| What do the returned values mean? | Allows the application to present results accurately. |
| How should results relate to application records? | Supports linking stored outputs to equipment or other relevant entities. |
| Will results be stored in tables or provided inline? | Determines how they participate in the user experience. |
These questions guide the integration design. They are not a specification of a standard input format, file layout or invocation API.
Trigger-based invocation
Data runners are invoked by triggers. Portal pages can also contain runner triggers, providing a place for users to initiate computation as part of their application experience.
The trigger provides the starting point. The configured integration must still supply the appropriate input and determine how output is handled. Making a runner available on a page does not define which records should be analysed.
NOOSAdmin includes a data runner administrator role, and groups can receive permissions on runner entities. When planning a user-facing action, consider the relevant runner permissions alongside access to the portal and its pages.
Working with results
Runner output can be written to other tables or provided as inline output. Table storage makes a computational result available as application data, where explorers and dashboards can query it.
For example, an Analysis results table could hold a model's returned values and an equipment reference. A dashboard could present those values, while an explorer could let users inspect the underlying result records. The table structure and the interpretation of each value are choices made for the application.
Inline output provides the result through the runner's output. Its presentation and retention are implementation-specific. When the intended experience requires reusable queries over results, plan the destination tables as part of the integration.
Remote runners
NOOSAdmin also provides a remote-runner option. In the documented preparation flow, it gathers the required data, exports it, compresses it into a ZIP archive and uploads it to a remote server.
| Step | Documented action |
|---|---|
| Gather | Collect the data required for the remote operation. |
| Export | Produce an export of that data. |
| Compress | Package the export as a ZIP archive. |
| Upload | Transfer the archive to a remote server. |
This describes the outbound data preparation and transfer. The remote execution protocol and the mechanism for returning results are not specified in the supplied functionality overview, so this guide does not prescribe them.
The remote integration needs its own agreement about the exported data and destination. The general runner output capabilities should not be read as a description of an automatic remote-result retrieval mechanism.
Example: analysing equipment measurements
In an illustrative equipment-monitoring application, an external model examines a selected set of readings. The integration supplies the inputs expected by the model, invokes the Docker-based runner through a configured trigger and stores its returned result in an Analysis results table.
The application team could expose a runner trigger on an analyst's portal page. The input arrangement would establish which equipment and readings are included. The result table would preserve the association with the equipment so users can interpret the output in context.
A dashboard can query the stored analysis results alongside other relevant information. This creates a connection between external computation and the application experience without requiring the dashboard itself to perform the analysis.
If the component instead uses the remote-runner option, NOOSAdmin's documented gathering, export, ZIP and upload flow covers the outbound preparation. The remote execution and return path must be defined before describing the complete scenario as an implemented workflow.