SAP CDS F1 DEFINE HIERARCHY



Get Example source ABAP code based on a different SAP table
  


• DEFINE HIERARCHY ABAP_CDS_DDL_STATEMENT
• SOURCE ABAP_CDS_DEFINE_HIERA
• AS PARENT CHILD HIERARCHY ABAP_CDS_DEFINE_HIERA
• CHILD TO PARENT ASSOCIATION ABAP_CDS_DEFINE_HIERA
• DIRECTORY FILTER BY ABAP_CDS_DEFINE_HIERA
• START WHERE ABAP_CDS_DEFINE_HIERA
• SIBLINGS ORDER BY ABAP_CDS_DEFINE_HIERA
• ASCENDING ABAP_CDS_DEFINE_HIERA
• DESCENDING ABAP_CDS_DEFINE_HIERA
• DEPTH ABAP_CDS_DEFINE_HIERA
• NODETYPE ABAP_CDS_DEFINE_HIERA
• MULTIPLE PARENTS ALLOWED ABAP_CDS_DEFINE_HIERA
• MULTIPLE PARENTS NOT ALLOWED ABAP_CDS_DEFINE_HIERA
• MULTIPLE PARENTS LEAVES ONLY ABAP_CDS_DEFINE_HIERA
• ORPHANS ERROR ABAP_CDS_DEFINE_HIERA
• ORPHANS IGNORE ABAP_CDS_DEFINE_HIERA
• ORPHANS ROOT ABAP_CDS_DEFINE_HIERA
• CYCLES ERROR ABAP_CDS_DEFINE_HIERA
• LOAD BULK ABAP_CDS_DEFINE_HIERA
• LOAD INCREMENTAL ABAP_CDS_DEFINE_HIERA
• CYCLES BREAKUP ABAP_CDS_DEFINE_HIERA
• GENERATE SPANTREE ABAP_CDS_DEFINE_HIERA
• PERIOD FROM TO ABAP_CDS_DEFINE_HIERA
• VALID FROM TO ABAP_CDS_DEFINE_HIERA
• CACHE ON ABAP_CDS_DEFINE_HIERA
• CACHE OFF ABAP_CDS_DEFINE_HIERA
• CACHE FORCE ABAP_CDS_DEFINE_HIERA

ABAP_CDS_DDL - DEFINE HIERARCHY

ABAP_SYNTAX
$[@entity_annot1$]
$[@entity_annot2$]
...
$[@hierarchy_annot1$]
$[@hierarchy_annot2$]
...
$[DEFINE$] HIERARCHY hierarchy
$[parameter_list$]
AS PARENT CHILD HIERARCHY(
SOURCE cds_view
CHILD TO PARENT ASSOCIATION _hierarchy_assoc
$[PERIOD FROM field1 TO field2 VALID FROM from TO to$]
$[DIRECTORY _directory_assoc FILTER BY cds_cond$]
$[START WHERE cds_cond$]
SIBLINGS ORDER BY field1 $[ASCENDING$|DESCENDING$]$[,
field2 $[ASCENDING$|DESCENDING$], ...$]
$[DEPTH depth$]
$[NODETYPE node_type$]
$[LOAD BULK$|INCREMENTAL$|load_option$]
$[MULTIPLE PARENTS ${NOT ALLOWED$}$|LEAVES$|ALLOWED$]
$[ORPHANS IGNORE$|ERROR$|ROOT$]
$[CYCLES ERROR$|BREAKUP$]
$[GENERATE SPANTREE$]
$[CACHE ON$|OFF$|FORCE$])
{ element_list }

ABAP Addition
1 ... SOURCE cds_view
2 ... CHILD TO PARENT ASSOCIATION _hierarchy_assoc
3 ... PERIOD FROM field1 TO field2 VALID FROM from TO to
4 ... DIRECTORY _directory_assoc FILTER BY cds_cond
5 ... START WHERE cds_cond
6 ... SIBLINGS ORDER BY field1 $[ASCENDING$|DESCENDING$], ...
7 ... DEPTH depth
8 ... NODETYPE node_type
9 ... LOAD BULK$|INCREMENTAL$|load_option
10 ... MULTIPLE PARENTS ${NOT ALLOWED$}$|${LEAVES ONLY$}$|ALLOWED
11 ... ORPHANS IGNORE$|ERROR$|ROOT
12 ... CYCLES ERROR$|BREAKUP
13 ... GENERATE SPANTREE
14 ... CACHE ON$|OFF$|FORCE

What does it do?
Defines a CDS entity hierarchy as a CDS hierarchy in the CDS DDL. A CDS hierarchy has a tabular result set whose rows construct parent-child relationships . When a CDS hierarchy is accessed as the data source of a AB_SQL query, it is handled like an SQL hierarchy in which additional hierarchy columns can be selected.
@entity_annot and @hierarchy_annot can be used to specify optional annotations for the CDS hierarchy.
parameter_list is used to declare a list of optional input parameters for the CDS hierarchy.
element_list is used to declare the elements of the CDS hierarchy.
The additions in parentheses after AS PARENT CHILD HIERARCHY define the way the hierarchy is created:
SOURCE must be followed by a ABAP_CDS_V2_VIEW or a ABAP_CDS_V1_VIEW cds_view as the source of the hierarchy.
CHILD TO PARENT ASSOCIATION must be followed by a hierarchy association _hierarchy_assoc exposed by the source cds_view. The hierarchy association must be a self-association where the association source and association target must be the source cds_view. The ON condition of the hierarchy association defines the parent-child relationships between the hierarchy nodes.
START WHERE can be followed by a start condition that defines root nodes for the root node set of the hierarchy. The hierarchy consists of the root nodes of the root node set and their descendant nodes. If START WHERE is not specified, the root node set implicitly consists of all rows where the column that contains the parent node (as defined by the hierarchy association) is initial.
All other additions define further properties of the hierarchy. The rows of the tabular result set of the CDS hierarchy are the hierarchy nodes of the new hierarchy but without its hierarchy columns.
The name of a CDS hierarchy is in the namespace of all global types of an AS ABAP.



Latest notes:

The syntax and functions of a CDS hierarchy overlap to a large extent with the hierarchy generator HIERARCHY in AB_SQL
Unlike in AB_SQL , however, ABAP CDS cannot access the additional hierarchy columns of a CDS hierarchy. Instead, the associated hierarchy attributes must be entered in the element list of the CDS hierarchy if required.
On SAP HANA databases, the result sets of CDS hierarchies plus the hierarchy generator HIERARCHY are created by using the SAP HANA hierarchy generator function HIERARCHY and similar. More information can be found in the HANA SQL documentation.
Since hierarchies generated from the START WHERE condition are buffered on the database, it is advisable to use fixed values for the root nodes of large hierarchies of data that do not change often. To evaluate subnodes of such hierarchies, the hierarchy navigators of ABAP SQL can then be used. The usage of arbitrary parameters for specifying the root nodes especially should be restricted to small hierarchies or for demonstration purposes only.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
Defines a simple CDS hierarchy. The class CL_DEMO_HIERARCHY_TREE accesses the CDS hierarchy and compares this with accesses to similar hierarchies in AB_SQL .
DDLS DEMO_CDS_SIMPLE_TREE
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The mandatory addition SOURCE specifies a ABAP_CDS_V2_VIEW or a ABAP_CDS_V1_VIEW as the hierarchy source of the CDS hierarchy. This source must expose the hierarchy association specified after CHILD TO PARENT ASSOCIATION in its SELECT list.



Latest notes:

CDS view entities and CDS DDIC based views are currently the only CDS entities that can be specified as the source of a CDS hierarchy. More specifically, a CDS hierarchy cannot be the source of another CDS hierarchy.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The CDS hierarchy of the previous example uses the following CDS view entity as a source:
DDLS DEMO_CDS_SIMPLE_TREE_SOURCE
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The mandatory addition CHILD TO PARENT ASSOCIATION specifies the hierarchy association whose ON condition selects the descendant nodes of the root node set. The hierarchy association must be exposed by the CDS view specified after SOURCE .
The hierarchy association defines the parent-child relationship between the hierarchy nodes. The following conditions apply here:
The CDS association must be a self-association.
Only equality comparisons with the operator = and combined using AND can occur in the ON condition of the CDS association.
In each comparison in the ON condition, one field of the association source must be compared with a field (prefixed with _hierarchy_assoc) of the association target.
The association source of the CDS association cannot contain any fields that have the same name as a hierarchy attribute. An alternative element name must be defined for these fields.
Each row of the result set of the source hierarchy_source that meets the ON condition for an existing hierarchy node is included recursively in the hierarchy as its child node (if this is possible).



Latest notes:

The optional additions define further conditions specifying whether a row can be included as a hierarchy node or not.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The CDS view entity of the previous example exposes its association _tree . This CDS association meets all requirements of a hierarchy association and can be used as one.
ABAP_EXAMPLE_END

ABAP Addition TO to

What does it do?
The optional addition PERIOD defines the hierarchy as a temporal SQL hierarchy in which the hierarchy nodes are limited by an adjustment of time intervals.
field1 and field2 are used to specify the fields of the source cds_view that define the lower and upper limits of a period in the hierarchy data. field1 and field2 must be different fields of the same data type. This can be:
The built-in type DATS of ABAP Dictionary.
A data type that is defined by one of the DDIC data elements TIMESTAMP or TIMESTAMPL.
from and to define the lower and upper limit of a time interval that acts as a condition for the periods of the root node set. The data type of from and to must match the data type of field1 and field2. The following can be specified:
Parameters from the parameter list of the hierarchy. Here, only the syntax $parameters.pname is possible.
Literals whose value matches the requested data type. Typed date literals are recommended.
BEGIN_SECTION SAP_INTERNAL_HINT
The data types DATN and UTCLONG are not yet supported.
END_SECTION SAP_INTERNAL_HINT
A temporal SQL hierarchy is created as follows:
Only root nodes of the root node set in which the period defined using field1 and field2 has a non empty intersection with the time interval defined by from and to are taken into account. This intersection forms the validity interval of the root node.
Only child nodes in which the period defined by field1 and field2 has a non empty intersection with the validity interval of the parent node are generated. This intersection forms the validity interval of the child node.
For temporal SQL hierarchies, there are additional hierarchy attributes VALID_FROM and VALID_UNTIL that contain the interval limits of the validity interval of each hierarchy node.
The addition PERIOD must not be used with GENERATE SPANTREE .



Latest notes:

The validity interval of a descendant node is always a subset of a validity interval of all ancestor nodes. Validity intervals can only remain the same or become narrower from hierarchy level to hierarchy level, they can never get wider.
For a descendant node to belong to a temporal SQL hierarchy, it is not sufficient for its period to overlap with the time interval defined by from and to. Only the validity interval of the parent node is decisive. A path of a regular hierarchy is truncated in a temporal SQL hierarchy at the position in which there is no intersection between the period and the preceding validity interval.
The association source of the current hierarchy association must not have any fields called VALID_FROM or VALID_UNTIL. An alternative element name must be defined for these fields.
The value of to can also be less than the value of from. However, a validity interval is formed where necessary. In contrast, if the value of the lower interval limit of the period is greater than the value of the upper interval limit, the validity interval is empty.
Additions such as MULTIPLE PARENTS or CYCLES affect the temporal SQL hierarchy. Nodes that would raise an exception in a regular hierarchy can be hidden in a temporal SQL hierarchy.
On an SAP HANA database, the associated hierarchy generator function HIERARCHY_TEMPORAL is used to create a temporal SQL hierarchy.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The following CDS hierarchies create two temporal SQL hierarchies. Here, date fields and time stamp fields are both used once as periods. The class CL_DEMO_HIERARCHY_TEMPORAL accesses the CDS hierarchies and compares the results with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, CL_DEMO_HIERARCHY_TEMPORAL demonstrates how the addition PERIOD works.
DDLS DEMO_CDS_PARENT_CHILD_DATE_PRD
DDLS DEMO_CDS_PARENT_CHILD_TS_PRD
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The optional addition DIRECTORY defines a filter condition cds_cond for the rows of the source of the hierarchy specified after SOURCE. The hierarchy is generated only from those rows in the source that meet the filter condition. For cds_cond, AND comparisons for equality using = can be specified as follows:
The operator on the left side of a comparison must be an element of the current hierarchy whose name occurs as an operand in the CDS view specified after SOURCE as follows:
On the left side of an ON condition of a CDS association _directory_assoc.
On the left side of an ON condition of the hierarchy association _hierarchy_assoc.
The operator on the right side of the comparison can be a typed literal or a type-compliant parameter from the parameter list of the hierarchy.
The same rules apply to the comparable types as to CDS views.



Latest notes:

A filter condition removes all hierarchy nodes and their descendant nodes from the result set that do not match the condition cds_cond .
The content of the association target of the CDS association _directory_assoc is ignored when the filter condition is evaluated.
The restriction of the operands on the left side of a comparison to the operands of a CDS association of the source is mainly intended for analytical data models that are evaluated by an analytical runtime. The analytical runtime reads data from the association target of this CDS association and passes it to input parameters of the hierarchy that evaluates them in the filter condition.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The following CDS view entity defines a self association _pcr, which itself defines a parent-child relationship, and a CDS association _dir of a DDIC database table DEMO_HIERA_DIR:
DDLS DEMO_CDS_PARENT_CHILD_SRC_DIR
The following CDS hierarchy uses the operand dir_entry from the left side of the ON condition from the CDS view in the filter condition after DIRECTORY _dir FILTER BY:
DDLS DEMO_CDS_PARENT_CHILD_DIR
When the class CL_DEMO_HIERARCHY_PRNTCHLD_DIR is executed, various parameters can be passed and the filter condition is demonstrated.
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The optional addition START WHERE specifies the start condition for creating the hierarchy. START WHERE can be followed by a logical expression cds_cond that selects rows from the source cds_view. The same operators can be specified for cds_cond as in a WHERE clause of a CDS view and the same rules apply. The operands on the left side can be elements of the CDS view specified after SOURCE. The operands on the right side can be literals, parameters from the parameter list of the hierarchy, and session variables. When specifying literals, parameters, and session variables, the same applies as when defining CDS views.
If the addition START WHERE is not specified explicitly, it is added implicitly with a condition that selects all rows where the column that contains the parent node (as defined in the hierarchy association) is initial.
The selected rows are inserted in the hierarchy as a root node set. For each root node in the root node set, the descendant nodes are selected that meet the ON condition of the hierarchy association and, if possible, inserted in the hierarchy.



Latest notes:

It is advisable to always specify the start condition explicitly, since this makes the definition clearer. Furthermore, the root node set defined by the implicit start condition is not always suitable and also cannot be modified using parameters.
The start condition should select a feasible set of root nodes. If no rows in the result set of the source cds_view meet the condition, the hierarchy is empty. If all rows meet the condition, the descendant nodes of every row are selected and inserted.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The following CDS hierarchy uses an interval boundary with BETWEEN as a start condition. The class CL_DEMO_HIERARCHY_START_WHERE accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_PARENT_CHILD_STRTWHR
ABAP_EXAMPLE_END

ABAP_EXAMPLE_VX5
The following CDS hierarchy does not have a START WHERE condition:
DDLS DEMO_CDS_HIERA_NO_START_WHERE
It is implicitly handled like the following CDS hierarchy:
DDLS DEMO_CDS_HIERA_START_WHERE
An implicit START WHERE condition is added that depends on the parent column, which again depends on the hierarchy association. The class CL_DEMO_CDS_HIERA_START_WHERE shows that both CDS hierarchies select the same data.
ABAP_EXAMPLE_END

ABAP Addition $[ASCENDING$|DESCENDING$], ...

What does it do?
The mandatory addition SIBLINGS ORDER BY sorts sibling nodes in the hierarchy. Fields field1, field2, ... of the source cds_view can be specified in a comma-separated list after the addition SIBLINGS ORDER BY to specify the order of the sibling nodes.
The addition ASCENDING or DESCENDING can be specified for each field to specify an ascending or descending order (ascending is the default).
The fields specified after SIBLINGS ORDER BY cannot be of the type LCHR, LRAW, STRING , RAWSTRING, or GEOM_EWKB.



Latest notes:

The addition SIBLINGS ORDER BY is mandatory in the case of CDS hierarchies, since this sort cannot be performed at a later time. For example, the result of a hierarchy navigator in AB_SQL may depend on how the hierarchy specified as a source is sorted. A hierarchy generator specified as a source can be sorted directly here, but this is no longer possible in the case of predefined CDS hierarchies.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The following CDS hierarchy sorts siblings in descending order by the field id. The class CL_DEMO_HRRCHY_SIBLINGS_ORDER accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_SIMPLE_TREE_SIBL_ORD
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The optional addition depth limits the number of hierarchy levels used to create descendant nodes. depth can be a typed literal or a parameter from the parameter list of the hierarchy that has an integer type.
The value in depth has the following meaning:
For depth values greater then 0, the number of hierarchy edges are traversed that is specified in depth, starting from a root node.
If the value of depth is 0, only the root nodes are inserted in the hierarchy.
For depth values less than 0, no hierarchy nodes are created.
The addition DEPTH can be used only if the addition ORPHANS is not specified or is specified as ORPHANS IGNORE.

ABAP_EXAMPLE_VX5
The following CDS hierarchy uses an input parameter p_depth to restrict the hierarchy levels. The class CL_DEMO_HIERARCHY_DEPTH accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_SIMPLE_TREE_DEPTH
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The optional addition NODETYPE identifies an element of the CDS hierarchy that can be used to determine the type of the hierarchy node. The values of this element must be element names, which must also be contained in the element list of the CDS hierarchy. Using the foreign key association or text association, which is assigned (via dedicated annotations) to the respective element , the attributes and the text for the respective hierarchy node can be determined. The element node_type specified with NODETYPE is saved in the metadata of the CDS hierarchy and can be read by consumers using the method GET_NODETYPE_FIELD of interface IF_DD_CDS_READ_API_HIER_C2P.



Latest notes:

A framework that analyzes NODETYPE is currently the ABAP Analytical Engine.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
In the following tree-like CDS hierarchy, the element name is defined as a node type. If a hierarchy node in the element name has the value Apple, it should be a leaf node without any descendant nodes.
DDLS DEMO_CDS_SIMPLE_TREE_NODETYPE
The class CL_DEMO_HRRCHY_TREE_NODETYPE accesses the CDS hierarchy and when executed returns any hierarchy nodes that violate the rule. For that, the node type of the CDS hierarchy is evaluated by the following code sequence:
ABEXA 01557
ABAP_EXAMPLE_END

ABAP_EXAMPLE_VX5
In the following tree-like CDS hierarchy, the element NodeType is defined as a node type. When selecting data from the CDS hierarchy for a view that can be used by the ABAP Analytical Engine, the element NodeType might return two different values. One is CostCenter and the other is HierarchyNode. When NodeType = CostCenter, then the elements ControllingArea and CostCenter must be filled, and with the foreign key association _CostCenter, the text and additional attributes can be derived. When NodeType = HierarchyNode, then the text association _Text is used to get the text for that node. define hierarchy DEMO_COSTCENTERHIER
with parameters
p_controllingArea : fis_kokrs,
P_hierarchy : fis_hryid_cctr
as parent child hierarchy(
source
DEMO_COSTCENTERHIERARCHYNODE
child to parent association
_parent
directory
_Hierarchy
filter by
ControllingArea = $parameters.p_controllingArea
and CostCenterHierarchy = $parameters.P_hierarchy
start where
ParentNode is initial
siblings order by
HierarchyNodeSequence
nodetype
NodeType
)
{
@ObjectModel.foreignKey.association: '_ControllingArea'
ControllingArea,
CostCenterHierarchy,
@ObjectModel.text.association: '_Text'
HierarchyNode,
ParentNode,
@ObjectModel.foreignKey.association: '_CostCenter'
CostCenter,
HierarchyNodeSequence,
NodeType,

_Text,
_CostCenter,
_Hierarchy,
_ControllingArea
}
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The addition LOAD specifies the load policy for the generated hierarchy. It can be used for performance optimization.
The addition works as follows:
BULK This is the default setting. The complete source table of the hierarchy is loaded.
INCREMENTAL Only the rows of the source table that can be reached from the start nodes (root node set) are loaded.
load_option For load_option a parameter from the parameter list of the hierarchy can specified using the syntax $parameters.pname. The parameter must have the data type CHAR or SSTRING and a length of at least 11. Valid values of the parameter are BULK or INCREMENTAL in uppercase and have the same effect as the respective keywords. Invalid values lead to an exception from the database.



Latest notes:

The performance optimization with LOAD INCREMENTAL depends on the data source. If the source table is very large and the hierarchy reads relatively few rows, there is a positive effect. If, by contrast, the source table has only few rows and they are all part of the hierarchy, LOAD INCREMENTAL might even take longer than LOAD BULK.
Do not use LOAD INCREMENTAL with global temporary tables as data source, because it does not have any positive effect then (if anything, it slows down the performance).
The valid values for load_option are the names of enumerated constants with the enumerated type LOAD_OPTION from the class SQL_HIERARCHY. When accessing a CDS hierarchy with a parameter for load_option in ABAP SQL, the character representation of these enumerated constants can be passed.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The following CDS hierarchy uses the addition LOAD with a parameter p_load:
DDLS DEMO_CDS_GUID_HIERA_BULK_INCR
The following SELECT statement is taken from the class CL_DEMO_CDS_HIERA_BLK_INCRMNT:
ABEXA 01443
By converting the enumerated constant sql_hierarchy=>c_load_option-incremental into a character string, the value INCREMENTAL is passed to the parameter p_load . The program works in the same way as described for the executable example for the hierarchy generator of ABAP SQL.
ABAP_EXAMPLE_END

ABAP Addition ONLY$}$|ALLOWED

What does it do?
The optional addition MULTIPLE PARENTS specifies whether the hierarchy can have child nodes with multiple parent nodes:
NOT ALLOWED This is the default setting (a child node can have exactly one parent node only).
LEAVES ONLY Only leaf nodes can have multiple parent nodes.
ALLOWED All hierarchy nodes can have multiple parent nodes.

ABAP_EXAMPLE_VX5
The following CDS hierarchy allows multiple parent nodes for leaf nodes. The class CL_DEMO_HIERARCHY_MULTI_PRNTS accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_PARENT_CHILD_MULTIPAR
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The optional addition ORPHANS defines the way orphan nodes are handled. The following categories of orphan nodes exist:
Hierarchy nodes that could have parent nodes (as specified by the parent-child relationship) but the parent nodes are not in the hierarchy (known as true orphans).
Hierarchy nodes that cannot be reached from the root node set using hierarchy edges.
Hierarchy nodes that are part of a node cycle and cannot be reached from the root node set using hierarchy nodes (known as island orphans).
The additions work as follows:
IGNORE This is the default setting (any orphan nodes are not inserted in the hierarchy).
ERROR Any orphan nodes detected raise an exception.
ROOT Orphan nodes are inserted in the hierarchy as follows:
True orphans are included in the root node set as root nodes and flagged as orphan nodes in the hierarchy attribute HIERARCHY_IS_ORPHAN.
Descendant nodes of true orphans are handled like descendant nodes of parent nodes from the root node set, but are also flagged as orphan nodes in the hierarchy attribute HIERARCHY_IS_ORPHAN.
For the hierarchy nodes of island orphans, a parent node in the root node set is generated for the child node where the cycle occurs. In the generated root node, all columns of the source hierarchy_source contain the null value. In the hierarchy attributes, the additional root node is flagged as an orphan node and PARENT_ID also contains the null value.

ABAP_EXAMPLE_VX5
The following CDS hierarchy transforms orphan nodes into root nodes. The class CL_DEMO_HIERARCHY_ORPHANS accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_PARENT_CHILD_ORPHANS
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The addition CYCLES defines how node cycles are defined. The additions work as follows:
ERROR This is the default setting (an exception is raised when a node cycle is detected).
BREAKUP The traversal of descendant nodes is broken at the child node where the node cycle occurs and the hierarchy attribute HIERARCHY_IS_CYCLE is set to the value 1.
If the addition BREAKUP is specified, MULTIPLE PARENTS ALLOWED must also be specified.

ABAP_EXAMPLE_VX5
The following CDS hierarchy breaks node cycles using CYCLES BREAKUP . The class CL_DEMO_HIERARCHY_CYCLES accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_PARENT_CHILD_CYCLES
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
If the addition GENERATE SPANTREE is specified, only those child nodes without multiple parent nodes are inserted in the hierarchy, starting from every root node. If, due to its parent-child relationships, a child node were to have multiple parent nodes after its root node, exactly one of the potential paths from the root node to this child node is selected and the child node is created for this path only.
If the paths have different lengths, the shortest is selected.
If the paths all have the same length, the first path found is selected.
If the addition GENERATE SPANTREE is specified, the additions MULTIPLE PARENTS, ORPHANS, and CYCLES cannot be specified and other defaults apply in parts:
MULTIPLE PARENTS is used implicitly with ALLOWED.
CYCLES is used implicitly with BREAKUP.




Latest notes:

If the parent-child relationships for the current data do not produce tree-like hierarchies, the addition GENERATE SPANTREE is ignored.
Even if one path (from many paths) to a child node is selected, this does not mean that all others are rejected. In this case, only the edges leading to the child node are missing.
The addition GENERATE SPANTREE can be used to detect whether at least one path leads from a root node to a child node without the result set needing to contain all paths.
The addition GENERATE SPANTREE is used in an SAP HANA database to access the hierarchy generator function HIERARCHY_SPANTREE there.
NON_V5_HINTS
ABAP_HINT_END

ABAP_EXAMPLE_VX5
The following CDS hierarchy uses the addition GENERATE SPANTREE. The class CL_DEMO_HIERARCHY_SPANTREE accesses the CDS hierarchy and compares the result with the hierarchy generator HIERARCHY in AB_SQL used in a similar way. When executed, this class demonstrates how this addition works.
DDLS DEMO_CDS_PARENT_CHILD_SPANTREE
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
The optional addition CACHE defines the caching policy for the generated hierarchy result. It can be used for performance optimization. The addition works as follows:
ON The generated hierarchy is cached by the database if the system assesses the source to be reliably deterministic. This is the default behavior.
OFF The generated hierarchy is not cached by the database.
FORCE The generated hierarchy is cached by the database even if the source cannot be assessed to be reliably deterministic.