Transaktionsdaten enthalten in der Regel Stammdatenschlüssel, welche verschiedene Ausprägungen einer Entität zum Beispiel Produkt abbilden. Die Texte (Kurz/Mittel/Lang) der verschiedenen Produkte bilden mit den Attributen und Hierarchien die zum Merkmal gehörenden Stammdaten.
In klassischen SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… BW werden diese Informationen i.d.R. in InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,… abgelegt. InfoObjects bieten dabei in (SAP-)Reportingtools die komfortable Möglichkeit zwischen der Anzeige der Texte oder Schlüssel/ ID’s zu Wechseln beziehungsweise beide einzublenden. Mit SAP BW/4 HANA ergibt sich zudem die Möglichkeit Texte ebenfalls mit Hilfe von Open ODS Views zu modellieren.
Inhaltsverzeichnis
2. Modellierung von Texten mit InfoObjects
3. Modellierung von Texten mit Open ODS Views
4. Erstellung des Open ODS Views (Texte)
5. Zwischenergebnis zur 1:1 Nutzung von Open ODS View Texten
6.1 Modellierung Open ODS View mit “Textattributen”
6.2 Erstellung von Reporting Calculation Views und Labeling
8. Fazit
Je nach dem welches technische Objekt für die Stammdatenmodellierung genutzt wird und wie der Zugriff von Frontends auf SAP BW Daten erfolgt, ergeben sich funktionale Einschränkungen bzw. Besonderheiten. Mit diesem Blogeintrag geben wir Einblick in die verschiedenen Modellierungsarten und Folgen aus Sicht von Frontends. Unsere Untersuchung ist mit einem SAP BW/4 HANA 2.0 SP03 und Analysis Office als Frontend durchgeführt worden.
Arten des Zugriffs
Für unsere Analyse betrachten wir vier Szenarien, wie ein Frontend auf Daten des SAP BW zugreift:
- Composite Provider über den BW Server
- Query über den BW Server
- Calculation View auf Basis des Composite Providers
- Calculation View auf Basis der Query
Modellierung von Texten mit InfoObjects
In unserem ersten Szenario nutzen wir ein InfoObject um die Produkttexte zu modellieren.
Unsere Analyse zeigt, dass in dieser Konstellation keine Einschränkungen auftreten für die Nutzung von Texten in Frontends:
| Kurztitel | Objekt für Frontend-Zugriff | Texte verfügbar |
|---|---|---|
| A | Composite Provider / ADSO mit assoziertem InfoObject (inklusive Texten ) | ✔ |
| B | Query auf dem Composite Provider A | ✔ |
| C | generierter Calculation View auf dem Composite Provider von A | ✔ |
| D | generierter Calculation View zu der Query von B | ✔ |
| Legende | |
|---|---|
| ✔ | Frontend-Tool erhält die typische Schlüssel/ Text Semantik eines InfoObjects |
| ✘ | Frontend erhält ausschließlich Schlüssel |
Modellierung von Texten mit Open ODS Views
In diesem Szenario wird ein Open ODS View genutzt – alles andere ist identisch zu dem InfoObject Szenario.
Erstellung des Open ODS Views (Texte)
Open ODS-Views lassen sich in den BW Modelling Tools mittels eines Wizards erstellen. Das Öffnen des Wizards erfolgt über Rechts-Klick/ Neu / Open ODS View.
Anschließend müssen der technische Name und die Semantik definiert werden. In unserem Fall handelt es sich um den Semantik Text.
Im folgenden Schritt muss der Quelltyp für die Texte festgelegt werden.
Es muss ein spezifisches Objekt ausgewählt werden.
Nun können gegebenenfalls zusätzliche Stammdatenquellen angebunden werden.
Unter dem Reiter Texte muss ein repräsentatives Schlüsselfeld definiert werden. Dieses dient bei der Assoziation als Schlüsselfeld für die Zuordnung der Texte.
Zwischenergebnis zur 1:1 Nutzung von Open ODS View Texten
Wird ein Open ODS View so wie beschrieben modelliert, gibt es für den HANA seitigen Zugriff erhebliche Einschränkungen. Können SAP Frontends auch sehr gut über den BW Server auf die BW Daten zugreifen, nutzen die meisten nonSAP Frontends die MDX Schnittstelle mit Ihren Nachteilen (Funktional & Performance). Aus Sicht von nonSAP Frontends ist der Zugriff auf HANA Calculation Views, um auf SAP BW Daten zuzugreifen unterm Strich meistens besser. Daher ist es wichtig die Einschränkung in der Modellierung zu beachten. Open ODS Views lassen sich so nicht ohne weiteres gut nutzen.
| Kurztitel | Objekt für Frontend-Zugriff | Texte verfügbar |
|---|---|---|
| E | Composite Provider/ ADSO mit assoziertem open ODS View (inklusive Texten ) | ✔ |
| F | Query auf E | ✔ |
| G | generierter Calculation View von E | ✘ |
| H | generierter Calculation View von F | ✘ |
| Legende | |
|---|---|
| ✔ | Frontend-Tool erhält die typische Schlüssel/ Text Semantik eines InfoObjects |
| ✘ | Frontend erhält ausschließlich Schlüssel |
Workaround: Modellierung von Texten als Attribute von Open ODS Views und Erstellung von Reporting Calculation Views
In diesem Kapitel möchten wir Ihnen einen Workaround für diese Einschränkungen zeigen.
Der Workaround besteht aus zwei Komponenten:
1) Modellierung Open ODS View mit “Textattributen”
Anschließend können diese “Texte-Attribute” bei der Assoziation als Navigationsattribute im Composite Provider hinzugefügt werden.
2) Erstellung von Reporting Calculation Views und labeling
Es wird ein eigener Calculation View angelegt, welcher den jeweiligen generierten Calculation View enthält. Der generierte Calculaton View muss dazu in einem in einer Projection angebunden werden. Ein eigener Calculation View ist notwendig, da bei einer Aktivierung des CompositeProviders, Änderungen im generierten Calculation View verloren gehen würde. Die notwendigen Einstellungen erfolgen in der Semantics-Node des Calculation Views.
- Ausblenden des Text-Attributes
- Hinzufügen des Text-Attributes als “Label Column”
Ergebnisse des Workarounds
Durch den Workaround können auch für den HANA seitigen Zugriff Open ODS Views genutzt werden. Aufgrund der Einschränkungen reiner “Text” Open ODS Views, empfehlen wir die Texte zusätzlich als Attribute zu modellieren.
| Kurztitel | Objekt für Frontend-Zugriff | Texte verfügbar |
|---|---|---|
| I | Composite Provider mit assoziertem Open ODS View (inklusive Texten als Attribute & Texten ) | ✔ |
| J | Query auf I | ✔ |
| K | generierter Calculation View von I | ✔ |
| L | generierter Calculation View von L | ✔ |
| M | Abbildung von Schlüssel-Textbeziehung durch Join im Calculation View (keine Assoziation BW-seitig) | ✔ |
| Legende | |
|---|---|
| ✔ | Frontend-Tool erhält die typische Schlüssel/ Text Semantik eines InfoObjects |
| ✘ | Frontend erhält ausschließlich Schlüssel |
| ✔ | Erfordert eigenen Reporting Calculation View |
Fazit
Die Assoziierung von Stammdaten in Composite Providern ist eine sehr wichtige und gute Veränderung durch SAP BW/4 HANA. Funktioniert bei klassischen SAP BW Szenarien noch alles, kommt es bei mixed Szenarien sehr auf die Details an. Zu diesen Details zählt neben der Modellierung nach unserer Erfahrung auch das verwendete BW Release. SAP optimiert das BW weiterhin und es hat sich gezeigt, dass sich das Systemverhalten dadurch abhängig vom SP Level durchaus ändern kann.
Aufgrund der verwendeten Frontend-Lösung kann es trotz dieser Komplexität notwendig sein, auf Daten des SAP BW über HANA Calucation Views zuzugreifen. Mit unserem Beitrag zeigen wir einen Weg auf, funktionale Einschränkungen von Open ODS Views zu überwinden. Entscheidend für die Wahl der Modellierung wird damit nicht, ob Texte angezeigt werden können oder nicht sondern andere funktionale Aspekte (z.B. Stabilität vs. Agilität und Entwicklungsgeschwindigkeit).
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
