Module logic flow

The main concept of nested modules is that parent (upstream) modules affect child (downstream) modules. Looking at the first panel, the full module flow is as follows:

<module name="ExtendedFieldSearch"> 
<module name="TimeRangePicker"> 
<module name="SubmitButton"> 
<module name="HiddenSearch"> 
<module name="ViewstateAdapter"> 
<module name="HiddenFieldPicker"> 
<module name="JobProgressIndicator"> 
<module name="EnablePreview"> 
<module name="HiddenChartFormatter"> 
<module name="JSChart"> 
<module name="ConvertToDrilldownSearch"> 
<module name="ViewRedirector"> 
<module name="ViewRedirectorLink"> 

A reference to the modules installed in your instance of Splunk is available at /modules. In my case, the full URL is as follows:

http://localhost:8000/en-US/modules

Let's step through these modules in turn and discuss what each of them accomplishes:

• ExtendedFieldSearch: This provides a textbox for entry. The parameters for this module are complicated and represent arguably the most complicated aspect of advanced XML intentions. Intentions affect child modules, specifically HiddenSearch. We will cover them in the Using intentions section.
• TimeRangePicker: This provides the standard time picker. It affects child HiddenSearch modules that do not have times specified either using param values or in the query itself. The precedence of times used in a query is as follows:
  • Times specified in the query itself
  • Times specified via the earliest and latest param values to the search module
  • A value provided by TimeRangePicker
• SubmitButton: This draws the Search button and fires off any child search modules when clicked on.
• HiddenSearch: As we saw before, this runs a query and produces events for downstream modules. In this case, autoRun is set to false so that the query waits for the user.
• ViewstateAdapter: A viewstate describes what settings a user has selected in the GUI, for instance, sort order, page size, or chart type. Any time you change a chart setting or pick a time range, you create a viewstate that is saved by Splunk. This module is used to access an existing viewstate or to suppress specific viewstate settings. By suppressing specific settings, the default or specified values of child modules will be used instead. This module is rarely needed unless you are using a saved search with an associated viewstate.
• HiddenFieldPicker: This module limits what fields are accessible by downstream modules. This is useful when we run a query that produces many fields but only certain fields are needed. This affects the fields shown below events in an events listing or the columns displayed in a table view. This module is rarely needed.
• JobProgressIndicator: This module displays a progress bar until the job is completed. In this case, because of the placement of the module in XML, it appears above the results. This module does not affect downstream modules, so it can be listed on its own.
• EnablePreview: This module allows you to specify whether searches should refresh with incomplete results while the query is running.
  The default appears to be true for Splunk-provided modules, but this module allows you to control this behavior. This module does not affect downstream modules, so it can be listed on its own.
  Disabling the preview can improve the performance dramatically but it provides no information until the query is complete, which is less visually appealing, particularly during a long-running query.

• HiddenChartFormatter: This module is where the chart settings are specified. These settings affect any child modules that draw charts.
• JSChart: This draws a chart using JavaScript. Prior to Splunk 4.3, all charts were drawn using Flash. The FlashChart module is still included for backward compatibility.
• ConvertToDrilldownSearch: This module takes the values from a click on a parent module and produces a query based on the query that produced the results. This usually works, but not always, depending on the complexity of the query. We will build a custom drill-down search later.
• ViewRedirector: This module accepts the query from its upstream module and redirects the user to use viewTarget with the query specified in the URL. Usually, flashtimeline is specified as viewTarget param, but it could be any dashboard. The query affects a HiddenSearch or SearchBar module.
• ViewRedirectorLink: This module sends the user to a new search page with the search results for this module.

Thinking about what we have seen in this flow, we can say that modules can do the following things:

• Generate events
• Modify a query
• Modify the behavior of a downstream module
• Display an element on the dashboard
• Handle actions produced by clicks

It is also possible for a module to do the following:

• Post-process the events produced by a query
• Add custom JavaScript to the dashboard