Composite Business Objects in RAP

CDS Views for Composite RAP Business Object

 

Up to now, we worked with RAP Business Objects that consisted of one single node, the root entity. More generally, a Business Object (BO) consists of a hierarchical tree of nodes where each node of is an element that is modeled with a CDS entity and arranged along a composition path.

 

At runtime, one instance of the BO consists of exactly one instance of the root entity and a variable number of instances of the child entities. A sales order, for example, consists of exactly one header (the root entity instance) and several items (child entity instances).

 

The hierarchy of entities is defined through two special kinds of associations, namely by Compositions and To-Parent Associations.

The Composition Tree

 

In RAP, a composition is a specialized association that defines a whole-part relationship and always leads from the parent to the direct child. A child entity (composite part) only exists together with its parent entity (whole). The definition of a composition always requires the definition of a corresponding to-parent association that leads from the child entity to the direct parent entity.

 

In the example, the hierarchy consists of three entities, the root entity (Text), its direct child entity (Line) and an indirect child entity (Word), which has the first child entity as its parent. The text is a composition of text lines and each line is a composition of words. For each of the two compositions, there is a corresponding to-parent association.

 

As well as the compositions and to-parent associations, it is possible to define other relations within the composition tree, for example, from a child entity's child to the root entity. Such relations are defined with ordinary associations. They are not mandatory in general, but might be needed in certain circumstances, for example, to establish a lock master/ lock dependent relation over more than two layers.

 

The following restrictions apply when modeling the composition tree of a RAP Business Objects:

• There is exactly one root entity.
• The root entity may be the source but must not be the target of a composition.
• Source and target of a composition are never the same entity

 

The cardinality of an association expresses how many instances of an entity may be involved in the relationship. It specifies the number of entity instances that are connected to a single source instance and is expressed with a lower bound and an upper bound in the form: x..y (lower_bound..upper_bound). In a RAP BO, the cardinality of the composition can be 0..1 or 0..n, but the cardinality of a to-parent association always has to be 1..1.

 

CDS Compositions and To-Parent Associations

Example: Root Entity

 

The root entity is of particular importance in a composition tree. The root entity serves as a representation of the business object and defines the top node within a hierarchy in a business object's structure. This is considered in the source code of the CDS data definition for D437_I_Text with the keyword ROOT.

 

The root entity (D437_I_Text) serves as the source of a composition which is defined using the keyword COMPOSITION in the corresponding data definition. The target of this composition (D437_I_Line) defines the direct child entity.

 

CDS compositions are defined similarly to CDS associations. The same rules apply for the cardinality and the name of the composition. The main difference is that for a composition no ON-condition is defined explicitly. The ON condition is generated automatically using the ON condition of the to-parent association of the composition target.

 

The name of the composition 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.