What does it do? A RAP behavior definition can define authorization contexts for disable using the statement define authorization context. Authorization contexts for disable list multiple authorization objects that are used for the ABAP statement AUTHORITY-CHECK OBJECT. When an authorization context for disable is activated, authority checks for all associated authorization objects are always successful; in other words, the respective authorization checks are skipped. This can be useful, for example, when a BDEF implements its own authorization check and then calls existing code, which again has its own authorization checks. One RAP behavior definition can define one or more authorization contexts for disable. The contexts may be defined before, between, or after the entity behavior definitions. Each context can contain one or more authorization objects AuthObject1, AuthObject2, .... It is also possible to define an empty authorization context for disable. This can be useful when using BDEF privileged mode : to enable BDEF privileged mode, it is mandatory to specify at least one authorization context for disable. However, some RAP BOs use authority checks that do not rely on authorization objects. In this case, an empty authorization context for disable can be specified. The optional addition for disable(${modify$|read$|modify,read$}) activates the authorization context for disable in question for certain handler methods. When a context is activated for a handler method, then the corresponding handler method is automatically and implicitly disabled for the authorization context in the ABAP behavior pool. Example: define authorization context ReadContext for disable (read) ... in the BDEF has the effect that METHOD read. ... ENDMETHOD. in the ABAP behavior pool behaves as if the code was METHOD read. AUTHORITY-CHECK DISABLE BEGIN CONTEXT demo_context~ReadContext. ... AUTHORITY-CHECK DISABLE END. ENDMETHOD. Currently, only the handler methods modify and read are available. They can be specified individually, or both together. Each handler method can only be assigned once within a RAP behavior definition.
Activating an Authorization Context for Disable An authorization context for disable can be activated and the corresponding authorization objects skipped in the following ways:
by using AUTHORITY-CHECK DISABLE BEGIN CONTEXT ... AUTHORITY-CHECK DISABLE END in the ABAP behavior pool for a handler or saver method.
implicitly by registering a context for use in privileged mode.
implicitly by registering a context for a category of handler method, as described above.
ABAP_AVAILABILITY
Managed RAP BO
Unmanaged RAP BO
Projection BDEF: a projection BDEF can define an authorization context for disable independently of the projected BDEF. This means that an authorization context for disable can be defined in the projection layer even if the projected entity does not have an authorization context for disable. ABAP_AVAILABILITY_END
Dependency If you define and activate an authorization context for disable which lists authorization objects (that means, it is not empty), you also need to specify a RAP full authorization context that lists all mentioned authorization objects, unless they are forbidden for use in full authorization contexts as per their classification. Otherwise, syntax check warnings occur. Further details are described in topic TITLE .
Latest notes: The optional registration of an authority context for a dedicated purpose using the syntax for disable(${modify$|read$|modify,read$}) does not generate an AUTHORITY-CHECK DISABLE BEGIN CONTEXT ... AUTHORITY-CHECK DISABLE END bracket within handler methods that are introduced by RAP extensions. In other words, no such bracket is generated in implementation classes that are named in extension BDEFs. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following managed BDEF defines two authorization contexts for disable: ac1 and ac2 with the addition for disable. A full authorization context which lists all objects from ac_1 is also required. 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_EXAMPLE_ABEXA The example Using the addition PRIVILEGED with an ABAP_EML 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. ABAP_EXAMPLE_END
