Der „SAP HANA Modeler“

Autor: Axel Eggers | Veröffentlicht: 09.09.2020

Im vorherigen Teil der Next Level Analytics Serie beschäftigten wir uns mit den ersten Schritten der Datenmodellierung und der Erstellung von Calculation Views im HANA Studio bzw. Eclipse.  

Für die nächsten Schritte wechseln wir jetzt in die Perspektive „SAP HANA Modeler“, um dort den virtuellen Teil der Lösung zu definieren. Unser Ziel ist es ja, auf Basis der persistierten Grunddaten alle notwendigen Berechnungen zum Ausführungszeitpunkt der Abfrage durchzuführen.

Beginnen wir mit einem Calculation View, der uns die an einem beliebigen Stichtag gültigen Einkaufspreise aus den zeitabhängigen Konditionen berechnet.

Folgende Punkte soll der Calculation View leisten:

  • Aus dem allgemeinen Konditionswert sollen mehrere spezifische EK-Preise abgeleitet werden.

  • Dafür muss für jeden Konditionstyp eine spezifische Kennzahl erstellt werden: z.B. für den Konditionstyp ZNNE soll es die Kennzahl ZNNE_PREIS geben. Diese Kennzahl hat dann ausschließlich bei Datensätzen mit dem Konditionstyp ZNNE einen Wert, bei allen anderen Konditionsarten hat sie den Wert 0.

  • Der Anwender soll einen Stichtag eingeben, so dass nur diejenigen Konditionen berücksichtigt werden, die an diesem Stichtag gültig sind.

  • Der Stichtag soll als Vorschlagswert den Vortag anbieten.

  • Die so gebildeten EK-Preise entsprechen dem jeweiligen Konditionswert, wenn bei einer Preisanfrage sämtliche Merkmale abgefragt werden. Werden bei einer Preisanfrage Merkmale weggelassen und damit Datensätze verdichtet, soll der Durchschnittspreis berechnet werden.

Im ersten Schritt fügen wir eine Projektion in den neuen Calculation View ein und ordnen ihr den externen SQL-View von dem aDSO „ZCOND_EK“ zu. Der externe SQL-View ist an seiner Endung „8“ zu erkennen, die hinter dem technischen Namen des aDSO folgt. Die externen SQL-Views bieten für jede Kennzahl immer die interne und externe Darstellung an. Für die weiteren Berechnungen verwenden wir aber immer nur die interne Darstellung, erkennbar an der Endung „__INT“.

Nachdem wir den externen SQL-View für unsere Projektion ausgewählt haben, stehen uns alle seine Spalten zur Auswahl zur Verfügung. Indem wir eine Spalte aus dem Angebot auswählen, definieren wir die Ausgabe von dem Knoten Projektion. Die Liste der Ausgabespalten ist dann wieder das Angebot an Eingabespalten für den folgenden Knoten.

Wir wählen die folgenden Spalten aus:

Projektion EK

Abbildung 01: Projektion EK

Damit wir immer nur diejenigen Datensätze aus dem aDSO selektieren, die am gewünschten Stichtag gültig sind, benötigen wir einen eingabebereiten Input Parameter. Mit diesem Input Parameter können wir dann die Datensätze über die Merkmale GUELTIG_VON und GUELTIG_BIS filtern.

Bei der Definition des Input Parameters vergeben wir einen technischen Namen, hier IP_STICHTAG, und einen Datentyp, hier NVARCHAR mit der Länge 8, weil SAP diesen Datentyp für Tage verwendet, wenn die Datenbanktabellen zu einem aDSO generiert werden.

Über den Parametertyp „DIRECT“ ermöglichen wir es dem Anwender, einen Wert für den Parameter einzugeben. Den Vorschlagswert berechnen wir über einen kleinen SQL Ausdruck, der vom aktuellen Datum einen Tag abzieht und das Ergebnis in der SAP internen Darstellung formatiert anzeigt.

Input Parameter – Stichtag

Abbildung 02: Input Parameter – Stichtag

Wir können jetzt die am Stichtag gültigen Datensätze filtern, indem wir für die Spalte GUELTIG_VON festlegen, dass der Wert von GUELTIG_VON im Datensatz kleiner oder gleich dem Input Parameter ist, während der Wert von GUELTIG_BIS im Datensatz größer oder gleich dem Input Parameter sein soll.

Den daraus generierten Filterausdruck für die Projektion kontrollieren wir im Ausgabebereich des Knotens:

Filterdefinition für Projektion EK

Abbildung 03: Filterdefinition für Projektion EK

Die Ausgabe der Projektion sieht jetzt folgendermaßen aus, nachdem wir den Namen der Spalten „KOND_VAL__INT“ auf „KOND_VAL“ geändert haben:

Ausgabe Projektion EK

Abbildung 04: Ausgabe Projektion EK

Schauen wir uns Beispieldaten für einen Artikel auf dieser Projektion an, erkennen wir die verschiedenen Konditionstypen unterschiedlicher Lieferanten mit ihren Gültigkeitszeiträumen für einen bestimmten Konditionswert.

Beispiel EK-Konditionen

Abbildung 05: Beispiel EK-Konditionen

Wir wollen unsere Projektion jetzt dahingehend erweitern, dass wir aus dem allgemeinen Konditionstyp und -wert spezifische Kennzahlen für die einzelnen Konditionstypen ableiten. Wir erreichen dies über die Definition von „Calculated Columns“, die neben einem Namen und Datentyp auch eine mehr oder weniger komplexe Berechnungslogik enthalten.

Für die Berechnung eines EK-Netto-Netto Preises prüfen wir den Konditionstyp auf den Wert „ZNNE“. Nur wenn der Datensatz diesen Konditionstyp enthält, übernehmen wir den allgemeinen Konditionswert als unseren EK-Netto-Netto Preis. Bei allen anderen Konditionstypen setzten wir den Wert auf Null.

Konditionsspezifischer EK-Preis

Abbildung 06: Konditionsspezifischer EK-Preis

Ganz wichtig dabei: wir erweitern jeden Datensatz aus dem aDSO um diese Preis-Spalte! Immer wenn die Bedingung erfüllt ist, enthält die Preisspalte einen Wert, ansonsten haben alle anderen Datensätze hier nur den Wert Null.

Für die spätere Berechnung von Durchschnittspreisen definieren wir uns einen zusätzlichen Zähler, der in jedem Datensatz den Wert 1 bekommt, in dem der Konditionstyp „ZNNE“ und der Konditionswert gefüllt ist. In allen anderen Datensätze steht hier der Wert Null.

Konditionsspezifischer Zähler

Abbildung 07: Konditionsspezifischer Zähler

Für den ZNNE-Preis benötigen wir auch noch eine spezifische Spalte für die Währung: Abhängig vom Konditionstyp im Datensatz übernehmen wir die allgemeine Währung oder setzten den Initialwert für alle anderen.

Konditionsspezifische EK-Währung

Abbildung 08: Konditionsspezifische EK-Währung

Nach genau diesem Muster definieren wir weitere calculated columns für die Konditionstypen ZLPR und ZRKP, so dass wir insgesamt folgende zusätzliche Spalten in unserer Projektion haben.

Berechnete Spalten

Abbildung 09: Berechnete Spalten

Der Knoten Projektion ist jetzt vollständig definiert und liefert uns die zu einem Stichtag gültigen EK-Konditionen, wobei jeder Datensatz um Konditionstyp spezifische Spalten ergänzt ist.

Beispieldaten Projektion EK

Abbildung 10: Beispieldaten Projektion EK

An diesen Beispieldaten sehen wir u.a. den Effekt, dass unseren berechneten Spalten nur für einige Datensätze einen Wert haben.

Indem wir die Projektion mit dem Knoten Aggregation verbinden, stehen uns alle Spalten aus dem Ausgabebereich der Projektion in der Aggregation zur Verfügung. Wir übernehmen alle Spalten in die Aggregation und können uns jetzt um die Durchschnittsberechnungen kümmern.

Aggregation EK

Abbildung 11: Aggregation EK

Standardmäßig ist für alle Kennzahlen in der Aggregation die Summierung als Aggregationsverhalten eingestellt. Das würde aber dazu führen, dass wir Preise aufaddieren sobald wir Datensätze verdichten und mit derartigen Werten können wir nichts weiter sinnvoll berechnen.

Da wir auch auf dem Aggregationsknoten wieder Calculated Columns definieren können, haben wir die Möglichkeit, Durchschnittspreise zu berechnen. Wir teilen dazu den kumulierten Preis durch den kumulierten Zähler, wobei wir allerdings darauf achten müssen, eine Division durch Null zu verhindern. Der Zähler wurde ja in Abhängigkeit vom Konditionstyp gesetzt und kann daher durchaus den Wert Null haben.

Spezifischer EK-Preis

Abbildung 12: Spezifischer EK-Preis

Für die konditionsspezifische Währung reicht es, die berechnete Spalte aus der Projektion zu verwenden.

Spezifische EK-Währung

Abbildung 13: Spezifische EK-Währung

Auf diese Weise definieren wir weitere calculated columns für die restlichen Konditionstypen.

Berechnete Spalten

Abbildung 14: Berechnete Spalten

Abschließend setzen wir auf dem Knoten Semantik die passenden Typen (Merkmal / Kennzahl) für alle Spalten, so dass alle Objekte, die diesen Calculation View verwenden, das passende Verhalten für jede Spalte anwenden können.

Für die finalen Preise (ZNNE_PREIS) und deren spezifische Einheiten (ZNNE_CURR) haben wir noch diverse Hilfsspalten (CC_ZNNE_PREIS, CC_ZNNE_WHRG, …), die bei der Verwendung des Views nur stören und irritieren würden. Indem wir diese Spalten verstecken / ausblenden, gestalten wir den Ausgabebereich von unserem View übersichtlicher.

Ausgabe Aggregation EK

Abbildung 15: Ausgabe Aggregation EK

In der Gesamtübersicht sehen wir noch einmal die drei Knoten in unserem Calculation View.

Scenario EK

Abbildung 16: Scenario EK

Die folgenden Beispieldaten liefert unser View für einen Artikel und einen Stichtag. Abhängig vom Konditionstyp sind wieder nur bestimmte berechnete Spalten in einem Datensatz gefüllt. Die Werte entsprechen aber dem jeweiligen „Originalwert“, da wir gerade sämtliche Merkmale in der Anzeige sehen.

Beispieldaten EK, ohne Verdichtung

Abbildung 17: Beispieldaten EK, ohne Verdichtung

Entfernen wir jetzt aber Merkmale (Lieferant , Gültig ab) aus den Anzeige, bekommen wir Durchschnittspreise (242,05 + 481,53) / 2 = 361,79.

Beispieldaten EK, mit Verdichtung

Abbildung 18: Beispieldaten EK, mit Verdichtung

Im nächsten Teil der Serie zeigen wir Ihnen, wie wir den Calculation View für die Verkaufspreise aufbauen.

Zurück zum Analytics-Blog

Der Blog hat Ihnen gefallen und Sie wollen gerne direkt per E-Mail benachrichtigt werden, wenn der nächste Artikel erscheint? Gerne geben wir Ihnen Bescheid!

Ansprechpartner SAP Analytics Blog Sascha Hanf

Haben Sie Fragen?

Sascha Hanf ist Ihr Ansprechpartner für den Analytics Blog.

Jetzt Kontakt aufnehmen
Ansprechpartner SAP Analytics Blog Sascha Hanf

Haben Sie Fragen?

Sascha Hanf ist Ihr Ansprechpartner für den Analytics Blog.

Jetzt Kontakt aufnehmen