Hi community,
I did da lot of research during the last weeks on how to implement a report for the following scenario:
I have a dynamic list of subjects on which I want to run a quite complex sub-report (The report is an advanced XML view with 10+ charts and a custom layout, filling an A3 page for each subject when printed)
The dynamic list of subjects (could be servers, users, or anything else ) is the result of a splunk query
The sub-reports shall all be displayed in one View -- to be able to deliver it as a scheduled PDF
After three weeks I have the following research results:
There is currently no foreach construct in Advanced XML
There is currently no pattern to include a view in another view
Subsequently, There is no 'standard' construct for parameterizing sub-views
What I have come up with after three weeks is the following approach to implement the complex report:
As there is no foreach construct to iterate over search results, I do the search in advance and then use a regex replace pattern to generate the outer enclosing view XML, that runs the sub-reports on the particular search result items
As there is no particular include construct for including a view as sub-view into the current view, I use the IFrameInclude module for including the sub-view into the main view
The particular subject is passed to the sub-report via URL-encoded HTTP GET Parameters: <module name="IFrameInclude"> layoutPanel="messaging"><param name="src">/app/xxx/dev_single_subject_report?loggerId=myFoundLoggerId01</param></module> -- It seems that the XML display of code fragments gest somewhat mangled, if in doubt, look at the source code of this post to see what I meant
The sub-view uses the URLLoader module of the SideviewUtils app to make the HTTP GET Parameters available to the sub-view context
The sub-view runs charts on saved searches, which are then post-processed using SideviewUtils PostProcess module to filter the saved search result for the particular subject passed to the sub-view
This approach has the following disadvantages:
Due to the use of a beforehand search for the subject list of the outer view, ith dynamic is somewhat 'limited' to the manual updates of the view XML whenever the subject list changes.
Due to the use of IFrame includes the Scheduled PDF reporting is totally fragile: The emedded firefox does not correctly report when the Page has finished rendering -- it reports ist readiness whenever it has finished rendering a HTML Page containg 20+ IFrames . The Ste of the IFrames is not taken into account for this statsus and thus the page gets printed to PDF before the IFrames have finished rendering.
To fix this problem I had to patch the Python code of pdfhandler.py to specify the option -printdelay 500 (To be able to use a 500 second printdelay, the javascript code of the cdlineprint firefox plugin must be patched, as it normally limits the value of this option to 120 seconds). After this patch, the PDF server unconditionally waits 5000 seconds for firefox to finish rendering the iframes and then starts to print the firefox page to PDF. To be able to use this for Scheduled PDF reports, several timeouts along the call chain of the scheduler need to be adjusted to take the long duration of PDF rendering into account. I'm not sure whether the next update might break this fragile chain, but that is the best approach I was able to find
The JSChart module sporadically fails to render the result of a post-processed saved search, which sporadiacally results into the SideviewUtils HTML module displaying the search result and the JSChart radial gauge next to it (rendering the same search result) failing to even show the result. Not very useful ina fully-automated scenario. This has been confirmed by Splunk to be a bug in JSChart [1]
I hope some splunk experts in the community have some Ideas on how to improve this approach or show a completely different approach
[1] :http://splunk-base.splunk.com/answers/46481/jschart-using-sideview-in-431
... View more