Firstly, see my pastebin
sourcetype=applog source!=*jboss-*GA/* | transaction transactionid keepevicted=t | fields _time, ResponseType, RequestType, PlatformName, ErrorMessage, exception, exception_message
search ResponseType="ERROR_SERVER" | table _time, RequestType, exception, exception_message, ErrorMessage
search ResponseType="ERROR_UNKNOWN" | table _time, ErrorMessage, PlatformName, exception
Neither Table module shows results for its respective PostProcess.
I know some questions are going to come up regarding why I'm doing it this way. I understand my method of accomplishing this may not be the best, so please offer suggestions for improvement.
Why am I just grabbing transaction'ed events for my base search? The data I need to display won't appear in the event that has ResponseType=ERROR_SERVER or ResponseType=ERROR_UNKNOWN. It will appear in another event with the same transactionid. If you can think of a better way to put the data together, please tell me.
Why am I using keepevicted=t? No clue. I don't get results when I don't have that in there. Educate me?
Why am I adding fields at the end of my base search? Per the PostProcess documentation in the Sideview app, Splunk will discard fields from the base search that it has deemed unimportant. By explicitly telling Splunk that I want those fields, I think that should bypass that problem. Maybe I'm wrong?
So yeah, no idea why I'm not getting results. Running the base search in combination with the PostProcess does yield results. Help?
I would just back up and check basic assumptions. This dashboard runs over last 4 hours, so make sure when you run the combined baseSearch+postProcess search in another window, that the timeranges match. And make sure your field extractions are actually in the same app as the dashboard. I know these are kind of obvious suggestions but I suspect it'll be something like that. I put together a little testcase for this, basing it off your example but running against _internal data, with transaction and postprocess etc, it worked fine.
It's good you checked by running the baseSearch concatenated with the postProcess search. That is a great sanity check.
Maybe change the "fields" to "table" in the base search, but like I said I just ran a little testcase here and it seemed fine... Maybe try and see if rigging up a similar example but against internal data works... transaction might be doing something really weird in your particular data. =/
There was also a lot of unnecessary nesting and redundant JobProgressIndicators in that XML so I cleaned it up for you here:
All that redundant nesting wasn't really having a negative effect but it makes the XML look way more complicated.