In diesem Blogbeitrag werden die Erkenntnisse aus einem kürzlich durchgeführten Reporting-Projekt mit DeltaMaster 6.2.0 auf SAP BW on HANA beschrieben. Alle genannten Erkenntnisse beziehen sich auf das Projekt; eine allgemeine Gültigkeit der Erkenntnisse kann nicht gewährleistet werden.
Datenquelle ermitteln
Zu Beginn eines Projekts muss ermittelt werden, welches System beim Kunden vorliegt, damit die richtige Schnittstelle in DeltaMaster ausgewählt werden kann. DeltaMaster bietet zwei Datenquellen für SAP an (s. Abbildung 1): „SAP HANA“ (relational, SQL) und „SAP BW / Netweaver BI“ (OLAP, MDX).
In diesem Projekt hat der Kunde ein „BW-System Release 7.40 on HANA“ im Einsatz. „on HANA“ bedeutet, dass keine HANA-Objekte verwendet werden, sondern klassisch SAP BW Queries. HANA ist nur die Datenbank des SAP BW, ein direkter Zugriff auf die Datenbank ist nicht vorgesehen.
Abbildung 1: Datenquelle auswählen in DeltaMaster 6.2.0
Konfiguration einer Query
SAP Variablen
Als nächstes muss der Kunde Zugangsdaten, einen berechtigten SAP User sowie Query Informationen bereitstellen. Beim Zugriff auf eine Query wird DeltaMaster den Anwender in den meisten Fällen auffordern, SAP-Variablen auszuwählen (s. Abbildung 2).
Abbildung 2: SAP Variables Dialog in DeltaMaster 6.2.0
Im Umfeld von SAP BW ist es nicht unüblich, bereits an dieser Stelle eine Vorauswahl zu treffen, für DeltaMaster-Anwender hingegen schon. Mit DeltaMaster hat ein Anwender die Möglichkeit, Filter jederzeit je Bericht einzustellen. Demnach sollten alle verfügbaren Elemente ausgewählt werden, um später in einer DeltaMaster-Analysesitzung danach filtern zu können. Jedoch sollten die einzelnen Elemente angehakt werden und nicht der „All-Member“, da die Performance bei Auswahl des „All-Members“ signifikant schlechter ist.
Die schnellste, beste und somit empfohlene Möglichkeit ist, die Variablen gleich fest in der Query zu hinterlegen und den Auswahldialog gar nicht erst anzubieten. Bei jeder Abfrage werden über den Befehl „SAP VARIABLES […] INCLUDING […]“ die Variablen mit angehängt.
Da Queries häufig auch mit anderen Tools, welche nicht die Möglichkeiten von DeltaMaster bieten, verwendet werden, sollte eine eigene Query für DeltaMaster bereitgestellt werden, um diese entsprechend anpassen zu können.
Berechnete Kennzahlen und komplexe Berechnungen
Die Berechnung einer Vorjahres- oder Plan-Abweichung erfolgt üblicherweise auf Basis des von DeltaMaster generierten Statements in der Datenbank. Wird die zu vergleichende Kennzahl, z. B. ein Deckungsbeitrag oder ein Quotient wie Profitabilität, genauso wie die Abweichung im Frontend definiert und somit erst bei einer Abfrage berechnet, verschlechtern sich die Antwortzeiten signifikant. Deswegen sollten alle Kennzahlen im Backend vorausberechnet und nach Möglichkeit festgeschrieben werden. Es ist auch zu überlegen, ob nicht auch Abweichungen in der Datenbank berechnet werden sollten.
Das gleiche gilt auch für komplexe Berechnungen, z.B. Geschäftslogiken wie eine Währungsumrechnung. Auch diese sollten im Backend vorgenommen und nach Möglichkeit in der Datenbank festgeschrieben werden.
Eine weitere Steigerung der Abfragegeschwindigkeit konnte mit der Komprimierung der Daten im SAP BW erzielt werden. Dabei spielt sicherlich auch die Hardware-Ausstattung eine Rolle.
Default Member
Im Projekt tauchte ein Phänomen auf, welches wir uns zunächst überhaupt nicht erklären konnten. Nach einiger Zeit war uns aufgefallen, dass Abfragen auf den Monaten Februar bis Dezember schnell waren – doch wenn der Januar ausgewählt wurde, dauerte die Abfrage um ein Vielfaches länger. Durch eine Analyse des mdx.log haben wir herausgefunden, dass in der WHERE-Bedingung bei Verwendung des Monats Januar dieser nicht mit angegeben wurde, alle anderen Monate hingegen schon. Das Kuriose: das Verhalten war offenbar korrekt.
Zu dem Zeitpunkt, als das Phänomen auftrat, war noch keine Hierarchie in der Perioden-Dimension abgebildet. Stattdessen gab es zwei getrennte Dimensionen Fiskaljahr und Fiskalmonat, beides flache Listen ohne „All-Member“. Januar ist das erste Element in dieser flachen Liste und somit das „Default Member“. Aus diesem Grund lässt DeltaMaster das Element in der WHERE-Bedingung weg, und aus der Datenbank werden alle Monate abgerufen. Die SAP BW OLAP Engine empfängt zwar alle Daten, versteht aber das „Default Member“ und wertet daher nur den Januar aus. Dieses Verhalten ist leicht zu übersehen, da das Ergebnis korrekt ist, aber unnötig langsam. Die Abfragegeschwindigkeit des Monats Januar war im Projekt beinahe exakt um den Anteil an unnötig abgefragten Rohdaten höher. Theoretisch kann dieses bei jedem „Default-Member“ ein Problem sein!
Die Modellierung einer Hierarchie Jahr-Quartal-Monat-Fiskalmonat löste das Problem.
Exkurs: Ist in der Query nur „0FISCPER“ vorhanden, nicht aber „0CALCMONTH“ mit der bekannten Hierarchie Jahr-Quartal-Monat und eine Implementierung von „0CALCMONTH“ nicht gewünscht
oder möglich, dann kann auch auf „0FISCPER“ eine vergleichbare Hierarchie erstellt werden. Im Projekt haben wir Perioden für Rückstellungen o.ä. unter einem separaten Knoten gehängt.
Multiple Queries
Sollte die Performance einer Query weiterhin nicht den Erwartungen entsprechen, so kann eine komplexe Query auch in mehrere einzelne Queries zerlegt werden. DeltaMaster kann in einer Analyse-sitzung mehrere Queries anbinden, und es können auch Kennzahlen aus unterschiedlichen Queries in einem Bericht verwendet werden. Dabei müssen zwei Punkte beachtet werden:
- Es dürfen in einem solchen Bericht nur Dimensionen auf den Achsen verwendet werden, die in beiden Queries vorhanden sind (logische Bedingung)
- Kennzahlen dürfen nur in der Zeilenachse (untereinander, nicht nebeneinander) verwendet werden (technische Restriktion)
Zusammenfassung
- Eigene SAP BW Query für DeltaMaster Anwendung erstellen
- SAP BW Variablen gemeinsam mit dem Kunden definieren und fest in der Query hinterlegen; mit DeltaMaster können Filter im Frontend definiert werden
- Daten in SAP BW komprimieren
- Alle Kennzahlen im Backend vorausberechnen und festschreiben
- Komplexe Berechnungen nicht auf Selektionsbasis durchführen, sondern vorausberechnen und festschreiben
- Achtung: SAP BW kennt keine Standard-Elemente bei flachen Hierarchien
- Perioden-Dimension: Hierarchie Jahr-Quartal-Monat aktivieren/modellieren
- Verwendung einzelner Queries statt einer komplexen Query
Einstellungen in DeltaMaster
Optionen
Auch in DeltaMaster sind einige Einstellungen zu beachten. Eine signifikante Verbesserung der Performance bringt die Deaktivierung der Option „Use MDX command „NON EMPTY“ to hide empty rows or columns“. Vermutlich kann SAP BW die Ergebnisse ohne NON EMPTY aus einem Cache abfragen. Im Standard ist die Option in DeltaMaster aktiviert (s. Abbildung 3).
„Cache results“ sollte aber definitiv aktiviert bleiben, damit DeltaMaster bereits berechnete Ergebnisse nicht nochmals von der Datenbank abfragt.
Abbildung 3: SAP Variables Dialog in DeltaMaster 6.2.0
Die maximale Anzahl der Verbindungen zur Datenbank sollte im Projekt bestimmt und mit der IT des Kunden besprochen werden. Mehr Verbindungen bedeutet nicht automatisch eine bessere Performance. Aus der nachstehenden Tabelle ist eine Messung aus dem Projekt beim Start einer Berichtsmappe mit sechs Ordnerkacheln zu entnehmen.
„Magic Buttons“
Die Erstellung von Berichten geht in DeltaMaster in wenigen Mausklicks mit den „Magic Buttons“, die von Nutzern sehr geschätzt werden, wie von Zauberhand. In der DeltaMaster Version 6.2.0 wird ein äußerst ungünstiges MDX-Statement erzeugt: In der WHERE-Bedingung wird die gesamte Zeit abgefragt und nicht nur die ausgewählte Periode. Die Einschränkung erfolgt stattdessen über ein CROSSJOIN auf der Achse.
Lösung: Wird die Periode aus der Achse entfernt, so wird der CROSSJOIN ebenfalls entfernt und die WHERE-Bedingung um die aktuelle Periode erweitert. Anschließend ist die gleiche Abfrage um ein Vielfaches schneller. Die beiden folgenden MDX-Statements zeigen den gleichen Bericht, zuerst mit „Magic Buttons“ erzeugt und anschließend ohne Periode auf der Spaltenachse.
1) Bericht mit „Magic Buttons“ erzeugt
SELECT Crossjoin(Crossjoin({[0FISCPER ZBW_FISCPER_HIER].[201805 0CALMONTH]}, {[ZDM_FLG1].[temp 8],[ZDM_FLG1].[temp 13],[ZDM_FLG1].[temp 14]}), {[ZDM_FLG2].[#],[ZDM_FLG2].[temp]}) ON AXIS(0),
{[Measures].[00O2TP5XA5F9YGB0CNQ505KWP],
[Measures].[00O2TP5XA5F9YGB0CNQ505R89],
[Measures].[00O2TP5XA5F9YGB0CNQ506A6X],
[Measures].[00O2TP5XA5F9YGB0CNQ50400P],
[Measures].[00O2TP5XA5F9YGB0CNQ503TP5]} ON AXIS(1)
FROM [ZPA_RM10/ZZPA_RM10_Q0003_DM]
WHERE ([0CURTYPE].[21], [0FISCPER].[All
CELL PROPERTIES VALUE
Execution Time: 157.206s2) Gleicher Bericht, aber Perioden-Dimension aus dem Bericht entfernt
SELECT Crossjoin({[ZDM_FLG1].[temp 8],[ZDM_FLG1].[temp 13],[ZDM_FLG1].[temp 14]}, {[ZDM_FLG2].[#],[ZDM_FLG2].[temp]}) ON AXIS(0),
{[Measures].[00O2TP5XA5F9YGB0CNQ505KWP],
[Measures].[00O2TP5XA5F9YGB0CNQ505R89],
[Measures].[00O2TP5XA5F9YGB0CNQ506A6X],
[Measures].[00O2TP5XA5F9YGB0CNQ50400P],
[Measures].[00O2TP5XA5F9YGB0CNQ503TP5]} ON AXIS(1)
FROM [ZPA_RM10/ZZPA_RM10_Q0003_DM]
WHERE ([0CURTYPE].[21], [0FISCPER ZBW_FISCPER_HIER].[201805 0CALMONTH])
CELL PROPERTIES VALUE
Execution Time: 0.343sZusammenfassung
- „Use MDX command „NON EMPTY“ to hide empty rows or columns” deaktivieren
- Berichte nicht mit „Magic Buttons” erstellen: Zeit-Dimension sollte nicht auf einer Achse verwendet werden, da sonst immer die gesamte Zeit abgefragt wird
Weitere Informationen
Weitere Beiträge zu SAP BW
- Beitrag KRE vom 16.10.2009 – SAP BW OLAP Interface
- Beitrag KRE vom 06.03.2015 – Anlegen einer Hilfsdimension in einer SAP BW Query
SAP BW Performance Tipps
https://blogs.sap.com/2013/04/03/sap-bw-query-performance-optimization/
https://blogs.sap.com/2015/04/08/backend-performance-tips/
https://blogs.sap.com/2015/09/09/performance-tips-for-webi-reports-using-bics/
