CDS - Hierarchie
Was machen eigentlich Hierarchien und wie kannst du sie mit Core Data Services in ABAP aufbauen? In diesem Artikel schauen wir uns die Definition an.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns Hierarchien an, wie du sie aufbauen und definieren kannst und am Ende auch verwenden kannst. Dabei gehen wir auf verschiedene Details im Entwicklungsprozess ein.
Einleitung
Core Data Services, kurz CDS, sind die neuen Standardobjekte, wenn es um die Modellierung von RAP Anwendungen geht oder für den Zugriff auf die Datenbank. Dabei können mit CDS Views wiederverwendbare Objekte im System definiert werden, die du in Anwendungen wiederverwenden kannst. Ändert sich die Datenbank, kann ein Core Data Service weiterhin stabil bleiben und ist damit die perfekte "Middleware".
Definition
Definieren wir uns dazu den ersten Core Data Service. Dabei verwenden wir die Tabelle und den Basis View aus dem Artikel "Custom Data Browser". Dort findest du die Definition der Tabelle und des Views, aber auch eine ausführbare Klasse, mit der du Daten erzeugen kannst. Die Tabelle bildet verschiedene Teams ab und jedes Team hat einen Teamleiter, also eine hierarchische Beziehung.
Interface
Im ersten Schritt definieren wir einen neuen Interface Views auf dem Basis-View, da wir auch weitere Assoziationen definieren wollen. Über das Kontextmenü in den ABAP Development Tools kannst du auf dem Basis View einen neuen Core Data Service anlegen.
Entsprechend wird uns bereits der Core Data Service als Referenz angeboten und wir müssen noch den Namen des neuen Views angeben und eine Beschreibung hinterlegen. Nicht vergessen, dass nach der Zuordnung des Transports erst der Typ des Core Data Services abgefragt wird, wenn du eine VIEW ENTITY erzeugen willst. Hat das beim ersten Schritt nicht geklappt, gibt es hier einen kleinen Tipp.
Nachdem wir den CDS Views nun angelegt haben, definieren wir noch eine neue Assoziation. Die Assoziation verweist auf den aktuellen View und nicht auf ein anderes Objekt. Als Zugriff verwenden wir den Teamleiter und verbinden ihn mit der User-ID. Dadurch können wir über die Assoziation an die Informationen des Teamleiters kommen.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface for Team'
define view entity ZBS_I_DMOTeamView
as select from ZBS_B_DMOTeamView
association of many to one ZBS_I_DMOTeamView as _Leader on _Leader.UserIdentification = $projection.TeamLeader
{
key UserIdentification,
PlayerFullName,
EMailAddress,
PlayerPosition,
ELOScore,
TeamName,
TeamLeader,
_Leader
}
Navigation
In diesem Schritt testen wir die Navigation über die Assoziation. Dazu starten wir über den Core Data Service den "Data Preview". Diesen kannst du über "Ausführen" (F8) starten, das Kontextmenü des Objekts oder das Kontextmenü des Project Explorers. Mit einem Rechts-Klick auf eine Zeile wählen wir "Follow Assoziation".
Als nächstes können wir die definierten Assoziationen wählen. Da wir bisher nur eine Assoziation angelegt haben, wird diese auch angezeigt. Hierbei ist es egal, welches Feld du in der Liste im Schritt vorher ausgewählt hast.
Es werden nun alle Daten angezeigt, die wir über die Assoziation erhalten würden. Da wir mit der Personalnummer auf den View gehen, erhalten wir genau einen Eintrag.
Hierarchie
Nun sind alle Vorbereitungen abgeschlossen und wir können mit der Definition der Hierarchie beginnen. Dazu legen wir auf unserem Interface View einen neuen View an.
Dazu findest du im letzten Bereich des Wizards, nach der Auswahl des Transports, das entsprechende Template. Dieses wählen wir und bestätigen die Erstellung des Core Data Services.
Nun müssen wir noch einige Bestandteile im View befüllen. Dazu geben wir die Assoziation für die Navigation nach oben an, definieren eine Bedingung um den obersten Knoten (erste Teilmenge) zu finden und ein Kriterium, nach dem die Datensätze sortiert werden sollen. Zum Abschluss definieren wir die Felder, die wir nach Außen geben wollen. Deine Hierarchie sollte nun wie folgt aussehen:
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Team Hierarchy'
define hierarchy ZBS_I_DMOTeamViewHR
as parent child hierarchy(
source ZBS_I_DMOTeamView
child to parent association _Leader
start where
TeamLeader is initial
siblings order by
UserIdentification ascending
)
{
key UserIdentification,
TeamLeader
}
Hierarchie Attribute
Neben den Standardfeldern kannst du in einer Hierarchie noch auf zusätzliche Attribute zugreifen, dazu steht wir $NODE im View zur Verfügung und darunter die folgenden Felder.
Dazu eine Erklärung zu den wichtigsten Feldern und Informationen:
- HIERARCHY_RANK - Eindeutige und fortlaufende Nummer zu Identifizierung der Datensätze und Bestimmung der Reihenfolge.
- HIERARCHY_PARENT_RANK - Enthält die RANK ID des Oberknotens, bei Wurzelknoten findest du hier eine Null (0).
- HIERARCHY_LEVEL - Beschreibung auf welchem Level des Baums du dich befindest. Der Baum startet bei Eins (1) und die nächste Ebene wäre (2), usw.
- HIERARCHY_TREE_SIZE - Beschreibt die Anzahl der Knoten unten diesem Knoten, dabei wird der aktuelle Eintrag in die Menge eingerechnet.
- NODE_ID - Eindeutige ID zur Identifizierung eines Datensatzes, wird in den meisten Fällen mit dem Schlüssel befüllt.
- PARENT_ID - Enthält die NODE_ID zum Elternelement, wenn es ein weiteres Element gibt.
- VALID_FROM, VALID_TO - Nur die Hierarchien mit Zeitabgrenzung vorhanden und beschreibt das genutzte Intervall.
Wenn wir die Informationen und Felder von oben nehmen, dann baut sich die Hierarchie unseres Teams wie folgt auf:
Möglichkeiten
Schaust du dir noch die SAP Help Dokumentation zur Erstellung von Hierarchien an, dann wirst du auch noch weitere Möglichkeiten für die Hierarchie finden, wie zeitliche Hierarchien oder Directories. Auf diese Details werden wir aber nicht in diesem Artikel eingehen. Grundsätzlich kannst du Hierarchien auch verwenden, um in Fiori Elements Bäume darzustellen. Auf diesen Aspekt werden wir in einem zukünftigen RAP Artikel eingehen.
Vollständiges Beispiel
Das vollständige Beispiel findest du bei uns im GitHub Repository, sowie alle gemachten Änderungen in diesem Commit im Repository. Hier findest du noch einmal die vollständige Hierarchie aus unserem Beispiel mit den $node Feldern für den Test:
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Team Hierarchy'
define hierarchy ZBS_I_DMOTeamViewHR
as parent child hierarchy(
source ZBS_I_DMOTeamView
child to parent association _Leader
start where
TeamLeader is initial
siblings order by
UserIdentification ascending
)
{
UserIdentification,
TeamLeader,
$node.hierarchy_is_cycle as NodeCycle,
$node.hierarchy_is_orphan as NodeOrphan,
$node.hierarchy_level as NodeLevel,
$node.hierarchy_parent_rank as NodeParentRank,
$node.hierarchy_rank as NodeRank,
$node.hierarchy_tree_size as NodeTreeSize,
$node.node_id as NodeID,
$node.parent_id as NodeParentID
}
Fazit
Mit etwas Vorbereitung ist die Erstellung von Hierarchien mit Core Data Services recht einfach. Diese kannst du dann im Reporting oder zur Erstellung von Anwendungen verwenden. Wichtig ist vor allem, die Aufbereitung der Daten zu verstehen, um selbst einfache Hierarchien zu erstellen.
Quelle:
SAP Help - Hierarchy Definition
SAP Help - DEFINE HIERARCHY
SAP Help - Hierarchy Attributes
