All Apps and Add-ons

Issue with PostProcessing

theouhuios
Motivator

Hello

I am trying to use Post processing and use the same search with minor changes in different searchbars using searchbar module below. But it still uses the same base search in both the searchbars. When it's able to send the base search below, I wonder why is it not able to do Postprocessing on it. Any ideas?

<!--Post Process -->
<module name="HiddenSearch" layoutPanel="panel_row1_col1"  autoRun="True">
  <param name="search">earliest=-7d@d latest=@m sourcetype="incident"| stats count by record.affectedCI</param>
  <module name="HTML" layoutPanel="panel_row1_col1" >
    <param name="html"><![CDATA[
      xxx
    ]]></param>
  </module>

  <module name="HiddenPostProcess" layoutPanel="panel_row2_col1" >
    <param name="search">sort - count</param>

    <module name="SearchBar">
      <param name="useAssistant">true</param>
      <param name="useTypeahead">true</param>
      <param name="useOwnSubmitButton">False</param>

      <module name="SimpleResultsTable">
        <param name="count">5</param>
        <param name="entityName">results</param>
        <param name="drilldown">all</param>
        <param name="displayRowNumbers">true</param>
      </module>
    </module><!-- End of SearchBar Module-->
  </module><!-- End of Search Module -->

  <module name="HTML" layoutPanel="panel_row2_col2">
    <param name="html"><![CDATA[
      xxxx
    ]]></param>
  </module>
  <module name="HiddenPostProcess" layoutPanel="panel_row3_col1" >
    <param name="search">sort - count| head 5</param>

    <module name="SearchBar">
      <param name="useAssistant">true</param>
      <param name="useTypeahead">true</param>
      <param name="useOwnSubmitButton">False</param>
      <module name="HiddenChartFormatter">
        <param name="charting.axisTitleY.text">Total and free MB</param>
        <param name="charting.count">5</param>
        <param name="charting.chart">pie</param>
        <param name="charting.chart.stackMode">None</param>
        <param name="charting.legend.placement">top</param>
        <param name="charting.chart.nullValueMode">zero</param>
        <param name="charting.axisTitleX.text">Host</param>
        <module name="JobProgressIndicator"/>
        <module name="JSChart">
          <param name="width">90%</param>
          <param name="height">250px</param>
        </module>
      </module><!-- End of Table Module-->
    </module><!-- End of SearchBar Module-->
  </module><!-- End of Search Module -->
Tags (1)

sideview
SplunkTrust
SplunkTrust

I'm not sure what you're expecting the SearchBar module to do here exactly, but at any rate I think you're misunderstanding what it does.

Also, HiddenSearch, HiddenPostProcess, SimpleResultsTable and even SearchBar are all Splunk modules not Sideview modules. Since you're already using the Sideview Utils (in the form of the HTML module) you should probably switch to using Search and PostProcess instead of HiddenSearch and HiddenPostProcess, because that will allow you to do a lot of things a lot easier and without intentions, and the docs will tell you more about all this.

but back to the SearchBar module -- SearchBar outputs the "search" key, which is the same key that Splunk's HiddenSearch module and Sideview's Search module output. So your config here has the SearchBar downstream from HiddenSearch... You might think that the SearchBar module would simply clobber the HiddenSearch module's key. However the convention in the module system here is that the SearchBar sees the value coming from upstream, and sets itself to that value. So what you'll be seeing is the SearchBars in your config will be setting themselves to the base search string from that Search module, when the page loads. And then it's the SearchBars themselves outputting that base search string further downstream.

If after the page loads, the user the changes the contents of the SearchBar and hits return, it's that modified version that operates downstream from that point, and unless there were to be another push from upstream of the SearchBar, it's as though the HiddenSearch upstream was gone at that point. Since no such push will ever come in this config, basically you're just using those HiddenSearch modules to prepopulate your SearchBar modules.

So that's what's actually happening and why. To move on to what could be happening, that might be more like what you're aiming for, let me tell you how you could be using SearchBar.

When you use Sideview Utils you use a lot of Sideview modules instead of Splunk modules - like Search instead of HiddenSearch, Pulldown instead of SearchSelectLister and so on and so forth, and you keep using about a dozen core Splunk modules like SearchBar. However Sideview Utils in general patches those core modules even so.

What Sideview Utils changes about the SearchBar, is that it also makes it output a generic key called $searchBar$, and so you can with some ingenuity wire up views where the searchBar's output is wired into just a part of a search in a downstream Search module, or where it's wired into a PostProcess module... Note that as the docs reiterate, in both of these scenarios the SearchBar has to be upstream from the module using the $searchBar$ key,

But first and foremost, I strongly recommend going back and reading the core docs in Sideview Utils. Make sure you read the "introduction to the advanced XML" page in particular, even though it is long and fairly dense; once you make it through that page and understand the two points it's making, all the examples will become much easier to read.

0 Karma

sideview
SplunkTrust
SplunkTrust

Sure. Well the SearchBar doesn't really do searches either technically. But anyway, the TextField module, with a Search module under it that references the $myTextField$ name param of that TextField, with some modules underneath that like tables/charts/etc... will certainly result in searches kicking off just fine.

0 Karma

sideview
SplunkTrust
SplunkTrust

Oh I see, have 2 or more SearchBar modules drive different postProcess searches, against a single base-search. Yea that's a little trickier, cause like I said SearchBar will clobber the base search key entirely, so the dispatched nature of the upstream search will get erased. You could try the Sideview TextField module, which has a size param you can use to turn it into a textarea. It doesn't have all the whizbangery of the SearchBar with typeahead and autoexpand and contextual help and all that, but it's a solid little textarea control, and it behaves like a sensible control.

0 Karma

theouhuios
Motivator

I was trying to use just one search for all Searchbar's. The above one didn't work. Looks like searchbar module derives its search from the base search only

0 Karma

sideview
SplunkTrust
SplunkTrust

If you're just trying to prepopulate the SearchBar, it's a lot easier to just use the 'default' param on SearchBar and delete that Search module. But yes that config in your comment looks more sensible. 😃

0 Karma

theouhuios
Motivator

Thanks for the explanation Nick. I went through the document page to understand how the data is being pushed down. But would this be the way that it will be working?


SEARCH
---> The above search is being given to the SearchBar directly.

$searchBar$|sort - count

0 Karma
Get Updates on the Splunk Community!

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...