Dashboards & Visualizations

What is the proper way for listening SearchManager results in JavaScript

harshpatel
Contributor

I tried the following ways:

Way 1: One method is to run search and wait for its results is as follows:

require([
    "splunkjs/mvc/searchmanager",
    "splunkjs/mvc/simplexml/ready!"
], function (
    SearchManager
) {
    // search to run
    var defaultTableSearch = new SearchManager({
        id: "populate-default-table",
        preview: true,
        cache: true,
        search: mvc.tokenSafe(`##your search query here##`)
    });
    // fetch results from search
    var defaultResults = defaultTableSearch.data("results");

    // wait for the search to return results
    defaultResults.on("data", function () {
        var data = defaultResults.data();
        // do something with data...
    });
});

Problem with Way 1: With the above method, if our search doesn't result in any data then it will not trigger on("data" ...); at all.

Way 2: One other solution may be to listen onto search:done event on search manager
Problem with Way 2: it's not guaranteed we will get results immediately after that event gets triggered.

Is there something wrong I'm doing or something I'm missing?

Note: Blocking search solves this but I want to find a proper way to do it asynchronously.

Thanks.

==================================================================================================
Edit:
I was missing two arguments for search:done callback function from which I can fetch the results as follows:

defaultTableSearch.on("search:done", function (state, job) {
        if (state.content.resultCount === 0) {
            console.log("no results");
        } else {
            // Get the job from the server to display more info
            job.fetch(function (err) {
                // Get the results and display them
                job.results({}, function (err, results) {
                    // do something with results...
                    console.log(results);
                });
            });
        }
    });
1 Solution

jeffland
SplunkTrust
SplunkTrust

The proper way to listen for result events is using defaultTableSearch.data("results").on("data", callback). If you need to also act if there are no results returned, a case in which the data callback is not called, you can check your search results in the search:done callback for the number of results and only run code if it is zero:

search.on("search:done", function(state, job) {
    if (state.content.resultCount === 0) {
        alert("no results");
    }
});

Refer to this answer for a past discussion.

View solution in original post

jeffland
SplunkTrust
SplunkTrust

The proper way to listen for result events is using defaultTableSearch.data("results").on("data", callback). If you need to also act if there are no results returned, a case in which the data callback is not called, you can check your search results in the search:done callback for the number of results and only run code if it is zero:

search.on("search:done", function(state, job) {
    if (state.content.resultCount === 0) {
        alert("no results");
    }
});

Refer to this answer for a past discussion.

harshpatel
Contributor

Thanks! I wish Splunk doc for its JS stack was well documented with examples like it is for other things.

0 Karma

jeffland
SplunkTrust
SplunkTrust

I couldn't agree more. Just FYI, there is a Web Framework Component Reference which at least covers the basics. It's not as good as the splunk docs though, but they set a fairly high standard.

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

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