Dashboards erlauben über einzelne Dashboard-Widgets die Auswertung und Analyse von Daten. Sie können über Steuerelemente als eigener Tab in der Anwendung oder als neuer Browser-Tab aufgerufen werden. Außerdem können sie in Ansichten oder Masken angezeigt werden. Wenn sie in Masken angezeigt werden, können sie Daten für den speziellen Datensatz filtern. Das Dashboard-Widget kann auf Seiten verwendet werden. um Dashboards anzuzeigen.
Dashboards werden im Dashboard-Designer erstellt. Eine Demonstration der vielen Möglichkeiten des Dashboards kann hier aufgerufen werden.
| Eigenschaft | Beschreibung |
|---|---|
| Name | Vergeben Sie einen Namen für dieses Element. Der Name wird in der Anwendung nirgendwo angezeigt und nur in der Anwendungskonfiguration verwendet. |
| Vor Aktualisierung schützen | Dieses Element bei Importen nicht aktualisieren. |
| Sichtbar für | Wählen Sie die Rollen oder Benutzer, die dieses Dashboard anzeigen können. Wenn Sie nichts wählen, ist das Dashboard für alle verfügbar. |
| Beschreibung | Beschreiben Sie dieses Element. |
| Cache aktivieren | Diese Option aktiviert den Cache für dieses Dashboard. Die Inhalte werden dann einige Zeit im Speicher gehalten und sind schneller verfügbar, möglicherweise aber nicht immer aktuell. Die Verwendung des Caches erhöht den Hauptspeicherbedarf des Webservers. |
| Max. Dauer (Minuten) | Anzahl Minuten, wie lange die Inhalte des Dashboards maximal im Speicher des Webservers gehalten werden, bevor sie aus der Datenbank neu geladen werden. Wenn die Inhalte für mehr als 5 Minuten nicht benutzt wurden, werden sie immer neu geladen. Das Caching berücksichtigt die Parameter und speichert das Dashboard pro Parameter (z.B. aktueller Benutzer oder ausgewählter Datensatz). |
Externe Datenquellen
In einem Dashboard kann pro Widget eine andere Datenquelle verwendet werden. Die Datenquellen können auch externe Datenquellen sein. Für den Zugriff auf externe Datenbanken müssen zusätzliche Connection Strings in der „Web.Config”-Datei” hinterlegt werden.
- Der Name der Datenquelle muss mit BA.Dashboard: beginnen.
- Das, was hinter BA.Dashboard: steht, wird dem Anwender im Designer als Anzeigename der Datenquelle angezeigt und auch als technischer Name in den Dahboard-Konfigurationen verwendet. Ändert man den, funktionieren die Dashboards nicht mehr.
- Man kann auf alle von DevExpress unterstützten Ressourcen der Datenquelle zugreifen (Tabellen, Views, Prozeduren). Dabei werden die Rechte des Datenbankbenutzers, der in der Verbindung konfiguriert wird, verwendet.
- Es können beliebig viele zusätzliche Datenbankverbindungen für Dashboard konfiguriert werden. Ihr Name muss natürlich unterschiedlich sein.
- Es wird empfohlen, die Datenbankverbindungen nicht in der „Web.Config” zu hinterlegen, sondern in einer eigenen Datei, da erstere beim Publish immer überschrieben wird. Dann müssen aber alle Datenbankverbindungen in einer eigenen Datei liegen, auch die von BA. (CustomConnections.config-Datei)
- Der Name der eigene Datei mit Verbindungen muss mit Custom beginnen, da sie sonst bei Publish gelöscht wird. (Vorausgesetzt es werden die korrekten, aktuellen Publish-Regeln mit Aussnahme für Custom.* verwendet.)
- Änderungen an den Verbindungen, egal ob „Web.Config” oder eigene Datei, starten die Anwendung sofort und ohne Rückfrage neu.
Beispiel:
Web.Config
<connectionStrings configSource="CustomConnections.config"/>CustomConnections.config
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=localhost;Initial Catalog=bacrm_mm3;Integrated Security=True" providerName="System.Data.SqlClient" />
<add name="BA.Dashboard:My Additional Database" connectionString="Data Source=dbservername;Initial Catalog=dbname;..." providerName="System.Data.SqlClient" />
<add name="BA.Dashboard:ConfiguredJsonConnection" connectionString="Uri=https://gorest.co.in/public/v2/users;Username=anonymous;Password=ftp@ftp.test" providerName="JsonSourceProvider" />
</connectionStrings>Zugriff auf die Anwendung
Im Dashboard-Designer steht automatisch eine Datenquelle „Local Business App Database” zur Verfügung.
Der Zugriff erfolgt über spezielle Datenbank-Views, die automatisch auf Basis der konfigurierten Datentabellen gebildet werden.
Auswahllisten
Auswahllistenwerte werden in allen konfigurierten Sprachen direkt in den Views abgebildet. Zusätzlich steht pro Auswahlliste eine spezielle View zu Verfügung, die über einen Join verbunden werden kann, um auf alle Auswahllistenwerte und spezielle Datenspalten der Auswahllistenwerte zugreifen zu können.
Hyperlinks
Ein interner Hyperlink auf einen Datensatz der BA-Instanz kann einfach über ToStr([OID]) erzeugt werden. Der Datensatz wird dadurch in einem neuen Anwendungstab geöffnet.
Interne Hyperlinks werden mit der OpenTab-Methode geöffnet und passen in ein Muster [baseurl]/OpenRecord/[contentOfTheLinkVariable]. Dies bedeutet, dass Datensätze im Dialog und über ein gewünschte Maske geöffnet werden können: (z.B. Concat(ToStr([OID]),'?openInDialog=true&form=GUID')).
Externe Hyperlinks müssen mit dem String „http” beginnen und werden immer in einem eigenen Browsertab geöffnet.
Parameter
Es stehen vier Parameter innerhalb der Dashboard-Konfiguration zur Verfügung. Wenn Sie diese für Filter verwenden, sollten Sie diese soweit möglich direkt in der Datenquelle anwenden, um eine optimale Performance zu erreichen.
| Parameter | Beschreibung |
|---|---|
| CurrentRecord_OID | Die OID des aktuellen Datensatzes, falls das Dashboard neben einer Maske angezeigt wird. |
| CurrentUser_OID | Die OID des aktuell angemeldeten Benutzers. |
| BaseUrl | Die Basis-URL der Anwendung. |
| AdditionalKey | Ein in Masken optional konfigurierbarer, weiterer Schlüssel. |
Relationen
Der EntityTitle des primären Quelldatensatzes einer Relation steht direkt in den Views zur Verfügung. Ansonsten kann über die OID direkt auf den in Relation stehenden Datensatz zugegriffen werden.
Für hierarchische Relationstypen wird jeweils eine spezielle View „VOrmHiearchyRelation_TYP” erzeugt.
Teildatensätze
Auch Teildatensätze werden als Extra Views erzeugt. Über Joins und Filter kann auf spezifische Teildatensätze zugegriffen werden.
Gelöschte Datensätze
In den Datenbank-Views sind Datensätze im Papierkorb automatisch ausgeschlossen. Die Datenbank-View „VOrmRecycleBin” zeigt Datensätze im Papierkorb und die DatentbankView „VOrmDeletedObjects” zeigt rudimentäre Informationen zu endgültig gelöschten Datensätzen. Zum Löschen gibt es hier weitere zusammenhängende Informationen.
Dashboard Caching
Das Ergebnis der in Dashboards verwendeten Datenquellen wird standardmäßig im Speicher des Servers gehalten, um interaktive Features der Dashboards zu beschleunigen und um die Datenbankserver-Last zu begrenzen.
Die Daten werden 5 Minuten nach der letzten Nutzung eines Dashboards (Öffnen oder Interaktion) verworfen. Das maximale Alter der Daten kann zusätzlich in der Dashboard-Konfiguration begrenzt werden. Dann werden die Daten auch dann neu geladen, wenn sie bis dahin mindestens alle 5 Minuten gebraucht wurden. Die maximale Haltedauer ist standardmäßig 15 Minuten.
Der Cache kann für ein Dashboard auch vollständig deaktiviert werden.
Abhängig davon, ob das Dashboard Parameter wie CurrentUser_OID oder CurrentRecord_OID verwendet, ist der Cache Benutzer und/oder sogar Datensatzabhängig. Wenn keine Parameter verwendet werden, teilen sich alle Zugriffe aller User auf das Dashboard denselben Cache. Das ist die effizienteste Lösung.
Richtlinien für den Umgang mit dem Cache
- Das Caching geht zu Lasten des Hauptspeicherbedarfs des Webservers.
- Dashboard sollten keine unnötig großen Rohdatenmengen in den Cache legen. Es sollten nur wirklich benötigte Spalten geladen werden.
- Aggregationen sind soweit möglich in der Datenquellendefinition zu konfigurieren und nicht erst in den Dashboard-Items.
- Kennzahlen der Datenquellen sollten soweit möglich eine Summenaggregation o.ä. verwenden. Optional kann dann in der Konfiguration der Items noch weiter aggregiert werden.
- Dashboards sollten keine Parameter in Datenquellen definieren, die diese nicht brauchen. Sobald eine Datenquelle z.B. den Dashboard-Parameter CurrentUser_OID definiert, wird pro BA-Benutzer ein eigener Cache für das Dashboard geführt, auch dann, wenn die Datenquelledefinition diesen Parameter nicht (mehr) verwendet. Die Existenz eines Parameters auf der obersten Ebene des Dashboards, ohne dass er irgendwo verwendet wird, hat hingegen keine Auswirkungen.
- Bei datensatzspezifischen Dashboards sollte man überlegen, ob für diese eine Deaktivierung des Caches in Frage kommt. Das gilt im Besonderen dann, wenn das Dashboard keine Interaktivität bietet und die Wahrscheinlichkeit dafür, die Daten eines Datensatzes erneut zu brauchen, deshalb gering ist.
- Das maximale Alter sollte nur in Ausnahmefällen auf sehr geringe Werte begrenzt werden.
Bei Daten, die sehr häufig gebraucht werden und die nur geringe Volatilität aufweisen (z.B. globales Dashboard auf der Startseite für alle Benutzer), sollte es auf einen möglichst großen Wert gesetzt werden. - Der Dashboard Designer verwendet keinen Cache. Deshalb ist sein Laufzeitverhalten der Worst-Case, der einem User passieren könnte. In der Regel sind die Dashboards im Viewer deutlich schneller als im Designer.