The management console is the restricted part of the service. It displays the behaviour of BesluitBron and not the data from the source platforms, as this data can be viewed by anyone without logging in.
Accessible via /login at the installation’s address. What each screen displays is shown, along with an image, at Beheer; this page describes how to use it. The console is not indexed by search engines.
What there is to see
Next to ‘Dashboard’ is another button, ‘Menu’. This opens each screen below as a tile, grouped according to its purpose, with a star icon to place a tile at the top of its own group. See Menu for those groups.
- The dashboard: displaying calls as they come in, showing their duration and volume, via a live connection;
- The request log: a list of what has been accessed over the past few days, filtered by connector. See Logging en Verantwoording;
- The analysis: usage by tool over a longer period. This reveals which questions are actually being asked;
- One explorer per connector: each tool can be called up manually, with the parameters entered into a form. This is the way to check what a tool actually returns, regardless of what an assistant makes of it;
- The configuration page: to see which sources are available and whether a fallback has been applied, see Connectorregister;
- The response cache: what has been cached for each source platform, how much data there is, how old it is, and which version of BesluitBron wrote it. See Buffering en Doorlooptijd;
- The error page: the messages and their codes;
- The trace page: every event logged by the server, from start-up to every call to a source platform and every error with its stack trace. It can be viewed on screen and downloaded as a file, so that details of a fault can be passed on to someone else. See Logging en Verantwoording.
What the explorer is designed for
To check whether the answer is correct, anyone wishing to verify an assistant’s result should call up the same tool with the same parameters in the explorer. The raw result from the source platform will then appear on the screen, including the precision fields from Zoekprecisie.
When the response cache is cleared
Rarely. A cached response is processed automatically, and a response from a previous version is automatically discarded, as described at Buffering en Doorlooptijd. Clearing the buffer is intended for cases that fall outside this scope. This occurs in two situations: a data provider has corrected data and that correction must now be visible, or an investigation is being carried out to determine whether a discrepancy in the response originates from the buffer or from the platform itself.
Clearing can be done for the entire buffer, for a single source platform, for everything stored prior to a specific date, and for content that has already expired or was from a different edition. The last two involve clearing without any consequences. The first two take time. Any response that has been discarded is retrieved from the source platform again when the next query is made. This counts towards the request limits set out at Buffering en Doorlooptijd.
The figures on the screen are measured at the moment the page is displayed, and are not stored. This is because they are read by someone who makes a decision to delete something at that very moment.
Rectifying errors
The ‘Errors’ screen shows what went wrong. For each message, the following details are provided: the requested address, the IP address from which the request originated, the browser identifier and, if logged in, the username. From version 1.3.0 onwards, this table can be cleared using the “Delete now” button. This button deletes everything older than the number of days shown next to it; the default is ninety.
From 1 March 2010, the service will also clear that table itself, every day, after ninety days. The button will remain in place for those who wish to delete a specific period earlier. Up to version 1.3.9, this was done manually: an error log entry is the only trace of a fault that no one has yet looked at, and a timer deletes it just as it becomes of interest. This approach has been reversed with version 1.3.10, because an error log entry contains an address, a browser identifier and sometimes a username, and a timeframe promised to the visitor by the system must be honoured – not based on habit. Ninety days is sufficient to identify a recurring fault.
Zero days is not permitted, as this would delete everything. The number of lines deleted appears on the screen and is recorded in the trace file. That file is therefore the only evidence that this has taken place.
Measurement and consent request
From 1 February 2017, the console uses the same visitor tracking and the same consent request as the public pages. Prior to that update, it did not use either. Anyone who answers the question on BesluitBron.nl will not be asked it again in the console. Anyone who declines tracking will not be tracked in the console either.
The system tracks which screens are opened. Up until version 1.2.24, the installation could also record sessions, capturing the administrator’s screens in the same way as those of any other visitor. This functionality has been removed, along with the setting that enabled it. Since then, what an installation tracks has been determined solely by the contents of the tag container, and the consent request relates to this. Tracking can be disabled by leaving the key under BesluitBron:Analytics blank. Without that key, the installation will not load any tracking and no consent request will appear.
From version 1.3.74 onwards, the console – just like the public screens – also tracks three types of events: the execution of a query, an unexpected error in the page’s JavaScript, and whether a visit lasts thirty minutes or spans at least ten days. None of these three events includes the content of a query or an error message. The full description can be found on the ‘Privacy and cookies’ page, to which the following paragraph refers.
From 1 February 2024, details of what data is and isn’t collected, who it is shared with and how long it is retained will be available on the public ‘Privacy and cookies’ page. This can be accessed via /nl/privacy and via the footer on every screen, including the console.
Sending a test message
The Settings screen is otherwise read-only, but features a button labelled ‘Send test message’. This sends a message directly to the mail gateway, bypassing the normal queue, to the address entered by the administrator. The result appears immediately after the button is pressed; there is no need to refresh the page.
Three separate checks are carried out, in the following order: whether the server is accessible, whether the login details are accepted, and whether the message has been accepted for delivery. A failed test also displays the gateway’s own error message, so it is clear which of the settings is incorrect. The screen does not indicate whether the message subsequently actually ends up in the recipient’s inbox, rather than in a junk folder: that is a case between the gateway and the recipient.
The server, port, username, password and STARTTLS setting are pre-filled with the configured values when the screen opens, and each of these can be changed for that particular test – for example, to try out a proposed setting before it is applied to the configuration file. The password field is the exception: it never displays the set password, so a blank password field will test using that set password and not an empty password.
The test message includes an attachment containing the time, the application and its version, the machine name and the mail gateway used, so that a recipient checking their mailbox will find something specific.
Restrictions
- The console does not display conversations with the assistant. That content does not reach the service; see Openbaarheid en Persoonsgegevens;
- The console’s language is determined by the session, not the address. After logging in, the addresses no longer include a language code;
- The console adopts the operating system’s light or dark theme.