Hierarchy Vocabulary

Namespace: com.sap.vocabularies.Hierarchy.v1

Terms for Hierarchies

Terms

Actions

Template_ChangeNextSiblingAction (Experimental)

Template for actions that move a node among its siblings and are named in RecursiveHierarchyActions/ChangeNextSiblingAction

Template_CopyAction (Experimental)

Template for actions that copy a node and its descendants and are named in RecursiveHierarchyActions/CopyAction

To give the copied sub-hierarchy a parent, the action invocation can be followed by a PATCH that binds the parent navigation property (for example, Superordinate in the following JSON batch request).

{"requests": [{
  "id": "1",
  "method": "post",
  "url": "HierarchyDirectory(1)/Nodes('A')/CopyAction"
}, {
  "id": "2",
  "dependsOn": ["1"],
  "method": "patch",
  "url": "$1",
  "body": {
    "Superordinate@odata.bind": "Nodes('B')"
  }
}]}

Functions

TopLevels (Experimental)

Returns the first n levels of a hierarchical collection in preorder with individual nodes expanded or collapsed

This function can be used as a transformation whose input set has a recursive hierarchy defined by an Aggregation.RecursiveHierarchy annotation on the entity type of the HierarchyNodes. (Its binding parameter is the unlimited hierarchy as defined here, its output is the limited hierarchy.) The output initially contains the nodes with less than n ancestors in the hierarchical collection given in the binding parameter. Then individual nodes are expanded, shown or collapsed in the output, which extends or reduces the limited hierarchy. Finally the output is sorted in preorder as with the traverse transformation with the hierarchy-specific definition of start nodes.

RecursiveHierarchyType (Experimental)

The properties in this complex type contain information about a node in the result set of a hierarchical request. If the same node occurs multiple times with different parents, certain properties may differ between the occurrences. The properties are derived when hierarchical transformations are applied whose first parameter has the annotated entity type and whose second parameter is the annotation qualifier.

For requests like

SalesOrganizations?$apply=
descendants(..., ID, filter(ID eq 'US'), keep start)
/ancestors(..., ID, filter(contains(Name, 'New York')), keep start)
/Hierarchy.TopLevels(..., NodeProperty='ID', Levels=2)
&$top=10

or

SalesOrganizations?$apply=groupby((rolluprecursive(..., ID,
  descendants(..., ID, filter(ID eq 'US')),
  ancestors(..., ID, filter(contains(Name, 'New York')), keep start))), aggregate(...))
/Hierarchy.TopLevels(..., NodeProperty='ID', Levels=2)
&$top=10

(where ..., stands for hierarchy nodes and hierarchy qualifier) the following collections of hierarchy nodes are distinguished:

RecursiveHierarchyActionsType

The qualified action names identify actions for maintaining nodes in the recursive hierarchy, which are specific for the given annotation qualifier. These actions MUST have the same signature as the template actions linked below, with Edm.EntityType replaced with the entity type on which the recursive hierarchy is defined. The resource path of the binding parameter MUST traverse the hierarchy collection, including any hierarchy directory. If the resource path contains a Content ID reference to an earlier request, the hierarchy directory MUST be determined from the resource path of that request.

{"requests": [{
  "id": "1",
  "method": "post",
  "url": "HierarchyDirectory(1)/Nodes",
  "body": {
    "Name": "child of A",
    "Superordinate@odata.bind": "Nodes('A')"
  }
}, {
  "id": "2",
  "dependsOn": ["1"],
  "method": "post",
  "url": "$1/Hierarchy.ChangeNextSiblingAction",
  "body": {
    "NextSibling": null
  }
}]}

The template actions themselves cannot be invoked.

TopLevelsExpandType (Experimental)

Information about nodes to be expanded