ABAP - BOPF Berechtigung
Der Einbau von eigenen Berechtigungen ist auch mit BOPF möglich, wir zeigen dir wie du das leicht umsetzen kannst.
Inhaltsverzeichnis
Die Hilfe im BOPF beschreibt zwei Wege zur Erstellung einer eigenen Berechtigungsprüfung, einmal über die Klasse /BOBF/CL_LIB_AUTHCHECK_W_QUERY oder bei kompletter Neuimplementierung einer eigenen Logik über die abstrakte Klasse /BOBF/CL_FRW_AUTHORITY_CHECK. Wir zeigen dir heute den kompletten Weg über die abstrakte Klasse, bei der du deine eigenen Berechtigungsprüfungen implementierst.
Vorbereitung
Die Klasse zur Prüfung der Berechtigungen muss selbst angelegt werden, da wir mit einer Vererbung arbeiten und noch Nacharbeiten an der neuen Klasse durchführen müssen. Name, Beschreibung und Oberklasse müssen eingetragen werden, der Rest kann auf den Standardeinstellungen bleiben.
Die Methoden CHECK_AUTHORITY und CHECK_AUTHORITY_STATICALLY solltest du im ersten Schritt redefinieren, kannst diese aber leer lassen. Die Methode GET_QUERY_CONDITION_PROVIDER sollte ebenfalls redefiniert werden und benötigt eine Implementierung. Im folgenden Coding erhältst du ein Beispielcoding, wie so eine Implementierung aussehen kann. Dort wird die Konfiguration nachgelesen und ein Provider für Knoten und Objekt erzeugt. Ohne die Implementierung der Methode kommt es zu einem Fehler beim Ausführen von Operationen auf das Business Object.
DATA(lo_conf) = /bobf/cl_frw_factory=>get_configuration( zif_tst_bopf_c=>sc_bo_key ).
lo_conf->get_node(
EXPORTING
iv_node_key = is_ctx-node_key
IMPORTING
es_node = DATA(ls_node_conf)
).
ro_provider = /bobf/cl_sadl_auth_cond_provid=>get_instance(
EXPORTING
iv_anchor_entity = /bobf/cl_sadl_entity=>get_entity_id_by_bo_node_name(
EXPORTING
iv_bo_name = CONV #( lo_conf->ms_obj-bo_name )
iv_node_name = CONV #( ls_node_conf-node_name )
)
is_customizing_context = is_ctx
).
Implementierung
Bei der Implementierung verwenden wir die dynamische Prüfung auf Werten der Instanz, dass heißt wir implementieren die Methode CHECK_AUTHORITY. Die Methode hat dabei die folgende Schnittstelle:
Entsprechend steht uns der Kontext der Anfrage zur Verfügung mit dem wir zuerst prüfen, ob der richtige Knoten übergeben wurde. BOPF prüft die Berechtigungen für alle Knoten, unsere Prüfung soll aber spezifisch nur für den Kopf greifen. Ist dies erfolgreich, lesen wir die Daten zum Knoten ein und überprüfen die Daten gegen ein Berechtigungsobjekt. Fehlerhafte Knoten werden die die Rückgabetabelle ET_FAILED_KEY übernommen, damit diese Datensätze herausgefiltert werden. Eine Implementierung könnte daher wie folgt aussehen:
DATA:
lt_head TYPE ztest_t_contract.
IF is_ctx-node_key <> zif_tst_bopf_c=>sc_node-contract.
RETURN.
ENDIF.
eo_message = /bobf/cl_frw_factory=>get_message( ).
io_read->retrieve(
EXPORTING
iv_node = is_ctx-node_key
it_key = it_key
iv_fill_data = abap_true
IMPORTING
et_data = lt_head
).
LOOP AT lt_head REFERENCE INTO DATA(lr_head).
" Do Authority Check
IF sy-subrc <> 0.
INSERT VALUE #( key = lr_head->key ) INTO TABLE et_failed_key.
ENDIF.
ENDLOOP.
Aktivierung
Die eigene Berechtigungprüfung muss aber erst noch aktiviert werden, bevor sie automatisch durchlaufen wird. Dafür muss im Kopf des Business Objekts die Checkbox "BO hat Berechtigungsprüfungen" aktiviert werden.
Damit werden auf den Knoten weitere Optionen und Felder freigeschaltet. Die Checkbox "Knoten hat eigene Prüfungen" und die Hinterlegung der Klasse aktivieren dann die Prüfungen. Dann wird bei jedem Zugriff die Berechtigung für den jweiligen Knoten geprüft.
Fazit
Für die Implementierung einer eigenen Berechtigungsprüfung sind einige Zusatzschritte nötig, doch diese sind schnell erklärt und durchgeführt. Mit unserem Tipp bist du damit schnell in der Lage die Kundenwünsche umzusetzen und spezifische Berechtigungen zu prüfen.
