Dashboards & Visualizations

TabSwitcher using serializeAll mode?

proctorgeorge
Path Finder

Hey Splunkers,

I was building a view that uses a HiddenSearch that populates a bunch (20+) of different SingleValue pillboxes with PostProcess for each SingleValue to par down the original search.

For the sake of organization I would like to have a TabSwitcher (or any Switcher I guess) that still utilizes the original HiddenSearch but with different SingleValue's on each Tab. I have a TabSwitcher module in independent mode that works but when you switch tabs it redoes the search (as seen by the Jobs manager).

It sounds like serializeAll mode might be what I am looking for but there is no good documentation for it, the module reference only states:

"SerializeAll mode lets you switch between different aspects of a single shared search or report. In this mode, the last child is not represented in the switcher's options and the last child tree is always visible. "

But this doesn't really tell me how to implement it. Does it mean that the last child module in the TabSwitcher module is visible to all the other tabs but does not have a tab of its own?

tl:dr

Has anyone used SerializeAll?

Tags (3)
1 Solution

sideview
SplunkTrust
SplunkTrust

I have certainly used it. However that's not what you want to do in this case.

It's not really the TabSwitcher that makes the searches re-run when you click on a tab.

Short Version: If you have a <module name="JobProgressIndicator"></module> one line before your TabSwitcher module, the TabSwitcher click will not kick off the search.

Long Version: There's a little sentence buried in the fifth bullet on the second intro page of the UI Examples app, and that little sentence is UBER important to really understanding the advanced XML well. That sentence should have been given it's own page with flashing lights and ponies. But repeating it here and expanding on it a little bit::

"As the data flows down from module to child module, at the level in the tree where the data hits the first module that actually needs the search to be running (think JobStatus/EventsViewer/FlashTimeline/etc), we kick off the search then and there. Then after the search is kicked off, at that level and at all levels further down as the data continues to flow, as long as no other module changes the search bits again, that dispatched search will get passed down as is."

Saying the same thing the other way, if a module initiates a push downstream (your TabSwitcher does this when you click a tab), and that module is holding a search that is not yet running, then the push will very likely result in a search dispatching.

As for why the one-line change described in short version above will work, the mere presence of the JobProgressIndicator at that level of the hierarchy will cause the search to already be dispatched when it hits the TabSwitcher. Therefore when the TabSwitcher itself initiates more pushes down to the Nth tab, nothing needs to be kicked off.

UPDATE: To actually answer your question about what the 'serializeAll' mode is... Sometimes you have a bunch of pulldowns and textfields and you want every one of them to contribute to one single final thing, like one chart. But there are so many pulldowns and textfields and all that, that you want to group them in sections, or tabs.

So if you take 3 groups of pulldowns and textfields, and you put them each as their own branch in a TabSwitcher, and that TabSwitcher is in "independent" mode, obviously all the modules wont contribute to a single stream of changes. You'll get three independent branches of stuff. serializeAll mode changes this. It makes the hierarchy get wired up very differently. The deepest node in the first branch is secretly rewired as the parent node of the second branch. Then the deepest node of the second branch is secretly rewired as the parent node of the third branch. And so on and so forth. And then the last branch under the 'serializeAll' switcher is where you put the FlashChart or what have you. And the last branch obviously doesnt get an actual 'tab', and actually the last branch is always visible. Hopefully that will help you understand what the docs are saying.

View solution in original post

sideview
SplunkTrust
SplunkTrust

I have certainly used it. However that's not what you want to do in this case.

It's not really the TabSwitcher that makes the searches re-run when you click on a tab.

Short Version: If you have a <module name="JobProgressIndicator"></module> one line before your TabSwitcher module, the TabSwitcher click will not kick off the search.

Long Version: There's a little sentence buried in the fifth bullet on the second intro page of the UI Examples app, and that little sentence is UBER important to really understanding the advanced XML well. That sentence should have been given it's own page with flashing lights and ponies. But repeating it here and expanding on it a little bit::

"As the data flows down from module to child module, at the level in the tree where the data hits the first module that actually needs the search to be running (think JobStatus/EventsViewer/FlashTimeline/etc), we kick off the search then and there. Then after the search is kicked off, at that level and at all levels further down as the data continues to flow, as long as no other module changes the search bits again, that dispatched search will get passed down as is."

Saying the same thing the other way, if a module initiates a push downstream (your TabSwitcher does this when you click a tab), and that module is holding a search that is not yet running, then the push will very likely result in a search dispatching.

As for why the one-line change described in short version above will work, the mere presence of the JobProgressIndicator at that level of the hierarchy will cause the search to already be dispatched when it hits the TabSwitcher. Therefore when the TabSwitcher itself initiates more pushes down to the Nth tab, nothing needs to be kicked off.

UPDATE: To actually answer your question about what the 'serializeAll' mode is... Sometimes you have a bunch of pulldowns and textfields and you want every one of them to contribute to one single final thing, like one chart. But there are so many pulldowns and textfields and all that, that you want to group them in sections, or tabs.

So if you take 3 groups of pulldowns and textfields, and you put them each as their own branch in a TabSwitcher, and that TabSwitcher is in "independent" mode, obviously all the modules wont contribute to a single stream of changes. You'll get three independent branches of stuff. serializeAll mode changes this. It makes the hierarchy get wired up very differently. The deepest node in the first branch is secretly rewired as the parent node of the second branch. Then the deepest node of the second branch is secretly rewired as the parent node of the third branch. And so on and so forth. And then the last branch under the 'serializeAll' switcher is where you put the FlashChart or what have you. And the last branch obviously doesnt get an actual 'tab', and actually the last branch is always visible. Hopefully that will help you understand what the docs are saying.

proctorgeorge
Path Finder

Awesome, very informative. Thanks for the response!

0 Karma
Get Updates on the Splunk Community!

How to Monitor Google Kubernetes Engine (GKE)

We’ve looked at how to integrate Kubernetes environments with Splunk Observability Cloud, but what about ...

Index This | How can you make 45 using only 4?

October 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...

Splunk Education Goes to Washington | Splunk GovSummit 2024

If you’re in the Washington, D.C. area, this is your opportunity to take your career and Splunk skills to the ...