Mit DeltaMaster 6 erscheint das Repository – das nun Repository Rollenverwaltung heißt – nicht nur in einem neuem Design, es ist auch um einige neue und mächtige Funktionen erweitert worden. Wie diese optimal genutzt werden können, wird im Folgenden beschrieben.

Allgemein

Vorbereitung

Um das Repository nutzen zu können, bedarf es einer „Grundkonfiguration“. Diese Schritte sind in den DeltaMaster deltas! 5.6.1 beschrieben.

Wer kann mit wem

Mit dem Release-Zyklus von DeltaMaster erscheinen jährlich vier Versionen mit neuen Features. Wir empfehlen generell alle DeltaMaster Komponenten auf der gleichen Versionsstufe zu installieren. Allerdings wird in der Praxis oftmals DeltaMaster 5 und DeltaMaster 6 gleichzeitig eingesetzt. Welche Version von DeltaMaster auf welche Version des Repositorys zugreifen kann, ist der Kompatibilitätsmatrix zu entnehmen.

Die Oberfläche

Mit der Einführung von DeltaMaster 6 ist das neue Layout auch in der Repository Verwaltungsoberfläche, der Repository Rollenverwaltung, angekommen. Diese wurde übersichtlicher und nutzerfreundlicher gestaltet und enthält einige neue Möglichkeiten in der Administration. Gestartet wird die Repository Rollenverwaltung jetzt separat als eigenes Programm.

Abbildung 1: Oberfläche Repository Rollenverwaltung

Die Oberfläche gliedert sich in 5 Bereiche:

Anwendungen

Abbildung 2: Anwendungen

Das Speichern in das Repository erfordert zwei Dinge:
– Die Sitzung befindet sich im Editiermodus.

Abbildung 3: Editiermodus

• In den Optionen der Analysesitzung ist die Checkbox bei Speichern in Repository und Berechtigungsverwaltung aktivieren gesetzt (siehe Abbildung 5).

Abbildung 4: Optionsdialog

Sobald eine Analysesitzung (vorhanden oder neu angelegt) im Repository gespeichert wird, sollte der Haken bei Anwendung anlegen gesetzt und ein entsprechender Name vergeben werden (siehe Abbildung 5). Erst durch Setzten dieses Hakens wird für den User die Anwendung im Repository sichtbar.

Die FileID ist ein Schlüssel, der für die Quelldatei (Analysesitzung) vergeben wird. Basierend auf dieser ID wird die Anwendung erstellt. Eine generelle Empfehlung ist, die FileID automatisch über DeltaMaster bestimmen zu lassen.
Die Anwendung kann sowohl für die Verwendung mit DeltaMaster, als auch für den Zugriff über das Web oder die App gespeichert werden.
Durch den Punkt Berichte ohne Datenwerte speichern wird ein schnelleres Abspeichern der Anwendung gewährleistet. Erst beim Start eines Berichtes in der Anwendung werden die Daten dann abgefragt.
Wird beim Speichern eine neue Anwendung angelegt, wird auch automatisch eine neue Anwendergruppe („<Anwendungsname> Administrator“) erstellt, zu der zunächst ausschließlich der speichernde Benutzer hinzugefügt wird. Diese neue Benutzergruppe wird der Anwendung in der Rolle „Anwendungsadministrator“ zugeordnet. Mehr dazu finden Sie unter 1.3.5 Zuordnung Anwendung/Anwendergruppe/Rolle.
Eine Anwendung kann aber auch „rückwärts“ erzeugt werden, d. h. es wird erst eine Anwendung angelegt und diese dann mit einer Datei verbunden.

Abbildung 6: Anlegen einer neuen Anwendung

Sobald mehrere Anwendungen gespeichert sind, kann eine logische Gruppierung mittels Gruppen er-folgen. Die einzelnen Anwendungen können dann per Drag & Drop in die dafür vorgesehenen Gruppen verschoben werden.
Ob eine Anwendung im Repository erscheinen soll oder nicht, kann mit dem Kennzeichen aktiv gesteuert werden.

Abbildung 7: Aktivieren und Deaktivieren einer Anwendung

Windows Benutzer

Hier werden (lokale bzw. Domänen-) Windowsbenutzer hinzugefügt. Neben einzelnen Benutzern können auch komplette Gruppen ausgewählt werden, was den Administrationsaufwand ab einer gewissen Zahl erheblich mindert.

Abbildung 8: Windows-Benutzer

Anwendergruppen

Im Fenster Anwendergruppen können nun die einzelnen Windowsbenutzer bzw. –gruppen zu Anwen-dergruppen zusammengefasst werden.

Abbildung 9: Anwendergruppen

Eine Zuordnung ist zwingend erforderlich, da nicht einzelne Windowsbenutzer mit Berechtigungen versehen werden können, sondern nur die hier dargestellten Anwendergruppen.
Beispiel: Es soll der User „Benutzer“ der Gruppe „Anwender“ zugeordnet werden. Beim Klick auf „Benutzer“ erscheint ein Radiobutton vor dem User und er kann einer oder mehreren Anwendungsgruppen zugeordnet werden, indem hier der entsprechende Haken aktiviert wird (siehe Abbildung 10).

Abbildung 10: Zuordnung Benutzer zu Anwendergruppe

Rollen

Die einzelnen Rollen, in DeltaMaster 5 noch Modi genannt, sind nun nicht mehr frei definierbar, sondern statisch. Folgende Rollen können zugeordnet werden:

• Berichtsempfänger:
  In diesem Modus können Berichte betrachtet werden, Elemente aus den Dimensionen ausgewählt/verändert werden.
• Berichtsredakteur:
  In diesem Modus können Berichte angelegt/editiert und die Anwendung in das Repository gespeichert werden.
• Anwendungsadministrator:
  In diesem Modus können Berichte editiert und Sitzungsberechtigungen verwaltet werden.
• Berichtsverteilung definieren:
  In diesem Modus kann ein Publisher Job angelegt und bearbeitet werden. In dieser Rolle hat der User auch implizit die Rechte des Berichtsempfängers.
• Berichtsverteilung ausführen:
  In diesem Modus können Publisher Jobs ausgeführt werden.

Die Rolle Anwendungsadministrator beinhaltet nicht automatisch Berichtsverteilung definieren und/oder Berichtsverteilung ausführen. Diese müssen bei Bedarf zusätzlich aktiviert werden.
Die Rechte gelten nur für die jeweilige Anwendung, die mit der Rolle verbunden ist (siehe nächster Abschnitt).

Abbildung 11: Rollen

Zuordnung Anwendung/Anwendergruppe/Rolle

Um nun festzulegen, welche Anwendergruppe welcher Rolle für welche Anwendung zugeordnet wird, muss immer eine fixe Auswahl von zweien der drei Teile erfolgen, um dann den noch fehlenden Part adressieren zu können.
Beispiel: Für die Anwendung Chair – Support soll die Anwendergruppe Anwender die Rolle Berichtsempfänger erhalten:

Abbildung 12: Auswahl Anwendergruppe

    1. Klick auf die Anwendungsgruppe Anwender: Radiobutton erscheint.

3. Klick auf die Anwendung Chair – Support: Radiobutton erscheint.

Abbildung 13: Auswahl Anwendungen

3. Da nun zwei Teile aktiviert worden sind, kann für diese Kombination eine Zuordnung der Rolle(n) erfolgen, indem die entsprechenden Haken gesetzt werden
Die Reihenfolge der Klicks hat keine Auswirkung, jede beliebige Zweierkombination aus Anwendung, Anwendergruppe und Rolle kann ausgewählt werden, um dann die Zuordnung zu vervollständigen.

Die Reihenfolge der Klicks hat keine Auswirkung, jede beliebige Zweierkombination aus Anwendung, Anwendergruppe und Rolle kann ausgewählt werden, um dann die Zuordnung zu vervollständigen.

Abbildung 14: Zuordnung Rolle

Dateien

Hinter dem Feld „Dateien“ steckt keine Datei im herkömmlichen Sinne, sondern der eigentliche Sitzungsinhalt, der im Repository gespeichert wird. Wenn eine bereits vorhandene .das-Datei in das Repository geschrieben wird, steht dann im Bereich „Dateien“ der ursprüngliche Dateipfad. Wird eine neue Analysesitzung in DeltaMaster angelegt, erfolgt die Verbindung auf eine Datenbank. Wird dann der Sitzungsinhalt direkt in das Repository gespeichert, erscheint unter Dateiname kein Pfad. In diesem Fall bleibt dieser Bereich leer. Ein Verschieben, Umbenennen oder Löschen der ursprünglichen Analysesitzung hat keinerlei Einfluss auf die Repository-Anwendung. Der Dateiname zeigt nur den Pfad an, an dem die Datei zu dem Zeitpunkt abgelegt war, an dem sie in das Repository gespeichert wurde.

Abbildung 15: Dateien

Beim Klick auf die Datei verändert sich das Anzeigefenster zu folgender Darstellung:

Abbildung 16: Darstellung der Optionen

Auf die Möglichkeit, Berechtigungen auf Berichte/Ordner zu setzen, wird in diesem Blogbeitrag nicht weiter eingegangen. Informationen dazu sind in weiteren Beiträgen ausführlich beschrieben.

Auf die Möglichkeit, Berechtigungen auf Berichte/Ordner zu setzen, wird in diesem Blogbeitrag nicht weiter eingegangen. Informationen dazu sind in weiteren Beiträgen ausführlich beschrieben.

Logging

Um einen Überblick zu erhalten, welcher Bericht intensiv genutzt wird oder welche Benutzer intensiv mit DeltaMaster arbeiten, kann ein Logging aktiviert werden.

Voraussetzungen

Das Logging wird aktiviert, indem man in der Datei DeltaMaster.Service.exe.config den folgenden Parameter im Abschnitt <appSettings> hinzufügt:
<add key=”Logbook” value=”X” />
X gibt den Logginglevel an, d.h.:

• 0 Nicht loggen (wie fehlender Eintrag; bisheriges Verhalten)
• 1 „Service Instances“ loggen
• 2 Wie 1 und zusätzlich „User Sessions“ loggen
• 3 Wie 2 und zusätzlich „Application Sessions“ loggen
• 4 Wie 3 und zusätzlich „Folder Activities“ und „Report Activities“ loggen

In der Repository-Datenbank werden in den Log-Tabellen abhängig vom eingestellten Level die Einträge festgehalten. Eine von Bissantz & Company vorgefertigte Analysesitzung (Logbook.das) stellt eine Auswahl an Berichten zur Verfügung, um das Nutzungsverhalten zu analysieren.