Wie wir in den letzten Blogbeiträgen - wie z. B. SAP HANA Native Modelling - Zurück auf Anfang? - erfahren haben, ist die Datenbank eines SAP BW Data Warehouse auf HANA Basis nicht mehr nur der Speicherort für die Daten und Metadaten, sondern erlaubt auch Native Entwicklungen.

Dies bedeutet in der Praxis, dass die Möglichkeit besteht, die SAP BW Modelle um SAP HANA Views zu erweitern. Diese Views sind vielfältig einsetzbar, sehr flexibel und durch die Nähe zur Datenbank auch sehr performant. So können sie im Datenfluss z. B. Transformationen ersetzen oder im Reporting als performante und virtuelle Datenquellen dienen. Bei Nutzung von Analyse-Tools, die keine SAP BW Schnittstelle unterstützen oder besser mit der direkten Datenbankverbindung arbeiten, spielen die Views ihre volle Stärke aus.

SAP hat die Möglichkeiten erkannt und bietet für eine Vielzahl von SAP BW Objekten, wie z. B. aDSO, Infoobjekte oder Queries, eine Möglichkeit, SAP HANA Views automatisch generieren zu lassen.

Jedes Data Warehouse steht vor der Herausforderung, seine Daten vor unbefugtem Zugriff zu schützen, was bei der oft großen Anzahl von Objekten, Datenbeständen und Anwendern nicht leicht ist. Neben den SAP-Standardberechtigungen wurde ein weiteres, SAP BW-spezifisches Konzept, die Analyseberechtigungen, entwickelt. Diese Technik wird seit vielen Jahren angewendet und hat sich in der Praxis bewährt.

Die Analyseberechtigung deckt also den SAP BW Bereich hervorragend ab. Was ist aber mit den SAP HANA Views, die ja zum Teil aus dem SAP BW heraus generiert werden?

Bei früheren SAP BW Versionen, wie z. B. SAP BW on Hana und Nutzung der Admin Workbench, hatte man gefühlt keinen Kontakt zur Datenbank. Dies war wegen der Strategie, jede Datenbank zu unterstützen, auch nicht gewünscht. Mit Einführung der SAP HANA Datenbank ist auch SAP BW dahingehend offener geworden, was sich auch in der o.g. Unterstützung von SAP HANA Views widerspiegelt.

Bei der Nutzung des SAP HANA Studio wird die Nähe zur Datenbank sichtbarer, da man SAP BW und SAP HANA Objekte gemeinsam entwickeln und pflegen kann. Lediglich die Perspektive trennen die Bereiche, so nutzt man die BW Modeler Perspektive für die SAP BW Entwicklung und die SAP HANA Modeler Perspektive für Datenbankobjekte wie die SAP HANA Views und SAP HANA Berechtigungen.

Bei den Berechtigungen gibt es aber noch einen kleinen Bruch; so werden Benutzer, Rollen und Berechtigungen nach wie vor in der klassischen SAP GUI verwaltet.

Anhand des Beispiels der beteiligten Perspektiven wird klar, dass wir es hier mit zwei Bereichen zu tun haben. Obwohl alle SAP Objekte Bestandteile der HANA Datenbank sind, also auch in der SAP HANA Modeler Perspektive zu finden sind, werden die BW Objekte wie auch deren Daten von SAP BW verwaltet. Damit übernimmt das SAP BW auch die Verwaltung von Berechtigungen.

Für die SAP HANA Views gilt dies nicht, also was tun?

Die SAP HANA Views sind reine Datenbankobjekte und unterliegen somit der Datenbankverwaltung mit ihrem eigenen Berechtigungskonzept.

Zuerst muss für jeden SAP BW Benutzer auch ein entsprechender DBMS Benutzer erstellt werden. Bei der Anlage dieser DBMS Benutzer, vor allem bei großen Systemen, stellt die SAP einen Report (RSUSR_DBMS_USERS) zur Verfügung, der diese Arbeit erleichtert.

Jetzt müssen die Analyseberechtigungen aus dem SAP BW auf die SAP HANA Views angewendet werden, da der Zugriff auf SAP BW Daten sonst verloren geht.

In SAP HANA gibt es dafür analog die analytischen Privilegien. Für die generierten SAP HANA Views stellt das SAP BW umfangreiche Tools (Prefix RS2HANA, wie z. B. RS2HANA_ADMIN) zur Verfügung.

Berechtigungen werden immer beim Aktivieren vom SAP BW∕4HANA-System aus generiert und dem Benutzer über Rollen zugewiesen. Das SAP BW Customizing (RS2HANA_VIEW)  erlaubt hier umfangreiche Einstellungen für die Generierung von Berechtigungen im SAP HANA. So ist gewährleistet, dass jeder generierte SAP HANA View in der SAP BW Berechtigung einfließt und so verfügbar ist.

Bei individuell erstellten SAP HANA Views muss die Berechtigung manuell vergeben werden und darauf geachtet werden, dass diese nicht die geforderten Berechtigungsanforderungen umgehen.

Übernimmt SAP BW auch die Generierung der notwendigen Berechtigungen bei den externen SAP HANA Views, so können doch nicht alle SAP BW∕4HANA-Berechtigungen 1:1 nach SAP HANA konvertiert werden. So gibt es Einschränkungen bei

• Aggregationsberechtigungen (:)
• Einschränkungen auf bestimmte Kennzahlen

Ganz wichtig ist auch, dass bei Anpassungen der Berechtigungen im SAP BW/4HANA System die SAP HANA Analyseberechtigungen synchronisiert werden. Dazu bietet SAP BW/4HANA extra einen Prozess im Rahmen der Prozessketten analog zur Transaktion RS2HANA_GEN.

SAP HANA Views, die im Rahmen des Generierungs-Szenarios erstellt und gepflegt werden, stehen auch automatisch dem Standard Transportwesen zur Verfügung.

Varianten von Analyse-Modellen können sein

• BW-zentrisches Modell: Ein bestehendes SAP BW System wird um native HANA Modelle ergänzt
• HANA-zentrisches Modell: Natives HANA Reporting System um BW Modelle ergänzt
• Gemeinsames Modell: SAP BW und HANA sind gleich vertreten, Berechtigung soll aber zentral und gemeinsam erfolgen

Beim BW-zentrischen Modell geht man von einem bestehenden SAP BW System aus, das um ein natives HANA Reporting erweitert werden soll. Wichtig ist hier, dass in beiden Systemen dieselben Ausprägungen berechtigt werden sollen. Dies ist bei der Nutzung der externen SAP HANA Views weitestgehend gewährleistet. Bei Abweichungen müssen die fehlenden Berechtigungen manuell angepasst werden.

Das HANA-zentrische Modell basiert primär auf Nativen Reporting Modellen. Wird dieses Modell um SAP BW Reporting Modelle erweitert, gibt es keinen systemunterstützen Weg wie die Generierung, um die bestehende SAP HANA Berechtigungslogik zu übernehmen.

Existieren beide Systeme in ähnlicher Ausprägung, sollen aber einem Berechtigungskonzept folgen, muss eine neutrale zentrale Ablage geschaffen werden, aus denen sich beide Systeme gleichermaßen bedienen und eine durchgehende Berechtigung erstellen.