Techniken im  SAP - Berechtigungswesen - Bernd Klüppelberg - ebook

Techniken im SAP - Berechtigungswesen ebook

Bernd Klüppelberg

0,0
67,99 zł

Opis

Ein Projekt in SAP durchzuführen, bedarf meist der Vergabe komplexer Zugriffsrechte. Dieser kompetente Ratgeber vermittelt Ihnen die entscheidenden Schritte zur Entwicklung und Realisierung eines Berechtigungskonzepts in SAP ERP. Lernen Sie die verschiedenen SAP-Rollentypen und Berechtigungsobjekte detailliert kennen. Lassen Sie sich anhand zahlreicher Beispiele mit SAP-bezogenen Abbildungen in die zentrale Transaktion der Rollenpflege PFCG einführen. Auch Einflussfaktoren wie die Namensgebung der Rollen, besondere Berechtigungen der SAP-Basis oder das Berechtigungstrace werden eingehend behandelt. Als besonderen Mehrwert lernen Sie die originären Tabellen kennen, auf denen die Berechtigungen im System basieren – ein Wissen, das die Arbeit ungemein erleichtert! - Konzeption und Realisierung von Berechtigungskonzepten in SAP ERP - SAP-Praxisbeispiele mit zahlreichen Screenshots - Besonderheiten wie SE16N, Z-Programme, Menühandling uvm. - Viele Tipps und Tricks aus 10 Jahren Praxis-Erfahrung Buchautor Bernd Klüppelberg ist seit über zehn Jahren als Berater im Schwerpunktthema Konzeption und Realisierung von Berechtigungskonzepten aktiv. Seine umfassenden Erfahrungen hat er in dieses Buch einfließen lassen.

Ebooka przeczytasz w aplikacjach Legimi lub dowolnej aplikacji obsługującej format:

EPUB
MOBI

Liczba stron: 183




Dr. Bernd Klüppelberg

Techniken im SAP®-Berechtigungswesen

ISBN:978-3-943546-80-4 (ePUB) 978-3-943546-79-8 (Kindle)Lektorat:Christine Weber, Anja AchillesCoverdesign:Philip Esch, Martin MunzelCoverfoto:fotalia: #41908523 © Maksim KabakouSatz & Layout:Johann-Christian Hanke

Alle Rechte vorbehalten

1. Aufl. 2014, Gleichen

© Espresso Tutorials GmbH

URL:www.espresso-tutorials.com

Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.

Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.

Feedback: Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected]

Inhaltsverzeichnis

Cover
Titelseite
Copyright / Impressum
Vorwort
1 Einführung
1.1 Zentrale Regel
1.2 Begrifflichkeiten
2 Rollentypen
2.1 Einzelrollen
2.2 Masterrollen
2.3 Abgeleitete (Child-)Rollen
2.4 Werterollen
2.5 Sammelrollen
2.6 Sonderrollen
3 Namenskonventionen
3.1 Forderungen an Rollennamen
3.2 Einflussfaktoren
3.3 Namenstest-Vorlage
3.4 Rollenkonzeption
4 Zu treffende Entscheidungen
4.1 Regelung des Tabellenzugriffs
4.2 Regelung des Programmzugriffs
4.3 Forderungen an die Entwicklung
4.4 Benutzertypen
4.5 Fazit
5 Techniken
5.1 Limits bei Rollen
5.2 Besonderheiten PFCG
5.3 Jobs für Berechtigungen
5.4 Suchtechniken
5.5 Besondere Berechtigungen aus der Basis
5.6 Kritische Berechtigungen
5.7 Z-Programme
5.8 Objekt-Pflege über dieTransaktion SU24
5.9 Menühandling
5.10 Modularisierung, Granulierung
5.11 Einführung Org-Levels
5.12 Zusammenspiel von M-, A- und V-Rollen
5.13 Benutzergruppen
5.14 Rollenzuordnungen
5.15 Rollendokumentation
5.16 Rollentest
5.17 Produktivsetzung der neuen Rollen
6 Weitere Tipps und Tricks
6.1 Export des Systemmenüs
6.2 Löschen von Rollen
6.3 Transport von Rollen zwischen Mandanten
6.4 Rollen umbenennen
6.5 Benutzerzuordnung in Rollen
6.6 Gelöschte Transaktionen aus Rollen entfernen
6.7 ACCESS-DB zur Analyse
6.8 ST01-Berechtigungstrace
7 Anhang
7.1 Wichtige Tabellen
7.2 Wichtige Transaktionen
7.3 Abkürzungen
A Der Autor
B Quellenverzeichnis
C Disclaimer
Weitere Bücher von Espresso Tutorials

Vorwort

Sie stehen als SAP-Rollen-Administrator vor der Aufgabe, all die Forderungen, die Ihnen von Wirtschaftsprüfern, Fachabteilungen und ihrer Unternehmensorganisation gestellt werden, in ein Berechtigungskonzept zu übernehmen.

Dieses Buch soll Sie als Ratgeber dabei unterstützen, indem es Ihnen die Techniken des Berechtigungswesens aufzeigt. Sie erlernen neben den Vorgehensweisen bei der Konzeption auch, welche Entscheidungen Sie in Angriff nehmen müssen, um ein beständiges Berechtigungskonzept zu erstellen und vor allem zu realisieren.

Nach einigen wichtigen Begriffsdefinitionen erhalten Sie Hinweise auf die einzelnen Einflussfaktoren, die die Namensgebung der Rollen betreffen, aber auch darauf, welche Entscheidungen global über das Konzept festgelegt werden müssen. Anschließend werden bestimmte Techniken, Tipps und Tricks sowie eine Fülle von Informationen für das To-Do dargestellt.

Seit über zehn Jahren berate ich Kunden bei der Konzeption und Realisierung von Berechtigungskonzepten. Die dabei gesammelten Erfahrungen will ich Ihnen in diesem Buch zusammengefasst darstellen, damit Sie nicht in die gleichen Fallen tappen wie ich!

Als ehemaliger Entwickler bei SAP habe ich gelernt, mich bei Problemsuchen mehr auf die originären Quellen als auf die Transaktionsdienste zu verlassen. Deshalb werden Sie in diesem Buch auch oft die originären Tabellen kennenlernen, auf welchen die Berechtigungen im System basieren. Denn das Wissen darüber erleichtert Ihnen die Arbeit ungemein. Außerdem werden Ihnen Suchtechniken nach wissenswerten Objekten vermittelt, die Sie zu manch einer geforderten Auswertung benötigen können. Doch auch die Organisation des Berechtigungswesens, die Verantwortlichkeiten und geforderten Festlegungen werden nicht zu kurz kommen.

Querverweise auf meinen »Technik-Blog Berechtigungen« (http://blog.technik.berechtigung.sybeklue.de/) geben Ihnen die Möglichkeit, dort einige Themen unterstützend nachzulesen, um die Länge dieses Buches beschränken zu können. Auf diese Weise bleibt mehr Raum für Beispiele und die Erläuterung von Techniken.

Als zusätzlichen Service habe ich für Sie eine kleine Sammlung von Vorlagen zusammengestellt, die Ihnen bei Ihrer Arbeit nützlich sein könnten. Diese Vorlagen können Sie auf der Webseite von Espresso Tutorials unter http://6000.espresso-tutorials.com herunterladen. Sie finden dort folgende Unterlagen:

Eine Vorlage für eine Protokollierung

Je eine Vorlage für eine Rollendokumentation in Excel- und Word-Format

Eine Vorlage für Rollennamen

Eine Vorlage für ein Rollentestprotokoll

Im weiteren Verlauf dieses Buches werde ich auf dieses Vorlagenverzeichnis verweisen und erläutern, wie Sie diese Vorlagen benutzen können.

Ich wünsche Ihnen mit dieser Lektüre viel Vergnügen!

Dr. Bernd Klüppelberg

Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, der diesen genauer klassifiziert:

Hinweis

Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.  

Beispiel

Beispiele dienen dazu, ein Thema besser zu illustrieren.  

Warnung

Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin  

1 Einführung

Dieses Buch beschäftigt sich mit dem klassischen Berechtigungswesen im SAP-System (SAP ERP), wobei die technischen Gegebenheiten im Mittelpunkt stehen sollen.

Ich werde nicht auf die Theorie von SOX, den »instrumentellen Organisationsbegriff« oder Richtlinien der Prüfungen eingehen. Dennoch werden wir immer mal wieder auf geforderte Kontrollen und Aufteilungen zu sprechen kommen. Wenn Sie die Prüfungsrichtlinien oder Theorie nachlesen wollen, verweise ich an dieser Stelle auf die Quellen im Literaturverzeichnis.

Die Idee zu diesem Buch kam mir (genau genommen, ist sie an mich herangetragen worden) nach dem Studium etlicher Werke über das Berechtigungswesen und den Problemen, die sich bis dahin im Umgang mit Kunden ergaben. In der Literatur fand ich kaum technische Verfahrensweisen, wie man ein Konzept erstellt, welche Forderungen und Einflussfaktoren auf ein Konzept einwirken, kurz, wenig bis keine Angaben zum »How to do«.

Dieses Buch möchte ein Ratgeber sein, denn hier soll es um die harte Technik gehen! Ich versuche dabei auf viele Eigentümlichkeiten, Tipps und Tricks einzugehen, die mir bei der Beratung von Kunden aufgefallen sind und die ich mir glücklicherweise irgendwo in meinem roten Büchlein notiert habe.

Es richtet sich an den Rollenadministrator mit den notwendigen Vorkenntnissen, stellt dabei jedoch kein Einführungsbuch für das Berechtigungswesen dar, sondern wird gleich in medias res gehen. Dargestellt wird das klassische Berechtigungswesen (PFCG), ohne auf CRM-, SRM-, BW- oder sog. strukturelle Berechtigungen einzugehen.

1.1 Zentrale Regel

Bei Fragen nach Berechtigungen müssen Sie sich und allen Kollegen – also auch Benutzern – immer folgenden Satz klarmachen:

Zentrale Regel

Das System kann nur die Berechtigungen prüfen, die auch programmiert sind.  

Dies ist ein zentraler Satz im gesamten Berechtigungswesen. Falls Sie wissen wollen, ob man eine bestimmte Funktion berechtigen kann und wie, müssen Sie aufgrund obiger Regel herausfinden, ob in den Programmen eine bestimmte Berechtigung geprüft wird. Gerade bei Eigenentwicklungen wird oft die Prüfung auf bestimmte Berechtigungen vergessen.

1.2 Begrifflichkeiten

Zunächst sollten einige Begriffe, die in diesem Buch benutzt werden, definiert werden. Da es im Berechtigungswesen eine Vielzahl unterschiedlicher Bezeichnungen gibt, die immer wieder zu Verständnisschwierigkeiten führen, dient dies der Schaffung einer gemeinsamen theoretischen Ausgangsbasis, auf der dann weiter aufgebaut werden kann.

1.2.1 Profil

Im SAP-System sind die Berechtigungen in sog. Profilen organisiert. Erst später wurden im R/3 die sog. Rollen über die Profile definiert.

Bei Rollen definiert man ein ihnen zugehöriges Profil. Dies ist ein achtstelliger Name, der entweder frei oder per Knopfdruck generiert werden kann.

Nicht zu verwechseln ist das achtstellige Profil mit der Berechtigung, welche die Profilnummer um zwei Stellen erweitert und in der Rolle bei den Berechtigungen angezeigt wird. Darauf werden wir im Einzelnen aber noch eingehen.

1.2.2 Berechtigungsfelder

Die unterste Ebene, in der Berechtigungen behandelt werden, sind die Berechtigungsfelder.

Definition Berechtigungsfeld

Ein Berechtigungsfeld(B-Feld) ist ein Feld, das die Bewertung, die Ausprägung eines zu berechtigenden Tatbestandes, ausdrückt. Das Berechtigungsfeld hat einen Namen (max. zehn Stellen) und ist im SAP-Standard mit einem Namen und einer Bedeutung definiert.

Diese Felder können auch organisatorische Beschränkungen oder Aktivitäten beinhalten, die den Zugriff beschränken. Letztlich sind es aber zunächst einmal lediglich Felder, die in einer Tabelle gespeichert sind.

1.2.3 Berechtigungswerte

Der in ein Berechtigungsfeld einzutragende Wert wird als Berechtigungswert bezeichnet.

Definition Berechtigungswert

Der Berechtigungswert (B-Wert) gibt den Wertebereich eines Berechtigungsfeldes an. Die einzelnen Werte können dabei aus bestimmten Tabellen ausgewählt oder frei vergeben werden. Hier können auch sog. Organisationsebenen-Variablen festgelegt werden, die später das Recht auf eine bestimmte Organisationsebene beschränken. Die Größe des Wertebereichs ist nahezu beliebig.

1.2.4 Berechtigungsobjekte

Die einzelnen Berechtigungsfelder kann man nun zu sog. Berechtigungsobjekten zusammenfassen. Diese werden dann auch von den Programmen auf ihre Ausprägung geprüft.

Definition Berechtigungsobjekt

Das Berechtigungsobjekt fasst einen oder mehrere (bis zu zehn) Berechtigungswerte in einem Objekt zusammen. Es stellt dann das von Programmen zu prüfende Objekt dar. Mit dem Befehl:

AUTHORITY-CHECK OBECT 'xxxx'   ID 'yyyy' FIELD 'zzzz'…………….   ID 'ACTVT' FIELD 'ww'

kann dann eine Berechtigung geprüft werden; wobei

xxxx: der Objektname,yyyy: das Berechtigungsfeld undzzzz: der Berechtigungswert ist, der an dieser Stelle verlangt wird, währendww die Ausprägung einer Aktivität darstellt.

Die Definition der Berechtigungsobjekte wird mit der Transaktion SU21 vorgenommen. Alle »kundeneigenen« Berechtigungsobjekte sollten im Namensraum Z, Y oder /…./ definiert sein. Alle nicht in diesem Namensraum definierten Felder sind Standardfelder, die nicht verändert werden sollten.

1.2.5 Berechtigungen

Eine Ausprägung eines Berechtigungsobjektes wird in Profilen und Rollen mit einer Nummer versehen, die als zweistellige Nummer an den Profilnamen angehängt wird.

Definition Berechtigung

Die Berechtigung ist eine zweistellige Nummer, die innerhalb eines Profils der Ausprägung eines Berechtigungsobjekts vergeben wird.

Innerhalb eines Profils kann man mehrere Ausprägungen des gleichen Berechtigungsobjektes als unterschiedliche Berechtigungen definieren.

Die Prüfung der einzelnen Berechtigungen werden mit einem logischen ODER verknüpft.

1.2.6 Berechtigungsklassen

Um eine Gliederung der Berechtigungsobjekte zu erzeugen, werden diese sogenannten Berechtigungsklassen zugeordnet.

Definition Berechtigungsklasse

Die Berechtigungsklasse ist ein vierstelliger Name, mit dem die Berechtigungsobjekte in einer Klasse gruppiert werden.

Zur besseren Zuordnung werden in Rollen, Profilen und der SU21 diese Berechtigungsklassen angezeigt. Dies dient aber nur der Ordnung innerhalb einer Rolle oder eines Profils.

1.2.7 Organisationsebene (Org-Level)

Eine Organisationsebene nimmt Bezug auf eine »betriebswirtschaftliche Einheit«, um ein Berechtigungsfeld auf diese zu beschränken.

Definition Organisationsebene

Organisationsebenen bzw. Org-Levels sind betriebswirtschaftliche Werte wie Buchungskreise (BuKrs), Einkauforganisation (EkOrg) etc., die in der Tabelle USVAR definiert sind. Mit ihnen werden Bewertungen von Berechtigungsfeldern versehen, um Berechtigungen bzgl. dieser Organisationseinheiten zu bewerten.

Alle diese Org-Levels beginnen mit dem $-Zeichen und werden bei sog. abgeleiteten Rollen benutzt, um Rollen von einem Master abzuleiten, die sich nur in den Org-Levels voneinander unterscheiden.

Org-Levels müssen unverändert in der Rolle stehen. Man darf diese Felder nicht verändern, da sonst die Rolle zerstört werden kann.

1.2.8 Zusammenspiel der Begrifflichkeiten (Berechtigungsprüfung)

Wie werden nun die obigen Definitionen verwendet und zusammengesetzt?

Im Zeitalter der Rolle wird eine solche aus mehreren Berechtigungsobjekten zusammengebaut. Zur Unterstützung gibt es die Transaktion PFCG, den Profil-Generator (eigentlich müsste er »Rollengenerator« heißen, doch stammt dieses Wort und damit die Abkürzung der Transaktion noch aus dem Zeitalter der Profile). Mit der PFCG werden nun alle Berechtigungen, die letztlich einem Benutzer zugeordnet werden sollen, in einer Rolle gruppiert.

Es werden in einer Rolle also Berechtigungsobjekte bewertet und der Rolle zugeordnet. Dabei werden ein Berechtigungsobjekt in die Rolle importiert, und die Berechtigungsfelder der Rolle bewertet.

Nur wenn alle Bewertungen in den Berechtigungen bewertet sind, sollte die Rolle generiert werden, und wird damit funktionstüchtig. Fehlen Bewertungen, so kann es einmal sein, dass die Org-Levels oder Berechtigungsfelder nicht bewertet worden sind. Der PFCG markiert im ersten Fall das Berechtigungsobjekt rot und im zweiten Fall gelb.

Alle markierten Berechtigungsausprägungen werden nicht aktiv, es kann also nicht auf sie geprüft werden und die Rolle ist dann nur eingeschränkt funktionsfähig!

Alle Berechtigungen werden als Profile in den sog. Userbuffer geladen, wenn sich der Benutzer anmeldet. Alle Prüfungen mit AUTHORITY-CHECK greifen auf diesen Userbuffer zu und kontrollieren, ob die Berechtigung beim Benutzer vorhanden ist oder nicht.

Dabei prüft das System wie folgt: Alle Werte innerhalb einer Berechtigung werden mit einem logischen UND geprüft, alle Einzelberechtigungen mit einem logischen ODER. Dazu möchte ich Ihnen ein Beispiel vorführen:

Ein Benutzer hat folgende Berechtigungen:

Obj1-Ausprägung 1:

Obj1-Ausprägung 2:

Obj2-Ausprägung1:

Wird jetzt das Objekt 1 mit

AUTHORITY-CHECK OBJECT 'Obj1'

   ID 'BUKRS' FIELD '002'

ID 'ACTVT' FIELD '01'

geprüft, dann prüft das System: Hat der Benutzer beim Objekt 1 die Werte ACTVT = 01 und BUKRS = 002 in der Rolle?

Somit trifft das Programm auf:

ACTVT = 02 und BUKRS = 002 ist in der Rolle => Vergleich falsch

oder ACTVT = 03 und BUKRS = 002 ist in der Rolle => Vergleich falsch

oder ACTVT = 01 und BUKRS = 001 ist in der Rolle => Vergleich falsch.

Der Benutzer hat die Berechtigung also nicht.

Prüft das Programm aber das Objekt 1 mit

AUTHORITY-CHECK OBECT 'Obj1'

   ID 'BUKRS' FIELD '001'

ID 'ACTVT' FIELD '01',

dann prüft das System: 01 und 002 in der Rolle?

Also trifft es auf:

02 und 002 ist in der Rolle => Vergleich falsch

oder 03 und 002 ist in der Rolle => Vergleich falsch

oder 01 und 001 ist in der Rolle => Vergleich ist o. k.!

Der Benutzer hat die Berechtigung! Das zweite Objekt wird hier gar nicht geprüft, weil es keinen AUTHORITY-CHECK auf dieses gibt.

Nachfolgende Tabelle 1.1 zeigt die Wahrheitstafel für ein logisches UND:

Wert 1

Wert2

Ergebnis UND

falsch

falsch

falsch

falsch

wahr

falsch

wahr

falsch

falsch

wahr

wahr

wahr

Tabelle 1.1: Wahrheitstafel logisches UND

Tabelle 1.2 zeigt die Wahrheitstafel für ein logisches ODER:

Wert 1

Wert2

Ergebnis ODER

falsch

falsch

falsch

falsch

wahr

wahr

wahr

falsch

wahr

wahr

wahr

wahr

Tabelle 1.2: Wahrheitstafel logisches ODER

Es kommt also immer auf die Zusammensetzung der Berechtigungsobjekte in der Rolle an. Sie müssen sich aber vergegenwärtigen, dass die Prüfung auf alle im Userbuffer befindlichen Profile und Berechtigungen geht.

Falls nun eine andere Rolle, die dem Benutzer zugeordnet ist, ein Objekt Obj1 mit ACTVT=01 und BUKRS=002 hat, dann tritt es im Userbuffer genauso auf, und der Benutzer hat bei Prüfung wie im Fall 2 die Berechtigung.

Der Benutzer wäre für das Anlegen (ACTVT=01) im Buchungskreis (BUKRS=002) nur dann nicht berechtigt, wenn es in seinem Userbuffer die Kombination ACTVT=01 und BUKRS=002 nicht gibt.

So können sich also Berechtigungen überlagern!

Bitte verdeutlichen Sie sich diese Beispiele, denn sie sind rudimentär für die Berechtigungsprüfung im System.

1.2.9 Bewertungen von B-Feldern

Bei der Bewertung der Berechtigungsfelder in der PFCG haben Sie die unterschiedlichsten Möglichkeiten, die ggf. aber auch einige Kniffe und Eigentümlichkeiten beinhalten.

Sie können bei

Berechtigungsfelder

einmal den genauen Wert angeben. Evtl. wird die Transaktion PFCG ihnen auch Vorschlagswerte präsentieren, die Sie nur auswählen müssen oder können.

Weiterhin gibt es den sog.

Platzhalter

als B-Wert in einem Feld, den Sie mit dem Ausdruck ' ' (also Hochkomma – Leertaste – Hochkomma) angeben können. Dieser Wert dient einerseits nur als Platzhalter, um einen beliebigen Wert in das Feld zu schreiben, andererseits gibt es aber auch Berechtigungsabfragen, die genau diesen Platzhalter abfragen.

Die Stern-Bewertung (*) gibt das volle Recht auf alle Wertausprägungen des B-Feldes. D. h. alle Rechte werden als erlaubt gekennzeichnet.

Generische Werte: Mit Ausdrücken wie AA* oder ACB* können Sie generische Werte als erlaubt setzen. Aber Achtung: Es existiert hier kein volles

pattern matching

. Ab dem Stern werden weitere Eingaben ignoriert. Dies bedeutet, dass die Werte AA*100 und AA*200 keine Wirkung haben, sondern nur AA* abgeprüft wird.

Falls Sie die Objekte sortieren, hat das System eine abweichende Sortierreihenfolge von z.B. Windows-Excel! So wird das Zeichen »_« als im Wert grösser als das Zeichen Z bewertet. Unter Windows ist das »_«-Zeichen kleiner als 0!

Sie können B-Werte auch als Intervalle angeben, doch ist auch hier Vorsicht geboten.

Ein Bereich von A* bis Z* würde doch eigentlich bedeuten, dass ZA oder ZZ in diesem Bereich enthalten ist. Dies ist aber nicht der Fall! Wie Sie gerne mit der SE16 ausprobieren können, wird hier nur bis kleiner Z geprüft und ausgegeben. Die letzte Anzeige wäre also z.B. Y___

Diese Prüfungen können leicht zu Fehlern und Verwirrungen führen.

2 Rollentypen

In alten R/3-Zeiten wurden die Berechtigungen über Berechtigungsprofile realisiert. Nachdem man merkte, dass diese Berechtigungsprofile nicht unbedingt praktikabel waren, stülpte man sozusagen ein anderes Konstrukt über diese Profile, die sogenannten Rollen, früher auch als Aktivitätsrollen bezeichnet .

Eine funktionierende Rolle hat immer auch ein Profil, das der Rolle dann die Berechtigungen zuordnet. Ein Profilname kann entweder für die Rolle gewählt oder generiert werden.

Es gibt verschiedene Ausprägungen von Rollen, wobei die einfachste die sog. Einzelrolle ist. Darunter existieren verschieden Spielarten, wie Rollen erzeugt werden können. Diese sind abhängig von Organisationsebenen – auch oft Org-Levels genannt (vgl. Abschnitt 1.2.7).

Auch bei den Rollen gibt es zu viele missverständliche Namen und Namensgebungen, sodass es auch hier bei den Rollentypen angebracht erscheint, eine einheitliche, einfache und verständliche Nomenklatur einzuführen.

Achtung!

Rollen sind im Gegensatz zu Berechtigungsobjekten mandantenbezogen!

2.1 Einzelrollen

Definition Einzelrolle

Eine Einzelrolle ist eine normale Rolle, die Transaktionen und die Berechtigungen für diese Transaktionen beinhaltet. Sie besitzt ein Rollenmenü, und alle Org-Levels sind mit gültigen Werten bewertet. Dass diese Rolle eine Einzelrolle ist, sollte aus der Namensgebung für die Rolle hervorgehen.

Eine Einzelrolle kommt immer dann zum Einsatz, wenn sich entweder die Berechtigung nicht auf Org-Levels bezieht, oder Berechtigungen – unabhängig von Org-Levels – Benutzern zugeordnet werden können.

2.2 Masterrollen

Wenn die Rechte, die einem Benutzer zugeordnet werden sollen, nur von Org-Levels abhängig sein sollen, der Benutzer sonst aber über die gleichen Zugriffsrechte verfügt, kann man das Konstrukt der Masterrolle und »abgeleiteten Rolle« benutzen.

Definition Masterrolle

Eine Masterrolle ist eine Art Einzelrolle, die Transaktionen und die Berechtigungen für diese Transaktionen beinhaltet. Sie besitzt ein Rollenmenü und alle Org-Levels sollten mit nicht-gültigen Werten (z.B. »?«) bewertet sein. Sie gibt nur eine »leere Hülle« einer Rolle an, wird selbst aber nicht zur Benutzeradministration eingesetzt.

Die Masterrolle erhält ihren Sinn erst durch die sog. Ableitung der Rolle als abgeleitete oder Child-Rolle.

Dass diese eine Masterrolle ist, sollte aus der Namensgebung hervorgehen.

Es gibt Fremdsysteme, die den Begriff der Masterrolle anders auffassen: So arbeitet Realtime-APM mit Masterrollen und Ableitungen. Letztere sind nicht auf Org-Levels beschränkt, sondern durch einen zwischengeschalteten Ableitungsordner definiert! Dieser ersetzt alle Berechtigungsfelder der Rolle. Dies hat nichts mit dem hier eingeführten Begriffen Master- und Child-Rolle zu tun, sondern stellt sich ganz anders dar.

2.3 Abgeleitete (Child-)Rollen

Durch die Bewertung der Org-Levels in der Masterrolle wird die Rolle sozusagen aktiv. Sie ist aber dann eine Rolle, welche die gleichen Transaktionen und Berechtigungsobjekte enthält wie die Masterrolle, und unterscheidet sich durch anders bewertete Org-Levels.

Definition abgeleitete Rolle

Eine abgeleitete Rolle oder auch Child-Rolle, wird aus einer bestehenden Masterrolle erzeugt. Sie enthält die gleichen Transaktionen, das gleiche Rollenmenü und die gleichen Berechtigungsobjekte wie die Masterrolle.

Der einzige Unterschied zwischen zwei Child-Rollen ist die unterschiedliche Bewertung der Org-Levels in den einzelnen Ableitungen. Somit ist es möglich, Rollen für Benutzer zu definieren, die sich nur in den Org-Levels unterscheiden.

Welche abgeleitete Rolle aus welcher Masterrolle ist, lässt sich über die Tabelle AGR_DEFINE bestimmen: Dort ist die Rolle die abgeleitete Rolle, und das Feld parent_agr ist die Masterrolle. Dass diese eine Child-Rolle ist, sollte aus der Namensgebung hervorgehen.

Zum Einsatz kommt das Konstrukt der Master- und Child-Rolle immer, wenn Benutzer zwar die gleichen Transaktionen bspw. in der Buchhaltung durchführen dürfen, ihre Rechte sich aber hinsichtlich der Bearbeitung eines bestimmten Buchungskreises unterscheiden. Benutzer A darf zwar die Transaktion FB03 (Anzeigen Beleg) aufrufen, innerhalb dieser aber nur Belege sehen, die dem Buchungskreis 002 zugeordnet sind. Für andere Buchungskreise hat er keine Zugriffsrechte.

2.4 Werterollen

Manchmal kommt es vor, dass bspw. eine betriebswirtschaftliche Größe im Standard nicht als Org-Level ausgeprägt ist. Dann kann man die Rechte für dieses Objekt auch gesondert in eine Rolle stecken und dem Benutzer zuweisen. Der Benutzer-Puffer sorgt dann dafür, dass der Benutzer das Recht über die Oder-Verknüpfung erhält. Derartige Rollen sollen hier Value- oder Werte-Rollen heißen.

Definition Value-Rolle

Eine Value- oder Werte-Rolle ist eine Rolle, die normalerweise keine Transaktionen und kein Rollenmenü enthält. Sie definiert und bewertet nur einzelne Berechtigungsobjekte, die im User-Puffer eine Berechtigung ergänzen.

Bei der Bildung einer Value-Rolle müssen in anderen Rollen ggf. Objekte inaktiviert werden, da sie sonst die Ausprägung der Value-Rolle im User-Buffer überlagern würden.

Dass diese Rolle eine Value-Rolle ist, sollte aus der Namensgebung hervorgehen.

Dazu ein kurzes Beispiel:

Sie wollen den Zugriff auf bestimmte Kostenstellen beschränken. Die Kostenstelle ist normalerweise kein Org-Level. Sie nehmen in der Masterrolle alle Objekte Kostenstelle aus der Rolle, indem sie die Objekte inaktivieren. Nun definieren Sie einige Value-Rollen, die nur das Kostenstellenobjekt beinhalten, und bewerten es unterschiedlich. Letztlich hat dann der eine Benutzer Zugriff auf Kostenstelle xx und der andere auf Kostenstelle yy!

2.5 Sammelrollen

Man kann Rollen in einer zusammenfassen und diese dem Benutzer zuordnen. Dies führt zum Begriff der Sammelrolle:

Definition Sammelrolle

Eine Sammelrolle ist im System ein eigener Rollentyp, mit dem man beliebige Rollen zu einer zusammenfassen kann. Man notiert in einer eigenen Funktionalität der Transaktion PFCG eine Sammelrolle und ordnet ihr unterschiedliche bestehende andere Rollen zu.

Damit wird es für die User-Administration ggf. leichter, einem Benutzer Rollen zuzuordnen. Dass eine Rolle eine Sammelrolle ist, ist in der Tabelle AGR_AGRS verankert.

Dass diese Rolle eine Sammelrolle ist, sollte aus der Namensgebung hervorgehen.

2.6 Sonderrollen

Der Begriff der Sonderrolle sei hier eingeführt, diese stellt keinen besonderen Typ einer Rolle dar, sondern bestimmt die Funktion der Rolle:

Funktion der Sonderrolle

Eine Sonderrolle sei eine Rolle (egal ob Einzel- oder Value-Rolle), die funktionsmäßig bestimmte Tätigkeitsrechte beinhaltet. Sonderrollen könnten bspw. Notfallrollen, RFC-Rollen, IDOC-Rollen etc. darstellen. Sie heben sich schon von dem Namen von anderen Rollen ab und beschreiben die Rechte von Funktionen.

So können Sie auch begrifflich Sonder- von sog. End-User-Rollen unterscheiden: Während die End-User-Rolle einem »normalen« Benutzer zuordenbar ist, werden Sonderrollen meist nur bestimmten Funktions-Usern zugeordnet. Diese könnten bspw. Batchuser, RFC-User etc. sein.

3 Namenskonventionen