Bigfix Web Reports Data Flow

Does anyone know or have a document of how the Web Reports server caches data. In other words, how does data flow into web reports when the WR server is on the root server and remote from the root server.

We are still have a problem with WR cache becoming corrupt, and WR reporting erroneous data. Support thinks that it is a network issue.

It looks like the SQL database used by Web Reports just stores report configurations in XML, users, roles, favorite reports, etc.

It looks like the actual data that is queried is stored in SQLite database files in:

F:\Program Files (x86)\BigFix Enterprise\BES Server\BESReportsData\mybigfixserver.my.domain\PropertyResults

It looks like refreshing the cache causes the web reports server to open a connection over 52311 to the BigFix Server.

These connections are HTTP get requests over 52311 in the format of:

http://mybigfixserver:52311/external-site-data?siteName=BES+Support&siteID=1

It seems to do this for each site available and it downloads the site contents into this directory:

F:\Program Files (x86)\BigFix Enterprise\BES Server\BESReportsServer\wwwroot\SiteData\mybigfixserver\Sites

I haven’t been able to figure out if it uses http for obtaining the actual fixlet/device results though – it could be that query is occasionally timing out on your BigFix server though

You might be able to look at the PropertyResults, FixletResults, etc to see what the date is on them?

1 Like

Development claims that the problem is a network error as seen from the Web Reports log. Since our Bigfix Server is virtual with virtual storage and the database is on a remote server, all data movement is over the network. We don’t have a problem with the console, just Web Reports. It seems that Web Reports is not handling an error condition and recovering.

Have looked into Antivirus scan exceptions? I wonder if there is some locking going on.

1 Like

The Bigfix directories are excluded from AV scanning.

1 Like

Just looking for the sole ones :smile:

How about file compression or indexing?

It is really strange that the console does not also have the same issue.

It should be the same way, but more complicated the more things are separated.

Does the WebReports server / service have read access to the remote BFEnterprise DB and the ability to connect to it? I’m not certain, but I thought it needed to read it directly for some things.

CC: @dexdexdex

I think prior to 8.2 Web Reports used a direct SQL connection but after 8.2 it switched to using an authentication token (stored in dbo.data_sources in BESReporting and dbo.SERVERDATA_SESSIONS in BFEnterprise) meaning web reports gathers all data over 52311 and thus from the root server application and not directly from the database

1 Like

Here is the final answer to the problem from development.

We see the following error:

CAUGHT EXCEPTION ON BACKGROUND THREAD: Error

414 – Request-URI Too
Long



A background server data exception occurred for datasource xxxxxx (yyyyyy)
: Error

414 –
Request-URI Too Long

This kind of error is due to requests returning back data larger than the WebReports line buffer admitted value (the default is 32768) and prevents WRs from successfully completing the refresh and it causes WRs to show old or inaccurate data.

The WRs request length can be configured and increased to avoid the error, setting the key _BESRelay_HTTPServer_MaxRequestLineLength.

So, please, on WebReports systems (stand-alone and local to the Root Server) set the Client setting _BESRelay_HTTPServer_MaxRequestLineLength =
65536.
If the problem continues, keep increasing the value until the issue is resolve. We ended up with a value of 163840 which is significantly greater than the default of 32768.