SAP SE’s new architecture paradigm for building a data warehouse in SAP HANA, including in particular the SAP Financial Services Data Platform (SAP FSDP), brings with it a number of challenges for building a reporting layer.
The central difference to classic data warehouses is that there are no longer any persistent data marts. This means that all the logic that used to be implemented in transformations to compile the InfoCube data from the DataStore objects must now be designed in the form of a view hierarchy in SAP HANA Studio.
The following outlines a few basic ideas that should be incorporated into the design of the reporting layer.
Selection of reporting tools and design requirements for reports
In many cases, the reference data that SAP BW has previously provided for reporting (master data, texts, hierarchies) cannot be dispensed with. Reporting access then takes place via a query and one or more composite providers in SAP BW, which in turn access the HANA views and blend their information with the reference data.
Without these requirements, reporting tools, such as Lumira or WebI, can access HANA views directly. They must then prepare the data completely for reporting.
Structuring the view hierarchies
Similar to an earlier InfoCube, it makes sense to group HANA views by transaction and master data, and to define individual blocks within the master data (business partner, business, etc.), which in turn consist of individual sub-blocks. This increases reusability.
Since view hierarchies can become very complex, it is difficult to create an overall view. Reverse engineering the view hierarchy in SAP Powerdesigner can help.
Handling of calculated attributes and key figures
Special preparation of data from the data platform is often required for reporting. A common example is transposing data that is stored in the data platform as name/value pairs – for example, rating information that may come from multiple agencies. In the data tables, there are several rows for the individual ratings for a transaction, but in reporting, these are to be displayed next to each other. Such transpositions and other simple formatting are optimally done directly in the lower layers of the view hierarchy.
Complex calculations for reporting, on the other hand, are better mapped in separate view structures and only mixed in with the other data further up in the view hierarchy.
Naming conventions for reporting
Even though SAP makes an effort with the Financial Services Data Platform to assign speaking names for the individual attributes, it may be necessary to introduce your own naming conventions for reporting, for example to assign German designations.
The translation of the field names is best done at the very bottom of the view hierarchy, so that the correct field names are directly available to all views accessing them.
When the view hierarchy is transferred to SAP Powerdesigner, checks against the naming conventions can also be performed there.
Selection of the right time versions for reporting
First of all, the fundamental question must be clarified whether it is necessary for reporting to also narrow down to the technical version of two-dimensional versioning in SAP FSDP. As a rule, however, it should be sufficient to limit the reporting to the reporting date and to use the latest technical version there. In this case, the view hierarchies for reporting are not based on the tables with historical data, but on the tables with current data.
Furthermore, for optimized data access, it makes sense to use input parameters to pass through the selection of the reporting key date to the very bottom, so that further processing in the view hierarchy takes place exclusively on the relevant versions.
Ongoing performance optimization
The design of view hierarchies should be tested against real or synthetic data as early as possible to evaluate performance implications. The HANA optimizer works very well, but certain constellations in complex view hierarchies push it to its limits. Then individual blocks may have to be rearranged, logics for calculated fields adapted or database hints introduced.
It is particularly important to pay attention to the initial breakdowns with which the business users access the views and to use these as a starting point for the performance analyses.
Over time, many reporting views will emerge on the SAP Financial Services Data Platform (FSDP), just as new InfoCubes were created in the past to cover new reporting requirements. For this reason, it is necessary to define the architectural framework as early as possible during the implementation of SAP FSDP so that each new reporting view can build on the existing building blocks and ensure a consistent and high-performance view of the data.