Bewegungsdaten mandantenbasiert vorzuhalten, stellt in der OLAP-Entwicklung keine große Herausforderung dar. Der Mandant ist nur ein weiteres Merkmal, welches es als Dimension zu modellieren gilt. Die Sache wird weniger trivial, wenn Stammdaten mandantenabhängig im Berichtsfilter in DeltaMaster angezeigt werden sollen. In diesem Blogbeitrag geben wir einen Überblick über ein Lösungskonzept zur Realisierung einer mandantenfähigen Anwendung, skizzieren die notwendigen Modellierungsschritte im Modell, beschreiben die vorgenommenen Einstellungen in DeltaMaster und wägen mögliche Alternativen ab. Abschließend schildern wir, wie das beschriebene Lösungskonzept auch für andere Problemstellungen herangezogen werden kann.

ERP-begeisterte Anwender kennen sie nur zu gut: Mandantenfähige Anwendungen. Nicht selten unterscheiden Unternehmen innerhalb ihrer Organisation oder sogar organisationsübergreifend zwischen unterschiedlichen Einheiten. Sollen alle diese Einheiten nun Zugriff auf eine DeltaMaster-Anwendung erhalten, kommt der Begriff „Mandantenfähigkeit“ unweigerlich ins Spiel.

Der Arbeitskreis Technik der Konferenz der Datenschutzbeauftragten des Bundes und der Länder definiert Mandantenfähigkeit wie folgt:

„Der Begriff „Mandant“ oder „Mandantenfähigkeit“ wird häufig verwendet, wenn es Unternehmen, Behörden oder Organisationen ermöglicht werden soll, Daten in einer Datenbank logisch zu trennen und zu verwalten. Mit Hilfe der Mandantenfähigkeit können z. B. Daten verschiedener Abteilungen einer Organisation / eines Unternehmens oder verschiedener Kunden eines IT-Services / Rechenzentrums getrennt vorgehalten werden.“[1]

Obwohl diese Thematik schon länger ein Begriff ist, stellte sie doch einige Herausforderungen an die Konzeption, wenn zum ersten Mal eine mandantenfähige DeltaMaster-Anwendung realisiert werden soll.

Unterteilung: Berechtigungen und Sichtkontext

Vielleicht keimt in so manchem Leser schon jetzt der Gedanke: „Moment, das kann man doch alles über Berechtigungen im OLAP-Würfel lösen!“. Die Antwort darauf ist ein ganz klares „Jein“. So kann es vorkommen, dass beispielsweise das Controlling Zugriff auf Kostenstellen und Sachkonten mehrerer Mandanten haben muss. Kostenstellenleiter hingegen sind nur in einem Mandanten aktiv. Hier wäre das Steuern über Berechtigungen möglich. Für einen User, der in beiden Mandanten berechtigt ist, ist es jedoch verwirrend im Filter Sachkonten auswählen zu können, die gar nicht zum ausgewählten Mandanten gehören. Es muss also deutlich zwischen einer Sicherheitsfunktion (die unbedingt notwendigen Berechtigungen) und einer Komfortfunktion (eingeschränkter Filterkontext) unterschieden werden.

Anforderungen an das Datenmodell

Klar, Bewegungsdaten mandantenfähig zu machen, ist eine leichte Übung. Schnell das Modell um eine Mandantendimension erweitern, die Schlüssel in der Faktentabelle pflegen, fertig. Etwas anders sieht das Ganze aber aus, wenn es um Stammdaten geht. Auch hier gilt natürlich: Durch das Ausblenden von leeren und Null-Zeilen entfallen im Bericht die Elemente, die zu anderen Mandanten gehören schon allein durch die Zuordnung der Bewegungsdaten. Dies trifft jedoch nicht auf den DeltaMaster Berichtsfilter zu. Hier werden für die Auswahl des Filters stets alle verfügbaren Elemente angeboten. Das zugrundeliegende Datenmodell muss also einige zusätzliche Anforderungen erfüllen:

–   Wie in Punkt 1 kurz angedeutet, sollte ein Berechtigungskonzept vorhanden sein, um das Anzeigen von Daten generell je nach User einzuschränken. In diesem Beispiel wurde dafür eine zusätzliche Measuregruppe angelegt, bei der ein Flag bestimmt, ob ein User auf einen Mandanten berechtigt ist.

–  Um die Kostenstellen und Sachkonten mandantenabhängig anzuzeigen, müssen beide Dimensionen ein Merkmal aufweisen, welches Aufschluss über den Mandanten gibt. In diesem Beispiel wurde dafür ein Attribut modelliert (Abbildung 1). Der Inhalt des Attributes deckt sich mit dem Schlüssel der Mandantendimension, welcher per .MemberKey angesprochen werden kann.

Abbildung 1: Dimensionsattribute
 

Berichtsmappe

Um sicherzustellen, dass ein User nur Daten zu Mandanten sehen kann, auf die er auch berechtigt ist, wird zunächst mit Hilfe von Visual Studio oder dem SQL Server Management Studio eine OLAP-Rolle angelegt. Diese wird folgendermaßen erweitert (Rolle=>Dimensionsdaten=>Dimension Mandant=> Attribut MandantID):

NonEmpty(
 DESCENDANTS(
        [Mandant].[MandantID]
   )
   ,(
       StrToMember("[Benutzer].[Benutzer].[Benutzer].&[" + USERNAME() + "]"
       )
       ,[Measures].[Flag]
     )
)

Die Abfrage prüft, ob zu der Nutzer-Mandantenkombination ein Eintrag in der Berechtigungsmeasuregruppe vorhanden ist. Ist dies der Fall, darf auf den Mandanten zugegriffen werden.

Ist ein User auf mehrere Mandanten berechtigt, führt diese Lösung dazu, dass er beim Öffnen des Berichtes die Daten von mehreren Mandanten auf einmal sieht. Wird dies nicht gewünscht, kann beispielsweise das folgende Defaultelement in den Berichtseigenschaften definiert werden:

[Mandant].[Mandant].[Mandant].Members.item(0)

Benutzer, die Zugriff auf mehrere Mandanten haben, dürften alle Dimensionselemente bei Sachkonten und Kostenstellen sehen. Es ist jedoch verwirrend, wenn man bereits einen Mandanten A ausgewählt hat und im Filter immer noch Sachkonten für Mandanten B auswählen kann. Hierfür kann eine benannte Menge definiert werden, welche dann im Filterkontext die Elementauswahl einschränken soll. Dazu wird das unter Punkt 2 beschriebene Mandantenattribut genutzt:

 FILTER(
        DESCENDANTS(
		[Sachkonto].[Sachkonto].[Alle Sachkonten]
		,[Sachkonto].[Sachkonto].[Sachkonto]
	)
	,[Sachkonto].[Sachkonto].CurrentMember.Properties("Sachkonto_Mandant") = 
<view3>.Member_Key
)

<view3> ist in dem zugrundeliegenden Modell der aktuell gesetzte Mandantenfilter.

Analog wird mit der Kostenstellendimension verfahren:

FILTER(
	DESCENDANTS(
		[Kostenstelle].[Kostenstelle].[Alle Kostenstellen]
		,[Kostenstelle].[Kostenstelle].[Kostenstelle]
	)
	,[Kostenstelle].[Kostenstelle].CurrentMember.Properties("Kostenstelle_Mandant") = 
<view3>.Member_Key
)

Unter den Berichtseigenschaften wird nun noch die benannte Menge zur Einschränkung des Filterkontextes ausgewählt:

Abbildung 2: Elementauswahl im Filterkontext einschränken

 
Abbildung 3: Benannte Menge auswählen

Wie auf Abbildung 2 ersichtlich, wurde der Filterkontext für Sachkonten und Kostenstellen auf diese Weise eingeschränkt. Außerdem wurde für den Mandanten die Mehrfachauswahl deaktiviert, da diese nicht sinnvoll ist und mit der hier beschriebenen Filtereinschränkung auch nicht funktioniert. Ist eine Mehrfachauswahl gewünscht, so muss die benannte Menge wie folgt angepasst werden:

GENERATE(
	{<view3>}
	,FILTER(
		DESCENDANTS(
			[Sachkonto].[Sachkonto].[Alle Sachkonten]
			,[Sachkonto].[Sachkonto].[Sachkonto]
		)
		,[Sachkonto].[Sachkonto].CurrentMember.Properties("Sachkonto_Mandant") = 
[Mandant].[Mandant].CurrentMember.Member_Key
	)
)

Mit diesen Einstellungen werden, wenn beispielsweise der Mandant A ausgewählt ist, für die Sachkonten nur zugehörige Elemente als Filter angeboten (Abbildung 4).

Abbildung 4: Mandantenabhängige Anzeige im Berichtsfilter

Alternativen

Vor der Implementierung dieses Ansatzes wurden einige Alternativen in Erwägung gezogen:

Modellierung über Hierarchieebenen

Um die Auswahl im Berichtsfilter übersichtlicher zu gestalten, wurde als erster Lösungsansatz die Modellierung über Hierarchieebenen implementiert. Somit muss zunächst beispielsweise in der Sachkontenhierarchie als erste Ebene ein Mandant ausgewählt werden, um dann die entsprechenden Sachkonten anzuzeigen. Dieser Ansatz wurde verworfen, da bei mehreren mandantenabhängigen Dimensionen die Auswahl häufig wiederholt werden muss. Tritt zudem neben dem Mandanten ein zusätzliches einschränkendes Merkmal auf (z.B. jahresabhängige Kontenpläne), können diese ohne viel Aufwand in den dynamischen Filterkontext eingebaut werden und sorgen nicht für eine zusätzliche Ebene in der Dimension.

Berechtigungen

Da die beschriebene Lösung ein Einrichten des Filterkontextes in jedem Bericht erfordert, wurde im Rahmen der Implementierung die Möglichkeit überprüft, ob das gewünschte Ergebnis mit Berechtigungen oder Berechnungen im SSAS-Cubescript gelöst werden kann. Diese Überlegung stößt schnell an eine Grenze: Der in DeltaMaster ausgewählte Filter für den Mandanten ist dem Cube bei der Abfrage der Dimensionselemente nicht bekannt. Erst beim Anzeigen des Berichtes greift die WHERE-Bedingung für den Mandanten. Somit lässt sich keine allgemeingültige „Regel“ im Cube erstellen, die dynamisch auf den Mandantenfilter reagiert.

Fazit und Ausblick

Dieser Blogartikel zeigt an einem kleinen Beispiel, wie mit wenigen Handgriffen im Datenmodell und einigen Definitionen im DeltaMaster mandantenfähige Anwendungen entstehen können. Beim Lesen dieses Artikels ist dem Einen oder Anderen aber sicher schon in den Sinn gekommen, dass sich der Ansatz nicht nur für Mandantenfähigkeit nutzen lässt. Der dynamische Filterkontext kann beispielsweise auch genutzt werden, um eine zeitabhängige, geographisch bedingte oder kundenabhängige Anzeige von Elementen zu realisieren. Wichtig ist jedoch: Der Filterkontext muss in jedem Bericht definiert werden. Die Auslagerung der MDX-Abfragen als benannte Mengen empfiehlt sich deshalb dringend.

Darüber hinaus ist es zwingend notwendig, mit einem wasserdichten Berechtigungskonzept im OLAP-Modell sicherzustellen, dass Daten nur mandantenübergreifend betrachtet werden können, wenn der User entsprechend berechtigt ist. Die Einrichtung des Filterkontextes ist nur als Komfortfunktion zu betrachten. Für mehr Informationen zu der dynamischen Anzeige im Filterkontext empfiehlt sich die Lektüre der 155. Ausgabe der DeltaMaster clicks.

[1] https://www.baden-wuerttemberg.datenschutz.de/wp-content/uploads/2013/04/Mandantenf%C3%A4higkeit.pdf