Module system terminology

Important notice: As part of Advanced XML deprecation, the Module System is officially deprecated beginning with Splunk Enterprise 6.3. For more information, see Advanced XML Deprecation.

These terms are relevant to the Module System. For general Splunk terms and definitions, see the Splexicon.

A - B - C - D - E - H - I - J - M - N - P - Q - R - S - T - V

-A-

abstract class

Actually, an abstract base class which may define methods to be implemented by subclasses. Abstract classes enforce inheritance hierarchy.

Module System uses the mechanism, in Python and JavaScript, for apps to hook into the framework, by sub-classing. The following are abstract classes:

• Splunk.Module
• Splunk.Module.DispatchingModule
• ModuleController
• ModuleHandler
• BaseController

See also: base class, extension point

add-on

App implementations that have configurations, knowledge, inputs, outputs, and workflows that classify, transform, or normalize data, and are intended to be used by one or more apps are called add-ons.

An add-on provides a container for knowledge (event types, field extractions, lookups), scripted inputs, and other extensions to core Splunk capabilities, which may or may not be technology-, product-, or solution-specific.

Note  : Add-ons should not depend on other apps or add-ons for correct operation.

Add-on packaging facilitates distribution to Splunk instances.

See also: app

app

An app is a redistributable package containing some or all of the following components:

• Configurations
• Views
• Modules
• Controllers
• Templates
• Models
• JavaScript
• Static Content (HTML, CSS, Images)

In general, apps create a compelling and enriching user experience for exploring data produced by a particular,

• Technology
• Product
• Solution

Apps provide a container for custom workflows, views, and other extensions to SplunkWeb. Apps also contain saved searches, macros, and other knowledge for working with domain-specific data and objects.

App packaging is intended to facilitate distribution to Splunk instances. Apps are commonly distributed using the app and add-on repository on Splunk Apps but can also be distributed using Splunk Web or by extracting the package within the Splunk file system.

Apps contain the ability to integrate with add-ons for advanced data collection.

See also: add-on

application

The term application refers to domain-specific software, independent of a particular implementation. Applications achieve significant reuse in the Splunk environment by being implemented using the Module System. Apps and add-ons are application implementations.

See also: add-on, app

-B-

base class

The class from which another class inherits is a base class, providing structural integrity.

Sub-classing a base class is the Module System mechanism for hooking an app into framework functionality. Applications usually need to implement required base class methods in a way that modifies Module System behavior to suit application requirements.

See also: abstract class

bind (events)

Web programming typically requires that a method or function is bound to a particular user or program event to perform the desired action when the event occurs. Binding, effectively, attaches a callback function to some event or action.

For example, AJAX request parameters include a completion function to be executed when the request completes.

Also, see the jQuery bind() method for binding browser events to DOM elements.

You can override default Splunk event handlers by implementing a custom handler in the application.js file. A number of API methods, such as dispatchJob(), also permit you to specify callback functions on success or failure of the operation.

-C-

CherryPy

CherryPy is a Python framework for building web applications. Module System uses CherryPy to handle HTTP requests, including session handling.

child (module)

In the hierarchical module relationship a child module is encapsulated by a parent module.

context

A context is a set of name-value pairs shared among views, which are defined by and only meaningful to the application. The Splunk.Context class encapsulates context getter and setter operations. Context is instantiated when a view is created and modules share context to communicate search and event changes. The Splunk.Module class provides mechanisms for sharing context, such as pushing context to child modules and receiving notification of a context change.

controller (module)

(See module controller)

-D-

decorator

Python syntactic sugar that wraps a function definition. (See 7.6. Function definitions and decorator.)

-E-

entity

The MVC model consists of entities (configuration objects or similar artifacts), which are REST resources accessed using the REST API. Entities are uniquely identified by ID and have associated metadata attributes, or model fields. The SplunkRESTManager class usually represents a unique entity and provides a number of API methods to abstract the REST interface for manipulating entities. Entities can also be created and deleted.

extension point

Module System extension points are hooks for attaching custom code to extend framework functionality, for creating domain-specific applications. Extension points are presented through the API and custom functionality is usually implemented by subclassing. The API describes how and where framework functionality can be changed.

-H-

hidden module

A hidden module has no visible elements. A hidden module typically does non-UI work whose results can be rendered by various UI child modules in the module hierarchy. An example is the HiddenSearchSwapper module.

-I-

ID

MVC model entities are uniquely referenced by ID, which is a string representing the hierarchical REST API path to a configuration object or similar artifact.

Example: /servicesNS/admin/search/saved/searches

-J-

job progress

Applications might perform different actions depending on job progress, the progression of a job from initiation through completion. Job progress states are:

jobCanceled	Job has been canceled.
jobDispatched	Job has been dispatched.
jobDone	Job has completed.
jobFinalized	Job has been stopped.
jobPaused	Job has been paused.
jobProgress	Job has made progress.
jobResurrected	A search restarted the job poller.
jobStatusChanged	Job status has changed.

The Splunk.Job class provides methods for checking job progress. The Splunk.Module and Splunk.Module.DispatchingModule classes include callback methods for handling job progress changes.

-M-

Mako templates

Module views are implemented using Mako templates

metadata

Metadata are the ownership, access control, sharing, and mutability settings associated with an entity. The ObjectMetadataModel and SplunkAppObjModel classes abstract operations on resource metadata contained in model fields.

model

Definition coming soon ...

model field

A model field is an attribute associated with a given entity, as defined by the model class. Fields have the notion of mutability.

module

A module is a fundamental Module System artifact that implements application functionality, including UI artifacts; every item in a view is module. The View XML provides the structuring component that defines the relationship between application modules. A module implementation is required to have a configuration (.conf) file and client-side logic (<file>.js</file>). A module can also, optionally, include a template (.html) file, a module controller (.py) file and static content, such as style sheets and images.

module controller

A module controller is the server-side component that responds to XMLHttpRequest AJAX calls, and is analagous to the controller part of the MVC pattern. A module controller, unlike a basic Splunk controller, has the following limitations:

• Does not have access to decorators.
• Only handles GET requests.
• Cannot return a generator.

Module System

The Module System is a set of core Splunk software and architecture principles that provides large-scale reuse in creating Splunk apps and add-ons. Module System extension points provide hooks into framework module, AJAX, and MVC components and patterns, facilitating custom application development.

See also: app, add-on, module

-N-

namespace

See Mako Namespaces

-P-

parent

In the hierarchical module relationship a parent module encapsulates a child module.

-Q-

query set

Definition coming soon ...

-R-

resource

A partial resource path used to build Entity Id's (e.g. "resource = 'saved/my_object'").

result

In the context of the Module System, the result is what is returned by a job. For a search job, the result is search results.

-S-

self

Self is a Python keyword used in class instantiation that refers to the instantiated object, itself. By convention, the keyword cls may be used interchangeably with self.

-T-

template

(See Mako templates )

-V-

view

A view is a collection and layout of modules that work together, hierarchically, to give an enhanced user experience when exploring or visualizing data in Splunk. Views are configured using view XML.

View XML

The View XML provides the structuring component of the Module System that defines the relationship between application modules.