vorheriger Artikel
SAP BW stellt als Business-Intelligence-Paket viele Möglichkeiten für ein performantes Reporting bereit – birgt jedoch auch zahlreiche Hemmnisse, die die Performance merklich verlangsamen. Am Beispiel von in der Anwendung verfügbaren Berichtsfiltern zeigt dieser Beitrag, wie kleinste Adaptionen die Leistung von SAP BW mindern und wie eine performante Einstellung der Filtermöglichkeiten zu besseren Ergebnissen führen kann.
Durch Definition der fachlichen wie technischen Inhalte ermöglicht die Nutzung von SAP BW Query eine perfekte Vorbereitung der Interaktion von Anwendern und Daten. Was viele Anwender – vor allem fachlich orientierte Power User – jedoch meist nicht wissen: Jede noch so kleine Einstellung kann mitunter immense Auswirkungen auf die Report-Performance haben. Im Falle von Filtern kann dies beispielsweise von schlicht nicht nutzbaren bis hin zu hochperformanten und schnellen Reports variieren.
Das nachfolgende Beispiel zeigt eine Filterauswahl aus dem Bereich EC-PCA mit dem InfoObject „Belegart“ in Analysis for Office:
Filtern ja, aber wie geht’s richtig?
Bei der Betrachtung von Berichtsfiltern stellt sich der Anwender zuerst einmal die Frage: Wo kann das Filterverhalten definiert werden und welche Gründe gibt es, diese Einstellungen an die eigenen Reporting-Anforderungen anzupassen? Wie bei SAP BW üblich, gibt es zahlreiche Möglichkeiten, das Verhalten der Filterauswahl zu definieren, um so eine größtmögliche Wiederverwendung zu erreichen. Gerade für Query-Entwickler kann dies eine erhebliche Arbeitserleichterung darstellen, da diese im idealen Fall keine Einstellungen ändern müssen. Klar ist: Anwender sollten die zur Verfügung stehenden Filtermöglichkeiten kennen und nutzen, denn die von SAP vordefinierte Auswahl stellt die am wenigsten performante Lösung dar und lässt in Sachen Schnelligkeit häufig zu wünschen übrig.
Die Einstellung des Filterverhaltens kann in folgenden Objekten vorgenommen werden:
1. Im InfoObject und somit global für CompositeProvider und Query:
2. Im CompositeProvider, um auf von dem expliziten Datenmodell begründete Anpassungen zu reagieren:
3. In der Query, wenn Besonderheiten im Query-Aufbau eine Änderung notwendig machen:
Die oben getroffene Auswahl ändert das Abfrageverhalten von SAP BW auf die Datenbank und damit auch die Anzahl der sichtbaren Einträge. Die Ermittlung von Filtern aus den Stammdaten beispielsweise ist in sehr hoher Geschwindigkeit möglich, zeigt allerdings auch Merkmale ohne Daten, was den Anwender irritieren kann.
Folgende Filteroptionen stehen zur Verfügung:
Auswahl | Beschreibung | Problematik |
Nur verbuchte Werte für Navigation (Standard) | Der Standard stellt bei der Filterung nur Merkmale zur Auswahl, die in der Query vorkommen. Diese Einstellung wertet somit sämtliche in der Query enthaltenen Kennzahlen anhand des Filteraufrisses aus. | Bei einem Merkmal mit hoher Kardinalität, wie einer Belegnummer, werden für alle Belegnummern (Queryfilter werden berücksichtigt) die Kennzahlen der Query ausgewertet. Hat eine Query viele Ausnahmeaggregationen oder ist die Anzahl der Einträge in den Stammdaten sehr hoch, kann es bis zur Anzeige der Filterauswahl sehr lange dauern, oder der Vorgang wird sogar abgebrochen. Da die Werte durch die Analytic Engine ermittelt werden, wird zudem die Beschränkung der Anzahl von Einträgen bei der Ermittlung nicht berücksichtigt. |
Nur Werte im InfoProvider | Die Einstellung ignoriert die Kennzahlen einer Query (berechnete sowie eingeschränkte) und führt einen Join mit den zugrundeliegenden InfoProvidern durch. Dies kann direkt auf der HANA-Datenbank passieren und berücksichtigt auch die Begrenzung der Ergebniszeilen. | Diese Einstellung muss gewählt werden, wenn das InfoObject eine hohe Kardinalität aufweist oder die Berechnungen in einer Query sehr komplex sind. Die Queryfilter werden berücksichtigt, jedoch nicht die Kennzahlen. Somit könnten im Filterfenster Einträge ohne Daten angezeigt werden, wenn zum Beispiel eingeschränkte Kennzahlen genutzt werden. |
Werte in Stammdatentabelle | Die InfoProvider werden ignoriert und es wird nur auf die Stammdatentabelle zugegriffen. Dies unterdrückt den Join auf die InfoProvider und stellt die performanteste Variante dar. | Stammdatenabfragen sind sinnvoll, wenn bewusst alle Merkmale eines InfoObjects zur Verfügung stehen sollen. Zudem kann ein CompositeProvider aufgrund von Joins, Berechnungen oder anderen Eigenschaften verursachen, dass die Filterliste nicht performant geöffnet wird. Diese Einstellung umgeht diesen und sämtliche Filter einer Query und ist dabei der performanteste Weg des Zugriffs. |
Merkmalsbeziehungen | Kann nur in einer Query ausgewählt werden und ist relevant für die Planung. Diese Filteroption soll hier nicht weiter behandelt werden. |
Beispiele aus der Praxis
Die folgenden Beispiele aus der Praxis zeigen Ursache und Lösung möglicher Probleme auf:
Problem | Ursache | Lösung |
Analysis for Office stürzt häufig ab, wenn der Anwender die Auswahlliste öffnet. | Dies ist häufig der Fall, wenn ein InfoObject mit hoher Kardinalität, wie der Belegnummer, angezeigt werden soll und Ausnahmeaggregationen in der Query vorhanden sind. Die Analytic Engine muss für alle Belege die Berechnungen durchführen, was häufig zum Abbruch aufgrund Speichermangel oder Laufzeit führt. | Änderung auf die Einstellung „Nur Werte im InfoProvider“ im InfoObject. Dies umgeht die Berechnung sämtlicher Kennzahlen für jeden Eintrag (z. B. Belegnummer) und führt einen direkten Join auf HANA-Ebene durch. Dieser wird über TOP 1000 abhängig von der Begrenzung in BO eingeschränkt und ist somit performant.
|
Das Auswahlfenster von z. B. Kalendermonat (0CALMONTH) öffnet sich nur sehr langsam. | Eine Query ist häufig auf einen Monat eingeschränkt, um das Datenvolumen zu begrenzen. Ändert der Anwender diesen Filter, führt die Analytic Engine für den gesamten Datenbestand (da der Zeitfilter fehlt) die Berechnung der Kennzahlen durch. | Änderung auf die Einstellung „Nur Werte im InfoProvider“ in der Query. Dies umgeht die Berechnung der Kennzahlen ohne zeitliche Einschränkung und führt einen direkten Join auf HANA-Ebene durch. |
Das Auswahlfenster öffnet sich nur langsam, obwohl nur Werte aus dem InfoProvider gelesen werden. | Wird ein virtueller InfoProvider mit Zugriff auf ein Vorsystem oder Hadoop genutzt, kann auch ein Join auf die Daten nicht performant sein. | Die Einstellung „Werte in Stammdatentabelle“ in dem CompositeProvider umgeht den Zugriff auf die Bewegungsdaten und liest direkt aus der Stammdatentabelle. |
Umsetzung bei Drittanbieterlösungen mit MDX-Zugriff wie Longview
Da diese Einstellungen nur in SAP-BI-Mandanten wie Design Studio, Analysis for Office etc. berücksichtigt werden, müssen Tools von Drittanbietern das Verhalten selbst steuern. Wie dies zum Beispiel für Longview funktioniert, ist in einem unserer Blogbeiträge beschrieben.
Fazit
Kleine Änderung, große Wirkung: Um Aufwände bei der Entwicklung von Querys zu vermeiden, sollten Fachbereich und BI-Abteilung immer im Austausch bleiben, Probleme mit den Query-Einstellungen besprechen und die Lösung zentral bereitstellen. Dabei sollte sich aber auch der Power User über das Verhalten von Filtern und deren Auswirkungen bewusst sein, um ggf. eine Optimierungsmöglichkeit erkennen und kommunizieren zu können.
Sie stoßen häufiger auf Performance-Probleme? Sprechen Sie uns gerne an. In einer ersten Analyse oder unserem BI-Quickcheck identifizieren wir Stolpersteine und bieten Ihnen schnelle und unkomplizierte Hilfe zur Selbsthilfe.
