Snippet Framework Arguments

Download this manual as a PDF file

This section covers snippet arguments, which are the main way you configure collection behavior in the Snippet Framework. It explains what a snippet argument is, shows what the YAML structure looks like, and describes how using arguments instead of custom code makes monitoring development faster and more reusable. It also introduces substitution tokens, which let you inject dynamic runtime values like device hostnames and credentials directly into your arguments.

Defining Snippet Arguments

Snippet arguments are the primary configuration mechanism for Snippet Framework-based Dynamic Applications. They are what make low-code monitoring development possible. Instead of writing custom Python code for every collection need, you define collection behavior through structured configuration that the framework reads and executes.

A snippet argument is a YAML block attached to a collection object in a Snippet-type Dynamic Application. When the Snippet Framework executes the application, it reads the snippet argument to determine:

  • Which step types to run and in what order
  • How to configure each step (e.g., the endpoint URL, authentication method, parse expression)
  • Any substitution tokens to resolve at runtime

Snippet arguments externalize collection behavior from code into configuration. This is a core design principle of the framework. The snippet code is boilerplate; the snippet argument is where the actual logic lives.

Where Snippet Arguments Are Configured

Snippet arguments are configured at the collection object level within a Dynamic Application. In the Skylar One user interface, snippet arguments appear as a YAML input field on each collection object in a snippet-based Dynamic Application.

For step-by-step instructions on locating and editing snippet arguments in the UI, see the Snippet Dynamic Application Development manual.

Basic Snippet Argument Structure

A snippet argument YAML block specifies a list of steps under a top-level key that identifies the execution context. The exact structure depends on the toolkit in use, but a representative REST-based snippet argument might look like the following:

yaml
rest_requestor:
url: "https://api.example.com/metrics"
auth: basic

json.processor: {}

jsonpath_processor:
expression: "data.value"

Each entry in the YAML corresponds to a step in the collection pipeline:

  • rest_requestor tells the framework to use the REST Toolkit's Requestor step, targeting the specified URL with basic authentication.
  • json_processor tells the framework tells the framework to parse the response body as JSON.
  • jsonpath.processor tells the framework to extract the value at `data.value` from the parsed response.

The exact YAML keys, field names, and supported options for each step depend on the toolkit providing that step. For more information, see the toolkit-specific manuals.

For snippet-based Dynamic Applications that make HTTP/S requests, SSL certificate verification during collection is controlled by the Verify SSL for Collections by Default setting on the Behavior Settings page (System > Settings > Behavior). This setting is disabled by default. For more information, see the System Administration manual.

Snippet Argument Development

The argument-driven approach means that:

  • The same snippet code can serve dozens of different collection scenarios, each with different behavior defined entirely through its YAML argument.
  • Non-developer users can configure collection behavior by editing YAML rather than writing Python.
  • Snippet bodies are standardized and interchangeable, reducing maintenance overhead.
  • Behavior changes are confined to the argument field, making them easier to review and track.

This is why snippet arguments are described as the central element of low-code monitoring development in the Snippet Framework.

Substitution Tokens

Substitution tokens allow snippet arguments to reference dynamic runtime values rather than hardcoded strings. At execution time, the framework resolves each token to its actual value before passing the argument to the pipeline.

Common uses for substitution tokens include:

  • Inserting device-specific values such as hostname or IP address into request URLs
  • Referencing credential fields such as usernames or passwords from the aligned credential record
  • Inserting collection-specific values such as the collection label or OID

The full substitution token reference is maintained in the developer-facing documentation. See the section on Developer Resources at the end of this manual.

Substitution token availabiltiy and syntax might vary by toolkit version. Confirm the available tokens against the documentation for the specific Low-code Tools or toolkit version installed in your environment.