Ausgestaltung eines eigenen Berechtigungsobjekts

Ein Entwickler will bspw. in einer Transaktion, die Funktion „Preisänderung“ an eine Berechtigung knüpfen. Der Benutzer soll das Recht haben den Preis zu ändern oder nicht. Die Funktion sei im Standard so nicht gegeben, deshalb entscheidet sich der Entwickler, ein eigenes B-Objekt zu definieren.

Diese binäre Abfrage will der Entwickler nun über ein Objekt Z_PREIS mit dem Berechtigungsfeld PREISJA realisieren. Welche Schwierigkeiten, kann es dabei geben?

Berechtigungsobjekt im Programm

Der Entwickler könnte ein B-Objekt definieren das den Namen Z_PREIS und das B-Feld PREISJA trägt. Für das Feld PREISJA wählt er den Wert X, wenn der Preis geändert werden soll.

Der Rollenadministrator baut dieses B-Objekt nun in eine Rolle ein. Das Programm des Entwicklers prüft ab:

  • ist das Objekt Z_PREIS im Feld mit PREISJA=’*‘ bewertet ⇒ Preis kann geändert werden
  • ist das Objekt nicht in der Rolle ⇒ Preis darf nicht geändert werden

Der Rollenadmin kennt dieses Coding nicht. Er baut also in eine andere Rolle, die den Preis nicht ändern darf, das Objekt Z_PREIS mit PREISJA=‘ ‚ ein. Was passiert?
Beide Rollen dürfen den Preis ändern. Unschön?!

Der Rollenadmin lässt dieses Objekt in der Rolle ganz weg, und der Preis kann nicht geändert werden. Works as designed?

Nun nehmen Sie an, ein Benutzer sollte nicht das Recht haben, den Preis zu ändern. Er hat also die Rolle, in der das obige Objekt nicht enthalten ist. Die Transaktion läuft aber über das Coding unseres Entwicklers. Im Berechtigungstrace [ST01] erhält er an dieser Stelle einen RC=12 für das Objekt. Der Analysator des Traces, schaut sofort an dieser Stelle nach, sieht die Beschreibung des Objektes Z_PREIS in der SU21 und bewertet ggf. die Rolle falsch.

Also eine ganze Reihe von verstecktem Wissen, das dieses B-Objekt umgibt. Ohne die Programmierung der Berechtigungsabfrage zu kennen, hat hier wohl jeder seine Schwierigkeiten.

Analyse

Was ist hier falsch gelaufen?
Zum einen will es sich der Entwickler einfach machen, denn sein Programm läuft eigentlich richtig.
Der Rollenadministrator muss entweder seitenlange Dokumentation über die Rolle schreiben und sie jedem Hotliner zugänglich machen. Er muss das Programm verstehen und einmal das Objekt in die Rolle einpflanzen, ein andermal nicht.
Hätte der Entwickler für das B-Objekt nicht ein eigenes Bewertungsfeld PREISJA eingebaut, sondern sich des Standard-Felds ACTVT bedient, hätte er mit ACTVT=02
die Preisänderung erlauben können, mit ACTVT = 03 nur das Anzeigen etc. Man hätte das Objekt in alle Rollen der Transaktion des Entwicklers aufnehmen können und durch Bewertung die Steuerung ermöglichen können. Letztlich wäre kein RC=12 mehr im Trace aufgetaucht.
Der evtl. Fehler bei einem Benutzer wäre leichter analysierbar gewesen.

Fazit

Bei Eigenprogrammierung sollte der Entwickler sich bzgl. Berechtigungen mit dem Rollenadmin zusammensetzen und das Design der Berechtigungsprüfung diskutieren.
(Das obige Beispiel war eine Vereinfachung, denn jeder Entwickler würde an das Feld ACTVT denken! Aber ähnliche Dinge habe ich schon untersuchen müssen!)
Ziel der Diskussion der Beiden sollte sein, dass

  • wenn das Programm gerufen wird, das B-Objekt auch immer in der Rolle sein sollte! Es gehört zu dem Programm bzw. Transaktion!
  • ein Berechtigungstrace wegen eines Benutzerberechtigungsproblems aussagefähig bleiben sollte und nicht verwirrend!
  • man für derartige Prüfungen ggf. auf bestehende B-Felder zurückgreifen sollte!
  • man als Entwickler nie auf ‚*‘ im Berechtigungsfeld prüfen sollte!

Natürlich sollte das Programm bei Nicht-Erlaubnis der Preisänderung ggf. eine ordentliche Fehlermeldung ausgeben. Wie oft sieht man als Meldung an den Benutzer die Meldung „Nicht alle Daten wurden geändert“.

Falls Ihnen auch schon mal solche Negativbeispiele vorgekommen sind, dann schreiben Sie es doch bitte in einen Kommentar, bestimmt findet sich dafür auch eine Lösung.

Bernd Klüppelberg

Schreiben Sie bitte einen Kommentar





SAP Berechtigungen, -Konzepte, -Technik | System Beratung Bernd Klüppelberg