SAP Abgeleitete Rollen | Derived Roles | Rollenvererbung

(Last Updated On: 18. Dezember 2018)

Wer im SAP Umfeld mit der Umgestaltung eines geerbten Rollen- und Berechtigungskonzeptes zu tun hat, stellt sich häufig die Frage nach dem richtigen Modell. Viele Kunden nutzen den Standard der abgeleiteten Rollen (engl.: Derived Roles) noch nicht, und kopieren stattdessen die Rollen oder die Menüs innerhalb einer Rolle.

Demnach nutzen viele Kunden aus alten Zeiten noch den Workflow, dass Template-Rollen gebaut werden. Nach einer Änderung in dieser Template Rolle wird beim ersten Rollout diese in eine Kindrolle kopiert und angepasst. Später, wenn nachträgliche Änderungen am Template vorgenommen wurden und mehrere untergeordnete Rollen (Subordinate Roles) vorhanden sind, wird das Menü kopiert und die Rolle mit dem Expertenmodus neu generiert.

Das muss aber alles nicht sein, denn die SAP liefert im Standard den Workflow der abgeleiteten Rollen aus. Mit diesem Workflow ist es möglich, Eigenschaften einer übergeordneten Rolle (Superior Role) an mehrere untergeordneten Rollen (Subordinate Roles) zu vererben. Kunden setzen diesen Standard jedoch nicht um, weil sie häufig auf einige Hürden stoßen, die es zu überwinden gilt.

In diesem Beitrag werde ich einige der Fragen, die Kunden im Rahmen der Einführung eines Derived Roles Workflows haben, aufgreifen und versuchen zu beantworten. Dabei möchte ich zeigen, dass es keinen Grund für die Aufrechterhaltung eines umständlichen Copy-Paste-Szenarios mehr gibt.

SAP Rollenvererbung: Superior und Subordinate Role


Damit wir tiefer in das Thema einstiegen können, müssen wir erst einmal eine Template Rolle bzw. eine Superior Role erstellen und davon eine Kindrolle bzw. Subordinate Role ableiten. Danach werde ich aufzeigen, auf welche Probleme die Kunden zum ersten mal stoßen, wenn Sie diesen Ansatz selber versuchen.

 Das Konzept der abgeleiteten Rollen bzw. der Rollenvererbungshierarchien macht immer dann sinn, wenn

  • mehrerere Rollen sich die gleichen Autorisierungsobjekte (Authorization Oobjects) teilen, oder
  • sich in in den verschiedenen untergeordneten Rollen immer nur einzelne Feldwerte oder Organisationshierarchien (Organizational Levels) unterscheiden.

Übergeordnete Template Rolle für Ableitungskonzept


Einen solchen Fall wollen wir einmal nachstellen. Als aller erstes erstellen wir dazu eine Superior Role. Diese kann sozusagen als Eltern-Rolle angesehen werden und vererbt ihre Eigenschaften an alle untergeordneten Rollen. Dabei erstellen wir eine typische Rolle für den FI-Bereich

  1. Wir fügen dazu zunächst im Reiter Menü einige Transaktionen hinzu
  2. Im Reiter Autorisierung pflegen wir zunächst die sogenannten Vorschlagswerte. Um die Vorschlagswerte möglichst wenig anpassen zu müssen, können Sie die Standard Berechtigungsvorschlagswerte für eine Trnaskation in der SU24 anpassen.
  3. Vorschlagswerte, die wir nicht übernehmen wollen, setzen wir auf inaktiv und kopieren sie. Wir bearbeiten dann die Feldausprägungen der kopierten Vorschlagswerte. Dadurch verhindern wir, dass beim Entfernen und erneuten Hinzufügen einer Transkation im Reiter „Menü“ Vorschlagswerte wieder hinzu kommen, ohne dass wir davon Kenntnis nehmen. Dies führt in der Praxis häufig zu versehentlich zu großzügig vergebenen Berechtigungen. Wir wollen vermeiden, dass Berechtigungsobjekte in unserer Rolle den Verarbeitungsstatus „Manuell“ bekommen. Dies ist ein Hinweis auf nicht ordnungsgemäß gepflegte Rollen.
  4. Pflegen Sie alle Felder, die in den Kindrollen gleich ausgeprägt sein sollen, so dass diese den Status „gepflegt“ bzw. „Maintained“ erhalten. Alle Felder, die in den Kindrollen unterschiedliche ausgeprägt werden sollen, wie etwa der Verantwortungsbereich (RESPAREA), lassen wir ungepflegt (Status gelb)
  5. Pflegen Sie die Organisationsebenen (engl.: Organizational Levels). Organisationsebenen, die in allen Subordinate Rollen gleich sein sollen, können Sie bereits in der Superior Role pflegen. Organisationsebenen, die sich in den Ableitungsrollen unterscheiden sollen, können Sie mit einer Tilde (~) belegen.

Anlegen einer Ableitungsrolle (Derived Role)


Im nächsten Schritt legen wir nun eine Ableitungsrolle (engl.: Derived Role) an. Im Einstiegsbildschirm geben Sie dann im Feld „Ableiten von“ (engl.: Derive From) den Namen der Master Rolle an. Speichern Sie die soebene angelegte Subordinate Role.

Wenn Sie sich jetzt die abgeleitete Rolle ansehen, werden Sie feststellen, dass derzeit nur das Menü, aber nicht der Pflegestatus der einzelnen Berechtigungsobjekte, geerbt wurde. Alle Felder haben den Vorschlagswert ihrer Transaktion, aber nicht den Pflegestatus aus der Superior Role. Auch die Organisationsebenen wurden nicht geerbt.

Im nächsten Schritt wollen wir nun die Organisationsebenen, die in der Master Role gepflegt wurden, sowie den Pflegestatus der Berechtigungsobjekte, vererben. Begeben Sie sich dazu in die Template Rolle und dort in den Reiter Berechtigungen (engl.: Authorizations) und dort in den Änderungsmodus der Berechtigungsdaten. Wählen Sie nun im Menü nach Berechtigungen -> Abgeleitete anpassen -> Abgeleitete Rollen generieren (engl. Authorizations -> Adjust derived -> Generate derived roles).

Wenn Sie sich nun wieder in die Derived Role begeben, werden Sie feststellen, dass nun sowohl der Pflegestatus der einzelnen Berechtigungsobjekte, als auch die einzelnen Organisationsebenen geändert wurden.

Wichtiger Hinweis: Die Organisationsebenen werden nur von der Master Role geerbt, solange die Organisationsebenen in der Derived Role noch nicht explizit gepflegt wurden.  Nachdem Sie die Organisationsebene der Ableitungsrollen einmal anfassen, werden Änderungen an den Organisationsebenen des Templates nicht mehr runter vererbt. Dies entspricht dem gewollten Verhalten im Standard (SAP Note 314513).

Änderung in Master Role überschreibt Derived Role


Kommen wir nun zu unserem nächsten Problem. In unserem Beispiel haben wir eine Rolle erstellt, welche das Berechtigungsobjekt K_ORDER enthält. Dieses Berechtigungsfeld enthält wiederum das Feld RESPAREA, welches den Verantwortlichkeitsbereich steuert.

Im Rahmen unseres Ableitungskonzeptes möchten wir, dass in den einzelnen Subordinate Rollen dieser Verantwortlichkeitsbereich unterschiedlich ist. Wir wollen immer noch, dass Änderungen in der Master Rolle an die abgeleitete Role vererbt werden, wollen aber den in der Subordinate Rolle gepflegten Verantwortungsbereich erhalten. Dadurch wollen wir sicher stellen, dass wir beim Ändern der Master Rolle nicht die Verantwortungsbereiche aller abgeleiteten Rollen händisch nachpflegen müssen. An dieser Stelle werden Kunden häufig frustriert und fallen wieder auf ihre alten Gewohnheiten der Rollenkopie zurück.

Genau dieses Problem können Sie jedoch aktuell herstellen. Ändern Sie dazu etwas am Master Template, indem Sie beispielsweise im Reiter Menü eine neue Transaktion hinzufügen. Generieren Sie im Anschluss die von dieser Rolle abgeleiteten Rollen. Wie Sie sehen, wird der ungepflegte Zustand im Feld RESPAREA des Berechtigungsobjektes K_ORDER übernommen. Sie müssten nun den Verantwortungsbereich erneut pflegen.

Anhebung eines Berechtigungsfeldes zur Organisationsebene


Eine Möglichkeit zur Lösung dieses Problems ist die Anhebung des Berechtigungsfeldes RESPAREA zur Organisationsebene.  In diesem Fall pflegen Sie nun die Verantwortungsbereiche als Organizational Level. Dies ermöglicht es Ihnen, Menüänderungen in der Hauptrolle vorzunehmen und den Verwantwortungsbereich individuell für die Abgeleiteten Rollen konsistent zu pflegen.

Jedoch sollten Sie diesen Schritt nicht allzu leichtfertig vornehmen, denn er hat die folgenden Konsequenzen:

  • Wenn Sie ein Feld zur Organisationsebene anheben, wirkt sich dies auf alle Berechtigungsobjekte aus, welche dieses Berechtigungsfeld enthalten.
  • Dadurch hat diese Aktion automatisch eine Auswirkung auf nicht nur diese Rolle, sondern auf alle Rollen mit diesem Berechtigungsfeld

Auswirkungsanalyse der Überführung in die Organisationsebene


Um die Auswirkungen dieses Schrittes festzustellen, muss deshalb eine kurze Auswirkungsanalyse durchgeführt werden. Zunächst sollten Sie feststellen, in welchen Berechtigungsobjekten das betroffene Berechtigungsfeld RESPAREA vorkommt. Dazu können Sie die Transaktion S_BCE_68001413 (Authorization BOjects by Complex Selection Criteria) verwenden. Geben Sie in das Feld den Namen des Berechtigungsfeldes ein – in unserem Fall RESPAREA. Sie erhalten eine Liste mit allen Berechtigungsobjekten.

Im nächsten Schritt ermitteln Sie, in welchen Transaktionen die betroffenen Berechtigungsobjekte in den Berechtigungsvorschlagswerten enthalten sind. Dies können Sie in der Tabelle USOBX_C tun. Damit diese Analyse ein möglichst aussagefähiges Ergebnis liefert, sollten die Berechtigungsvorschlagswerte in Ihrem System gut gepflegt sein (SU24). Geben Sie in der SE16 im Feld OBJECT den Namen des Berechtigungsobjekts und im Feld OKFLAG ein „Y“ ein. Führen Sie die Analyse auf die Tabelle aus.

Um nun zu guter letzt noch heraus zu finden, in welchen Rollen Berechtigungsobjekte mit dem Feld RESPAREA vorhanden sind, können Sie in der Transkation SE16 die Tabelle AGR_1251 analysieren. Geben Sie dort in das Feld „FIELD“ den Namen des Berechtigungsfeldes, in unserem Fall RESPAREA, ein. Um die Anzeige gelöschter Objekte zu unterdrücken, setzen Sie im Feld „DELETED“ ein “ ungleich X“. Führen Sie die Analyse aus.

Nicht nur erhalten Sie eine Liste aller Rollen mit dem Berechtigungsfeld, sondern auch die Ausprägung des Feldes in diesen Rollen. Dadurch können Sie sehr zuverlässig analysieren, welchen Pflegeaufwand Sie durch die Anpassung der einzelnen Feldausprägungen haben. Ist es vielleicht sogar akzeptabel, dass  das Feld RESPAREA in der Master Role gepflegt wird, weil es in den meisten Rollen gleich ausgeprägt ist und daher in der Superior Role vielleicht sogar vorbelegt werden kann?

Vorarbeiten für vor der Konvertierung des Berechtigungsfeldes


Wenn Sie sich anhand der Auswirkungsanalyse für eine Anhebung des Berechtigungsfeldes zur Organisationsebene entschieden haben, gilt es die technischen Voraussetzungen zu prüfen. Grundsätzlich können Sie  alle Berechtigungsfelder zur Organisationsebene anheben, außer die in SAP Hinweis 727536 unter Frage 1 genannten. Wenn Sie auf den Bedarf stoßen, eines der in Frage 1 genannten Felder vererben zu wollen, lesen Sie den alternativen Lösungsansatz weiter unten.

Viele Berechtigungsfelder erfordern technische Basis Vorarbeiten, bevor diese zu einer Organisationsebene angehoben werden können. Im Falle des Feldes RESPAREA müssen etwa die SAP Hinweise 698401 und 565436 beachtet werden. Dabei gibt es Unterschiede, je nachdem ob Sie die Elevation über PFCG_ORGFIELD_CREATE oder über Transkation SUPO (siehe unten) durchführen wollen.

Bevor Sie die Autorisierungsfelder einer Rolle zur Organisationsebene anheben, sollten Sie einen Transport dieser Rollen und der entsprechenden Standardwerte aus der SU25 erstellen. Folgen Sie dazu den Anweisungen aus SAP Hinweis 727536, Frage 5.


Anhebung eines Feldes zur Organisationsebene


Nachdem Sie die Vorarbeiten für das Berechtigungsfeld durchgeführt haben, können Sie es mit einem Report zur Organisationsebene anheben.

  • Für Releases <750 verwenden Sie den Report 
     PFCG_ORGFIELD_CREATE (SAP Note 727536)
  • Für Releases >=750 verwenden Sie die Transaktion SUPO (SAP Note 
    2625102)

Tragen Sie den Namen des zu konvertierenden Feldes ein. Wenn Sie den Report im Testmodus ausführen, erhalten Sie zunächst eine Übersicht über alle betroffenen Rollen und die darin vorgenommenen Änderungen.

Das Berechtigungsfeld selbst ist weiterhin in den betroffenen Berechtigungsfeldern enthalten. Nun enthält dieses Feld jedoch nicht mehr einen konkreten Wert, sondern einen Verweise auf die Organisationsebene, der in unserem Beispiel $RESPAREA genannt wird.

Bei der Ausführung des Reports kann es beim Übertrag des Feldwertes im Berechtigungsobjekt zur Organisationsebene der Rolle zu logischen Abweichungen kommen. Das ist deswegen so, weil eine Organisationsbene nicht die selben Werte entgegen nimmt wie ein Berechtigungsfeld. Diese Vorkommnisse werden im Ergebnisbereicht des Reports gelb dargestellt. Die so erfassten Rollen werden für die generierung in der Transaktion SUPC vorgesehen.

Wichtiger Hinweis: Dieser Report ist mandantenbezogen und muss daher in jedem Mandanten ausgeführt werden. Das initiale Anheben der Berechtigungsfelder muss jedoch im Entwicklungsmandanten der Systemlinie geschehen (siehe SAP Note 727536, Frage 10).

Wenn Sie den Report PFCG_ORGFIELD_CREATE verwenden, sollten Sie außerdem folgende Troubleshooting Notes berücksichtigen und auf Relevanz prüfen:

  • 826871 (SAP_BASIS 700 SP00)
  • 604787 (SAP_BASIS <=620)
  • 532695 (SAP_BASIS <=620)
  • 754836 (SAP_BASIS <=640)
  • 724896 (SAP_BASIS <=640)
  • 1336674 (SAP_BASIS <=711)
  • 1247245(SAP_BASIS <=711, mit Nacharbeiten)
  • 323817 (SAP_BASIS <=711)
  • 1539557 (SAP_BASIS <=730)
  • 1502568 (SAP_BASIS <=730)
  • 1549101 (SAP_BASIS <=730)
  • 1564573 (SAP_BASIS <=730)
  • 1752992 (SAP_BASIS <=731)
  • 1739055
  • 2707782 (SAP_BASIS 731-750)
  • 1624104 (sehr wichtig, mit Nacharbeiten, SAP_BASIS <=731)
  • 2366702 (releaseunabhängig, bei Fehlermeldung „Locked by User“) + 
    2555130
  • 1572774 + 1473306 (SEM-BW <=634)
  • 1785259 (SEM-BW <=746)
  • 2238411 (SAP_BW 750 mit BPC)
  • 1659154 + 1866958 + 1660168 (GRCFND_A V1000, V1100, V8000)
  • 2358446 (GRCPIERP V1000_700 & V1100_700)

Wenn Sie die Transaktion SUPO verwenden, beachten Sie die folgenden Notes:

  • 1627197 (SAP_BASIS 750-752)
  • 2535602
  • 2166856
  • 2505291
  • 2697721

beachten Sie übergreifend außerdem die Restriktionen von SAP Note  410993 sowie
2067400.

Pflege von Organisationsebenen nach der Anhebung


Nachdem Sie das Berechtigungsfeld zur Organisationsebene angehoben haben, müssen Sie es in den einzelnen Rollen eventuell nachpflegen. Das Berechtigungsfeld RESPAREA ist ein sehr gutes Beispiel dafür. Denn im SAP-Standard kann ein Verantwortungsbereich unterschiedliche Elemente umfassen. Ein Verantwortungsbereich kann demnach auf folgende Elemente beziehen.

  • eine Kostenstellengruppe
  • eine Kostenstelle oder Kostenstellenstandardhierarchieknoten
  • einen Auftrag
  • einen Geschäftsprozess oder Geschäftsprozessknoten
  • ein Profit-Center oder einen Profit-Center-Knoten

Um diese Logik nun auch in der Organsationsebene abdecken zu können, bekommen Sie zur Pflege der Organisationsebene „Verantwortungsbereich“ eine Mehrfachselektion mit unterschiedlichen Reitern.

Beachten Sie, dass es zu Inkonsistenzen im Mapping zwischen Organisationsebenen und Berechtigungsfeldern geben kann, wenn Sie Rollen aus einem anderen System importieren bzw. hochladen. In diesem Fall müssen Sie vorgehen wir in SAP Note 727536, Frage 21 beschrieben.

Upgrade und Einspielen von Support Packages

Für Berechtigungsfelder haben Sie ursprünglich die Schritte 1 und 2a der Transaktion SU25 verwendet, müssen Sie für die Übernahme neuer Vorschlagswerte in den Organisationsebenen den Report PFCG_ORGFIELD_UPGRADE bemühen (nur wenn Sie PFCG_ORGFIELD_CREATE verwenden. Bei Verwendung der Transaktion SUPO finden Sie die Funktionalität dort integriert) und diesen einmal pro relevanter Organisationsebene im Entwicklungsmandanten ausführen (siehe SAP Note 727536, Frage 11).

Ein zur Organisationsebene angehobenes Berechtigungsfeld wieder rückgängig machen


Sollten Sie sich umentschieden haben und es für besser erachten, eine Organisationsebene wieder als Berechtigungsfeld abzubilden, können Sie dazu den Report PFCG_ORGFIELD_DELETE verwenden.

Dabei werden jedoch nicht die zuvor gepflegten Berechtigungsfeldwerte oder die Werte der Organisationsebene übernommen, sondern lediglich die Standardpflege wiederhergestellt. Es handelt sich dabei also um eine verlustbehaftete Wiederherstellung des Ursprungszustandes. Um einen Datenverlust zu vermeiden, können Sie vor der erstmaligen Umstellung über PFCG_ORGFIELD_CREATE einen Sicherungstransport der Rollen und der SU25 Werte exportieren.

Andere Lösungsmöglichkeit über Sammelrollen


Selbstverständlich können Sie das oben genannte Problem der überschriebenen Feldausprägungen in den Derived Roles auch lösen, ohne das Berechtigungsfeld auf eine Organisationsebene zu heben. In diesem alternativen Lösungsweg setzen Sie in der Hauptrolle das Berechtigungsfeld auf inaktiv, also Status gelb. Unterschied: Vorhin haben wir das zu vererbende Feld ungepflegt, also auf Status gelb, gelassen

Zusätzlich zu der Hauptrolle erstellen Sie die Ableitungsrollen sowie sogenannte Addon Rollen (auch Exception Roles genannt). Diese Exception Roles enthalten dann einzig und allein das Berechtigungsfeld mit den gewünschten Feldwerten. 

Zu guter letzt erstellen Sie eine Sammelrolle (Composite Role), in welcher Sie die Ableitungsrolle + die Exception Role mit dem gewünschten Verantwortungsbereich reinpacken. Diese Sammelrolle weisen Sie letztendlich den einzelnen Usern zu.

Dieser Lösungsansatz ist außerdem Pflicht, wenn Sie für verschiedene Organisationseinheiten in den Ableitungsrollen unterschiedliche Aktivitätsfelder pflegen wollen. Wie bereits erwähnt können bestimmte Felder, darunter das Berechtigungsfeld ACTVT, nicht auf Organisationsebene angehoben werden. Wenn Sie also beispielsweise folgendes realisieren wollen

  • Bestimmte Benutzer sollen in den Buchungskreisen 610 und 620 lesen, aber nicht verändern oder löschen dürfen
  • Sie sollen in einem anderen Buchungskreis (630 z. B.) hingegen alles dürfen

Dann bleibt Ihnen nichts Anderes übrig, als diese Aktivitäten in verschiedene Exception Roles auszulagern und den Benutzern die Template Rolle plus die jeweiligen Exception Rollen individuell bzw. über eine Sammelrolle zuzuweisen.

Diese Lösung ist außerdem empfehlenswert, wenn Sie den Lösungsansatz über die Organisationshierarchien als zu kompliziert ansehen und möglichst wenig in den Standard eingreifen wollen.

Bereits bestehendes Eltern-Kind-Rollensystem migrieren

Sie haben bereits, wie mein Kunde, ein Rollen-System, und wollen dieses nun in das Master-Derived Role Konzept überführen? Dann müssen Sie in diesem Schritt heraus finden, welche Unterschiede es zwischen der Master und der Derived Role gibt.

Nur so können Sie wissen, welche Berechtigungsfelder und Organisationsebenenfelder Sie ohne Weiteres vererben und welche Sie dann im Anschluss manuell nachpflegen müssen. Hierzu können Sie die Transaktion S_BCE_68001777 verwenden.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.