Example: Direct Child Entity

 

If CDS view entity is the target of a composition, it has to define a CDS to-parent association. The to-parent association is defined using the special syntax ASSOCIATION TO PARENT.

 

The direct child entity (D437_I_Line) servers as target of a composition and therefore defines a to-parent association to the direct parent entity (D437_I_Text).

 

CDS to-parent associations are defined similarly to CDS associations. The same rules apply for the name of the association. An ON -condition has to be defined for which some certain rules apply.

 

The main difference is that for a to-parent association the cardinality cannot be defined explicitly for to-parent associations and is generated as [1..1].

 

A child entity cannot have more than one to-parent associations but itself be a parent entity and define further compositions. Child entity D437_I_Line, for example, is parent of child entity D437_I_Word.

 

The name of the to-parent association must be added exactly once to the select list of the CDS view entity it is defined in, without attributes and alias. If no name is defined for the composition, the name of the composition is the name of the target entity target and this name must be made available in the SELECT list.

 

The following rules apply to the operands and syntax of the ON condition of a to-parent association:

• Only key fields of the parent entity
• All key fields of the parent entity
• Each field of child entity only once
• Fields on child entity with prefix $projection
• Only comparison with "="
• No OR or NOT

 

The child entity of a child entity only requires the to-parent association to its direct parent. It is not mandatory to define a direct association to the root entity and there is no special association type for that purpose. The child entity D437_I_Word of D437_I_Line does not necessarily require an association to the root entity (D437_I_Text).

 

We will see later that, when adding the behavior for the RAP BO, such an association can be helpful, for example, to reference the root entity as lock master or authorization master.

 

If an association to the root entity is needed, it is defined as an ordinary association with cardinality (1..1).

 

Behavior Definition for Composite RAP BO

Behavior Definition for a Composite RAP BO

 

While each entity of a composite RAP BO has its own data definition, there is only one behavior definition source per business object.

 

After some general properties of the business object, for example the implementation type of draft/non-draft enabled implementation, the behavior definition source contains exactly one define behavior statement for each entity of the hierarchy.

Behavior Implementation for a Composite RAP BO

 

If a behavior definition source contains more than one DEFINE BEHAVIOR FOR statements, the corresponding behavior pool, that is the global ABAP class specified after IMPLEMENTATION IN CLASS, contains one local handler class for each of the entities.

 

We recommend that the name of the local handler class is lhc_ where is the name of the CDS view entity or, if provided, the alias name for the entity from the behavior definition.

Associations in the Behavior Definition

 

By adding your associations to the behavior definition, you explicitly enable read access and create access for your associations. This means that you allow a RAP BO consumer to read data from related entity instances or to create new instances of the association target entity.

 

Read and create access is defined with the statement association _Assoc { create; }. Create access is only allowed for compositions. It is not allowed for to-parent associations. This means that child nodes can be created via their parent node, but parents can't be created via their child nodes.