Auswahl der Reportingwerkzeuge und Designanforderungen an die Reports

In vielen Fällen kann auf die Referenzdaten, die SAP BW bisher für das Reporting bereitgestellt hat (Stammdaten, Texte, Hierarchien), nicht verzichtet werden. Der Reportingzugriff erfolgt dann über eine Query und einen oder mehrere Composite Provider in SAP BW, die dann wiederum auf die HANA-Views zugreifen und deren Informationen mit den Referenzdaten abmischen.

Ohne diese Anforderungen können die Reportingwerkzeuge, wie etwa Lumira oder WebI, direkt auf die HANA-Views zugreifen. Diese müssen dann die Daten vollständig für das Reporting aufbereiten.

Strukturierung der View-Hierarchien

Ähnlich wie ein früherer InfoCube bietet es sich an, die HANA-Views nach Bewegungs- und Stammdaten zu gruppieren, und innerhalb der Stammdaten einzelne Blöcke zu definieren (Geschäftspartner, Geschäft, usw.), die dann wiederum aus einzelnen Teilblöcken bestehen. Das erhöht die Wiederverwendbarkeit.

Da die View-Hierarchien sehr komplex werden können, ist es schwierig, einen Gesamtüberblick herzustellen. Ein Reverse Engineering der View-Hierarchie in SAP Powerdesigner kann hier Abhilfe schaffen.

Umgang mit berechneten Attributen und Kennzahlen

Oft wird für das Reporting eine spezielle Aufbereitung der Daten aus der Datenplattform benötigt. Ein häufig vorkommendes Beispiel ist das Transponieren von Daten, die in der Datenplattform als Name/Wert-Paare abgelegt sind – beispielsweise bei Ratinginformationen, die von mehreren Agenturen kommen können. In den Datentabellen stehen zu einem Geschäft mehrere Zeilen zu den einzelnen Ratings, aber im Reporting sollen diese nebeneinander dargestellt werden. Solche Transponierungen und andere einfache Aufbereitungen erfolgen optimalerweise direkt in den unteren Schichten der Viewhierarchie.

Komplexe Berechnungen für das Reporting hingegen werden besser in separaten View-Strukturen abgebildet und erst weiter oben in der View-Hierarchie zu den übrigen Daten hinzugemischt.

Namenskonventionen für das Reporting

Auch wenn sich SAP bei der Financial Services Data Platform Mühe gibt, sprechende Namen für die einzelnen Attribute zu vergeben, kann es notwendig sein, eigene Namenskonventionen für das Reporting einzuführen, beispielsweise um deutsche Bezeichnungen zu vergeben.

Die Übersetzung der Feldnamen findet am besten ganz unten in der View-Hierarchie statt, so dass die korrekten Feldnamen allen darauf zugreifenden Views direkt zur Verfügung stehen.

Bei einer Übernahme der View-Hierarchie in SAP Powerdesigner können dort auch Prüfungen gegen die Namenskonventionen durchgeführt werden.

Auswahl der richtigen zeitlichen Versionen für das Reporting

Zunächst muss die grundlegende Frage geklärt werden, ob es für das Reporting notwendig ist, auch auf die technische Version der zweidimensionalen Versionierung in der SAP FSDP einzugrenzen. In der Regel sollte es aber ausreichend sein, auf den Reporting-Stichtag einzugrenzen und dort die jeweils aktuellste technische Version zu verwenden. In diesem Fall werden die View-Hierarchien für das Reporting nicht auf die Tabellen mit den historischen, sondern auf die Tabellen mit den laufenden Daten abgestellt.

Weiterhin ist es für einen optimierten Datenzugriff sinnvoll, die Selektion des Reporting-Stichtags mit Hilfe von Input-Parametern bis ganz unten durchzureichen, sodass die weitere Verarbeitung in der View-Hierarchie ausschließlich auf den relevanten Versionen stattfindet.

Laufende Performanceoptimierung

Das Design der View-Hierarchien sollte so früh wie möglich gegen echte oder synthetische Daten getestet werden, um Auswirkungen auf die Performance zu evaluieren. Der HANA-Optimizer arbeitet zwar sehr gut, aber bestimmte Konstellationen in komplexen View-Hierarchien bringen ihn an seine Grenzen. Dann müssen ggf. einzelne Blöcke umgestellt, Logiken für berechnete Felder angepasst oder Datenbank-Hints eingeführt werden.

Dabei ist es besonders wichtig, darauf zu achten, mit welchen initialen Aufrissen die Fachanwender auf die Views zugreifen und diese als Ausgangspunkt für die Performanceanalysen zu nutzen.

Im Laufe der Zeit werden auf der SAP Financial Services Data Platform (FSDP) viele Reporting-Sichten entstehen, genauso wie früher neue InfoCubes erstellt wurden, um neue Reportinganforderungen abzudecken. Aus diesem Grund ist es notwendig, möglichst frühzeitig während der Einführung der SAP FSDP die architektonischen Rahmenbedingungen festzulegen, so dass jede neue Reporting-Sicht auf den vorhandenen Bausteinen aufbauen kann und eine konsistente und performante Sicht auf die Daten gewährleistet ist.