Anfang des InhaltsbereichsDiese Grafik wird im zugehörigen Text erklärt Beispiele zu BAdI HRPAD00AUTH_CHECK Dokument im Navigationsbaum lokalisieren

Die folgenden Beispiele sind absichtlich sehr einfach gehalten, da die Beschreibung einer vollständigen Neuimplementierung des BAdIs HRPAD00AUTH_CHECK den Rahmen dieser Dokumentation deutlich sprengen würde.

  1. Die Methoden CHECK_... werden so implementiert, dass immer IS_AUTHORIZED = TRUE zurückgegeben wird. Dies hat zur Folge, dass alle Stammdatenberechtigungsprüfungen immer positiv ausgehen und folglich jeder Benutzer auf alle Infotypen aller Personalnummern zugreifen kann.
  2. Die Methoden CHECK_... werden so implementiert, dass immer IS_AUTHORIZED = FALSE zurückgegeben wird. Dies hat zur Folge, dass alle Stammdatenberechtigungsprüfungen immer negativ ausgehen und folglich kein Benutzer auf irgendeinen Infotypen irgendeiner Personalnummer zugreifen kann. Im Reporting wäre allerdings bei vorhandenen P_ABAP Berechtigungen mit Vereinfachungsgrad COARS = 2 immer noch ein Zugriff möglich, da in diesem Fall keine Berechtigungsprüfungen durchgeführt werden.
  3. Die im Standard ausgelieferte Klasse CL_HRPAD00AUTH_CHECK_STD wird als BAdI aktiviert. Die Berechtigungsprüfungen verhalten sich dann im Dialog genau so, wie man es erwarten würde. Im Reporting würde für Reports, für die eine P_ABAP Berechtigung mit COARS = 1 hinterlegt ist, allerdings die Berechtigungsprüfung nicht "vereinfacht". Die Ursache hierfür liegt darin, dass der Standard zwei Klassen für die Berechtigungsprüfung verwendet:

    4. CL_HRPAD00AUTH_CHECK_STD und CL_HRPAD00AUTH_CHECK_FAST. Wenn kein BAdI aktiv ist, wird bei COARS = 1 die zweite Klasse verwendet. Wenn ein BAdI aktiv ist, wird lediglich auf COARS = 2 geprüft.

  4. Es wird eine Klasse implementiert, die im Konstruktor eine Berechtigungsprüfung für SY-CPROG und COARS = 1 durchführt und bei fehlender Berechtigung alle Methodenaufrufe an die Klasse CL_HRPAD00AUTH_CHECK_STD bzw. bei vorhandener Berechtigung alle Methodenaufrufe an die Klasse CL_HRPAD00AUTH_CHECK_FAST delegiert. In diesem Fall würden sich die Berechtigungsprüfungen sowohl im Dialog als auch bei Reportausführungen völlig identisch verhalten. Beim Prozessieren von Eingabehilfen würde die Berechtigungsprüfung bei Reports mit COARS = 1 nun die Methoden der Klasse CL_HRPAD00AUTH_CHECK_FAST anstelle der Klasse CL_HRPAD00AUTH_CHECK_STD prozessieren.
  5. Sie haben Anforderungen, die von der Standardzeitlogik nicht abgedeckt werden und möchten stattdessen die folgende Zeitlogik in Ihrem System realisieren: Wer zum aktuellen Datum zuständig für eine Personalnummer ist, darf auf alle Daten der entsprechenden Personalnummer zugreifen. Wer nicht zuständig ist, darf dagegen auf keinerlei Daten zugreifen. Weiterhin sollen die Prüfverfahren wie gehabt weiter funktionieren. Sie verwenden in Ihrem System keine P_ABAP-Berechtigungen mit COARS = 1 :

Die eben genannten Prüfungen sind im Prinzip alle bereits in der Klasse CL_HRPAD00AUTH_CHECK_STD vorhanden. Es ist lediglich nötig, die Zeitlogik anzupassen. Sie wollen aber keine Kopie der Klasse erzeugen und diese Kopie modifizieren, da Sie damit letztendlich eine vollständig kundenindividuelle Berechtigungsprüfung im System implementieren würden, d.h. sämtliche von SAP ausgelieferten Korrekturen müssten jeweils von Hand angepasst werden. Da die Klasse CL_HRPAD00AUTH_CHECK_STD bei allen Schreibzugriffen und außerdem auch bei Lesezugriffen zum aktuellen Datum bereits richtig reagiert, delegieren Sie die eigentlichen Prüfungen weiterhin an diese Klasse. Allerdings ändern Sie das Datum vorher jeweils so ab, dass nachher der gewünschte Effekt eintritt. Beachten Sie hierzu auch das folgende Diagramm und die Beispiel-Implementation von HRPAD00AUTH_CHECK:

Diese Grafik wird im zugehörigen Text erklärt

Ende des Inhaltsbereichs