Bei der hybriden oder auch mixed Modellierung eines SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Mehr BW basierten Data Warehouses werden Teile der Datenmodellierung über HANA SQL / native Mittel durchgeführt. Die Modellierung wird dabei in den meisten Fällen durch HANA Calculation Views durchgeführt.
Daher ist es sehr wichtig die Funktionsweisen von HANA Calucation Views zu verstehen, um sie korrekt in ein SAP BW getriebenes Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Mehr zu integrieren. Seit der Veröffentlichung von Revision 26 für SAP HANA wird für die Parametrisierung von HANA Calculation Views zwischen Input-Parametern und Variablen unterschieden. Bis dahin standen lediglich Variablen für die Dateneingrenzung zur Laufzeit bereit. Zwar ist in Frontends (wie SAP Analytics CloudDer Begriff Cloud stammt aus dem Englischen, zu deutsch „Wolke“…. Mehr) erstmal kein Unterschied zwischen Variablen und Input Parametern erkennbar. Aus funktionalen Gesichtspunkten weisen beide Varianten jedoch erhebliche Unterschiede auf. Wir möchten mit diesem Beitrag einen Überblick zu den Unterschieden geben anhand eines Beispiels. Unser Beispiel bezieht sich auf eine Eclipse basierte Implementierung, weil dies für BW mixed Modelle bisher der de facto Standard ist (HDIHana Depoloyment Infrastruktur Container Mehr Container sind noch vollständig integriert).
Unterschiede
Die nachfolgende Tabelle gibt einen Überblick zu den unterschiedlichen Ansätzen von Variablen und Input Parametern:
Im Detail: Variablen in HANA Calculation Views
Die Eingabe einer Variablen erfolgt durch den Anwender beim Aufruf der Calculation View. Die Variable ist nur clientseitig (z.B. Analysis Office, Analytics Cloud etc.) bekannt. Sie bezieht sich immer auf ein Attribut und kann nur Werte liefern, welche bereits in der Spalte vorhanden sind. Innerhalb des SQL-Statements der Calculation View wird die Variable mit der WHERE-Klausel verarbeitet. Aufgrund dieser relativ simplen Funktionsweise findet die Definition der Variablen nur im „letzten“ (d.h. vor Bereitstellung an Frontend. Siehe Beispiel in Grafik unten) Calculation View statt. Ein Mapping über mehrere Objekte wie zum Beispiel Calculation Views oder Composite Provider ist daher nicht notwendig.
Beispiel
Die Ausgabe eines HANA Calculation Views soll über das Geschäftsjahr bzw. die Periode eingeschränkt werden. Zunächst wird in den Semantiken der CalculationView für das gewünschte Attribut ein Variablen-filter angelegt:
Bei der Erstellung einer Variablen kann zwischen den Selektionskriterien „Single Value“, „Intervall“ und „Range“ gewählt werden. Zudem können Defaultwerte angegeben werden, welche eine Konstante oder einen Ausdruck als Grundlage haben können. In unserem Szenario wird per Default mithilfe der NOW() Funktion automatisch die aktuelle Fiskalperiode als Variable gesetzt:
Bei der Ausführung des Calculation Views (bspw. mit Analysis Office) erscheint nun ein Popup, in welchem die definierten Variablen gepflegt werden können. Zusätzlich kann über den Value Help Dialog kann aus allen verfügbaren Variablenwerten gewählt werden:
Im Detail: Input-Parameter in HANA Calculation Views / Composite Provider
Die Eingabe erfolgt durch den Anwender beim Aufruf der CalculationView. Input-Parameter werden von der HANA-Datenbank verarbeitet und dienen dazu eine View intern zu parametrisieren. Sie können auch in Formeln, zum Beispiel zur Definition einer berechneten Spalte verwendet werden. Eine wichtige Eigenschaft ist, dass es möglich ist, Input-Parameter per Mapping-Funktion über beliebig viele Views hinweg zu übergeben. Neben diesem rein HANA-seitigen „Durchschleusen“ ist es aber ebenfalls möglich, diese Input-Parameter über Composite Provider im ABAP-System zu verarbeiten. In diesem Fall stehen die Input-Parameter als Felder im Composite Provider zur Verfügung, können anschließend aber auch wieder an eine CalculationView übergeben werden. Auch der Knoten, in welchem der Input-Parameter letztendlich verwendet werden soll, kann bestimmt werden. Auf diese Weise kann das Verhalten von CalculationViews sehr gut gesteuert werden. Ein weiterer Vorteil dieser flexiblen Verarbeitung von InputParametern ist, dass Daten bereits auf „unterster“ Ebene eingegrenzt werden können. Dies bringt je nach Szenario natürlich Performancevorteile. Die untenstehende Abbildung zeigt ein Beispiel für ein hybrides Datenmodell:
Beispiel
Wir haben ein hybrides SAP BW Datenmodell, bei dem die Verarbeitung der Daten über mehrere geschachtelte Calculation Views erfolgt Mithilfe des Input-Parameters „Mehrwertsteuersatz“ soll eine Spalte berechnet werden (Betrag + Mehrwertsteuer). Die HANA nativ verarbeiteten Daten werden über einen Composite Provider zurück in das SAP BW geholt. Der Input-Parameter muss daher ebenfalls an einen CompositeProvider übergeben werden.
Szenario
Zunächst wird in den Semantiken der „untersten“ CalculationView ein InputParameter angelegt:
Es kann zwischen mehreren Parametertypen gewählt werden, für dieses Szenario wird der „direkte“ genommen. Wie auch bei Variablen, kann ein Standardwert in Form einer Konstanten oder eines Ausdrucks gesetzt werden.
Anschließend kann in allen darauf aufbauenden Calculation Views der Input-Paramter verwendet werden (per Mapping in den Semantiken):
Innerhalb des SQL-Statements werden Input-Parameter mit der PLACEHOLDER-Klausel verarbeitet:
In diesem Beispiel wird eine berechnete Spalte angelegt, innerhalb welcher ein Betrag unter Berücksichtigung des eingegebenen Mehrwertsteuersatzes angepasst wird. Diese Berechnung kann beliebig weit in andere Calculation Views verlagert werden („Push Down“):
In dem Composite Provider ist der Input Parameter sichtbar und kann gemappt werden.
Bei der Ausführung öffnet sich zu Beginn ein Popup, in welchem analog zur Variableneingabe der Wert für den InputParameter gesetzt werden kann. Der definierte Defaultwert ist bereits eingetragen:
Die Datenvorschau lässt erkennen, dass die hinterlegte Logik unter Berücksichtigung des über mehrere Ebenen weitergegebenen InputParameters, die Beträge der linken Spalte, in der berechneten Spalte rechts daneben (Bruttobetrag), korrekt um die Mehrwersteuerbeträge angereichert hat. Zur anschaulichen Darstellung wurde ein Mehrwertsteuersatz von 200% gewählt:
Fazit
Um Eingaben eines Nutzers zu erhalten kann sowohl auf Variablen als auch auf Input Parameter zurückgegriffen werden. Variablen lassen sich vergleichen mit sehr einfachen Eingabevariablen aus der BW Query. Es lassen sich die Werte eines Merkmals relativ einfach einschränken. Input Parameter haben wesentlich mehr Freiheitsgrade. Es wird ein fiktives Feld geschaffen und ein Wert für dieses Feld abgefragt. Der Eingabewert kann flexibel in anderen Logiken (z.B. Calculated Columns) verwendet werden. Eine vergleichbare BW Queryfunktion gibt es nicht, weil (auch Customer Exit) Variablen sich immer auf ein Merkmal beziehen und dieses einschränken. Aus Performancegesichtspunkten hilfreich ist das Mapping von Input Parametern über mehrere Calculation Views hinweg, um Datenmengen möglichst weit „unten“ einzuschränken.
Autor: David Pangalela
KONTAKT
Christopher Kampmann
Senior Manager
SAP Information Management
