HRPAD00AUTH_CHECK (BAdI: Kundeneigene Berechtigungsprüfungen) 
HRPAD00AUTH_CHECK (BAdI: Kundeneigene Berechtigungsprüfungen)
Definition
Business Add-In (BAdI), mit dem Sie die SAP Standardberechtigungsprüfung für Personalstammdaten und Infotypen durch eine kundenindividuelle Berechtigungsprüfung ersetzen können.Verwendung
Wenn Anforderungen an die Berechtigungsprüfung für Stammdaten-Infotypen weder mit der Standardauslieferung noch mit einem kundeneigenen Berechtigungsobjekt abgebildet werden können, besteht (ab Release 4.6C) die Möglichkeit, die kompletten Berechtigungsprüfungen modifikationsfrei auszutauschen. Hierzu wird die Business Add-In (BAdI)-Technik benutzt. Das BAdI für die Stammdatenberechtigungsprüfung hat den Namen HRPAD00AUTH_CHECK.
Sie finden das Business Add-In (BAdI) im Einführungsleitfaden (IMG) des Personalmanagements unter Personaladministration ® Werkzeuge ® Berechtigungsverwaltung ® BAdI: Kundenindividuelle Berechtigungsprüfung einrichten. In der Dokumentation zur entsprechenden IMG-Aktivität finden Sie Informationen zur Implementierung des BAdIs.
Sobald für dieses BAdI eine Implementation aktiv ist, werden alle (!) Stammdatenberechtigungsprüfungen des Standards nicht mehr prozessiert, sondern stattdessen die aktivierte Implementation ausgeführt.
Die Implementierung des BAdIs erfolgt mit der Transaktion SE19.
In diesem Zusammenhang sollte darauf hingewiesen werden, dass in dieser Transaktion manchmal der Zugriff auf die Dokumentation nicht korrekt funktioniert. Wenn dies der Fall zu sein scheint, kann über die Transaktion SE18 über das BAdI (hier: HRPAD00AUTH_CHECK) bzw. mit der Transaktion SE24 über die entsprechende Schnittstelle (hier: IF_EX_HRPAD00AUTH_CHECK) auf die Dokumentation zugegriffen werden: Über einen Doppelklick auf den Interface-Namen gelangt man aus der Transaktion SE18 bzw. SE19 in die Transaktion SE24, wo der Zugriff auf die jeweiligen Methodendokumentationen möglich ist.
Um den vielen Anforderungen an die Berechtigungsprüfung gerecht zu werden, wurde die Schnittstelle IF_EX_HRPAD00AUTH_CHECK relativ offen gehalten. Die folgenden Methoden stehen zur Verfügung und müssen alle implementiert werden:
CHECK_MAX_INFTY_AUTHORIZATION
CHECK_MAX_LEVEL_AUTHORIZATION
CHECK_MAX_SUBTY_AUTHORIZATION
CHECK_MIN_INFTY_AUTHORIZATION
CHECK_MIN_LEVEL_AUTHORIZATION
CHECK_MIN_SUBTY_AUTHORIZATION
SET_ORG_ASSIGNMENT
SET_PARTIAL_ORG_ASSIGNMENT
CHECK_AUTHORIZATION
CHECK_MAX_PERNR_AUTHORIZATION
CHECK_MIN_PERNR_AUTHORIZATION
CHECK_PERNR_AUTHORIZATION
DELAYED_CONSTRUCTOR
Wenn Sie nur eine Änderung einer speziellen Teilfunktion der Standardberechtigungsprüfung vornehmen möchten (z.B. eine geänderte Zeitlogik), bietet sich als einfachste Vorgehensweise an, die im Standard verwendete Klasse CL_HRPAD00AUTH_CHECK_STD zu kopieren, anschließend die (kundeneigene) Kopie den speziellen Erfordernissen anzupassen und dann als BAdI zu aktivieren (siehe auch
Beispiel). Ein fragwürdiger Ansatz wäre es, hierzu nur die Methode CHECK_AUTHORIZATION anzupassen. Dies mag in manchen Fällen funktionieren, aber durch eine solche Anpassung sind häufig automatisch auch Änderungen an den anderen Methoden nötig.Struktur
In diesem Abschnitt wird ausgeführt, welche Rolle die verschiedenen Methoden der Schnittstelle IF_EX_HRPAD00AUTH_CHECK bei der Berechtigungsprüfung spielen. Die Methodenschnittstellen selbst sind im System an den entsprechenden Methoden als Dokumentation hinterlegt. Bei einer Neuimplementierung oder Änderung der Methoden sollte die jeweilige Methodendokumentation beachtet werden.
Diese Methode ist die zentrale Methode der Berechtigungsprüfung auf Stammdaten-Infotypen. Bei jeder Berechtigungsprüfung auf Einzelsatzebene wird diese Methode prozessiert.
Bei der Implementierung ist zu beachten, dass diese Methode auch bei Einstellungsmaßnahmen prozessiert wird, insbesondere kann es vorkommen, dass zu dem Zeitpunkt, zu dem die Methode prozessiert wird, zu den Infotypen Maßnahmen 0000 und Organisatorische Zuordnung (0001) noch keine Datensätze auf der Datenbank vorhanden sind.
Bei der Implementierung ist auf ein korrektes Zusammenspiel mit den Methoden ..._ORG_ASSIGNMENT zu achten.
Diese Methode wird von Anwendungen gerufen, die bereits alle Datensätze des Infotyps Organisatorische Zuordnung (0001) gelesen haben und vermeiden möchten, dass diese Daten in der Berechtigungsprüfung nochmals nachgelesen werden. Diese Methode dient ausschließlich der Performance-Optimierung.
Da während Einstellungsmaßnahmen die organisatorische Zuordnung nur teilweise bekannt ist, ist eine "normale" Berechtigungsprüfung nicht möglich, da die hierzu benötigten Daten im System noch nicht bekannt sind. Um wenigstens grob prüfen zu können, übergibt die Anwendung die jeweils bereits bekannten Felder des Infotyps Organisatorische Zuordnung (0001) mit dieser Methode an die Berechtigungsprüfung.
Diese Methode wird von Anwendungen aufgerufen, die wissen möchten, ob ein Benutzer eine "Maximalberechtigung" für ein Berechtigungslevel besitzt, d.h. ob er für das vorgegebene Berechtigungslevel auf alle Infotypen und alle Personalnummern zugreifen darf.
Wenn diese Methode zu dem Ergebnis
Das Ziel dieses Methodenaufrufs ist immer eine Performance-Optimierung, d.h. die Methode soll möglichst schnell eine grobe Aussage liefern. Abgesehen von der Performance ist es aus Berechtigungssicht deshalb harmlos, wenn die Methode immer
IS_AUTHORIZED = FALSE liefert, da die entsprechenden Anwendungen dann weitere Prüfungen durchführen. Kritisch ist es dagegen, wenn die Methode für Benutzer mit zu wenig Berechtigungen IS_AUTHORIZED = TRUE liefert, da dann Zugriffe ohne weitere Berechtigungsprüfungen ermöglicht werden. Insbesondere ist es also wichtig, dass diese Methode entweder passend zur Methode CHECK_AUTHORIZATION implementiert wird, oder immer IS_AUTHORIZED = FALSE zurückgibt.Weiterhin gehen Anwendungen, die diese Methode rufen, davon aus, dass die Antwortzeit deutlich unterhalb einer Sekunde liegt. Deshalb sind insbesondere Implementationen an dieser Stelle unangebracht, die tatsächlich die Berechtigungen für alle Personalnummern im System überprüfen.
Diese Methode wird ähnlich verwendet wie die Methode CHECK_MAX_LEVEL_AUTHORIZATION. Der Unterschied besteht lediglich darin, dass es sich hierbei um die Anfrage handelt, ob ein Benutzer für einen vorgegebenen Infotyp und ein vorgegebenes Berechtigungslevel eine "Maximalberechtigung" besitzt. Die Anmerkungen zur Methode CHECK_MAX_LEVEL_AUTHORIZATION sind hier analog gültig.
Hier gilt das gleiche wie bei Methode CHECK_MAX_INFTY_AUTHORIZATION, nur wird hier nach der Maximalberechtigung für den Subtyp eines Infotyps und ein vorgegebenes Berechtigungslevel abgefragt.
Diese Methode wird von Anwendungen aufgerufen, die ermitteln möchten, ob ein Benutzer eine "Minimalberechtigung" für ein Berechtigungslevel besitzt, d.h. ob er für das vorgegebene Berechtigungslevel auf wenigstens einen (nicht notwendig existierenden) Datensatz eines Infotyps für eine Personalnummer zugreifen dürfte.
Wenn diese Methode zu dem Ergebnis
Das Ziel dieses Methodenaufrufs ist es, Benutzer möglichst früh von Zugriffen abhalten zu können, d.h. ein Benutzer soll z.B. nicht bei jeder Funktion, die er ausführt, den Zugriff verweigert bekommen, sondern gegebenenfalls die entsprechende Transaktion gar nicht erst starten können. Wie bei den Maximalprüfungen genügt es, schnell eine grobe Aussage zu bekommen. Abgesehen von Performance- und Bedienbarkeitsgesichtspunkten ist es aus Berechtigungssicht deshalb unbedenklich, wenn die Methode immer
IS_AUTHORIZED = TRUE liefert, da die entsprechenden Anwendungen dann ohnehin weitere Prüfungen durchführen. Kritisch ist es, wenn die Methode IS_AUTHORIZED = FALSE für Benutzer zurückliefert, die doch über geeignete Berechtigungen verfügen, da dann Zugriffe bereits im Vorfeld verweigert werden. Insbesondere ist es also wichtig, dass diese Methode entweder passend zur Methode CHECK_AUTHORIZATION implementiert wird, oder immer IS_AUTHORIZED = TRUE zurückgibt.Auch hier gehen Anwendungen, die diese Methode rufen, davon aus, dass die Antwortzeit dieser Methode deutlich unterhalb einer Sekunde liegt. Deshalb sind insbesondere Implementationen, die tatsächlich so lange nach einem Datensatz einer Personalnummer suchen, für den eine Berechtigung vorliegt, an dieser Stelle unangebracht.
Diese Methode wird ähnlich verwendet wie die Methode CHECK_MIN_LEVEL_AUTHORIZATION. Der Unterschied besteht lediglich darin, dass es sich hierbei um die Anfrage handelt, ob ein Benutzer für einen vorgegebenen Infotyp und ein vorgegebenes Berechtigungslevel eine "Minimalberechtigung" besitzt. Die Anmerkungen zur Methode CHECK_MIN_LEVEL_AUTHORIZATION sind hier analog gültig.
Hier gilt das gleiche wie bei der Methode CHECK_MIN_INFTY_AUTHORIZATION, nur wird hier nach der Minimalberechtigung für einen Subtyp eines Infotyps und ein vorgegebenes Berechtigungslevel überprüft.
Diese Methode wird von Anwendungen außerhalb der Stammdaten aufgerufen, wenn diese überprüfen möchten, ob ein Zugriff auf die vorgegebene Personalnummer zulässig sein soll oder nicht. Diese Anfrage ist aus Sicht der Stammdaten problematisch, da die Personalnummer als solche kein bei den Stammdaten abgelegtes Objekt ist. Die Stammdatenverwaltung kennt lediglich Infotypen. Aus diesem Grund ist die Semantik einer Prüfung auf die Zugriffsberechtigung für eine Personalnummer aus Stammdatensicht unklar. Deshalb wird im Standard bei dieser Methode die Berechtigung auf den fiktiven Infotyp
Einige Anwendungen rufen anstelle von dieser Methode eine der beiden folgenden Methoden auf.
Diese Methode wird von Anwendungen aufgerufen, die ermitteln möchten, ob eine Zugriffsberechtigung für alle Infotypen/Subtypen einer vorgegebenen Personalnummer besteht, d.h. ob eine Gesamtberechtigung zum Zugriff auf alle Daten einer Personalnummer vorliegt. Die Standardauslieferung realisiert die Prüfung dadurch, dass bei der AUTHORITY-CHECK-Anweisung die Felder
Diese Methode wird von Anwendungen aufgerufen, die ermitteln möchten, ob eine Zugriffsberechtigung für wenigstens einen Infotypsatz der vorgegebenen Personalnummer besteht, d.h. ob eine Minimalberechtigung zum Zugriff auf wenigstens einen Datensatz der Personalnummer vorliegen könnte. Die Standardauslieferung realisiert die Prüfung dadurch, dass bei der AUTHORITY-CHECK-Anweisung die Felder
Die BAdI-Technik erlaubt es nicht, den Konstruktor in der Schnittstelle anzugeben. Aus diesem Grund wurde die Methode DELAYED_CONSTRUCTOR in die Schnittstelle aufgenommen. Die Methode wird immer direkt nach dem Konstruktor prozessiert. Die Methodenschnittstelle erlaubt es, Informationen zum Umfeld der Instanzenerzeugung zu erhalten.
Die Parameter dieser Methode sind das Ergebnis von sehr speziellen Kundenanforderungen, die bei der Schnittstellenentwicklung berücksichtigt wurden. Die Auswertung dieser Parameter ist nur in sehr speziellen Sonderfällen überhaupt sinnvoll. Aus diesem Grund ist es in fast allen Fällen ratsam, diese Methode nicht bzw. leer zu implementieren und stattdessen den üblichen Konstruktor zu verwenden.
Siehe auch:
Beispiele zu BAdI HRPAD00AUTH_CHECK Beispiel-Implementation von HRPAD00AUTH_CHECK