Ansicht
Dokumentation

ABENBDL_PRIVILEGED_MODE - BDL PRIVILEGED MODE

Addresses (Business Address Services)   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

- with privileged mode

BDEF privileged mode for managed and unmanaged RAP BOs

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

BDEF privileged mode for RAP projection BOs

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

BDEF privileged mode for CDS interface behavior definitions

...
with privileged mode;
...

Alternatives:

1. with privileged mode disabling BaseContext

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

3. with privileged mode

Effect

Enables BDEF privileged mode for a RAP BO. BDEF privileged mode is prerequisite to use the addition PRIVILEGED in EML when consuming the RAP BO. BDEF privileged mode can be specified for managed, unmanaged, projection, and interface BOs. The syntax for the different BO types (managed, unmanaged, projection, interface) varies. Details are described below.

The example Using the addition PRIVILEGED with an Statement defines an authorization context and registers it for use in privileged mode. It then demonstrates access to the RAP BO, first without the addition PRIVILEGED, afterwards with using PRIVILEGED.

Alternative 1

with privileged mode disabling BaseContext

Effect

This syntax variant is available only for managed and unmanaged BDEFs.

In the header part of a behavior definition of a managed or unmanaged RAP BO, it is possible to specify with privileged mode disabling ContextName. The effect is that the authorization context ContextName is automatically disabled when a RAP BO consumer uses privileged access to the RAP BO in question. ContextName must be an authorization context defined in the same BDEF. Not more than one authorization context can be specified.

Example:

with privileged mode disabling demo_context_bdl

in the BDEF has the effect that the EML statement

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

behaved as if

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.

had been written.

So with the syntax with privileged mode disabling, the RAP framework leaves out calls to authorization objects. No implementation in the ABAP behavior pool is required.

There are other kinds of authority checks, such as CDS access control. If a business object is protected from unauthorized access using any other method than authorization objects, the BDEF can define an empty authorization context that is referred to in ContextName.

Example:

BDEF header: with privileged mode disabling EmptyContext

BDEF body: define authorization context EmptyContext { }

In the case of empty authorization contexts, privileged EML calls are handled as follows:

• In a managed RAP BO, the RAP framework automatically and implicitly checks for other authorizations, such as CDS access control.

• In an unmanaged RAP BO, rules for the handling of a privileged access can be defined in the respective handler methods in the ABAP behavior pool.

Notes

• The syntax with privileged mode; has been deprecated for managed and unmanaged RAP BOs. For compatibility reasons, it can still be used, but it is not recommended and if used, a warning message appears.

• There are multiple options how to activate an authorization context (described in topic define authorization context). One of them is that a context can directly be registered for a category of handler method using the syntax

define authorization context ContextName
   for disable(${read$|modify$|read,modify$})

The difference between this and with privileged mode disabling is that in the first case, the context is active within the handler method. In the latter case, the context is active around the EML statement and that means it is also active during calls to the handler method that might be performed by the RAP framework implicitly before calling the actual handler targeted by the EML statement.

Example - 1, Deprecated Syntax

The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_PRIVILEGED and it enables privileged mode.

The privileged mode must be implemented in class BP_DEMO_RAP_PRIVILEGED (currently not implemented in this example).

This syntax has been deprecated and is not recommended.

Example - 2, New, Recommended Syntax

The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_AUTH_CONTEXT. It enables privileged mode and specifies that for privileged EML access, the authorization context ac_1 is disabled.

Alternative 2

with privileged mode disabling base context

Effect

This syntax variant is available only for projection BDEFs. It enables BDEF privileged mode for a projection BDEF. As a prerequisite, the projected BDEF must offer privileged mode. The syntax for enabling privileged mode in a projection BDEF is as follows:

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

base context refers to the authorization context that is specified in the projected BDEF. It is compulsory to reuse the authorization context from the projected BDEF.

If the projected BDEF specifies an empty authorization context, this can also be reused by the projection BDEF.

With the optional addition and ContextName, it is possible to specify an additional authorization context in the projection BDEF. ContextName must be an authorization context defined in the same projection BDEF. For all privileged operations on the projection BDEF, both the authorization context of the projected BDEF and the context of the projection BDEF are disabled.

Note

Privileged mode can only be reused in a projection BDEF if the syntax with privileged mode disabling ContextName is specified in the projected BDEF. If the projected BDEF uses the deprecated syntax form with privileged mode;, then BDEF privileged mode is not available in the projection BO.

Example

The following example shows a projection BDEF based on the projected BDEF DEMO_RAP_AUTH_CONTEXT. It enables privileged mode, reuses the authorization context from the projected BDEF and adds one further authorization context to the projection layer.

Alternative 3

with privileged mode

Effect

This syntax variant is available only for interface BDEFs. It enables BDEF privileged mode for an interface BDEF, so that access with EML can take place in privileged mode using the addition PRIVILEGED. Since interface BDEFs cannot define any access restrictions or authorization contexts themselves, it is a prerequisite that the underlying the projected BDEF offers privileged mode. A privileged access is then delegated to the implementation of the underlying base RAP BO. The syntax for enabling privileged mode in an interface BDEF is as follows:

with privileged mode;

Note

Privileged mode can only be reused in an interface BDEF if the syntax with privileged mode disabling ContextName is specified in the projected BDEF.

TXBHW - Original Tax Base Amount in Local Currency   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Length: 13696 Date: 20240420 Time: 153108     sap01-206 ( 152 ms )