Get Example source ABAP code based on a different SAP table
• WITH PRIVILEGED MODE DISABLING ABAP_BDL_HEADER • BASE CONTEXT ABAP_BDL_PROJECTION • AND ABAP_BDL_HEADER , privileged mode • WITH PRIVILEGED MODE ABAP_BDL_INTERFACE
ABAP_RAP - with privileged mode
ABAP_SYNTAX_FORMS
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 RAP Interface Behavior Definitions ... with privileged mode; ...
ABAP_ALTERNATIVES: 1 with privileged mode disabling ContextName 2 with privileged mode disabling base context $[and$] 3 with privileged mode
What does it do? 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.
ABAP_EXAMPLE_ABEXA The example Using the addition PRIVILEGED with an ABAP_EML Statement defines an authorization context for disable and registers it for use in privileged mode. It then demonstrates access to the RAP BO, first without the addition PRIVILEGED, afterwards using PRIVILEGED. ABAP_EXAMPLE_END
ABAP Alternative 1 with privileged mode disabling ContextName
What does it do? 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 for disable ContextName is automatically disabled when a RAP BO consumer uses privileged access to the RAP BO in question. ContextName must be an authorization context for disable 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.
Latest 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 for disable (described in topic TITLE ). 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. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 - 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). ABAP_NOTE This syntax has been deprecated and is not recommended. BDEF DEMO_RAP_PRIVILEGED ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 - 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. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. The RAP handler method FOR GLOBAL AUTHORIZATION is not implemented here. In a real-life scenario, the authorization objects from the full authorization context would be implemented in this RAP handler method. BDEF DEMO_RAP_AUTH_CONTEXT ABAP_EXAMPLE_END
ABAP Alternative 2 with privileged mode disabling base context
What does it do? 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 for disable 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 for disable in the projection BDEF. ContextName must be an authorization context for disable 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.
Latest notes: 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. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following example shows a projection BDEF based on the projected BDEF DEMO_RAP_AUTH_CONTEXT. It enables privileged mode, reuses the authorization context for disable from the projected BDEF and adds one further authorization context to the projection layer. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. The ABAP behavior pool is not implemented here. In a real-life scenario, AUTHOBJ1 would be implemented in the ABAP behavior pool. BDEF DEMO_RAP_AUTH_CONTEXT_PROJ ABAP_EXAMPLE_END
ABAP Alternative 3 with privileged mode
What does it do? 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 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;
Latest notes: Privileged mode can only be reused in an interface BDEF if the syntax with privileged mode disabling ContextName is specified in the projected BDEF. NON_V5_HINTS ABAP_HINT_END
