Ansicht
Dokumentation

ABENBDL_ASSOCIATION - BDL ASSOCIATION

ABENBDL_ASSOCIATION - BDL ASSOCIATION

General Material Data   General Data in Customer Master  
This documentation is copyright by SAP AG.
SAP E-Book

- Operations for Associations

... $[internal$] association _Assoc
              $[abbreviation _newName$]
              $[without response$]
               {$[
              $[internal$] create
             $[${( features:instance $| features:global$}$]
              $[,precheck$]
              $[,authorization:none$]
              $[,authorization:update$]);
              $[with draft$];
               $]}


Additions

1. ... abbreviation _newName ...

2. ... without response ...

3. ... with draft; ...

Effect

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. Still, it is recommended and in BDEF strict mode also enforced to specify the read- and create-by-association operations explicitly.

Cross-BO associations that are not part of the composition tree are not per 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 CDS BDL - use, projection BDEF.

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 can't 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 root entity, can be read enabled, but not create enabled. In an unmanaged RAP BO, this limitation doesn't apply.

CDS BDL Operation Additions

The following CDS BDL operation additions are possible:

  • 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.

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.
  • It is technically possible to declare an association as 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.

Development guide for the ABAP RESTful Application Programming Model, topic Create by Association Operation.

Example - 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 CDS BDL - locking).

The program 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.

Example - 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.

For the implementation in the ABAP behavior pool, see BP_DEMO_RAP_UNMANAGED_AUTH====CCIMP

The program 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.

Addition 1

... abbreviation _newName

Effect

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.

Addition 2

... without response

Effect

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; }

Example

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.

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@@

Addition 3

... with draft; ...

Effect

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 CDS 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.

Example - 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;.

The program 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.






SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   General Material Data  
This documentation is copyright by SAP AG.

Length: 22463 Date: 20240423 Time: 210506     sap01-206 ( 200 ms )