Skip to content

ABAP Keyword Documentation →  ABAP - Dictionary →  ABAP CDS in ABAP Dictionary →  ABAP CDS - Access Control →  ABAP CDS - DCL Statements →  ABAP CDS - DEFINE ACCESSPOLICY 

ABAP CDS - DEFINE ASPECT

Other versions: 7.31 | 7.40 | 7.54

Syntax


 
[DEFINE] ASPECT generic_aspect AS SELECT FROM aspect_entity 

  WITH USER ELEMENT user_element 
{ 
    output1 [BYPASS WHEN aspect_bypass_condition] 

    [, ... ] 
}

Effect

Defines a generic aspect generic_aspect as part of a CDS access policy defined using DEFINE ACCESSPOLICY. The name of the generic aspect must be the same as the name of the CDS access policy.

The definition of a generic aspect contains the following:

  • An aspect entity aspect_entity, specified after the name generic_aspect, which is used as a data source.
  • An element user_element of the aspect entity that is used as an input field for the user name of the logged on user.
  • A comma-separated list that specifies the output fields output1, output2, ... of the generic aspect. The specified order applies.
  • Any number of output fields that can be tagged with a condition using the addition BYPASS WHEN aspect_bypass_condition. Typical bypass values are * or an empty value. The following are possible as aspect bypass conditions aspect_bypass_condition: IS NULL | IS [NOT] NULL | = Literal

At runtime, the field user_element is filled with the user name of the current user. The rows produced in the aspect entity are matched with their output fields in the specified order and with the elements on the left side of the access condition to which the generic aspect is assigned. This means those rows in the protected entity meet the condition for which a row exists for the current user in the aspect entity.

When the bypass condition is used, the match with this field is not used if this condition exists in a row of the aspect entity. A specified value, therefore, (such as an asterisk) can be used to indicate that any values of the protected entity are allowed.

Special Requirements in the Aspect Entity

The content of the aspect entity has a particular relevance for audits by being used in a generic aspect in access control.

To determine which user had access to particular data at a particular time in a system, it must be possible to reconstruct the state of the data of the aspect entity. Existing mechanisms (such as version management or change documents) cover this requirement in the case of development objects or PFCG roles, aspect entities do not specify their data sources and whether these sources are themselves auditable.

The development and runtime systems for CDS access control cannot check whether data sources are auditable. To highlight this requirement, however, the aspect entity must have the following annotations:

  • An auditing type with the annotation @AccessControl.auditing.type. Currently only the value #CUSTOM is possible.
  • A component with the annotation @AccessControl.auditing.specification specifying (as text) how the content of the entity is audited.


Notes

  • Just adding the annotations, however, does not activate auditing. It must first be ensure that auditing is actually possible.

  • Auditing must respect all data sources of the aspect entity.

  • If auditing cannot be ensured, the aspect entity cannot be used in a generic aspect.

  • In ABAP SQL access to a CDS entity assigned a role of this type, generic aspects are defined internally using a subquery after EXISTS. This can be seen in an SQL trace.