Geänderte Anforderungen an moderne Data-Warehouse-Systeme bedeuten, dass Aspekte wie Einfachheit, Flexibilität und Agilität deutlich wichtiger werden, und somit in der Architektur und Modellierung eben solcher Systeme inhärent berücksichtigt werden sollten.
SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… bietet mit ihrem Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Produkt, SAP BW4/HANA, die Möglichkeiten, über ein – starres und veraltetes – Layered Scalable Architecture (LSA) hinaus auch solche modernen Architekturen umzusetzen. SAP empfiehlt dabei eine Architektur, die sich an der LSA++ orientiert. Dieser neue Schichten-Ansatz zeichnet sich besonders durch den Fokus auf virtuelle Objekte aus. VirtualisierungMit Virtualisierung kann man dedizierte Server in kleinere virtuelle Server… bedeutet, dass weniger Kopien von Daten zwischen Architekturschichten notwendig sind, wodurch deren Design einfacher, kleiner und schneller wird. Die Data Warehouse Architektur soll so möglichst schlank und einfach gestaltet werden.
Weitere Informationen
Lesen Sie hier auch unser Blogartikel zum Thema “Agiles Data Warehousing mit SAP BW/4HANA”
Der klassische BW-Entwickler mit viel Erfahrung in BW 3.x – 7.x weiß: Warnungen sind nichts Schlimmes – wenn man weiß was man da tut wird eigentlich alles hinterher auch funktionieren. In dem Sinne sind Warnungen des SAP BW eher als Hinweise zu verstehen gewesen. Oder, in anderen Worten: “Zeigt die Ampel Gelb, schnell nochmal auf Gas treten.”
Dies ist bei der hybriden Modellierung unter BW/4HANA jedoch anders!
Bei der Generierung von HANA Calculation Views sind die “Hinweise” des BWs in Form von Warnungen durchaus zu berücksichtigen – andernfalls stellt sich später die Erkenntnis ein, dass nämlich nicht alles “einfach so funktioniert”.
Wann Gelb das neue Rot ist: Modellierung von Persistenten Daten
Modellierung von Persistenten Daten
SAP BW unterstützt in der Datenmodellierung eine Vielzahl von Datentypen. Eine Persistenzschicht, bspw. in Form von ADSOs, kann alle BW-seitig erlaubten Datentypen beinhalten, so auch bspw.:
- DEC (Decimal mit frei wählbarer Länge und Nachkommastellen)
- RAW (unkonvertierte Byte-Zeichenfolge)
- INT1 und INT2 (1-Byte bzw. 2-Byte Integer)
Ein ADSO, welches Felder mit diesen Datentypen beinhaltet, lässt sich problemlos aktivieren und beladen.
Soll das Objekt jedoch nun konsumiert werden im Reporting, entweder per Composite Provider oder per HANA CalcView, so sind die obigen Felder nicht enthalten, und damit gar nicht erst nutzbar. Ursache sind, die beim Aktivieren erzeugten, aber bislang ignorierten, Warnungen:
Neben BW-eigenen Restriktionen für das Reporting (bspw. ist Datentyp RAW nicht nutzbar), bestehen auch HANA-seitig Beschränkungen. Insbesondere besteht an Kennzahlen HANA-seitig eine Mindestanforderung an die Länge, um eine gefahrlose Aggregation der Werte zu ermöglichen. Diese Einschränkungen sind bei der SAP dokumentiert.
Lösung: Hier hilft nur, den Warnungen des BW entsprechend Folge zu schenken, und die Datentypen in er Persistenzschicht so abzuändern, dass eine problemlose Weiterverarbeitung sowohl BW-seitig als auch HANA-seitig möglich ist.
Stammdaten-Assoziationen
Die Assoziation von Stammdaten – via OpenODS View oder InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,… – zu beliebigen Feldbasierten Bewegungsdaten stellt eine der großen Stärken der agilen Modellierung von BW/4HANA dar.
Bei einer Generierung von HANA Calculation Views auf Basis dieser Datenmodelle ist jedoch im Composite Provider oder Fakten OpenODS View genau darauf zu achten, ob und welche Warnungen durch das System erzeugt werden:
- RS2HANA_VIEW151: “Navigationsattribut ist von der externen SAP-HANA-View ausgeschlossen”
- RS2HANA_VIEW160: “Externe SAP-HANA-View: Keine PartProvider unterstützt”
- RS2HANA_VIEW047: “Navigationsattribute werden nicht unterstützt”
Die Ursache dafür ist eine gewählte Modellierung, die in diesem Fall die HANA-seitige Konsumierung nicht (vollständig) unterstützt.
Dazu zählen:
- Assoziierung (beispielsweise im Composite Provider) mit InfoObjects und Nutzen von Transitiven Navigationsattributen. Diese stehen dann jedoch im generierten HANA Calculation View nicht zur Verfügung.
- Mögliche Lösung/Workaround: Die Assoziation mit dem InfoObject in einem OpenODS View vom Typ “Fakten” durchführen, die transitiven Navigationsattribute auf eigene Felder mappen, und diesen OOV dann in einem Composite Provider nutzen.
- Assoziierung (beispielsweise im Composite Provider) mit OpenODS Views vom Typ “Stammdaten”, unter Nutzung der Assoziierungsart “Systemweit eindeutiger Name”.
- Mögliche Lösung/Workaround: Die Assoziation mit dem OpenODS View muss dann unter Nutzung der Assoziierungsart “Direktverwendung” erfolgen. In Konsequenz heißt dies dann jedoch, dass in einem Composite Provider mit diesem OpenODS-View nur ein einziges Mal assoziiert werden kann.
Darüber hinaus gibt es noch weitere Einschränkungen, dass unter Umständen Objekttypen (wie ADSO, InfoObject, OpenODS View) in einem speziellen Fall nicht in der Generierung von HANA Views verwendet werden können.
Siehe dazu folgende SAP Dokumentation
Wichtig ist hierbei mitzunehmen, dass es in der Regel doch Möglichkeiten gibt, die entsprechenden Informationen mittels gemischter Modellierung auch HANA-seitig zur Verfügung zu stellen:
- Wählen einer anderen Modellierungsvariante – wie bereits oben erwähnt, Assoziationen an anderer Stelle durchführen (Fakten OOV), oder Link-Satelliten-Modellierung auf Basis CalcViews/OpenODS Views durchführen, anstatt InfoObjecte mit Transitiven Attributen zu nutzen.
- Aktualisierung auf das neuste BW/4HANA Support Package. Diverse Restriktionen, u.a. die Assoziation mit OpenODS Views via systemweit eindeutigem Namen (anstatt Direktverwendung), sind in BW/4HANA 2.0 SPS04 nicht mehr vorhanden. Die Möglichkeiten zur gemischten Modellierung sind daher nicht als statisch zu betrachten, sondern werden also zunehmend besser.
Erzeugung von CalcViews beim Import von Transporten
Besonders häufig werden von klassischen BW-Entwicklern Gelbe Warnmeldungen beim Import von Transporten ins das Zielsystem ignoriert.
Im Gegensatz zu klassischen ABAP-Transporten im ERP-Umfeld, bei denen ein Import mit grün eher die Regel ist, sind BW-Entwickler es gewohnt, dass ein Transport sowohl im Schritt “Import” als auch im Schritt “Nachbehandlung” diverse Warnungen erzeugt. Diese sind aber tatsächlich zumeist kein Problem, bzw. werden durch die geschickte Strukturierung von Transporten durch Folgetransporte behoben. Ein typisches Beispiel hier wäre die Warnung, dass DTPs deaktiviert wurden, nachdem eine Transformation angepasst und neu aktiviert wurde. Genau dieser deaktivierte DTP steht jedoch bereits auf dem gleichen Auftrag, oder einem Folgeauftrag, so dass nach Abschluss sämtlicher Objekt-Nachbehandlungen keine fälschlich inaktiven Objekte verbleiben.
Bei BW/4HANA und der gemischten Modellierung muss jedoch einigen Meldungen erhöhte Aufmerksamkeit zukommen: können für die gerade importierten und aktivierten BW-Objekte nämlich die HANA-Views nicht aktiviert werden, deutet dies auf ein strukturelles Problem mit der BW+HANA-seitigen Kommunikation, und/oder Berechtigungen hin.
Typische Warnungen hierbei gehören zur Meldungsklasse RS2HANA_AUTH, so bspw.:
- RS2HANA_AUTH234: “Replikation fehlgeschlagen”
Hier liegt die entsprechende Ursache nicht in der Modellierung selbst – die hat auf der Entwicklungsumgebung ja erfolgreich stattgefunden.
Stattdessen sind folgende Punkt zu prüfen:
- Ist das Berechtigungskonzept mit Vergabe der notwendigen Rollen, Objekt-, Analytics- und Systemprivileges korrekt im Zielsystem umgesetzt?
- Sind die Systembenutzer – u.a. DDIC, BWREMOTE, SAPHANADB et. al. – auf Seite BW und HANA korrekt mit den notwendigen (und weitrechenden) Schreibrechten ausgestattet?
- Hat eine Berechtigungsreplikation für die vom BW erzeugten Analytic Privileges an die entsprechenden HANA-DB-User stattgefunden? Dies kann auch manuell mittels Transaktion RS2HANA_GEN durchggeführt werden.
- Als Workaround kann auch versucht werden, im Nachgang die nicht erfolgreich generierten HANA Views manuell zu generieren. Hierzu steht die Transaktion RS2HANA_ADMIN auf Seite BW zur Verfügung.
Fazit
Gelb ist das neue Rot – zumindest teilweise, und wenn man sich in einer BW/4HANA hybriden Modellierung befindet, in der es essenziell ist, dass sowohl die BW-seitigen als auch die HANA-seitigen Objekte korrekt erzeugt und miteinander synchron sind.
Natürlich hat es auch dem klassischen BW-Entwickler noch nie geschadet, die Warnungen auch einmal im Detail anzusehen und nicht einfach per se zu ignorieren.
Auch hier hat die agile Entwicklungsmethodik – und vor allem die Ansätze Test Driven Development und Continous Testing – eine klare Aussage: es ist viel effizienter und billiger ein potenzielles Problem früh zu entdecken und zu beheben, als wenn es erst später – gar in produktiver Nutzung – auffällt.
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
