Appearance
Triggers and scheduled workflows
Triggers and schedules provide ways to initiate work in NOOSAdmin. They connect data collection and computation with the events or timing rules relevant to an application.
A trigger initiates a configured operation in response to an event or invocation. A schedule supplies a recurring timing rule. Together with ingress, processors and runners, these mechanisms support applications that collect information periodically or respond to newly available data.
Event-driven and scheduled execution
Event-driven work is useful when an operation should respond to something happening. For example, a processor can run on a trigger when a new row is added. Scheduled collection is useful when NOOSAdmin should retrieve data at a recurring interval.
| Mechanism | Question it answers | Documented example |
|---|---|---|
| Event-based trigger | What event should initiate this work? | A processor runs when a new row is added. |
| Recurring rule | At what interval should collection start? | Pull ingress runs every specified number of minutes or hours. |
| User-facing runner trigger | Where can a user initiate computation? | A portal page provides a runner trigger. |
A schedule and a trigger describe initiation. The processing logic, selected inputs and destination for results remain responsibilities of the configured operation.
Triggers associated with ingress
Ingress can fire a system-wide trigger. Pull ingress can also be initiated after a system-wide trigger fires, allowing retrieval to respond to a configured event.
“System-wide” describes the trigger's scope in the supplied functionality description. It should not be interpreted as granting users access across organisations or as bypassing entity permissions.
When planning an event-based operation, identify the event that should start it and the work that should follow. This makes the relationship explicit instead of assuming that every incoming record should cause every available computation to run.
Processing and runner execution
Data processors can operate on a single row or multiple rows and can run in response to triggers, including a newly added row. Their scripts define what information to read and what results to produce.
Data runners are invoked by triggers and execute external code packaged as Docker images. Portal pages can contain runner triggers, providing a user-facing way to initiate that functionality.
These capabilities support different starting points for computation. A single-record transformation may respond to new data, while a portal can offer a runner action to its audience. Each operation still needs its own input and output arrangement.
Example: periodic collection
In an illustrative monitoring application, a source publishes measurement exports throughout the day. A recurring rule initiates pull ingress at the chosen interval. The retrieval logic obtains the export, and the integration maps its data for storage in the application.
The interval should reflect how frequently the source updates and how current the application needs its information to be. Pull-ingress retries can address failed retrieval, and throttling can constrain call frequency. Detailed collection behaviour is covered in Pull ingress.
Example: processing a new record
In a second illustrative arrangement, adding a measurement initiates a processor. The processor uses the new record and can read related equipment information from another table. It stores a derived result in a destination table that a dashboard can query.
The diagram shows that conceptual arrangement. It does not imply that viewing or refreshing the dashboard is part of the same execution.
Loading diagram…
This example illustrates one processing relationship. A larger workflow may use additional operations, but their dependencies and initiation must be configured explicitly. A processor finishing does not by itself establish an automatic hand-off to a runner.
Timing and workflow boundaries
Three concepts matter when planning collection timing:
- Schedule: the recurring rule that initiates retrieval.
- Throttle: the minimum time between successive calls associated with the same pull trigger.
- Retry limit: the configured number of additional fetching attempts after failure.
These controls describe when collection is initiated or attempted. They do not establish guarantees about operation ordering, concurrent execution, event delivery or complete workflow recovery.
For a conceptual workflow, specify the initiating event or interval, the operation to perform, the required input and where the result should be stored or presented. This provides a clear account of what the application is intended to do without assuming undocumented orchestration behaviour.
Access and administration
NOOSAdmin identifies scheduling administration as a role area, referred to as cron administration in the platform overview. Groups can receive permissions on scheduled operations, as well as entities such as ingress and runners.
Planning an automated workflow therefore includes deciding who maintains its relevant resources. The people using a result may have different responsibilities from those managing the collection rule or external computation behind it.