We’re testing BigFix Explorer and have it installed on same server that we currently use for WebReports “REST API Calls”
Everything is working fine however we notice strange issue with our WebReports REST API Calls, when both services are running (BigFix Explorer/WebReportsServer) and we initiate REST API Query again WebReports then it does return less records then if BigFix Explorer is not running.
Simple query is to list all managed PC’s which should total around 126,000
If BigFix Explorer is running it only returns anywhere from 20,000 - 30,000 records, from the moment we stop the BigFix Explorer service it returns the correct number of records. The REST API calls are targeted against WebReports instance so not using BigFix Explorer to retrieve data.
I’ve also opend case with HCL Support but wanted to check here if somebody has come accross similar issue.
I’m using BigFix version 11.03.x and both WebReports/BigFix Explorer are installed on Windows 2022 DataCenter.
Thx!
If you’re using REST API with the root server as the endpoint, then queries will automatically be sent to Explorer instead of Web Reports if there is an Explorer instance running. But we’d expect the same results from both services.
I think the first step is to determine which service is correct - is Explorer giving too few results, or Web Reports giving too many?
Hi Jason,
Indeed we’re sending the queries to root server as the endpoint, what I’m not aware of is that if both instances are running Explorer would process the request. I really thought you needed to use the Explorer URL. In that case explorer is not giving enough data as I’ve mentioned before. Could this be because the instance is not yet full loaded ?
When I run https://bfexplorerinstance:9383/api/status it does return ‘online’ I don’t think it does process any request while status is ‘starting’
Jason,
I migh have found the issue for discrepancy in data. Problem was that certain properties we retrieve do not exists for every OS Flavor, for some reason in WebReports it did not cause any problems, however with BigFix Explorer the query just stopped processing data.
I’ve make sure now to add following logic to each property “<propertyName” | “not found” if property does not exists it will return “Not found” I’ve done successful test and managed to retrieve 22k records.
This brings me to my next question (If I may 
) The speed of processing data. When running Rest API query the time it takes to process it using BigFix Explorer vs. WebReports is quiet different for the same query I’m getting below results
Web Reports: 2-3 minutes
BigFix Explorer: 1 hour
Is this expected behavior? I’m fine if it would take a bit longer (few minutes) to process data but in this case it’s difference of 1 hour for the same query.
Query that I’m using
(id of it, name of it, last report time of it, value of results from (BES Property “_PG_Serial_Number”) of it | “not found”, value of results from (BES Property “_PG_BigFix_Discovery”) of it | “not found”,
value of results from (BES Property “_PG_Marimba_Install_Date”) of it | “not found”,operating system of it | “not found”,
(if (value of results from (BES Property “_PG_CurrentIPAddress”) of it | “not found”) as string as lowercase contains “not found” then (concatenation “|” of (it as string) of ip addresses of it | “not found”) else (value of results from (BES Property “_PG_CurrentIPAddress”) of it | “not found”)),
value of results from (BES Property “_PG_MAC_Address”) of it | “not found”, agent version of it | “not found”, value of results from (BES Property “_PG_Manufacturer”) of it | “not found”,
value of results from (BES Property “_PG_Model_Name”) of it | “not found”, value of results from (BES Property “_PG_Model_Number”) of it | “not found”,value of results from (BES Property “RAM”) of it | “not found”,
value of results from (BES Property “Device Type”) of it | “not found”, value of results from (BES Property whose (name of it as lowercase = “dns name” AND reserved flag of it)) of it | “not found”,
value of results from (BES Property “Total Size of System Drive”) of it | “not found”, CPU of it | “not found”, value of results from (BES Property “Free Space on System Drive”) of it | “not found”,
value of results from (BES Property “_PG_BIOS_UUID”) of it | “not found”,value of results from (BES Property “_PG_Computer_Type”) of it | “not found”,value of results from (BES Property “_PG_Last_User”) of it | “not found”,
value of results from (BES Property “_PG_CurrentSiteID”) of it | “not found”, concatenation “|” of names of bes computer groups whose (name of site of it=“ActionSite”) of it | “not found”,
value of results from (BES Property “CPU Count”) of it|“not found”,value of results from (BES Property “CPU Core Count”) of it|“not found”,value of result from (bes property “OS Type - Windows”) of it|“not found”,
value of result from (bes property “Kernel version / OS Release - Unix”) of it|“not found”)
of bes computers
Thx!
That definitely does not sound right. In fact the reason we built Explorer in the first place is to enable more API-focused implementations that did not need the extra weight or attack surface of a Web Reports instance. In terms of tooling, Explorer behaves closer to a BESConsole cache than the UI-focused Web Reports.
That said, the behavior you’re describing (where a computer drops out of the result if it had not reported a result for a property) is actually the expected behavior; I would expect you would have needed to apply your workaround for a query result from Web Reports as well.
As for the performance - are you comparing the new query on both Web Reports and on Explorer, or are you comparing the original query on WR to the new query on Explorer?
I see your new query can be made much more efficient. What’s happening now, is that for every computer result, it is repeating the lookup of the property definition for each property. Read through the technique at Efficient Session Relevance Query for Computer Properties to make this much more efficient by looking up the property definitions just once, and the retrieving each computers’ results for that property directly.
I’m afraid I’m away from computer for now and I can’t refactor this on my phone, but I’m very confident you can get a much faster result from refactoring the query.
That said, I’d like to hear your use-case if you want to use Explorer but not make it the default for processing REST API queries. If you engage with Support I think we do have ways to direct the root back to Web Reports by default, but I’d discourage it because Explorer should be more robust in most cases.