Snippet Framework

The Collection Factory

You can think of the framework as a factory assembly line. SL1 takes input from Dynamic Applications, credentials, and discovered devices and delivers them to the factory as raw materials and work orders. During production, the framework takes the work orders and materials and determines the sequence of steps and machines that will result in the requested finished product. The line supervisor and station technicians watch for errors and ensure that any issues are handled or reported. Finally, SL1 picks up the finished product for delivery to the customer.

../_images/framework_assembly_line.png

In the assembly line analogy, the supervisors do not limit the type of products that can be produced or the way in which they can be assembled. The role of the framework is to arrange the step and steps according to the work orders, move the materials through the stages, handle routine reporting tasks, and deliver the finished items.

The Framework for Collection

A software framework is an abstraction that provides the ability for user-written code to customize and plug into general functionality in a controlled way to accomplish specific tasks.

Your role as a Snippet Framework developer is to define the steps that will do the work, the order in which they will execute, and any customizations needed.

The Snippet Framework handles the basic tasks and responsibilities of collection applications, so that you can focus on the specifics of what to request and how to process it. In other words, you get to spend more time thinking about the data you want to collect, display, and act on, rather than spending time understanding snippet variables, the order of operations, and routine collection tasks like parsing and conversion of data types.

The framework takes as input the configuration of SL1, the snippet argument, custom snippet functions, and any custom libraries, and then it assembles the collection sequence of events, executes that sequence, and finally returns the results to the snippet for storage in SL1.

This diagram shows these responsibilities at a high level:

../_images/low_code_overview.png

The orange entities indicate the parts that a Snippet Framework developer needs to be concerned with. The rest are handled by SL1, built-in steps, or the framework.

The following sections describe from simple to more complex, the ways in which a Snippet Framework developer can customize collection.

Snippet Framework Arguments

As a user of the Snippet Framework, your main method for customizing collection is the snippet argument. The snippet_arg is a text field that is provided as input for the collection object when the snippet executes. For a general snippet, this text field can contain anything useful to the snippet for identifying or working with the object. For a snippet, this field contains a Snippet Framework specification for:

  • the protocol to use for device communication

  • a resource to request from the device

  • transformations to apply to the response

Combined with the built-in steps in the framework, the snippet argument allows a Snippet Framework developer to solve most collection problems without any traditional programming language knowledge.

Snippet Framework Functions

The snippet argument allows you to specify what values should be collected and how they should be processed using built-in Step, but sometimes those built-in Step will not be sufficient for special cases and you will need some Python code. In this case you can use or create custom Step in the snippet. These steps can be added to the framework’s execution step to customize the collection objects as the framework moves through each step.

Snippet Framework Step

The Snippet Framework executes reusable code blocks known as steps. A step would only have a single purpose (e.g. parse string to JSON, select a value from a dict, etc). Steps are chained together during execution to collect, process, and select the correct values with little to no coding required. A valid step can be a class or function, depending on where the step is registered.

Execution of a step is referred as an action and an action argument is the configuration parameters for the step.

If neither the snippet argument’s Snippet Framework syntax nor a Step defined in the snippet offer enough flexibility to solve a problem, you can create your own Step to include and reuse in a ScienceLogic Library.

As a developer of Snippet Framework steps and libraries, you can customize operations through:

  1. a custom sequence of events

  2. custom steps

  3. using steps in different combinations

This level of customization allows you nearly full control of the sequence of events, the flow of data, and communication with the device, while relieving you of having to worry about core functionality like error handling, logging, and code management.

Caching

The Snippet Framework has a step type that enables caching. While any processor could be a Cacher, the Cacher step adds the ability to register a read function that enables the Snippet Framework to fast-forward to the next step. By fast-forwarding and re-using cached data, the speed and efficiency of the framework can be improved by reusing past calculations.

Cacher steps do not have the ability to modify the result or result_container as they do not update the automatic cache key. The exception is when you are performing a read operation you are able to return the result of the read.

Rewind / Collect more data

The Snippet Framework has the ability to have a step that requests more information from a Requestor. This functionality is referred to as rewinding within the Snippet Framework. This feature allows us to continue to request more data until all data has been received. One example of this could be a paginated response from a REST API.

To use this functionality the following requirements must be met:

  • The Requestor must be registered with a rewind function

    • @register_requestor(rewind=<func>)

  • The processor must be registered with the correct type

    • @register_processor(type=silo.low_code.REQUEST_MORE_DATA_TYPE)

  • The processor must raise the exception silo.low_code.RequestMoreData

  • The index must not have been previously collected.

  • The maximum number of iterations is 100, unless otherwise specified.

If these criteria are met, the Snippet Framework will continue to collect the data until the Processor step determines there is no more data to collect. Once all of the data is collected, the result of the step will be an OrderedDictionary of all collected results.

Summary

The Snippet Framework allows a developer to specify collection configuration and processes using:

  • snippet arguments

  • snippet functions

  • custom steps

Many issues can be solved with little to no code intervention. However, some issues problems can be solved with additional code that plugs into the framework. With this approach, you can focus less on tedious and repetitive work, and receive more value from the data that SL1 collects quickly.