Dieser Blogbeitrag beschreibt, wie im DeltaMaster Präsentationsmodus die Leistungen zwischen Merkmalsausprägungen verglichen werden können, obwohl der Anwender keine Leseberechtigung auf die Merkmale hat.
In vielen Anwendungen haben Benutzer eingeschränkte Berechtigungen. So dürfen z. B. Vertreter nur ihr Vertriebsgebiet, Kostenstellenleiter nur ihre Kostenstelle und Geschäftsführer nur ihre Gesellschaft im Konzern betrachten. Wie solche Berechtigungen in OLAP-Datenbanken eingerichtet werden können, beschreibt der Blogbeitrag Rollenmanagement sehr gut.
Um seine betriebswirtschaftliche Kenngrößen einzuschätzen, kann es auf der anderen Seite sinnvoll sein, sich mit anderen zu vergleichen. Der Vertreter möchte wissen, wie hoch der Umsatz je Kunde in den anderen Gebieten ist; der Kostenstellenverantwortliche möchte bestimmte Sachkosten mit der Nachbarabteilung vergleichen und der Geschäftsführer interessiert sich für die Personalauslastungsquote in den anderen Gesellschaften. So ein Leistungsvergleich – in der Betriebswirtschaft auch Benchmarking genannt – ist eine übliche Managementmethode; sie wird für DeltaMaster-Anwendungen hier dargestellt und erläutert.
Eigentlich ist es nicht möglich, sich mit Objekten zu vergleichen, für die man selbst keine Leseberechtigung hat. In diesem Blogbeitrag wird beschrieben, wie mit Hilfe der Funktion „Benutzername übertragen“ in DeltaMaster dennoch ein Leistungsvergleich trotz eingeschränkter Berechtigung möglich ist.
Seit DeltaMaster 5.6.4 ist diese Funktion in .das-Dateien und in Repository-Anwendungen für Anwendungsadministratoren im Anmeldedialog an die OLAP-Datenbank unter „Weitere Optionen“ verfügbar (vgl. Abbildung 1). Das heißt, neue Dateien/Anwendungen müssen erst einmal gespeichert und die Berechtigung vorhanden sein, sonst ist die Option nicht sichtbar.
Abbildung 1: Aktiviertes Kontrollkästchen für „Benutzername übertragen“ im Anmeldedialog von DeltaMaster
Die Auswahl dieser Option bewirkt, dass DeltaMaster in die MDX-Funktion „CustomData()“ den aktuell angemeldeten Windows-Benutzer schreibt und dieser dann in der Anwendung abrufbar ist. Dazu später mehr.
Das Setzen dieser Option ist nicht ausreichend, um auf nicht berechtigte Objekte zuzugreifen. Dafür wird zusätzlich ein Windows-Benutzer, der Vollzugriff auf die OLAP-Datenbank hat, angelegt. Dieser wird als Benutzer im Anmeldedialog eingetragen (vgl. Abbildung 2).
Abbildung 2: Zusätzlichen Benutzer im Anmeldedialog eintragen
Außerdem haken wir die Option „Automatisch mit diesen Informationen anmelden“ an, nehmen den Warnhinweis (vgl. Abbildung 3) zur Kenntnis und bestätigen ihn mit „Ja“.
Abbildung 3: Warnhinweis vor der Anmeldung an die OLAP-Datenbank
Was wurde jetzt konfiguriert? Es wurde einem Benutzer, der mehr Rechte hat als der Anwender selbst, Zugriff auf die Datenbank gewährt. Damit wird das Berechtigungssystem bewusst übersteuert. Das geschieht aber nur in dieser einen Anwendung, die gesondert verwaltet und gesichert werden muss. Wenn über einen anderen Weg als über diese Anwendung Daten abgefragt werden, wirkt das Berechtigungskonzept weiterhin so, wie es definiert wurde.
Um nun für den jeweiligen Benutzer die Berichte richtig zu konfigurieren, dient die oben schon erwähnte MDX-Funktion „CustomData()“. In dieser Funktion ist der Benutzername gespeichert, der die Anwendung gestartet hat. Diese Funktion kann z. B. als Analysewert abgefragt werden (vgl. Abbildung 4) oder in MDX-Ausdrücken verwendet werden (vgl. Abbildung 5).
Abbildung 4: Konfiguration CustomData () als Analysewert für Testzwecke
Abbildung 5: Bericht 1
Abbildung 6: Einschränkung einer Dimension über CustomData in Filterausdruck
Gerade eine Filterung in der Sicht mit einem erweiterten Sicherheitskontext macht die Anwendung sehr elegant. Es können weiterhin benutzerdefinierte Anpassungen gemacht werden, ohne jedoch auf weitere Einschränkungen achtgeben zu müssen.
Anmerkung 1: Eigentlich wurde die Implementierung der CustomData()-Funktion mit dem Benutzernamen in DeltaMaster für einen anderen Zweck eingebaut. Sie dient der Weitergabe der Anmeldeinformationen in einer Drei-Schichten-Architektur. Anwendungsfall war ein Projekt bei einem Großkonzern, der dies als Sicherheitsrichtlinie forderte. Die Anmeldeinformationen des Benutzers werden so über die Datenhaltungsschicht, die Logikschicht und die Präsentationsschicht transportiert. Mehr Informationen dazu beim Projektteam.
Anmerkung 2: In meinem Projekt hat die Umstellung auf die neue Anmeldung einen ReportServer-Job abgelöst, der nach Änderungen in einer DeltaMaster-Anwendung über mehrere Stunden die Benutzer mit den passenden .das-Dateien für ihre Standorte versorgt hat. Durch die zusätzliche Nutzung des DeltaMaster Repositorys (statt Ablage auf einem Dateisystem) gibt es jetzt nicht mehr so viele „Master-Anwendungen“. Dank der Ordnerberechtigungen konnte hier von ca. acht Vorlagen auf eine Anwendung reduziert werden.
