1.Überblick
Das ServerDashboard besteht Grundsätzlich aus drei verschiedenen Komponenten.
Als Benutzeroberfläche dient eine Blazor WebAssembly, im weiteren als „ServerDashboard“ oder GUI bezeichnet, diese stellt Daten dar, welche von der DabisServerWebAPI aufbereitet werden.
Der DabisServerWwwService ist dabei dafür zuständig das die GUI via Localhost bereigestellt wird und im Browser angezeigt werden kann.
Standardmässig wird die GUI unter http://localhost:49153/Dashboard/ bereitgestellt, die genaue URL variiert je nach Konfiguration.
2.Komponenten
2.1. GUI: ServerDashboard
Die Blazor GUI besteht im wesentlichen aus zwei Seiten welche unterschiedliche Informationen zur Nutzung anzeigen, diese Daten werden über ein SwaggerHub NuGet Paket vom DabisServerWebAPiService abgeholt. Die beiden Seiten werden in diesem Dokument nach dem GUI Überblick genauer beschrieben.
2.1.1. GUI Überblick
Hier sehen wir die vollständig geladene Default View der ServerDashboard GUI.
Im oberen Teil der Seite gibt es eine Filtersektion über welche es möglich ist die angezeigten Daten zu filtern. Dazu verwenden wir ein Dropdown über welches die Datenbank, auf welche zugegriffen wird, ausgewählt werden kann. Standardmässig wird hier die erste gefundene Datenbank selektiert, die Liste stellt sich aus allen Datenbanken zusammen welche an der aktuellen DABiS Serverinstanz konfiguriert sind.
Daneben kann der Zeitraum indem gesucht wird via DateTime-Picker eingeschränkt oder erweitert werden. Beim Verlassen der Felder wird die GUI automatisch neu geladen um die neuen Daten zu suchen und anzuzeigen.
Darunter sehen wir eine Line Chart welche die Zugriffe auf die ausgewählte Datenbank über Zeit visualisiert. Beim hovern über die einzelnen Datenpunkte wird ein Tooltip aufgeklappt welche das Datum sowie den effektiven Wert für den Punkt ausweist.
Im untersten Teil finden wir eine Datentabelle welche die Daten aus der Chart mit Text und Zahlen anzeigt, dies zum einen zur Kontrolle, zum anderen gibt es hier aber auch die Möglichkeit die Daten zu „zoomen“. Dies ist in drei verschiedene Stufen möglich: 3 Tage, 1 Woche oder 1 Monat.
Mit Klick auf den entsprechenden Link werden die Datumsfelder automatisch abgefüllt und die Daten neu geladen, dabei wird das Datum aus der Zeile immer das erste Datum des neuen „gezoomten“ Zeitraums sein. Unter der Tabelle finden wir die höchste gefundene Anzahl gleichzeitiger Verbindungen im Zeitraum.
Eine bestimmte Zeile kann auch mit der Chart gesucht werden. Indem wir auf einen Datenpunkt im Chart hovern wird die Tooltip ausgeklappt welche wir vorhin bereits gesehen haben, diese kann angeklickt werden um den dazugehörigen Eintrag in der Datentabelle kurz blau zu markieren, dieser wird automatisch in den sichtbaren Bereich gescrollt.
Im gezoomten View wird diese Mechanik besonders interessant, da wir hier alle Details des Datensatzes sehen können (Clientname, Modul, Verbindungsauf & -abbau), in der Default View sind hier neben Datum und Anzahl lediglich die Links mit welchen der Zoom eingestellt werden kann.
2.1.2. Useraccess
Die erste Seite findet sich unter dem Link Useraccess. Hier werden Daten aus der PERSONEN Tabelle einer ausgewählten DABiS Datenbank geladen und in einem LineChart visualisiert.
Standardmässig wird dabei der Zeitraum von genau einem Jahr bis zum heutigen Datum angezeigt, dies ist zugleich der grösste Zeitraum welcher vollständig mit Daten gefüllt sein kann, da die Zugriffsdaten per Löschroutine nach einem Jahr aus der PERSONEN Tabelle gelöscht werden.
Mittels DB Dropdown werden die möglichen Datenbanken angezeigt welche für den verwendeten DABiS Server konfiguriert wurden. Die aktuell angezeigten Daten werden bei der Auswahl eines Eintrages automatisch neu geladen.
Wichtig ist dabei das die Datenbank einen „Service“-Benutzer konfiguriert hat, dieser wird standardmässig für alle Zugriffe verwendet.
Mit den Feldern „von“ und „bis“ kann der Zeitraum nach dem initialen laden weiter eingeschränkt werden, werden die Felder verlassen und hat sich dabei der Wert geändert, so werden auch hier die Daten automatisch neu geladen.
Angezeigt werden die Daten in einer LineChart welche von DevExpress entwickelt wurde.
Beim Hovern über einen der Datenpunkte im Grid wird ein Tooltip aufgeklappt auf dem ersichtlich ist wieviele Clients zu diesem Zeitpunkt gleichzeitig am System angemeldet waren.
Wird der Tooltip geklickt, so wird automatisch der entsprechende Datensatz in der Tabelle in den sichtbaren Bereich gescrollt.
2.1.3. Clients
Die zweite Seite findet sich unter dem Link „Clients“. Wenn die Ansicht von der Useraccess Seite aufgerufen wird, werden die Abfrageparameter DB, Von und Bis automatisch übernommen.
Auf dieser Seite werden die Clientnamen von allen Geräten angezeigt welche sich im definierten Zeitraum am System der ausgewählten Datenbank angemeldet haben.
2.2.Service: DabisWebApiService
Die Daten welche auf der Server Dashboard GUI angezeigt werden, sind Nutzungsdaten welche in der Datenbank in der PERSON Tabelle gespeichert sind.
Diese werden von Funktionen der DabisServerWebAPIService aufbereitet und als JSON Files zur Verfügung gestellt.
Ab V3.3.2 kann der RestApiService-Endpoint in den Einstellungen unter Server -> ServerEndpoints -> RestApiService konfiguriert und aktiviert werden.
Vor V3.3.2 müssen in der ServerHost Konfiguration die entsprechenden Zeilen vorhanden sein (nicht auskommentiert). Hier kann auch konfiguriert werden auf welcher BaseAdress der Service läuft:
2.2.1. GetConcurrentAccess
Parameter
string startDate, string endDate, bool isZoomed, string dbAlias = null
URI Template useraccess/concurrent?startDate={startDate}&endDate={endDate}&isZoomed={isZoomed}&dbAlias={dbAlias}
Return Type
List<UserAccessDto>
Diese Funktion gibt die Anzahl gleichzeitiger Zugriffe für den angegebenen Zeitraum zurück, wenn der isZoomed Parameter auf False steht, werden die Daten nach Tag gruppiert, andernfalls wird die Liste ohne Gruppierung zurückgegeben.
Aus den beiden Parametern startDate und endDate wird jeweils ein Query zusammengebaut welches alle Datensätze aus der PERSON Tabelle holt welche in diesem Zeitraum Aktiv waren.
Dies beinhaltet zum einen Datensätze die im Zeitraum starten und enden, zum anderen aber auch Edgecases welche vor dem Zeitraum anfangen und danach enden, oder aber vor dem Zeitraum anfangen und währenddessen enden.
In der PERSON Tabelle kann es Datensätze haben welche nur ein Start und kein Enddatum aufweisen, für diese speziellen Fälle (Computerabsturz, Beenden via Task Manager, Application Freeze, etc.) wird eine Sessionlaufzeit von zwei Stunden angenommen.
Die Resultate dieses Querys müssen anschliessend zur Anzeige aufbereitet werden, dazu wird zu jedem Tag im Zeitraum die Anzahl gleichzeitig angemeldeter Clients errechnet und zusammen mit dem Datum in ein JSON File gepackt welches per GET Request an die GUI geliefert wird.
2.2.2. GetDistinctAccess
Parameter
string startDate, string endDate, string dbAlias = null
URI Template
useraccess/clients?startDate={startDate}&endDate={endDate}&dbAlias={dbAlias}
Return Type
List<string>
Diese Funktion holt ebenfalls Daten aus der PERSON Tabelle, hier interessieren uns allerdings nicht die Anzahl Zugriffe, sondern die Clients welche im Zeitraum effektiv angemeldet waren.
Auch hier wird die Query gleich zusammengebaut um alle Daten inkl. Edgecases zu holen, die Resultate werden dann aber mit einem DISTINCT Statement gefiltert damit Pro Client nur ein Eintrag in den Resultaten zu finden ist.
Die Resultate werden per GET Request als JSON an die GUI geliefert.
2.2.3. UserAccessDto
Der Objekttyp mit welchem Concurrent Zugriffe von der WebAPI zurückgegeben werden enthält einige Methoden um die Personen Einträge aus der Datenbank zu übersetzen und als JSON Serialisieren zu können. Serialisiert werden folgende Eigenschaften:
string startDate, string endDate, string clientName, string module, int clientCount
2.3. Service: DabisServerWwwService
Ab Version 3.3.2 kann der WwwService-Endpoint in den Einstellungen unter Server -> ServerEndpoints -> WwwService konfiguriert und aktiviert werden.
Vor Version 3.3.2 muss in der DabisServerService.exe.config ein HttpEndpoint konfiguriert werden, welcher die Anfragen der entsprechenden Subdomain entgegen nimmt.
Im ausführenden Verzeichnis wird jeweils nach einem Order mit demselben Namen wie der im Request mitgegebenen Subdomain gesucht, wird kein explizites File verlangt, wird darin nach einer index.html Datei gesucht.