ABENBDL_PRIVILEGED_MODE - BDL PRIVILEGED MODE

ABENBDL_PRIVILEGED_MODE - BDL PRIVILEGED MODE

rdisp/max_wprun_time - Maximum work process run time   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

- with privileged mode

Privilegierter BDEF-Modus für verwaltete und nicht verwaltete RAP-BOs

...
with privileged mode disabling ContextName;
...


BDEF privileged mode for RAP projection BOs

...
with privileged mode disabling base context
  $[and ContextName$];
...


Privilegierter BDEF-Modus für CDS-Interface-Verhaltensdefinitionen

...
with privileged mode;
...


Alternativen:

1. with privileged mode disabling BaseContext

2. with privileged mode disabling base context $[and$]

3. with privileged mode

Wirkung

Schaltet den privilegierten BDEF-Modus für ein RAP-BO ein. Der privilegierte BDEF-Modus ist eine Voraussetzung für das Verwenden des Zusatzes PRIVILEGED in EML beim Konsumieren des RAP-BOs. Der privilegierte BDEF-Modus kann für verwaltete BOs, nicht verwaltete BOs, Projektions-BOs und Interface-BOsangegeben werden. Die unterschiedlichen BO-Arten (verwaltet, nicht verwaltet, Projektion und Interface) besitzen unterschiedliche Syntax. Details sind unten beschrieben:

Mit dem Beispiel Verwendung des Zusatzes PRIVILEGED mit einer -Anweisung wird ein Berechtigungskontext definiert und für die Verwendung im privilegierten Modus registriert. Danach wird dann der Zugriff auf das RAP-BO demonstriert, zuerst ohne den Zusatz PRIVILEGED und danach mit PRIVILEGED.

Alternative 1

with privileged mode disabling BaseContext


Wirkung

Diese Syntaxvariante steht nur verwalteten und nicht verwalteten BDEFs zur Verfügung.

Im Kopfteil einer Verhaltensdefinition eines verwalteten oder nicht verwalteten RAP-BOs darf with privileged mode disabling ContextName angegeben werden. Dabei wird der Berechtigungskontext ContextName bei der Verwendung des privilegierten Zugriffs auf das jeweilige RAP-BO durch den RAP-BO-Consumer automatisch ausgeschaltet. ContextName muss ein in der gleichen BDEF definierten Berechtigungskontext sein. Es darf maximal ein Berechtigungskontext angegeben werden.

Beispiel:

with privileged mode disabling demo_context_bdl

bewirkt in der BDEF, dass die EML-Anweisung

read entity privileged demo_context_bdl
   all fields with value #( ( name = field1 ) )
   result data(result)
   failed data(failed)

sich verhielt, als ob

authority-check disable begin context demo_context_bdl~privileged context.
   read entity privileged demo_context_bdl
   all fields with value #( (name = field1 ) )
   result data(result)
   failed data(failed)
authority-check disable end.

geschrieben wurde.

Daher bewirkt die Syntax with privileged mode disabling, dass das RAP-Framework Aufrufe auf Berechtigungsobjekte auslässt. Es ist keine Implementierung im ABAP-Behavior-Pool erforderlich.

Es existieren auch andere Arten von Berechtigungsprüfung, beispielsweise CDS-Zugriffskontrolle. Falls ein Business-Objekt durch Methoden anders als Berechtigungsobjekte gegen unberechtigten Zugriff geschützt wird, kann die BDEF einen leeren Berechtigungskontext definiert, die im ContextName referenziert wird.

Beispiel:

BDEF-Kopf: with privileged mode disabling EmptyContext

BDEF-Rumpf: define authorization context EmptyContext { }

Bei leeren Berechtigungskontexten werden privilegierten EML-Aufrufen wie folgt behandelt:

  • In einem verwalteten RAP-BO prüft das RAP-Framework automatisch und implizit auf andere Berechtigungen, wie CDS-Zugriffskontrolle.
  • In einem nicht verwaltetem RAP-BO können die Regeln für die Behandlung eines privilegierten Zugriffs in den jeweiligen Behandlermethoden im ABAP-Behavior-Pool definiert werden

Hinweise

  • Die Syntax with privileged mode; wurde für verwaltete und nicht verwaltete RAP-BOs abgekündigt. Sie darf aus Kompatibilitätsgründen noch verwendet werden, dies ist aber nicht empfohlen und führt zu einer Warnungsmeldung.
  • Ein Berechtigungskontext kann auf mehrere Arten aktiviert werden (wie im Abschnitt define authorization context beschrieben). Eine Option, ist die direkte Registrierung eines Kontexts für eine Kategorie der Behandlermethode mit folgender Syntax:
define authorization context ContextName
   for disable(${read$|modify$|read,modify$})
Der Unterschied zu with privileged mode disabling ist im ersten Fall, dass der Kontext innerhalb der Behandlermethode aktiv ist. Im letzteren Fall ist der Kontext um die EML-Anweisung aktiv. Das heißt, dass er auch während implizit durch das RAP-Framework durchgeführte Aufrufe an die Behandlermethode aktiv ist, bevor der eigentlich durch die EML-Anweisung anvisierte Behandler aufgerufen wird..

Beispiel - 1, abgekündigte Syntax

Im folgenden Beispiel wird eine auf der CDS-Wurzel-View-Entität DEMO_RAP_PRIVILEGED basierte verwaltete BDEF gezeigt und der privilegierter Modus eingeschaltet.

Der privilegierte Modus muss in der Klasse BP_DEMO_RAP_PRIVILEGED implementiert werden (in diesem Beispiel zur Zeit nicht implementiert).

Diese Syntax ist abgekündigt und ist nicht empfohlen.

Beispiel - 2, neue empfohlene Syntax

Im folgenden Beispiel wird eine auf der CDS-Wurzel-View-Entität DEMO_RAP_AUTH_CONTEXT basierte verwaltete BDEF gezeigt. Hiermit wird der privilegierte Modus eingeschaltet und die Angabe gemacht, dass der Berechtigungskontext ac_1 für privilegierten EML-Zugriff ausgeschaltet.

Alternative 2

with privileged mode disabling base context


Wirkung

Diese Syntaxvariante steht nur Projektions-BDEFs zur Verfügung. Hiermit wird der privilegierte BDEF-Modus für eine Projektions-BDEF eingeschaltet. Als Voraussetzung muss die projizierte BDEF den privilegierten Modus anbieten. Mit folgender Syntax kann der privilegierte Modus in einer Projektions-BDEF eingeschaltet werden:

with privileged mode disabling base context
  $[and ContextName$]

base context bezieht sich auf den Berechtigungskontext, der in der projizierten BDEF angegeben wird. Die Wiederverwendung des Berechtigungskontexts aus der projizierten PDEF ist obligatorisch.

Falls die projizierte BDEF einen leeren Berechtigungskontext angibt, darf er auch von der Projektions-BDEF wiederverwendet werden.

Mit dem optionalen Zusatz and ContextName kann ein zusätzlicher Berechtigungskontext in der Projektions-BDEF angegeben werden. ContextName muss ein in der gleichen Projektions-BDEF definierten Berechtigungskontext sein. Für alle privilegierten Operationen auf der Projektions-BDEF sind sowohl der Berechtigungskontext der projizierten BDEF als auch der Kontext der Projektions-BDEF ausgeschaltet.

Hinweis

Die Wiederverwendung vom privilegierten Modus in einer Projektions-BDEF ist nur bei der Angabe der Syntax with privileged mode disabling ContextName in der projizierten BDEF erlaubt. Falls die projizierte BDEF die abgekündigte Syntaxform with privileged mode; verwendet, steht der privilegierte BDEF-Modus im Projektions-BO nicht zur Verfügung.

Beispiel

Im folgenden Beispiel wird eine auf der projizierten BDEF DEMO_RAP_AUTH_CONTEXT basierte Projektions-BDEF gezeigt Damit wird der privilegierte Modus eingeschaltet, der Berechtigungskontext aus der projizierten BDEF wiederverwendet und die Projektionsschicht um einen weiteren Berechtigungskontext erweitert.

Alternative 3

with privileged mode


Wirkung

Diese Syntaxvariante steht nur Interface-BDEFs zur Verfügung. Hiermit wird der privilegierte BDEF-Modus für eine Interface-BDEF ermöglicht, damit der Zugriff mit EML im privilegierten Modus über den Zusatz PRIVILEGED stattfinden kann. Da Interface-BDEFs selbst keine Zugriffseinschränkungen oder Berechtigungskontexte definieren können, muss die zugrundeliegende projizierte BDEF als Voraussetzung den privilegierten Modus anbieten. Der privilegierte Zugriff wird dann an die Implementierung der zugrundeliegenden Basis-RAP-BO delegiert. Mit folgender Syntax kann der privilegierte Modus in einer Interface-BDEF eingeschaltet werden:

with privileged mode;

Hinweis

Die Wiederverwendung vom privilegierten Modus in einer Interface-BDEF ist nur bei der Angabe der Syntax with privileged mode disabling ContextName in der projizierten BDEF erlaubt.






Fill RESBD Structure from EBP Component Structure   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 14830 Date: 20240921 Time: 021750     sap01-206 ( 183 ms )