Appearance
Data processors
Data processors use TypeScript scripts to work with application records and produce derived information. A processor can operate on a single row, loop through multiple rows and read other tables. It can store its results in tables or provide inline output.
This makes processors useful for calculations and transformations built around the application's data. For example, a processor could calculate a summary of equipment measurements and store it in a table that supplies a dashboard. The calculation is application-specific logic written in the script.
Working with one record or multiple rows
The scope of processing depends on the task. A single-record operation can use one row as its input, such as a newly added measurement. A multi-row operation can iterate through a collection of records to derive information from them together.
| Processing scope | Illustrative task |
|---|---|
| One row | Derive a value from an individual measurement. |
| Multiple rows | Calculate a summary from a selected collection of readings. |
| Records combined with another table | Use equipment information when interpreting measurements. |
These are examples of what a script can implement. NOOSAdmin supplies the processing facility; the application defines the calculation, the records it uses and the meaning of the result.
Reading related information
Processors have access to other tables. This allows a calculation to combine its primary records with information stored elsewhere in the application.
In the equipment example, a measurement refers to an equipment record. A processor could read that equipment information while calculating a result. The script must implement the relevant lookup and calculation; a relationship in the data model does not, by itself, define the processing logic.
Planning a processor therefore starts with identifying its inputs: which records it needs, which additional tables it reads and what each value represents. Clear input definitions help keep the resulting calculations consistent with the application's data model.
Stored results and inline output
A processor can write results to a table or provide them as inline output.
Stored results become application records. They can supply an explorer or a dashboard, or be read by another processor. A destination table is useful when users need to query derived information alongside other data.
Inline output provides results through the processor's output rather than through a destination table. The available output format and how it is presented depend on the implementation. This guide does not assume a particular output viewer or retention policy.
The intended use of the result should guide this choice. If a calculation will supply a recurring dashboard, define a table that represents that result and configure the processor to write it there.
Trigger-based processing
A processor can run in response to a trigger, including when a new row is added. This supports work associated with newly available data, such as calculating a derived value for an incoming measurement.
The trigger determines when the processor is initiated. The script determines which information it reads and what it produces. Keeping these responsibilities explicit helps describe the workflow: an event starts processing, and the processor performs the application's calculation.
Trigger behaviour is explained in Triggers and scheduled workflows. A processor writing a result does not, by itself, establish an automatic sequence of further operations.
Example: calculating equipment summaries
Consider an illustrative application with Equipment and Measurements tables. The team wants a dashboard that presents an average reading for each piece of equipment over a chosen period.
A processor could implement the following logic:
- Identify the equipment and period to summarise.
- Read the relevant measurements and any required equipment information.
- Calculate an average from readings representing the same measurement type and unit.
- Store the equipment reference, period and calculated value in a summary table.
A dashboard can then query that table. These steps describe proposed script logic, not a built-in averaging function or a predefined NOOSAdmin table.
The team also needs to decide what a summary record represents and how the script should handle missing readings or a repeated calculation for the same period. Those are application decisions that affect the meaning of the stored result.
Choosing a processor or a runner
Processors and runners both produce results, but they integrate computation in different ways.
| Consideration | Data processor | Data runner |
|---|---|---|
| Implementation | A TypeScript script. | External code packaged as a Docker image. |
| Data handling | Works with one or multiple rows and can read other tables. | Uses defined inputs and outputs for the packaged computation. |
| Initiation | Can run in response to a trigger, including a newly added row. | Invoked by a trigger; portal pages can provide runner triggers. |
| Results | Table storage or inline output. | Table storage or inline output. |
| Illustrative use | Calculate summaries from application records. | Execute an independently developed analytical or AI model. |
| Remote capability | No remote-processor mechanism is described in this guide. | Remote runners support gathering, exporting, compressing and uploading required data. |
A processor is a suitable starting point when the work is naturally expressed as TypeScript logic over application records. A runner is useful when the computation is supplied as an external component with its own packaged software requirements.
An application can use both. For example, a processor could prepare derived data that later forms part of a runner's input. The input selection and initiation of that runner still need to be configured for the workflow.