Dynamische Befüllung von Variablen mit ABAP CDS – Query Design Teil 1

Einleitung

In diesem Blog wird anhand eines einfachen Beispiels gezeigt, wie mittels ABAP CDS dynamisch Variablenwerte abgeleitet und auf einen Queryfilter angewendet werden können. Die Funktion ähnelt somit der Customer Exit Variable aus der klassischen SAP BW Anwendung.

Daten und Zielsetzung

Für dieses Szenario wurde eine Tabelle (ZTKST_DVU) mit Beispieldaten erzeugt, welche unter anderem die Kostenstelle, Geschäftsperiode sowie Planversion und den Betrag enthält.

Die Daten sollen in einer Query, basierend auf einem CDS-Datenmodell, auswertbar sein. Die Query soll jedoch nur Datenssätze zur aktuellen Budgetversion, die in einer Parametertabelle namens ZPARAM_DVU gepflegt ist, anzeigen (Parameter BUDAKT).

Datenmodell

Für das Datenmodell wird im ersten Schritt eine Basic View (ZI_PARAM_VERS_DVU) erstellt die lediglich die in der Parametertabelle gepflegte Budgetversion ausliest:

Im nächsten Schritt legen wir eine weitere Basic View (ZI_KST_DVU) an, welche die Fakten aus unserer Kostenstellentabelle ausliest:

Darauf wird eine View vom Typ CUBE gesetzt, welche auf die zuvor erstellte Entität zugreift. Auf zusätzliche Assoziationen und das Einbinden von Stammdaten über weitere Interface View wird diesmal verzichtet:

Zuletzt wird eine Query View (ZC_KST_QUERY_DVU) erzeugt die ein Select auf den zuvor erzeugten Cube beinhaltet:

Neben der Festlegung der Zeilen- sowie Spaltenstruktur und der Zuweisung passender Feldbezeichnungen, wird ein Parameter namens p_version definiert. An der Stelle ist es wichtig auf die dem Parameter in den Zeilen 12 und 13 zugewiesenen Annotationen näher einzugehen:

Consumption.derivation.lookupEntity:

Hier wird der Name einer anderen (Lookup-) CDS-Entität/View angegeben die den Zielwert für unseren Parameter p_version ausliest. In unserem Fall handelt es sich um die anfangs erstellte View ZI_PARAM_VERS_DVU.

Consumption.derivation.resultElement:

Mit Hilfe dieser Annotation wird das Element, welches den eigentlichen Wert der Version beinhaltet, angegeben, also das Feld wert der View ZI_PARAM_VERS_DVU.

Da die genannten zwei Annotationen zur selben Gruppe gehören, werden sie in der Schreibweise zusammengefasst:

Consumption.derivation: {lookupEntity: ‚zi_param_vers_dvu‘,resultElement: ‚wert‘}

Somit wird die Version 222 dem Parameter unserer Query View übergeben. Bei Aufruf der Query ist die Variable damit automatisch mit der entsprechenden Version vorbelegt:

Um die Verarbeitung der Variable bzw. den Aufruf zu automatisieren, kann zusätzlich die Annotation Consumption.hidden mit dem Wert true auf den Parameter angewendet werden.

Wir fügen sie an entsprechender Stelle in der Query Definition hinzu:

Hiermit wird bewirkt, dass der Eingabeparameter im Eingabefenster nicht mehr erscheint und der Wert automatisch verarbeitet wird.

Im Query Ergebnis erhalten wir entsprechend dem Filter nur Sätze mit Version 222:

Wenn sich die aktuelle Budgetversion im nächsten Jahr ändert, besteht im Datenmodell bzw. der Query kein Handlungsbedarf mehr, es wird automatisch die gepflegte Version in der Query berücksichtigt.

Ableitung mit Parametrisierung

Die Ermittlung der Variable für die Version soll nun zusätzlich parametrisiert werden, so dass an der Entität ZI_PARAM_VERS_DVU, welche die Parametertabelle ausliest, der zu lesende Parameter aus der Querydefinition mitgegeben wird und nicht fest eingeschränkt ist.

Dazu wird zunächst die View ZI_PARAM_VERS_DVU angepasst. Es wird ein Parameter p_param vom Typ charakter (10) hinzugefügt welcher in der WHERE Klausel anstatt des Werts BUDAKT eingesetzt wird:

In der Query View erhält der Parameter p_version drei zusätzliche Annotationen in den Zeilen 15-17:

Consumption.derivation.binding.targetParameter:

Diese Annotation gibt an, welcher Parameter der Lookup Entity (ZI_PARAM_VERS_DVU) versorgt wird. In diesem Fall p_param.

Consumption.derivation.binding.type:

Damit wird der Typ des Wertes festgelegt der an p_param übergeben wird. In unserem Fall ist es ein konstanter Wert.

Consumption.derivation.binding.value

Hiermit wird der an p_param übergebene Wert festgelegt. Diesmal entscheiden wir uns für BUDVJ aus der Tabelle ZPARAM_DVU (Budgetversion des Vorjahres):

Nun wird der Input Parameter der Lookup Entity, also der View ZI_PARAM_VERS_DVU, durch die Consumption.derivation.binding Annotationen in der Query View mit einem Wert versorgt, mit dem die entsprechende Version aus der Parametertabelle ZPARAM_DVU ausgelesen wird. Der Wert wird dann an den Input Parameter p_version der Query View zurückgegeben.

Im Queryergebnis erhalten wir dementsprechend nur noch Daten mit Version 221

Da die Lookup Entity ZI_PARAM_VERS_DVU nicht mehr auf eine bestimmte Version eingeschränkt ist und der Rückgabewert durch den Inputparameter beeinflussbar ist, könnte man beispielsweise mehrere Queries für die Auswertung verschiedener Versionen anlegen, indem man mit den erwähnten Annotationen in der Query View unterschiedliche Werte an p_param mitgibt. Es ist ebenso möglich den Filterwert für die Modellierung einer eingeschränkten Kennzahl zu verwenden. Auf die Modellierung von Kennzahlen sowie weitere Query Design Funktionen wird jedoch noch in einem eigenen Blog näher eingegangen.

Conclusio

Es lassen sich innerhalb von S/4 embedded Analytics mit CDS-Views durchaus Szenarien realisieren für die man im SAP BW System Customer Exit Variablen und ABAP Code heranziehen würde. Es gibt jedoch Einschränkungen. Mehrere Einzelwerte sowie Bereiche beispielsweise, können nicht an einen Parameter gereicht bzw. von diesem verarbeitet werden. Um Selektionskriterien (SELECT-OPTIONS) in CDS zu verarbeiten bzw. an die Datenbankebene weitergeben zu können, kommt man an der Verwendung von ABAP und Table Functions nicht vorbei.

Weitere Blogs zu diesem Thema:

Kennzahlen und Textvariablen mit ABAP CDS-Views – Query Design Teil 2