Get Example source ABAP code based on a different SAP table
• ASSOCIATION ABAP_BDL_BODY • ABBREVIATION ABAP_BDL_BODY , ASSOCIATION • CREATE ABAP_BDL_BODY , ASSOCIATION • WITHOUT RESPONSE ABAP_BDL_BODY , ASSOCIATION • WITH DRAFT ABAP_BDL_BODY , ASSOCIATION
ABAP Addition 1 ... abbreviation _newName ... 2 ... without response ... 3 ... with draft; ...
What does it do? Enables read-by-association and create-by-association operations for associations. That means, it allows RAP BO consumers read access to the association target (read-by-association operation) or the creation of new RAP BO entity instances of the association target entity (create-by-association operation). Compositions and to-parent associations are per default implicitly read and create enabled. Yet, it is recommended and in BDEF strict mode also enforced that the read- and create-by-association operations are specified explicitly. Cross-BO associations that are not part of the composition tree are not by default read- and create-enabled and this behavior must be defined explicitly, if required. A prerequisite is that the association target entity must have an own BDEF and offer the respective operations as well. In a managed RAP BO, operations for associations are provided by the managed RAP BO provider. In an unmanaged RAP BO, operations for associations must be implemented in the ABAP behavior pool in the RAP handler method FOR MODIFY. In a projection BDEF, operations for associations can be reused from the base BDEF. This can be done using the keyword use. For further details, see topic TITLE .
Read and Create Access The following syntax explicitly defines read and create access: association _Assoc $[abbreviation _newName$] { create; } This is only required and only allowed for compositions (that is, associations from the parent node to the child node), it is not allowed for to-parent associations. In other words, child nodes can be created via their parent node, but parents cannot be created via their child nodes.
Read Access Only To enable only read access and deactivate create operations for the associated entity, the following syntax can be used: association _Assoc $[abbreviation _newName$] { } Alternative spelling option: association _Assoc $[abbreviation _newName$]; This is allowed in both directions, from parent to child and vice versa.
Limitation in a Managed RAP BO In a managed RAP BO, create-by-association works only on direct child entities. Entities that are part of the same composition tree, but more than one level below the RAP BO root entity, can be read enabled, but not create enabled. In an unmanaged RAP BO, this limitation does not apply.
RAP BDL Operation Additions The following RAP BDL operation additions are possible:
internal: Can be used in two places:
in front of the association:
Example: internal association _Assoc;
In this case, the complete association can only be accessed from its own business object implementation. This affects both read and create operations along CDS associations.
in front of create within the curly brackets:
Example: association _Assoc { internal create; }
If only create is marked as internal, read access to the association target is allowed, but create-by-association operations are only allowed internally. The following additions are only possible in combination with { create; } and therefore, in case of a composition relationship, can only be declared for the parent entity. Example: association _Assoc { create(addition);}
features:instance: Enables dynamic feature control for the association in question.
features:global: Enables global feature control for the association in question.
precheck: Prevents illegal changes from reaching the application buffer by prechecking modify operations.
authorization:none: Excludes the association in question from authorization checks.
authorization:update: Delegates the authorization control to the authorization check that is implemented for the update operation.
Latest notes:
If BDEF strict mode is enabled, it is mandatory that each target entity of a behavior-enabled association within the same composition tree has an own behavior definition.
If BDEF strict mode is enabled, it is mandatory that each target entity of a behavior-enabled cross-BO association has an own behavior definition.
If BDEF strict mode is enabled, to-parent associations and compositions must be publicly and explicitly exposed. Public means without the keyword internal. NON_V5_HINTS
It is technically possible to declare an association as an ancestor association using the syntax addition ancestor. When working with ancestor associations, it is no longer required to explicitly define the RAP authorization master entity, RAP lock master entity, and RAP ETag master entity of a dependent entity, since the path to the respective master entities is derived via ancestor associations. This syntax was first introduced in the context of BDEF extensions and it is mandatory for BDEF extensions. It can also be used in BDEFs of type managed and unmanaged, but SAP does not recommend this. For further details, see the topic about ancestor associations. ABAP_HINT_END
ABAP_FURTHER_INFO Development guide for the ABAP RESTful Application Programming Model, topic Create by Association Operation.
ABAP_EXAMPLE_VX5 - managed The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_MANAGED_ASSOC_ROOT. The root entity explicitly enables read and create access for two associations:
the composition _child to its child node, and
the cross-BO association _ext to an external association which is not part of the composition tree. The child entity explicitly enables read access to the parent entity _parent. In this example, this is required by the RAP locking mechanism (the association from the lock dependent entity to the lock master entity must be explicitly defined, see topic TITLE ). ABAP_NOTE This example does not fully meet the requirements of the RAP BO contract. It is intentionally kept short and simple and serves demonstration purposes only. See more information on the RAP BO contract in the Development guide for the ABAP RESTful Application Programming Model. BDEF DEMO_RAP_MANAGED_ASSOC_ROOT The class CL_DEMO_RAP_MANAGED_ASSOC_1 accesses the business object using EML performs the following steps:
it creates a new instance of _Child via the composition _child from its parent entity.
it creates new instances of the association target entity of the external association _ext
a read by association operation is performed via the external association. ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 - unmanaged The following example shows an unmanaged BDEF based on the CDS root view entity DEMO_RAP_UNMANAGED_AUTH.
The association _child is read- and create-enabled.
The association _parent is read-enabled. BDEF DEMO_RAP_UNMANAGED_AUTH For the implementation in the ABAP behavior pool, see BP_DEMO_RAP_UNMANAGED_AUTH====CCIMP The class CL_DEMO_RAP_UNMANAGED_ASSOC accesses the business object using EML and performs the following steps:
it creates three instances of the parent entity and two instances of the child entity via the association _child.
it reads the content of the parent table via the association _parent and the content of the child table via the association _child and displays the result. ABAP_EXAMPLE_END
ABAP Addition
What does it do? 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 to the association with no more that 16 characters.
ABAP Addition
What does it do?
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. Notation: association _ext without response { create; }
ABAP_EXAMPLE_VX5 - draft-enabled association The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_MANAGED_WITHOUT_RES . It exposes the cross-BO association _ext, which has the foreign entity DEMO_RAP_MANAGED_ASSOC_EXT as association target. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. The RAP handler methods in the ABAP behavior pool are not implemented here. BDEF DEMO_RAP_MANAGED_WITHOUT_RES As the addition without response is used, the mapped, failed, and reported response structures do not include the foreign entity DEMO_RAP_MANAGED_ASSOC_EXT. IMAGE ABDOC_foreign_entity_excluded.jpg 284 130 Without the addition without response, the response structures would look as follows: IMAGE ABDOC_foreign_entity_included.jpg 286 188 ABAP_EXAMPLE_END
ABAP Addition
What does it do? 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 - draft-enabled association The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_MANAGED_DRAFT_ROOT. The BDEF is draft-enabled and the association _child is draft-enabled using the syntax element with draft;. ABAP_NOTE This example does not fully meet the requirements of the RAP BO contract. It is intentionally kept short and simple and serves demonstration purposes only. See more information on the RAP BO contract in the Development guide for the ABAP RESTful Application Programming Model. BDEF DEMO_RAP_MANAGED_DRAFT_ROOT The class CL_DEMO_RAP_MANAGED_DRAFT accesses the business object using EML. It first creates two new draft instances of the parent entity and two new draft instances of the child entity and displays the content of the draft tables. Then it activates the draft entities. The content of the draft tables is written to the persistent tables and the draft tables are emptied. ABAP_EXAMPLE_END
