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

Einleitung

Im Blog „dynamische Variablenableitung mit ABAP CDS“ wurde erklärt wie Parameter dynamisch befüllt und auf einen Queryfilter angewendet werden können. Auf dem selben Datenmodell aufbauend, zeigen wir im aktuellen Blog wie Parameterwerte für die Einschränkung von Kennzahlen verwendet werden die in einem Plan-\Ist Vergleich zur Anwendung kommen. Dabei wird die vom User frei selektierbare Planversion automatisch in die Bezeichnung der entsprechenden Kennzahl übernommen (ähnlich der BW Textvariablen).

Daten

Zu den bereits vorhandenen Kostenstellen Plandaten aus Tabelle ZTKST_DVU, werden Ist-Daten (Version 000) in einer separaten Tabelle ZTKST_IST_DVU zur Verfügung gestellt.  Somit haben wir zwei Tabellen, aus denen für unser Modell Fakten bezogen werden:

Zielsetzung

Auf Basis der vorhandenen Daten soll nun, mit Hilfe von eingeschränkten und berechneten Kennzahlen, eine Plan-Ist Vergleich Query erstellt werden. Diese soll Ist-Daten sowie Daten einer Planversion, welche vom User eingegeben wird, gegenüberstellen. Ebenso wird eine prozentuelle Abweichung errechnet. Die vom User selektierte Planversion soll dabei automatisch in die Bezeichnung der Kennzahl in der Query übernommen werden.

Datenmodell

Wir greifen auf das bereits existente Datenmodell zurück und erweitern es für das erforderliche Szenario entsprechend. Wie in der Einleitung erwähnt, kann die Version manuell vom User im Variablenbild gewählt werden, und wird nicht mehr automatisch abgeleitet. Daher sind die für die Ableitung relevanten Objekte bzw. Views nicht mehr im Modell enthalten.

Das Modell wurde so angepasst, dass die Fakten aus der neuen Ist-Daten Tabelle ZTKST_IST_DVU in einer neuen Basic View namens ZI_KST_IST_DVU selektiert und per Union Operation in der neuen Composite View ZC_KST_UNION_DVU mit den Plandaten zusammengeführt wurden. Die bereits vorhandene Composite View ZC_KST_DVU greift nunmehr auf ZC_KST_UNION_DVU und nicht mehr direkt lediglich auf ZI_KST_DVU zu. Die beiden Basic Views ZI_KST_DVU sowie ZI_KST_IST_DVU unterscheiden sich in der Definition nur darin, dass im SELECT Statement auf unterschiedliche Tabellen (mit gleicher Struktur) zugegriffen wird. Hier noch ein kurzer Blick auf die neue Union View welche beide Ergebnismengen zusammenführt:

Eingeschränkte Kennzahl

Im ersten Teil der Blog-Reihe wurde der dynamisch abgeleitete Parameter p_version, dafür verwendet die Query ZC_KST_QUERY_DVU automatisch auf die Budgetversion des Vorjahres einzuschränken. Nun wollen wir die nunmehr manuell gepflegte Planversion, sowie die Version 000 (Ist), dazu nutzen eingeschränkte Kennzahlen zu erstellen. Dazu erweitern wir im ersten Schritt den Cube ZC_KST_DVU um einen Parameter p_version1. Der SELECT im Cube bezieht sich nun, entsprechend den vorher gezeigten Änderungen, auf die Union View ZC_KST_UNION_DVU. Da die Struktur und Feldselektion unverändert sind, muss der Rest der Definition vorerst nicht angepasst werden.

Als nächstes wird der Parameter p_version in der Query an den zuvor erstellen Parameter p_version1 im Cube weitergereicht. Nebenbei wurde in der Query, mittels der Annotationen in den Zeilen 8-10, die Nullzeilenunterdrückung aktiviert. Die Annotationen für den Parameter, die im vorherigen Blog zur automatischen Ableitung der Planversion gedient haben, wurden auskommentiert:

Im nächsten Schritt erstellen wir im Cube, zur bestehenden Basiskennzahl Betrag, zwei zusätzliche Betragskennzahlen namens act und plan1. Mit den entsprechenden Annotationen wird die Standardaggregation auf SUM festgelegt und whr als Währungsfeld referenziert. Mittels CASE-Anweisungen, werden sämtliche Beträge mit Version 000 (IST) auf act und Beträge mit der mitgegebenen Planversion (p_version1) auf plan1 geschrieben:

Damit wurden auf Infoprovider Ebene zwei eingeschränkte Kennzahlen erzeugt, die zum Zweck haben Ist- sowie Plandaten anzuzeigen. Es werden durch das Statement jedoch auch 0 Sätze erzeugt (wäre auch ohne ELSE Zweig der Fall), was beispielsweise bei Ausnahmeaggregationen von Relevanz sein kann, und im nächsten Teil der Blogserie näher beleuchtet wird.

Nun wird die Query View angepasst, die neuen Kennzahlen im SELECT-Statement mit aufgenommen und im Initialaufriss in die Spalten gesetzt. Die Version wird in die freien Merkmale gelegt und die ursprüngliche WHERE Bedingung entfernt, da die Query nun nicht mehr generell auf eine einzige Planversion eingeschränkt sein soll:

Es wurde zusätzlich ein eingabebereiter Queryfilter für die Periode erzeugt (siehe Annotationen in Zeilen 30-31), damit der Auswertungszeitraum bereits beim Aufruf eingeschränkt werden kann.

Textvariable

Ein besonderes Augenmerk ist hierbei auf die Annotationen für die Plankennzahl plan1 in Zeile 43 zu legen. Anstatt EndUserTextlabel für die Bezeichnung in der Query zu nutzen, werden folgende Annotationen genutzt, um das Element zu benennen und die Version aus dem Parameter p_version dynamisch in die Bezeichnung zu integrieren:

Consumption.dynamicLabel.label -> fixer, manuell festgelegter Teil der Bezeichnung (inklusive Platzhalter für variablen Wert -> &1)

Consumption.dynamicLabel.binding.index -> gibt an welcher Platzhalter im Text mit dem Parameter ausgefüllt wird (da bei uns nur ein Platzhalter &1 in Verwendung, ist der Wert 1)

Consumption.dynamicLabel.binding.parameter -> Gibt den Parameter an, dessen Wert in die Bezeichnung übernommen werden soll (p_version)

Es ergibt sich nach den Änderungen folgendes Variableneingabebild für die Query:

Nachdem wir für die Periode das gesamte Geschäftsjahr 2022 sowie für die Version 221 (Budgetversion Vorjahr) eingeben, führen wir die Query aus. Im Initialaufriss sieht man nun Ist- sowie Plandaten nebeneinander im Spaltenaufriss. Die eingegebene Planversion ist in der Kennzahlenbezeichnung integriert:

Prozentuelle Abweichung (berechnete Kennzahl)

Nun wollen wir die prozentuale Abweichung der Ist-Werte vom Plan in der Query berechnen. Im BW Query Designer stünde uns diese Funktion bereits fertig zur Verfügung, hier gelangen wir auch zum Ziel, jedoch sind ein paar zusätzlichen Handgriffe vonnöten.

Zunächst ist es erforderlich % als Einheit zu definieren. Für die spätere Berechnung erzeugen wir ebenfalls eine separate Kennzahl, welche den konstanten Wert 100% beinhaltet. Dies geschieht auf Infoprovider Ebene, also in unserem Cube ZC_KST_DVU. Wir fügen den entsprechenden Code in die Zeilen 27-31 hinzu:

Es wird ein neues Element unit_percent erzeugt welches mittels der Annotation Semantics.unitOfMeasure als Einheit festgelegt wird. Diesem Feld wird der konstante Wert % zugewiesen, der mittels CAST in den ABAP Typ Unit konvertiert werden muss, da der Wert als Einheit dienen soll.

Anschließend wird eine Kennzahl namens hundred angelegt, welche die Konstante 100 beinhaltet. Dieser wird mit der Annotation in Zeile 29 die zuvor definierte Einheit (%) zugeteilt. Als Standardaggreagtion wird MAX festgelegt, da SUM, welches bisher bei den Beträgen angewandt wurde, bei der Prozentkennzahl natürlich falsch wäre.

Nun kann in der Query, mittels Formel, eine berechnete Kennzahl erstellt werden, die die prozentuale Abweichung des Ist vom Plan ausgibt. Der relevante Abschnitt wurde in den Zeilen 45-49 hinzugefügt:

Die neue Kennzahl deviation wird in der Query Abweichung genannt und ebenfalls in die Spalten gesetzt. Wir legen die Anzahl der Dezimalstellen mit der Annotation AnalyticsDetails.query.decimals auf 2 fest. Zuletzt wird mit der Annotation AnalyticsDetails.query.formula die Berechnungslogik erstellt. Wie ersichtlich können in Formeln bereits aus dem BW Query Designer bekannte Daten- als auch mathematische Funktionen wie NDIV0 oder ABS direkt verwendet werden. Die Query zeigt nun wie erwartet die zusätzliche Abweichungsspalte mit den entsprechenden Prozentwerten:

Die zuvor im Cube erfolgten Definitionen (Prozent als Einheit, 100% Kennzahl) waren erforderlich, um das Ergebnis der Berechnung in Prozent ausgeben zu können.

Hinweis: Eingeschränkte Kennzahlen werden bereits auf Provider- bzw. Cube Ebene angelegt, damit diese Elemente in der darüberliegenden Schicht (Query) im Datenmodell in Berechnungen bzw. Formeln verwendet werden können. Zudem wird im Cube die Standardaggregation der Kennzahlen festgelegt, welche als Eigenschaft auch in der darüberliegenden Ebene noch gültig ist. Im Gegensatz zu eingeschränkten Kennzahlen werden berechnete meist in der Query selbst definiert, da Formeln und damit auch entsprechende Funktionen, sowie Ausnahmeaggregationen und weitere Eigenschaften, durch die Analytics Annotationen nur dort wirksam verwendet werden können.

Conclusio

Es braucht anfangs durchaus etwas Praxis bis klar ist, auf welcher Ebene im virtuellen Datenmodell was erstellt werden darf. Der Blog zeigt aber, dass einfache, aber auch gängige Reporting Szenarien mittels CDS-Views realisiert werden können. Es geht dabei jedoch auch hervor, dass nicht alle aus SAP BW bekannten Funktionen standardmäßig zur Verfügung stehen bzw. zusätzlicher Aufwand im Datenmodell erforderlich ist, um die eine oder andere Funktion zu realisieren.  

Weitere Blogs zu diesem Thema:

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