Skip to main content
File-based reports package a Script query with typed parameters and presentation. They let operators run a supported procedure without access to an unrestricted Script prompt.

​
Build a report

  1. Define one operational question, such as “Which XMPP counters changed between two labels?”
  2. Declare the minimum parameters and safe defaults.
  3. Validate parameter length, range, wildcard use, and permitted prefixes.
  4. Query or calculate in Script.
  5. Return a typed table, graph, or document.
  6. Add empty-state and error output.
  7. Package the report under the administrative Sources & Nodes tree.

​
Counter comparison example

Persist labelled snapshots as an owned report object. Later, subtract dictionaries and filter zero differences:

​
Scheduled jobs

The jobs subsystem can run Script on a schedule or in response to application events. A production job should be:
  • idempotent or protected by a durable operation key;
  • bounded by time and batch size;
  • explicit about time zone (prefer UTC internally);
  • resumable after restart;
  • observable through stable event IDs and counters;
  • safe when two runtime nodes attempt the same work.

​
Event queues

Use an encrypted FIFO queue when event producers and Script consumers run at different speeds. Dequeue in batches, commit the business result before acknowledging, and isolate poison messages.

​
External effects

Neuron extensions let Script send XMPP messages and email, create or propose contracts, query tokens, and call payment services. Separate a workflow into:
This makes retries understandable. Do not send a payment or signature request directly from a report that users expect to be read-only.

​
Parameter security

Do not interpolate report parameters into raw SQL, XML, paths, URLs, or .NET type names. Use typed parameters, allowlists, and the provider’s parameter binding.