What does it do? Declares an association as an ancestor association. The following rules apply to ancestor associations:
Each association that points to an entity between the current node and the root node should be marked as ancestor, except for the direct parent entity. That means that an entity can have multiple ancestor associations. The following associations must not be declared as ancestor:
Sibling entities on the same hierarchy level must not be marked as ancestor.
The direct parent entity must not be marked as ancestor, since it can be clearly identified as ancestor by its CDS definition.
If there are multiple associations with the same association target, at most one of them can be declared as ancestor. All other associations should be marked as ancestor.
An ancestor association must have a cardinality of 1.
The key fields of all ancestor associations must be marked as readonly. The purpose of ancestor associations is to guarantee the stability of extensions even if the extended RAP BO is modified. Via ancestor associations, the path to the RAP authorization master entity, RAP lock master entity , and RAP ETag master entity can be derived and need not be specified explicitly. Therefore, the syntax ancestor association makes the direct pointing to a authorization master, lock master, and ETag master obsolete:
Syntax to specify a RAP lock dependent entity: lock dependent instead of lock dependent by _Assoc
Syntax to specify a RAP authorization dependent entity: authorization dependent instead of authorization dependent by _Assoc
Syntax to specify a RAP ETag dependent entity: etag dependent instead of etag dependent by _Assoc A short syntax form is available: ( lock, authorization, etag ) dependent. Each of the three components lock, authorization, and etag is optional but at least one of them must be specified within the brackets.
Additions:
abbreviation _newName: Defines an alternative name for an association. The abbreviation _newName can have a maximum of 16 characters. Associations are in the namespace of their root entity and can have up to 30 characters. This is under certain circumstances too long to be processed in ABAP RAP. Whenever a shorter name is required, you are prompted to assign an abbreviation for the association with no more than 16 characters.
without response The optional addition without response is for cross-BO associations that have an association target from another BO. With such a cross-BO association, the association target entity is automatically included in the response types as foreign entity . In this way, problems with the target entity can become part of the response types during read-by-association or create-by-association operations. without response prevents the default behavior of the foreign entity being included in the response types.
with draft: Draft-enables an association. A draft-enabled association retrieves active data if it is followed from an active instance and draft data if it is followed from a draft instance (for details about RAP draft handling, see RAP BDL - managed, with draft). If a BO is draft-enabled, then all associations should be draft-enabled , so that the associations always lead to the target instance with the same state (draft or active). As soon as you draft-enable a BO by adding with draft , all BO-internal associations are automatically draft-enabled. To make this behavior explicit, the behavior prompts you to specify the compositions within a draft BO with with draft.
ABAP_EXAMPLE_VX5 The BDEF extension DEMO_RAP_EXTENSION_1 extends the RAP behavior definition DEMO_RAP_EXTENSIBLE_ROOT. It behavior-enables an extension node and defines the associations to its sibling, grandparent, and great-grandparent as ancestor associations. Lock, authorization, and ETag master are not specified explicitly, but derived implicitly via ancestor associations. BDEF DEMO_RAP_EXTENSION_1 ABAP_EXAMPLE_END
ABAP_EXAMPLE_ABEXA The executable example Node Extension explains the example above in detail. ABAP_EXAMPLE_END
