Rollentypen und ihre Auswirkungen

Heute will ich Ihnen zeigen, welche Rollentypen es im SAP^®-System gibt.

Ja ich weiß, das ist ein alter Hut! Doch kann ich ggf. auf einige weniger bekannte Dinge hinweisen, wie man einzelne Rollentypen einsetzt, oder welche man zwar einsetzen kann, diese aber doch - gerade am Anfang des Rollenkonzepts - enorme Zusatzarbeit bescheren können.

Fangen wir also an:

1. Die Einzelrolle

Die Einzelrolle soll einmal folgendermaßen definiert werden:

Eine Einzelrolle enthält mindestens eine Transaktion mit all ihren bewerteten Berechtigungsobjekten.

2. Die Master- und Child-Rolle

Die Master- und die Child-Rollen stehen für die Möglichkeit von einer Rolle sogenannte Ableitungen zu erstellen. Diese Ableitungen unterscheiden sich nur in der unterschiedlichen Bewertung der sog. Organisationsebenen (=Org-Levels).

D.h. man erstellt eine Rolle mit einer Anzahl zugeordneter Transaktionen. Im System sind nun global sog. Organisationsebenen definiert, die in eine Rolle vom System mit einer eigenen Bewertung eingebaut werden können. Diese Organisationsebenen sind bspw. der Buchungskreis, die Einkaufsorganisation etc. Man baut sich nun eine Rolle, den sog. Master und bewertet dort die offenen Berechtigungen der Org-Levels mit bspw. "*".

Im Nachhinein werden nun für jedes Org-Level weitere Rollen definiert, die die gleichen Transaktionen und Berechtigungsobjekte haben, nur dass in ihnen die Org-Levels jeweils anders bewertet sind. Man vergibt dann noch den Inhalt Masterrolle und hat somit eine sog. abgeleitete Rolle oder eine Child-Rolle.

Der Vorteil an einer solchen Kombination von Master und Child-Rollen ist die leichte Veränderbarkeit der Rollen. Wird bspw. eine neue Transaktion in die Rolle aufgenommen, dann wird nur die Master-Rolle verändert. Die Child-Rollen - deren Struktur ja quasi vererbt wird - kann dann auf "Knopfdruck" mitverändert werden. Ja, dieses Vorgehen verbietet sogar die Veränderung der Child-Rolle, außer in den Org-Levels! Natürlich muss die Child-Rolle einen anderen Namen als die Master-Rolle besitzen.

Man kann auch - und das würde ich empfehlen - die Master-Rolle nie einem Benutzer zuordnen und hat dann eben für die Vollberechtigungen eine Child-Rolle mit den "*" Einträgen. Um zu verhindern, dass die Master-Rolle Auswirkungen bei einer fehlerhaften Zuordnung hat, bewertet man die Org-Levels der Master-Rolle mit "?".

3. Die Value-Rolle

Anders ist es bei der sog. Value-Rolle (der Werte-Rolle). Hier werden keine Transaktionen, sondern nur Berechigungsobjekte bewertet.

Eine Value-Rolle kann man dann einem Benutzer zuordnen, und er erhält zusätzlich ein bestimmtes Recht.

Voraussetzung für die Anwendbarkeit einer Value-Rolle ist natürlich, dass in den anderen, dem Benutzer zugeordneten Rollen, nicht dieses "Value-Rollen-Objekt" überlagert wird. D.h. in den Einzel- und Master-Child-Rollen werden die Objekte der Value-Rolle ausgeschaltet (inaktiviert).

So kann man z.B. in allen Rollen die Berechtigung für Up- und Download (S_GUI) inaktivieren. Damit hat zunächst kein Benutzer mehr das Recht einen Download oder Upload zu tätigen.

Definiert man nun eine Value-Rolle mit dem Recht zum Download (S_GUI ACTVT=61), und eine 2. Rolle mit dem Recht zum Upload (S_GUI ACTVT=60), dann können durch Zuordnung genau dieser beiden Rollen pro Benutzer diese Rechte - unabhängig von anderen Rollenbewertungen - gesteuert werden.

Man setzt Value-Rollen auch oft bei der Unterscheidung des Zugriffs auf bspw. der Kostenstelle oder einer Kontengruppe im System ein. Die Value-Rolle stellt somit ein Mittel dar, die Einführung eines neuen Org-Levels zu vermeiden.

4. Die Sammelrolle

Wie uns die System-Dokumentation zeigt, gibt es auch noch eine 4. Rollenart, die sog. Sammelrolle. Sie sammelt mehrere Rollen in einer Rolle, also einer Sammelrolle. Dafür gibt es in der Transaktion PFCG sogar eine eigene Funktion.

Dies hört sich gut an, doch möchte ich am Anfang des Konzeptes doch von der Sammelrolle abraten. Denn Änderungen an der Sammelrolle, bspw. wie Namensänderungen sind nur über Löschung und Neuanlage möglich, was ein erhöhter Aufwand darstellt. Überhaupt glaube ich, dass man im Konzept völlig auf Sammelrollen verzichten kann, und sie nur zu speziellen Dingen wie generell feststehendem Benutzertyp einsetzen sollte.

Man tut sich einfach leichter, bei Anpassungen.

Natürlich sollten diese Rollentypen in den Namen der Rolle einfließen, um eine Unterscheidungsmöglichkeit beim Transport und der Pflege zu haben.

So das war's gewesen zu den unterschiedlichen Rollentypen. Weitere Dinge wie Definition von Org-Levels, Unterscheidbarkeit der Rollentypen werden folgen.

Herzliche Grüße

Bernd Klüppelberg