Data Warehousing mit SAP Business Warehouse powered by SAP HANA, BW310H Col15

Dieses E-Book führt praxisnah in die Modellierung mit SAP BW auf SAP HANA ein. Schritt für Schritt lernen Leserinnen und Leser, wie sie Infoobjekte gestalten, Daten aus SAP-Quellsystemen und Flatfiles bereitstellen und Datenflüsse sowohl klassisch als auch grafisch abbilden. Dabei kommen Data Warehousing Workbench und SAP HANA Studio gezielt zum Einsatz, um leistungsfähige Modelle aufzubauen und zu betreiben.

Ein besonderer Fokus liegt auf ODP-basierten Extraktionen, der Arbeit mit Datenspeicherobjekten (Advanced) sowie der Konstruktion von Composite-Providern und Open ODS Views. Ergänzend wird die native HANA-Modellierung mit Calculation Views adressiert, um Reporting-Szenarien flexibel zu unterstützen.

Abgerundet wird der Inhalt durch die Automatisierung mit Prozessketten, sodass regelmäßige Lade- und Transformationsprozesse zuverlässig laufen. Das Material eignet sich für alle, die BW-Datenmodelle modernisieren oder neu aufsetzen und die Stärken von SAP HANA gezielt nutzen möchten.

1. BW310H
Data Warehousing mit SAP
Business Warehouse powered by
SAP HANA
.
.
TEILNEHMERHANDBUCH
PRÄSENZSCHULUNG
.
Version der Schulung: 15
Dauer der Schulung: 5 Tage
Dauer e-Book: 9 Stunden 55 Minuten
Materialnummer: 50138342Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

2. SAP-Copyright und Markenzeichen
©2018 SAP SE oder ein SAP-Konzernunternehmen. Alle Rechte vorbehalten.
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch
immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP SE oder ein SAP-Konzernunternehmen nicht gestattet.
SAP und andere in diesem Dokument erwähnte Produkte und Dienstleistungen von SAP sowie die dazugehörigen Logos sind
Marken oder eingetragene Marken der SAP SE (oder von einem SAP-Konzernunternehmen) in Deutschland und verschiedenen
anderen Ländern weltweit. Weitere Hinweise und Informationen zum Markenrecht finden Sie unter http://global12.sap.com/
corporate-en/legal/copyright/index.epx
Die von SAP SE oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer
Softwarehersteller enthalten.
Produkte können länderspezifische Unterschiede aufweisen.
Die vorliegenden Unterlagen werden von der SAP SE oder einem SAP-Konzernunternehmen bereitgestellt und dienen
ausschließlich zu Informations-zwecken. Die SAP SE oder ihre Konzernunternehmen übernehmen keinerlei Haftung oder
Gewährleistung für Fehler oder Unvollständigkeiten in dieser Publikation. Die SAP SE oder ein SAP-Konzernunternehmen steht
lediglich für Produkte und Dienstleistungen nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen Produkte und
Dienstleistungen ausdrücklich geregelt ist. Keine der hierin enthaltenen Informationen ist als zusätzliche Garantie zu
interpretieren.
Insbesondere sind die SAP SE oder ihre Konzernunternehmen in keiner Weise verpflichtet, in dieser Publikation oder einer
zugehörigen Präsentation dargestellte Geschäftsabläufe zu verfolgen oder hierin wiedergegebene Funktionen zu entwickeln oder
zu veröffentlichen. Diese Publikation oder eine zugehörige Präsentation, die Strategie und etwaige künftige Entwicklungen,
Produkte und/oder Plattformen der SAP SE oder ihrer Konzern- unternehmen können von der SAP SE oder ihren
Konzernunternehmen jederzeit und ohne Angabe von Gründen unangekündigt geändert werden. Die in dieser Publikation
enthaltenen Informationen stellen keine Zusage, kein Versprechen und keine rechtliche Verpflichtung zur Lieferung von Material,
Code oder Funktionen dar. Sämtliche vorausschauenden Aussagen unterliegen unterschiedlichen Risiken und Unsicherheiten, durch die die tatsächlichen Ergebnisse von den Erwartungen abweichen können. Die vorausschauenden Aussagen geben die Sicht
zu dem Zeitpunkt wieder, zu dem sie getätigt wurden. Dem Leser wird empfohlen, diesen Aussagen kein übertriebenes Vertrauen
zu schenken und sich bei Kaufentscheidungen nicht auf sie zu stützen.Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

3. Typografische Konventionen
Dieses Handbuch wurde vom Amerikanischen Englisch ins Deutsche übersetzt.
Die folgenden typografischen Konventionen werden in diesem Handbuch verwendet:
Diese Informationen werden in der Präsentation des Schulungsreferenten
angezeigt.
Demonstration
Vorgehensweise
Warnung oder Achtung
Hinweis
Zugehörige oder zusätzliche Informationen
Moderierte Diskussion
Steuerung der Benutzungsoberfläche Beispieltext
Fenstertitel Beispieltext
©Copyright. Alle Rechte vorbehalten. iiiLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

4. ©Copyright. Alle Rechte vorbehalten. ivLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

5. Inhaltsverzeichnis
vii Überblick über die Schulung
1 Kapitel 1:Einführung in SAP HANA
2 Lektion: Beschreiben der Entwicklung und des Datenlayouts von
SAP HANA
14 Lektion: Beschreiben der Konzepte von Business Intelligence (BI)
und Data Warehousing in beliebigen Datenbanken
22 Lektion: Die Grundlagen von SAP Business Warehouse powered by
SAP HANA
38 Kapitel 2:Stammdaten in SAP Business Warehouse powered by SAP HANA
39 Lektion: Beschreiben von Merkmal-InfoObjects
53 Lektion: Anlegen einer generischen DataSource
64 Lektion: Anlegen von Transformations- und Datentransferprozessen (DTP) für das Laden von Attributstammdaten
70
Lektion: Unterschied zwischen der klassischen und grafischen
Datenfluss-Modellierung
76 Lektion: Löschen und Aktivieren von Stammdaten
82 Kapitel 3:Bewegungsdaten in SAP Business Warehouse (SAP BW)
83 Lektion: Einführung in die SAP Business Warehouse (SAP BW)
InfoProvider
91 Lektion: Anlegen eines Kennzahl-InfoObjects
94 Lektion: Modellieren von DataStore-Objekten (advanced)
105 Lektion: Anlegen eines Datenflusses für Bewegungsdaten
113 Lektion: Anlegen eines Advanced DataStore-Objekts (wie
klassisches DSO) und Laden von Daten aus einer Flatfile-
DataSource
133 Lektion: Modellieren von CompositeProvidern
141 Kapitel 4:Native Modellierung in SAP HANA
142 Lektion: Erkunden von SAP HANA Studio
148 Lektion: Beschreibung der Datenbereitstellung in SAP HANA
156 Lektion: Einführung in die native SAP-HANA-Modellierung
177 Lektion: Kombinieren von SAP Business Warehouse (SAP BW) InfoProvider mit SAP-HANA-Views
186 Kapitel 5:Open ODS Views
187 Lektion: Anlegen von Open ODS Views
201 Lektion: Anlegen von DataSources aus Open ODS View
©Copyright. Alle Rechte vorbehalten. vLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

6. 212 Kapitel 6:SAP Business Warehouse (SAP BW) – erweiterte Themen
214 Lektion: Erläutern der Details von Datentransformation und
Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
243 Lektion: Erläutern von InfoObject-Erweiterungen für SAP Business
Warehouse powered by SAP HANA
249 Lektion: Administrieren von DataStore-Objekten (advanced)
256 Lektion: Einführung zu Prozessketten
281 Lektion: Erläutern von SAP-HANA-Delta-Merges in SAP Business
Warehouse (SAP BW)
287 Lektion: Einführung zu Business-Intelligence-Content (BI Content)
293 Lektion: Einführung zu S4/HANA
©Copyright. Alle Rechte vorbehalten.
viLibrer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

7. Überblick über die Schulung
ZIELGRUPPE
Diese Schulung richtet sich an die folgenden Zielgruppen:
●Anwendungsberater
●Wirtschaftsanalyst
●Geschäftsprozessverantwortlicher/Teamleiter/Power-User
●Programm-/Projektmanager
●Technologieberater
●Benutzer
©Copyright. Alle Rechte vorbehalten. viiLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

8. ©Copyright. Alle Rechte vorbehalten. viiiLibrer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

9. KAPITEL 1Einführung in SAP
HANA
Lektion 1
Beschreiben der Entwicklung und des Datenlayouts von SAP HANA 2
Lektion 2
Beschreiben der Konzepte von Business Intelligence (BI) und Data Warehousing in beliebigen
Datenbanken
14
Lektion 3
Die Grundlagen von SAP Business Warehouse powered by SAP HANA 22
LERNZIELE
●Die Entwicklung und das Datenlayout von SAP HANA beschreiben
●Die Konzepte von Business Intelligence (BI) und Data Warehousing beschreiben
●SAP Business Warehouse powered by SAP HANA einführen
©Copyright. Alle Rechte vorbehalten. 1Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

10. Kapitel 1
Lektion 1
Beschreiben der Entwicklung und des
Datenlayouts von SAP HANA
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in SAP HANA. Die wichtigsten Vorteile und die
Architektur von SAP HANA werden erläutert.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Die Entwicklung und das Datenlayout von SAP HANA beschreiben
Einführung in SAP HANA
Abbildung 1: SAP BW und SAP Business Suite auf SAP HANA
SAP-Software kann auf einer Datenbank (DB) oder auf der SAP-HANA-Datenbank ausgeführt
werden.
Ein traditioneller Aspekt der SAP-HANA-Datenbank ist die Fähigkeit, Daten zu speichern und
als Antwort auf strukturierte Abfragen abzurufen. Dies geschieht durch den Zugriff auf den
Hauptspeicher – und nicht auf die Festplatte –, was den Datenabruf viel schneller macht.
Allerdings verbringen komplexe Anwendungen, die große Datenmengen erfordern,
©Copyright. Alle Rechte vorbehalten. 2Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

11. möglicherweise nur einen kleinen Prozentsatz ihrer Gesamtlaufzeit mit dem Datenabruf und
wesentlich mehr Zeit mit der Verarbeitung der Daten.
Um diese Arbeitsweise zu unterstützen, müssen komplexe Handhabungsroutinen
implementiert werden, die mit diesen Datenvolumina umgehen können. Vor SAP HANA
hatten Datenbanken hatten eine Drei-Schichten Architektur mit Datenhaltungsschicht,
Anwendungsschicht und Präsentationsschicht. Die Datenbanken lasen die Daten, der
Datenbankspeicher verarbeitete die Daten und schrieb die Ergebnisse entweder in die
Datenbank oder in die Präsentationsschicht zurück. Angesichts der immensen Menge an
Daten, die von aktueller Unternehmenssoftware, von Sensoren und sozialen Netzwerken
produziert wird, wird dieses Konzept jedoch immer problematischer. Darüber hinaus muss
das Datenvolumen sehr schnell ausgewertet werden, um auf mobilen Plattformen Ergebnisse
liefern zu können. Dadurch wird das alte Konzept unbrauchbar.
Bei den In-Memory-Techniken werden alle Daten im Arbeitsspeicher abgelegt, und moderne
Computersysteme verfügen über zahlreiche Prozessorkerne, die eine beeindruckende
Rechenleistung bieten. Bei dem neuen Konzept werden nicht die Daten verschoben, sondern
die Recheninstruktionen. Die komplexen Rechenprozesse finden direkt im Speicher statt und
werden nicht mehr auf den Anwendungsserver verlagert.
Unter dem Namen „In-Memory Computing“ bietet SAP eine Technologie an, bei der
datenintensive Prozesse von der Anwendungsschicht auf die Datenhaltungsschicht
übertragen und dort durchgeführt werden. Somit beseitigt SAP jetzt die
Leistungseinschränkungen früherer Datenbank- und Hardware-Kombinationen.
Abbildung 2: Herausforderung vielfältiger Anwendungen
Zu den vielfältigen Anwendungen gehören:
●Eingabequellen für Bewegungsdaten:
-Rechner
-Operative Anwendungen
-Benutzereingaben
●Echtzeitanalysen und strukturierte Datenquellen:
Lektion: Beschreiben der Entwicklung und des Datenlayouts von SAP HANA
©Copyright. Alle Rechte vorbehalten. 3Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

12. -Reporting
-Klassische Analysen
-Planung
-Simulation
●Datenquellen für Ereignisverarbeitungs-Datenströme:
-Rechner
-Sensoren
-Systeme mit hohem Datenvolumen
●Textanalysen oder unstrukturierte Daten, Datenquellen:
-Web
-Soziale Netzwerke
-Protokolle
-Supportsystem
Tabelle 1: Technologietreiber
199020102015Verbesserung
Prozessor in
MIPS/s
0,05 7,15 70,8 1.416
Speicher in
MB/s
0,02 5 120 6.000
Adressierbarer
Speicher
2
16
2
64
2
64
2
48
x
Netzwerkge-
schwindigkeit in
MB/s
2 125 300 150
Datenübertra-
gung Festplatte
MB/s
5 130 300 60
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 4Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

13. Architektur von SAP HANA
Abbildung 3: Architektur von SAP HANA
SAP HANA ist eine Datenbank, die in eine komplette Plattform eingebettet ist. Die Plattform
ist um diese Datenbank herum aufgebaut. Sie besteht aus einem Webanwendungsserver (XS-
Engine) sowie Komponenten zur Verwaltung von Planung, Online Analytical Processing
(OLAP), Vorhersagen (wie Planning Engine, Analytic Engine und Vorhersage-Engine) und
vieles mehr. Der Umfang dieser Plattform wird kontinuierlich erweitert.
Abbildung 4: Technische Neuerungen als Basis für SAP HANA
Lektion: Beschreiben der Entwicklung und des Datenlayouts von SAP HANA
©Copyright. Alle Rechte vorbehalten. 5Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

14. Die 64-Bit-Prozessoren sind so konzipiert, dass ihre arithmetische Logikeinheit während
eines Zyklus gleichzeitig 64 Bits (8 Bytes) verarbeiten kann. Dies umfasst das konsistente
Design der externen und internen Daten, der Adressbusse und der Bandbreiten der Register.
Weiterhin ist der Befehlsvorrat üblicherweise konsequent auf 64-Bit ausgelegt, sofern kein
rückwärtskompatibles Legacy-System vorhanden ist (siehe X86-Architektur).
Entsprechendes gilt für die Standardadressierungsmodi. Die Bitbreite der arithmetischen
Logikeinheit kann sich grundsätzlich von der Adresse der Einheit unterscheiden (wie bei den
meisten 64-Bit-Prozessoren).
Zur Beschleunigung der Datenverarbeitung haben die Hersteller unterschiedliche
Beschleunigungstechniken entwickelt. Die technischen Lösungen reichen von der
Reduzierung von Schreiboperationen auf den äußeren Spuren der Plattensektoren während
der Vorverarbeitung der Daten auf der Festplatte selbst bis hin zu großen Caches, die dafür
ausgelegt sind, die tatsächliche Treffermenge auf den Festplatten zu reduzieren. Diese
Techniken gehen jedoch alle davon aus, dass die Daten auf Festplatten gespeichert sind, und
versuchen, den Zugriff zu beschleunigen. Die heutigen Speicher haben eine viel größere
Kapazität als früher, sind erschwinglicher und dank moderner 64-Bit-Betriebssysteme
erstmalig nutzbar. Der 32-Bit-Adressraum ist auf vier Gigabyte Speicher beschränkt, während
mit der 64-Bit-Adressierung so viel mehr Speicher genutzt werden kann, was die Kapazität
mancher Server übersteigt.
Jedoch sind alle Daten im Hauptspeicher nutzlos, wenn Prozessor nicht leistungsfähig genug
ist, um diese Daten zu verarbeiten. Diesbezüglich gab es in den letzten Jahren große
Veränderungen bei den komplexen Prozessoren hin zu den Mehrkern-Prozessoreinheiten.
Um diese neuartige Rechenleistung zu unterstützen, muss die Software auf bestimmte Weise
geschrieben sein. SAP HANA Software teilt die Gesamtaufgabe in viele kleine Prozessstränge
(Threads) auf, die auf die große Anzahl paralleler Kerne verteilt werden. Eine optimale
Verarbeitung der Daten ist auch erforderlich, um optimierte Datenstrukturen bereitzustellen.
Beim spaltenorientierten Speicher werden die Daten nur teilweise blockiert. Aus diesem
Grund können einzelne Spalten von mehreren Kernen gleichzeitig verarbeitet werden.
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 6Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

15. Abbildung 5: Computerarchitektur verändert sich
Die Computerarchitektur hat sich in den letzten Jahren verändert. Heute sind Mehrkern-
Prozessoren der Standard, und die extrem schnelle Kommunikation zwischen den
Prozessorkernen ermöglicht die Parallelverarbeitung. Der Hauptspeicher ist längst keine
beschränkte Ressource mehr. Moderne Server können mehrere Terabyte Systemspeicher
haben, sodass vollständige Datenbanken im RAM gehalten werden können. Derzeit haben
Serverprozessoren bis zu 64 Kerne, demnächst werden auch Prozessoren mit 128 Kernen auf
dem Markt sein. Durch die zunehmende Anzahl von Kernen sind die CPUs nun in der Lage,
wesentlich mehr Daten pro Zeitintervall zu verarbeiten. Dadurch verlagert sich der
Performance-Engpass vom Platten-I/O zur Datenübertragung zwischen CPU-Cache und
Hauptspeicher.
Die SAP-HANA-Datenbank beruht auf den folgenden vier Konzepten:
●Spaltenspeicher
●Komprimierung
●Partitionierung und Parallelisierung
●Einfügen nur in Delta
Lektion: Beschreiben der Entwicklung und des Datenlayouts von SAP HANA
©Copyright. Alle Rechte vorbehalten. 7Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

16. Spalten- und Zeilenspeicher-Tabellen
Abbildung 6: Zeilenorientiertes Datenlayout
Zeilenorientiertes Datenlayout:
●Daten werden nach Tupeln gespeichert
●Nutzt „Co-Location“ von Attributen für ein einzelnes Tupel
●Geringe Kosten für den Neuaufbau, aber höhere Kosten für sequentielle Scans einzelner
Attribute
Die SAP HANA-Datenbank unterstützt zwei Arten von Tabellen, die Daten entweder
spaltenweise (Spaltentabellen) oder zeilenweise (Zeilentabellen) ablegen. SAP HANA ist für
die spaltenorientierte Speicherung optimiert.
Konzeptuell betrachtet ist eine Datenbanktabelle eine zweidimensionale Datenstruktur mit in
Zeilen und Spalten organisierten Zellen. Der Computerspeicher dagegen ist als lineare
Sequenz organisiert. Beim Speichern einer Tabelle im linearen Speicher stehen Ihnen zwei
Optionen zur Auswahl, wie in der Abbildung „Zeilenorientiertes Datenlayout“ dargestellt.
Ein Zeilenspeicher speichert eine Sequenz von Datensätzen, die die Felder einer Zeile in der
Tabelle enthält. In einem Spaltenspeicher werden die Einträge einer Spalte an
zusammenhängenden Speicherorten gespeichert.
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 8Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

17. Abbildung 7: Spaltenorientiertes Datenlayout
SAP HANA nutzt nicht nur den klassischen zeilenorientierten Datenspeicher, sondern
speichert Tabellen auch im spaltenorientierten Datenspeicher. Es ist wichtig, die
Unterschiede zwischen diesen beiden Methoden sowie den Grund zu verstehen, aus dem
spaltenorientierter Speicher die Leistung bestimmter Datenverarbeitungstypen deutlich
verbessern kann. Das Konzept des Spalten-Datenspeichers wird seit einiger Zeit verwendet.
Beispielsweise kam die erste Version von SAP Sybase IQ, eine spaltenorientierte relationale
Datenbank, im Jahr 1999 auf den Markt. Historisch betrachtet wurde der spaltenorientierte
Speicher hauptsächlich für Analysen und Data Warehousing verwendet, d.h. für Vorgänge, bei
denen Aggregatfunktionen eine wichtige Rolle spielen. Andererseits erfordert die Verwendung
von Spaltenablagen in Online-Transaction-Processing-Anwendungen (OLTP-Anwendungen)
eine ausgewogene Herangehensweise an die Einfügung und Indizierung von Spaltendaten, um
Cache-Fehlzugriff e auf ein Minimum zu reduzieren. Die SAP-HANA-Datenbank ermöglicht
den Entwicklern anzugeben, ob eine Tabelle spalten- oder zeilenweise gespeichert werden
soll. Außerdem kann eine vorhandene spaltenorientierte Tabelle in eine zeilenorientierte
geändert werden und umgekehrt.
Spaltenbezogenes Datenlayout:
●Daten werden nach Attributen gespeichert
●Nutzt Geschwindigkeit sequentieller Scans im Hauptspeicher
●Tupel-Rekonstruktion ist aufwändig
Konzeptuell betrachtet ist eine Datenbanktabelle eine zweidimensionale Datenstruktur mit in
Zeilen und Spalten organisierten Zellen. Der Computerspeicher dagegen ist als lineare
Struktur organisiert. Zum Speichern einer Tabelle im Speicher gibt es zwei Möglichkeiten:
Lektion: Beschreiben der Entwicklung und des Datenlayouts von SAP HANA
©Copyright. Alle Rechte vorbehalten. 9Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

18. ●Ein zeilenorientierter Ansatz, bei dem eine Tabelle als Folge von Datensätzen gespeichert
wird, von denen jede die Felder einer Zeile enthält.
●Ein spaltenorientierter Ansatz, bei dem die Einträge einer Spalte in zusammenhängenden
Speicherorten gespeichert werden.
Abbildung 8: Prozessorlast im Vergleich: Zeilen- und Spaltenspeicherung
Beispiel: Sie möchten Sie die Summe allerUmsätzemit einer zeilenorientierte Tabelle
aggregieren. Die Datenübertragung vom Hauptspeicher in den Prozessor-Cache erfolgt in
Blöcken mit fester Größe (z.B. 64 Byte), die Cache-Lines genannt werden. Bei einer
zeilenorientierten Datenorganisation kann es vorkommen, dass jede Cache-Line nur einen
Umsatz-Wert (gespeichert mit 4 Byte) enthält, während die übrigen Bytes für die anderen
Felder des Datensatzes verwendet werden. Für jeden für die Aggregation benötigten Wert ist
ein neuer Zugriff auf den Hauptspeicher erforderlich.
Bei der zeilenorientierten Datenorganisation kann der Vorgang durch Cache-Fehlzugriff e
verlangsamt werden. In diesem Fall muss der Prozessor warten, bis die erforderlichen Daten verfügbar sind. Bei der spaltenorientierten Speicherung werden jedoch alle Umsatzwerte im
zusammenhängenden Speicher abgelegt. In diesem Fall enthält die Cache-Line sechzehn
Werte, die alle für den Vorgang benötigt werden. Darüber hinaus ermöglicht die Tatsache,
dass Spalten im zusammenhängenden Speicher gespeichert sind, ein Prefetching durch die
Speicher-Controller, um die Anzahl von Cache-Fehlzugriff en weiter zu minimieren.
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 10Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

19. Abbildung 9: Komprimierung von Tabellen mit Spaltenspeicher
Neben den genannten Performance-Gründen bietet das Datenmanagement im
Spaltenspeicher noch viel mehr Möglichkeiten für den Einsatz modernster
Datenkompressionskonzepte. Beispielsweise arbeitet SAP HANA mit bitcodierten Werten
und komprimiert wiederholte Werte, was im Vergleich zu einer klassischen Zeilenspeicher-
Tabelle wesentlich geringeren Speicherbedarf erfordert.
Der Spaltenspeicher ermöglicht die effiziente Komprimierung von Daten. Dies macht es
weniger kostspielig, die Daten für die SAP-HANA-Datenbank im Hauptspeicher zu speichern.
Auch Suchvorgänge und Berechnungen werden beschleunigt.
Daten in Spaltentabellen werden zweifach komprimiert:
●Wörterbuchkomprimierung: Diese Standardmethode für die Komprimierung wird auf alle
Spalten angewendet. Es handelt sich dabei um die Zuordnung von verschiedenen
Spaltenwerten zu Zahlen einer Zahlenfolge, so dass anstelle des tatsächlich gespeicherten
Wertes die typischerweise viel kleinere Zahl dieser Zahlenfolge gespeichert wird.
●Erweiterte Komprimierung: Bei diesem Verfahren kann jede Spalte unter Verwendung
verschiedener Komprimierungsverfahren Präfix-Codierung, Lauflängencodierung (RLE),
Cluster-Codierung, Sparse-Codierung und indirekte Codierung) noch weiter komprimiert
werden. Die SAP-HANA-Datenbank verwendet Komprimierungsalgorithmen, um zu
bestimmen, welche Komprimierung für eine Spalte am besten geeignet ist.
In den folgenden Fällen verwenden Sie zeilenorientiertes Speichern:
●Hauptsächlich eindeutige Werte in der Quelldatenbank
Dies führt zu einer geringen Komprimierungsrate
●Alle Spalten der Tabelle sind relevant
●Keine Aggregation oder Suche erforderlich
Lektion: Beschreiben der Entwicklung und des Datenlayouts von SAP HANA
©Copyright. Alle Rechte vorbehalten. 11Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

20. ●Tabelle enthält eine geringe Anzahl von Datensätzen
Einige Systemtabellen werden im Zeilenspeicher abgelegt
In den folgenden Fällen verwenden Sie spaltenorientiertes Speichern:
●Große Anzahl von Zeilen, wenn spaltenorientierte Vorgänge verarbeitet werden
●Hohe Komprimierungsrate
●Große Anzahl von Spalten
●Sehr gute Eignung für analytische Anwendungen (Lesezugriff )
Abbildung 10: Spalten- und Zeilenspeicher-Tabellen in SAP
Wenn ein SAP-System nach SAP HANA migriert wird, werden die SAP-Tabellen automatisch
in die am besten geeignete Speicherart migriert. Diese Logik ist von SAP definiert. Die
Mehrheit der Tabellen sind im Spaltenspeicher abgelegt. Diese Informationen finden Sie in
SAP HANA Studio (Catalog→Open Definition ) oder in den technischen Einstellungen der
einzelnen Tabellen im SAP Dictionary (TransaktionSE13).
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 12Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

21. Abbildung 11: SAP HANA – Einfügen nur in Delta
Der Spaltenspeicher nutzt effiziente Komprimierungsalgorithmen, die das Speichern aller
relevanten Anwendungsdaten im Speicher unterstützen. Schreiboperationen mit diesen
komprimierten Daten wären teuer, da sie eine Reorganisation der Speicherstruktur erfordern
würden. Das Aktualisieren und Einfügen von Daten in eine sortierte Spaltenspeicher-Tabelle
ist sehr kostspielig, da die Sortierreihenfolge neu erzeugt werden muss und jedes Mal die
gesamte Tabelle reorganisiert wird. Aus diesem Grund hat SAP diese Tabellen auf einen
Hauptspeicher (leseoptimierte, sortierte Spalten) und mehrere Deltaspeicher
(schreiboptimierte, nicht sortierte Spalten oder Zeilen) aufgeteilt.
Alle Änderungen werden in einem separaten Bereich, dem Deltaspeicher, abgelegt. Der
Deltaspeicher existiert nur im Hauptspeicher. Nur Delta-Log-Einträge werden in den
Hauptspeicher geschrieben. Diese Aktivität wird als Delta Merge bezeichnet. In der Abbildung
„SAP HANA – Einfügen nur in Delta“ sehen Sie die verschiedenen Stufen der
Datenspeicherung. Hier wird zwischen Hauptspeicher und Deltaspeicher unterschieden.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Die Entwicklung und das Datenlayout von SAP HANA beschreiben
Lektion: Beschreiben der Entwicklung und des Datenlayouts von SAP HANA
©Copyright. Alle Rechte vorbehalten. 13Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

22. Kapitel 1
Lektion 2
Beschreiben der Konzepte von Business
Intelligence (BI) und Data Warehousing in
beliebigen Datenbanken
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in SAP Business Warehouse (BW). Die Drei-Schichten-
Architektur von BW wird erklärt. In dieser Lektion werden auch die InfoProvider beschrieben,
die zum Speichern und Zugreifen auf Daten in SAP BW verwendet werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Die Konzepte von Business Intelligence (BI) und Data Warehousing beschreiben
SAP Business Warehouse (BW)
Die Einführung klassischer Datenverarbeitungssysteme hatte die Beschleunigung,
Kostenreduzierung und Automatisierung von Prozessen in einzelnen
Unternehmensbereichen zum Ziel. Dies wird durch ERP-Systeme (Enterprise Resource
Planning) und andere Software-Tools erreicht. Durch den Einsatz dieser ERP-, CRM-,
Bankenabwicklungs- und Kreditkartensysteme sowie durch die
Unternehmensleitungsrichtlinien hat sich das auszuwertende Datenvolumen exponentiell
erhöht. Dies wird von einigen als negativ betrachtet; andere – zu denen auch SAP gehört –
meinen, dass dieser enorme Umfang an elektronischen Informationen Vorteile bringt.
Die parallel dazu auftretende, sich ständig erweiternde Globalisierung und die zunehmende
Dezentralisierung von Unternehmen brachte das Erfordernis mit sich, Markttrends zu
analysieren und Informationen über Mitbewerber zu sammeln. Dies versetzt das
Unternehmen in die Lage, sich rasch auf veränderte Marktverhältnisse einzustellen. In diesem
Internetzeitalter ist eine effiziente Informationsverarbeitung wichtig, um einen
Wettbewerbsvorteil beizubehalten.
Aufgrund der ständigen Innovation in der Datenverarbeitung werden Informationen immer
detaillierter gespeichert. Die Folge ist die Notwendigkeit, diese Daten zu reduzieren und zu
strukturieren, um aussagefähige Analysen zu erhalten. Um die zum Erstellen von Business
Intelligence erforderliche Analyse aus den Rohdaten durchzuführen, werden verschiedene
Werkzeuge benötigt.
Entscheidungsträger in modernen globalen Unternehmen stellen fest, dass ihr Überleben von
der nutzbringenden Verwendung dieser Informationen abhängt. Da diese Informationen
häufig über mehrere Systeme und u.U. auch mehrere Länder verteilt sind, ist eine wirksame
Nutzung der Informationen schwierig. Dieser Herausforderung stellen sich moderne
Business-Intelligence-Systeme. Es werden umfassende Lösungen benötigt, die den gesamten
Verlauf von der Beschaffung der Quelldaten bis zur Analyse abdecken. Die Unternehmen
müssen sich unternehmensweit mit Metadaten (geschäftliche und technische Attribute und Beschreibungen von Objekten) befassen. Darüber hinaus müssen sie homogene globale
©Copyright. Alle Rechte vorbehalten. 14Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

23. Stammdaten wie auch große Mengen von Bewegungsdaten in unterschiedlichen
Verdichtungen konsolidieren und anlegen.
In heterogenen Systemlandschaften stellen die Extraktion und Vorbereitung konsolidierter
Bewegungs- und Stammdaten aus unterschiedlichen Quellsystemen eine besondere
Herausforderung dar. Neben der integrierten Datenübernahme werden die Möglichkeiten
einer detaillierten Datenanalyse und Multimediadarstellung der Ergebnisse benötigt, um die
steigenden Ansprüche an die Qualität der Unternehmensinformationen zu erfüllen. Es besteht
ein sehr großer Bedarf an Business-Intelligence-Lösungen, die alle der oben genannten
Merkmale aufweisen.
Abbildung 12: OLTP- und OLAP-Umgebungen
Die Business-Intelligence-Software beruht auf Daten, die aus den Quellsystemen stammen.
Diese Informationen können jedoch nicht ohne Weiteres für gezielte Analysen verwendet
werden. Daher werden die Quelldaten zunächst bereinigt und technisch und semantisch
aufbereitet (homogenisiert). Die Daten werden daraufhin in der Data-Warehouse-
Komponente von Business Intelligence gespeichert. Anhand der Analyse dieser Informationen
mit soliden und flexiblen Reporting-Werkzeugen werden die Unternehmensinformationen
verständlicher und ein Wissensaufbau ermöglicht. Dieses Wissen dient dem Unternehmen als
Unterstützung bei der Definition oder Neudefinition seiner Geschäftsstrategie sowie bei den
sich daraus ergebenden Geschäftsprozessen. Die Online-Transaction-Processing- (OLTP-)Umgebungen (ERP) und die Online-Analytical-Processing-(OLAP-)Umgebungen
(Business Intelligence) sind unabhängige Einheiten. Abbildung „OLTP- und OLAP-
Umgebungen“ zeigt die Interaktion der beiden Umgebungen.
Lektion: Beschreiben der Konzepte von Business Intelligence (BI) und Data Warehousing in beliebigen Datenbanken
©Copyright. Alle Rechte vorbehalten. 15Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

24. Drei-Schichten-Architektur von SAP BW
Tabelle 2: Ziele von Data-Warehouse-Lösungen
SchichtDetails
Reporting-Schicht Flexible Datenauswertung
●Qualität der Informationen (flexible Analy-
sewerkzeuge)
●
Standardisiertes und einheitliches Repor-
ting-Werkzeug
●
(Ad-hoc-)Reporting der Performance
●
Analytische Services (Data Mining und
Planung)
Datenschicht Redundante Datenhaltung
●
Entlastung der Quellsysteme
●Datenhistorie
●Performance
Reporting-spezifische Datenaufbereitung
●Homogenisierung (Datentyp, Währung)
●Bereinigung
●
Komprimierung
Extraktionsschicht Datenbereitstellung aus unterschiedlichen
Quellsystemen
●Integration
Mithilfe des BW-Servers können Sie die Beziehungen von Daten über sämtliche Bereiche
Ihres Unternehmens hinweg untersuchen. OLAP-Technologien ermöglichen
mehrdimensionale Analysen nach unterschiedlichen betriebswirtschaftlichen
Gesichtspunkten. Um diesen Zielen entsprechen zu können, ist die Architektur von SAP BW
im Allgemeinen – und die der Warehouse-Komponente im Besonderen – gut strukturiert und
stabil. In den folgenden Abschnitten lernen Sie die Grundarchitektur von SAP BW kennen und erfahren mehr zu den verschiedenen Schichten dieser Architektur.
Die Architektur von SAP Business Warehouse ist in die folgenden drei Schichten aufgeteilt:
●
Beschaffung der Daten
●Ablegen der Daten im Warehouse
●Reporting der Daten anhand von Reporting-Werkzeugen
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 16Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

25. Beim Arbeiten mit SAP BW müssen Sie zu den drei Schichten Folgendes ermitteln:
●Wo sind die benötigten Daten derzeit gespeichert?
●Wie können Sie auf diese Daten zugreifen?
●Wie können Sie sie in SAP BW hochladen?
●Wie werden die Daten in SAP BW gespeichert?
●Welche InfoProvider werden benötigt?
●Welche Speicherstufen?
●Wie werden Ihre Power-User und Endbenutzer auf die Daten zugreifen? Welche Reporting-
Werkzeuge werden eingesetzt?
Die Abbildung „Drei-Schichten-Architektur von SAP BW“ gibt einen Überblick über die drei
Schichten der SAP-BW-Architektur.
Abbildung 13: Drei-Schichten-Architektur von SAP BW
Ein Quellsystem stellt SAP BW Daten zur Verfügung. Sie müssen dabei zwischen
unterschiedlichen Quellsystemtypen unterscheiden:
●SAP-Quellsysteme, zum Beispiel: SAP ERP, SAP BW, SAP SCM.
●Fremdquellen, zum Beispiel: Datenbanken von verschiedenen Lieferanten, Webdiensten,
die Daten übertragen, Dateien, die relevante Daten enthalten.
Ein Vorteil von SAP BW ist die offene Architektur mit externen OLTP-Providern und anderen
Altsystemen. Es besteht die Möglichkeit, SAP BW mit allen möglichen Quellsystemen zu
verbinden und SAP BW als konsolidierte und unternehmensweite Reporting-Datenbank zu
verwenden, insbesondere in einer heterogenen Systemlandschaft. SAP liefert Werkzeuge, mit
deren Hilfe die entsprechenden Schnittstellen rasch und effizient implementiert werden
können.
Lektion: Beschreiben der Konzepte von Business Intelligence (BI) und Data Warehousing in beliebigen Datenbanken
©Copyright. Alle Rechte vorbehalten. 17Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

26. Die Abbildung „Quellsysteme und Aufbereitungstechnologie für SAP BW“ liefert eine
Übersicht der verschiedenen Quellsystemtypen, die mit SAP BW verbunden werden können,
und beschreibt die technische Schnittstelle, die für die Verbindung und Datenaufbereitung
verwendet wird.
Abbildung 14: Quellsysteme und Aufbereitungstechnologie für SAP BW
Quellsysteme: Zum Laden der Daten in SAP BW werden die folgenden Technologien
eingesetzt:
●Operational Data Provisioning (ODP)
Zum Bereitstellen von Daten mit Hilfe der Application Programming Interface (API) für die
ODP-Datenreplikation aus verschiedenen Quellen, z.B. SAP-ERP-Extraktoren, SAP BW,
SAP HANA Views, SAP Business ByDesign und SAP Landscape Transformation
Replication Server (SLT).
●BW Service API (S-API)
Das S-API ist ein Technologiepaket in SAP-Quellsystemen von BW, das einen hohen
Integrationsgrad für die Datenübernahme aus den Quellsystemen in SAP BW ermöglicht.
Es ermöglicht auch die Kommunikation zwischen den SAP-Quellsystemen und SAP BW.
Das S-API ist als Teil der Softwarekomponente SAP Basis Plug-In im SAP-Quellsystem
installiert.
●DB Connect
Ermöglicht den Direktzugriff auf relationale Datenbanken. Über DB-Multi-Connect wird
eine Verbindung zum Datenbankmanagementsystem (DBMS) in der externen Datenbank
hergestellt. Über den Import von Metadaten und Originaldaten können die notwendigen
Strukturen in SAP BW generiert und die Daten auf einfache und effiziente Weise geladen
werden.
●UD Connect
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 18Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

27. Mit UD Connect können Sie auf nahezu alle relationalen Datenquellen zugreifen. Diese
Technologie läuft auf der J2EE-Engine und unterstützt die J2EE-Connector-Architektur.
●Dateischnittstelle
SAP BW unterstützt den automatischen Import von Dateien im CSV-, ASCII- und XLS-
Format für Flatfiles.
●Web-Services
Mit den Web-Services können Sie Daten unter externer Steuerung an SAP BW senden.
●SAP Data Services
Zur Verwendung der engen Integration von SAP Data Services bei der Aufbereitung von
Daten über BAPIs (Business Application Programming Interfaces).
●Staging BAPIs
Staging BAPIs sind offene Schnittstellen, mit deren Hilfe SAP Data Services und
zertifizierte Third-Party-Tools Daten aus älteren Systemen extrahieren können. Der
Datentransfer kann durch einen Request von SAP BW, durch SAP Data Services oder durch ein Third-Party-Tool angestoßen werden.
Klassische InfoProvider in SAP BW
Abbildung 15: Klassische InfoProvider in SAP BW
Aus einem Quellsystem extrahierte Daten können anfangs in den PSA-Tabellen (Persistent
Staging Area) abgelegt werden. Anschließend müssen Sie in den meisten Fällen diese Daten
physisch und dauerhaft in SAP BW speichern.
Für eine dauerhafte Speicherung und den Zugriff auf BW-Daten mit Reporting-Werkzeugen ist
die Erstellung von InfoProvidern erforderlich. SAP BW bietet eine Reihe von InfoProvidern für unterschiedliche Zwecke an. Einige speichern Daten physisch, andere bieten eine zusätzliche Sicht der Daten.
Lektion: Beschreiben der Konzepte von Business Intelligence (BI) und Data Warehousing in beliebigen Datenbanken
©Copyright. Alle Rechte vorbehalten. 19Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

28. In der Tabelle „InfoProvider in SAP BW“ sind einige der in SAP BW verfügbaren InfoProvider
mit einigen zentralen Merkmalen der wichtigsten InfoProvider für Ihre Informationen
aufgeführt.
●Merkmals-InfoObject
Speichert Stammdaten (z. B. Kunde, Material und Kostenstelle), die zum Erstellen der
Tabellen für andere InfoProvider verwendet werden.
●DataStore-Objekt
Speichert Bewegungsdaten auf einer detaillierten Ebene (zum Beispiel
Kundenauftragsdaten auf der Positionsebene).
●InfoCube
Speichert Bewegungsdaten (zum Beispiel Verkaufsbeträge und -mengen pro Monat) auf
einer aggregierten Ebene
●MultiProvider
Stellt eine Sicht auf die Daten von mehreren InfoProvidern zur Verfügung (zum Beispiel
Verkaufsbeträge in Deutschland und den USA).
Mit Transformationen können Sie die Daten, die Sie aus dem Quellsystem extrahiert haben,
transformieren, anreichern und ändern. Dies ist eventuell bei speziellen Reporting-
Anforderungen oder der Harmonisierung von Daten aus unterschiedlichen Quellsystemen
erforderlich. Die Abbildung „Klassische InfoProvider in SAP BW“ bietet einen Überblick über
die Verwendungsmöglichkeiten der verschiedenen InfoProvider in SAP BW. Jeder
InfoProvider erfüllt eine eigene Rolle und kann mit Daten aus den Quellsystemen geladen
werden. Über die Reporting-Werkzeuge von SAP BW können Sie auf die Daten zugreifen und
diese für das Reporting nutzen.
Abbildung 16: Beispiel des Datenflusses in SAP BW
Eine DataSource ist das Objekt in SAP BW, das zur Datenextraktion aus dem Quellsystem
angelegt wird. Die DataSource enthält Informationen zum Speicherort der erforderlichen
Daten und zu den Datenstrukturen. Die PSA ist eine Tabelle, in der die erforderlichen Daten
zunächst in SAP BW gespeichert werden. Sie speichert die Daten im Quellformat (nicht
transformiert).
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 20Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

29. InfoProvider sind die Objekte, die zum dauerhaften Speichern der Daten oder zum Zugreifen
auf Daten aus anderen Tabellen in SAP BW verwendet werden. Diese Objekte bilden zudem
auch die Grundlage für Ihre Reporting-Requests.
DataStore-Objekt speichert Bewegungsdaten detailliert (zum Beispiel Kundenauftragsdaten
auf Positionsebene).
InfoCube speichert Bewegungsdaten auf einer aggregierten Ebene (zum Beispiel
Verkaufsbeträge und -mengen pro Monat).
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Die Konzepte von Business Intelligence (BI) und Data Warehousing beschreiben
Lektion: Beschreiben der Konzepte von Business Intelligence (BI) und Data Warehousing in beliebigen Datenbanken
©Copyright. Alle Rechte vorbehalten. 21Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

30. Kapitel 1
Lektion 3
Die Grundlagen von SAP Business Warehouse
powered by SAP HANA
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion zeigt die Entwicklung von SAP BW. In dieser Lektion wird auch die Data
Warehousing Workbench vorgestellt und deren wichtigsten Funktionen erläutert.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●SAP Business Warehouse powered by SAP HANA einführen
SAP-HANA-Datamodelle
Abbildung 17: SAP Business Warehouse Februar 2016
SAP BW 7.5 Edition für SAP HANA hat folgende Zwecke:
●Vereinfachte Ausführung von SAP BW
●Vereinfachte Governance
●Kürzere Entwicklungszeiten bis zur Marktreife mit neuen agilen und flexiblen
Datenmodellierungsmustern
●Möglichkeit, SAP BW 7.5 (SP1) nur mit neuen und optimierten SAP-HANA-Objekten
auszuführen
●Vereinfachte Modellierung ausschließlich mit SAP-HANA-Objekten und erneuerten
intuitiven Benutzungsoberflächen in Eclipse und SAP UI5
●Unterbrechungsfreier Übergang und Wechsel zur Edition für SAP HANA
©Copyright. Alle Rechte vorbehalten. 22Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

31. ●Eingeschränkte Nutzung von klassischen/HANA-fremden Funktionen
Abbildung 18: SAP-BW-Roadmap mit SAP HANA
Unterstützung von Werkzeugen für automatisierten Transfer zu CompositeProvider und
DataStore-Objekten (advanced):
●Transfer vorhandener Datenflüsse mit traditionellen Modellen in neue Objekte, die für BW
auf HANA optimiert sind
●Objektkopie (1:1, keine Daten) von InfoCubes und DataStore-Objekten in DataStore-
Objekte (advanced)
●MultiProvider-Transfer oder -Kopie in CompositeProvider
●Erzeugung von Kopien von Datenflussobjekten, DTPs und Transformationen
●Sammeln aller notwendigen Objekte, um den Datenfluss unterhalb von einem Startobjekt
wiederherzustellen
Abbildung 19: SAP-HANA-Datamodelle
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 23Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

32. Modeler verwenden das ADSO (DataStore-Objekt (advanced)) für die Modellierung der
Persistenz von neuen End-to-End-Szenarien in BW 7.5 auf HANA. Das ADSO kombiniert
Funktionen aus InfoCube und DSO (klassisch) und bietet zusätzliche Erweiterungen wie die
Modellierung auf InfoObjects sowie auf Feldern für einfache Datentypen an. Im Kontext von
SAP HANA und BW wird das ADSO zum zentralen Objekt für die Modellierung von
Persistenzschichten und ersetzt die traditionellen BW-InfoProvider mit Persistenz
(InfoCubes, DSO (klassisch), Persistent Staging Area). Die bestehenden traditionellen
InfoProvider werden bei der schrittweisen Entwicklung hin zur EDW-Architektur auf Basis von
ADSOs weiterhin verfügbar sein.
Abbildung 20: Klassische InfoProvider in SAP BW
Diese Folie zeigt im Vergleich wieder die klassischen InfoProvider, aus denen die Drei-
Schichten-Architektur von BW aufgebaut ist.
●DataStore-Objekt: Speichert Bewegungsdaten detailliert (zum Beispiel
Kundenauftragsdaten auf Positionsebene).
●InfoCube: Speichert Bewegungsdaten auf der aggregierten Ebene (zum Beispiel
Verkaufsbeträge und -mengen pro Monat).
●MultiProvider: Bietet eine Sicht der Daten verschiedener InfoProvider (zum Beispiel
Verkaufsbeträge in Deutschland und den USA).
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 24Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

33. Abbildung 21: SAP BW auf HANA-InfoProvidern
Die BW-Architektur basiert auf den neuen SAP-HANA-InfoProvidern.
Abbildung 22: Architektur von SAP HANA
Über die Erweiterten Anwendungsservices von SAP HANA (SAP HANA XS) haben
Anwendungen und Anwendungsentwickler über ein Konsumierungsmodell, das über HTTP
verfügbar gemacht wird, Zugriff auf die SAP-HANA-Datenbank. Neben der Bereitstellung
anwendungsspezifischer Konsumierungsmodelle bietet SAP HANA XS auch Host-
Systemservices, die Teil der SAP HANA-Datenbank sind, darunter beispielsweise
Suchservices und einen integrierten Webserver, der Zugriff auf statische Inhalte bietet, die im
SAP HANA-Repository abgelegt sind.
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 25Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

34. Abbildung 23: Softwareoptimierung für SAP HANA
Wie unterscheidet sich BW auf HANA von BW auf anderen Datenbanken?
Datenintensive Funktionen werden vom BW-ABAP-Anwendungsserver auf die SAP-HANA-
Datenbank übertragen.
●Hervorragende Query-Performance zur Verbesserung der Entscheidungsfindung
●Leistungssteigerung für Datenladeprozesse für niedrigere Datenlatenz
●Beschleunigte In-Memory-Planungsfähigkeiten für schnellere Planungsszenarien
●Flexibles Kombinieren von EDW und SAP-HANA-eigenen Daten für Echtzeitinformationen
und -Entscheidungsfindung
●Getrennte Datenpersistenzschichten und geringerer Verwaltungsaufwand
●Vereinfachte Datenmodellierung und -remodellierung und dadurch flexibler für die
Reaktion auf Kundenanforderungen
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 26Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

35. Abbildung 24: Softwareoptimierung für SAP HANA 2
Datenintensive Funktionen werden vom BW-ABAP-Anwendungsserver auf die SAP-HANA-
Datenbank übertragen.
●Erweiterte, integrierte Analysefunktionen
●Vollständige Datenbankfunktionen
●Vollständige BWA-Funktionen
Zusätzliche Funktionen:
●HANA-optimierter InfoCube
●HANA-optimierte Aktivierung von DataStore-Objekten
●HANA-optimierte neue Datenmodelle wie DataStore-Objekte (advanced),
CompositeProviders und Open ODS View
●Veröffentlichung von SAP-HANA-Modellen in BW und umgekehrt
●Optimierte Transformationen
●BW Workspaces
●OLAP- und Planungsfunktionen werden abwärts übertragen
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 27Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

36. Abbildung 25: Entwicklung der In-Memory-Technologie für SAP BW
Zu Beginn, im Jahr 2012, als BW für SAP HANA weiterentwickelt wurde, stand kurzzeitig eine
HANA-optimierte Version von DataStore-Objekten (klassisch) zur Verfügung. Aufgrund
technischer Herausforderungen ließ SAP dieses Konzept jedoch fallen. Damit ist die für SAP
HANA optimierte Version von DSO (klassisch) obsolet, und es ist nicht mehr möglich, DSOs
(klassisch) in eine HANA-optimierte Version zu migrieren/konvertieren. Sie können weiterhin
SAP-HANA-optimierte DataStore-Objekte (klassisch) aus älteren Releases verwenden. Wir
empfehlen jedoch, diese zu rekonvertieren. Verwenden Sie dazu den Report
RSDRI_RECONVERT_DATASTORE.
Obwohl es keine HANA-optimierte Version klassischer DSOs gibt (wie dies bei den InfoCubes
der Fall ist, siehe vorherige Lektion), profitiert dieses Datenmodell von einer SAP-HANA-
Datenbank, da alle damit verbundenen Datenmanagement-Prozesse in hohem Maße für
HANA-optimiert sind. Die Aktivierung wird nun für alle gängigen DSOs (klassisch) extrem
schnell durchgeführt, ohne zusätzliche Einstellungen vornehmen zu müssen. Es sind keine
Konvertierungen oder Migrationen erforderlich. Zusätzlich zur Aktivierung ist die SID-
Erzeugung (auch als BEx-Flag bekannt) ebenfalls HANA-optimiert. Daher hat es kaum
Auswirkungen auf die Leistung, wenn Sie die SID-Erzeugung während der Aktivierung der
Daten einrichten.
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 28Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

37. Abbildung 26: Kombinieren von nativen HANA-Funktionen mit SAP BW
Zusammenführen der Daten aus BW und SAP HANA (gemischte Szenarien)
Sie können Szenarien anlegen, bei denen im BW-System modellierte Daten mit in SAP HANA
mit SAP-HANA-Werkzeugen modellierten Daten zusammengeführt werden.
Wenn ein BW-System auf der SAP-HANA-Datenbank läuft, sind die BW-Daten in einem
speziellen Schema, dem BW-managed Schema, abgelegt. In anderen SAP-HANA-Schemas
können Daten in SAP-HANA-Tabellen oder Modellierungssichten gespeichert werden. Sie
können nun Daten von jedem SAP-HANA-Datenbankschema in BW zur Verfügung stellen. Sie
können auch BW-Daten (Daten aus dem BW-verwalteten Schema in der SAP-HANA-
Datenbank) in einem anderen SAP-HANA-Schema zur Verfügung stellen. Sie können
Datenreplikationsmethoden und virtuelle Zugriff smethoden verwenden. Die folgende Liste
führt die verschiedenen Möglichkeiten auf und verweist auf weiterführende Informationen.
Beim Aktivieren der BW-Objekte, die Sie anlegen möchten, können Sie SAP-HANA-Views mit
identischen Strukturen generieren.
Sie können so Szenarien anlegen, bei denen im BW-System modellierte Daten mit Daten, die
in SAP HANA mithilfe von SAP-HANA-Werkzeugen modelliert wurden, zusammengeführt
werden (gemischte Szenarien).
Folgende Objekte werden hier unterstützt: SAP HANA-optimierte InfoCubes, DataStore-
Objekte, InfoObjects, Queries als InfoProvider, CompositeProvider, lokale CompositeProvider
im BW-Workspace und Queries.
Beim Generieren von SAP-HANA-Views werden BW-Daten in SAP HANA publiziert. Diese
SAP-HANA-Views zeigen direkt auf die Daten und Tabellen, die von BW verwaltet werden.
BW-Daten können daher direkt in SAP HANA konsumiert werden. Darüber hinaus wird so eine
übersichtliche Schnittstelle zwischen dem von BW verwalteten Schema und einem Bereich
außerhalb von BW, der von anderen Werkzeugen oder von einer anderen Benutzergruppe
verwaltet wird, bereitgestellt. Diese Schnittstelle zeigt deutlich an, wo die Services im BW-
System enden und wo die manuellen Erweiterungen oder die Erweiterungen durch
Drittanbieterwerkzeuge beginnen. Es ist nicht möglich, generierte SAP-HANA-Views manuell
zu ändern. Die von BW generierten SAP-HANA-Views können vom System jederzeit
überschrieben werden. Dies bedeutet, dass alle manuellen Änderungen verloren gehen
würden.
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 29Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

38. Sie können jedoch weitere SAP-HANA-Views auf Basis dieser generierten Views anlegen.
Diese werden dann in einem anderen Content-Paket gespeichert.
Bei Generierung von SAP-HANA-Views aus dem BW-System heraus können Sie SAP-HANA-
Views generieren, ohne dazu den SAP HANA Modeler verwenden zu müssen. Sie können über
SQL-Frontends auf BW-Daten zugreifen. Alle Anwendungen, die SAP-HANA-Views lesen
können, sind in der Lage, die Daten zu verarbeiten (z.B. SAP BusinessObjects Analysis,
Edition für Microsoft Office, SAP BusinessObjects Web Intelligence, SAP BusinessObjects
Explorer, SAP Lumira und BI-Clients von Drittanbietern).
Beim Ausführen einer Query auf der SAP-HANA-View werden die Daten direkt aus SAP HANA
angefordert, ohne dass das BW-System angesprochen wird.
Die Generierung von SAP-HANA-Views aus dem BW-System heraus wurde als Schnittstelle
für eigenständige Data Marts implementiert. Das bedeutet, dass diese SAP-HANA-Views nur
für besondere Szenarien geeignet sind.
Diese SAP-HANA-Views sind Teil des BW-InfoProvider-Lebenszyklus. Sie werden mit den
entsprechenden BW-Objekten transportiert. Das Zielsystem muss über eine SAP-HANA-
Datenbank verfügen. Andernfalls geht die Eigenschaft, dass das Objekt über eine SAP-HANA-
View verfügt, verloren.
Beim Aktivieren eines BW-Objekts mit der SAP-HANA-View werden alle abhängigen SAP-
HANA-Views ebenfalls aktiviert. Wenn im Zusammenhang mit einer von Ihnen angelegten
SAP-HANA-View ein Fehler auftritt, führt dies lediglich zu einer Warnung, und das BW-Objekt
wird aktiviert.
Data Warehousing Workbench
Abbildung 27: Data Warehousing Workbench
Um Wartungs- und Administrationsarbeiten für SAP BW auszuführen, müssen Sie sich mit
den Funktionen und Eigenschaften der Data Warehousing Workbench und dem Zugriff darauf
vertraut machen. Außerdem benötigen Sie allgemeine Kenntnisse der Navigation, wie z. B.
der Suche nach Objekten, und wie Sie diese dann Ihren Favoriten hinzufügen können.
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 30Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

39. Kenntnisse zum Umgang mit der Suchfunktion und anderen Funktionen machen die Arbeit in
SAP BW deutlich leichter.
Die Data Warehousing Workbench (DWB) ist das zentrale Werkzeug für den technischen
Business-Warehouse-Experten. Diese zentrale Transaktion bietet Zugriff auf zahlreiche
Funktionen und Werkzeuge, die Sie in Ihrer täglichen Arbeit mit SAP BW verwenden. Der
Transaktionscode für die Data Warehousing Workbench lautet RSA1.
Abbildung 28: Funktionsbereich „Modellierung“ der Data Warehousing Workbench
Wenn Sie die Data Warehousing Workbench öffnen, erscheint auf der linken Bildseite ein
Navigationsbereich. Dort werden die einzelnen Funktionsbereiche der Data Warehousing
Workbench angezeigt.
Die DWB enthält folgende Funktionsbereiche:
●Modellierung: In diesem Bereich werden SAP-BW-Objekte und -Datenflüsse angelegt.
●Administration: Dieser Bereich dient der Lastplanung, Überwachung und Datenverwaltung.
●Transportanschluss: Dies ist das spezielle Transport-Toolset.
●Dokumente: Dies ist die zentrale Benutzeroberfläche für die Pflege von Dokumenten.
●BI-Content: Bereitgestellter BI Content kann zur Verwendung aktiviert werden
●Übersetzung: Beschreibungen von SAP-BW-Objekten (z.B. Querys, InfoCubes) können für
die Mehrsprachenunterstützung übersetzt werden.
●Metadata Repository: In diesem Bereich können Power-User und Fachleute Details zu
ausgelieferten und kundendefinierten Objekten suchen.
Der Funktionsbereich „Modellierung“ dient dem Anlegen und Verwalten der für den
Datenaufbereitungsprozess relevanten Objekte in SAP BW. Die Darstellung dieser Objekte
erfolgt jeweils in einer Baumstruktur, in der diese Objekte nach hierarchischen Kriterien
angeordnet sind. Über ein Kontextmenü können die jeweils relevanten Pflegedialoge und
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 31Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

40. Funktionen der Objekte im entsprechenden Objekt-Baum ausgewählt werden. Sie werden im
weiteren Verlauf dieses Kurses öfters auf diesen Bereich zugreifen, während Sie Aufgaben wie
das Anlegen von InfoObjects, InfoCubes und DataStore-Objekten ausführen.
Im Funktionsbereich „Dokumente“ können Sie Dokumente zu Objekten von SAP BW
hinzufügen. Hier können Sie Suchen durchführen und Verknüpfungen zwischen Dokumenten
in verschiedenen Formaten, Versionen und Sprachen anlegen.
BI Content bietet auf Metadaten basierend vorkonfigurierte Informationsmodelle. Sie können
diese Objekte in Ihrem System direkt verwenden oder sie überarbeiten. Mit BI Content sind
Unternehmen in der Lage, Datenmodelle in SAP BW auf schnellere Prototypart aufzubauen.
Im Funktionsbereich „Übersetzung“ können Kurz- und Langtexte von SAP-BW-Objekten
übersetzt werden. Beispielsweise ist es für einen französischen Mitarbeiter viel einfacher, eine
Query zu finden, wenn deren Bezeichnung nicht „Sales Analysis“, sondern „Analyse de
Ventes“ lautet.
Das Metadata Repository dient als zentraler Zugriff spunkt auf Informationen zu den
Metadatenobjekten von SAP Business Warehouse. Diese Metadaten beinhalten wichtige
Objekteigenschaften und deren Beziehungen zu anderen Objekten. Im integrierten Metadata-
Repository-Browser steht eine Suchfunktion zur Verfügung, die einen schnellen Zugriff auf die
Metadatenobjekte ermöglicht. Des Weiteren können z. B. Metadaten zwischen verschiedenen Systemen ausgetauscht, HTML-Seiten, auf denen Metadaten aufgeführt sind, exportiert
sowie grafische Darstellungen zu den Objekten angezeigt werden.
Abbildung 29: Datenfluss in SAP BW 7.x
Der ETL-Prozess (Extraktion, Transformation und Laden), auch als „Datenfluss“ bezeichnet,
besteht aus bestimmten Schritten, in denen die Rohdaten (Quelldaten) extrahiert,
transformiert und in das SAP-BW-Ziel geladen werden.
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 32Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

41. Abbildung 30: Funktionsbereich „Administration“ der Data Warehousing Workbench
Der Funktionsbereich „Administration“ enthält Informationen zur Administration und
optimalen Verwaltung Ihres Data Warehouse. Darin werden die Aufgaben sowie die
zugehörigen Werkzeuge und Funktionen aufgelistet und Verweise auf die für die Aufgaben
benötigte zusätzliche Dokumentation aufgeführt. Der Eintrag „Monitore“ in der
Administrationssicht macht es möglich, den Datenladeprozess sowie weitere Prozesse der
Datenverarbeitung in SAP BW zu überwachen und zu steuern. Hier können Sie alles
überwachen, einschließlich des Extraktionsmonitors für eingehende Daten und des Open Hub
Monitor für Daten, die aus SAP BW für andere Systeme beschafft werden.
Eine andere wichtige Funktion innerhalb der Administration ist die Erstellung, Ausführung und
Überwachung von Prozessketten. Dieses graphische Planungs- und Monitoringtool
ermöglicht komplexe Abhängigkeiten zwischen Stammdaten- und
Bewegungsdatenübernahmen sowie andere komplexe Aufgaben, die im Data Warehouse
ausgeführt werden sollen.
Eine wichtige technische Anforderung für alle SAP-Produkte ist die Verwaltung der Metadaten
und Konfigurationseinstellungen zwischen Ihren Entwicklungs-, Test- und
Produktivumgebungen. Die Transportwerkzeuge, über die alle SAP-Produkte verfügen,
wurden um besondere Funktionen zur Unterstützung von SAP BW erweitert. Mit dem
Transportanschluss können Sie Objekte erfassen, die vor kurzem angelegt oder geändert
wurden. Mithilfe des Change and Transport Organizers (CTO) transportieren Sie diese
Objekte in andere SAP-BW-Systeme (z. B. aus dem Entwicklungssystem in Ihr
Qualitätssicherungssystem und weiter in das Produktivsystem).
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 33Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

42. Abbildung 31: Anwendungsserver und SAP-HANA-DB
Abbildung 32: SAP HANA Studio – Perspektive
Kapitel 1: Einführung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 34Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

43. Abbildung 33: SAP HANA Studio – Open SAP GUI
Abbildung 34: Die Data Warehousing Workbench verwenden – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●SAP Business Warehouse powered by SAP HANA einführen
Lektion: Die Grundlagen von SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 35Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

44. Kapitel 1
Überprüfung des Lernerfolgs
1.Was ist SAP-HANA-In-Memory-Computing?
2.Der Spaltenspeicher ist eines der vier Hauptkonzepte der SAP-HANA-Datenbank.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
3.Was wird mit der Implementierung von SAP Business Warehouse beabsichtigt?
4.Die Integrationsschicht ist eine der drei Schichten des SAP BW.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
5.Wozu verwendet der Modeler das ADSO?
6.Der InfoCube speichert Bewegungsdaten auf aggregierter Ebene.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
©Copyright. Alle Rechte vorbehalten. 36Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

45. Kapitel 1
Überprüfung des Lernerfolgs - Antworten
1.Was ist SAP-HANA-In-Memory-Computing?
SAP-HANA-In-Memory-Computing ist eine Technologie, bei der die Datenbank im RAM
eines Computers anstatt auf der Festplatte gespeichert ist. In-Memory Computing ist eine
Kombination aus Hardware und Software, die für die schnelle Verarbeitung von großen
Datenmengen in Echtzeit ausgelegt ist.
2.Der Spaltenspeicher ist eines der vier Hauptkonzepte der SAP-HANA-Datenbank.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
3.Was wird mit der Implementierung von SAP Business Warehouse beabsichtigt?
SAP Business Warehouse hilft Unternehmen, große Datenmengen zu analysieren, zu
interpretieren und Berichte daraus zu erstellen.
4.Die Integrationsschicht ist eine der drei Schichten des SAP BW.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
5.Wozu verwendet der Modeler das ADSO?
Modeler verwenden das DataStore-Objekt (advanced) für die Modellierung der Persistenz
von neuen Szenarien in SAP BW HANA.
6.Der InfoCube speichert Bewegungsdaten auf aggregierter Ebene.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
©Copyright. Alle Rechte vorbehalten. 37Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

46. KAPITEL 2Stammdaten in SAP
Business Warehouse
powered by SAP HANA
Lektion 1
Beschreiben von Merkmal-InfoObjects 39
Lektion 2
Anlegen einer generischen DataSource 53
Lektion 3
Anlegen von Transformations- und Datentransferprozessen (DTP) für das Laden von
Attributstammdaten
64
Lektion 4
Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung 70
Lektion 5
Löschen und Aktivieren von Stammdaten 76
LERNZIELE
●Merkmale von InfoObjects erläutern
●Eine generische DataSource anlegen
●Transformations- und Datentransferprozesse (DTP) für das Laden von
Attributstammdaten anlegen
●Den Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung
verstehen
●Das Löschen und Aktivieren von Stammdaten verstehen
©Copyright. Alle Rechte vorbehalten. 38Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

47. Kapitel 2
Lektion 1
Beschreiben von Merkmal-InfoObjects
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in InfoObjects. In dieser Lektion wird erläutert, wie
InfoObjects in BW verwendet werden, um Strukturen und Tabellen anzulegen, in denen Daten
gespeichert werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Merkmale von InfoObjects erläutern
InfoObjects
Wichtigste Eigenschaften von InfoObjects in SAP BW:
●Sie können durch ihren technischen Namen eindeutig identifiziert werden.
●Sie enthalten technische und betriebswirtschaftliche Informationen.
●Sie ermöglichen die Modellierung von Informationen.
●Sie werden verwendet, um Berichte zu definieren und Stamm- und Bewegungsdaten zu
bewerten.
Als Komponenten des Metadata Repository (dem Speicherbereich für alle Objekte von SAP
BW) enthalten InfoObjects technische Informationen und Informationen für Stamm- und
Bewegungsdaten in SAP BW.
InfoObjects werden im gesamten System zur Erstellung von Strukturen und Tabellen
verwendet, in denen Daten gespeichert werden. Sie ermöglichen eine Modellierung von
Informationen in strukturierter Form. Auch werden sie verwendet, um Berichte zu definieren
und Stamm- und Bewegungsdaten zu bewerten.
SAP liefert mit dem BW Content InfoObjects aus. Die technischen Namen der mit BW Content
ausgelieferten InfoObjects beginnen mit 0 (Null). Sie können auch eigene InfoObjects
definieren. Anders als bei den SAP-Quellsystemen ist die einzige Anforderung, dass die
technischen Namen nicht mit einer Zahl oder einem Sonderzeichen beginnen und drei bis
neun Zeichen lang sind. Z-Namen, die für einige SAP-Produkte erforderlich sind, sind nicht
notwendig.
©Copyright. Alle Rechte vorbehalten. 39Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

48. Abbildung 35: InfoObject-Typen und Definitionen
InfoObjects unterteilen sich in erster Linie in die Haupttypen Kennzahlen oder Merkmale. Der
Typ Merkmal untergliedert sich weiter in Zeitmerkmale, technische Merkmale und Einheiten.
Kennzahl-InfoObjects stellen die Werte bereit, die berechnet oder ausgewertet werden sollen.
Die folgenden Beispiele sind Kennzahl-InfoObjects:
●Menge (0QUANTITY)
●Betrag (0AMOUNT)
Merkmal-InfoObjects sind betriebswirtschaftliche Bezugsobjekte, anhand derer die
Kennzahlen analysiert werden. Die folgenden Beispiele sind Merkmal-InfoObjects:
●Kostenstelle (0COSTCENTER)
●Material (0MATERIAL)
Zeitmerkmal-InfoObjects bilden den zeitlichen Bezugsrahmen für viele Datenauswertungen
und -bewertungen. Sie werden mit dem BW Content ausgeliefert. Die folgenden Beispiele sind
Zeitmerkmal-InfoObjects:
●Kalendertag (0CALDAY): Zeitmerkmal mit der kleinsten Granularität
●Zeitmerkmal mit der größten Granularität
●Kalenderjahr (0CALYEAR) oder Geschäftsjahr (0FISCYEAR)
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 40Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

49. Abbildung 36: InfoObjects in SAP BW
In der klassischen BW-Modellierung benötigen Sie für jedes Feld der Tabelle ein InfoObject.
Mit den neuen InfoProvider-Typen in BW powered by SAP HANA können Sie auch einen
feldbasierten Ansatz nutzen.
Abbildung 37: Kataloge in SAP Netweaver BW: InfoObject-bezogen
Kataloge in SAP BW dienen organisatorischen und Suchzwecken. Sie können beispielsweise
einen kundeneigenen Katalog für jeden größeren Bereich anlegen. Dieser würde dann die
kundeneigenen InfoObjects für den gesamten Bereich beinhalten, beispielsweise CO-
Merkmale. Wenn das Objekt keinem Ordner zugeordnet ist, wird es automatisch im Ordner
„Nicht zugeordnet“ abgelegt. Obwohl diese nicht erforderlich ist, können auf diese Weise die
bereichsbezogenen Objekte viel einfacher gesucht und als Vorlage zum Anlegen der
InfoProvider verwendet werden. SAP stellt viele Ordner bereit, doch Sie werden
Lektion: Beschreiben von Merkmal-InfoObjects
©Copyright. Alle Rechte vorbehalten. 41Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

50. möglicherweise selbst Ordner anlegen, insbesondere, wenn Sie benutzerdefinierte Objekte
anlegen. Eine Möglichkeit besteht darin, einen kundeneigenen Katalog für jeden größeren
Bereich anzulegen. Dieser würde dann die kundeneigenen InfoObjects für den gesamten
Bereich beinhalten, z. B. Umsatzkennzahlen.
Die Katalogpflege kann auf zwei Arten erfolgen. Indem Sie im Änderungsmodus auf den
Katalog zugreifen, können Sie InfoObjects schnell suchen und finden und sie Ihrem Katalog
hinzufügen oder entnehmen. Auch ist direktes Anlegen von InfoObjects in Ihrem Katalog über das Kontextmenü möglich.
Diese Kataloge finden Sie in der InfoArea NODESNOTCONNECTED (nicht zugeordnete
Knoten). Die InfoObjects können jedoch jederzeit einem InfoObjectCatalog zugeordnet
werden. Wenn Sie einen InfoObjectCatalog löschen, werden die ihm zugeordneten
InfoObjects nicht gelöscht. Stattdessen werden die nicht zugeordneten Merkmale oder nicht
zugeordneten Kennzahlen dem jeweiligen nicht zugeordneten InfoObjectCatalog zugeordnet.
„Bisher können Sie Kataloge nur in der Data Warehousing Workbench erstellen, pflegen und
verwenden. In SAP HANA Studio sind Kataloge nicht sichtbar.”
Abbildung 38: Szenario für das InfoObject U##_COSTC
Ihr Unternehmen möchte Kostenstellendaten aus einem SAP-System und aus einem
Fremdsystem über eine Dateischnittstelle konsolidieren. Im Altsystem ist die Nummer der
Kostenstelle 13 Zeichen lang, im SAP-System sind jedoch nur 10 Zeichen möglich. Um dies zu
berücksichtigen, müssen Sie ein neues InfoObject anlegen, das die 13-stellige
Kostenstellennummer darstellt. Anstatt die drei zusätzlichen Zeichen leerzulassen, wenn die
Daten aus dem SAP-System beschafft werden, wird die drei Zeichen lange System-ID an alle
Kostenstellen aus dieser Quelle angehängt.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 42Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

51. Abbildung 39: Beispiele für stammdatentragende Merkmale
Bevor die Änderungsregisterkarten untersucht werden, muss das Konzept der
stammdatentragenden Merkmale beschrieben werden. Ein Merkmal ist stammdatentragend,
wenn es Tabellen mit Attributen, Texten oder Hierarchien enthält, die weitere Informationen
zu den Merkmalswerten liefern. Es ist von Ihrem Geschäftsprozess und dem Merkmal
abhängig, ob diese Stammdatentabellen verwendet werden. Sie bieten in vielen Situationen
eine wichtige Informationsquelle für Ihre Reporting-Bedürfnisse.
Die stammdatentragenden Merkmale aktivieren Sie, indem Sie das entsprechende
Kennzeichen für Text, Stammdaten oder Hierarchien auf den Registerkarten setzen, die in
folgenden Abbildungen zu sehen sind. Wenn eine dieser Optionen ausgewählt ist, wird das
Merkmal als stammdatentragend betrachtet.
Abbildung 40: Unternehmensszenario Klammerung
Sie können die Registerkarten verwenden, die Sie im Kontextmenü unter „Ändern“ erreichen,
um Merkmal-InfoObjects zu definieren und Einstellungen zu ändern. An diesen Registerkarten
wird auch deutlich, dass für eine sinnvolle Definition der Merkmale präzises Know-how über
die betriebswirtschaftliche Bedeutung erforderlich ist.
Der Änderungsmodus umfasst folgende Registerkarten:
Lektion: Beschreiben von Merkmal-InfoObjects
©Copyright. Alle Rechte vorbehalten. 43Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

52. ●Allgemein
●Stammdaten/Texte
●Attribute
●Hierarchie
●BI-Clients
Im Bereich für die Klammerung legen Sie fest, ob das Merkmal an andere InfoObjects
geklammert werden soll. Es ist häufig erforderlich, Merkmalswerte zu klammern, um eine
eindeutige Zuordnung von Merkmalswerten zu ermöglichen. Dies ist in den meisten Fällen
zwar nicht erforderlich, doch wenn es vergessen wird und erforderlich wäre, führt dies zu
irrelevanten Daten. Bei der Klammerung wird ein Merkmal-InfoObject mit einem anderen
Merkmal-InfoObject kombiniert, um die Möglichkeit zur eindeutigen Definition der Werte des
InfoObjects sicherzustellen.
Nehmen wir beispielsweise einmal an, die Kostenstelle 100 steht im Kostenrechnungskreis
1000 für den Vertrieb und im Kostenrechnungskreis 2000 für das Marketing. In diesem Fall
muss eine Kostenstelle definiert werden, die an das Kostenrechnungskreis-Merkmal
geklammert ist. Ein weiteres Beispiel ist der Lagerort. In SAP MM kann man kein Material nur
anhand seines Lagerorts finden; man braucht auch das Werk. Die Klammerung kann
außerdem verwendet werden, um Abhängigkeiten zwischen Objekten zu definieren. Dies
vereinfacht die Navigation im Reporting.
Merkmale von InfoObjects – Einstellungen und Tabellen
Abbildung 41: Registerkarte „Allgemein“
Auf der Registerkarte „Allgemein“ werden die grundlegenden Eigenschaften eines Merkmals
festgelegt, wie z.B. Beschreibung, Datentyp (CHAR, NUM), Länge (max. 250 Zeichen) und
Konvertierungsroutine.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 44Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

53. Abbildung 42: Registerkarte „Stammdaten/Texte“
Die Registerkarte „Business Explorer“ wird verwendet, um die Anzeigestandardwerte im
Business Explorer festzulegen. Die Einstellungen auf dieser Registerkarte bestimmen, ob das
Merkmal als Textbeschreibung oder als Schlüssel im Business Explorer angezeigt wird.
Abbildung 43: Registerkarte „Attribute“
Attribute sind selbst InfoObjects (Merkmale/Kennzahlen), die zur näheren Beschreibung von
Merkmalen verwendet werden. Das Merkmal „Kostenstelle“ kann beispielsweise mit den
Informationen über die „Kostenstelle“ und „Verantwortliche Person“ genauer beschrieben
werden. In diesem Kontext fungieren diese beiden InfoObjects als Attribute. Wenn das
Kennzeichen für „Mit Stammdaten“ auf der Registerkarte „Stammdaten/Texte“ gesetzt ist,
die auf der Abbildung oben zu sehen ist, so hat man innerhalb der Registerkarte „Attribute“
die Möglichkeit, Attribute und Eigenschaften zu diesen Attributen anzugeben. Die Attribute
sind selbst auch InfoObjects, da wir die Feldinformationen auf dem InfoObject dafür
verwenden, in der primären Merkmale-Stammdatentabelle eine Spalte aufzubauen.
Wenn Sie Attribute als Anzeigeattribute definieren, können Sie diese Attribute nur in
Kombination mit dem Merkmal als zusätzliche Informationen im Reporting verwenden.
Anders ausgedrückt kann im Reporting innerhalb des Datenbestands eines InfoProviders
nicht mithilfe dieser Attribute navigiert werden.
Lektion: Beschreiben von Merkmal-InfoObjects
©Copyright. Alle Rechte vorbehalten. 45Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

54. Wenn Sie Attribute als Navigationsattribute definieren, können Sie anhand dieser Attribute im
Reporting navigieren. Wenn eine Query ausgeführt wird, unterscheidet das System nicht
zwischen Navigationsattributen und Merkmalen für einen InfoProvider. Mit anderen Worten
sind also alle Navigationsfunktionen in der Query auch für Navigationsattribute möglich. Um
Attribute im Reporting als Navigationsattribute verfügbar zu machen, müssen Sie sie auf dem
InfoProvider aktivieren. Andernfalls funktionieren die Attribute wie Anzeigeattribute.
Sie können Anzeige- und Navigationsattribute zeitabhängig machen, wenn für jeden
Attributwert ein Gültigkeitszeitraum erforderlich ist. Diese Funktion ist leistungsstark, da sie
Ihnen ermöglicht, Berichte auf Grundlage von Stammdaten, wie sie zu einem beliebigen
Zeitpunkt vorlagen, auszuführen. So könnten Sie mit dieser Funktion beispielsweise einen
Bericht anlegen, der den Absatz von iPods in Ostdeutschland 2016 zeigt, obwohl keiner Ihrer
Kunden mehr in Ostdeutschland lebt.
Abbildung 44: Merkmalswerte über 60 Zeichen und überlange Texte
Auf der RegisterkarteStammdaten/Textelegen Sie fest, ob das Merkmal Attribute oder Texte
tragen kann. Falls das Merkmal über Texte verfügen soll, muss mindestens eine Textauswahl
(kurzer, mittellanger, langer oder überlanger Text, d.h. 20, 40, 60 oder 1.333 Zeichen)
getroffen werden. Die Attribute werden dem Merkmal auf der Registerkarte „Attribute“
zugeordnet. Durch Setzen eines dieser Kennzeichen wird das Merkmal als
stammdatentragend definiert.
In den BW-Releases vor 7.4 ist die maximale Länge eines Merkmalswerts auf 60 Zeichen begrenzt. Ab Release 7.4 SPS2 sind bis zu 250 Zeichen möglich. Um dies zu erreichen, wurde
die Domäne RSCHAVL von CHAR 60 auf SSTRING 1.333 geändert. Daher sind
Datenelemente, die die Domäne RSCHAVL verwenden, tiefe Typen in einem ABAP-Kontext.
Für Merkmalswerte sind Texte mit einer Länge von bis zu 1.333 Zeichen möglich. Dazu wurde
die Struktur RSTXTSMXL angelegt, die tiefer Typ im ABAP-Kontext ist. In den internen
Methodenschnittstellen und Funktionsbaustein-Schnittstellen, wo die Texte der
Merkmalswerte gehandhabt werden, wurde der Typ RSTXTSML durch RSTXTSMXL ersetzt.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 46Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

55. Die RSRTXTSML-Struktur bleibt jedoch unverändert und ist für die Beschreibung von
Metadaten erforderlich.
Bei langen Texten mit mehr als 60 Zeichen wählen Sie „Langtext“.
Abbildung 45: Registerkarte „Hierarchie“
Hierarchien können in der Analyse zur Beschreibung alternativer Sichten auf die Daten
verwendet werden. Sie erfüllen eine Gruppierungsfunktion, ganz so wie in anderen SAP-
Produkten wie etwa SAP ECC. Eine Hierarchie besteht aus mehreren Knoten und Blättern, die
einander über- bzw. untergeordnet sind. Die Knoten stellen jede gewünschte Gruppierung
dar, z.B. Region West. Die Blätter der Hierarchie werden von den Merkmalswerten dargestellt,
z.B. einem Vertriebsmitarbeiter.
Auf der RegisterkarteHierarchiewird festgelegt, ob das Merkmal Hierarchien tragen kann und
welche Eigenschaften diese Hierarchien haben können. Wenn das KennzeichenMit
Hierarchiengesetzt ist, können für dieses Merkmal manuell Hierarchien angelegt werden
(TransaktionscodeRSH1). Sie können wahlweise auch aus dem SAP-System oder anderen
Quellsystemen geladen werden.
Abbildung 46: Versionsabhängige Hierarchie
In SAP BW sind externe Hierarchien Präsentationshierarchien, die als Struktur für
Merkmalswerte in Hierarchietabellen gespeichert werden.
Merkmalshierarchien können in verschiedenen Hierarchieversionen verwendet werden. Die
Beziehungen können außerdem zeitabhängig sein. Wenn im Quellsystem verschiedene
Lektion: Beschreiben von Merkmal-InfoObjects
©Copyright. Alle Rechte vorbehalten. 47Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

56. Hierarchieversionen oder Zeitabhängigkeiten vorliegen, können diese in SAP BW modelliert
werden.
Merkmalshierarchien können in verschiedenen Hierarchieversionen verwendet werden.
Unterschiedliche Hierarchieversionen im Quellsystem können in SAP BW modelliert werden;
Sie können jedoch auch verschiedene Versionen für ein und dieselbe Hierarchie aus dem
Quellsystem anlegen. Diese Versionen können dann in einer Query miteinander verglichen
werden. Beispielsweise werden bei der Restrukturierung der Verkaufsbezirke eines
Unternehmens für das Merkmal Hauptbezirk mehrere Hierarchieversionen angelegt. Diese
können in einer Query miteinander verglichen werden.
Abbildung 47: Zeitabhängige Gesamthierarchie
Auf der RegisterkarteHierarchiekönnen Sie festlegen, dass die gesamte Hierarchie
zeitabhängig sein kann. Anders ausgedrückt gibt es verschiedene Versionen dieser
Hierarchie, die nur für ein bestimmtes Zeitintervall gültig sind. Das System wählt anhand der
Einstellungen in der Query automatisch die gültige Version aus. Beispielsweise wird bei der
Restrukturierung der Verkaufsbezirke eines Unternehmens für das Merkmal „Hauptbezirk“
die Hierarchie zeitabhängig gemacht. Dadurch ist ein Vergleich dieser Restrukturierung für
verschiedene Zeiten in einer Query (mithilfe des Felds „Stichtag“) möglich.
Abbildung 48: Zeitabhängige Hierarchiestruktur
Auf dem InfoObject könnten Sie bestimmen, dass die Hierarchiestruktur (ein
Hierarchieknoten) zeitabhängig sein soll. Dabei wird die Hierarchie zum aktuellen oder dem in
der Query festgelegten Stichtag aufgebaut.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 48Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

57. Beispielsweise zeigt sich im Rahmen der Umstrukturierung der Verkaufsbezirke eines
Unternehmens, dass ein Mitarbeiter zu verschiedenen Zeitpunkten unterschiedlichen
Kostenstellen zugeordnet ist. Es ist möglich, unter einem Hierarchieknoten
Merkmalsausprägungen in Form von Intervallen zu positionieren. Anstatt z. B. in einer
Kostenartenhierarchie die Kostenartenwerte zu Materialkosten alle einzeln unter den Knoten
„Materialkosten“ zu positionieren, können die Kostenartenwerte als Kostenart 100 und 1000
angeben werden. Es können auch Intervalle für Merkmalswerte angelegt werden, zu denen
noch keine Stammdaten existieren. Dadurch muss die Hierarchie für neue Stammdaten nicht
erweitert werden (da neue Merkmalswerte automatisch zugeordnet werden).
Eine Einschränkung der Intervalloption besteht in vielen Bereichen darin, dass der technische
Schlüssel des Merkmalswertes aussagekräftig sein muss. Die meisten Unternehmen haben
keine durchdachte Vergabe von Nummern für Ihre Teilnummern oder Kunden, doch die
Intervalloption kann in vielen Fällen für finanzwirtschaftliche Objekte wie
Sachkontennummern verwendet werden.
Bei der Verwendung von Hierarchien für Merkmale gelten folgende Voraussetzungen:
●Es können keine Hierarchien zu Merkmalen angelegt werden, falls dieses Merkmal auf ein
anderes Merkmal referenziert (d. h. Referenzmerkmale).
●Ein Merkmal kann mehrere Hierarchien tragen.
●Falls ein Merkmal Hierarchien enthält, darf die maximale Länge (des Merkmalswerts) mit
Klammerung nur 32 (statt 60) Zeichen betragen.
Per Vorzeichenumkehr für Hierarchieknoten kann das Anzeigeverhalten von Knoten in der
Query beeinflusst werden. Man kann bei jedem Hierarchieknoten für die Darstellung in der
Query angeben, ob das Vorzeichen für die auf diesen Knoten gebuchten Bewegungsdaten umgekehrt werden soll.
Abbildung 49: Hierarchien im Reporting
Lektion: Beschreiben von Merkmal-InfoObjects
©Copyright. Alle Rechte vorbehalten. 49Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

58. Hierarchien bieten flexible, leicht änderbare Roll-Up-Gruppierungen für das Reporting in
Reporting-Werkzeugen von BEx und SAP BusinessObjects. Wenn Tausende von
Merkmalswerten für das Reporting vorliegen, können die Hierarchien zur besseren
Strukturierung der Daten verwendet werden. Die Merkmalswerte eines Merkmals werden in
einer Baumstruktur angezeigt, und Sie können einen Drilldown durchführen, indem Sie
einfach auf das kleine Dreieck klicken.
Abbildung 50: Stammdatentragende Merkmalstabelle
Wenn Ihr InfoObject aktiviert wird, werden automatisch die entsprechenden zugrunde
liegenden Tabellen erstellt. Im vorliegenden Beispiel werden die angelegten Tabellen (nur
funktionale Sicht) in der Abbildung „Merkmalstabellen – Funktionale Sicht“ dargestellt.
Die Stammdaten werden in verschiedenen Tabellen eines Merkmals gespeichert. Aus
Performance-Gründen werden in InfoCubes und Aggregaten statt der Merkmalswerte die
Stammdaten-IDs (SIDs) gesichert. In der SID-Tabelle wird für jeden Merkmalswert eine
Stammdaten-ID gespeichert. Auch die Analytic Engine arbeitet intern nur mit SIDs und nicht
mit Merkmalswerten.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 50Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

59. Abbildung 51: Merkmal-InfoObjects: Übertragungsroutine
Abbildung 52: Anlegen eines InfoObject-Merkmals – Übung
Lektion: Beschreiben von Merkmal-InfoObjects
©Copyright. Alle Rechte vorbehalten. 51Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

60. Abbildung 53: Anlegen einer globalen Übertragungsroutine – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Merkmale von InfoObjects erläutern
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 52Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

61. Kapitel 2
Lektion 2
Anlegen einer generischen DataSource
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in DataSources zeigt Ihnen, wie Sie eine generische
DataSource zum Laden von Stammdaten aus einer SAP-Quelle anlegen können.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Eine generische DataSource anlegen
Generische DataSources
Ein Quellsystem ist jedes System, das SAP BW für die Extraktion und den Transfer von Daten
zur Verfügung steht.
Beispiele: SAP CRM, Custom, Oracle DB, PeopleSoft.
Abbildung 54: Quellsystemtypen und Schnittstellen
Zum Laden der Daten in SAP BW werden die folgenden Technologien eingesetzt:
●Operational Data Provisioning (ODP)
©Copyright. Alle Rechte vorbehalten. 53Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

62. Zum Bereitstellen von Daten mit Hilfe der Application Programming Interface (API) für die
ODP-Datenreplikation aus verschiedenen Quellen, z.B. SAP-ERP-Extraktoren, SAP BW,
SAP HANA Views, SAP Business ByDesign, SAP Landscape Transformation Replication
Server (SLT).
●BW Service API (S-API)
Die Service-API ist ein Technologiepaket in SAP-Quellsystemen von BW, die einen hohen
Integrationsgrad für die Datenübernahme aus den Quellsystemen in SAP BW ermöglicht.
Damit wird auch die Kommunikation zwischen den SAP-Quellsystemen und SAP BW
möglich. Die S-API ist als Teil der Softwarekomponente SAP Basis Plug-In im SAP-
Quellsystem installiert.
●DB Connect
Ermöglicht den Direktzugriff auf relationale Datenbanken. Hier wird über DB-Multi-
Connect eine Verbindung zum Datenbankmanagementsystem (DBMS) in der externen
Datenbank hergestellt. Über den Import von Metadaten und Originaldaten können die
notwendigen Strukturen in SAP BW generiert und die Daten auf einfache und effiziente
Weise geladen werden.
●UD Connect
Mit UD Connect können Sie auf nahezu alle relationalen Datenquellen zugreifen. Diese
Technologie läuft auf der J2EE-Engine und unterstützt die J2EE-Connector-Architektur.
●Dateischnittstelle
SAP BW unterstützt den automatischen Import von Dateien im CSV-, ASCII- und XLS-
Format für Flatfiles.
●Web-Services
Mit den Web-Services können Sie Daten unter externer Steuerung an SAP BW senden.
●SAP Data Services
Zur Verwendung der engen Integration von SAP Data Services bei der Aufbereitung von
Daten über BAPIs (Business Application Programming Interfaces).
●Staging-BAPIs
Staging BAPIs sind offene Schnittstellen, mit deren Hilfe SAP Data Services und
zertifizierte Third-Party-Tools Daten aus älteren Systemen extrahieren können. Der
Datentransfer kann durch einen Request von SAP BW, durch SAP Data Services oder
durch ein Third-Party-Tool angestoßen werden.
Persistent Staging Area (PSA) ist ein branchenspezifischer Begriff , der jedoch nicht
einheitlich definiert wird. In seiner Antwort auf einen Beitrag in der Rubrik „Ask the Experts“
(Fragen an die Experten) unter DMreview.com definiert Evan Levy eine PSA wie folgt:
●Die Persistent Staging Area (PSA)
Die PSA dient der Datenablage und -verarbeitung zur Unterstützung der
Datentransformation
●in der Regel temporär
●nicht für den Benutzer- oder Werkzeugzugriff eingerichtet
●speziell für die Bereitstellung von Arbeits- (bzw. temporärem) Speicherplatz für die ETL-
Verarbeitung konzipiert
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 54Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

63. Technisch gesehen ist die PSA eine transparente Datenbanktabelle, in der angeforderte
Daten abgelegt werden. Pro DataSource und Quellsystem wird eine PSA angelegt. Sie dient
als Eingangsspeicher in SAP BW, in dem die aus dem Quellsystem angeforderten Daten
unverändert gesichert werden.
Sie dient als Eingangsspeicher in SAP BW, in dem die aus dem Quellsystem angeforderten
Daten unverändert gesichert werden. Jedes Laden von Daten erzeugt in der PSA-Tabelle eine
Anforderung. Mithilfe von Prozessketten müssen Sie sicherstellen, dass die Anforderungen
nach dem erfolgreichen Laden der Daten wieder gelöscht werden.
Ohne Operational Data Provisioning befindet sich die Delta-Queue im Quellsystem. Das Delta
kann über die InfoPackage in die BW Persistent Staging Area (PSA) geladen werden.
Anschließend lädt der Datentransferprozess das Delta in den InfoProvider.
Mit Operational Data Provisioning befindet sich die Delta-Queue stark komprimiert im
Quellsystem. Das Delta kann mit dem Datentransferprozess direkt in den BW InfoProvider
geladen werden.
DataSource – Definition
●DataSources sind Objekte von SAP BW, die für die Extraktion und Aufbereitung von Daten
aus Quellsystemen verwendet werden. DataSources teilen die vom Quellsystem
bereitgestellten Daten auf eigenständige Geschäftsbereiche auf. Das hier gezeigte
Kostenstellenbeispiel umfasst DataSources mit Kostenstellentexten, Stammdaten und
Kostenstellen-Bewegungsdaten aus zwei unterschiedlichen Quellsystemen.
●Eine DataSource enthält logisch aufeinander bezogene Felder, die in einer flachen Struktur
angeordnet sind und an SAP BW zu transferierende Daten enthalten.
Der für die Einrichtung der generischen (kundendefinierten) DataSource im Quellsystem (in
unserem Fall RK3CL800) verwendete Konfigurationstransaktionscode ist SBIW. In einem
SAP-Quellsystem istSBIWdie zentrale Transaktion für das Customizing des Datentransfers
nach SAP BW, für die Erweiterung von DataSources aus dem Business Content und für die
Entwicklung generischer (kundendefinierter) DataSources, wenn keine Business-Content-
DataSources verfügbar sind (Beispiel: Kundentabellen). In unserem Fall wird
TransaktionscodeSBIWzum Anlegen einer generischen DataSource verwendet, um
Kostenstellendaten aus der Tabelle zu lesen, in der sie abgelegt sind.
Persistent Staging Area (PSA) ist ein branchenspezifischer Begriff , der jedoch nicht
einheitlich definiert wird. n seiner Antwort auf einen Beitrag in der Rubrik „Ask the Experts“
(Fragen an die Experten) unter DMreview.com definiert Evan Levy eine PSA wie folgt: Die PSA
dient der Datenablage und -verarbeitung zur Unterstützung der Datentransformation. Die
folgende Liste liefert eine Übersicht der PSA.
Persistent Staging Area (PSA)
●Die Persistent Staging Area (PSA) ist seit BW 7.x obligatorisch:
-Datenablage und -verarbeitung unterstützt Datentransformation
-Sie ist in der Regel temporär
-Sie ist nicht für den Benutzer- oder Werkzeugzugriff eingerichtet
-Sie ist speziell für die Bereitstellung von Arbeits- (bzw. temporärem) Speicherplatz für
die ETL-Verarbeitung konzipiert
Lektion: Anlegen einer generischen DataSource
©Copyright. Alle Rechte vorbehalten. 55Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

64. ●Seit der Einführung des Operational Data Provisioning (ODP) Framework ist die PSA
wieder optional (wie vor BW 7.x).
Technisch gesehen ist die PSA eine transparente Datenbanktabelle, in der angeforderte
Daten abgelegt werden. Pro DataSource und Quellsystem wird eine PSA angelegt. Sie dient
als Eingangsspeicher in SAP BW, in dem die aus dem Quellsystem angeforderten Daten
unverändert gesichert werden. Jedes Laden von Daten erzeugt in der PSA-Tabelle eine
Anforderung. Mithilfe von Prozessketten müssen Sie sicherstellen, dass die Anforderungen
nach dem erfolgreichen Laden der Daten wieder gelöscht werden.
Ohne Operational Data Provisioning befindet sich die Delta-Queue im Quellsystem. Das Delta
kann über die InfoPackage in die BW Persistent Staging Area (PSA) geladen werden.
Anschließend lädt der Datentransferprozess das Delta in den InfoProvider.
Mit Operational Data Provisioning befindet sich die Delta-Queue stark komprimiert im
Quellsystem. Das Delta kann mit dem Datentransferprozess direkt in den BW InfoProvider geladen werden.
Operational Data Provisioning
Abbildung 55: Operational-DataProvider-Technologie
Der Operational Data Provider (ODP) ist die Verbindung zwischen den in der Struktur von
DataSources gespeicherten Geschäftsdaten und den Anforderungen, die aus Operational
Analytics und der Replikation von Massendaten hervorgehen. Der Operational Data Provider
definiert die Schnittstellen für Bewegungsdaten und Stammdaten. Nach der Implementierung
ermöglichen diese den Zugriff auf Daten für Reporting und Analyse und für die Replikation auf
verschiedene Konsumenten. Für BW DataSources mit Direktzugriff gibt es eine generische
Implementierung von ODP-Schnittstellen.
Die Operational Data Provider werden in einer gemeinsamen Modellierungsumgebung für die
Suche und Analyse definiert. In einem Such- und Analysemodell werden BW DataSources
oder andere Datenquellen als Knoten importiert. Wenn ein Operational Data Provider auf
einem Knoten definiert ist, erhält der Knoten analytische Eigenschaften, die beispielsweise
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 56Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

65. festlegen, ob ein bestimmtes Feld als Kennzahl oder als Merkmal interpretiert wird, ob es als
Navigationsattribut verfügbar ist, oder welche Selektionseigenschaften ein Feld besitzt.
Für Zwecke der Operational Analytics kann ein Operational Data Provider mit anderen
semantisch verwandten Operational Data Providern über Relationen verknüpft werden, die
Fremdschlüsselbeziehungen definieren. Der Analytic Manager kann aus dieser Art von Modell
einen InfoProvider ableiten. Ein InfoProvider dieses Typs wird als TransientProvider bezeichnet, da er nicht wie in BW modelliert, sondern zur Query-Designzeit während der Laufzeit angelegt wird. Operational Data Providers ermöglichen somit das Reporting und die
Analyse in BW-Datenquellen oder anderen Datenquellen im operativen System der
Unternehmensanwendung, ohne die Daten in einem BW replizieren zu müssen.
In der Implementierung für DataSources unterstützt der Operational Data Provider implizit
die Replikation von Massendaten unter Verwendung der Replikationseigenschaften der
DataSources.
Abbildung 56: Details des Datenflusses in SAP BW
Nachdem die Daten in die PSA übertragen wurden, müssen sie vor ihrer physischen Ablage in
den Zielen zunächst bereinigt und transformiert werden. Zu diesen Zielen zählen InfoObjects
(Stammdaten), InfoCubes und DataStore-Objekte.
Die Transformation wird unter Verwendung einer grafischen Oberfläche bearbeitet. Hinter
den Kulissen verwendet das SAP-System den ABAP-Stack für die Kodierung der
Transformationen, die von Ihnen, dem Kunden, überwiegend ohne ABAP-Coding kodiert
wurden.
Eine InfoSource ist eine nicht persistente, aus InfoObjects bestehende Struktur zur
Verknüpfung zweier Transformationen.
Sie verwenden InfoSources, wenn im Datenfluss zwei (oder mehr) Transformationen
nacheinander durchlaufen werden sollen, ohne dass die Daten zusätzlich abgelegt werden sollen.
Lektion: Anlegen einer generischen DataSource
©Copyright. Alle Rechte vorbehalten. 57Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

66. Wenn Sie keine zwei aufeinanderfolgenden Transformationen benötigen, können Sie den
Datenfluss ohne InfoSources modellieren. In diesem Fall werden die Daten mithilfe einer
Transformation direkt aus der Quelle in das Ziel geschrieben.
Möglicherweise ist es jedoch aus Gründen der Semantik oder der Komplexität erforderlich,
eine oder mehrere InfoSources zu verwenden. So benötigen Sie z.B. eine Transformation, um
das Format und die Zuordnung zu InfoObjects sicherzustellen, und eine weitere
Transformation, um die eigentlichen Geschäftsregeln umzusetzen. Wenn es sich um
komplexe, von einander abhängige Regeln handelt, ist es möglicherweise sinnvoll, mehr als
eine InfoSource zu nutzen.
Wir empfehlen für die Zuordnung verschiedener DataSources zu einem Ziel die Verwendung
einer InfoSource, wenn für die DataSources dieselben Geschäftsregeln gelten. In der
Transformation haben Sie die Möglichkeit, das Datenformat in der DataSource dem
Datenformat in der InfoSource anzugleichen. Die erforderlichen Geschäftsregeln werden in
der nachfolgenden Transformation zwischen der InfoSource und dem Ziel angewendet.
Eventuell erforderliche Änderungen dieser Regeln können zentral in dieser Transformation
durchgeführt werden.
Abbildung 57: Operational Data Provisioning – Delta-Queue (ODP/ODQ)
Operational Data Provisioning unterstützt Extraktions- und Replikationsszenarien für
verschiedene Zielanwendungen und die Delta-Mechanismen in diesen Szenarien. Neben der
Indizierung von Daten in der SAP-HANA-Datenbank oder im SAP BW Accelerator ermöglicht
Operational Data Provisioning die Datenübertragung (z.B. zu SAP BusinessObjects Data
Services) mithilfe eines ETL-Prozesses (Extraktion, Transformation und Laden). Zur
Unterstützung des Deltaverfahrens werden die Daten aus einer Quelle unter Verwendung
eines Aktualisierungsprozesses automatisch in eine Delta-Queue geschrieben oder über eine
Extraktorschnittstelle an die Delta-Queue übergeben. DataSources werden derzeit als
Provider unterstützt, die die Delta-Queue-Daten verfügbar machen. Die Zielanwendungen (die
als Abonnenten bezeichnet werden) rufen die Daten aus der Delta-Queue ab und verarbeiten
die Daten weiter.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 58Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

67. Der Delta-Queue-Monitor (TransaktionODQMON) ermöglicht das Überwachen der Delta-
Queues in verschiedenen Views:
●Queues: Hier sehen Sie alle Queues, die im System verfügbar sind, mit dem jeweiligen
Status, der Anzahl der zugehörigen Abonnements und der Anzahl der zugehörigen
Requests.
●Abonnements: Die ausführlichen Informationen zur Abonnementstufe werden hier
angezeigt.
●Requests: Die ausführlichen Informationen zur Requeststufe werden hier angezeigt.
●Einheiten: Die Einheiten, in denen die Daten eines Requests gemeinsam übertragen
werden können, werden hier angezeigt.
Um auf die Views zuzugreifen, verwenden Sie die Drucktasten oder das MenüMonitor.
Abbildung 58: Operational Data Provisioning mit SAP-Extraktoren
Eine Delta-Queue ist ein Datenspeicher im Quellsystem. Datensätze werden entweder
automatisch mit einem Fortschreibungsprozess im Quellsystem in die Delta-Queue
geschrieben (z.B. 2LIS_11_VAITM) oder mit der Extraktorschnittstelle
(z.B. 0COSTCENTER_ATTR) abgerufen.
Die Rolle eines Providers ist die Bereitstellung mindestens einer Delta-Queue von einem
bestimmten Typ. Die BW-DataSource ist beispielsweise ein Provider. In diesem Fall stimmt
der Name der Delta-Queue mit dem Namen der DataSource überein (z.B. 2LIS_11_VAITM).
Die Zielanwendung der Delta-Queue wird als „Abonnent“ bezeichnet (z.B. eines bestimmten
Datendienstsystems). Ein Abonnement kann wie folgt definiert werden: Ein bestimmter
Abonnent fordert von mindestens einer Queue Datenänderungen an und fährt mit der Verarbeitung der übertragenen Daten fort. Abonnenten werden durch ihren Abonnententyp
kategorisiert (z.B. SAP BusinessObjects Data Services). Ein Abonnement erfolgt, wenn der
Abonnent Daten anfordert. Jedes Abonnement hat eine eindeutige Transaktionsnummer, z.B.
(2010-10-22 08:03:52 000001 CET). Ein Abonnent kann mehrere Abonnements haben. Eine
Queue kann auch in mehreren Abonnements desselben Abonnenten vorkommen.
Die Daten werden in der Delta-Queue komprimiert abgelegt. Ein Delta-Request überträgt die
Datensätze aus der Queue an den Abonnenten. Die Datenänderungen für eine Queue können
Lektion: Anlegen einer generischen DataSource
©Copyright. Alle Rechte vorbehalten. 59Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

68. auch von mehreren Abonnenten angefordert werden. Ein Abonnent kann auch Daten aus
einer Queue in Form eines einmaligen Requests (Full) anfordern. In diesem Fall stellt der
Request kein Abonnement dar.
Die Daten werden für eine bestimmte Zeitspanne zu Wiederherstellungszwecken in der Delta-
Queue gehalten, falls der Abonnent die Datensätze erneut abrufen muss.
Abbildung 59: DataSource-Erstellungszugriff und der generische Extraktor
Die Abbildung „DataSource-Erstellungszugriff und der generische Extraktor“ zeigt die
TransaktionSBIWim Quellsystem. Hier können Sie generische DataSources anlegen und
ändern.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 60Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

69. Abbildung 60: DataSource für ODP freigeben
Die ODP-API zeigt nicht alle Extraktoren an, nur die freigegebenen. SAP hat verschiedene
Extraktoren entwickelt, einige sind inzwischen veraltet, und einige funktionieren
möglicherweise nicht mit dieser API. Mit der ODP-API wird im Dictionary die neue Tabelle
ROOSATTR angelegt, die alle Extraktoren der API enthält und somit DataServices 4.0
unterstützt. Zunächst ist dies nur eine sehr begrenzte Liste mit Schwerpunkt auf den
wichtigsten Extraktoren. Sie wird im Laufe der Zeit immer mehr wachsen. Sie enthält
sicherlich keine von Kunden geschriebenen Extraktoren.
Mit dem SAP-Programm RODPS_OS_EXPOSE, dessen Transaktionscode unbekannt ist,
können von Kunden geschriebene Extraktoren hinzugefügt werden. Weitere Informationen
zur Verfügbarkeit von Standard-Extraktoren finden Sie in den SAP-Hinweisen 1558737 und
1806637.
Lektion: Anlegen einer generischen DataSource
©Copyright. Alle Rechte vorbehalten. 61Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

70. Abbildung 61: DataSource in SAP BW nach der Replikation
Um auf DataSources zugreifen und diese in Ihren InfoProvidern abbilden zu können, müssen
Sie die Informationen zum DataSource-Namen und zu den von der DataSource
bereitgestellten Feldern nach SAP BW übertragen. Dieser Vorgang wird Replikation bzw.
Replizieren der DataSource-Metadaten genannt. Er wird über das Kontextmenü des Ordners
ausgeführt, in dem sich die DataSource befindet. Nachdem die DataSource in SAP BW
repliziert wurde, besteht der letzte Schritt in ihrer Aktivierung. Sie können Business-Content-
Datenflüsse vollständig aus der Data Warehousing Workbench aktivieren. Während dieses
Prozesses erfolgt die Aktivierung der Business-Content-DataSource im SAP-Quellsystem und
die Replikation in SAP BW mithilfe eines Remote Function Call (RFC).
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 62Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

71. Abbildung 62: Generische DataSource anlegen – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Eine generische DataSource anlegen
Lektion: Anlegen einer generischen DataSource
©Copyright. Alle Rechte vorbehalten. 63Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

72. Kapitel 2
Lektion 3
Anlegen von Transformations- und
Datentransferprozessen (DTP) für das Laden
von Attributstammdaten
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in den Datentransferprozess (DTP). In dieser Lektion
wird beschrieben, wie Sie eine Transformation und einen DTP anlegen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Transformations- und Datentransferprozesse (DTP) für das Laden von
Attributstammdaten anlegen
Datenfluss für stammdatentragendes InfoObject
Abbildung 63: Datenfluss für stammdatentragendes InfoObject
Die Abbildung „Datenfluss für stammdatentragendes InfoObject“ stellt im Wesentlichen die
fünf Hauptschritte des Prozesses zum Laden von Stammdaten aus SAP-Quellsystemen im
Klassenszenario dar. Beachten Sie, dass in Schritt 2 die DataSource repliziert und aktiviert
wird und das Merkmal zuvor als InfoProvider hinzugefügt wurde.
Der Ladeprozess umfasst die folgenden Schritte:
©Copyright. Alle Rechte vorbehalten. 64Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

73. ●Legen Sie eine DataSource auf SAP-ECC-Seite an, um zu definieren, welche Felder in SAP
BW hochgeladen werden sollen.
●Replizieren Sie die DataSource in SAP BW, um die Felder zur Verfügung zu stellen.
●Aktivieren Sie die DataSource, um die PSA-Tabelle zu generieren.
●Fügen Sie das Merkmal als InfoProvider ein, da das Ziel einer Transformation ein
InfoProvider sein muss. (Bei Verwendung der Datenflussfunktion wird dies automatisch
durchgeführt).
●Legen Sie eine Transformation an, um die Zuordnung der DataSource-Felder zu den
Attributfeldern des Merkmals festzulegen.
●Legen Sie den Datentransferprozess (DTP) an, und führen Sie ihn aus, um die Daten aus
der ODQ-Delta-Queue in die Attributtabelle zu laden.
Abbildung 64: Szenario zum Laden von Stammdaten aus SAP-Quellsystemen
Die Bereinigung oder Transformation der Daten erfolgt innerhalb einer dedizierten
Transformation in SAP BW. Jedes Mal, wenn Sie aus Ihrem Quellsystem stammende Felder in
InfoObjects in Ihren InfoProvidern von SAP BW konvertieren möchten, legen Sie eine
dedizierte Transformation an, die aus einer Transformationsregel pro Objekt besteht.
Anstatt den benutzerdefinierten Übertragungscode für jedes Vorkommen der Kostenstelle in
einer Transformation einzeln zu schreiben, können Sie den Code auch direkt an das
InfoObject (im vorliegenden FallU##_COSTC) anfügen. Durch Erstellung einer globalen
Übertragungsroutine, die die gewünschte Logik enthält, wird gewährleistet, dass diese Logik
jedes Mal automatisch ausgeführt wird, wenn das InfoObject Kostenstelle in einer
Transformation verwendet wird. Nach dem einmaligen Schreibaufwand für den Code steht
dieser jedes Mal zur Verfügung, wenn Kostenstellen-InfoObjects verwendet werden.
Lektion: Anlegen von Transformations- und Datentransferprozessen (DTP) für das Laden von Attributstammdaten
©Copyright. Alle Rechte vorbehalten. 65Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

74. Transformation und DTP
Abbildung 65: Zugriff spfad zum Anlegen einer Transformation
Sie können die SAP-BW-Transformation über das Kontextmenü des InfoProviders anlegen.
Anschließend verwendet das System den InfoProvider als Ziel der SAP-BW-Transformation.
Sie können die SAP BW-Transformation auch über das Kontextmenü der DataSource
anlegen. Anschließend verwendet das System die DataSource als Quelle der SAP-BW-
Transformation.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 66Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

75. Abbildung 66: Transformations-GUI-Stammdaten
Dieser erste Ladeprozess soll einfach gehalten werden. Da eine benutzerdefinierte globale
Übertragungslogik direkt zum InfoObject hinzugefügt wurde, ist für den dritten Schritt nur
eine Feld-zu-Feld-Zuordnung erforderlich.
Mit Ausnahme der 13-stelligen Kostenstelle sind für alle übrigen Felder in den Stammdaten
der Kostenstelle in Tabelle CSKS im SAP-ERP-System entsprechende InfoObjects vorhanden;
die Informationen müssen lediglich SAP BW mitgeteilt werden. Dazu legen Sie eine
Transformation und feldspezifische Transformationsregeln an. In unserem Fall entsprechen
sämtliche Regeln dem Typ „Direkte Zuordnung“. Die Zuordnung zwischen den Feldern und
der Kostenstellen-Stammdatentabelle kann in der Transformation per Drag&Drop erfolgen.
Lektion: Anlegen von Transformations- und Datentransferprozessen (DTP) für das Laden von Attributstammdaten
©Copyright. Alle Rechte vorbehalten. 67Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

76. Abbildung 67: Erstellung und Überwachung des Datentransferprozesses
Wenn Sie den Data Transfer Process (DTP) ausführen, werden Sie gefragt, ob Sie sich den
Monitor anschauen möchten. Hier finden Sie detaillierte Informationen zum Ladeprozess.
Abbildung 68: Stammdaten erfolgreich geladen
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 68Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

77. Nach dem Laden der Attribute können Sie die Stammdaten über das Kontextmenü von
InfoObject: Stammdaten pflegen überprüfen.
Abbildung 69: Transformation und DTP für Attributstammdaten anlegen – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Transformations- und Datentransferprozesse (DTP) für das Laden von
Attributstammdaten anlegen
Lektion: Anlegen von Transformations- und Datentransferprozessen (DTP) für das Laden von Attributstammdaten
©Copyright. Alle Rechte vorbehalten. 69Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

78. Kapitel 2
Lektion 4
Unterschied zwischen der klassischen und
grafischen Datenfluss-Modellierung
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erhalten Sie eine Einführung in die grafischen Datenflüsse in der Data
Warehousing Workbench. Darüber hinaus erfahren Sie, wie Sie einen grafischen Datenfluss
anlegen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Den Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung
verstehen
Grafischer Datenfluss
Abbildung 70: Stammdaten-Ladeszenario
Den ersten Datenfluss für die Attribute haben wir über das Kontextmenü angelegt. Wir
werden den zweiten Datenfluss für Texte im grafischen Datenflusstool anlegen.
©Copyright. Alle Rechte vorbehalten. 70Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

79. Abbildung 71: Datenflussobjekte in RSA1
Das Werkzeug zur grafischen Datenflussmodellierung
Datenflussobjekte können zur Verwaltung und Ausführung von Datenflusskomponenten
verwendet werden. Datenflussobjekte verwenden eine grafische Benutzungsoberfläche.
Datenflussobjekte (und Datenflussvorlagen) werden im Modellierungsbild der Data
Warehousing Workbench in einem separaten Objektbaum angezeigt. Datenflussobjekte sind
InfoAreas zugeordnet. Die Ordner (nach Objekttyp organisiert) unter einem Datenflussobjekt
zeigen an, welche Objekte im Datenflussobjekt enthalten sind.
Lektion: Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung
©Copyright. Alle Rechte vorbehalten. 71Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

80. Abbildung 72: Aufbauen eines Datenflussobjekts
Grafische Datenflussmodellierung
Anhand einer grafischen Benutzungsoberfläche können Sie Datenflussobjekte und
Datenflussvorlagen in der Data Warehousing Workbench einfach anlegen. Die grafische
Datenflussmodellierung bringt zahlreiche Vorteile mit sich. Die grafische Top-Down-
Modellierung ermöglicht eine schnelle und strukturierte Modellierung direkt in SAP BW. Zu
den Vorteilen gehören unter anderem:
●Sie können Datenflussvorlagen mit Blick auf die Standardisierung der Modellierung
definieren und somit die Gesamtentwicklungskosten reduzieren. Die Implementierung ist
anhand von Datenflüssen strukturierbar.
Sie können Modellierungsobjekte gruppieren und diese als persistente Sicht für Ihr
Unternehmensmodell speichern. Sie können auch vorhandene Modelle (aus SAP BW 7.0
oder höher) hinzufügen.
●
Eine bessere Übersicht über die Datenflüsse erhalten Sie, indem Sie diese nach
Anwendungsbereich oder Data-Warehouse-Schicht ordnen.
●Der Datenfluss bzw. die Datenflussvorlage ist ein eigenständiger TLOGO-Objekttyp
(DMOD). Datenflüsse und Datenflussvorlagen können transportiert werden und verfügen
über einen Repository-Anschluss, einen Dokumentenanschluss sowie einen Anschluss zur
Versionsverwaltung.
●Mithilfe von Namenskonventionen können Modelle gleichzeitig verwendet und
wiederverwendet werden.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 72Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

81. Abbildung 73: Grafisches Datenflussobjekt
Enthält ein Datenfluss ausschließlich nicht persistente Objekte, kann das Datenflussobjekt als
Datenflussvorlage gesichert und verwendet werden. Diese Objekte werden als Platzhalter für
die Definition des Objekts und einiger anderer Eigenschaften (technischer Name und
Beschreibung) verwendet.
Eine Datenflussvorlage beschreibt ein Datenflussszenario mit allen erforderlichen Objekten.
In Datenflussvorlagen sind die Kenntnisse zur geeignetsten Modellierung praktisch
gespeichert, auf die Sie beim Definieren der Datenflüsse zurückgreifen können.
Datenflussvorlagen unterstützen die komplexe Modellierung diff erenzierter Data-Warehouse-
Schichten in der LSA (Layered Scalable Architecture) wie auch die schnelle Modellierung
einfacher Standarddatenflüsse. Sie können auch eigene Vorlagen definieren und damit
Standards für Ihr Unternehmen festlegen.
Abbildung 74: Grafische Datenflüsse anlegen – Übung
Lektion: Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung
©Copyright. Alle Rechte vorbehalten. 73Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

82. Grafische Datenflüsse anlegen
In der Vorgehensweise wird erläutert, wie ein Datenfluss im Datenflussbaum in der Data
Warehousing Workbench angelegt wird.
1.Wählen Sie im BaumDatenflüsse des Navigators die InfoArea aus, der Sie den neuen
Datenfluss zuordnen möchten.
2.Wählen Sie im Kontextmenü derInfoAreaDatenfluss anlegen .
3.Geben Sie im DialogfensterDatenfluss anlegen im FeldDatenfluss einen technischen
Namen und im FeldBeschreibungeine Beschreibung des Datenflusses ein, und wählen Sie
Weiter.
Das BildDatenfluss bearbeiten wird angezeigt. Der technische Name des Datenflusses ist
auf 30 Zeichen begrenzt. Wenn Sie eine Datenflussvorlage anlegen, wird für die letzten
Zeichen TMPL eingesetzt.
4.Um die erforderlichen Objekte dem Datenfluss hinzuzufügen, wählen Sie die Objekte aus,
und ziehen Sie sie in den ArbeitsbereichDatenfluss . Persistente und nichtpersistente
Objekte werden auf unterschiedliche Weise hinzugefügt.
5.Verbinden Sie die Objekte miteinander.
6.Um den Datenfluss auf Konsistenz zu prüfen, wählen Sie Prüfen.
Ein Datenfluss ist dann konsistent und kann aktiviert werden, wenn alle zum Datenfluss
gehörenden persistenten Objekte vorhanden sind und den Objektstatus „aktiv“ haben.
Wenn der Datenfluss nicht persistente Objekte enthält, werden während der
Konsistenzprüfung entsprechende Warnmeldungen angezeigt. Der Datenfluss kann
dennoch gesichert und aktiviert werden. Eine Datenflussvorlage ist nur dann konsistent
und kann aktiviert werden, wenn sie ausschließlich nicht persistente Objekte enthält.
7.Sichern und aktivieren Sie den Datenfluss.
Sie haben auch die Möglichkeit, den Datenfluss als Vorlage zu sichern und zu aktivieren,
aber nur unter der Voraussetzung, dass er ausschließlich nicht persistente Objekte
enthält.
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 74Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

83. Grafischer Datenfluss zum Laden von Textstammdaten
Abbildung 75: Textstammdaten über den grafischen Datenfluss laden –Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Den Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung
verstehen
Lektion: Unterschied zwischen der klassischen und grafischen Datenfluss-Modellierung
©Copyright. Alle Rechte vorbehalten. 75Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

84. Kapitel 2
Lektion 5
Löschen und Aktivieren von Stammdaten
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erfahren Sie, wie Stammdaten gelöscht und aktiviert werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Das Löschen und Aktivieren von Stammdaten verstehen
Löschen und Aktivieren von Stammdaten
Abbildung 76: Administration: Request-Management für InfoObjects
Ein Ladevorgang wird als Request bezeichnet. Sie können Informationen zu Requests
anzeigen und überprüfen, ob die Daten erfolgreich gebucht und fortgeschrieben wurden. Sie
können die Verwaltungsinformationen für diese Requests löschen, aber Sie können hier keine
Daten aus dem InfoObject löschen, wie dies bei DataStore.Objekten und InfoCubes möglich
ist.
©Copyright. Alle Rechte vorbehalten. 76Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

85. Abbildung 77: Administration: Löschen von Merkmalstammdaten
Sie können Stammdaten und Texte direkt aus der Stammdatentabelle in BW löschen. Sie
müssen keine Löschvorgänge auf den einzelnen Datensatzebenen durchführen. Mit dieser
Funktion können Sie alle vorhandenen Stammdaten und Texte eines Merkmals in einem
Vorgang löschen.
Voraussetzungen: Um Stammdaten löschen zu können, dürfen für diese Stammdaten keine
Bewegungsdaten in BW vorhanden sein, sie dürfen nicht als Attribut für InfoObjects
verwendet werden, und es dürfen keine Hierarchien für diese Stammdaten vorhanden sein.
Sie finden die Funktion „Stammdaten löschen“ im Kontextmenü Ihres InfoObjects im
InfoObject-Baum und auch im InfoProvider-Baum.
Wenn Sie die Funktion „Stammdaten löschen“ wählen, prüft das Programm die Einträge in
der betroffenen Stammdatentabelle, um festzustellen, ob sie in anderen Objekten verwendet
werden. Beim Löschen können Sie auswählen, ob Einträge in der SID-Tabelle eines Merkmals
beibehalten oder gelöscht werden sollen:
●Wenn Sie den SID-Tabelleneintrag für ein bestimmtes Merkmal löschen, geht der dem
Merkmalswert zugeordnete SID-Wert verloren. Wenn Sie neue Attribute für diesen
Merkmalswert zu einem späteren Zeitpunkt laden, müssen Sie für den Merkmalswert
einen neuen SID-Wert anlegen. Dies wirkt sich in der Regel negativ auf die für den
Ladeprozess erforderliche Laufzeit aus. In manchen Fällen kann das Löschen von
Einträgen aus der SID-Tabelle auch zu schwerwiegenden Dateninkonsistenzen führen.
Dies ist der Fall, wenn die Liste der SID-Werte (generiert aus dem Verwendungsnachweis)
nicht vollständig ist. Dies kommt jedoch selten vor.
●Löschen und Beibehalten von SIDs
Sie sollten diese Option standardmäßig wählen. Auch wenn Sie z.B. sicherstellen möchten,
dass einzelne Attribute des Merkmals, die nicht mehr benötigt werden, vor dem Laden von
Lektion: Löschen und Aktivieren von Stammdaten
©Copyright. Alle Rechte vorbehalten. 77Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

86. Stammdatenattributen oder -texten gelöscht werden, ist die Möglichkeit, Stammdaten zu
löschen, aber die Einträge aus der SID-Tabelle beizuhalten, ebenfalls absolut angemessen.
●Löschen mit SIDs
Beachten Sie, dass das Löschen von Einträgen aus der SID-Tabelle nur in Ausnahmefällen
erforderlich oder nützlich ist. Das Löschen von Einträgen aus der SID-Tabelle macht
keinen Sinn, wenn Sie z. B. die Zusammensetzung des Merkmalschlüssels erheblich
ändern und Sie von einem großen Datensatz mit Merkmalswerten zu einem neuen
Datensatz mit neuen Schlüsselwerten wechseln möchten.
Abbildung 78: Administration: Stammdatenaktivierung
Wenn Sie Stammdaten aus einem Quellsystem aktualisieren, werden die Stammdaten im
inaktiven Zustand importiert. Sie müssen die neuen Stammdaten aktivieren, damit sie für
Berichtszwecke abgerufen und genutzt werden können. Wählen SieInfoObject-
Baum→Kontextmenü des entsprechenden Merkmals→Aktivieren.
Das System aktiviert nun automatisch die Stammdaten, so dass sie direkt im Reporting
verwendet werden können. Die Texte sind sofort aktiv und können direkt in Analyse und
Reporting verwendet werden. Sie brauchen sie nicht manuell zu aktivieren.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Das Löschen und Aktivieren von Stammdaten verstehen
Kapitel 2: Stammdaten in SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 78Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

87. Kapitel 2
Überprüfung des Lernerfolgs
1.Welche Funktion hat ein InfoObject?
2.Welche der folgenden Objekte sind InfoObjects?
Wählen Sie die richtigen Antworten.
X
AMerkmal-InfoObjects
X
BKennzahl-InfoObjects
X
CTransformations-InfoObjects
X
DZeitmerkmal-InfoObjects
3.Welche Funktion hat die PSA?
4.In SAP BW 7.x ist die PSA optional.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
5.Datenflussobjekte sind InfoAreas zugeordnet.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
©Copyright. Alle Rechte vorbehalten. 79Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

88. 6.Mit welcher Transaktion wird die Data Warehousing Workbench aufgerufen?
Kapitel 2: Überprüfung des Lernerfolgs
©Copyright. Alle Rechte vorbehalten. 80Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

89. Kapitel 2
Überprüfung des Lernerfolgs - Antworten
1.Welche Funktion hat ein InfoObject?
Ein InfoObject wird zum Anlegen von Tabellen für die Speicherung von Daten verwendet.
2.Welche der folgenden Objekte sind InfoObjects?
Wählen Sie die richtigen Antworten.
X
AMerkmal-InfoObjects
X
BKennzahl-InfoObjects
X
CTransformations-InfoObjects
X
DZeitmerkmal-InfoObjects
3.Welche Funktion hat die PSA?
Die PSA ist eine transparente Datenbanktabelle, in der angeforderte Daten abgelegt
werden. Sie stellt den Arbeitsbereich für die ETL-Verarbeitung bereit.
4.In SAP BW 7.x ist die PSA optional.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
5.Datenflussobjekte sind InfoAreas zugeordnet.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
6.Mit welcher Transaktion wird die Data Warehousing Workbench aufgerufen?
RSA1
©Copyright. Alle Rechte vorbehalten. 81Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

90. KAPITEL 3Bewegungsdaten in SAP
Business Warehouse
(SAP BW)
Lektion 1
Einführung in die SAP Business Warehouse (SAP BW) InfoProvider 83
Lektion 2
Anlegen eines Kennzahl-InfoObjects 91
Lektion 3
Modellieren von DataStore-Objekten (advanced) 94
Lektion 4
Anlegen eines Datenflusses für Bewegungsdaten 105
Lektion 5
Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer
Flatfile-DataSource
113
Lektion 6
Modellieren von CompositeProvidern 133
LERNZIELE
●SAP-BW-InfoProvider beschreiben
●ein Kennzahl-InfoObject anlegen
●Advanced DataStore-Objekte modellieren
●Einen Datenfluss für Bewegungsdaten anlegen
●Ein Advanced DataStore-Objekt anlegen (wie klassisches DSO) und Daten aus einer
Flatfile-DataSource laden
●Daten aus einer Flatfile-DataSource in das DataStore-Objekt (advanced) laden
●Daten in einem DataStore-Objekt (advanced) aktivieren und fortschreiben
●CompositeProvider anlegen
©Copyright. Alle Rechte vorbehalten. 82Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

91. Kapitel 3
Lektion 1
Einführung in die SAP Business Warehouse
(SAP BW) InfoProvider
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in die InfoProvider. Sie erfahren, wie InfoProvider in SAP
BW eingesetzt werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●SAP-BW-InfoProvider beschreiben
Klassischer InfoProvider
Im folgenden Text wird der Begriff InfoProvider definiert.
●Ein InfoProvider ist ein Objekt, für das Querys angelegt oder ausgeführt werden können.
●InfoProvider sind physische Objekte oder manchmal logische Sichten, die relevant für das
Reporting sind.
Die Definition folgert richtig, dass ein InfoProvider entweder die physische Speicherung von
Daten in realen Datenbanktabellen oder eine virtuelle Sammlung von Daten (wie eine Sicht)
sein kann, in der Daten nur für die Eingabe in eine Query vorübergehend zusammengestellt,
aber nicht dauerhaft gespeichert werden. Wir werden uns hier, bei unserem ersten Kontakt
mit InfoProvidern, auf die beiden wichtigsten physischen InfoProvider konzentrieren:
●InfoCubes
●DataStore-Objekte
©Copyright. Alle Rechte vorbehalten. 83Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

92. Abbildung 79: Schichten und klassische InfoProvider im Enterprise Data Warehouse
Aus einem Quellsystem extrahierte Daten können anfangs in den PSA-Tabellen (Persistent
Staging Area) abgelegt werden. Anschließend müssen Sie in den meisten Fällen diese Daten
physisch und dauerhaft in SAP BW speichern. Für eine dauerhafte Speicherung und den
Zugriff auf BW-Daten mit Reporting-Werkzeugen ist die Erstellung von InfoProvidern
erforderlich. SAP BW bietet eine Reihe von InfoProvidern für unterschiedliche Zwecke an.
Einige speichern Daten physisch, andere bieten eine zusätzliche Sicht der Daten.
In vielen Situationen ist es notwendig, zusätzliche Schichten in den Stagingprozess
einzubauen. SAP BW bietet die Möglichkeit, ein oder mehrere DataStore-Objekte in den
Datenfluss zwischen PSA und InfoCubes zu integrieren. Diese DataStore-Objekte speichern
die Daten normalerweise auf detaillierter Ebene und dienen dazu, die Daten zu harmonisieren
und zu konsolidieren, bevor sie in mehrdimensionalen InfoCubes aggregiert abgelegt werden.
●Merkmals-InfoObject
Speichert Stammdaten (z. B. Kunde, Material und Kostenstelle), die zum Erstellen der
Tabellen für andere InfoProvider verwendet werden.
●DataStore-Objekt
Speichert Bewegungsdaten detailliert (zum Beispiel Kundenauftragsdaten auf
Positionsebene).
●InfoCube
Speichert Bewegungsdaten auf der aggregierten Ebene (zum Beispiel Verkaufsbeträge
und -mengen pro Monat).
●MultiProvider
Bietet eine Sicht der Daten verschiedener InfoProvider (zum Beispiel Verkaufsbeträge in
Deutschland und den USA).
Mit Transformationen können Sie die Daten, die Sie aus dem Quellsystem extrahiert haben,
transformieren, anreichern und ändern. Dies ist eventuell bei speziellen Reporting-
Anforderungen oder der Harmonisierung von Daten aus unterschiedlichen Quellsystemen
erforderlich.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 84Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

93. Die Abbildung „Schichten und klassische InfoProvider im Enterprise Data Warehouse“ bietet
einen Überblick über die Verwendungsmöglichkeiten der verschiedenen InfoProvider in SAP
BW. Jeder InfoProvider erfüllt eine eigene Rolle und kann mit Daten aus den Quellsystemen
geladen werden. Über die Reporting-Werkzeuge von SAP BW können Sie auf die Daten
zugreifen und diese für das Reporting nutzen.
Abbildung 80: Datenfluss mit SAP BW und einer beliebigen Datenbank (Beispiel)
Eine DataSource ist das Objekt in SAP BW, das zur Datenextraktion aus dem Quellsystem
angelegt wird. Die DataSource enthält Informationen zum Speicherort der erforderlichen
Daten und zu den Datenstrukturen. Die PSA ist eine Tabelle, in der die erforderlichen Daten
zunächst in SAP BW gespeichert werden. Sie speichert die Daten im Quellformat (nicht
transformiert).
InfoProvider sind die Objekte, die zum dauerhaften Speichern der Daten oder zum Zugreifen
auf Daten aus anderen Tabellen in SAP BW verwendet werden. Diese Objekte bilden zudem
auch die Grundlage für Ihre Reporting-Requests.
DataStore-Objekt speichert Bewegungsdaten detailliert (zum Beispiel Kundenauftragsdaten
auf Positionsebene).
InfoCube speichert Bewegungsdaten auf einer aggregierten Ebene (zum Beispiel
Verkaufsbeträge und -mengen pro Monat).
Lektion: Einführung in die SAP Business Warehouse (SAP BW) InfoProvider
©Copyright. Alle Rechte vorbehalten. 85Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

94. Abbildung 81: Klassisches DataStore-Objekt: Eine vereinfachte funktionale Sicht
In einem DataStore-Objekt werden konsolidierte und bereinigte Daten (Bewegungsdaten oder
Stammdaten) auf Dokumentenebene (atomarer Ebene) gespeichert. In DataStore-Objekten
können zwar aus guten Gründen Stammdaten gespeichert werden, jedoch werden in erster
Linie detaillierte Bewegungsdaten in diesen Objekten gespeichert. Die Abbildung „Klassisches
DataStore-Objekt: Eine vereinfachte funktionale Sicht“ zeigt die Position von DataStore-
Objekten im Warehouse-Gesamtdesign. Sie können zur Unterstützung des detaillierten
operativen Reportings eingesetzt werden oder Teil des Warehouse sein, wo sie eventuell
benötigte Daten zu mehreren Jahren speichern können.
Abbildung 82: Grundkonzept eines InfoCube Eine vereinfachte funktionale Sicht
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 86Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

95. InfoCubes sind die Hauptobjekte zur Unterstützung von SAP-BW-Querys. Sie sind dafür
konzipiert, zusammengefasste und verdichtete Daten über längere Zeiträume zu sichern. Ihr
Ziel bei der Entwicklung eines Warehouse ist es, sicherzustellen, dass die meisten Querys
anfangs auf diesen Datenbankobjekttyp abzielen. In der Abbildung „Grundkonzept eines
InfoCube“ wird eine vereinfachte Sicht dargestellt.
Abbildung 83: Klassisches MultiProvider-Konzept
Ein MultiProvider ist ein InfoProvider, der Daten aus mehreren InfoProvidern zusammenführt
und sie gemeinsam für das Reporting zur Verfügung stellt. Der MultiProvider enthält selbst
keine Daten (wie InfoSets und VirtualProvider). Seine Daten ergeben sich ausschließlich aus
den zugrunde liegenden InfoProvidern. Die meisten Querys werden für MultiProvider
angelegt, die einen oder mehrere InfoCubes umfassen.
Eine Query kann nur auf einen einzelnen InfoProvider geschrieben werden. Ein MultiProvider
ist ein einzelner InfoProvider für eine Query, aber durch ihn kann indirekt auf mehrere
Provider zugegriff en werden.
Wir haben einen InfoProvider mit Istdaten zu einem logisch in sich geschlossenen
betriebswirtschaftlichen Bereich sowie einen entsprechenden InfoProvider mit Plandaten. Sie
können die beiden InfoProvider zu einem MultiProvider kombinieren, um Ist- und Plandaten in
einer Query vergleichen zu können.
Lektion: Einführung in die SAP Business Warehouse (SAP BW) InfoProvider
©Copyright. Alle Rechte vorbehalten. 87Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

96. Kern-InfoProvider in SAP Business Warehouse powered by SAP HANA
Abbildung 84: MultiProvider — Union
Sie verfügen über einen InfoProvider mit den Istdaten für einen logischen Geschäftsbereich
und einen entsprechenden InfoProvider mit den Plandaten. Für einen Vergleich der Ist- mit
den Plandaten in einer Query kombinieren Sie die beiden InfoProvider in einen MultiProvider.
Dies ist ein homogenes Datenmodell. Homogene MultiProvider bestehen aus InfoProvidern,
die technisch identisch sind, z.B. InfoCubes mit genau denselben Merkmalen und ähnlichen
Kennzahlen. In diesem Fall enthält der InfoCube mit den Plandaten die Kennzahl Plankosten,
und der InfoCube mit den Istdaten enthält die Kennzahl Istkosten.
Homogene MultiProvider sind eine Möglichkeit zur Partitionierung innerhalb der
Modellierung. Sie können ein Verkaufsszenario mit den Teilprozessen Auftrag, Lieferung und
Fakturierung modellieren. Jeder dieser Teilprozesse hat hier seine eigenen
(prozessspezifischen) InfoObjects (z.B. Lieferort und Rechnungsnummer) sowie eine Reihe
prozessübergreifender Objekte (wie Kunden- oder Auftragsnummer). Es wird empfohlen, jeden Teilprozess in einem eigenen InfoProvider zu modellieren und die InfoProvider
anschließend in einem MultiProvider zu kombinieren.
Sie können alle Teilszenarien in einem InfoProvider modellieren oder für jedes Teilszenario
einen InfoProvider anlegen und diese InfoProvider dann zu einem einzigen MultiProvider
kombinieren.
Die zweite Option vereinfacht in der Regel den Modellierungsprozess und kann die
Systemleistung beim Laden und Lesen von Daten verbessern. Für Auftrag, Lieferung und
Fakturierung gibt es jeweils einen InfoCube. Sie können individuelle Queries für die einzelnen
InfoCubes ausführen oder einen Überblick über den Gesamtprozess erstellen, indem Sie eine
Query auf der Basis des MultiProviders anlegen.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 88Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

97. Abbildung 85: InfoSet — Join
BW-InfoSets sind Objekte, mit denen beliebige Datenziele in einer logischen Sicht gesammelt
und verknüpft werden können. Diese können gesammelt und als Provider für Querys
verwendet werden. Sie verhalten sich analog zu Datenbank-Views, die verschiedene Tabellen
sammeln, auf die Programmierer anschließend zugreifen können.
InfoSets legen Sichten an und sammeln Daten aus unterschiedlichen InfoProvidern, ähnlich
wie MultiProvider. Es gibt jedoch einen bedeutenden Unterschied. InfoSets erstellen Joins
(und bieten Schnittmengen an), während MultiProvider Unions erstellen (und die Daten der
beteiligten InfoProvider kombinieren). Für Joins werden von InfoSets drei Typen unterstützt;
diese sind Inner (Equal) Joins, Anti-Joins und Outer Joins.
Abbildung 86: Alle klassischen InfoProviders
Ein MultiProvider ist ein Typ von InfoProvider, der Daten aus einer Reihe von InfoProvidern
zusammenführt und sie gemeinsam für Analysezwecke verfügbar macht. Der MultiProvider
Lektion: Einführung in die SAP Business Warehouse (SAP BW) InfoProvider
©Copyright. Alle Rechte vorbehalten. 89Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

98. enthält selbst keine Daten. Seine Daten ergeben sich vollständig aus den zugrunde liegenden
InfoProvidern. Diese InfoProvidern werden per Union-Operation miteinander verbunden.
Ein MultiProvider kann sich aus verschiedenen Kombinationen der folgenden InfoProvider
zusammensetzen: InfoCube, DataStore-Objekt, Semantisch Partitioniertes Objekt,
InfoObject, HybridProvider, InfoSet, VirtualProvider und Aggregationsebene.
Abbildung 87: Zukünftige Datamodelle – Advanced DataStore-Objekt
Modeler können jetzt das ADSO (Advanced DataStore-Objekt) für die Modellierung der
Persistenz von neuen End-to-End-Szenarien in BW 7.5 auf HANA verwenden. Das ADSO
kombiniert Funktionen aus InfoCube und DSO (klassisch) und bietet zusätzliche
Erweiterungen wie die Modellierung auf InfoObjects sowie auf Feldern für einfache
Datentypen an. Im Kontext von SAP HANA und BW soll das ADSO zum zentralen Objekt für
die Modellierung von Persistenzschichten werden und die traditionellen BW-InfoProvider mit
Persistenz (InfoCubes, DSO (klassisch), Persistent Staging Area) ersetzen. Die bestehenden
traditionellen InfoProvider werden bei der schrittweisen Entwicklung hin zur EDW-Architektur
auf Basis von ADSOs weiterhin verfügbar sein.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●SAP-BW-InfoProvider beschreiben
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 90Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

99. Kapitel 3
Lektion 2
Anlegen eines Kennzahl-InfoObjects
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird beschrieben, wie Sie ein Kennzahl-InfoObject anlegen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●ein Kennzahl-InfoObject anlegen
Kennzahl-InfoObjects
Abbildung 88: Kennzahl-InfoObject – Registerkarte „Typ/Einheit“
Wählt man den KennzahltypBetragbzw.Menge, so muss dieser Kennzahl eine Währung bzw.
Mengeneinheit zugewiesen werden. Für den KennzahltypBetragkönnen Sie zwischen einer
festen Währung (z. B. EUR) oder einer variablen Währung (z. B. 0CURRENCY) wählen. Für
KennzahltypMengekönnen Sie zwischen einer festen Mengeneinheit wie kg oder einer
variablen Mengeneinheit wie 0UNIT wählen.
Die Währung oder Einheit ist variabel, das heißt, dass Sie ein Feld zuordnen, das die Währung
enthält, in der eine Transaktion jeweils abgewickelt wird. Wenn Sie wissen, dass Ihr gesamtes
Unternehmen seine Transaktionen durchgängig in einer Maßeinheit oder Währung abwickelt,
gäbe es keinen Grund, ein Feld mit einer Variablen zu haben.
©Copyright. Alle Rechte vorbehalten. 91Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

100. Abbildung 89: Kennzahl-InfoObject-Aggregation
Abbildung 90: Anlegen eines Kennzahl-InfoObjects
Auf dieser Registerkarte werden Aggregationsvorschriften für das Verhalten der Kennzahl für
die Ablage von Daten in Tabellen in SAP BW und die Aggregation in Berichten während der
Laufzeit festgelegt. Dadurch ist sichergestellt, dass Kennzahlen aussagekräftig ausgewertet
werden. Das Aggregationsverhalten bestimmt, ob und wie die Kennzahlwerte in
Auswertungen über die verschiedenen Merkmale bzw. deren Ausprägungen
zusammengefasst werden können. Die Aggregationsvorschriften gelten nur für InfoCubes
oder Advanced DSOs (wie InfoCubes). Ausnahmeaggregation ist nur eine Standard-
Aggregation für Abfragen.
Eine Bestandsgröße ist eine nicht aggregierbare Kennzahl auf Basis eines oder mehrerer
Objekte, das mit Zeitbezug angezeigt wird. Beispiele für eine Bestandsgröße sind unter
anderem Personalbestand, Kontostand und Materialbestand. Dies sind Bestandskennzahlen
in Bezug auf Zeit. So können beispielsweise zur Errechnung des Gesamt-Materialbestands
nicht der Bestand dieses und des kommenden Monats addiert werden.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 92Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

101. ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●ein Kennzahl-InfoObject anlegen
Lektion: Anlegen eines Kennzahl-InfoObjects
©Copyright. Alle Rechte vorbehalten. 93Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

102. Kapitel 3
Lektion 3
Modellieren von DataStore-Objekten
(advanced)
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erfahren Sie, wie DataStore-Objekte modelliert werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Advanced DataStore-Objekte modellieren
DataStore-Objekt (advanced)
Abbildung 91: Grundkonzept eines InfoCube
©Copyright. Alle Rechte vorbehalten. 94Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

103. Abbildung 92: BI-InfoCube anlegen
Abbildung 93: Stammdatentragende InfoObjects
Bevor wir uns eingehender mit dem Schema eines SAP-BW-InfoCubes beschäftigen, müssen
wir noch einmal auf die Merkmal-InfoObjects zurückkommen. Wir wollen uns dabei auf
stammdatentragende Merkmal-InfoObjects konzentrieren. In der Abbildung
„Stammdatentragende InfoObjects“ sind zwei der vielen stammdatentragenden Merkmale zu
Lektion: Modellieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 95Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

104. sehen, die durch SAP BW bereitgestellt werden. Zwar sind Merkmal-InfoObjects die
Attributfelder in den Dimensionstabellen, doch spielen die Merkmale, die eine eigene mit
ihnen verknüpfte Stammdatentabelle haben, eine wichtige Rolle in unserem gesamten
Schemadesign.
Abbildung 94: Kompletter SAP-Netweaver-BW-InfoCube
Vor SAP HANA waren InfoCubes die zentralen Objekte des multidimensionalen Modells in
SAP BW. Die meisten Berichte und Analysen beruhen darauf. Ein InfoCube beschreibt aus
Reporting-Sicht einen in sich geschlossenen Datenbestand eines betriebswirtschaftlich
Bereichs, für den Sie Querys definieren können.
Ein InfoCube besteht aus einer Menge relationaler Tabellen, die mehrdimensional angeordnet
sind. Er besteht aus einer zentralen Faktentabelle, die von mehreren Dimensionstabellen
umgeben ist. SID-Tabellen verknüpfen diese Dimensionstabellen mit ihren jeweiligen
Stammdatentabellen.
Die Dimensionstabelle besitzt einen generierten, numerischen Primärschlüssel, der als
Dimensionsschlüssel bezeichnet wird. Dimensionstabellen werden mit dem Präfix DIM_ID_
versehen. Hierbei ist „DIM_ID_CostCenter“ der Dimensionsschlüssel der Dimension
„Kostenstelle“. Analog zum klassischen Sternschema setzt sich der Primärschlüssel der
Faktentabelle aus Dimensionsschlüsseln zusammen.
Sie können bis zu 13 Dimensionstabellen zu einem InfoCube definieren und müssen
mindestens eine definieren. SAP stellt drei Dimensionstabellen für insgesamt maximal 16
bereit. Paket (DIM_ID_DATAPAKET), Zeit (DIM_ID_TIME) und Einheit (DIM_ID_UNITS) sind
die drei von SAP bereitgestellten Tabellen. Die Zeit einer Transaktion ist für die Aussagekraft
erforderlich, daher ist die Zeitdimension notwendig. In der Dimension Einheit sind die Maß-
und Währungseinheiten der Kennzahlen abgelegt, also wiederum eine kritische Information.
Die Paketdimension identifieziert eindeutig den technischen Lasdevorgang.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 96Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

105. Abbildung 95: Umfassendes Beispiel für ein erweitertes Sternschema
In der Abbildung „Umfassendes Beispiel für ein erweitertes Sternschema“ sind weitere
Dimensionen und Stammdaten dargestellt. Wie wir bereits im ersten Abschnitt dieser Lektion
gesehen haben, werden die Fakten in der Faktentabelle „Kennzahlen“ und die
Dimensionsattribute „Merkmale“ genannt. Die Dimensionstabellen sind über
Schlüsselbeziehungen mit der zentralen Faktentabelle verknüpft.
Im Gegensatz zum klassischen Sternschema sind die Merkmale nicht Bestandteil der
Dimensionstabellen; die Merkmalswerte werden nicht in den Dimensionstabellen abgelegt. Es
wird zu jedem Merkmal ein numerischer SID-Schlüssel generiert. Dieser Alias-Schlüssel ist
anstelle des Merkmals Bestandteil der Dimensionstabelle. Dabei steht SID für Stammdaten-
ID oder Surrogat-ID (Ersatzschlüssel).
Lektion: Modellieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 97Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

106. Abbildung 96: InfoCube-übergreifend gemeinsam genutzte Stammdaten
Ein Aspekt der Stammdaten ist, dass sie allen InfoCubes gemeinsam (mit ihnen verknüpft)
sind, die das entsprechende Merkmal-InfoObject als Bestandteil einer Dimension haben. Dies
wurde durch die Entfernung von Stammdaten aus den Dimensionstabellen mithilfe von SID-
Technologie zur Erstellung der Verknüpfungen möglich. Das Ergebnis ist, dass Sie die
Stammdaten mit verschiedenen InfoCubes von SAP BW verwenden. Die Stammdaten sind
InfoCube-unabhängig und können von mehreren Querys aus mehreren verschiedenen
InfoCubes gleichzeitig verwendet werden. Dieses Konzept wird in der Abbildung „InfoCube-
übergreifend gemeinsam genutzte Stammdaten“ dargestellt.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 98Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

107. Abbildung 97: SAP-HANA-optimierter InfoCube: Vom Schneeflockenschema zum Sternschema
Der SAP-HANA-optimierte InfoCube ist ein Standard-InfoCube, der für die Verwendung mit
SAP HANA optimiert wurde. Das Datenmodell ist viel schlanker als der ursprüngliche
InfoCube und sollte genutzt werden, wenn Sie mit einem BW-System auf SAP HANA arbeiten.
Anstelle von bis zu achtzehn Tabellen eines klassischen InfoCube-Datenmodells gibt es in der
HANA-optimierten Version nur noch zwei Tabellen: Faktentabelle und Paketdimension.
Der SAP-HANA-optimierte InfoCube ist ein Standard-InfoCube, der für die Verwendung mit
SAP HANA optimiert wurde. Wenn Sie HANA-optimierte InfoCubes anlegen, können Sie den
Dimensionen Merkmale und Kennzahlen zuordnen. Das System legt jedoch außer der
Paketdimension keine weiteren Dimensionstabellen an. Die SIDs (Stammdaten-IDs) werden
direkt in die Faktentabelle geschrieben. Dadurch verbessert sich die Systemperformance
beim Laden von Daten. Da Dimensionen nicht berücksichtigt werden, müssen keine DIM-IDs
(Dimensionsschlüssel) angelegt werden. Die Dimensionen werden einfach als
Sortierkriterium verwendet und bieten Ihnen einen klareren Überblick beim Anlegen einer
Query im BEx Query Designer.
Nach der Migration in die SAP-HANA-Datenbank befinden sich normale Standard-InfoCubes
im spaltenbasierten Speicher der SAP HANA-Datenbank und haben einen logischen Index
(CalculationScenario). In der Analyse verhalten sie sich wie BWA-indizierte InfoCubes.
Wenn die InfoCubes Datenpersistenz im BWA haben, wird der Inhalt während der
Systemmigration nach SAP HANA gelöscht und die InfoCubes auf inaktiv gesetzt. Wenn Sie
einen dieser InfoCubes als Standard-InfoCube weiterverwenden möchten, müssen Sie ihn
erneut aktivieren und die Daten aus der früheren primären Persistenz (z.B. DataStore-Objekt)
erneut laden.
Wenn Sie InfoCubes für die Umwandlung in Prozessketten integriert haben, besteht keine
Notwendigkeit, die Prozessketten zu ändern. Bestimmte Prozesstypen sind veraltet, können
jedoch in der Prozesskette verbleiben, wenn eine SAP-HANA-Datenbank verwendet wird. Die
veralteten Prozesse haben keine Funktion, wenn eine SAP-HANA-Datenbank verwendet wird.
Das System überspringt sie einfach.
Lektion: Modellieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 99Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

108. Abbildung 98: Struktur des Advanced DataStore-Objekt (ADSO)
Das DataStore-Objekt (advanced) ist das zentrale Objekt der Datenspeicherung und
Datenkonsolidierung in SAP BW powered by SAP HANA.
Wenn die erforderlichen Eigenschaften entsprechend festgelegt werden, kann das DataStore-
Objekt (advanced) in verschiedenen Schichten des Data Warehouse verwendet werden. Zur
Vereinfachung der Modellierung des DataStore-Objekts (advanced) stellen wir Vorlagen
bereit, die zum Generieren der erforderlichen Eigenschaften verwendet werden können. Das
DataStore-Objekt (advanced) kann InfoObjects und Felder enthalten. Das bedeutet, Sie
können Daten in das BW-System laden, ohne InfoObjects zuordnen zu müssen. Sämtliche
Funktionen sind weiterhin verfügbar. Wegen des neuen Request-Managements ist das
DataStore-Objekt (advanced) gut für häufige Ladevorgänge und große Datenmengen
geeignet.
Das Advanced DSO (ADSO) besteht aus drei Kerntabellen, die beim Anlegen und Aktivieren
des ADSO im Hintergrund erzeugt werden. Die Tabellen werden abhängig von den gewählten
Modellierungsoptionen vom System verwendet. Unabhängig vom Anwendungsfall werden
diese drei Tabellen immer generiert, um zu einem späteren Zeitpunkt einen schnellen und
flexiblen Wechsel des Datenmodells zu ermöglichen.
Eingangstabelle (entspricht der Aktivierungs-Queue-Tabelle für Standard-DSO (klassisch)
oder der unkomprimierten Faktentabelle des nicht HANA-optimierten InfoCubes):
technischer Name /BIC/A<ADSO technischer Name>1.
Tabelle der aktiven Daten (entspricht DSO (klassisch) oder der komprimierten Faktentabelle
des nicht HANA-optimierten InfoCubes): technischer Name /BIC/A <ADSO technischer
Name>2.
Change Log (entspricht Standard-DSO (klassich)): technischer Name /BIC/A <ADSO
technischer Name>3.
Die Daten werden zunächst in die Eingangstabelle geladen. Die Daten werden entweder direkt
aus der Eingangstabelle ausgelesen, oder sie werden zuerst aktiviert und dann aus der Tabelle
der aktiven Daten gelesen. Dies hängt davon ab, wie die Daten verwendet werden. Das
Change Log enthält den Änderungsverlauf für das Delta-Update vom ADSO zu anderen
Datenzielen.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 100Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

109. Abbildung 99: ADSO mit Funktionen und Services eines InfoCubes anlegen
Sie können das DataStore-Objekt (advanced) in verschiedenen Data-Warehouse-Schichten
verwenden, indem Sie die erforderlichen Vorlagen oder die gewünschten Eigenschaften
selektieren.
Die Vorlagen sind nach zwei Aspekten strukturiert: nach Data-Warehouse-Schicht und nach
klassischen BW-InfoProvidern. Wenn Sie mit den klassischen BW-InfoProvidern vertraut sind
und mit der Modellierung für das DataStore-Objekt (advanced) arbeiten möchten, können Sie
Ihre Vorlage aus der Kategorie der klassischen Objekte auswählen. Wenn Sie mit der
Schichtenarchitektur arbeiten möchten, können Sie Ihre Vorlage aus der Kategorie
„Enterprise Data Warehouse Architecture“ auswählen.
Hier finden Sie Vorlagen für folgende schichten:
●Datenbereitstellungsschicht/Persistent Staging Area
●Corporate Memory:
-Corporate Memory
-Corporate Memory mit Komprimierung
-Corporate Memory mit Komprimierung und Delta-Ladeprozess
●Datenpropagationsschicht
●Reporting-Schicht:
-Reporting nur zu aktiven Daten
-Reporting zu aktiven Daten und Eingangs-Queue
Lektion: Modellieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 101Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

110. Abbildung 100: ADSO-Modellvorlagen und Modellierungseigenschaften
Wenn Sie die Eigenschaft „Alle Merkmale sind Schlüssel, Reporting für Union von Eingangs-
und aktiver Tabelle“ auswählen, werden alle Merkmale in dem Schlüssel einbezogen. Das
System greift in der Query auf die Eingangstabelle und die aktive Tabelle zu (mittels Union
über beide Tabellen). In diesem Fall sollten Sie nur additive Deltas laden. Die Daten werden
aggregiert. Die Eigenschaften sind mit dem InfoCube vergleichbar.
Abbildung 101: ADSO mit Funktionen und Services eines InfoCubes
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 102Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

111. Die Eingangstabelle entspricht der F-Tabelle des InfoCubes, die aktive Datentabelle entspricht
der E-Tabelle.
Das Reporting für diese Art von DataStore-Objekt ist konsistent und bietet eine stabile
Navigation. Eine Query kann direkt nach dem Laden ausgeführt werden. Sie brauchen sie
nicht vorher zu komprimieren. Sie müssen Deltas laden, z.B. aus einem anderen DataStore-
Objekt (advanced). Die Daten werden aggregiert. Daher es z.B. nicht möglich, Kennzahlen zu
überschreiben. Da das Change Log nicht gefüllt ist, können Sie keine Daten aus dem
DataStore-Objekt löschen.
Beim Ausführen einer Query wird auf die aktive Tabelle und die Eingangstabelle zugegriff en.
Abbildung 102: ADSO-Verwaltungsfunktionen
Die Modellierung von Objekten erfolgt komplett in den BW-Modellierungstools (BWMT) von
SAP HANA Studio. Die Verwaltung des zugehörigen Datenflusses und die Ladeüberwachung
sind noch vollständig in die BW DataWarehousing Workbench integriert. Sie arbeiten
weiterhin mit der Funktion „Administrieren“ in der DataWarehousing Workbench von SAP
BW. Hier können Sie administrative Aufgaben durchführen, z.B. Requests löschen, Daten
anzeigen und Transformationen aus dem bzw. in das ADSO anlegen.
Das Advanced DSO basiert auf einem neuen BW-Request-Management. Dieses neue
Request-Management überwindet die Einschränkungen der derzeitigen klassischen Request-
Logik, vor allem im Bereich hoher Ladefrequenzen, bei den Obergrenzen von Requests, bei
der Auswirkung auf die Performance des Datenladeprozesses, bei der Archivierung von
Requests sowie bei Routineaufgaben Das neue Request-Management hat eine neue
Verwaltungsoberfläche, die in die DataWarehousing Workbench integriert ist.
Mit der neuen TransaktionRSOADSOstehen Ihnen darüber hinaus folgende Support-
Funktionen zur Verfügung:
Lektion: Modellieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 103Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

112. ●Anzeigedaten
●Datenmodell anzeigen
●Datenmodell überprüfen und aktivierem
●Objektverzeichniseintrag
●Transportauftrag schreiben
●Verwendungsnachweis
Advanced DSOs sind wie andere InfoProvider als Quelle oder Ziel für BW-
Transformationsregeln verfügbar. Darüber hinaus können Sie in Transformationsregeln einen
Lookup für eine Advanced ADSO nach Merkmalswerten als neuen Regeltyp „Lesen aus
DataStore (Advanced)“ definieren.
Abbildung 103: Advanced DataStore-Objekt anlegen (InfoCube-artig) – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Advanced DataStore-Objekte modellieren
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 104Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

113. Kapitel 3
Lektion 4
Anlegen eines Datenflusses für
Bewegungsdaten
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion erfahren Sie, wie ein Datenfluss für Bewegungsdaten angelegt wird.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Einen Datenfluss für Bewegungsdaten anlegen
Bewegungsdaten in ein DataStore-Objekt (advanced) laden
Abbildung 104: Datenfluss in SAP BW auf HANA mit Operational Data Provisioning
Geschäftsanwendungen legen in der Regel die operativen Daten in Form von
Geschäftsbelegen und Stammdaten ab. In SAP NetWeaver BW ermöglichen DataSources und
deren Extraktoren den Zugriff auf diese Daten. Die DataSources liefern eine flache
Analysesicht auf die Daten in Geschäftsbelegen (z.B. Kundenaufträge oder Bestellungen). Sie
enthalten die Geschäftslogik, mit der aus der Bewegungsdaten-Sicht eine Analysesicht
abgeleitet wird. Es gibt verschiedene Arten von DataSources: DataSources für
Bewegungsdaten, Stammdatenattribute, Stammdatentexte und Stammdatenhierarchien.
Bisher wurden DataSources verwendet, um Massendaten aus dem operativen System in das
Data Warehouse von SAP NetWeaver, SAP NetWeaver BW, zu replizieren. Hier werden die
Daten aus verschiedenen Quellen integriert, konsolidiert und für OLAP-Analysen verfügbar
©Copyright. Alle Rechte vorbehalten. 105Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

114. gemacht. OLAP-Analysen in BW basieren jedoch nicht direkt auf DataSources. Sie basieren
auf InfoProvidern. InfoProvider bieten eine Sicht auf einen Datensatz aus verschiedenen,
semantisch verknüpften DataSources (z.B. Bestelldaten, Kundendaten oder Produktdaten).
Mit Operational Data Provisioning liefert SAP NetWeaver ein Metadatenkonzept, das
analytische Abfragen im operativen System für OLAP-Analysen sowie Replikationsszenarien
(einschließlich ETL-Service mit Delta-Mechanismus) ermöglicht. Das Operational Data
Provisioning wird in einer Modellierungsumgebung implementiert, die zusammen mit der
Suche verwendet wird. Es bietet eine Metadaten-View, in der eine DataSource analytische
Eigenschaften bekommen kann, um einen Operational Data Provider (ODP) zu definieren. Ein
Operational Data Provider kann verwendet werden, um auf Daten für die Replikation in
verschiedenen Konsumenten (z.B. BWA oder SAP BusinessObjects Data Services) und für
Zwecke der Operational Analytics zuzugreifen. DataSources sind für Operational Analytics
nicht geeignet, da sie zu einfach sind. Eine DataSource für Bewegungsdaten erkennt die
zugeordneten Stammdatenattribute nicht und die DataSource für Stammdatenattribute
erkennt die zugehörigen Texte nicht. Das Operational Data Provisioning verwendet hierbei
ODPs, damit semantisch verwandte DataSources als InfoProvider fungieren können, sodass
die Daten der Analytic Engine in einem Operational Analytics-Szenario ohne Replikation an
SAP NetWeaver BW zur Verfügung stehen.
Abbildung 105: InfoPackages und Datentransferprozesse
Das Operational Data Provisioning stellt eine technische Infrastruktur zur Verfügung, mit der
zwei verschiedene Anwendungsszenarien unterstützt werden können. Das erste Szenario ist
Operational Analytics zur Entscheidungsfindung in operativen Geschäftsprozessen. Die
zweite Szenarion ist die Datenextraktion und -replikation.
●Operational Analytics
Mit Operational Analytics können Sie OLAP-Analysen der Anwendungsdaten lokal im
Anwendungssystem durchführen. Für Operational Analytics brauchen Sie nur eine
minimale Konfiguration des BW in Ihrem Anwendungssystem und müssen kein Data
Warehouse einrichten. Eine Replikation der Daten auf ein BW-System ist nicht erforderlich.
Auf die Applikationsdaten kann direkt zugegriff en werden. Die Analyse-Performance kann
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 106Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

115. durch die Verwendung von SAP HANA oder SAP NetWeaver BW Accelerator verbessert
werden.
●Datenextraktion und -replikation
Neben der Indizierung von Daten in SAP HANA oder SAP NetWeaver BW Accelerator
können Sie mit Operational Data Provisioning für andere externe Konsumenten wie SAP
BusinessObjects Data Services Daten bereitstellen. Hier werden auch Delta-Mechanismen
unterstützt.
Ohne Operational Data Provisioning befindet sich die Delta-Queue im Quellsystem. Das Delta
kann über die InfoPackage in die BW Persistent Staging Area (PSA) geladen werden. Anschließend lädt der Datentransferprozess das Delta in den InfoProvider.
Mit Operational Data Provisioning befindet sich die Delta-Queue stark komprimiert im
Quellsystem. Das Delta kann mit dem Datentransferprozess direkt in den BW InfoProvider
geladen werden.
Abbildung 106: Operational-Delta-Queue im Einsatz
Eine Delta-Queue ist ein Datenspeicher im Quellsystem. Datensätze werden entweder
automatisch mit einem Fortschreibungsprozess im Quellsystem in die Delta-Queue
geschrieben (z.B. 2LIS_11_VAITM) oder mit der Extraktorschnittstelle
(z.B. 0COSTCENTER_ATTR) abgerufen.
Die Rolle eines Providers ist die Bereitstellung mindestens einer Delta-Queue von einem
bestimmten Typ. Die BW-DataSource ist beispielsweise ein Provider. In diesem Fall stimmt
der Name der Delta-Queue mit dem Namen der DataSource überein (z.B. 2LIS_11_VAITM).
Die Zielanwendung der Delta-Queue wird als „Abonnent“ bezeichnet (z.B. eines bestimmten
Datendienstsystems). Ein Abonnement kann wie folgt definiert werden: Ein bestimmter
Abonnent fordert von mindestens einer Queue Datenänderungen an und fährt mit der Verarbeitung der übertragenen Daten fort. Abonnenten werden durch ihren Abonnementtyp
kategorisiert (z.B. SAP BusinessObjects Data Services). Ein Abonnement erfolgt, wenn der
Abonnent Daten anfordert. Jedes Abonnement hat eine eindeutige Transaktionsnummer, z.B.
(2010-10-22 08:03:52 000001 CET). Ein Abonnent kann mehrere Abonnements haben. Eine
Queue kann auch in mehreren Abonnements desselben Abonnenten vorkommen.
Die Daten werden in der Delta-Queue komprimiert abgelegt. Ein Delta-Request überträgt die
Datensätze aus der Queue an den Abonnenten. Die Datenänderungen für eine Queue können
auch von mehreren Abonnenten angefordert werden. Ein Abonnent kann auch Daten aus
Lektion: Anlegen eines Datenflusses für Bewegungsdaten
©Copyright. Alle Rechte vorbehalten. 107Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

116. einer Queue in Form eines einmaligen Requests (Full) anfordern. In diesem Fall stellt der
Request kein Abonnement dar.
Die Daten werden für eine bestimmte Zeitspanne zu Wiederherstellungszwecken in der Delta-
Queue gehalten, d.h., falls der Abonnent die Datensätze erneut abrufen muss.
Abbildung 107: Operational-Delta-Queue im Einsatz
Der Delta-Queue-Monitor (TransaktionODQMON) ermöglicht das Überwachen der Delta-
Queues in den folgenden Views:
●Queues
Hier sehen Sie alle Queues, die im System verfügbar sind, mit dem jeweiligen Status, der
Anzahl der zugehörigen Abonnements und der Anzahl der zugehörigen Requests.
●Abonnements
Diese View zeigt die ausführlichen Informationen zur Abonnementstufe an.
●Requests
Diese View zeigt die ausführlichen Informationen zur Requeststufe an.
●Einheiten
Diese View zeigt die Einheiten an, in denen die Daten eines Requests gemeinsam
übertragen werden können.
Um auf die Views zuzugreifen, verwenden Sie die Drucktasten oder das MenüMonitor.
Die Informationen in der Delta-Queue können auf verschiedene Weise eingeschränkt werden:
●Vorselektion im Monitor
Sie können im oberen Bereich des Monitorbilds die in der Queue angezeigten Daten
einschränken, indem Sie verschiedene Kriterien verwenden. Dadurch wird die Leistung des
Monitors verbessert.
●Provider-basierte Einschränkung
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 108Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

117. Wenn Sie einen bestimmten Provider (z.B. BW DataSources) auswählen, werden im
Monitor nur die Queues angezeigt, die zu diesem Provider gehören. Abonnenten, die keine
Queues dieses Providers abonniert haben, werden nicht angezeigt. Wenn Sie keinen
Provider auswählen, werden im Monitor alle Queues aller Provider angezeigt.
●Queue-basierte Einschränkung
Wenn Sie eine bestimmte Queue angeben, z.B. eine DataSource, wird nur diese bestimmte
Queue im Monitor angezeigt. Bei der Angabe einer Queue können Sie den Platzhalter *
(z.B. 0FI*) verwenden, um die Monitoranzeige auf mehrere Queues zu beschränken. Wenn
Sie keine Queue angeben, wird die Monitoranzeige nicht eingeschränkt.
●Einschränkung durch Abonnententyp
Wenn Sie einen bestimmten Abonnententyp auswählen, z.B. SAP BusinessObjects Data
Services, werden im Monitor nur die Queues angezeigt, die von einem Abonnenten dieses
Typs abonniert wurden. Wenn Sie keinen Abonnententyp auswählen, werden im Monitor
alle Queues aller Abonnententypen angezeigt.
●Abonnenten-basierte Einschränkung
Wenn Sie einen bestimmten Abonnenten angeben, z.B. ein Datendienstsystem, wird nur
dieser bestimmte Abonnent im Monitor angezeigt. Bei der Angabe eines Abonnenten
können Sie den Platzhalter * (z.B. SAP*) verwenden, um die Monitoranzeige auf mehrere
Abonnenten zu beschränken. Wenn Sie keinen Abonnenten angeben, wird die
Monitoranzeige nicht eingeschränkt.
Diese Einstellungen werden angewendet, wenn Sie zwischen Monitorviews wechseln.
Abbildung 108: Szenario - Bewegungsdaten von ECC zu einem ADSO laden
Die Abbildung zeigt unser Szenario unter Verwendung von Operational Data Provisioning mit
der DataSource0CO_OM_CCA_9.
Lektion: Anlegen eines Datenflusses für Bewegungsdaten
©Copyright. Alle Rechte vorbehalten. 109Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

118. Abbildung 109: Einrichten des Datenflusses
Die Abbildung zeigt unser Szenario, bei dem eine Transformation von der DataSource
0CO_OM_CCA_9zu dem ADSO eingerichtet wird.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 110Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

119. Abbildung 110: Datenvorschau von U##_ADSOA
Die Abbildung zeigt die Datenvorschau sowie den Speicherverbrauch und die Anzahl der
Einträge für die Eingangstabelle des ADSO.
Lektion: Anlegen eines Datenflusses für Bewegungsdaten
©Copyright. Alle Rechte vorbehalten. 111Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

120. Abbildung 111: Bewegungsdaten in ein DataStore-Objekt (advanced) laden – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Einen Datenfluss für Bewegungsdaten anlegen
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 112Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

121. Kapitel 3
Lektion 5
Anlegen eines Advanced DataStore-Objekts
(wie klassisches DSO) und Laden von Daten
aus einer Flatfile-DataSource
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion werden DataStore-Objekte (advanced) und DataStore-Objekte (klassisch)
erläutert. Darüber hinaus erfahren Sie, wie Sie eine Flatfile-DataSource anlegen. Weiterhin
erfahren Sie, wie Daten aus einer Flatfile-DataSource in das DataStore-Objekt (advanced)
geladen werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Ein Advanced DataStore-Objekt anlegen (wie klassisches DSO) und Daten aus einer
Flatfile-DataSource laden
●Daten aus einer Flatfile-DataSource in das DataStore-Objekt (advanced) laden
●Daten in einem DataStore-Objekt (advanced) aktivieren und fortschreiben
Standard-DSO (klassisch)
Abbildung 112: Klassisches DataStore-Objekt: Eine vereinfachte funktionale Sicht
In einem DataStore-Objekt werden konsolidierte und bereinigte Daten (Bewegungsdaten oder
Stammdaten) auf Dokumentenebene (atomarer Ebene) gespeichert. In DataStore-Objekten
©Copyright. Alle Rechte vorbehalten. 113Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

122. können zwar Stammdaten gespeichert werden, und dafür gibt es gute Gründe, jedoch werden
in erster Linie detaillierte Bewegungsdaten in diesen Objekten gespeichert. Die Abbildung
„Klassisches DataStore-Objekt: Eine vereinfachte funktionale Sicht“ zeigt die Position von
DataStore-Objekten im Warehouse-Gesamtdesign. Sie können zur Unterstützung des
detaillierten operativen Reportings eingesetzt werden oder Teil des Warehouse sein, wo sie
eventuell benötigte Daten zu mehreren Jahren speichern können.
Ein DataStore-Objekt ist wie eine Tabelle aufgebaut. Es enthält Schlüsselfelder
(beispielsweise Belegnummer und Position) und Datenfelder. Datenfelder können alle Arten
von InfoObjects wie Kennzahlen, Einheiten, Zeitmerkmale und auch Merkmalfelder sein (zum
Beispiel Auftragsstatus, Kunde oder Uhrzeit). Es ist wichtig, die Schlüsselfelder so zu
definieren, dass Sie Ihre Belege eindeutig identifizieren können.
Ein DataStore-Objekt, das Fakturainformationen auf Kopf- oder Positionsebene enthalten soll,
enthält als Schlüsselfelder nur die InfoObject-Faktura- und Fakturapositionsnummer. Alle
anderen Objekte, wie Kunde, Material und Erlös, müssen als Datenfelder modelliert werden.
Es kann sein, dass die Abhängigkeiten nicht einfach zu modellieren sind, wenn beispielsweise
die Daten nicht im DataStore-Objekt auf Beleg- oder Belegzeilenebene fortgeschrieben
werden sollen. In diesem Fall ist es sinnvoll, diese Beziehungen mithilfe eines Entity
Relationship Models abzuleiten.
Klassisches DataStore-Objekt (DSO)
●Entwickelt zum Sichern von bereinigten Daten auf Dokumentenebene:
-Konsolidierung oder überschrieben
●Überschreibefunktion:
-
Merkmale, die nicht im Datensatzidentifikator (Schlüssel) enthalten sind,
überschreiben immer (wie zum Beispiel Auftragsstatus).
-Für Kennzahlen (zum Beispiel Absatzmenge oder Anzahl der Belegzeilen) kann
Überschreiben, Hinzufügen oder nicht fortschreiben festgelegt werden.
●Reporting per BEx:
-Direktes Reporting ist optional (verwendet für DataStore-Objekte, die sich im Abschnitt
„Operations DataStore“ befinden).
-Kann für DataStore-Objekte aufgehoben werden, die zum Staging und für reine
Datenspeicherungsfunktionen im Warehouse-Abschnitt Ihrer Architektur verwendet
werden.
-Benutzern wird keine Reporting-Berechtigung für diese DataStore-Objekte gewährt.
-Normale Reporting-Szenarios umfassen einen Aufriss vom InfoCube zum DataStore-
Objekt.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 114Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

123. Abbildung 113: Schema eines klassischen Standard-DataStore-Objekts
Standard-DataStore-Objekte bestehen aus den folgenden drei Tabellen:
●Tabelle der aktiven Daten
In dieser Tabelle ist der aktuelle Zustand der Daten abgelegt. Die Tabelle enthält einen
semantischen Schlüssel (betriebswirtschaftlich sinnvoll), der vom Modellierer definiert
werden kann (z. B. Auftragsnummer, Position, Einteilung). Es ist wichtig, dass der
Modellierer den Schlüssel richtig definiert, da in der Aktivierungsphase ein
übereinstimmender Schlüssel eine besondere Delta-Verarbeitung initiiert (wird später
behandelt). Beim Reporting über den Data Manager wird diese Tabelle ebenfalls
verwendet.
●Change-Log-Tabelle
Während der Aktivierung werden Änderungen im Change Log gespeichert. In dieser
Tabelle finden Sie die gesamte Historie der Änderungen, da der Inhalt des Change Logs
nicht automatisch gelöscht wird. Werden angeschlossene Datenziele im Deltaverfahren
aus dem DataStore-Objekt mit Daten versorgt, so werden diese aus dem Change Log
fortgeschrieben. Das Change Log ist eine PSA-Tabelle und auch im PSA-Baum der Data
Warehousing Workbench pflegbar. Dementsprechend besitzt das Change Log wiederum
einen technischen Schlüssel aus Request-, Datenpaket- und Datensatznummer.
●Aktivierungs-Queue-Tabelle
Während des DTP werden die Datensätze zuerst in diese Tabelle geschrieben.
Anschließend werden die Datensätze während des Aktivierungsprozesses in die aktive
Datentabelle und die Change-Log-Tabelle geschrieben.
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 115Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

124. Abbildung 114: Daten in die Eingangstabelle eines ADSO mit Funktionen und Services eines Standard-DSO
(klassisch) laden
Abbildung 115: Beispiel für die Datenaktivierung im ADSO
Der Aktivierungslauf (Aktivieren der Daten in der Aktivierungs-Queue, damit diese verwendet
werden können) kann automatisch als Teil der Prozesskette ausgelöst oder auch manuell
gestartet werden. Zu Beginn des Aktivierungslaufes werden die Daten sortiert. Dies geschieht
in erster Linie nach dem semantischen Schlüssel des DataStore-Objekts (d. h. der Tabelle mit
den aktiven Daten). Anschließend werden die Daten entsprechend dem technischen
Schlüssel der Aktivierungs-Queue sortiert. Dies entspricht der Upload-Reihenfolge der
verschiedenen Datensätze. Durch die Sortierreihenfolge wird sichergestellt, dass die
Aktivierung parallel ausgeführt werden kann. Der Grund ist, dass alle Datensätze, die zum
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 116Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

125. gleichen semantischen Schlüssel gehören, nicht auf mehrere Prozesse verteilt werden. Die
Anzahl der zu aktivierenden Datensätze bestimmt, wie viele Aktivierungsprozesse gestartet
werden. Dabei ist einstellbar, ob die Prozesse parallel oder nacheinander ablaufen sollen.
Der Benutzer kann wählen, ob die durch die verschiedenen Lade-Requests hervorgerufenen
Änderungen in einem Change-Log-Request zusammengefasst werden sollen, oder ob für
jeden geladenen Request auch ein Change-Log-Request generiert wird. Ähnlich, wie ein Lade-
Request erkennt, wenn Datensätze geladen werden, erkennt ein Change-Log-Request, wenn
die Datensätze aktiviert und aus der Aktivierungs-Queue in ein Change Log verschoben
wurden. Dies sollte in der Regel mindestens einmal in der Nacht geschehen. Diese Einstellung
wird im Aktivierungsbild (Kontextmenü eines DataStore-Objekts) unter „Requests beim
Aktivieren nicht in einem Request kondensieren“ angezeigt.
Abbildung 116: Beispiel für die Datenaktivierung im ADSO (2)
In diesem Beispiel wurde ein Verkaufsbeleg 4711 mit einem Wert von 10 geladen und zum
DSO aktiviert. Der Beleg 4711 wurde im Quellsystem geändert und erneut geladen. Während
der Aktivierung erkennt das System, dass der Schlüssel bereits vorhanden ist. Daher muss es
den Wert in der aktiven Datentabelle überschreiben. In der Change-Log-Tabelle wird jeder
Schritt protokolliert, d.h. der alte Wert von 10 wird ausgebucht und der neue Wert von 30
eingebucht. Nach der Aktivierung wird der Request in der Eingangstabelle gelöscht
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 117Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

126. Abbildung 117: Drei verschiedene Typen von klassischen DataStore-Objekten
In SAP BW wird zwischen drei DataStore-Objekttypen unterschieden: Standard,
schreiboptimiert und direkte Fortschreibung. Diese drei Typen von DataStore-Objekten
werden in der Tabelle „Drei verschiedene Typen von DataStore-Objekten“ dargestellt.
Das Standard-DataStore-Objekt ist vollständig in den Stagingprozess integriert. Mit anderen
Worten, Daten können während des Stagingprozesses in die DataStore-Objekte und aus
diesen geladen werden. Alle Änderungen werden in das Change Log geschrieben und stehen
in Form von Delta-Uploads für angeschlossene Datenziele zur Verfügung. Da das
schreiboptimierte DataStore-Objekt nur aus der Tabelle der aktiven Daten besteht, entfällt die
beim Standard-DataStore-Objekt nötige Aktivierung der Daten. Dies bedeutet, dass Sie Daten
schneller verarbeiten können.
Es findet keine Aggregation der geladenen Daten statt; die Historie der Daten bleibt erhalten.
Werden zwei Datensätze mit gleichem logischen Schlüssel aus der Quelle extrahiert, so
werden beide Sätze im DataStore-Objekt gespeichert. Der für die Aggregation
verantwortliche Record Mode bleibt jedoch erhalten, sodass die Aggregation der Daten zu
einem späteren Zeitpunkt in Standard-DataStore-Objekten stattfinden kann.
Das System generiert für das schreiboptimierte DataStore-Objekt einen eindeutigen technischen Schlüssel. Die Standard-Schlüsselfelder sind bei diesem Typ von DataStore- Objekt nicht erforderlich. Wenn ohnehin Standard-Schlüsselfelder vorhanden sind, so werden
sie zur Unterscheidung von den technischen Schlüsseln semantische Schlüssel genannt. Der
technische Schlüssel besteht aus den Feldern für Request-GUID (0REQUEST), Datenpaket
(0DATAPAKID) und Datensatznummer (0RECORD). Zu diesem Schlüssel werden nur neue
Datensätze geladen.
Sie können angeben, dass Sie keine Überprüfung durchführen möchten, um sicherzustellen,
dass die Daten eindeutig sind. Wenn Sie die Eindeutigkeit der Daten nicht überprüfen, kann
die Tabelle des DataStore-Objekts mehrere Sätze mit demselben Schlüssel enthalten. Wenn
Sie dieses Kennzeichen nicht setzen und die Eindeutigkeit prüfen lassen, wird ein eindeutiger
Index im semantischen Schlüssel des InfoObjects generiert. Dieser Index hat den technischen
Namen „KEY“. Da das schreiboptimierte DataStore-Objekt nicht über ein Change Log verfügt,
generiert das System kein Delta (als Before- und After-Images). Beim Fortschreiben der
Daten in angeschlossene InfoProvider werden nur Requests fortgeschrieben, die dort noch
nicht verbucht sind.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 118Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

127. Ein DataStore-Objekt vom Typ „direkte Fortschreibung“ (früher 3.x transaktionales DSO)
umfasst nur die Tabelle mit aktiven Daten. Das bedeutet, es kann nicht so einfach in den
Stagingprozess integriert werden. Stattdessen wird dieser Typ von DataStore-Objekten durch
APIs gefüllt und kann über ein BAPI gelesen werden. DataStore-Objekte für direkte
Fortschreibung werden in der Regel in Business-Consolidation-Systemen verwendet, um
rechtliche Investitionsstrukturen zu speichern, die im Monatsabschlussprozess eingesetzt
werden. Darüber hinaus können DSO zur Planung in SAP Planning and Consolidation und der
integrierten Planung verwendet werden.
Abbildung 118: ADSO mit Funktionen und Services eines Standard-DSO (klassisch) anlegen
Das DataStore-Objekt (advanced) ist das zentrale Objekt der Datenspeicherung und
Datenkonsolidierung in SAP BW powered by SAP HANA.
Wenn die erforderlichen Eigenschaften entsprechend festgelegt werden, kann das DataStore-
Objekt (advanced) in verschiedenen Schichten des Data Warehouse verwendet werden. Zur
Vereinfachung der Modellierung des DataStore-Objekts (advanced) stellen wir Vorlagen
bereit, die zum Generieren der erforderlichen Eigenschaften verwendet werden können. Das
DataStore-Objekt (advanced) kann InfoObjects und Felder enthalten. Das bedeutet, Sie
können Daten in das BW-System laden, ohne InfoObjects zuordnen zu müssen. Sämtliche
Funktionen sind weiterhin verfügbar. Dank des neuen Request-Managements ist das
DataStore-Objekt (advanced) besonders gut für häufige Ladevorgänge und große
Datenmengen geeignet.
Sie können das DataStore-Objekt (advanced) in verschiedenen Data-Warehouse-Schichten
verwenden, indem Sie die erforderlichen Vorlagen oder die gewünschten Eigenschaften
selektieren.
Die Vorlagen sind nach zwei Aspekten strukturiert: nach Data-Warehouse-Schicht und nach
klassischen BW-InfoProvidern. Wenn Sie mit den klassischen BW-InfoProvidern vertraut sind
und mit der Modellierung für das DataStore-Objekt (advanced) arbeiten möchten, können Sie
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 119Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

128. Ihre Vorlage aus der Kategorie der klassischen Objekte auswählen. Wenn Sie mit der
Schichtenarchitektur arbeiten möchten, können Sie Ihre Vorlage aus der Kategorie
„Enterprise Data Warehouse Architecture“ auswählen.
Hier finden Sie Vorlagen für folgende schichten:
●Datenbereitstellungsschicht/Persistent Staging Area
●Corporate Memory:
-Corporate Memory
-Corporate Memory mit Komprimierung
-Corporate Memory mit Komprimierung und Delta-Ladeprozess
●Datenpropagationsschicht
●Reporting-Schicht:
-Reporting nur zu aktiven Daten
-Reporting zu aktiven Daten und Eingangs-Queue
Abbildung 119: ADSO mit Funktionen und Services eines Standard-DSO (klassisch)
Wenn Sie ein ADSO mit den Funktionen und Services eines Standard-DSO (klassisch)
anlegen, besitzt es dieselben drei Tabellen wie das Standard-DSO (klassisch).
In der Regel werden die Daten in die Eingangstabelle geschrieben. Wenn Sie „Daten
aktivieren“ wählen, werden die Daten (während des Aktivierungs- und
Komprimierungsvorgangs) in die Tabelle für aktive Daten geschrieben, sobald sie in der
Eingangstabelle eintreffen.
Es gibt drei Optionen:
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 120Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

129. ●Change Log schreiben
Wenn Sie diese Option wählen, wird das Delta (neue und geänderte Datensätze) im
Change Log abgelegt. Das Change Log wird verwendet, um das Delta zu extrahieren. Sie
können nur Daten aus dem DataStore-Objekt löschen, wenn das Objekt über ein Change
Log verfügt.
●Eingangsdaten behalten und aus Eingangstabelle extrahieren
Wenn Sie diese Option wählen, werden keine Daten im Change Log abgelegt. Der
Extraktionsprozess liest die Daten immer wieder in der Eingangstabelle, sowohl bei der
Delta-Extraktion als auch bei der vollständigen Extraktion.
●Eindeutige Datensätze
Diese Eigenschaft können Sie auswählen, wenn Sie nur eindeutige Datensätze (Datensätze
mit nicht wiederkehrenden Tastenkombinationen) in das DataStore-Objekt laden. Das
System prüft also nicht, ob der Datensatz bereits vorhanden ist. Sie müssen sicher sein,
dass keine doppelten Datensätze geladen werden. Dies bedeutet, dass die Tabelle der
aktiven Daten nur eindeutige Datensätze enthält. Eine Datenaggregation ist nicht zulässig.
Abbildung 120: ADSO mit Funktionen und Services eines schreiboptimierten DSO (klassisch)
Wenn Sie ein ADSO mit den Funktionen und Services eines schreiboptimierten DSO
(klassisch) anlegen, hat es dieselbe Eingangstabelle wie das schreiboptimierte DSO
(klassisch).
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 121Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

130. Abbildung 121: In-Memory-optimierte DSO - Merkmale des neuen Konzepts
SAP HANA besitzt verschiedene Engines, um die Berechnungslogik zu verarbeiten und
Programmcode auszuführen. Damit besteht die Möglichkeit, datenintensive Berechnungen
aus der ABAP-Anwendungsschicht in die SAP-HANA-Datenbank zu verlagern.
Aus diesem Grund wurde SAP ABAP mit SAP NetWeaver 7.30 und 7.40 erweitert, um die
erweiterten In-Memory-Funktionen von SAP HANA zu nutzen.
Dies führt dazu, dass weniger Daten zwischen Anwendungsschicht und Datenhaltungsschicht
bewegt werden und bewirkt damit eine wesentlich bessere Ressourcennutzung. Der
Schwerpunkt der Anwendungsschicht liegt eher bei der Harmonisierung und dem Anstoßen
der Verarbeitung innerhalb der Datenbank. Am Ende kann in sehr kurzer Zeit komplexe Logik
verarbeitet werden, was zu großen Leistungsverbesserungen führt.
Die wichtigsten Konzepte der Software-Innovationen lassen sich wie folgt zusammenfassen:
●Die Logik wird zu den Daten transportiert (Code-Pushdown von der Anwendungsschicht
zur Datenhaltungsschicht).
●Zuerst erfolgt die Berechnung, dann werden nur die Ergebnisse bewegt.
SAP-Anwendungen sind erforderlich, um nicht nur SAP HANA, sondern alle für ABAP
zertifizierten Datenbanken zu unterstützen. Aus diesem Grund gibt es in SAP-HANA-
optimierten ABAP-Programmen eine Erweiterung. In einem Business Add-In (BAdI)
überprüfen diese Programme zuerst, ob die Datenbank vorhanden ist. Im Fall von SAP HANA
wird die optimierte Version ausgelöst. Anderenfalls wird der klassische ABAP-Ablauf
ausgeführt. Es gibt zwei Versionen bestimmter Prozesse auf der Anwendungsschicht.
Optimierter ABAP-Code bedeutet, dass die datenintensiven Teile des ursprünglichen ABAP-
Codes ersetzt werden. Diese Teile werden nach SAP HANA verschoben und dort als SQL-
Skript-Prozedur ausgeführt. SAP BW nutzt wie viele andere SAP-Produkte die Vorteile von
SAP HANA in beiden Dimensionen. So ist es eine einmalige Kombination aus Hardware- und
Softwareoptimierung auf dem neuesten Stand der Technik. Komplexe Algorithmen werden
direkt auf der Datenbank und nicht mehr auf der Anwendungsseite ausgeführt.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 122Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

131. Advanced DataStore-Objekt (wie klassisches DSO)
Abbildung 122: DataStore-Objekte (klassisch) – traditionelle DB versus HANA DB
Der Code-Pushdown führt dazu, dass weniger Daten zwischen Anwendungsschicht und
Datenhaltungsschicht bewegt werden und bewirkt damit eine wesentlich bessere
Ressourcennutzung. Bei den DataStore-Objekten erfahren Sie eine dramatische Zeitersparnis
zur Aktivierung der Daten. Selbst der Daten-Upload kann verkürzt werden, wenn HANA-
optimierte Routinen verwendet werden.
Zusammenfassung der wichtigsten Merkmale von ADSO
●Advanced DSOs dienen als zentrales Persistenzmodell für Bewegungssdaten in Ihrem
EDW auf der Grundlage von BW auf HANA.
●Sie unterstützen feldbasierte Modellierung und InfoObject-basierte Modellierung.
●Sie unterstützen hohe Datenladefrequenzen.
●Sie können bis zu 120 Schlüsselfelder (InfoObjects sowie Felder) enthalten.
●Sie werden in Eclipse-basierten SAP-BW-Modellierungswerkzeugen modelliert.
●ADSOs dienen als Persistenz für Open ODS Views.
●
ADSOs bieten benutzerdefinierte Partitionen und Indizes für Performance-relevante
Zugriffe.
●ADSOs werden sich weiterentwickeln, um die Funktionen von InfoCubes, DSOs (klassisch),
HybridProviders und PSA vollständig zu übernehmen.
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 123Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

132. Abbildung 123: Administration und Datenaktivierung für ADSO (wie DSO)
Der Aktivierungslauf (Aktivieren der Daten in der Aktivierungs-Queue, damit diese verwendet
werden können) kann automatisch als Teil der Prozesskette ausgelöst oder auch manuell
gestartet werden. Zu Beginn des Aktivierungslaufes werden die Daten sortiert. Dies geschieht
in erster Linie nach dem semantischen Schlüssel des DataStore-Objekts (d. h. der Tabelle mit
den aktiven Daten). Anschließend werden die Daten entsprechend dem technischen
Schlüssel der Aktivierungs-Queue sortiert.
Der Benutzer kann wählen, ob die durch die verschiedenen Lade-Requests hervorgerufenen
Änderungen in einem Change-Log-Request zusammengefasst werden sollen, oder ob für
jeden geladenen Request auch ein Change-Log-Request generiert wird. Ähnlich, wie ein Lade-
Request erkennt, wenn Datensätze geladen werden, erkennt ein Change-Log-Request, wenn
die Datensätze aktiviert und aus der Aktivierungs-Queue in ein Change Log verschoben
wurden.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 124Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

133. Abbildung 124: Advanced DataStore-Objekt anlegen (wie klassisches DSO) – Übung
Daten aus einer Flatfile-DataSource in das DataStore-Objekt (advanced) laden
Abbildung 125: Quellsysteme und Aufbereitungstechnologie für SAP BW
Sie können die folgenden Technologien verwenden, um Daten nach SAP BW zu laden:
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 125Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

134. ●Operational Data Provisioning (ODP)
Zum Bereitstellen von Daten mit Hilfe der Application Programming Interface (API) für die
ODP-Datenreplikation aus verschiedenen Quellen, z.B. SAP-ERP-Extraktoren, SAP BW,
SAP HANA Views, SAP Business ByDesign, SAP Landscape Transformation Replication
Server (SLT).
●BW Service API (S-API)
Die Service-API ist ein Technologiepaket in SAP-Quellsystemen von BW, die einen hohen
Integrationsgrad für die Datenübernahme aus den Quellsystemen in SAP BW ermöglicht.
Damit wird auch die Kommunikation zwischen den SAP-Quellsystemen und SAP BW
möglich. Die S-API ist als Teil der Softwarekomponente SAP Basis Plug-In im SAP-
Quellsystem installiert.
●DB Connect
Ermöglicht den Direktzugriff auf relationale Datenbanken. Über DB-Multi-Connect wird
eine Verbindung zum Datenbankmanagementsystem (DBMS) in der externen Datenbank
hergestellt. Über den Import von Metadaten und Originaldaten können die notwendigen
Strukturen in SAP BW generiert und die Daten auf einfache und effiziente Weise geladen
werden.
●UD Connect
Mit UD-Connect greifen Sie auf nahezu alle relationalen Datenquellen zu. Diese
Technologie läuft auf der J2EE-Engine und unterstützt die J2EE-Connector-Architektur.
●Dateischnittstelle
SAP BW unterstützt den automatischen Import von Dateien im CSV-, ASCII- und XLS-
Format für Flatfiles.
●Web-Services
Mit den Web-Services können Sie Daten unter externer Steuerung an SAP BW senden.
●SAP Data Services
Zur Verwendung der engen Integration von SAP Data Services bei der Aufbereitung von
Daten über BAPIs (Business Application Programming Interfaces).
●Staging-BAPIs
Staging BAPIs sind offene Schnittstellen, mit deren Hilfe SAP Data Services und
zertifizierte Third-Party-Tools Daten aus älteren Systemen extrahieren können. Der
Datentransfer kann durch einen Request von SAP BW, durch SAP Data Services oder
durch ein Third-Party-Tool angestoßen werden.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 126Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

135. Abbildung 126: Dateisystem-DataSource: Registerkarte „Extraktion“
In fast jedem Unternehmen ist es zu einem bestimmten Zeitpunkt erforderlich, ein Flatfile zu
laden. Dies kann beispielsweise bei einem Pilotprojekt der Fall sein, oder wenn Daten
eingekauft werden (eingekaufte Daten werden häufig in Form eines Flatfiles geliefert). Die
grundlegenden Begriff e sind dieselben, es werden aber erheblich mehr Funktionen
beleuchtet.
Der Hauptunterschied zwischen dem Laden aus einem SAP-Quellsystem und aus einem
externen System mit Flatfiles liegt in der DataSource. Für ein SAP-Quellsystem definieren Sie
die DataSource im Quellsystem und replizieren sie in SAP BW. Wenn Sie aus einem externen
System mit Flatfiles laden, definieren Sie die DataSource in SAP BW.
Beim Laden von externen Daten haben Sie die Möglichkeit, die Daten von einer beliebigen
Workstation in SAP BW zu laden. Aus Performance-Gründen sollten Sie jedoch die Daten auf
dem Anwendungsserver ablegen und von dort in SAP BW laden. Auf diese Weise können Sie
die Daten auch im Hintergrund laden. Falls Sie eine große Menge von Bewegungsdaten aus
einem Flatfile in SAP BW laden möchten und Sie den Dateityp des Flatfile bestimmen können,
sollten Sie das Flatfile als ASCII-Datei anlegen. Unter Performance-Gesichtspunkten ist das
Laden von Daten aus einer ASCII-Datei die kostengünstigste Methode. Das Laden aus einer
CSV-Datei nimmt mehr Zeit in Anspruch, da in diesem Fall die Trennzeichen und Escape-
Zeichen gesendet und interpretiert werden müssen. Unter bestimmten Umständen kann
jedoch die Erzeugung einer ASCII-Datei einen höheren Aufwand erfordern.
In den folgenden Abbildungen sind alle dateispezifischen DataSource-Bilder dargestellt. Das
Bild „Allgemeine Informationen“ wird nicht behandelt, da es allen DataSources gemein ist und
es, wie der Name erahnen lässt, Informationen zur Identifikation und weiteren grundlegenden
Aspekten liefert.
Dateien vom Typ Text enthalten nur Zeichen, die als Text angezeigt und gelesen werden
können. Beispiele für Textdateien sind CSV- und ASCII-Dateien. Bei CSV-Dateien muss ein
Zeichen angegeben werden, das die einzelnen Feldwerte trennt. In SAP BW müssen Sie ggf.
dieses Trennzeichen und ein Escape-Zeichen angeben, das dieses Zeichen als eine
Komponente des Werts definiert. Nachdem Sie diese Zeichen angegeben haben, müssen
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 127Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

136. diese in der Datei verwendet werden. ASCII-Dateien enthalten Daten mit einer festgelegten
Länge. Die definierte Feldlänge in der Datei muss der Länge des zugeordneten Felds in SAP
BW entsprechen. Beachten Sie neben den Informationen in der Dropdown-Box der Abbildung
auch das Routine-Symbol, das sich neben dem Namen der Datei befindet. Mit dieser Ikone
können Sie Programme erzeugen, die wiederum dynamisch den tatsächlichen Namen und
den Speicherort des Flatfiles erzeugen. Durch den Einsatz einer Programmlogik, die im
resultierenden Dateinamen den aktuellen Tag und das aktuelle Jahr verwendet (z. B.
01.2006_Vertrieb), können Sie vermeiden, dass dieselbe Datei zweimal geladen wird. Das ist
darin begründet, dass beim Laden im nächsten Monat, der Name der benötigten Datei auf
dem Server 02.2006_Vertrieb lauten müsste.
Achten Sie darauf, das Dateiformat korrekt zu definieren. SAP empfiehlt die Verwendung
einer Kopfzeile, da das System diese Kopfinformationen nutzen kann, um die Definition der
Felder in der Datei zu erleichtern.
Abbildung 127: Dateisystem-DataSource: Registerkarte „Vorschlag“
Bevor Sie Daten aus einem Dateiquellsystem übertragen können, müssen die Metadaten
(Datei- und Feldinformationen) in SAP BW in Form einer DataSource verfügbar sein. Im
Grunde genommen ist eine auf einem Flatfile basierende DataSource ein Objekt, das alle für
das Laden und Parsen (bei der Initiierung durch das InfoPackage) erforderlichen Einstellungen enthält.
In der folgenden Liste sind einige Funktionen des SAP-BW-Dateiadapters und von
dateibasierten DataSources aufgeführt:
●Automatische Feldvorschläge zur Designzeit
●Automatische Konvertierung von externen Datentypen und Formaten
●Vorschaufunktion ermöglicht Prüfung des Datei-Parsings
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 128Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

137. ●Felder können als „Nicht übernommen“ gekennzeichnet werden
Die RegisterkarteVorschlagliest die Kopfzeile und schlägt auf Grundlage der gefundenen
Informationen Feldnamen und -typen vor. Die vorgeschlagenen Feldnamen, -größen und -
typen können auf der zweiten wichtigen Registerkarte, der RegisterkarteFeldergeändert
werden.
Abbildung 128: Dateisystem-DataSource: Registerkarte „Felder“
Das AnkreuzfeldTransferund das Dropdown-MenüIntern/Externbefinden sich auf der
RegisterkarteFelderam äußersten rechten Rand der GUI. Über das AnkreuzfeldTransfer(das
sich auch bei anderen DataSource-Typen findet) wird festgelegt, ob das Feld in die PSA
übernommen wird. In vielen Fällen – insbesondere bei Datenquellen, auf die Sie nicht
vorbereitet sind – gibt es nicht benötigte Felder, die im Ladezyklus Speicher und Zeit in
Anspruch nehmen.
Der FormatschalterIntern/Externübermittelt dem Parsing-Programm die Informationen
darüber, ob sich die gesendeten Daten in dem Format befinden, das der Benutzer in der
Anwendung sieht, oder in dem Format, in der sie in der Datenbank abgelegt sind. Ein Beispiel
wäre eine Geschäftsperiode: 01.1999 (extern) und 1999001 (intern). Weiterhin müssen Sie
den Datentyp prüfen oder korrigieren, falls dieser vom System falsch vorgeschlagen wird.
Während des testweisen Ladens von Kostenstellen-Bewegungsdaten kann das System z.B.
den Datentyp RAW vorschlagen, obwohl es sich um ein simples CHAR-Feld handelt.
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 129Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

138. Abbildung 129: Dateisystem-DataSource: Registerkarte „Felder“ (2)
Da Fehler auf den RegisterkartenFeldoderExtraktionnegative Auswirkungen auf das Laden
Ihrer Daten haben können, ist es ratsam, eine Prüfung mit Echtdaten durchzuführen. Auf der
RegisterkarteVorschaukönnen Sie dies mit der von Ihnen angeforderten Anzahl von Sätzen
tun, nachdem Sie die DataSource aktiviert haben.
Abbildung 130: Administration: ADSO-Daten anzeigen
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 130Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

139. Abbildung 131: Plandaten aus einer Flatfile zu einem ADSO (Change-Log-artig) laden – Übung
Lektion: Anlegen eines Advanced DataStore-Objekts (wie klassisches DSO) und Laden von Daten aus einer Flatfile-DataSource
©Copyright. Alle Rechte vorbehalten. 131Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

140. Daten in einem DataStore-Objekt (advanced) aktivieren
Abbildung 132: Plandaten in einem Advanced DataStore-Objekt (wie DSO) überschreiben – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Ein Advanced DataStore-Objekt anlegen (wie klassisches DSO) und Daten aus einer
Flatfile-DataSource laden
●Daten aus einer Flatfile-DataSource in das DataStore-Objekt (advanced) laden
●Daten in einem DataStore-Objekt (advanced) aktivieren und fortschreiben
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 132Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

141. Kapitel 3
Lektion 6
Modellieren von CompositeProvidern
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in CompositeProvider. Darüber hinaus erfahren Sie, wie
Sie CompositeProvider anlegen und nutzen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●CompositeProvider anlegen
Modellieren von CompositeProvidern
Abbildung 133: Klassisches MultiProvider-Konzept
Ein MultiProvider ist ein spezieller InfoProvider, der Daten aus mehreren InfoProvidern
zusammenführt und sie gemeinsam für das Reporting zur Verfügung stellt. Der MultiProvider
enthält selbst keine Daten (wie InfoSets und VirtualProvider). Seine Daten ergeben sich
ausschließlich aus den zugrunde liegenden InfoProvidern. Die meisten Querys werden für
MultiProvider angelegt, die einen oder mehrere InfoCubes umfassen.
Eine Query kann nur auf einen einzelnen InfoProvider geschrieben werden. Ein MultiProvider
ist ein einzelner InfoProvider für eine Query, aber durch ihn kann indirekt auf mehrere
Provider zugegriff en werden. Wir haben einen InfoProvider mit Istdaten zu einem logisch in
sich geschlossenen betriebswirtschaftlichen Bereich sowie einen entsprechenden
InfoProvider mit Plandaten. Sie können die beiden InfoProvider zu einem MultiProvider
kombinieren, um Ist- und Plandaten in einer Query vergleichen zu können.
©Copyright. Alle Rechte vorbehalten. 133Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

142. Abbildung 134: Konsolidierung von BW-InfoProvidern
In einer klassischen BW-Umgebung sind MultiProvider die wichtigsten virtuellen InfoProvider.
Sie werden aus folgenden Gründen häufig verwendet:
●Schnittstelle für alle Reporting-Objekte (hauptsächlich BEx-Queries): Es ist möglich,
Reporting-Objekte von den persistenten InfoCubes der Data-Mart-Schicht zu entkoppeln.
Änderungen an InfoCubes schaden Ihrem Reporting nicht, solange die MultiProvider
unverändert bleiben.
●Die semantische Partitionierung von Data Marts kann in mehrere kleinere Einheiten
unterteilt werden. Diese werden durch die UNION-Funktionen der MultiProvider integriert.
Ihr Datenmodell ist damit wesentlich flexibler, und Lade- und Reportingprozesse können
parallel verarbeitet werden. Dies führt am Ende zu großen Performance-Gewinnen.
Wenn SQL Union nicht erforderlich ist, sondern stattdessen SQL Joins, stellen BW-InfoSets in einem klassischen SAP BW die einzige Alternative dar. Sie werden jedoch wegen der
Anforderungen bei der Pflege und insbesondere aufgrund von Performance-Problemen nur
selten verwendet. Der Grund dafür ist, dass sie während der Query-Laufzeit einen Join
durchführen, und dieser wird vom Anwendungsserver verarbeitet. Daher sind BEx-Queries
auf InfoSets sehr langsam.
Mit BW auf HANA ist dieses Dilemma endlich gelöst. MultiProvider sind HANA-optimiert, da
sie ihre SQL-Operationen auf SAP HANA statt auf der ABAP-Applikationsseite ausführen. Die
SQL-Union-Operationen wurden auf SAP HANA verlagert. Allerdings ist dies noch keine
Verbesserung in Bezug auf die Features.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 134Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

143. Abbildung 135: CompositeProvider
In einer SAP-BW-Umgebung ist es üblich, dass Sie Daten kombinieren, die aus verschiedenen
Quellen stammen. Dieses Kombinieren von Daten kann während des Stagingprozesses durch
Anreicherung von Daten und durch Persistenz des Anreicherungsergebnisses auf
Datenbankebene (in der Regel im DataStore-Objekt oder InfoCube) stattfinden, oder während
der Laufzeit der Query durch Ausführen einer Union- oder Join-Operation.
CompositeProvider bieten eine neue Art der Verknüpfung von Daten und deren Darstellung in
der Reporting-Schicht. Ein CompositeProvider ist ein InfoProvider, der Daten aus SAP-HANA-
Views oder von anderen klassischen BW-InfoProvidern per Join oder Union kombiniert und
diese Daten für das Reporting und für Analysen zur Verfügung stellt. An dieser Stelle soll
darauf hingewiesen werden, dass CompositeProvider HANA-Views direkt enthalten können:
Die Modellierung eines CompositeProviders zusätzlich zu einer HANA-View ermöglicht es
Ihnen, zusätzlich zu den reinen SAP-HANA-Objekten das BEx-Reporting zu definieren.
Lektion: Modellieren von CompositeProvidern
©Copyright. Alle Rechte vorbehalten. 135Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

144. Abbildung 136: Hauptmerkmale von CompositeProvidern
1.Veralteter CompositeProvider
Anfangs gab es eine SAP-GUI-basierte grafische Umgebung (Transaktion RSLIMOBW), um
Daten von mehreren InfoProvidern zu kombinieren. Sie wurde mit BW Accelerator 7.2
bzw. BW 7.3 auf HANA freigegeben. Diese GUI und diese Art von CompositeProvider
wurden mit BW 7.4 wieder aus dem Betrieb genommen. Sie verwenden stattdessen einen
neuen zentralen CompositeProvider. BW-Objekttyp = COPR.
2.Lokaler CompositeProvider
Kern eines SAP BW Workspace, in dem Geschäftsbenutzer ihre eigenen Daten aus
Dateien mit Daten aus BW kombinieren können. Näheres dazu finden Sie später in diesem
Kurs. Basiert technisch auf dem veralteten CompositeProvider.
3.Neue zentraler CompositeProvider
In den Eclipse-basierten BW-Modellierungswerkzeugen können BW-Entwickler jetzt
flexibel Daten aus mehreren InfoProvidern und SAP-HANA-Views kombinieren. Für diesen
Zweck gibt es keine Modellierungsoption mehr, die auf SAP GUI basiert. Dieser
CompositeProvider wird der zentrale CompositeProvider sein. Er bildet die virtuelle Data-
Mart-Schicht, die die Daten für das Reporting und für Analysen bereitstellt, wenn Sie die
SAP-HANA-Datenbank verwenden. Er ersetzt beim Einsatz von SAP HANA den
CompositeProvider-Typ 1. Er ist seit BW7.4 SP5 erhältlich und nur in BW-
Modellierungswerkzeugen von SAP HANA Studio verfügbar. BW-Objekttyp = HCPR.
Die Rolle des CompositeProviders besteht darin, ein Metadatenobjekt bereitzustellen, das die
Data-Mart-Schicht im BW bildet. Er liefert die Daten für das Reporting und für Analysen in
Form einer Outbound-Struktur, die semantisch reich ist. Er abstrahiert die zugrunde
liegenden BW-Objekte und stellt ein Outbound-Interface zur Verfügung, das über alle Query-
Arten konsumiert werden kann, da er die Option zur Erzeugung einer HANA-View bietet.
Daher empfiehlt SAP, wie zuvor auch für den MultiProvider, als Basis für das BEx-Reporting
den neuen CompositeProvider zu verwenden. Denn mit dieser Option können Sie flexibel auf
Änderungen in Ihren Reporting-Anforderungen reagieren. Der Editor für die
CompositeProvider-Modellierung basiert rein auf Eclipse und wird als Teil der BW-
Modellierungswerkzeuge ausgeliefert, die als integraler Bestandteil von SAP HANA Studio in
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 136Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

145. einer eigenen Perspektive geliefert werden. In den Eclipse-basierten BW-
Modellierungswerkzeugen können BW-Entwickler flexibel Daten aus mehreren BW-
InfoProvidern und SAP-HANA-Views kombinieren.
Es ist möglich, einen CompositeProvider auf Basis eines MultiProviders oder eines alten
CompositeProviders anzulegen. Seit BW 7.40, SP10 gibt es das folgende Programm, mit dem
dies möglich ist: RSO_CONVERT_IPRO_TO_HCPR. Siehe SAP-Hinweis 2080851.
Abbildung 137: Der neue zentrale CompositeProvider in SAP HANA Studio – UNION
Im Bereich rechts auf dem Bild können Sie die Zuordnungen für die Felder konfigurieren. Auf
der linken Seite sehen Sie die beteiligten Provider. Rechts davon werden die Felder des
CompositeProviders angezeigt. In der grafischen Anzeige können Sie dem
CompositeProvider die Felder entweder per Drag&Drop hinzufügen oder im Kontextmenü
Create Assignmentsauswählen und die entsprechenden Zuordnungen anlegen. Wenn Sie
einen InfoProvider per Drag&Drop hinzufügen, werden die Felder und Dimensionen (Gruppen)
des InfoProviders angewendet, und alle erforderlichen Dimensionen, die noch nicht
vorhanden sind, werden angelegt.
Sie können auch komplette Dimensionen hinzufügen, indem Sie die jeweilige Dimension in
einen freien Bereich oder auf den Wurzelknoten ziehen. Wenn Sie eine Dimension auf eine
andere Dimension ziehen, werden nur die Felder zu der neuen Dimension hinzugefügt. Im
Falle der BW InfoProvider werden die InfoObjects hinzugefügt und die Dimensionen als
Gruppen hinzugefügt. Wenn ein Feld noch nicht in der Zielstruktur vorhanden ist, wird es vom
System angelegt. Wenn dem CompositeProvider Navigationsattribute hinzugefügt wurden,
handelt es sich nicht mehr um Navigationsattribute. Wenn den Feldern der SAP-HANA-View
InfoObject-Namen zugewiesen wurden, werden diese zum Anlegen einer Zuordnung für das
Feld im CompositeProvider für SAP-HANA-Views verwendet. Wenn dem CompositeProvider
Felder zugewiesen werden, werden die Zuordnungen automatisch festgelegt.
Wenn eine SAP-HANA-View Eingabeparameter enthält, werden diese angezeigt, und Sie
können sie wie normale Felder bearbeiten. Sie können Eingabeparameter nur anderen
Eingabeparametern zuordnen. Ein Eingabeparameter kann entweder mit einem InfoObject
oder mit einem anderen Eingabeparameter geklammert werden.
Lektion: Modellieren von CompositeProvidern
©Copyright. Alle Rechte vorbehalten. 137Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

146. Abbildung 138: Der neue zentrale CompositeProvider in SAP HANA Studio – JOIN
In einem BW DataWarehouse, das auf dem neuesten Stand ist, gibt es immer eine
Virtualisierungsschicht als Schnittstelle für das BEx-Reporting. Derzeit besteht diese aus
MultiProviders. MultiProvider bieten aufgrund des Query-Pruning eine erhöhte Query-
Performance. In seltenen Fällen können InfoSets verwendet werden. Da jedoch InfoSets
während der Query-Laufzeit einen Join der Daten durchführen, und dieser vom
Anwendungsserver verarbeitet wird, sind Querys auf InfoSets sehr langsam. Somit können in
der klassischen BW-Architektur Unions virtualisiert werden, während Joins vermieden werden
sollten und persistent sein sollten.
Hier bietet der neue CompositeProvider ein enormes Wertschöpfungspotenzial für Ihre
Architektur. Ein CompositeProvider ist ein InfoProvider, der Daten aus BW-InfoProvidern
sowie SAP-HANA-Informationssichten per Join oder Union kombiniert und diese Daten für
das Reporting und für Analysen zur Verfügung stellt.
CompositeProvider bieten ausgezeichnete Möglichkeiten, um die Datenpersistenz in Ihrem
Data Warehouse weiter zu reduzieren! In der Vergangenheit wurden Join-Vorgänge
hauptsächlich während der Datenaufbereitung mit persistenten Ergebnissen in DataStore-
Objekten (klassisch) durchgeführt. Mit dem neuen CompositeProvider gibt es jetzt eine
ausgezeichnete Alternative. Um z.B. diese Persistenz zu vermeiden, können Ad-hoc-Join-
Vorgänge über den neuen CompositeProvider genutzt werden, der von der leistungsstarken
SAP-HANA-Technologie profitiert.
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 138Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

147. Abbildung 139: BW-RSA1-Funktionen des CompositeProviders
Der CompositeProvider kann nicht in der BW Administrator Workbench angelegt werden.
Dennoch sind CompositeProvider sichtbar, und es stehen einige unterstützende Funktionen
zur Pflege im SAP GUI zur Verfügung.
Lektion: Modellieren von CompositeProvidern
©Copyright. Alle Rechte vorbehalten. 139Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

148. Abbildung 140: CompositeProvider anlegen (Union) – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●CompositeProvider anlegen
Kapitel 3: Bewegungsdaten in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 140Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

149. KAPITEL 4Native Modellierung in
SAP HANA
Lektion 1
Erkunden von SAP HANA Studio 142
Lektion 2
Beschreibung der Datenbereitstellung in SAP HANA 148
Lektion 3
Einführung in die native SAP-HANA-Modellierung 156
Lektion 4
Kombinieren von SAP Business Warehouse (SAP BW) InfoProvider mit SAP-HANA-Views 177
LERNZIELE
●SAP HANA Studio erkunden
●die Datenbereitstellung in SAP HANA beschreiben
●SAP HANA Calculation Views mit SAP-HANA-Modellierung anlegen
●SAP-BW-InfoProvider mit SAP-HANA-Views kombinieren
©Copyright. Alle Rechte vorbehalten. 141Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

150. Kapitel 4
Lektion 1
Erkunden von SAP HANA Studio
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in SAP HANA Studio. Es werden die
Benutzungsoberfläche (UI), die Perspektiven und die Funktionen von SAP HANA Studio
erläutert.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●SAP HANA Studio erkunden
SAP HANA Studio
Abbildung 141: Eclipse-basierte Modellierung 1
SAP HANA Studio wird auf der Eclipse-Plattform ausgeführt und ist sowohl eine
Entwicklungsumgebung als auch ein Verwaltungswerkzeug für SAP HANA.
Administratoren können mit SAP HANA Studio Dienste starten und anhalten, das System
überwachen, Systemeinstellungen konfigurieren und Benutzer und Berechtigungen
verwalten. SAP HANA Studio greift auf die Server der SAP-HANA-Datenbank per SQL zu.
Entwickler können mit SAP HANA Studio Inhalte wie modellierte Views und gespeicherte
Prozeduren anlegen. Diese Entwicklungsartefakte werden im Repository gespeichert, das Teil
©Copyright. Alle Rechte vorbehalten. 142Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

151. der SAP-HANA-Datenbank ist. SAP HANA Studio wurde in Java entwickelt und basiert auf der
Eclipse-Plattform.
SAP HANA Studio präsentiert seine unterschiedlichen Werkzeuge in Form von Perspektiven.
Funktionen zur Verwaltung und Überwachung der Datenbank stehen in der Perspektive SAP
HANA Administration Console zur Verfügung. Zu den weiteren Perspektiven gehören SAP
HANA Modeler und SAP HANA Development. Weitere Informationen zu diesen Perspektiven
finden Sie im SAP HANA Developer Guide (für SAP HANA Studio) und im SAP HANA Modeling
Guide (für SAP HANA Studio).
Bevor Sie mit der BW-Modellierung in SAP HANA Studio beginnen können, müssen Sie zuerst
ein BW-Projekt anlegen. Mithilfe des BW-Projekts wird die Verbindung zum BW-Backend-
System verwaltet, mit dem Sie arbeiten möchten. Das Projekt fungiert als ein Container (am
Frontend) für die im BW-System befindlichen BW-Metadatenobjekte.
Die Arbeit mit Projekten erfolgt in der Project-Explorer-View. Hier werden die Projekte in
alphabetischer Reihenfolge (aufsteigend) angezeigt. Um mit einem BW-Projekt arbeiten und
die Unterbäume des BW-Projekts anzeigen zu können, müssen Sie sich beim BW-Backend-
System anmelden. Es gibt mehrere Möglichkeiten zum Öffnen des Anmeldebildschirms:
Doppelklicken Sie auf das BW-Projekt, oder erweitern Sie die erste Ebene des BW-Projekts.
Wenn Sie auf ein Projekt doppelklicken oder es erweitern, während SSO für das verbundene
BW-System aktiviert ist, wird kein Anmeldebildschirm angezeigt und die Verbindung sofort
hergestellt. Nachdem Sie beim BW-System für ein bestimmtes Projekt angemeldet sind,
bleiben Sie für dieses Projekt angemeldet, bis Sie SAP HANA Studio beenden.
Abbildung 142: Eclipse-basierte Modellierung 2
Die Benutzungsoberflächen (UI) der BW-Modellierungswerkzeuge verfügen über
leistungsstarke Funktionen. Diese Dokumentation enthält Informationen zum Einrichten von
Projekten für die Durchführung von BW-Modellierungsaufgaben. Sie beschreibt außerdem die
Arbeit mit BW-Metadaten in der auf SAP HANA Studio basierenden integrierten
Entwicklungsumgebung (IDE). Insbesondere wird auf die Definition von BW-
Metadatenobjekten wie CompositeProviders und Open-ODS-Views eingegangen, die native, auf SAP HANA Studio basierende Editoren bereitstellen. Sie können auch die dem BW-
Lektion: Erkunden von SAP HANA Studio
©Copyright. Alle Rechte vorbehalten. 143Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

152. System zugrunde liegende SAP-HANA-Datenbank zuordnen und so die Nutzung von SAP-
HANA-Views (Informationsmodellen) in BW-Metadatenobjekten ermöglichen. Die BW-
Projektstruktur enthält in diesem Fall einen weiteren Knoten für die SAP-HANA-
Systembibliothek, unter dem die SAP-HANA-Views aufgeführt werden.
Die BW Modeling Tools (BWMT) sind eine separate Perspektive in SAP HANA Studio und
stellen eine integrierte Modellierungsumgebung für die Verwaltung und Wartung der BW-
Metadatenobjekte bereit. Das Hauptziel hiervon ist es, die Modellierer von BW-Metadaten in
zunehmend komplexeren BI-Umgebungen mit flexiblen, effizienten und modernen
Modellierungswerkzeugen zur Seite zu stehen. Die Werkzeuge integrieren sich in die ABAP Development Tools wie auch die SAP-HANA-Modellierung und unterstützen die Einbeziehung
von SAP-HANA-Elementen in BW-Metadatenobjekte wie Open-ODS-Views oder
CompositeProviders.
Wie jede andere Perspektive in SAP HANA Studio auch definiert die BW-
Modellierungsperspektive den Anfangssatz und das Layout der Werkzeuge (Views und Editoren) im HANA-Studio-Fenster. Sie stellt so eine Reihe von Funktionen bereit, die der
Erfüllung der BW-Modellierungsaufgaben dienen.
Insbesondere ermöglicht Sie die Arbeit mit BW-Metadatenobjekten, die von einem BW-
Backend-System verwaltet werden. Bei Verwendung der BW-Modellierungsperspektive
müssen Sie immer eine Systemverbindung zum BW-System herstellen (technisch realisiert
über das zugehörige BW-Projekt). Die BW-Perspektive gestattet den Zugriff sowohl über auf
SAP HANA Studio basierende als auch über GUI-basierte BW-Modellierungs-Editoren.
Abbildung 143: SAP HANA Studio – Perspektive
Die BW-Modellierungsperspektive ist für die Arbeit mit BW-Metadatenobjekten gedacht, auf
die der Anwender mit BW-Projekten zugreifen kann. Sie besteht aus einem Editorbereich – in
dem sich die BW-Metdatenobjekt-Editoren befinden – und den folgenden Views:
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 144Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

153. ●Project Explorer
●Properties
●Problems
●History
●BW Reporting Preview
●InfoProvider
Sie können Classic InfoProviders, DataSources, Transformations und Data Transfer-
Processes nur in der Data Warehousing Workbench anlegen und pflegen. Es ist vorgesehen,
die gesamte Wartung der BW-Objekte in der BW-Modellierungsperspektive
zusammenzuführen.
Abbildung 144: SAP HANA Studio – Open SAP GUI
In der Abbildung „SAP HANA Studio – Open SAP GUI“ sehen Sie, wie Sie die Data
Warehousing Workbench aus SAP HANA Studio heraus öffnen.
Abbildung 145: Eclipse-basiert bei Modellierung 3
In der BW-Modellierungsperspektive können Sie alle BW-Metadatenobjekte öffnen und
bearbeiten, die in BW-Projekten angezeigt werden. Bei klassischen BW-Metadatenobjekten
Lektion: Erkunden von SAP HANA Studio
©Copyright. Alle Rechte vorbehalten. 145Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

154. wird der SAP-GUI-Editor aus Data Warehousing Workbench in der auf SAP HANA Studio
basierenden IDE ausgeführt. Für aktuelle BW-InfoProvider wie CompositeProvider, Open ODS
View und Advanced DSO sind native HANA-Studio-Editoren verfügbar, mit denen Sie diese
Objekte auch anlegen können.
Abbildung 146: BW-Metadatensuche
In der folgenden Liste sehen Sie, wie Sie im Dialogfeld „Open BW Object“ nach Objekten
suchen und Objekte öffnen:
●Suchen Sie bei geöffnetem BW-Objekt-Dialogfeld über den Namen oder die Beschreibung
nach einem BW-Metadatenobjekt.
●Öffnen Sie den Editor (SAP HANA Studio oder SAP GUI) für das ausgewählte Objekt.
●Geben Sie eine Suchzeichenfolge ein. Das System sucht nach BW-Metadatenobjekten im
ausgewählten BW-Projekt.
●Es sucht nach Objekten, die die Suchzeichenfolge im Präfix des technischen Namens oder
in der Beschreibung enthalten. Bei der Suche wird nicht zwischen Groß- und
Kleinschreibung unterschieden. Folgende Platzhalter werden unterstützt: *- beliebiges
Zeichen * - beliebige Zeichenfolge (einschließlich der Zeichenfolgelänge 0). Wenn Sie keine
Platzhalter eingeben, wird * implizit bei der Suche verwendet. Die Suchergebnisse werden
im Bereich „Matching Items“ des Dialogfelds angezeigt.
Sie sind nach Objekttyp und Beschreibung in aufsteigender Reihenfolge sortiert.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 146Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

155. Abbildung 147: Übung zum Erkunden von SAP HANA Modeler
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●SAP HANA Studio erkunden
Lektion: Erkunden von SAP HANA Studio
©Copyright. Alle Rechte vorbehalten. 147Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

156. Kapitel 4
Lektion 2
Beschreibung der Datenbereitstellung in SAP
HANA
ÜBERBLICK ÜBER DIE LEKTION
Diese Lektion bietet eine Einführung in die Datenbereitstellung in SAP HANA.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●die Datenbereitstellung in SAP HANA beschreiben
Überblick über die Datenbereitstellung
Abbildung 148: Positionierung der Datenbereitstellung
Für das Importieren von Dateien in die Workbench gibt es folgende Möglichkeiten:
●per Drag-und-Drop im Dateisystem
●per Kopieren und Einfügen im Dateisystem
●mithilfe des Import-Assistenten
©Copyright. Alle Rechte vorbehalten. 148Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

157. Sie können Dateien per Drag-und-Drop oder mit Kopieren und einfügen importieren. Diese
Funktion ist jedoch von der verwendeten Plattform abhängig. Wenn Ihre Plattform diese
Importmethoden nicht unterstützt, können Sie stattdessen den Import-Assistenten
verwenden.
Abbildung 149: Flatfile importieren – Beispiel 1
Lektion: Beschreibung der Datenbereitstellung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 149Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

158. Abbildung 150: Flatfile importieren – Beispiel 2
Enterprise Information Management (EIM)
EIM erweitert, bereinigt und transformiert Daten, damit sie präziser und hilfreicher sind.
Durch den Geschwindigkeitsvorteil von SAP HANA kann die neue SAP-HANA-EIM-Option eine
Verbindung zu einer beliebigen Quelle herstellen, Daten bereitstellen und bereinigen sowie
Daten in eine lokale oder Cloud-Version von SAP HANA laden. Bei unterstützten Systemen ist
auch ein Rückschreiben der Daten in die ursprüngliche Quelle möglich.
Folgende EIM-Funktionen bietet SAP HANA EIM:
●Eine vereinfachte Landschaft, eine Umgebung zum Bereitstellen und Nutzen von Daten.
●Zugriff auf mehr Datenformate, einschließlich eines offenen Frameworks für neue
Datenquellen.
●In-Memory-Leistung, d.h. höhere Geschwindigkeit und geringere Latenzzeit.
Tabelle 3: Enterprise Information Management
SAP HANA EIM besteht aus zwei Hauptbereichen, Smart Data Integration und Smart-Data-
Qualität, die in der folgenden Tabelle beschrieben werden.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 150Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

159. FunktionsbereichBeschreibung
Smart Data IntegrationEchtzeit-, Hochgeschwindigkeits-Datenbereitstellung, Verschieben
von Massendaten und Föderation. SAP HANA EIM bietet integrierte
Adapter und ein SDK zur Anpassung an die eigenen Anforderun-
gen. Smart Data Integration umfasst folgende Funktionen und
Werkzeuge:
●Replikationseditor in der webbasierten SAP-HANA-Entwick-
lungsworkbench, mit dem Sie Batch- oder Echtzeit-Datenrepli-
kationsszenarios in einer benutzerfreundlichen Webanwendung
einrichten können
●Smart-Data-Integration-Transformationen, bereitgestellt als
neue Knoten in dem mit SAP HANA Studio und der webbasier-
ten SAP-HANA-Entwicklungsumgebung ausgelieferten Applica-
tion Function Modeler, mit dem Sie Batch- oder Echtzeit-Daten-
transformationsszenarios einrichten können
●Datenbereitstellungs-Agent, eine einfache Komponente, die Da-
tenbereitstellungs-Adapter hostet, die Datenföderations-, Repli-
kations- und Transformationsszenarios bei lokalen und Cloud-
Bereitstellungen ermöglichen
●Datenbereitstellungs-Adapter für Konnektivität zu Remote-
Quellen
●
Adapter-SDK zum Anlegen benutzerdefinierter Adapter
●SAP-HANA-Cockpit-Integration für Überwachung von Datenbe-
reitstellungs-Agenten, Remote-Subskriptionen und Datenlasten
Smart-Data-QualitätDatenbereinigung, Adressbereinigung und georäumliche Datenan-
reicherung in Echtzeit und mit höchster Geschwindigkeit. SAP HA-
NA EIM bietet eine intuitive Oberfläche zur Festlegung von Ablauf-
diagrammen für Datentransformationen in der webbasierten SAP-HANA-Entwicklungsumgebung und SAP HANA Studio. Smart-Da-ta-Qualität beinhaltet Application-Function-Modeler-Knoten zurDurchführung von Datenqualitätsaufgaben, z.B. Adressbereini-
gung, Datenbereinigung und Geokodierung.
SAP HANA Smart Data Access
Mit SAP HANA Smart Data Access können Sie auf Remote-Daten zugreifen, als ob die Daten
in lokalen Tabellen in SAP HANA gespeichert wären, ohne die Daten nach SAP HANA kopieren
zu müssen.
Nicht nur bietet diese Möglichkeit operative und finanzielle Vorteile, wichtiger noch
unterstützt sie die Entwicklung und Bereitstellung analytischer Anwendungen der nächsten
Generation, die Daten aus mehreren Systemen in Echtzeit abrufen, synthetisieren und
integrieren können müssen, unabhängig davon, wo die Daten gespeichert sind oder von
welchen Systemen sie generiert werden.
Speziell in SAP HANA können Sie virtuelle Tabellen anlegen, die auf Remote-Tabellen in
verschiedenen Datenquellen verweisen. Kunden können dann SQL-Querys in SAP HANA
programmieren, die auf virtuelle Tabellen zurückgreifen. Der SAP-HANA-Query-Prozessor
Lektion: Beschreibung der Datenbereitstellung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 151Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

160. optimiert diese Querys und führt den relevanten Teil einer Query in der Zieldatenbank aus. Er
gibt dann die Ergebnisse der Query an SAP HANA zurück und schließt die Operation ab.
Folgende Remote-Datenquellen werden unterstützt:
●SAP HANA
●SAP IQ
●SAP Adaptive Service Enterprise
●SAP Event Stream Processor (wird nur auf Intel-basierten Hardwareplattformen
unterstützt)
●SAP MaxDB (wird nur auf Intel-basierten Hardwareplattformen unterstützt)
●Hortonworks Distribution für Apache Hadoop: Version 2.3 (dies schließt Apache Hadoop
Version 1.0.3 und Apache Hive 0.9.0. ein) (wird nur auf Intel-basierten
Hardwareplattformen unterstützt)
●Teradata-Datenbank (wird nur auf Intel-basierten Hardwareplattformen unterstützt)
●Microsoft SQL Server 2012 (wird nur auf Intel-basierten Hardwareplattformen unterstützt)
●Oracle Database 12C
●IBM DB2 (wird nur auf Intel-basierten Hardwareplattformen unterstützt)
●IBM Netezza Appliance (wird nur auf Intel-basierten Hardwareplattformen unterstützt)
●Apache Spark (wird nur auf Intel-basierten Hardwareplattformen unterstützt)
SAP HANA Smart Data Streaming
SAP HANA Smart Data Streaming ist eine spezielle Option, bei der Ströme eingehender
Ereignisdaten in Echtzeit verarbeitet werden. Eingehende Daten werden erfasst und lösen
Aktionen aus. Smart Data Streaming ist ideal für Situationen geeignet, in denen Daten beim
eintreten bestimmter Ereignisse eintreffen und wo das Erfassen, Verstehen und sofortige
Reagieren auf diese Daten einen Mehrwert darstellt.
In der folgenden Liste sehen Sie Beispiel für Datenquellen, die Datenströme für Ereignisse in
Echtzeit erzeugen:
●Sensoren
●Mobile Lifestyle-Geräte
●Websites (Click-Datenströme)
●IT-Systeme (Protokolle)
●Finanzmärkte (Preise)
●Soziale Netzwerke
Daten treffen aus verschiedenen Quellen in Streaming-Projekten ein. Dies geschieht meist
über Adapter, die die Quellen mit dem Smart-Data-Streaming-Server verbinden. Die
Streaming-Projekte enthalten Geschäftslogik, die auf die eingehenden Daten angewendet
wird, meist in der Form stetiger Querys und Regeln. Diese Streaming-Projekte sind komplett
ereignisgesteuert. Sie wandeln eingehende Rohdatenströme in einen oder mehrere
abgeleitete Datenströme um, die in der SAP-HANA-Datenbank erfasst, als
Benachrichtigungen gesendet, in nachgelagerten Anwendungen gebucht oder an Live-
Dashboards gestreamt werden können.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 152Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

161. SAP Replication Server
Mit SAP Replication Server können Sie Daten in Echtzeit im gesamten Unternehmen
verschieben und synchronisieren. Mit dieser bewährten Datenreplikationssoftware können
Sie zahlreiche geschäftskritische Anforderungen erfüllen – von der Hochverfügbarkeit von
Anwendungen über die Desaster-Recovery, bis zur reibungslosen, extrem schnellen
Datenverteilung und der intelligenten Entscheidungsfindung auf Basis topaktueller
Informationen.
Transformation Replication Server
Mit SAP Landscape Transformation Replication Server (SAP LT Replication Server) können
Sie Echtzeitdaten aus Tabellen unterstützter Quelle für BW bereitstellen. Dies wird durch die
triggerbasierten Replikationsfunktionen des SAP LT Replication Server erreicht.
Die triggerbasierte Replikation (SAP LT Replication Server) ermöglicht Deltaverfahren auch
für Tabellen einzusetzen, die kein deltafähiges Feld besitzen. So können Sie beispielsweise
Deltaverfahren für DataSources (Extraktoren) ohne Deltalogik einsetzen. Für große
Stammdatentabellen ohne Deltalogik, die sich nur selten ändern, kann die
Übertragungsmethode über SAP LT Replication Server den bisherigen
Administrationsaufwand häufiger Full-Ladeprozesse durch den Ansatz der triggerbasierten
Replikation erheblich reduzieren. Beachten Sie die Lizenzbedingungen bei der Verwendung von SAP Landscape Transformation Replication Server.
SAP LT Replication Server stellt in folgenden Fällen eine sinnvolle Alternative für die
Datenübertragung ins BW dar:
●Die Tabellen in der Quelle sind einfache Tabellen ohne Join und Transformationslogik.
●Die DataSources (Extraktoren), die Sie durch den Einsatz des SAP LT Replication Servers
ersetzen möchten, sind DataSources auf einfachen Tabellen/Views, die keinen
Deltamechanismus anbieten und wenig Extraktorlogik beinhalten.
Achtung:
Beachten Sie folgende Punkte, wenn Sie diese Übertragungsmethode zum
Ersatz von Extraktoren verwenden möchten:
●Viele Extraktoren beinhalten Extraktorlogik (Assoziationen und Content-
Logik), deren Nachbau im BW-System sehr komplex ist.
●Viele Extraktoren können über die Delta-Queue eine konsistente
Deltaversorgung des BW-Systems gewährleisten. Daher empfehlen wir,
komplexe Extraktoren nur in Ausnahmefällen durch SAP LT Replication
Server zu ersetzen.
Die folgenden beiden Interfaces stehen für die Übertragung mit SAP LT Replication Server zur
Verfügung:
●Operational-Data-Provisioning-Datenübertragung mit Operational Data Provisioning wird
für Tabellen aus SAP-Systemen unterstützt
Der SAP LT Replication Server stellt die Operational-Data-Provisioning-Infrastruktur mit
Quelltabellen als Delta-Queues bereit. Die Daten aus der Delta-Queue können in BW als ein
Abonnent repliziert werden. Wenn Sie Operational Data Provisioning verwenden, können
Sie die Daten direkt in die InfoProvider laden (und die PSA-Schicht umgehen), indem Sie
Lektion: Beschreibung der Datenbereitstellung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 153Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

162. einen Datentransferprozess verwenden. Die ODP-Infrastruktur (mit Delta-Queues)
übernimmt wichtige Dienste wie das Überwachen von Datenrequests. Zusätzlich ist die
ODP-Infrastruktur auf die Unterstützung von BW und andere Abonnenten mit SLT-
Datenübertragung (z.B. SAP Data Services) vorbereitet.
●Web-Service-Datenübertragung mithilfe des Web-Service-Interfaces wird für Tabellen aus
SAP-Systemen und Tabellen aus Fremdsystemen unterstützt.
SAP LT Replication Server repliziert Daten in einer Web-Service-DataSource des BW
Persistent Staging Area, wo die Daten zur weiteren Verarbeitung verfügbar sind. Bei
Verwendung eines Web-Service-Interfaces können die Daten in regelmäßigen Intervallen
an BW übertragen werden, wo sie mithilfe der Real-Time Data Acquisition aktualisiert
werden können.
SAP HANA Direct Extractor Connection (DXC)
SAP HANA Direct Extractor Connection (DXC) stellt sofort einsatzbereite, auf SAP-Business-
Suite-Entitäten basierende Foundation-Datenmodelle für SAP HANA bereit und dient
gleichzeitig als Datenbereitstellungsmethode. Kundenprojekte habe bei der Modellierung von
Entitäten in SAP-Business-Suite-Systemen möglicherweise mit beträchtlicher Komplexität zu
kämpfen. In vielen Fällen erfordern Daten aus anderen Bereichen in SAP-Business-Suite-
Systemen eine Anwendungslogik, um den Zustand der Geschäftsbelege darzustellen. SAP-
Business-Content-DataSource-Extraktoren stehen bereits seit vielen Jahren als Basis für die
Datenmodellierung und Datengewinnung für SAP Business Warehouse zur Verfügung. Jetzt,
mit DXC, können diese SAP-Business-Content-DataSource-Extraktoren Daten auch direkt an
SAP HANA übertragen.
DXC ist eine Batch-gesteuerte Datengewinnungstechnik. Sie sollte als eine Möglichkeit zur
Extraktion, Transformation und Ladens in Betracht gezogen werden, auch wenn ihre
Transformationsfunktionen für die Extraktion auf User-Exit beschränkt sind. Ein wichtiger
Punkt bei DXC ist, dass in vielen Anwendungsfällen eine Batch-gesteuerte Datengewinnung in
bestimmten Intervallen ausreichend ist (z.B. alle 15 Minuten).
SAP Data Services
SAP Data Services und SAP Information Steward sind Teil der Enterprise-Information-
Management-Produktsuite, die sich an im Information Management arbeitende Personen
richtet: Administratoren, Entwickler und Fachexperten, die für Data Stewardship und Data
Governance zuständig sind.
SAP Data Services bieten eine Einzelunternehmenslösung für Datenintegration,
Datenqualität, Datenprofilierung und Textdatenverarbeitung. Die folgende Liste zeigt die
Vorteile der SAP Data Services:
●Ermöglicht die Integration, Transformation, Verbesserung und Bereitstellung
vertrauenswürdiger Daten für geschäftskritische Prozesse.
●Bietet eine Benutzungsoberfläche für die Entwicklung, ein Metadaten-Repository, eine
Datenkonnektivitätsschicht, eine Laufzeitumgebung und eine Managementkonsole,
sodass IT-Organisationen die Gesamtbetriebskosten senken und die Wertschöpfung
beschleunigen können.
●Befähigt IT-Organisationen, die betriebliche Effizienz mit einer einzigen Lösung zu
optimieren, um die Datenqualität zu verbessern und auf heterogene Quellen und
Anwendungen zugreifen zu können.
SAP Information Steward stellt Business-Analysten, Stammdatenverwaltern und IT-
Benutzern eine einzelne Umgebung bereit, in der sie mithilfe der folgenden Module
Unternehmensdaten entdecken, bewerten, definieren, überwachen und verbessern können:
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 154Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

163. ●Data Insight
Profilieren Sie Daten, legen Sie Validierungsregeln an und führen Sie sie aus, überwachen
Sie die Datenqualität mittels Scorecards und legen Sie Datenbereinigungslösungen an –
basierend auf Inhaltstyp-Identifikationsergebnissen und SAP Best Practices für Ihre Daten.
●Metadaten-Management.
Katalogisieren Sie die Metadaten für die gesamte Systemlandschaft, analysieren und
verstehen Sie die Beziehungen zwischen Unternehmensdaten
●Metapedia
Definieren Sie betriebswirtschaftliche Begriff e für Daten und organisieren Sie die Begriff e
in Kategorien.
●Bereinigungspaketerstellung
Definieren Sie Bereinigungspakete zum Analysieren und Standardisieren von Daten.
●Überprüfung des Datenvergleichs
Überprüfen Sie regelmäßig die Ergebnisse des automatisierten Abgleichs und nehmen Sie
notwendige Korrekturen vor. Die Überprüfung des Datenvergleichs führt eine Liste von
Datensätzen auf der RegisterkarteMein Arbeitsvorrat, die Aktionen des Prüfers zu
Abgleichentscheidungen enthält.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●die Datenbereitstellung in SAP HANA beschreiben
Lektion: Beschreibung der Datenbereitstellung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 155Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

164. Kapitel 4
Lektion 3
Einführung in die native SAP-HANA-
Modellierung
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird erläutert, wie Sie mit der SAP-HANA-Modellierung SAP-HANA-
Calculation Views erstellen. Darüber hinaus wird auf die Vorteile der Calculation Views
eingegangen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●SAP HANA Calculation Views mit SAP-HANA-Modellierung anlegen
SAP-HANA-Modellierung
Abbildung 151: SAP BW, Powered by SAP HANA: Gemischte Szenarien
Mit den in SAP BW und SAP HANA verfügbaren Modellierungsfunktionen ist es dank der
gemischten Modellierung möglich, auf BW-Daten aus jedem Schema in der SAP-HANA-
Datenbank und auf Daten in jedem Schema der SAP-HANA-Datenbank von BW aus
zuzugreifen. Sie können Szenarien anlegen, bei denen im BW-System modellierte Daten mit in
SAP HANA mit SAP-HANA-Werkzeugen modellierten Daten zusammengeführt werden.
Wenn ein BW-System auf der SAP-HANA-Datenbank läuft, sind die BW-Daten in einem
speziellen Schema, dem BW-verwalteten Schema abgelegt. In anderen SAP-HANA-Schemas
können Daten in SAP-HANA-Tabellen oder Views gespeichert werden. Einerseits können Sie
auf Daten aus einem BW wie auch auf Daten aus einem beliebigen Schema in der SAP-HANA-
©Copyright. Alle Rechte vorbehalten. 156Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

165. Datenbank zugreifen. Andererseits können Sie auf Daten aus einem BW-verwalteten Schema
(in der SAP-HANA-Datenbank) in einem anderen SAP-HANA-Schema zugreifen. Sie können
Datenreplikationsmethoden und virtuelle Zugriff smethoden verwenden. Die folgende Liste
führt die verschiedenen Möglichkeiten auf und verweist auf weiterführende Informationen.
In der folgenden Tabelle finden Sie die Gründe für die Kombination von Daten aus dem SAP-
BW-Data-Warehouse mit Daten aus SAP HANA, die am wahrscheinlichsten in Echtzeit
repliziert werden:
●Kombination historischer Informationen wie Verläufen mit Echtzeit-Statusinformationen,
die in SAP HANA vorhanden sind.
●Integration von SAP-Daten in SAP BW mit Nicht-SAP-Daten, die in HANA vorhanden sind.
●Import von BW-Datenmodellen in HANA-Szenarien wurde für den Explorer-
Anwendungsfall entwickelt. Explorer kann nicht direkt auf BW-Anbieter zugreifen. Daher
müssen Sie dieses Model direkt in HANA importieren und die zugehörigen Daten
zusätzlich zu SAP HANA in Explorer öffentlich machen.
Zum Anlegen von SAP-HANA-Views für BW-Objekte gibt es die folgenden beiden
Möglichkeiten. Aus dem BW-System oder aus SAP HANA Modeler. Auch wenn es gewisse
Unterschiede gibt, können beide Herangehensweisen gleichermaßen empfohlen werden.
In folgenden Situationen sollten Sie SAP-HANA-Views im BW-System generieren:
●Wenn Sie hauptsächlich die BW-Enterprise-Data-Warehouse-Schicht verwenden und
planen, Queries direkt für die Datenmodelle – ohne OLAP-Funktionen – auszuführen.
●Wenn die SAP-HANA-View bei Änderungen in BW automatisch angepasst werden soll
●Wenn die SAP-HANA-View Teil des BW-Transportsystems sein soll
●Wenn SAP-HANA-Benutzern automatisch SAP-HANA-Berechtigungen zugewiesen werden
sollen
●Wenn CompositeProviders oder Queries für SAP-HANA-Views verwendet werden sollen
●Wenn Sie auf den Nearline-Storage zugreifen oder Bestandskennzahlen verwenden
möchten
In den folgenden Situationen ist jedoch das Importieren von BW-Objekten aus dem SAP
HANA Modeler empfehlenswert:
●Wenn Sie hauptsächlich SAP HANA Modeler und Ihre eigenen ETL-Werkzeuge verwenden
●
Wenn das Inhaltspaket für jedes Objekt individuell konfiguriert werden kann
●Wenn Sie an der generierten SAP HANA-View vorgenommene Änderungen nach einem
erneuten Import behalten möchten
Tabelle 4: Views in SAP HANA für BW-Objekte
In dieser Tabelle werden die Unterschiede zwischen den beiden Herangehensweisen
dargestellt
Generiert im BW-SystemImport aus SAP HANA Mode-
ler
Werkzeug Wird bei der Modellierung
von BW-Objekten aufgerufen
(Push)
Wie von SAP HANA Modeler
ausgelöst (Pull)
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 157Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

166. Generiert im BW-SystemImport aus SAP HANA Mode-
ler
Aktualisierung nach Änderun-
gen am BW-Objekt
Die SAP-HANA-View wird au-
tomatisch in BW aktualisiert,
wenn Änderungen am Objekt
vorgenommen werden
Die SAP-HANA-View wird nur
bei einem erneuten Import
aktualisiert
Transport Wird mit BW-Transport
transportiert
Wird mit SAP-HANA-Trans-
port transportiert
Unterstützte Objekttypen InfoCube, DataStore-Objekt
(klassisch und advanced), In-
foObject, Query als InfoProvi-
der, CompositeProvider,
Query
InfoCube, DataStore-Stan-
dardobjekt (klassisch), In-
foObject, Query als InfoProvi-
der
Berechtigungen Generierung von SAP-HANA-
Berechtigungen und automa-
tische Zuweisung zu SAP-HA-
NA-Benutzern; Berechti-
gungstyp: SQL-Analysebe-
rechtigung
InfoCube, DataStore-Stan-
dardobjekt (klassisch), In-
foObject, Query als InfoProvi-
der
Inhaltspakete Ein zentrales Inhaltspaket, in
dem alle SAP-HANA-Views
gespeichert werden
Kann für jedes Objekt konfi-
guriert werden
Manuelle Änderungen an dergenerierten View
Nicht zulässig; Änderungenwerden überschrieben
Zulässig; berechnete Attribu-te, berechnete Kennzahlenund eingeschränkte Kenn-
zahlen werden beibehalten –
wenn die SAP-HANA-Viewdurch einen erneuten Import
aktualisiert wird
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 158Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

167. Abbildung 152: Anwendungsserver und SAP-HANA-DB
Die Modellierungswerkzeuge für SAP BW powered by SAP HANA (kurz BW-
Modellierungswerkzeuge) stellen eine neue Modellierungs-IDE (Integrated Development
Environment) dar, die auf die Eclipse-Plattform aufsetzt.
Ihr Hauptziel besteht in der Unterstützung von BW-Modellentwicklern in zunehmend
komplexeren BI-Umgebungen, indem ihnen moderne Modellierungswerkzeuge bereitgestellt
werden. Diese Tools schließen die Integration in die SAP-HANA-Modellierung und die Nutzung
von SAP-HANA-Elementen in BW Open ODS Views oder CompositeProviders, mit
leistungsstarken UI-Funktionen (Benutzungsoberfläche), ein.
Notiz:
Lesen Sie zuerst Hinweis 1954169, und befolgen Sie die in diesem Hinweis
beschriebenen Client-Installationsanweisungen.
SAP First Guidance - Implementing BW-MT for BW-aDSO
https://scn.sap.com/docs/DOC-60425
Tabelle 5: BW-Modellierungswerkzeuge
Die folgende Tabelle enthält einen Überblick über die Versionen der BW-
Modellierungswerkzeuge sowie relevante Release-Informationshinweise. In diesen werden
Abhängigkeiten von ABAP-Entwicklungstools, SAP HANA Studio und SAP NetWeaver
Support Package Stacks beschrieben.
VersionDetails
Version 1.12 SAP-Hinweis 2233558
Version 1.11 SAP-Hinweis 2202179
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 159Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

168. VersionDetails
Version 1.8 Patch 0 SAP-Hinweis 2164033
Patch 1: SAP-Hinweis 2175822
Patch 2: SAP-Hinweis 2175886
Version 1.7 Patch 0: SAP-Hinweis 2067815
Patch 1: SAP-Hinweis 2138863
Patch 2: SAP-Hinweis 2149780
Version 1.6 Patch 0: SAP-Hinweis 2067814
Patch 1: SAP-Hinweis 2104488
Patch 2: SAP-Hinweis 2108620
Version 1.5 SAP-Hinweis 2067813
Version 1.4 SAP-Hinweis 2030817
Abbildung 153: Native Modellierung in SAP HANA Attribute View und Analytic View
Die folgende Liste enthält die Typen der Informationssichten:
●Attribute View
●Analytic View
●Calculation View
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 160Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

169. Alle drei Typen von Sichten sind nicht-materialisierte Sichten. Dies führt zu Flexibilität durch
die schnelle Bereitstellung von Änderungen, da es keine Latenzzeiten gibt, wenn sich die
zugrunde liegenden Daten ändern.
Attribute View
Mithilfe von Attribute Views können Sie eine Entität modellieren, die auf Beziehungen
zwischen in verschiedenen Quelldaten enthaltene Attributdaten basiert. Beispielsweise stellt
Kunden-ID die Attributdaten dar, die Kennzahlen beschreiben (d.h., wer hat das Produkt
gekauft). Kunden-ID gewinnt jedoch deutlich an Tiefe, wenn andere Attributdaten
hinzukommen, die den Kunden detaillierter beschreiben (Kundenadresse, Kundenbeziehung,
Kundenstatus, Kundenhierarchie usw.). Sie können eine Attribute View anlegen, um die
Attributdaten zu lokalisieren und die Beziehungen zwischen Tabellen zu definieren, um so zu
modellieren, wie beispielsweise Kundenattributdaten für Geschäftsanforderungen genutzt
werden.
Sie können folgende Elemente in einer Attribute View modellieren:
●Spalten
●Berechnete Spalten
●Hierarchien
Sie können das Verhalten der Attribute einer Attribute View weiter feinsteuern, indem Sie die
Eigenschaften folgendermaßen festlegen:
●Wenden Sie Filter an, um Werte einzuschränken, die bei der Verwendung der Attribute
View ausgewählt werden.
●Definieren Sie Attribute alsVerborgen, sodass sie in berechneten Attributen verwendet
werden können, für Endbenutzer aber nicht sichtbar sind.
●Definieren Sie Attribute als Schlüsselattribute. Der Join-Optimizer verwendet die als
Schlüsselattribute markierten Attribute zum Identifizieren einer zentralen (Haupt-)Tabelle.
Die zentrale Tabelle ist der Ausgangspunkt für alle Join-Pfade. Außerdem erleichtert das
Identifizieren der zentralen Tabelle das Optimieren des Join-Ausführungsprozesses.
●Legen Sie die Eigenschaft für aktiviertes Drilldown fest, um anzuzeigen, ob ein Attribut bei
Inanspruchnahme zum weiteren Drilldown verfügbar ist.
Attribute Views können später, bei der Definition einer Analytic View oder einer Calculation
View, zu Tabellen mit Kennzahlen zusammengeführt werden, um ein virtuelles Sternschema
für die SAP-HANA-Daten anzulegen.
Analytic View
Mit Analytic Views werden Daten modelliert, die Kennzahlen enthalten. Ein Data Mart mit
operativen Daten, das die Kundenauftragshistorie darstellt, würde beispielsweise Kennzahlen
für Menge, Preis usw. enthalten. Die Datengrundlage einer Analytic View kann mehrere
Tabellen umfassen. Jedoch dürfen die für eine Analytic View ausgewählten Kennzahlen nur
aus einer dieser Tabellen stammen. Meist können Sie Attribute Views in die Definition einer
Analytic View einschließen. Auf diese Weise können Sie eine zusätzliche Tiefe der
Attributdaten erreichen. Die Analytic View erbt die Definitionen aller Analytic Views, die Teil
der Definition sind.
Analytic Views können auch eine Kombination aus Tabellen sein, die sowohl Attributdaten als
auch Kennzahlendaten enthalten.
Sie können folgende Elemente in einer Analytic View modellieren:
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 161Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

170. ●Spalten
●Berechnete Spalten
●Eingeschränkte Spalten
●Variablen
●Eingabeparameter
Sie können das Verhalten der Attribute und Kennzahlen einer Attribute View weiter
feinsteuern, indem Sie die Eigenschaften folgendermaßen festlegen:
●Wenden Sie Filter an, um Werte einzuschränken, die bei der Verwendung der Analytic View
ausgewählt werden.
●Definieren Sie Attribute und Kennzahlen als „Verborgen“, sodass sie in berechneten
Spalten verwendet werden können, für Endbenutzer aber nicht sichtbar sind.
●Legen Sie die Eigenschaft für aktiviertes Drilldown fest, um anzuzeigen, ob ein Attribut bei
Inanspruchnahme zum weiteren Drilldown verfügbar ist.
●Legen Sie die Aggregationsart auf Kennzahlen fest.
●Weisen Sie den Attributen und Kennzahlen einen semantischen Typ zu.
●Verknüpfen Sie eine Kennzahl mithilfe der Kennzahltyp-Eigenschaft mit der Währung und
Maßeinheit.
Abbildung 154: Native Modellierung in SAP HANA Calculation Views
Calculation Views
Mit einer Calculation View werden erweiterte Ausschnitte der Daten in der SAP-HANA-
Datenbank definiert. Calculation Views können einfach sein und die in Attribute Views und
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 162Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

171. Analytic Views vorgefundene Funktionalität spiegeln. In der Regel werden sie jedoch
eingesetzt, wenn der geschäftliche Anwendungsfall eine erweiterte Logik erfordert, die von
den vorherigen Typen von Informationssichten nicht abgedeckt wird.
Calculation Views können Schichten von Berechnungslogik aufweisen, Kennzahlen aus
verschiedenen Quelltabellen beinhalten, über erweiterte SQL-Logik verfügen usw. Die
Datengrundlage der Calculation View kann eine beliebige Kombination aus Tabellen,
Spaltenansichten, Attribute Views und Analytic Views umfassen. Sie können Joins, Unions,
Projektionen und Aggregationsstufen für die Quellen anlegen.
Sie können folgende Elemente in einer Calculation View modellieren:
●Attribute
●Kennzahlen
●Berechnete Spalten
●Zähler
●Hierarchien (außerhalb der Attribute View angelegt)
●Variablen
●Eingabeparameter
Calculation Views können Kennzahlen beinhalten und für mehrdimensionales Reporting
verwendet oder keine Kennzahlen beinhalten und für ein Reporting in Listenart verwendet
werden. Calculation Views können entweder mit einem grafischen Editor oder mithilfe von
SQL Script angelegt werden. Diese Optionen bieten eine maximale Flexibilität für extrem
komplexe und umfassende geschäftliche Anforderungen.
Sie können das Verhalten der Attribute und Kennzahlen einer Calculation View weiter
feinsteuern, indem Sie die Eigenschaften folgendermaßen festlegen:
●Wenden Sie Filter an, um Werte einzuschränken, die bei der Verwendung der Calculation
View ausgewählt werden.
●Definieren Sie Attribute und Kennzahlen alsVerborgen, sodass sie in berechneten Spalten
verwendet werden können, für Endbenutzer aber nicht sichtbar sind.
●Legen Sie dieEigenschaft für aktiviertes Drilldown fest, um anzuzeigen, ob ein Attribut bei
Inanspruchnahme zum weiteren Drilldown verfügbar ist.
●Legen Sie dieAggregationsart auf Kennzahlen fest.
●Verknüpfen Sie eine Kennzahl mithilfe derKennzahltyp-Eigenschaft mit der Währung und
Maßeinheit.
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 163Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

172. Abbildung 155: Join-Typen
Referential-Join
Es ist semantisch betrachtet ein Inner-Join, der eine vorhandene referenzielle Integrität
voraussetzt, d.h., die linke Tabelle besitzt immer einen zugehörigen Eintrag in der rechten
Tabelle. Er ist eine Art optimierter, schnellerer Inner-Join, bei dem die rechte Tabelle nicht
geprüft wird, wenn kein Feld aus der rechten Tabelle angefordert wird. Das bedeutet,
Referential-Joins werden nur ausgeführt, wenn Felder aus beiden Tabellen angefordert
werden. Wenn ein Feld in der rechten Tabelle ausgewählt wird, verhält sie sich daher ähnlich
einem Inner-Join. Wird kein Feld in der rechten Tabelle ausgewählt, verhält sie sich ähnlich
einem Left-Outer-Join. Aus Leistungssicht ist der Left-Outer-Join fast genauso schnell wie ein
Referential-Joins, während der Inner-Join meist langsamer ist, da er immer ausgeführt wird.
Referential-Joins müssen mit Vorsicht verwendet werden, da sie von einer Einhaltung der
referenziellen Integrität ausgehen.
Die folgende Liste stellt das einzige gültige Szenario für den Referential-Join dar:
●Es ist sichergestellt, dass es für jede Zeile in einer Tabelle mindestens einen Join-Partner in
der anderen Tabelle gibt.
●Die Joins existieren in beide Richtungen.
●Integrität ist zu jedem Zeitpunkt gewahrt. Wenn dies nicht der Fall ist, können Referential-
Joins bei Nichteinhaltung der referenziellen Integrität falsche Berechnungen liefern. Wenn
also ein Lieferungskopf angelegt wird, die Elemente aber erst zu einem späteren Zeitpunkt
verarbeitet werden, sind alle Berechnungen, die Referential-Joins verwenden, falsch.
Inner-Join und Outer-Join
Die für eine View auswählbaren Daten hängen vorrangig davon ab, ob die View einen Inner-
Join oder einen Outer-Join implementiert. Bei einem Inner-Join erhalten Sie nur die
Datensätze der Kreuzprodukte, für die ein Eintrag in allen in der View verwendeten Tabellen
vorhanden ist. Bei einem Outer-Join werden auch Datensätze ausgewählt, für die in
bestimmten in der View verwendeten Tabellen kein Eintrag vorhanden ist. Die durch einen
Inner-Join bestimmte Treffermenge kann daher eine Teilmenge der Treffermenge eines
Outer-Join sein.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 164Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

173. Datenbank-Views implementieren einen Inner-Join. Die Datenbank stellt daher nur die
Datensätze bereit, für die es einen Eintrag in allen in der View verwendeten Tabellen gibt.
Help-Views und Pflege-Views implementieren dagegen einen Outer-Join. Der Left-Outer-Join
wählt sämtliche Datensätze aus der rechten Tabelle zusammen mit den passenden
Datensätzen (sofern verfügbar) aus der zweiten Tabelle aus. Wenn es keine Entsprechung
gibt, ist die rechte Seite null. Der Right-Outer-Join wählt sämtliche Datensätze aus der
zweiten Tabelle zusammen mit den passenden Datensätzen (sofern verfügbar) aus der ersten
Tabelle aus. Wenn es keine Entsprechung gibt, ist die linke Seite null.
Text-Join
Mit einem Text-Join werden sprachspezifische Daten abgerufen. Sie haben eine
Produkttabelle, die Produkt-IDs ohne Beschreibungen enthält, und Sie haben eine Texttabelle
für Produkte, die für jedes Produkt sprachspezifische Beschreibungen enthält. Sie können
eine Text-Join zwischen den zwei Tabellen erstellen, um die sprachspezifischen Details
abzurufen. Bei einem Text-Join sollte die rechte Tabelle die Texttabelle sein. Es ist
obligatorisch, die Sprachspalte anzugeben.
Notiz:
In Fällen, in denen der Text nicht sprachabhängig ist, können Sie LEFT OUTER
JOIN für die Beschreibung TEXT verwenden. In solchen Fällen, wo es keine
Sprachspalte gibt, können Sie den Text-Join nicht verwenden.
Stern-Joins
Mithilfe von Stern-Joins in Calculation Views können Sie eine Faktentabelle mit
Dimensionsdaten verknüpfen. Die Faktentabelle enthält Daten, die Geschäftsdaten wie Preis,
Rabattwert und Anzahl der verkauften Einheiten darstellen. Dimensionstabellen bieten
verschiedene Möglichkeiten zum Anordnen von Daten, z.B. nach Geografie, Zeitintervall und
Ansprechpartner.
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 165Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

174. Abbildung 156: Beispiele für SQL-Join-Vorgänge
●INNER JOIN
Gibt alle Zeilen zurück, wenn es mindestens eine Übereinstimmung in BEIDEN Tabellen
gibt.
●LEFT Outer JOIN
Gibt alle Zeilen aus der linken Tabelle und die übereinstimmenden Zeilen aus der rechten
Tabelle zurück.
●RIGHT Outer JOIN
Gibt alle Zeilen aus der rechten Tabelle und die übereinstimmenden Zeilen aus der linken
Tabelle zurück.
●FULL Outer JOIN
Gibt alle Zeilen zurück, wenn es eine Übereinstimmung in EINER der Tabellen in Zeilen aus
zwei oder mehr Tabellen gibt, basierend auf einem gemeinsamen Feld zwischen diesen.
Mit dem UNION-Operator wird die Ergebnismenge von zwei oder mehr SELECT-Anweisungen
zusammengefasst.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 166Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

175. Abbildung 157: Attribute View: Text-Join
Ein Text-Join für die SpaltenCOUNTRY.KEYundCOUNTRY_TEXT.KEY mit derLanguage-
SpalteLANGverhält sich entsprechend der Sitzungssprache des Benutzers und ruft die
landesspezifische Beschreibung in der entsprechenden Sprache ab.
Abbildung 158: Spaltenansichten in SAP HANA
_SYS_BIC:
Dieses Schema enthält alle Spaltenansichten der aktivierten Objekte. Wenn der Benutzer die
Attribute View/Analytic View/Calculation View/Analyseberechtigung/Prozedur aktiviert,
werden die jeweiligen Laufzeitobjekte unter _SYS_BIC/Column Views angelegt.
_SYS_REPO:
Alle im System vorhandenen Objekte sind auch im Repository vorhanden. Dieses Schema
enthält die Liste der aktivierten Objekte, inaktiven Objekte, Paketdetails und Informationen zu
Laufzeitobjekten. Darüber hinaus benötigen _SYS_REPO-Benutzer die SELECT-Berechtigung
mit Gewähroption für das Datenschema.
_SYS_BI:
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 167Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

176. In diesem Schema werden alle Metadaten der angelegten Spaltenansichten gespeichert. Es
enthält die Tabellen für angelegte Variablen-, Zeitdaten- (Geschäftsjahr, Gregorianischer
Kalender), Schemazuordnungs- und Inhaltszuordnungstabellen.
_SYS_STATISTICS:
Dieses Schema enthält alle Systemkonfigurationen und -parameter.
_SYS_XS:
Dieses Schema wird für SAP HANA Extended Application Services verwendet.
Abbildung 159: Inhalte für SAP HANA erstellen und verwenden
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 168Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

177. Abbildung 160: Calculation View (grafisch) – Assistent zum Anlegen von Views
Eine Calculation View ist eine leistungsfähige und flexible Informationssicht, mit der Sie
erweiterte Ausschnitte für in der SAP-HANA-Datenbank verfügbare Daten definieren können.
Calculation Views sind einfach und spiegeln u.a. die in Attribute Views und Analytic Views
vorgefundene Funktionalität.
In der Regel werden Calculation Views jedoch eingesetzt, wenn der geschäftliche
Anwendungsfall eine erweiterte Logik erfordert, die Sie mit Analytic Views und Attribute
Views nicht erreichen können. Sie können beispielsweise Calculation Views mit Schichten von
Berechnungslogik anlegen, die Kennzahlen aus verschiedenen Quelltabellen, erweiterte SQL-
Logik usw. enthalten. Die Datengrundlage der Calculation View kann eine beliebige
Kombination aus Tabellen, Spaltenansichten, Attribute Views und Analytic Views umfassen.
Sie können Joins, Unions, Projektionen und Aggregationsstufen für Datenquellen anlegen.
Calculation Views können Kennzahlen beinhalten und für mehrdimensionales Reporting
verwendet oder keine Kennzahlen beinhalten und für ein Reporting in Listenart verwendet
werden.
Mit den grafischen Modellierungsfunktionen von SAP HANA Modeler können Sie eine
Calculation View anlegen, um ein komplexes Geschäftsszenario abzubilden, das Schichten
mit Berechnungslogik aufweist und Kennzahlen aus mehreren Quelltabellen beinhaltet.
Basierend auf den folgenden Anforderungen können Sie die Calculation-View-Eigenschaft für
die Datenkategorie auf Cube oder Dimension festlegen:
●Cube
Wenn Sie eine Calculation View definieren möchten, die in den Reporting-Werkzeugen
sichtbar ist. Sie müssen mindestens eine Kennzahl definieren, und der Standardknoten ist
„Aggregation“ oder „Stern-Join“ (basierend auf der Auswahl im Erstellungsassistenten).
Der Stern-Join-Knoten stellt die Plattform zum Verknüpfen der beschreibenden Daten
bereit, d.h., Dimensionen aus den Calculation Views vom Typ Dimension mit Faktdaten aus
den untergeordneten Knoten. Auf diese Weise erstellen Sie ein logisches Sternschema, bei
dem der Join von der zentralen Entität zu anderen Entitäten angelegt wird. Sie können
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 169Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

178. jedoch auch ein Schneeflockenschema anlegen, indem Sie Views mit der zentralen Entität
verknüpfen. In einem Stern-Join werden Calculation Views mit der Datenkategorie
Dimension als Shared Dimensions behandelt. Alle Attribute und Hierarchien dieser Shared
Dimensions werden der Ausgabe der Calculation View hinzugefügt. Beim Deployment wird
der Stern-Join immer mit einem zusätzlichen Aggregationsknoten bereitgestellt. Zuerst
wird der Stern-Join mit einer Reihe von Joins und dann die Aggregationslogik verteilt.
●Dimension
Wenn Sie eine einfache SQL-ähnliche Calculation View definieren möchten, die
beispielsweise dazu verwendet wird, einfache Benutzungsoberflächen auszufüllen, auf
denen wiederkehrende Attributwerte erforderlich sind. Zur Definition dieses View-Typs
definieren Sie keine Kennzahlen. Wenn Sie eine derartige View definieren, zeigt diese
folgendes Verhalten:
-Der Ausgabeknoten bietet keine Kennzahlen (oder Hierarchien) sondern nur Attribute
an, die nummerische Datentypen sein können
-Die Calculation View ist für das Reporting nicht verfügbar
-Die Calculation View kann nur mittels SQL genutzt werden
-Der Standardknoten ist „Projektion“
Abbildung 161: Calculation View (grafisch) – Ausgabeknoten
Attribute enthalten eine Teilmenge von Spalten, die als Bedingungen, Aktionen und in
berechneten Attributen verwendet werden können. Wählen Sie zum Löschen von Attributen
aus dem Knoten „Attribute“ die Option „Entfernen“ aus dem Kontextmenü des
Ausgabebereichs. Sie können jedoch keine Attribute löschen, die bereits als Aktionen oder
Bedingungen verwendet werden.
Sie können auch Objektreferenzen für Elemente im Ausgabebereich überprüfen. Wählen Sie
ein Objekt aus, und wählen Sie dann „Referenzen“ aus dem Kontextmenü. Im Detailbereich
können Sie ein Element aus den Registerkarten für Parameter, Variablen oder Spalten
auswählen.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 170Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

179. Abbildung 162: Calculation View (grafisch) – Berechnete Spalte
Berechnete Spalten erstellen
Legen Sie neue Ausgabespalten an, und berechnen Sie die zugehörigen Werte zur Laufzeit
basierend auf dem Ergebnis eines Ausdrucks. Sie können im Ausdruck andere Spaltenwerte,
Funktionen, Eingabeparameter oder Konstanten verwenden.
Kontext
Sie können beispielsweise eine berechnete Spalte DISCOUNT mithilfe des Ausdrucks
if("PRODUCT" = 'NOTEBOOK', "DISCOUNT" * 0.10, "DISCOUNT") anlegen. In diesem
Musterausdruck verwenden Sie die Funktion if(), die Spalte PRODUCT und den Operator *,
um Werte für die berechnete Spalte DISCOUNT zu erhalten.
Notiz:
Markieren Sie das Ankreuzfeld „Enable client side aggregation“, wenn Sie eine
berechnete Kennzahl erstellen und die clientseitige Aggregation für die
berechnete Kennzahl aktivieren möchten. Auf diese Weise können Sie die
Aggregation vorschlagen, die der Client für die Arbeit mit berechneten Kennzahl
benötigt.
Sie können einen Ausdruck auch anlegen, indem Sie die Ausdruckselemente,
Operatoren und Funktionen aus den Menüs des Ausdruckseditors per Drag&Drop
anordnen. Bei Ausdrücken in der SQL-Sprache unterstützt Modeler nur eine
begrenzte Anzahl von SQL-Funktionen.
Eigenschaften berechneter Spalten
Nach dem Erstellen eines berechneten Attributs oder einer berechneten Kennzahl können Sie
die zugehörigen Eigenschaften anzeigen oder sie entsprechend Ihrer fachlichen
Anforderungen ändern. Wählen Sie eine berechnete Spalte im Semantikknoten aus. Modeler
zeigt die folgenden Eigenschaften für berechnete Spalten im Eigenschaftsbereich an.
Data Type
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 171Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

180. Der Wert dieser Eigenschaft gibt den Datentyp der berechneten Attribute oder der
berechneten Kennzahlen an.
Semantic Type
Der Wert dieser Eigenschaft gibt den semantischen Typ der berechneten Attribute oder der
berechneten Kennzahlen an.
Hidden
Der Wert dieser Eigenschaft bestimmt, ob die berechnete Spalte in den Reporting-
Werkzeugen ausgeblendet ist.
Drill Down Enablement
Der Wert dieser Eigenschaft bestimmt, ob das berechnete Attribut in den Reporting-
Werkzeugen für Drilldowns aktiviert ist. Wenn es aktiviert ist, gibt der Wert dieser Eigenschaft
den Drilldown-Typ an.
Display Folder
Wenn die berechnete Kennzahl in einem der Anzeigeordner gruppiert ist, gibt der Wert dieser
Eigenschaft den Anzeigeordner an, der zum Gruppieren der zugehörigen Kennzahlen
verwendet wurde.
Abbildung 163: Calculation View (grafisch) – Union-Zuordnung
Ein Union-Knoten kombiniert mehrere Datenquellen, die über mehrere Spalten verfügen
können. Sie können die Ausgabe eines Union-Knotens verwalten, indem Sie die Quellspalten
den Ausgabespalten zuordnen oder indem Sie eine Zielausgabespalte mit Konstantenwerten
anlegen.
Für eine Quellspalte ohne zugeordnete Ausgabespalten können Sie eine Zielausgabespalte
anlegen und diese den nicht zugeordneten Quellspalten zuordnen. Sie können auch eine
Zielspalte mit Konstantenwerten anlegen.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 172Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

181. Abbildung 164: Calculation View (grafisch) – Semantischer Knoten
Der Bereich „Scenario“ des Editors umfasst folgende Standardknoten:
●Knoten „Aggregation/Projection“
Dieser Knoten basiert auf dem von Ihnen ausgewählten Wert für die Datenkategorie. Wenn
der Wert auf „Cube“ gesetzt ist, ist der Standardknoten ein Aggregationsknoten. Ist die
Eigenschaft auf „Dimension“ gesetzt, ist der Standardknoten ein Projektionsknoten. Wenn
Sie eine grafische Calculation View mit Stern-Join anlegen, ist der Standardknoten ein
Stern-Join-Knoten.
●Semantics
Dieser Knoten stellt die Ausgabestruktur der View dar.
Der Bereich „Details“ besteht aus folgenden Registerkarten:
●View Properties
Auf dieser Registerkarte werden die grundlegenden View-Eigenschaften angezeigt.
●Column
Diese Registerkarte enthält lokale Spalten der Analytic View, die Sie als Attribute oder
Kennzahlen definieren können. Wenn Sie einen Stern-Join-Knoten verwenden, enthält die
Registerkarte „Column“ auch die gemeinsamen Spalten der zugrunde liegenden Views.
●Hierarchies
Diese Registerkarte enthält die Hierarchien der zugrunde liegenden Calculation Views für
Dimensionen und die für die Calculation View definierten Hierarchien.
●Parameters/Variables
Diese Registerkarte umfasst Variablen und Eingabeparameter, die Sie zum Filtern von auf
Attributdaten basierenden, zur Laufzeit bereitgestellten Werten bzw. zum Parametrisieren
von Informationssichten verwenden.
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 173Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

182. Notiz:
Wenn Sie eine Attribute View als Datenquelle zum Modellieren der Calculation
View verwenden, werden im Abschnitt „Shared“ Attribute aus den Attribute Views
angezeigt, die in der Calculation View verwendet werden.
Die Datengrundlage der Calculation View kann eine beliebige Kombination aus Tabellen,
Spaltenansichten, Attribute Views und Analytic Views umfassen. Sie können Folgendes
anlegen: Joins, Unions, Projektionen und Aggregationsstufen für Datenquellen
●Union: Verwenden Sie den Union-Knoten, um die Ergebnismenge von zwei oder mehr
Datenquellen zu kombinieren. Union-Knoten haben zwei oder mehr Inputs. Beispielsweise
zum Abrufen der Namen aller Mitarbeiter einer Filiale, die mehrere Zweigstellen mit jeweils
eigener Mitarbeiterdatentabelle hat.
●Join: Verwenden Sie Join-Knoten, um Daten von zwei oder mehr Datenquellen basierend
auf einer bestimmten Bedingung abzufragen. Join-Knoten haben zwei Inputs.
Beispielsweise zum Abrufen von Kundendetails und zum Standort von Kunden basierend
auf der Postleitzahlspalte aus den zwei Tabellen CUSTOMER und GEOGRAPHY. Die
Tabelle CUSTOMER hat die Spalten Customer_ID, Customer_Name, Postal_Code und die
Tabelle GEOGRAPHY die Spalten Postal_Code, Region, Country.
●
Projektion: Mit dem Projektionsknoten können Sie eine Teilmenge der erforderlichen
Spalten einer Tabelle oder einer Informationssicht filtern oder abrufen. Projektionsknoten
haben einen Input. Beispielsweise zum Auswählen des Mitarbeiternamens und der Mitarbeiterabteilung aus einer aus vielen anderen Spalten bestehender Tabelle.
●
Aggregation: Verwenden Sie den Aggregationsknoten zum Zusammenfassen von Daten
für eine Gruppe von Zeilenwerten, durch Berechnen von Werten in einer Spalte. Aggregationsknoten haben einen Input. Beispielsweise zum Abrufen des Gesamtumsatzes
eines Produktes in einem Monat. Die unterstützten Aggregationsarten sind sum, min und
max.
●
Rang: Verwenden Sie den Rangknoten, um die Daten für einen Satz von Partitionsspalten
zu partitionieren und einen Sortiervorgang für die partitionierten Daten durchzuführen.
Rangknoten haben einen Input. Stellen Sie sich beispielsweise eine Tabelle TRANSACTION
mit zwei Spalten PRODUCT und SALES vor. Zum Abrufen der Top-5-Produkte basierend
auf dem Umsatz würden Sie einen Rangknoten verwenden.
●
Stern-Joins: Mithilfe von Stern-Joins in Calculation Views können Sie eine Faktentabelle
mit Dimensionsdaten verknüpfen. Die Faktentabelle enthält Daten, die Geschäftsdaten wie Preis, Rabattwert und Anzahl der verkauften Einheiten darstellen. Dimensionstabellen
bieten verschiedene Möglichkeiten zum Anordnen von Daten, z.B. nach Geografie,
Zeitintervall und Ansprechpartner.
Für den Aggregationsknoten werden die Kennzahlen zur Laufzeit automatisch auf der durch
die Group By-Klausel definierten Ebene aggregiert. In diesem Fall wird der Output-Knoten als
Aggregationsknoten im Laufzeitmodell bereitgestellt, das während des Deployment erstellt
wird. Darüber hinaus werden die Modellinformationen in die BI-Metadatennutzungstabellen
geschrieben und damit den BI-Clients von SAP HANA für das Reporting bereitgestellt.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 174Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

183. Notiz:
Wenn der Standardknoten „Aggregation“ ist und die Eigenschaft „Always
Aggregate Result“ des Knoten „Semantics“ auf „True“ festgelegt ist, wird die
Ausgabe von Kennzahlen immer aggregiert dargestellt.
Abbildung 165: Calculation View (grafisch) – Datenfluss erstellen
●Der Input für Union-, Join-, Projektions- und Aggregations-View-Knoten kann aus
Datenquellen, Union-, Join-, Projektions- und Aggregations-View-Knoten bestehen.
●Es kann nur eine Input-Quelle für Aggregations- und Projektions-View-Knoten geben und
zwei Inputs für einen Join.
●Sie können diese View-Knoten sogar zwischen zwei verbundenen View-Knoten einfügen.
Wenn Sie einen View-Knoten aus der Tools Palette auf die Datenquelle (d.h. Tabellen,
Attribute Views, Analytic Views und Calculation Views) eines View-Knoten ziehen, wird die
Datenquelle durch den neu hinzugefügten View-Knoten so ersetzt, dass der neue View-
Knoten die Datenquelle als Input hat. Wenn Sie beispielsweise den Projektions-View-
Knoten auf die Datenquelle DS1 des vorhandenen Aggregations-View-Knoten ziehen,
würde der Aggregations-View-Knoten den Projektions-View-Knoten als Datenquelle haben,
und DS1 wäre die Datenquelle des Projektionsknoten.
●Bei Join-Knoten (einschließlich Stern-Join-Knoten) ist die Eigenschaft „Optimize Join
Columns“ im Eigenschaftsbereich standardmäßig auf den Wert „False“ gesetzt. Diese
Eigenschaft erzwingt, dass eine Query die Join-Spalten aus der Datenbank abruft, auch
wenn dies in der Query nicht so festgelegt ist. Mit anderen Worten, diese Spalten werden in
den Join und in die Group By-Klausel einbezogen, auch wenn sie in der Query nicht
ausgewählt wurden. Sie können die Join-Eigenschaft „Optimize Join Columns“ auf „True“
setzen, um die Join-Ausführung zu optimieren (z.B. wenn der Join-Knoten viele Join-
Attribute enthält). Indem Sie die Eigenschaft auf „True“ setzen, können Sie vermeiden,
dass die Join-Spalten abgerufen werden, die nicht Teil der Query sind. Jedoch kann der
Join-Optimizer nicht die Attribute entfernen, die von statischen Filtern verwendet werden,
Lektion: Einführung in die native SAP-HANA-Modellierung
©Copyright. Alle Rechte vorbehalten. 175Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

184. wenn diese Filter für Join-Spalten definiert sind, für die die Eigenschaft „Optimize Join
Column“ auf „True“ gesetzt ist.
Bei einer aktiven Calculation View können Sie die Ausgabedaten eines Zwischenknoten in der
Vorschau anzeigen. Auf diese Weise kann jede Ebene eine komplexen Berechnungsszenarios
getestet werden (mit Join-, Union-, Aggregations-, Projektions- und Output-Knoten). Wählen
Sie die Option „Data Preview“ aus dem Kontextmenü eines Knoten. Wenn Sie die Daten eines
Zwischenknoten in der Vorschau anzeigen, aktiviert SAP HANA Studio das
Zwischenberechnungsmodell für den aktuellen Benutzer anstatt für den Benutzer
_SYS_REPO. Die in der Vorschau angezeigten Daten für einen Knoten sind für die aktive
Version der Calculation View. Wenn keine aktive Version des Objekts vorhanden ist, müssen
Sie zuerst das Objekt aktivieren. Die Projektion ist zwischen dem Join- und dem anfänglichen
Input-Knoten (mit Filter). Die Optimierung der Join-Spalten wird nur für Left-Outer-Join oder
Text-Join (mit Kardinalität 1:1 oder N:1) und Right-Outer-Join (mit Kardinalität 1:1 oder 1:N)
unterstützt.
Abbildung 166: Übung zum Anlegen von Calculation Views mit Stern-Joins
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●SAP HANA Calculation Views mit SAP-HANA-Modellierung anlegen
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 176Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

185. Kapitel 4
Lektion 4
Kombinieren von SAP Business Warehouse
(SAP BW) InfoProvider mit SAP-HANA-Views
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird erläutert, wie Sie einen SAP-BW-InfoProvider mit SAP-HANA-Views
kombinieren. Außerdem wird auf das Erstellen von CompositeProvidern eingegangen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●SAP-BW-InfoProvider mit SAP-HANA-Views kombinieren
CompositeProvider mit SAP-HANA-View
Abbildung 167: CompositeProvider mit HANA-Views
In einem CompositeProvider können Sie Daten aus BW-InfoProvidern mit Daten aus SAP-
HANA-Views mithilfe von Union und Join zusammenführen.
In den Eclipse-basierten BW-Modellierungswerkzeugen können BW-Entwickler flexibel Daten
aus mehreren InfoProvidern und SAP-HANA-Sichten kombinieren. Dieser CompositeProvider
wird der zentrale CompositeProvider sein, der die virtuelle Data-Mart-Schicht bildet, die
Daten für das Reporting und für Analysen bei Verwendung einer SAP-HANA-Datenbank
bereitstellt. Er ersetzt den Ad-hoc-Composite-Provider, wenn Sie SAP HANA verwenden. Das
©Copyright. Alle Rechte vorbehalten. 177Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

186. Verfahren „So erstellen Sie einen CompositeProvider“ demonstriert Ihnen, wie Sie einen
CompositeProvider erstellen.
Abbildung 168: DWH-Modellierungsansatz – Funktion und Integration
In SAP BW müssen Sie in Stacks modellieren. Zuerst modellieren Sie den Integrations-Stack
und dann den funktionalen Stack. Sie sehen dies auf der linken Seite der Abbildung „DWH-
Modellierungsansatz – Funktion und Integration“. Auf der rechten Seite sehen wir das
sofortige Modell – Funktion vor Integration (Feldebenenansatz). Hier besteht Ansatz darin,
einen minimalen Bedeutungsumfang für die Daten festzulegen, sodass Sie eine Query sofort
ausführen können, ohne InfoObjects, Transformationen usw. anlegen zu müssen. SAP BW
ohne SAP HANA ist für sich genommen ein leistungsfähiges Integration-Framework. Sie
arbeiten mit an BW ausgerichteten Stacks – Modellierung von Integration und Funktion –, die
normalerweise auf InfoObjects basieren. Ohne InfoObjects können Sie keine Daten
modellieren.
In BW mit HANA existieren zwei Arten von Modellierung nebeneinander. Sie können also den
üblichen Modellierungsansatz mit InfoObjects wählen oder basierend auf Feldern modellieren.
Die für SAP BW 7.5 powered on HANA entwickelte Funktionalität wurde aus
architektonischer, nicht aus technologiescher Sicht erstellt. Funktionsmodellierung ist jetzt
möglich, ohne dass alle Integrationsaspekte verloren gehen.
HANA kann Daten in der vorliegenden Form verwenden. Ohne vorherige Transformation der
Daten in spezielle Analysestrukturen können Sie mit virtuellen Objekten direkt an beliebigen
Daten auf Feldebene arbeiten. Die engere Verbindung der Quellsysteme mit BW bedeutet,
dass es etwas zwischen der Quelle und dem vollwertigen und Top-Down-modellierten EDW
geben muss, das von InfoObjects beschrieben wird. Hierzu dient die Open-ODS-Schicht.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 178Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

187. Abbildung 169: HANA-BW-Open-Service-Framework
BW auf SAP HANA und Logical Data Warehousing
Wir haben das Lösungsportfolio eines Data Warehouse erweitert und flexibler gestaltet, so
dass auch Remote-Daten Komponenten einer Data-Warehouse-basierten Lösung sein
können. Das setzt voraus, dass BW solche Remote-Daten interpretieren und ihnen Bedeutung
zuweisen kann. Da alle Daten außerhalb von BW in Form von Feldern definiert sind, liegt eine
wesentliche Voraussetzung für die virtuelle Integration solcher Daten in der feldbasierten
Modellierung auf der Basis von Open-ODS-Views.
Neue Off enheit von BW auf HANA.
Wir haben alle Erfahrungen damit gesammelt, was die Integration von Nicht-SAP-Rohdaten in
BW bedeutete. Sie mussten immer InfoObjects definieren und den Rohdatenfeldern
zuweisen. Dies ist nicht länger Voraussetzung für die Integration von Daten in BW, da BW auf HANA 7.40 über die sogenannte Feldbasierte Modellierung verfügt. Feldbasierte Modellierung heißt, dass Sie jetzt Daten mit deutlich weniger Aufwand als zuvor in BW integrieren können.
Dabei spielt es keine Rolle, ob Sie Daten in BW laden oder sich die Daten außerhalb von BW
befinden: Sie können jetzt Daten auf Feldebene direkt modellieren und mit ihnen arbeiten,
ohne vorher InfoObjects definieren und anschließend die Felder InfoObjects zuordnen zu
müssen. Dies erleichtert die Integration beliebiger Daten erheblich. Wie wird dies erreicht? Die
neuen Advanced DSOs gestatten das Speichern von Feldebenendaten in BW. Advanced DSOs
können ausschließlich Felder, eine Mischung mit InfoObjects oder nur InfoObjects haben, wie
die alten DSOs. Zusätzlich zu den BW Advanced DSOs mit Feldern oder einer beliebigen SQL/
HANA-View außerhalb von BW definieren Sie BW-auf-HANA-Open-ODS-Views, um
wiederverwendbare BW-Semantiken zu modellieren, die Fakten, Stammdaten und
Semantiken von Feldern, wie Währungsfelder oder Textfelder, identifizieren. Darüber hinaus
können Sie in Open ODS Views Zuordnungen zwischen Open ODS Views und InfoObjects
definieren, d.h., Sie modellieren virtuelle Sternschemas. Schließlich können Sie Open ODS
Views in einer Query oder kombiniert mit anderen Providern in einem CompositeProvider, wie
einem beliebigen InfoProvider, verwenden. BW auf HANA ist in der Lage, Rohdaten
unabhängig von ihrem Speicherort zu modellieren und zu verarbeiten. Diese Rohdaten
Lektion: Kombinieren von SAP Business Warehouse (SAP BW) InfoProvider mit SAP-HANA-Views
©Copyright. Alle Rechte vorbehalten. 179Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

188. können in die harmonisierte InfoObject-Welt integriert werden, indem InfoObjects in Open
ODS Views mit Feldern verknüpft werden.
Das Konzept der Arbeit mit Rohdaten in BW und die frühe und einfache Integration der
Rohdatenergebnisse in die neue Open-ODS-Schicht führt zu einer engeren Verbindung
zwischen BW und Quellen.
Abbildung 170: Übung zur Erweiterung von CompositeProvider mit SAP HANA View
So erstellen Sie einen CompositeProvider
Erstellen Sie den CompositeProvider. Sie befinden sich in den BW-Modellierungswerkzeugen.
Dieses Verfahren demonstriert Ihnen, wie Sie mit einem Assistenten einen
CompositeProvider erstellen.
1.Definieren Sie die Eigenschaften für die CompositeProvider-Laufzeit.
2.Generieren Sie aus dem CompositeProvider eine SAP-HANA-View.
3.Setzen Sie das KennzeichenThis CompositeProvider can be added to another
CompositeProvider, um den CompositeProvider als einen Provider in einem anderen
CompositeProvider zu verwenden.
4.UnterCommon Runtime Propertieskönnen Sie verschiedene Einstellungen für die Query-
Laufzeit konfigurieren. Runtime Profile Properties enthält die Einstellungen für die
Verarbeitung des CompositeProvider.
In den meisten Fällen können Sie diese Einstellungen unverändert lassen. Dies sind
Experteneinstellungen, die später bei Bedarf geändert werden können.
Kapitel 4: Native Modellierung in SAP HANA
©Copyright. Alle Rechte vorbehalten. 180Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

189. 5.Wählen Sie andere beteiligte InfoProvider oder SAP-HANA-Views aus, und nehmen Sie
Zuweisungen vor.
6.Definieren Sie das Erscheinungsbild des CompositeProvider in der Query.
7.Aktivieren Sie den CompositeProvider.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●SAP-BW-InfoProvider mit SAP-HANA-Views kombinieren
Lektion: Kombinieren von SAP Business Warehouse (SAP BW) InfoProvider mit SAP-HANA-Views
©Copyright. Alle Rechte vorbehalten. 181Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

190. Kapitel 4
Überprüfung des Lernerfolgs
1.SAP HANA Studio wurde in Java entwickelt und basiert auf der Eclipse-Plattform?
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
2.Bei der Datenbereitstellung können Dateien nur mit dem Import-Assistenten in die
Workbench importiert werden.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
3.Wofür steht SAP HANA DXC?
4.Passen Sie den Typ des Joins der Beschreibung an.
Ordnen Sie die Einträge der ersten Spalte den entsprechenden Einträgen der zweiten
Spalte zu.
Referential-Join
Inner-Join
Text-Join
Start-Join
Wird verwendet, wenn referen-
zielle Integrität erzwungen
wird.
Mit diesem Join können Sie die
Faktdaten mit den beschreib-
enden Daten verknüpfen.
Dieser Join gibt Zeilen zurück,
wenn es mindestens eine
Übereinstimmung in beiden
Tabellen gibt.
Für diesen Join muss eine Be-
schreibungszuordnung defi-
niert sein.
©Copyright. Alle Rechte vorbehalten. 182Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

191. 5.Welches Schema enthält alle Systemkonfigurationen und -parameter?
6.In SAP BW müssen Sie in Stacks modellieren. Nennen Sie zwei Stacks.
Kapitel 4: Überprüfung des Lernerfolgs
©Copyright. Alle Rechte vorbehalten. 183Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

192. Kapitel 4
Überprüfung des Lernerfolgs - Antworten
1.SAP HANA Studio wurde in Java entwickelt und basiert auf der Eclipse-Plattform?
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
2.Bei der Datenbereitstellung können Dateien nur mit dem Import-Assistenten in die
Workbench importiert werden.
Entscheiden Sie, ob diese Aussage richtig oder falsch ist.
XRichtig
XFalsch
3.Wofür steht SAP HANA DXC?
Direct Extractor Connection
4.Passen Sie den Typ des Joins der Beschreibung an.
Ordnen Sie die Einträge der ersten Spalte den entsprechenden Einträgen der zweiten
Spalte zu.
Referential-Join
Inner-Join
Text-Join
Start-Join
Wird verwendet, wenn referen-
zielle Integrität erzwungen
wird.
Dieser Join gibt Zeilen zurück,
wenn es mindestens eine
Übereinstimmung in beiden
Tabellen gibt.
Für diesen Join muss eine Be-
schreibungszuordnung defi-
niert sein.
Mit diesem Join können Sie die
Faktdaten mit den beschreib-
enden Daten verknüpfen.
©Copyright. Alle Rechte vorbehalten. 184Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

193. 5.Welches Schema enthält alle Systemkonfigurationen und -parameter?
_STS_STATISTICS
6.In SAP BW müssen Sie in Stacks modellieren. Nennen Sie zwei Stacks.
Integrations- und funktionale Stacks
Kapitel 4: Überprüfung des Lernerfolgs - Antworten
©Copyright. Alle Rechte vorbehalten. 185Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

194. KAPITEL 5Open ODS Views
Lektion 1
Anlegen von Open ODS Views 187
Lektion 2
Anlegen von DataSources aus Open ODS View 201
LERNZIELE
●Open ODS Views anlegen
●DataSources aus Open ODS View anlegen, um Daten persistent in SAP Business
Warehouse (SAP BW) zu speichern
©Copyright. Alle Rechte vorbehalten. 186Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

195. Kapitel 5
Lektion 1
Anlegen von Open ODS Views
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird erläutert, wie Open ODS Views für den virtuellen Zugriff auf externe
Quellen angelegt werden.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●Open ODS Views anlegen
Open ODS Views
Abbildung 171: Konsolidierung von BW-Objekten
Die herkömmlichen InfoProvider wird es auch in Zukunft geben. Die zukünftigen Innovationen
konzentrieren sich jedoch auf die neuen konsolidierten BW-Objekte von BW 7.5 auf HANA.
Open ODS Views sind die neuen Objekte für den virtuellen Zugriff externer Quellen.
CompositeProvider bieten eine neue Art der Verknüpfung von Daten und deren Darstellung in
der Reporting-Schicht. Ein CompositeProvider ist ein InfoProvider, der Daten aus SAP-HANA-
Views oder von anderen klassischen BW-InfoProvidern per Join oder Union kombiniert und
diese Daten für das Reporting und für Analysen zur Verfügung stellt. CompositeProvider
können direkt HANA-Views enthalten. Die Modellierung eines CompositeProviders zusätzlich
zu einer HANA-View ermöglicht es Ihnen, zusätzlich zu den reinen SAP-HANA-Objekten das
BEx-Reporting zu definieren.
©Copyright. Alle Rechte vorbehalten. 187Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

196. Abbildung 172: Open ODS View – Überblick
Open ODS View
Open ODS Views ermöglichen es Ihnen, BW-Datenmodelle für Objekte wie
Datenbanktabellen, Datenbank-Views und BW DataSources (für den Direktzugriff ) zu
definieren. Diese Datenmodelle ermöglichen eine flexible Integration, ohne dass InfoObjects
angelegt werden müssen. Dieser flexible Datenintegrationstyp ermöglicht die Verwendung
von externen Datenquellen in BW ohne Staging, die Kombination von Datenquellen mit BW-
Modellen und die physische Integration (Ladung) von externen Datenquellen durch Anlegen
von DataSources.
Die Open ODS View ist ein BW-Metadatenobjekt, das eine Strukturbeschreibung mit
Attributen (Feldern) und Datentypen bereitstellt. Sie stellt eine Sicht auf eine Quelle dar und
fügt analytische Metadaten zu dieser Quelle hinzu. Unterstützte Datenquellen sind Objekte,
die ihre Daten in einer Struktur mit Attributen und Datentypen (wie Datenbanktabellen),
Views und BW DataSources beschreiben. Die Open ODS View hat keinen separaten Speicher
für Bewegungsdaten und Stammdaten. Persistenz und analytische Modellierung sind für die
Open ODS View entkoppelt.
Obwohl die klassische Modellierung mit InfoObjects eine hohes Maß an Konsistenz im
Datenmodell gewährleistet, lässt sich vorhandene, bereits für das Reporting oder für
Analysen verwendete Modellierung schwer ändern. Die Modellierung mit Open ODS Views ist
wesentlich flexibler. Sie können eine Open ODS View mit minimalem Aufwand für eine
Datenquelle anlegen und den Feldern der Open ODS View Eigenschaften zuordnen.
Insbesondere beim Definieren der Struktur der Open ODS View können Sie angeben, ob ein
bestimmtes Feld als Kennzahl oder Merkmal interpretiert werden soll. Eine auf diese Weise modellierte Open ODS View stellt Daten für die Verwendung zur Verfügung (z.B. bei einer Query). Die View kann nach und nach für die weitere Integration in BW erweitert werden.
Verwendung, Kombination und physische Integration von Daten
●Externe Daten ohne Staging verwenden
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 188Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

197. Die Open ODS View ermöglicht die virtuelle Verwendung von Datenquellen, ohne dass eine
separate BW-Persistenz für die Daten benötigt wird. Diese Datenmodelle können sich in
einem Datenbankschema (der SAP-HANA-Datenbank in BW) befinden, das nicht von BW
verwaltet wird. Alternativ dazu können sich die Modelle in anderen Datenbanken befinden,
die über SAP HANA Smart Data Access mit der SAP-HANA-Datenbank in BW verbunden
werden können.
●Externe Daten mit BW-Modellen kombinieren
Unter Verwendung von Links zu InfoObjects können Sie Open ODS Views mit BW-Modellen
kombinieren und dabei beispielsweise Stammdatenattribute und Texte in BW verwenden.
Es gibt noch eine andere Möglichkeit, die Open ODS View mit BW-Modellen zu
kombinieren: die Verwendung des CompositeProviders.
●Physische Integration von externen Daten (Staging)
Sie können für ETL-Zwecke DataSources für Open ODS Views anlegen und dabei physisch
Datenquellen in BW integrieren. In diesem Fall wird die Persistenz der Open ODS View
durch ein DataStore-Objekt (advanced) gewährleistet, das hier mit einer Persistent
Staging Area (PSA) vergleichbar ist, von der aus die Daten weiterverarbeitet werden
können.
Der Grad der Integration für Datenmodelle kann iterativ weiterentwickelt werden, ohne
Modellierungsobjekte (z.B. Querys), die auf diesen Modellierungsobjekten basieren, zu
invalidieren. Sie können beispielsweise eine einfache Open ODS View mit
Standardeigenschaften für die Felder modellieren. Sie können diese View für Querys
verwenden und in nachfolgenden Schritten InfoObjects z.B. mit den Feldern der Open ODS
View verknüpfen und die InfoObject-Eigenschaften in Ihrem Modell verwenden.
Transportieren von Open ODS Views
Die Open ODS View ist im TLOGO-Framework integriert und kann transportiert werden. Das
Transportobjekt ist FBPA (A-Version) oder FBPD (Auslieferungsversion). Es ist wichtig, beim
Transport bestimmte Abhängigkeiten zu berücksichtigen.
Abhängigkeiten bei Quelltabellen und Quell-Views
Wenn Sie eine Tabelle oder eine View als Quellobjekt einer Open ODS View verwenden, muss
die Tabelle bzw. die View für den Transport im Zielsystem vorhanden sein, wenn die Open
ODS View transportiert wird. Wenn Sie SAP HANA Smart Data Access verwenden, muss die
SDA-Verbindung so konfiguriert sein, dass die Tabelle oder die View im Zielsystem zur
Verfügung steht.
Abhängigkeiten beim DB-Connect-Quellsystem
Die Open ODS View enthält keine Informationen, z.B. Verbindungsinformationen für die
Datenbank oder das Datenbankschema, zu dem lokalen System. Diese Informationen werden
in den DB-Connect-Quellsystemen für Open ODS Views angegeben, die auf Daten aus
Datenbanktabellen und Datenbank-Views zugreifen. Im Zieltransportsystem muss die
Zuordnungstabelle RSLOGSYSMAP richtig für die DB-Connect-Quellsysteme konfiguriert
werden. Diese wird für den Zugriff auf Tabellen und Views aus Open ODS Views verwendet.
Berechtigungsverhalten bei Feldern von Open ODS Views
Die Eigenschaft „Berechtigungsrelevanz“ im Merkmalsfeld der Open ODS View ermöglicht es
Ihnen festzulegen, ob ein Feld berechtigungsrelevant ist oder nicht. Die Einstellungen in der
Open ODS View bestimmen auch, welche Analyseberechtigungen für das Feld überprüft
werden sollten, wenn die Query ausgeführt wird. Wenn die Query ausgeführt wird, prüft das
System auch, ob der Benutzer über Analyseberechtigungen verfügt. Welche
Lektion: Anlegen von Open ODS Views
©Copyright. Alle Rechte vorbehalten. 189Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

198. Analyseberechtigungen überprüft werden, wenn die Query ausgeführt wird, hängt davon ab,
ob das Feld auf berechtigungsrelevant gesetzt wurde.
Keine Zuordnungen für das Merkmalsfeld definiert: Berechtigungsrelevanz wird lokal definiert
Wenn die Feldeigenschaft „Berechtigungsrelevanz“ lokal festgelegt wurde, überprüft das
System alle Berechtigungen, die für das Open-ODS-View-Feld definiert wurden.
Notiz:
Im Administrationsbild für Analyseberechtigungen können Sie
berechtigungsrelevante Open-ODS-View-Felder mit ihrem InfoObject-Namen für
die Berechtigungsdefinition verwenden. Die Felder werden als InfoObjects im
Administrationsbild für Analyseberechtigungen angezeigt.
Tabelle 6: Abhängigkeit der Eigenschaft „Berechtigungsrelevanz“ bei Zuordnungen
Wenn Sie für ein Feld der Open ODS View eine Zuordnung definiert haben, hängt das
Berechtigungsverhalten, wie in der Tabelle zu sehen ist, von den Einstellungen in der Open
ODS View ab.
Einstellungen in der Open ODS View (auf Ec-
lipse basierender Editor)
Berechtigungsverhalten
Sie haben eine Zuordnung definiert und „Di-
rect Usage of Associated Object by Name“
gewählt.
Die Berechtigungsrelevanz wird von der Zu-
ordnung vererbt und kann nicht lokal geän-
dert werden.
Wenn das zugeordnete Objekt berechti-
gungsrelevant ist, überprüft das System
beim Ausführen der Query die Analysebe-
rechtigungen (die für das zugeordnete Ob-
jekt definiert sind) für das Open-ODS-View-
Feld.
Sie haben eine Zuordnung definiert und
„Usage of System-Wide Unique Name“ ge-wählt.
Die Berechtigungsrelevanz wird von der Zu-ordnung vererbt. Wenn das zugeordnete Ob-jekt berechtigungsrelevant ist, überprüft das
System beim Ausführen der Query die Analy-
seberechtigungen (die für das zugeordnete
Objekt definiert sind) für das Open-ODS-
View-Feld.
Sie haben eine Zuordnung definiert, „Usage
of System-Wide Unique Name“ gewählt unddie Umschaltdrucktaste mit dem Stift („Tog-
gle Default Value/Manual Entry“) verwendet,
um die (lokal festgelegte) Eigenschaft zu
überschreiben.
Die Berechtigungsrelevanz wird lokal be-
stimmt. Wenn Sie das Feld als berechti-
gungsrelevant festgelegt haben, werden bei
der Ausführung der Query die für das Open-
ODS-View-Feld definierten Analyseberechti-
gungen überprüft. Das Open-ODS-View-Feld
steht zusammen mit seinem InfoObject-Na-
men als InfoObject im Administrationsbild für
Analyseberechtigungen zur Verfügung,
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 190Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

199. Einstellungen in der Open ODS View (auf Ec-
lipse basierender Editor)
Berechtigungsverhalten
auch dann, wenn Sie den Eintrag nach dem
Drücken der Stiftdrucktaste nicht ändern.
Toggle Default Value/Manual Entry: Das Sys-
tem interpretiert die Eigenschaft als lokal
festgelegt und nicht als Vorschlagswert oder
vererbten Wert. Die Analyseberechtigungen,
die für das InfoObject definiert wurden, wel-
ches das Feld der Open ODS View im Berech-
tigungspflegebild darstellt, werden überprüft.
Die Analyseberechtigungen des zugeordne-ten Objekts werden nicht überprüft.
Abbildung 173: Perspektive „BW Modeling“ in SAP HANA Studio
Open ODS Views ermöglichen es Ihnen, BW-Datenmodelle für externe Daten wie
Datenbanktabellen und Datenbank-Views eines beliebigen SAP-Schemas zu definieren. Diese
Datenmodelle ermöglichen eine einfache und flexible Integration, ohne dass InfoObjects
angelegt werden müssen. Die Datenquellen können in BW virtuell verwendet werden.
Die Modellierung von Open ODS Views erfolgt auf Feldebene, kann aber durch InfoObjects
komplementiert und nach und nach erweitert werden, um einen höheren Integrationsgrad zu
erzielen. Open ODS Views ermöglichen es Ihnen, zwischen Virtualisierung und dedizierten
Data-Warehouse-Persistenzen zu wechseln, und stellen somit einen flexiblen Zugangspunkt
für Replikationsszenarien bereit.
Wir empfehlen Open ODS Views in Fällen, in denen das Format der externen Daten für die
Integration in einen Datenfluss geeignet ist (wenn ein externes Datenmodell eine reine Fact
View oder eine reine Dimension View anzeigt). Voraussetzung für die Integration in einen BW-
Datenfluss ist die Unterteilung des Quellmodells in Fakten, Stammdaten und Texte. Basierend
Lektion: Anlegen von Open ODS Views
©Copyright. Alle Rechte vorbehalten. 191Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

200. auf diesen Einheiten, die repliziert werden können, ermöglichen Open ODS Views Ihnen die
Modellierung von Reporting Views für Daten.
Struktur des Open-ODS-View-Editors
Der Open-ODS-View-Editor enthält immer die Registerkarte „General“. Je nach Semantik der
Open ODS View kann er auch die relevanten semantischen Registerkarten „Facts“, „Master
Data“ und/oder „Texts“ enthalten.
Registerkarte: General
Auf der Registerkarte „General“ sehen Sie den Namen und die Beschreibung der Open ODS
View zusammen mit Informationen zu der Semantik der Open ODS View.
Tabelle 7: Registerkarten Facts, Master Data, Texts
Die Registerkarten „Facts“, „Master Data“ und „Texts“ stellen den zentralen Bereich für die
Open-ODS-View-Pflege dar. Open ODS Views für Stammdaten können zwei Arten von
Semantiken haben. In diesem Fall enthält der Editor sowohl die Registerkarte „Master Data“
als auch die Registerkarte „Texts“.
RegisterkartenbildbereichInhalt
Oberer Bildbereich Hier sehen Sie Informationen zu dem Quell-
objekt. Die Quick-Info kann für bestimmte
Quellentypen auch weitere Details zu der
Quelle anzeigen. Bestimmte Quellen, z.B. BW
DataSource, DataStore-Objekt (advanced)
und Transformation, ermöglichen Ihnen die
Navigation zur Objektpflege.
Linker Bildbereich – Quellfeld Hier sehen Sie die Struktur des Quellobjekts,einschließlich der Quellfelder und ihrer Eigen-
schaften. Wenn Sie eine Transformation als
Quelle verwenden, werden die InfoSource-
Felder in der Struktur des Quellobjekts ange-
zeigt.
Allgemeiner Bildbereich – View-Felder Hier sehen Sie die Struktur der Open ODS
View mit den View-Feldern, die in Feldkatego-
rien unterteilt sind. Die zu den Feldern ange-
zeigten Informationen beinhalten Folgendes:
●
In der Spalte „Associated Object“ wird an-
gezeigt, welche Zuordnung für das Feld
konfiguriert wurde.
●
Wenn Navigationsattribute für Felder an-gegeben wurden, können Sie die Liste der
Navigationsattribute erweitern, indem Sie
die Pfeiltaste auf dem Feldnamen verwen-
den.
Rechter Bildbereich – Allgemein Hier sehen Sie die analytischen Eigenschaf-ten des ausgewählten Quellfeldes bzw. View-
Feldes.
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 192Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

201. Abbildung 174: Perspektive „BW Modeling“ in BW SAP GUI
In der BW Data Warehousing Workbench können Sie mit der TransaktionRSODSVIEWeine
Open ODS View anlegen und pflegen. Sie müssen die Quellsemantik („Facts“, „Master Data“
oder „Texts“) auswählen. Jede dieser Semantiken hat andere zusätzliche Einstellungen, die
Sie vornehmen können.
Im Folgenden sind die Schritte zum Anlegen einer Open ODS View beschrieben:
1.Gehen Sie zur TransaktionRSODSVIEW.
2.Geben Sie den Namen der ODS View und die InfoArea ein.
3.Wählen Sie als Typ Datenquelle aus, und geben Sie die Quellsystemverbindung (RFC-
Name), unter der die Datenquelle zu finden ist, gefolgt vom Datenquellennamen an.
Unterstützte Quellen für Open ODS Views
Die folgenden Quellen stehen für den Datenzugriff mit Open ODS Views zur Verfügung:
DataSources in BW, DataStore-Objekte (advanced), Datenbanktabellen und Datenbank-
Views der BW-SAP-HANA-Datenbank und Datenbanken, die über SAP HANA Smart Data
Access mit BW verbunden sind. Darüber hinaus ermöglichen Transformationen
Datentypkonvertierungen, z.B. als Quellen, wenn Daten außerhalb des von BW verwalteten
Datenbankschemas verwendet werden.
DataSources in BW
Mit dem Quellentyp „DataSource (BW)“ können Open ODS Views für die unterstützten
Quellsystemtypen BW, SAP, ODP (SAP-Extraktoren), ODP (BW) und DB Connect auf Daten
zugreifen, für die es bereits DataSources in BW gibt. Für Open ODS Views stehen nur
DataSources als Quellen, die den Direktzugriff unterstützen, zu Verfügung.
DataStore-Objekte (advanced)
Lektion: Anlegen von Open ODS Views
©Copyright. Alle Rechte vorbehalten. 193Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

202. Mit dem Quellentyp „DataStore Object (Advanced)“ können Open ODS Views auf Daten aus
DataStore-Objekten (advanced) zugreifen. Nur DataStore-Objekte, für die das gesamte
Reporting in der aktiven Tabelle erfolgt, werden unterstützt.
Datenbanktabellen und Datenbank-Views der BW-SAP-HANA-Datenbank
Mit den Quellentypen „Database Table“ und „Database View“ können Open ODS Views auf
Daten aus allen Schemas in der BW-SAP-HANA-Datenbank zugreifen. Bis jetzt musste die
Verbindung zum relevanten Schema als DB-Connect-Quellsystem konfiguriert werden.
Tabellen und Views aus Datenbanken mit Verwendung von SAP HANA Smart Data Access
Mit dem Quellentyp „Virtual Tables Using HANA Smart Data Access“ können Open ODS
Views auf Remote-Daten in unterschiedlichen Quelldatenbanken zugreifen. Die
Quelldatenbank muss in SAP HANA als Remote-Source konfiguriert werden. Die Verbindung
zur Quelldatenbank und zu dem relevanten Schema wird unter Verwendung eines DB-
Connect-Quellsystems konfiguriert.
Wenn eine Open ODS View mit dem Quellentyp „Virtual Table Using HANA Smart Data
Access“ angelegt wird, wird in SAP HANA eine virtuelle Tabelle angelegt. Die virtuelle Tabelle
verweist auf eine Remote-Tabelle, die das Quellobjekt der Open ODS View ist und den Zugriff
auf die Daten ermöglicht.
Transformationen
Mit dem Quellentyp „Transformation“ können Sie Transformationen verwenden, um
beispielsweise Datenkonvertierungen, Zuordnungen und String-Operationen mit Daten
auszuführen, die mithilfe von Open ODS Views verwendet werden. Dies kann hilfreich sein,
wenn Sie diese Transformationen beispielsweise nicht in der Datenquelle für Daten
verwenden können oder möchten, die sich außerhalb des von BW verwalteten
Datenbankschemas befinden. Sie können eine Transformation als Quelle für die Open ODS
View verwenden, vorausgesetzt, Sie haben den zugehörigen Datenfluss angelegt.
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 194Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

203. Abbildung 175: Open ODS Views – Feldsemantik für „Facts“ und „Master Data“
Die Registerkarten „Facts“, „Master Data“ und „Texts“ stellen den zentralen Bereich für die
Open-ODS-View-Pflege dar. Open ODS Views für Stammdaten können zwei Arten von
Semantiken haben. In diesem Fall enthält der Editor sowohl die Registerkarte „Master Data“
als auch die Registerkarte „Texts“.
Unter Verwendung von Links zu InfoObjects können Sie Open ODS Views mit BW-Modellen
kombinieren und dabei beispielsweise Stammdatenattribute und Texte in BW verwenden. Es
gibt noch eine andere Möglichkeit, die Open ODS View mit BW-Modellen zu kombinieren: die
Verwendung des CompositeProviders.
Sie können diese View für Querys verwenden und in nachfolgenden Schritten InfoObjects z.B.
mit den Feldern der Open ODS View verknüpfen und die InfoObject-Eigenschaften in Ihrem
Modell verwenden.
Notiz:
Das Merkmal (Schlüssel) wird für die Open ODS View nur benötigt, um eine
DataSource und ein feldbasiertes DataStore-Objekt (advanced)
(Persistenzschicht) zu generieren.
Lektion: Anlegen von Open ODS Views
©Copyright. Alle Rechte vorbehalten. 195Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

204. Hinweis:
Objekte, die Open ODS Views für Stammdaten zugeordnet sind, sind nur für die
Navigation relevant, wenn die Query für die Stammdaten-ODS-View ausgeführt
wird. Wenn die Stammdaten-ODS-View einer ODS View für Fakten zugeordnet
ist, dann werden nur Texte (falls vorhanden) angeboten – keine Snowflake-
Unterstützung.
Die Eigenschaft „Berechtigungsrelevanz“ im Merkmalsfeld der Open ODS View ermöglicht es
Ihnen festzulegen, ob ein Feld berechtigungsrelevant ist oder nicht. Die Einstellungen in der
Open ODS View bestimmen auch, welche Analyseberechtigungen für das Feld überprüft
werden sollten, wenn die Query ausgeführt wird. Wenn die Query ausgeführt wird, prüft das
System auch, ob der Benutzer über Analyseberechtigungen verfügt. Welche
Analyseberechtigungen überprüft werden, wenn die Query ausgeführt wird, hängt davon ab,
ob das Feld auf berechtigungsrelevant gesetzt wurde.
Hinweis:
Im Administrationsbild für Analyseberechtigungen können Sie
berechtigungsrelevante Open-ODS-View-Felder mit ihrem InfoObject-Namen für
die Berechtigungsdefinition verwenden. Die Felder werden als InfoObjects im
Administrationsbild für Analyseberechtigungen angezeigt.
Abbildung 176: Feldbasierte Modellierung und Integration
Sie können bestimmte Felder Ihrer Open ODS View zu BW-InfoObjects zuordnen. Dies ist der
Grund für die Wiederverwendung der bereits vorhandenen und nützlichen BW-Metadaten, die
sich in Ihren SAP-BW-InfoObjects befinden könnten. Hier sind einige Beispiele:
●BEx-Standardeinstellungen
●Hierarchien
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 196Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

205. ●Texte
●Stammdatenattribute
●Navigationsattribute für Stammdaten
●BW-Analyseberechtigungen
Wie bei einem InfoObject kann die Open ODS View sprachenunabhängige Semantiken für die
Attributschlüssel mit sprachenabhängigen Semantiken für Texte kombinieren. Sie können für
eine Open ODS View, die Sie ursprünglich mit einer der beiden anderen Semantiken (Texte
oder Attribute) angelegt haben, zusätzliche Semantiken hinzufügen.
Abbildung 177: Open ODS View – Zuordnungen zu BW-InfoObjects
Wenn Sie für Felder vom TypcharacteristicZuordnungen verwenden, können Sie eine Open
ODS View mit Stammdaten und Texten anderer Open ODS Views und InfoObjects
verknüpfen. Dies ermöglicht es Ihnen, Eigenschaften vom zugeordneten Objekt zu vererben,
zusätzliche Schlüsselfelder (Klammerung) zuzuordnen sowie Texte und Navigationsattribute
der zugeordneten Objekte in Querys für die Open ODS View zu verwenden.
Im Falle von Feldern vom Typkey figure können Sie Zuordnungen zu InfoObjects hinzufügen.
Dies ist insbesondere relevant, wenn Sie Formeln und Variablen (die für das zugeordnete
InfoObject definiert wurden) in Querys wiederverwenden möchten.
Lektion: Anlegen von Open ODS Views
©Copyright. Alle Rechte vorbehalten. 197Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

206. Abbildung 178: Open ODS View – Namenskonventionen von Feldern und InfoObjects
Abbildung 179: Auf BW-Feld basierende Modellierung für alle Daten – Übersicht
Unterstützte Quellen für Open ODS Views
Die folgenden Quellen stehen für den Datenzugriff mit Open ODS Views zur Verfügung:
DataSources in BW, DataStore-Objekte (advanced), Datenbanktabellen und Datenbank-
Views der BW-SAP-HANA-Datenbank und Datenbanken, die über SAP HANA Smart Data
Access mit BW verbunden sind. Darüber hinaus ermöglichen Transformationen
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 198Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

207. Datentypkonvertierungen, z.B. als Quellen, wenn Daten außerhalb des von BW verwalteten
Datenbankschemas verwendet werden.
DataSources in BW
Mit dem Quellentyp „DataSource (BW)“ können Open ODS Views für die unterstützten
Quellsystemtypen BW, SAP, ODP (SAP-Extraktoren), ODP (BW) und DB Connect auf Daten
zugreifen, für die bereits DataSources in BW vorhanden sind. Für Open ODS Views stehen nur
DataSources als Quellen, die den Direktzugriff unterstützen, zu Verfügung.
DataStore-Objekte (advanced)
Mit dem Quellentyp „DataStore Object (Advanced)“ können Open ODS Views auf Daten aus
DataStore-Objekten (advanced) zugreifen. Nur DataStore-Objekte, für die das gesamte
Reporting in der aktiven Tabelle erfolgt, werden unterstützt.
Datenbanktabellen und Datenbank-Views der BW-SAP-HANA-Datenbank
Mit den Quellentypen „Database Table“ und „Database View“ können Open ODS Views auf
Daten aus allen Schemas in der BW-SAP-HANA-Datenbank zugreifen.
Bis jetzt musste die Verbindung zum relevanten Schema als DB-Connect-Quellsystem
konfiguriert werden.
Tabellen und Views aus Datenbanken mit Verwendung von SAP HANA Smart Data Access
Mit dem Quellentyp „Virtual Tables Using HANA Smart Data Access“ können Open ODS
Views auf Remote-Daten in unterschiedlichen Quelldatenbanken zugreifen. Die
Quelldatenbank muss in SAP HANA als Remote-Source konfiguriert werden. Die Verbindung
zur Quelldatenbank und zu dem relevanten Schema wird unter Verwendung eines DB-
Connect-Quellsystems konfiguriert.
Wenn eine Open ODS View mit dem Quellentyp „Virtual Table Using HANA Smart Data
Access“ angelegt wird, wird in SAP HANA eine virtuelle Tabelle angelegt. Die virtuelle Tabelle
verweist auf eine Remote-Tabelle, die das Quellobjekt der Open ODS View ist und den Zugriff
auf die Daten ermöglicht.
Transformationen
Mit dem Quellentyp „Transformation“ können Sie Transformationen verwenden, um
beispielsweise Datenkonvertierungen, Zuordnungen und String-Operationen mit Daten
auszuführen, die mithilfe von Open ODS Views verwendet werden. Dies kann hilfreich sein,
wenn Sie diese Transformationen beispielsweise nicht in der Datenquelle für Daten
verwenden können oder möchten, die sich außerhalb des von BW verwalteten
Datenbankschemas befinden.
Sie können eine Transformation als Quelle für die Open ODS View verwenden, vorausgesetzt,
Sie haben den zugehörigen Datenfluss angelegt.
Lektion: Anlegen von Open ODS Views
©Copyright. Alle Rechte vorbehalten. 199Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

208. Abbildung 180: Open ODS Views anlegen – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●Open ODS Views anlegen
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 200Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

209. Kapitel 5
Lektion 2
Anlegen von DataSources aus Open ODS View
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird erläutert, wie eine DataSource aus Open ODS Views erstellt wird.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●DataSources aus Open ODS View anlegen, um Daten persistent in SAP Business
Warehouse (SAP BW) zu speichern
DataSources aus Open ODS Views
Abbildung 181: Inkrementelle Modellierung der Datenlieferung – Staging in Advanced DSO
Bei vorhandenen Open ODS Views können Sie auch automatisch einen Datenfluss mit
Transformation erstellen. Beim Erstellen des Datenflusses wird die Quelle der Open ODS View
automatisch durch das erstellte Objekt ersetzt.
Sie können Ihr Datenmodell vollständig virtuell halten, können aber zusätzliche
Transformationslogik in einer BW-Standardtransformationsregel hinzufügen. Das bedeutet,
dass Sie bei vorhandenen Open ODS Views auch automatisch einen Datenfluss mit
Transformationen erstellen können. Beim Erstellen des Datenflusses wird die Quelle der Open
ODS View automatisch durch das erstellte Objekt, die erstellte InfoSource, ersetzt. Nutzen
Sie dieGenerate-Funktion beider Modellierungsumgebungen, um dies zu erreichen.
©Copyright. Alle Rechte vorbehalten. 201Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

210. Folgende Objekte werden erstellt, BW DataSource (Typ DB Connect), Transformationsregel
und Advanced DSO sowie DataTransferProcess:
●Das System erstellt ein Advanced DSO mit einer aktiven Tabelle im InfoArea der Open ODS
View. Die Felder dieser Tabelle werden aus den Feldern der Struktur der Open ODS View
übertragen. Verknüpfungen mit anderen Open-ODS-View-Feldern werden ignoriert.
●Das Advanced DSO basiert auf Feldern oder, wenn InfoObjects verknüpft sind, auf
InfoObjects.
●Das System tauscht das Quellobjekt in der Open ODS View aus. Das Quellobjekt ist jetzt
das ADSO.
●Das System erstellt eine Transformation zwischen DataSource und ADSO.
Die mit dem Datenfluss generierten Objekte werden ohne Transportauff orderung in das lokale
Paket $TMP geschrieben. Ändern Sie die Paketzuordnung im BW-Transportanschluss des
BW-Backend-Systems, und tragen Sie die Objekte manuell in einen Transportauftrag ein.
Die Quelle der Open ODS View ist jetzt die aktive Tabelle des ADSO. Ohne das Laden der
Daten sind für dieses Datenmodell keine Daten sichtbar. Achten Sie darauf, dass Sie in
diesem Fall Daten aus einer Quelle außerhalb des BW-verwalteten HANA-Schemas in das BW-
verwaltete Schema kopieren (replizieren). Das Outbound-Interface der ursprünglichen Open
ODS View bleibt unverändert. Alle BEx-Querys bleiben unverändert, alle Verbindungen zu
CompositeProvidern sind in keiner Weise betroffen.
Einige wichtige Überlegungen für dieses Szenario:
●Folgende Objekte werden erstellt: BW DataSource (Typ DB Connect),
Transformationsregel und InfoSource (als Ziel der Transformation).
●Das System erstellt eine InfoSource in der Anwendungskomponente
NODESNOTCONNECTED. Die Felder dieser InfoSource werden aus den Feldern der
Struktur der Open ODS View kopiert. Zuordnungen zu anderen Open-ODS-View-Feldern
werden beim Erstellen der InfoSource ignoriert.
●Die InfoSource basiert auf Feldern oder, wenn InfoObjects verknüpft sind, auf InfoObjects.
●Das System tauscht das Quellobjekt in der Open ODS View aus. Das Quellobjekt ist jetzt
die Transformation.
●Das System erstellt eine Transformation zwischen DataSource und InfoSource.
Die mit dem Datenfluss generierten Objekte werden ohne Transportauff orderung in das lokale
Paket $TMP geschrieben. Ändern Sie die Paketzuordnung im BW-Transportanschluss des
BW-Backend-Systems, und tragen Sie die Objekte manuell in einen Transportauftrag ein. Je
mehr Logik Sie in die Transformationsregel implementieren, desto höher sind die
Performancekosten: Reduzieren Sie die Logik auf ein Minimum. Das Outbound-Interface der
ursprünglichen Open ODS View bleibt unverändert. Alle BEx-Querys bleiben unverändert, alle
Verbindungen zu CompositeProvidern sind nicht betroffen.
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 202Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

211. Abbildung 182: Eigenschaften von Advanced DSO
Das DataStore-Objekt (advanced) ist das zentrale Objekt der Datenspeicherung und
Datenkonsolidierung im BW-System. Wenn die erforderlichen Eigenschaften entsprechend
festgelegt werden, kann das DataStore-Objekt (advanced) in verschiedenen Schichten des
Data Warehouse verwendet werden.
Zur Vereinfachung der Modellierung des DataStore-Objekt (advanced) stellen wir Vorlagen
bereit, die zum Generieren der erforderlichen Eigenschaften verwendet werden können. Das
DataStore-Objekt (advanced) kann InfoObjects und Felder enthalten. Sie können Daten in das
BW-System laden, ohne InfoObjects zuordnen zu müssen. Sämtliche Funktionen sind
weiterhin verfügbar. Dank des neuen Request-Managements ist das DataStore-Objekt
(advanced) besonders gut für häufige Ladevorgänge und große Datenmengen geeignet.
Das ODP-Quellsystem unterstützt Sie beim Aktualisieren der Daten aus einem InfoProvider
für einen anderen InfoProvider in einem anderen BW-System (Data Mart). Die Modellierung
für das DataStore-Objekt (advanced) ist in die BW-Modellierungswerkzeuge integriert. Für
das DataStore-Objekt (advanced) ist es vorgesehen, die BW InfoProvider dauerhaft zu
ersetzen (InfoCubes, DataStore-Objekte, Persistent Staging Area). Diese klassischen
InfoProvider werden weiterhin zusätzlich zum DataStore-Objekt (advanced) verfügbar sein
und werden weiterhin unterstützt.
Lektion: Anlegen von DataSources aus Open ODS View
©Copyright. Alle Rechte vorbehalten. 203Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

212. Abbildung 183: Generierung des Datenflusses von Open ODS View
Erstellen eines Datenflusses für Open ODS Views
Für Open ODS Views mit der Quellenart „Database Table“, „View“ oder „Virtual Table Using
HANA Smart Data Access“ können Sie einen Datenfluss mit einem DataStore-Objekt
(advanced) oder einer Transformation anlegen. Beim Erstellen des Datenflusses wird die
Quelle der Open ODS View automatisch durch das erstellte Objekt ersetzt.
Datenfluss mit DataStore-Objekt (advanced)
Sie können ein DataStore-Objekt (advanced) mit Datenfluss als Datenpersistenz für die Open
ODS View anlegen. Dieser Fall ist vergleichbar mit einem Persistent Staging Area (PSA), wo
Daten weiterverarbeitet werden können. Für Reporting-Zwecke und für die Verwendung des
CompositeProvider empfehlen wird die direkte Verwendung der Open ODS View.
Transformation
Sie können die Transformation mit Datenfluss verwenden, um Datentypkonvertierungen,
Zuordnungen oder Zeichenfolgenverarbeitungen, z.B. an der Datenquelle einer Open ODS View, vorzunehmen.
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 204Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

213. Abbildung 184: Open ODS View – Wechsel zu Persistenz
Der SAP-BW-Entwickler kann mit dem Entwickeln, Testen und Prototyping an Daten
beginnen, bevor er das zugrunde liegende Datenmodell bearbeitet und Änderungen an den
Anforderungen vornimmt. So wird eine agile Entwicklung und mehr Flexibilität bei Projekten
unterstützt.
In Vielen Situationen ist in Ihrem Projekt Datenpersistenz erforderlich, und ein ETL-Prozess
muss eingesetzt werden. Hier kommt Advanced DSO (ADSO) ins Spiel. Ab SAP BW 7.4 SP8
ist es möglich, ein Advanced DSO aus Ihrer vorhandenen Open ODS View zu generieren, das
alle InfoObject-Zuordnungen und Feldinformationen erbt. Bei Verwendung für eine SAP ERP
DataSource wird sogar eine Transformation in diese DataSource und ein
Datentransferprozess angelegt.
Abbildung 185: Open ODS View mit Smart Data Access – Wechsel zu Datenpersistenz
Lektion: Anlegen von DataSources aus Open ODS View
©Copyright. Alle Rechte vorbehalten. 205Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

214. Externe Daten ohne Staging verwenden
Die Open ODS View ermöglicht die virtuelle Verwendung von Datenquellen, ohne dass eine
separate BW-Persistenz für die Daten benötigt wird. Diese Datenmodelle können sich in
einem Datenbankschema (der SAP-HANA-Datenbank in BW) befinden, das nicht von BW
verwaltet wird. Alternativ dazu können sich die Modelle in anderen Datenbanken befinden, die
über SAP HANA Smart Data Access mit der SAP-HANA-Datenbank in BW verbunden werden können.
Open ODS View und logisches Data Warehouse
Die Open ODS View bietet eine Vielzahl von Funktionen, die wichtig für das Herstellen
logischer Data-Warehouse-Komponenten in einer Lösung sind.
Die Zugänglichkeit externer Daten
Jede Quelle, die für SAP HANA zugänglich ist, ist eine potenzielle Quelle für eine Open ODS
View. Die Open ODS View akzeptiert Folgendes: SQL-Views, SAP-HANA-Views, Tabellen und
virtuelle SAP-HANA-Tabellen, die eine Remote-DB-View oder eine Remote-Tabelle darstellen
(SAP HANA Smart Data Access).
Die Kapazität zu modellierender externer Datenstrukturen
Eine Open ODS View weist eine Quellsemantik zu (Fakten, Stammdaten, Texte). Es ist daher
möglich, für mehrere Open ODS Views Semantiken derselben Quelle zu haben. Die Quell-
Views müssen so geteilt werden, dass sie keine Kombination aus Fakten und Stammdaten
(Attribute) enthalten.
Die Kapazität zu modellierender externer Daten
Eine Open ODS View weist den Feldern in der Quellstruktur Semantiken zu (Merkmal,
Kennzahl, Währung usw.). Einem einzelnen Quellfeld können mehrere Semantiken
zugewiesen werden (Merkmal und Kennzahl beispielsweise). Textfelder können direkt als
Texte im BW-Sinne adressiert werden. Wenn Mehrsprachigkeit erforderlich ist, können
Textfelder zusammen mit anderen Attributen in einer Quellstruktur verwendet und
entsprechend von der ODS View interpretiert werden.
Die Integration externer Daten
Open ODS Views können mit anderen Open ODS Views verknüpft werden. Die Verbindung von
Stammdaten-Open ODS Views mit einer Fakten-Open ODS View führen beispielsweise zu
einem Sternschema. Open ODS Views können mit InfoObjects verknüpft werden und diese so
direkt adressieren. Open ODS Views können anderen BW InfoProvidern in
CompositeProvidern zugeordnet werden.
Die erforderliche Flexibilität und Stabilität in Beziehung zu anderen Quellstrukturen
Die Open ODS View macht es möglich, Quellstrukturen untereinander flexibel auszutauschen.
Die Open ODS View unterstützt den logischen Data-Warehouse-Ansatz, d.h., der Speicherort
der Daten spielt keine Rolle: Wenn ein Service-Level von Quelle A an Standort B nicht
eingehalten wird, müssen die Quelldaten von A nach Standort C verschoben werden können,
ohne dass Querys und andere für die Quellstruktur A angelegte Elemente betroffen sind. Es ist
natürlich wichtig, dass die neue Quellstruktur A an Standort C dieselben Felder bereithält.
Unterstützung für Änderung des Standorts der Quelle und für die Übertragung an das Data
Warehouse
Neben der Austauschbarkeit der Quellstrukturen unterstützt die Open ODS View auch die
optionale Generierung einer DataSource, eines DataStore-Objekts (advanced) und eines
Datenflusses aus der Definition der Open ODS View. Die Open ODS View ist somit das
zentrale Objekt für die virtuelle Integration externer Daten in das Data Warehouse.
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 206Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

215. Abbildung 186: LSA – ganzheitliches Framework für BW auf HANA
Ein wichtiger Aspekt der In-Memory-Technologie liegt in dem Paradigmenwechsel, nach dem
datenintensive Geschäftslogik von der Datenbank anstatt vom Anwendungsserver berechnet
werden soll. In SAP BW wird dieses In-Memory-Programmierungsparadigma mit dem BW
Accelerator (BWA) bereits seit mehreren Jahren verfolgt und wird in SAP HANA konsequent
weitergeführt. Es hat große Auswirkungen auf SAP BW und damit auf die Layered Scalable
Architecture (LSA). Während die Grundprinzipien unverändert bleiben, führt HANA deutlich
mehr Modellierungsoptionen ein, mit denen Sie Ihre Enterprise-Data-Warehouse-Architektur
optimieren können. Dieses Flexibilitätsvorteil demonstriert SAP in der aktualisierten
Referenzarchitektur LSA powered by SAP HANA (LSA++).
In der folgenden Liste werden die Eigenschaften von LSA++ aufgeführt:
●Reporting auf Propagator ist zulässig.
●Transformationen können von der Business-Transformation-Schicht in das Query-Design
oder nach SAP HANA verschoben werden. Querys können SAP-HANA-Views über den
Direktzugriff auf SAP HANA oder mittels CompositeProvider direkt verwenden.
●Virtualization-Schicht setzt auf Architected Data Marts und Propagator auf, indem UNION
oder JOIN durch CompositeProvider genutzt werden.
Lektion: Anlegen von DataSources aus Open ODS View
©Copyright. Alle Rechte vorbehalten. 207Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

216. Abbildung 187: DataSources aus Open ODS View erstellen
So generieren Sie einen Datenfluss
1.Drücken Sie im Pflegebild der Open ODS View auf Generieren.
2.Im eingeblendeten Popup-Fenster können Sie den vorgeschlagenen Namen für die
DataSource ändern.
3.Das System erstellt jetzt eine DataSource im Quellsystem der Open ODS View in der
AnwendungskomponenteNODESNOTCONNECTED . Die Felder dieser DataSource werden
aus den Quellfeldern der Open ODS View erstellt.
4.Das System tauscht das Quellobjekt in der Open ODS View aus. Das Quellobjekt ist jetzt
die DataSource.
5.Drücken Sie erneutGenerieren.
6.Wählen Sie im angezeigten Popup-FensterDataStore-Objekt (advanced)als Zielobjektart.
7.Ändern Sie den vorgeschlagenen Namen für dasDataStore-Objekt.
8.Legen Sie die Datentypen für die Felder fest. Der BW Analytic Manager unterstützt nur bestimmte Datentypen für das Reporting. Wenn die Quelle andere Datentypen verwendet,
werden diese zur Laufzeit automatisch konvertiert. Wenn Sie das Zielobjekt mit BW-
Datentypen anlegen, muss diese Konvertierung zur Laufzeit nicht durchgeführt werden.
Darüber hinaus erleichtert dies die Verwendung der Zielobjekte in anderen BW-Objekten.
9.Drücken Sie zum ErstellenEnter.
Kapitel 5: Open ODS Views
©Copyright. Alle Rechte vorbehalten. 208Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

217. ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●DataSources aus Open ODS View anlegen, um Daten persistent in SAP Business
Warehouse (SAP BW) zu speichern
Lektion: Anlegen von DataSources aus Open ODS View
©Copyright. Alle Rechte vorbehalten. 209Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

218. Kapitel 5
Überprüfung des Lernerfolgs
1.Mit welcher Transaktion wird eine Open ODS View angelegt und gepflegt?
©Copyright. Alle Rechte vorbehalten. 210Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

219. Kapitel 5
Überprüfung des Lernerfolgs - Antworten
1.Mit welcher Transaktion wird eine Open ODS View angelegt und gepflegt?
RSODSVIEW
©Copyright. Alle Rechte vorbehalten. 211Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

220. KAPITEL 6SAP Business
Warehouse (SAP BW) –
erweiterte Themen
Lektion 1
Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business
Warehouse (SAP BW)
214
Lektion 2
Erläutern von InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA 243
Lektion 3
Administrieren von DataStore-Objekten (advanced) 249
Lektion 4
Einführung zu Prozessketten 256
Lektion 5
Erläutern von SAP-HANA-Delta-Merges in SAP Business Warehouse (SAP BW) 281
Lektion 6
Einführung zu Business-Intelligence-Content (BI Content) 287
Lektion 7
Einführung zu S4/HANA 293
LERNZIELE
●die Möglichkeiten von Datentransformationen und Datentransferprozess in SAP Business
Warehouse powered by HANA erläutern
●InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA erläutern
●DataStore-Objekte (advanced) administrieren
●einfache Prozessketten anlegen
●SAP-HANA-Delta-Merges in SAP BW erläutern
©Copyright. Alle Rechte vorbehalten. 212Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

221. ●den BI Content und die BI-Content-Aktivierung erläutern
●den erweiterten SAP-HANA-optimierten Business Content beschreiben
●die Strategie zur Zusammenführung von OLAP und OLTP im Kontext von S/4HANA
beschreiben
●S/4HANA Analytics als Ergänzung zu SAP BW powered by HANA beschreiben
©Copyright. Alle Rechte vorbehalten. 213Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

222. Kapitel 6
Lektion 1
Erläutern der Details von Datentransformation
und Datentransferprozess (DTP) in SAP
Business Warehouse (SAP BW)
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion werden die Datentransformation und der DTP in SAP BW im Detail
betrachtet.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●die Möglichkeiten von Datentransformationen und Datentransferprozess in SAP Business
Warehouse powered by HANA erläutern
Transformation – Details
Abbildung 188: Details des Datenflusses in SAP BW
Der Datenfluss in SAP NetWeaver Business Warehouse (BW) legt fest, welche Objekte zur
Design-Zeit und welche Prozesse zur Laufzeit benötigt werden, um Daten aus einer Quelle an
BW zu übertragen, um die Daten dort zu bereinigen, zu konsolidieren und zu integrieren,
damit sie anschließend in Analysen, im Reporting und in der Planung verwendet werden
können. Die individuellen Anforderungen Ihrer Unternehmensprozesse werden durch
zahlreiche Optionen zur Gestaltung des Datenflusses unterstützt. Sie können sämtliche
©Copyright. Alle Rechte vorbehalten. 214Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

223. Datenquellen verwenden, die Daten an BW übertragen, oder direkt auf die Quelldaten
zugreifen, einfache oder komplexe Bereinigungs- und Konsolidierungsmethoden anwenden
und Daten-Repositorys definieren, die den Anforderungen Ihrer Schichtenarchitektur
entsprechen.
In SAP NetWeaver 7.0 wurden die Konzepte und Technologien für bestimmte Elemente im
Datenfluss geändert. In diesem Abschnitt werden die wichtigsten Bestandteile des neuen
Datenflusses erläutert, wobei auch auf die Änderungen im Vergleich zum bisherigen
Datenfluss eingegangen wird. Die zuvor verwendeten Objekte werden mit dem Zusatz 3.x
versehen, um sie von den neuen Objekten zu unterscheiden.
In BW wird die Metadatenbeschreibung der Quelldaten mit DataSources modelliert. Eine
DataSource besteht aus einer Reihe von Feldern, die zum Extrahieren von Daten aus einem
Quellsystem und zu ihrer Übertragung in die Eingangsschicht des BW-Systems oder zur
Bereitstellung für direkten Zugriff verwendet werden.
Für DataSources in BW (SAP NetWeaver 7.0 und höher) ist ein neues Objektkonzept
vorhanden. Die DataSource wird in BW unabhängig von 3.x-Objekten auf einer einheitlichen
Benutzungsoberfläche bearbeitet bzw. angelegt. Wenn die DataSource aktiviert wird, legt das
System in der Persistent Staging Area (PSA), der Eingangsschicht von BW, eine PSA-Tabelle
an. Somit stellt die DataSource ein persistentes Objekt im Datenfluss dar. Bevor Daten in BW
verarbeitet werden können, müssen sie mithilfe eines InfoPackages in die PSA geladen
werden. Im InfoPackage legen Sie die Selektionsparameter zur Übertragung von Daten in die
PSA fest. Im neuen Datenfluss werden InfoPackages nur zum Laden von Daten in die PSA
verwendet.
Mithilfe der Transformation werden Daten in BW aus einem Quellformat in ein Zielformat
kopiert. Dadurch ermöglicht Ihnen die Transformation, Daten aus mehreren Quellen zu
konsolidieren und zu bereinigen. Sie können Daten aus verschiedenen Quellen semantisch
synchronisieren. Durch die Zuordnung von Feldern der DataSource zu InfoObjects integrieren
Sie die Daten in das BW-System. Die Transformation ersetzt im Datenfluss die
Fortschreibungs- und Übertragungsregeln einschließlich der Transferstrukturpflege.
InfoObjects sind die kleinsten Informationseinheiten in BW. Sie strukturieren die Informationen in der zum Aufbau von InfoProvidern erforderlichen Form.
InfoProvider bestehen aus mehreren InfoObjects und sind persistente Daten-Repositorys, die
in der Schichtenarchitektur des Data Warehouse oder in Datensichten verwendet werden.
InfoProvider stellen die Daten für Analyse, Reporting und Planung zur Verfügung. Sie haben
auch die Möglichkeit, die Daten in weitere InfoProvider zu schreiben. Mit einer InfoSource (im
neuen Datenfluss optional) können Sie mehrere aufeinanderfolgende Transformationen
verbinden. Sie benötigen daher eine InfoSource für komplexe Transformationen (mehrstufige
Verfahren). Mit dem Datentransferprozess (DTP) übertragen Sie gemäß bestimmter
Transformationen und Filter die Daten innerhalb von BW von einem persistenten Objekt an
ein anderes Objekt. Zu den möglichen Quellen für die Datenübertragung zählen DataSources
und InfoProvider, zu den möglichen Zielen hingegen InfoProvider und Open Hub Destinations.
Der DTP ersetzt zur Verteilung der Daten innerhalb von BW und in nachgelagerte Systeme
das InfoPackage, das Data Mart Interface (Export-DataSources) und die InfoSpoke.
Außerdem können Sie Daten über eine Open Hub Destination in weitere Systeme verteilen. In
BW werden Prozessketten zum Einplanen der mit dem Datenfluss verbundenen Prozesse,
einschließlich InfoPackages und Datentransferprozesse, verwendet.
Die Komplexität der Datenflüsse ist unterschiedlich. Als absolutes Minimum benötigen Sie
eine DataSource, eine Transformation, einen InfoProvider, ein InfoPackage und einen Datentransferprozess.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 215Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

224. Abbildung 189: Erweiterter Datenfluss – InfoSources
Mit einer InfoSource (im neuen Datenfluss optional) können Sie mehrere aufeinanderfolgende
Transformationen verbinden. Sie benötigen eine InfoSource nur für komplexe
Transformationen (mehrstufige Verfahren).
Abbildung 190: Anzeigeoptionen für Transformationen
Mit dem Transformationsprozess können Sie Daten konsolidieren, bereinigen und integrieren.
Sie können Daten aus heterogenen Quellen semantisch synchronisieren. Wenn Sie Daten aus
einem BI-Objekt in ein anderes BI-Objekt laden, durchlaufen die Daten eine Transformation.
Bei einer Transformation werden die Felder der Quelle in das Format des Ziels umgesetzt.
Eine Transformation wird zwischen einer Quelle und einem Ziel angelegt. Die BI-Objekte
DataSource, InfoSource, DataStore-Objekt, InfoCube, InfoObject und InfoSet stehen als
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 216Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

225. Quellobjekte zur Verfügung. Als Zielobjekte können die BI-Objekte InfoSource, InfoObject,
DataStore-Objekt und InfoCube verwendet werden.
Abbildung 191: Experten-, Start- und Endroutinen
Sie verwenden Routinen zum Definieren komplexer Transformationsregeln. Routinen sind
lokale ABAP-Klassen, die aus einem vordefinierten Definitionsbereich und einem
Implementierungsbereich bestehen. Die Typen für die Eingangs- und Ausgangsparameter
und die Signatur der Routine (ABAP-Methode) werden im Definitionsbereich gespeichert. Die
eigentliche Routine wird im Implementierungsbereich angelegt. Im Coding der Routine sind
ABAP-Objektanweisungen verfügbar. Nach der Generierung wird das Coding in die lokale
Klasse des Transformationsprogramms eingebettet.
Die Routine besteht aus einem globalen und einem lokalen Teil. Im globalen Teil definieren Sie
globale Datendeklarationen ('CLASS-DATA'). Diese sind in allen Routinen verfügbar. Wenn Sie
Quelltext in Routinen wiederverwenden möchten, können Sie Funktionsbausteine, Methoden
oder externe Unterprogramme in der ABAP Workbench anlegen. Diese können im lokalen Teil
der Routine aufgerufen werden. Wenn Sie eine Routine transportieren möchten, die Aufrufe
dieses Typs enthält, sollten die Routine und das aufgerufene Objekt in denselben
Transportauftrag aufgenommen werden. Transformationen enthalten verschiedene Arten
von Routinen: Startroutinen, Routinen für Kennzahlen oder Merkmale, Endroutinen und
Expertenroutinen.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 217Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

226. Abbildung 192: Experten-, Start- und Endroutinen 2
Expertenroutine
Diese Art von Routine ist für spezielle Szenarien vorgesehen. Die Expertenroutine können Sie
dann verwenden, wenn die übrigen Transformationsfunktionen nicht ausreichen. Sie können
die Expertenroutine als Übergangslösung nutzen, bis die benötigten Funktionen in der
Standardroutine verfügbar sind. Damit können Sie die Transformation selbst programmieren,
ohne die vorhandenen Regeltypen zu verwenden. Die Übertragung der Meldungen an den
Monitor müssen Sie dabei selbst vornehmen. Wenn Sie bereits Transformationsregeln
angelegt haben, werden diese vom System gelöscht, sobald Sie eine Expertenroutine
angelegt haben. Navigationsattribute der Quelle der Transformation sind in der
Expertenroutine nicht verfügbar.
Notiz:
Wenn das Ziel der Transformation ein DataStore-Objekt ist, werden Kennzahlen
standardmäßig mit dem Aggregationsverhalten „Überschreiben“ (MOVE)
fortgeschrieben.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 218Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

227. Abbildung 193: Auf die Startroutine zugreifen
Startroutine
Die Startroutine wird zu Beginn der Transformation für jedes Datenpaket ausgeführt. Die
Startroutine verfügt über eine Tabelle im Format der Quellstruktur als Ein- und
Ausgabeparameter. Mit einer Startroutine können Vorabberechnungen durchgeführt und in
einer globalen Datenstruktur oder einer Tabelle abgelegt werden. Auf diese Struktur oder
Tabelle kann aus anderen Routinen heraus zugegriff en werden. Sie können Daten im
Datenpaket modifizieren oder löschen.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 219Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

228. Abbildung 194: Das Startroutinenkonzept
In der folgenden Liste sind die Parameter der Startroutine aufgeführt:
●Importing
-REQUEST: Request-ID
-DATAPAKID: Nummer des aktuellen Datenpakets
●Exporting
-
MONITOR: Tabelle für benutzerdefiniertes Monitoring. Diese Tabelle wird mithilfe der
Zeilenstruktur MONITOR_REC gefüllt (die Satznummer des verarbeiteten Satzes wird
vom Framework automatisch eingefügt).
●Changing
-SOURCE_PACKAGE: Struktur mit den Eingangsfeldern der Routine
●Raising
-CX_RSROUT_ABORT: Wenn in der Routine eine Ausnahme des Typs CX
RSROUT_ABORT ausgelöst wird, wird der gesamte Ladeprozess abgebrochen. Der
Request wird im Extraktionsmonitor als abgebrochen gekennzeichnet. Die
Verarbeitung des aktuellen Datenpakets wird beendet. Bei schwerwiegenden Fehlern
ist dies sinnvoll.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 220Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

229. Abbildung 195: Transformationsregeln: Regeldetails
Eine Transformation besteht aus mindestens einer Transformationsregel. Es stehen
verschiedene Regeltypen, Transformationsarten und Routinenarten zur Verfügung. Mithilfe
der folgenden Regeln können Sie einfache bis hoch komplexe Transformationen erstellen:
●Transformationsregeln
Transformationsregeln ordnen eine beliebige Anzahl von Quellfeldern mindestens einem
Zielfeld zu. Dazu können Sie verschiedene Regeltypen verwenden.
●Regeltyp
Ein Regeltyp ist ein Vorgang, der mittels einer Transformationsregel auf die betreffenden
Felder angewendet wird. Weitere Informationen finden Sie unter „Regeltyp“.
●Transformationsart
Die Transformationsart bestimmt, wie die Daten in die Zielfelder geschrieben werden.
Weitere Informationen finden Sie unter „Aggregationsart“.
●Regelgruppe
Eine Regelgruppe ist eine Gruppe von Transformationsregeln. Mithilfe von Regelgruppen
können Sie verschiedene Regeln kombinieren. Weitere Informationen finden Sie unter
„Regelgruppe“.
●Routine
Routinen verwenden Sie zur Implementierung komplexer Transformationsregeln. Routinen
sind als Regeltyp verfügbar. Außerdem gibt es Routinenarten, die Sie zur Implementierung
zusätzlicher Transformationen nutzen können. Weitere Informationen finden Sie unter
„Routinen in der Transformation“.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 221Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

230. Abbildung 196: Transformationsregeln
Regeltyp
Der Regeltyp bestimmt, ob und wie ein Merkmal/eine Kennzahl bzw. ein Datenfeld/ein
Schlüsselfeld in das Ziel fortgeschrieben wird.
Direkte Zuordnung
Das Feld wird direkt aus dem gewählten Quell-InfoObject gefüllt. Wenn das System kein Quell-
InfoObject vorschlägt, können Sie ein Quell-InfoObject desselben Typs (Betrag, Zahl, Integer,
Menge, Float, Zeit) zuordnen oder eine Routine anlegen. Wenn Sie einem Ziel-InfoObject ein
Quell-InfoObject desselben Typs zuordnen, das jedoch eine andere Währung hat, müssen Sie
die Quellwährung über die Währungsumrechnung in die Zielwährung umrechnen oder die
Währung aus der Quelle übernehmen.
Wenn Sie einem Ziel-InfoObject ein Quell-InfoObject desselben Typs zuordnen, das jedoch
eine andere Mengeneinheit hat, müssen Sie die Quellmengeneinheit über die
Mengeneinheitenumrechnung in die Zielmengeneinheit umrechnen oder die Mengeneinheit
aus der Quelle übernehmen.
Konstante
Das Feld wird direkt mit dem eingegebenen Wert gefüllt. Eine Ausnahme ist das InfoObject
0RECORDMODE, für das vom System „Konstante“ ausgewählt wird, aber kein Wert nötig ist.
Die Konstante wird in diesem Fall für die Delta-Verwaltung (After-Images) bei DataStore-
Objekten oder InfoObjects als InfoProvider benötigt. Abgesehen davon werden keine Sätze
gelöscht. Wenn Ihre DataSource ein passendes Feld für 0RECORDMODE zurückgibt, können
Sie dieses stattdessen direkt zuweisen.
Formel
Das InfoObject wird mit einem Wert fortgeschrieben, der anhand einer Formel ermittelt wird.
Weitere Informationen finden Sie unter „Transformationsbibliothek und Formeleditor“.
Stammdaten lesen
Die Fortschreibung des InfoObjects erfolgt durch Lesen der Stammdatentabelle eines
Merkmals, das in der Quelle mit einem Schlüssel und einem Wert enthalten ist und das
entsprechende InfoObject als Attribut enthält. Die Attribute und die zugehörigen Werte
werden über den Schlüssel ermittelt und anschließend zurückgegeben.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 222Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

231. Notiz:
Im Ziel befindet sich das Merkmal Finanzkreis, das jedoch nicht als Merkmal in der
Quelle vorkommt. In der Quelle befindet sich jedoch ein Merkmal (beispielsweise
Kostenstelle), das das Merkmal Finanzkreis als Attribut hat. Sie können das
Attribut Finanzkreis aus der Stammdatentabelle lesen und damit das Merkmal im
Ziel füllen.
Notiz:
Es ist nicht möglich, weitere Attribute der Attribute zu lesen. Dazu müssen Sie
Routinen verwenden. Wenn Sie Stammdaten geändert haben, müssen Sie den
Änderungslauf vornehmen. Der Grund hierfür liegt darin, dass beim
Stammdatenlesen die aktive Version gelesen wird. Wird diese nicht gefunden, wird
ein Fehler ausgegeben. Wenn das Attribut zeitabhängig ist, müssen Sie zusätzlich
den Lesezeitpunkt festlegen: zum jeweils aktuellen Datum (sy-datum), zu Beginn
oder Ende eines Zeitraums (durch das Zeitmerkmal in der InfoSource festgelegt)
oder zu einem konstanten Datum, das Sie direkt eingeben. Standardmäßig wird
sy-datum verwendet.
Aus DataStore-Objekt lesen
Die Fortschreibung des InfoObjects erfolgt ähnlich wie beim Stammdatenlesen durch Lesen
eines Merkmals in einem DataStore-Objekt. Es gibt allerdings keine Zeitabhängigkeit. Daten
werden sowohl aus der Datenbank als auch aus einem Nearline-Storage gelesen. Wenn ein
Nearline-Storage gefunden wird, prüft das System automatisch, ob dort Daten vorhanden
sind und liest diese.
Das Lesen von Stammdaten und DataStore-Objekten bei Bedarf ist Performance-optimiert.
Die disjunkten Schlüssel eines kompletten Datenpakets werden durch einen Massenzugriff
von der Datenbank gelesen und für die Weiterverarbeitung gepuff ert. Daher ist keine
kundeneigene Puff erung über eine Startroutine notwendig, da die Performance sehr ähnlich
ist.
Das System kann diese Daten nur lesen, wenn im Datenteil des DataStore-Objekts das
Zielfeld enthalten ist. Die Quellfelder werden dann anhand des kompletten Schlüssels
ermittelt. Die Zuweisung funktioniert nur über InfoObjects: Wenn die Quelle eine DataSource
ist, müssen Sie dem Feld ein InfoObject zuweisen.
Notiz:
Wenn im DataStore-Objekt mehr Schlüsselfelder als in der Quelle vorhanden sind,
kann es zu Performanceproblemen kommen.
Schreiboptimierte DataStore-Objekte benötigen einen semantischen Schlüssel.
Um Performanceprobleme zu vermeiden, müssen die Daten eindeutig sein. Sie
können festlegen, wie sich das System verhalten soll, wenn das Lesen fehlschlägt:
Das System gibt entweder eine Fehlermeldung aus, oder es gibt eine Konstante
an.
Aus DataStore-Objekt (advanced) lesen
Zum Lesen aus einem DataStore-Objekt (advanced) erhalten Sie zunächst einen Vorschlag
vom System, wie die Felder zugeordnet werden können. Die Schlüsselfelder müssen den
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 223Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

232. Quellfeldern in der Transformation zugeordnet werden. Beim Zuordnen der Felder müssen
die Namen nicht identisch sein.
Routine
Das Feld wird durch eine von Ihnen definierte Transformationsroutine gefüllt.
Notiz:
Bei DataStore-Objekten und InfoObjects: Für Datenfelder, die durch
Überschreiben fortgeschrieben werden, kann der Returncode in der Routine nicht
verwendet werden. Wenn Sie bestimmte Sätze nicht fortschreiben möchten,
können Sie diese aus der Startroutine löschen.
Wenn Sie für dasselbe Merkmal verschiedene Regeln für verschiedene
Kennzahlen/Datenfelder erzeugen, kann aus dem Datensatz der Quelle für jede
Kennzahl ein eigener Datensatz angelegt werden.
Bei InfoCubes: Sie können auch „Routine mit Einheit“ auswählen. Der Routine wird
dann auch der Rückgabeparameter UNIT hinzugefügt. Im Parameter können Sie
die erforderliche Einheit der Kennzahl hinterlegen, beispielsweise „ST“. Diese
Option können Sie nutzen, um beispielsweise die in der Quelle vorhandene Einheit
Kilogramm im Ziel in die Einheit Tonnen umzuwandeln.
Wenn Sie die Zielkennzahl aus einer Transformationsroutine füllen, muss die
Währungsumrechnung über die Transformationsroutine erfolgen. Das bedeutet,
dass keine automatische Berechnung möglich ist.
Zeitfortschreibung
Bei einer Zeitfortschreibung stehen die automatische Zeitkonvertierung und Zeitverteilung
zur Verfügung. Direkte Fortschreibung: Das System führt die Zeitkonvertierung automatisch
durch.
Zeitkonvertierung
Mit der automatischen Zeitkonvertierung können Sie Zeitmerkmale der Quelle in
Zeitmerkmale des Ziels fortschreiben. Diese Funktion ist für DataStore-Objekte nicht
verfügbar, da Zeitmerkmale wie gewöhnliche Datenfelder behandelt werden. Das System
bietet nur Zeitmerkmale an, zu denen eine automatische Zeitkonvertierungsroutine
vorhanden ist.
Zeitverteilung
Mit der Zeitverteilung können Sie Zeitmerkmale fortschreiben. Alle Kennzahlen, die
hinzugefügt werden können, werden in entsprechende kleinere Zeiteinheiten aufgeteilt. Wenn
die Quelle ein Zeitmerkmal (beispielsweise 0CALMONTH) enthält, das gröber ist als ein
Zeitmerkmal des Ziels (beispielsweise 0CALWEEK), können Sie diese Merkmale in der Regel
miteinander verbinden. Das System führt dann bei der Transformation eine Zeitverteilung
durch.
Initial
Das Feld bleibt leer.
Keine Transformation
Die Kennzahlen werden nicht in den InfoProvider geschrieben. Wenn eine Endroutine
vorhanden ist, werden alle Felder aus der Feldliste der Endroutine in das Datenziel
übertragen.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 224Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

233. Mengeneinheiten- und Währungsumrechnung
Sie können Datensätze in die Mengeneinheit oder die Währung des Ziels der Transformation
umrechnen.
Berechnung 0RECORDMODE für ODP
Wenn die Quelle Ihrer Transformation eine DataSource ist, die über einen Operational Data
Provider (ODP) mit Daten versorgt wird, und das Ziel entweder ein DataStore-Objekt oder ein
InfoObject ist, benötigen Sie für die Quellfelder ODQ_CHANGEMODE und ODQ_ENTITYCNTR
den Regeltyp „Berechnung 0RECORDMODE für ODP“.
Über diesen Regeltyp kann auch das Feld 0RECORDMODE berechnet werden. Wenn Sie
Deltas aus einem ODP laden, der nicht nur eine Image-Art (z.B. After-Images, Delete-Images
und New-Images) liefert, wird dieses Änderungsverhalten über die Felder
ODQ_CHANGEMODE und ODQ_ENTITYCNTR bereitgestellt. Aus diesen Feldern muss für die
Verwendung im BW-System das Feld 0RECORDMODE berechnet werden.
Aggregationsart
Mit der Aggregationsart steuern Sie, wie eine Kennzahl oder ein Datenfeld in den InfoProvider
fortgeschrieben wird.
Funktionen für InfoCubes
Je nachdem, welche Aggregationsart Sie in der Kennzahlenpflege für diese Kennzahl
angegeben haben, stehen Ihnen die Optionen Summierung, Maximum oder Minimum zur Verfügung. Bei Auswahl einer dieser Optionen werden neue Werte in den InfoCube
fortgeschrieben. Die Aggregationsart (Summierung, Minimum oder Maximum) gibt an, wie
Kennzahlen im Fall identischer Primärschlüssel fortgeschrieben werden. Bei neuen Werten
wird entweder die Summe, das Minimum oder das Maximum für diese Werte gebildet.
Für InfoObjects
Es ist nur die Option „Überschreiben“ verfügbar. Mit dieser Option werden neue Werte in das
InfoObject fortgeschrieben.
Für DataStore-Objekte
Je nach Art der Daten und der DataSource stehen die Optionen „Summierung“, „Minimum“,
„Maximum“ oder „Überschreiben“ zur Verfügung. Bei numerischen Datenfeldern erhalten Sie
durch das Merkmal 0RECORDMODE einen Vorschlag zur Fortschreibungsart. Wenn nur das
After-Image geliefert wird, wird „Überschreiben“ vorgeschlagen. Es ist jedoch sinnvoll, dies zu
ändern: z.B. bei dem Zählerdatenfeld „# Änderungen“, das durch eine Konstante „1“ gefüllt
wird, aber trotzdem (durch Addition) fortgeschrieben werden muss, auch wenn nur ein After-
Image geliefert wird.
Summierung
Die Summierung ist möglich, wenn die DataSource zu einem additiven Delta fähig ist. Bei den
Datentypen CHAR, DAT, TIMS, CUKY und UNIT wird die Summierung nicht unterstützt.
Überschreiben
Überschreiben ist möglich, wenn die DataSource deltafähig ist.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 225Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

234. Notiz:
Das Merkmal 0RECORDMODE dient dazu, Kennzeichen der DataSource (aus
SAP-Systemen) an die Fortschreibung zu übergeben. Solange Sie keine Delta-
Requests in das DataStore-Objekt laden oder nur aus Datei-DataSources laden,
wird das Merkmal 0RECORDMODE nicht benötigt.
Achtung:
Das System hält sich beim Fortschreiben an die zeitliche Reihenfolge der
Datenpakete und Requests. Für die logische Reihenfolge der Fortschreibung
müssen Sie selbst sorgen. Aufträge müssen vor Lieferungen angefordert
werden, sonst kann es durch das Überschreiben der Daten zu falschen
Ergebnissen kommen. Requests müssen beim Fortschreiben serialisiert werden.
Abbildung 197: Transformationsregeltyp „Formel“
In der Transaktion zur Bearbeitung von Transformationsregeln und Fortschreibungsregeln
steht Ihnen eine Transformationsbibliothek zur Verfügung, die Sie beim Arbeiten mit dem
Formeleditor nutzen können.
Notiz:
Beim Arbeiten mit VirtualProvidern sollten Sie keine Formeln verwenden, da hier
keine Invertierung möglich ist. Verwenden Sie in diesem Fall Routinen.
Wenn Sie die Transformationsbibliothek in Verbindung mit dem Formeleditor verwenden,
können Sie Formeln erstellen, ohne dass dazu ABAP-Coding erforderlich ist.
Die Transformationsbibliothek enthält mehr als 70 vordefinierte Funktionen aus den
folgenden Kategorien:
●Funktionen für Zeichenketten
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 226Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

235. ●Datumsfunktionen
●Grundfunktionen
●Mathematische Funktionen
●passende Funktionen
●sonstige Funktionen
Notiz:
Bei Formeln findet keine Typprüfung statt. Das heißt, es wird nicht geprüft, ob das
Ergebnis der Formel dem Typ des Zielfeldes entspricht.
In der Transformationsbibliothek im Formeleditor können Sie selbstdefinierte Funktionen
implementieren. In diese selbstdefinierten Funktionen können Sie vorhandene
Funktionsbausteine einbinden. Sie können Funktionen, die gegenwärtig nicht in der
Transformationsbibliothek enthalten sind, zur häufigen Verwendung verfügbar machen.
Der Formeleditor verfügt über den Standardmodus und den Expertenmodus. Im
Standardmodus können Sie Formeln nur über die Drucktasten und durch Doppelklick auf
Funktionen und Felder eingeben. Im Expertenmodus können Sie Formeln direkt eingeben.
Während der Eingabe einer Formel kann auch zwischen den beiden Modi gewechselt werden.
Notiz:
Unter „Anlegen einer Formel“ sind die Schritte und die Syntax zum Anlegen einer
Formel im Formeleditor dargestellt.
Abbildung 198: Zeitverteilung
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 227Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

236. Sie können den Kalendermonat 07.2001 auf die Wochen 26.2001, 27.2001, 28.2001, 29.2001,
30.2001 und 31.2001 aufteilen. Jede addierbare Kennzahl erhält für die Woche 26.2001 1/31
des ursprünglichen Werts, für die Wochen 27, 28, 29 und 30 jeweils 7/31 und für die Woche 31
genau 2/31 des ursprünglichen Werts. Die Zeitverteilung gilt immer für alle Kennzahlen.
Abbildung 199: Transformation: Regelgruppen
Regelgruppe
Eine Regelgruppe ist eine Gruppe von Transformationsregeln. Sie enthält eine
Transformationsregel für jedes Schlüsselfeld des Ziels. Eine Transformation kann mehrere
Regelgruppen enthalten. Mithilfe von Regelgruppen können Sie verschiedene Regeln
kombinieren. Sie können für ein Merkmal verschiedene Regeln für verschiedene Kennzahlen
anlegen.
Jede Transformation enthält zunächst eine Standardgruppe. Sie können neben dieser
Standardgruppe weitere Regelgruppen anlegen. Wenn Sie in den Regeldetails eine neue Regel
definiert haben, können Sie angeben, ob diese Regel für andere Regelgruppen als
Referenzregel verwendet werden soll. Wenn sie als Referenzregel verwendet wird, dann wird diese Regel auch in den anderen vorhandenen Regelgruppen verwendet, falls dort keine
andere Regel definiert wurde.
Die Quelle enthält die folgenden drei Datumsmerkmale:
●Bestelldatum
●Lieferdatum
●Rechnungsdatum
Das Ziel enthält genau ein allgemeines Datumsmerkmal. Je nach Kennzahl wird dieses
Merkmal mit den verschiedenen Datumsmerkmalen der Quelle gefüllt. Sie legen drei
Regelgruppen an, die je nach Kennzahl entweder das Bestelldatum, das Lieferdatum oder das
Rechnungsdatum in das Ziel fortschreiben.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 228Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

237. Abbildung 200: Regelgruppen
Abbildung 201: Beispiel für Regelgruppen
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 229Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

238. Abbildung 202: Endroutine
Die Endroutine ist eine Routine mit einer Tabelle im Format der Zielstruktur als
Eingangsparameter und Ausgangsparameter. Mit ihr können paketweise Nachbehandlungen
der Daten nach der Transformation durchgeführt werden. Sie können z.B. Sätze löschen, die
nicht fortgeschrieben werden sollen, oder Überprüfungen der Daten durchführen.
Notiz:
Wenn das Ziel der Transformation ein DataStore-Objekt ist, werden Kennzahlen
standardmäßig mit dem Aggregationsverhalten „Überschreiben“ (MOVE)
fortgeschrieben. Dies können Sie nur durch eine Dummy-Regel übersteuern.
Beispiel für Endroutine
Sie laden Daten über die DataSource „Hauptbuch: Verkehrszahlen“ (0FI_GL_1) im SAP-ERP-
System in das DataStore-Objekt „FIGL: Verkehrszahlen“ (0FIGL_O06). Sie möchten eine
Endroutine anlegen, durch die das zusätzliche InfoObject „Plan-/Ist-Kennzeichen“
(ZPLACTUAL) gefüllt wird. Die Routine soll außerdem das Feld „Werttyp“ lesen. Wenn der
Wert 10 (Ist) beträgt, wird der Wert A in das InfoObject „Plan-/Ist-Kennzeichen“ geschrieben,
wenn der Wert 20 (Plan) beträgt, wird der Wert P in das InfoObject „Plan-/Ist-Kennzeichen“
geschrieben.
In der Pflege der Transformation wählen Sie Endroutine anlegen. Im daraufhin geöffneten
Routineneditor geben Sie folgende Coding-Zeilen ein:
*----------------------------------------------------------------------
*
METHOD end_routine.
*=== Segments ===
FIELD-SYMBOLS:
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 230Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

239. <RESULT_FIELDS> TYPE _ty_s_TG_1.
*$*$ begin of routine - insert your code only below this line *-*
loop at RESULT_PACKAGE assigning <RESULT_FIELDS>
where vtype eq '010' or vtype eq '020'.
case <RESULT_FIELDS>-vtype.
when '010'.
<RESULT_FIELDS>-/bic/zplactual = 'A'. "Actual
when '020'.
<RESULT_FIELDS>-/bic/zplactual = 'P'. "Plan
endcase.
endloop.
*$*$ end of routine - insert your code only before this line *-*
ENDMETHOD.
"end_routine
*----------------------------------------------------------------------
*
Das Coding macht einen Loop über das result_package und sucht nach Werten, die den
Werttyp 10 oder 20 haben. Für diese Werte wird dann der entsprechende Wert an das
InfoObject „Plan-/Ist-Kennzeichen“ (ZPLACTUAL) übergeben.
Nach Eingabe des Codings können Sie den Editor verlassen und die Transformation sichern.
Am Bleistiftsymbol nebenEndroutineerkennen Sie, dass eine Endroutine verfügbar ist.
In der folgenden Liste sind die Parameter der Endroutine aufgeführt:
●Importing
-REQUEST: Request-ID
-DATAPAKID: Nummer des aktuellen Datenpakets
●Exporting
-
MONITOR: Tabelle für benutzerdefiniertes Monitoring. Diese Tabelle wird mithilfe der
Zeilenstruktur MONITOR_REC gefüllt (die Satznummer des verarbeiteten Satzes wird
vom Framework automatisch eingefügt).
●Changing
-RESULT_PACKAGE: enthält alle Daten, die die Transformation durchlaufen haben
●Raising
-CX_RSROUT_ABORT: Wenn in der Routine eine Ausnahme des Typs
CX_RSROUT_ABORT ausgelöst wird, wird der gesamte Ladeprozess abgebrochen. Der
Request wird im Extraktionsmonitor als abgebrochen gekennzeichnet. Die
Verarbeitung des aktuellen Datenpakets wird beendet. Bei schwerwiegenden Fehlern
kann dies hilfreich sein.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 231Librer?a= ERP https://libreriaerp.com/us [email protected] Librer?a= ERP https://libreriaerp.com/us [email protected]

240. Notiz:
In der Standardeinstellung werden nur die Felder aus der Endroutine
übernommen, die in der Transformation eine Regel haben. Wählen Sie
Fortschreibungsverhalten Endroutine ändern, um das Kennzeichen „alle Zielfelder
(unabhängig von aktiven Regeln)“ zu setzen. In diesem Fall werden auch Felder,
die erst in der Endroutine gefüllt werden, fortgeschrieben und gehen nicht
verloren. Diese Funktion ist nur für Standard-DataStore-Objekte, DataStore-
Objekte für direktes Schreiben und für Stammdatentabellen verfügbar.
Wenn bei Stammdatenattributen nur die Schlüsselfelder fortgeschrieben werden,
werden in jedem Fall unabhängig von der hier beschriebenen
Einstellungsmöglichkeit alle Attribute initialisiert. Weitere Informationen hierzu
finden Sie im SAP-Hinweis 1096307.
Anlegen einer Formel
Sie möchten eine Formel anlegen. Das Feld „Buchungskreis“ (0COMP_CODE) ist nicht in
Ihrem Datenziel bzw. Ihrer InfoSource enthalten. Sie können den Buchungskreis jedoch
anhand der ersten vier Stellen der Kostenstelle (0COSTCENTER) ermitteln.
Sie legen die folgende Formel an: SUBSTRING( Kostenstelle , '0' , '4')
Dabei müssen Sie die folgende Syntax verwenden: SUBSTRING( Zeichenkette , Off set ,
Länge )
Abbildung 203: Formeleditor
1.Wählen Sie in der Transformationsbibliothek auf der rechten Seite unterZeige mir:die
KategorieZeichenkettenaus. In der Liste wählen SieSubstringaus. Die Syntax der Formel
wird im Formelfenster angezeigt:SUBSTRING( , , ).
2.Der Cursor positioniert sich automatisch auf dem ersten anzugebenden Parameter.
3.In der Liste auf der linken Bildseite wählen SieKostenstelleaus.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 232Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

241. 4.Positionieren Sie den Cursor an der Stelle, an der Sie den nächsten Parameter eingeben
möchten.
5.Geben Sie über die DrucktasteKonstante(für den Parameter „Off set“) die Zahl0ein. Die
Hochkommata werden automatisch eingefügt.
6.Positionieren Sie den Cursor an der Stelle, an der Sie den nächsten Parameter eingeben
möchten.
7.Geben Sie über die DrucktasteKonstante(für den Parameter „Länge“) die Zahl4ein.
8.Wählen SieZurück.
Die Formel wird nun geprüft und gesichert, wenn sie korrekt ist. Werden bei der Prüfung
Fehler gefunden, erhalten Sie eine Meldung und das fehlerhafte Element wird farblich
hervorgehoben.
Details zum Datentransferprozess
Abbildung 204: Extraktionsmodus und Filtereinstellung im Datentransferprozess (DTP)
Datentransferprozess (DTP)
Ein Datentransferprozess (DTP) ist ein Objekt, das festlegt, wie Daten zwischen zwei
persistenten Objekten (Quelle und Ziel) in SAP BW übertragen werden.
Den Datentransferprozess verwenden Sie, um Daten innerhalb von SAP BW unter
Anwendung von Transformationen und Filtern von einem persistenten Objekt in ein anderes
zu übertragen. Sie können zwischen der Quelle und dem Ziel des Datentransferprozesses eine
Transformation anlegen. Alternativ können Sie mithilfe von InfoSources, die keine Persistenz
haben, den Datentransferprozess mit mehreren Transformationen hintereinander (d.h. mit
einem Transformationspfad) durchführen. Der Datentransferprozess ersetzt das
InfoPackage, das seit SAP NetWeaver 7.0 nur noch Daten in die Persistent Staging Area
(PSA) der DataSource lädt, sowie das Data Mart Interface.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 233Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

242. Der Datentransferprozess sorgt für transparente Transferprozesse in der Data-Warehousing-
Schicht. Eine optimierte parallele Verarbeitung wirkt sich positiv auf den Transferprozess aus
(der Datentransferprozess bestimmt den Verarbeitungsmodus). Mit dem
Datentransferprozess können Sie Delta-Verfahren für verschiedene Ziele trennen, und Sie
können Filteroptionen zwischen den persistenten Objekten auf verschiedenen Ebenen
verwenden, beispielsweise zwischen einem DataStore-Objekt und einem InfoCube.
Datentransferprozesse werden für den Standarddatentransfer, für Real-Time Data
Acquisition und für den direkten Datenzugriff verwendet.
Funktionen des Datentransferprozesses
Sie definieren einen Datentransferprozess über eine Prozesskette. Alternativ dazu können Sie
einen Datentransferprozess für einen InfoProvider in einem Objektbaum in der Data
Warehousing Workbench definieren. Wir empfehlen die Verwendung in Prozessketten. In
diesem Fall wird der Datentransferprozess ausgeführt, sobald er durch ein Ereignis im Vorgängerprozess der Prozesskette ausgelöst wird. Alternativ können Sie einen
Datentransferprozess in der Prozesskettenpflege im Hintergrund ausführen. Es steht auch
ein Debugging-Modus zur Verfügung.
Der Request ist eine Instanz, die zur Laufzeit des Datentransferprozesses generiert wird. Der
Request wird in den zuvor definierten Schritten des Datentransferprozesses verarbeitet
(Extraktion, Transformation und Filter). Im Monitor für den Request des
Datentransferprozesses werden die Kopfdaten, der Request-Status sowie der Status und die
Meldungen für die einzelnen Verarbeitungsschritte angezeigt.
Mit dem Datentransferprozess können Sie Daten entweder im Extraktionsmodus „Full“ oder
„Delta“ übertragen. Beim Full-Modus wird der gesamte Datenbestand der Quelle in das Ziel
übertragen; beim Delta-Modus werden nur jene Daten übertragen, die seit dem letzten
Transfer im Quellsystem verbucht wurden. Der Datentransferprozess steuert das Delta-
Handling und macht es dadurch möglich, verschiedene Ziele mit unterschiedlichen Deltas aus
einer Quelle zu beliefern. Eine Initialisierung des Delta-Verfahrens (wie bei der
Datenübernahme mit einem InfoPackage) muss bei einem Datentransferprozess nicht explizit
ausgeführt werden.
Der Datentransferprozess unterstützt die Behandlung fehlerhafter Datensätze. Wenn Sie den
Datentransferprozess definieren, können Sie festlegen, wie das System im Fehlerfall
reagieren soll. Zur Laufzeit werden die fehlerhaften Datensätze aussortiert und in einen
Fehlerstack (Request-basierte Datenbanktabelle) geschrieben. Die Fortschreibung aus dem
Fehlerstack in das Ziel erfolgt über einen speziellen Fehler-DTP. Fehlgeschlagene
Ladeprozesse lassen sich auf einfachere Weise erneut starten, wenn nach den einzelnen
Verarbeitungsschritten jeweils die Daten in einen Zwischenspeicher geschrieben werden.
Dadurch können Sie außerdem fehlerhafte Datensätze ermitteln. Über den Monitor für den
Request des Datentransferprozesses bzw. im jeweiligen Zwischenspeicher für die
Verarbeitungsschritte (sofern gefüllt) können Sie die Datensätze im Fehlerstack aufrufen. Bei
der Verwaltung des Datentransferprozesses legen Sie fest, nach welchen
Verarbeitungsschritten die Daten zwischengespeichert werden sollen.
Über „Filter“ können Sie bei Bedarf Filterkriterien für die Datenübertragung festlegen. Das
bedeutet, dass Sie, statt große Datenmengen zu übertragen, mehrere Datentransferprozesse
mit disjunktiven Selektionsbedingungen zur Übertragung kleiner Datenmengen aus der Quelle
in ein oder mehrere Ziele verwenden können. Der Filter schränkt somit die Menge der zu
übertragenden Daten ein und funktioniert wie die Selektionen im InfoPackage. Sie können
Einzelwerte, Mehrfachselektionen, Intervalle, Selektionen auf Basis von Variablen oder
Routinen angeben. Wenn Sie die Liste der auswählbaren InfoObjects ändern möchten, wählen
SieSelektion ändern. Das grüne Häkchen neben der Drucktaste „Filter“ zeigt an, dass für den
Datentransferprozess vordefinierte Selektionen vorhanden sind. Die Quick-Info zu diesem
Symbol zeigt die Selektionen als Zeichenkette an.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 234Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

243. Abbildung 205: Laden von Daten aus HANA in DSO (advanced)
HANA-optimierte Transformationsregeln
Abbildung 206: SAP-HANA-optimierte Transformationsregeln
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 235Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

244. Wenn Ihr BW auf einer SAP-HANA-Datenbank läuft, kann bzw. muss in bestimmten Fällen der
Datentransferprozess (DTP) mit dem Verarbeitungstyp „SAP-HANA-Ausführung“ verarbeitet
werden. Der Verarbeitungstyp wird im DTP im Bereich der Kopfdaten über das
entsprechende Kennzeichen „SAP-HANA-Ausführung“ gesteuert.
Für die Verarbeitung des Datentransferprozesses in SAP HANA gelten folgende Regeln:
●Der Datentransferprozess kann mit dem Verarbeitungstyp „SAP-HANA-Ausführung“
ausgeführt werden, wenn die Prüfung aller Transformationen für den
Datentransferprozess ergeben hat, dass sie in SAP HANA ausgeführt werden können. In
diesem Fall ist das Kennzeichen auf dem Pflegebild für den Datentransferprozess
eingabebereit, und Sie können das Kennzeichen setzen, wenn die Voraussetzungen dafür
im Datentransferprozess erfüllt sind. Wenn dies bereits beim Anlegen der Fall ist, ist das
Kennzeichen standardmäßig gesetzt.
●Der Datentransferprozess muss mit dem Verarbeitungstyp „SAP-HANA-Ausführung“
ausgeführt werden, wenn Sie in einer der Transformationen zum Datentransferprozess
ABAP Managed Database Procedures verwenden. In diesem Fall ist auf dem Pflegebild für
den Datentransferprozess das Kennzeichen gesetzt und nicht eingabebereit. Es ist der
Verarbeitungstyp „SAP-HANA-Ausführung“ eingestellt.
●Der Datentransferprozess kann nicht mit dem Verarbeitungstyp „SAP-HANA-Ausführung“
ausgeführt werden, wenn Sie in einer der Transformationen für den Datentransferprozess
eine ABAP-Routine verwenden. In diesem Fall ist auf dem Pflegebild für den
Datentransferprozess das Kennzeichen gesetzt und nicht eingabebereit, und es ist ein
Verarbeitungstyp eingestellt, der auf dem ABAP-Server ausgeführt werden kann.
Notiz:
Wenn es einen Pfad gibt, in dem eine Transformation eine ABAP-Routine enthält
und eine andere Transformation ABAP Managed Database Procedures, können
Sie zu diesem Pfad keinen Datentransferprozess definieren. Ändern Sie in diesem
Fall die Transformation dahin gehend, dass entweder die ABAP-Routine oder ABAP Managed Database Procedures verwendet werden können, aber nicht beides.
Transformation in der SAP-HANA-Datenbank
Wenn Sie eine SAP-HANA-Datenbank einsetzen, werden, soweit dies möglich ist, sämtliche
Transformationen in der SAP-HANA-Datenbank verarbeitet. Beim Aktivieren einer
Transformation prüft das System, ob die Transformation in SAP HANA ausgeführt werden
kann. Ist dies der Fall, können Sie festlegen, ob die Transformation in SAP HANA oder im
Anwendungsserver ausgeführt werden soll. Diese Festlegung nehmen Sie beim Anlegen eines
Datentransferprozesses vor. Wenn es sich jedoch um eine Transformation mit einer ABAP
Managed Database Procedure handelt, muss die Ausführung in SAP HANA erfolgen.
Über die OptionPrüfenrechts vom Namensfeld der Transformation können Sie prüfen, ob die
Transformation in SAP HANA ausgeführt werden kann. Dabei versucht das System, die
Transformation in SAP HANA anzulegen. Wenn dies erfolgreich ist, wird für die
Transformation das KennzeichenAusführen in SAP HANA möglichgesetzt. Wenn die Prüfung
nicht erfolgreich ist, finden Sie im Protokoll Informationen zu den entsprechenden Gründen.
Wenn Sie spezielle Transformationen benötigen, die mit den Standardregeln der
Transformation nicht möglich sind, können Sie diese als ABAP Managed Database
Procedures in SAP HANA anlegen. Diese Funktion ist nur für Experten vorgesehen. Um diese
Funktion verwenden zu können, müssen Sie als Entwickler registriert sein.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 236Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

245. Notiz:
Datumsberechnungen (z.B. sy-datum + 1) müssen Sie sowohl bei interner als
auch bei externer Darstellung mit der Formel ADD_DAYS_TO_DATE modellieren.
Folgende Objekte werden als Ziele unterstützt:
●DataStore-Objekt (klassisch: Standard und schreiboptimiert)
●DataStore-Objekt (advanced)
●auf DataStore-Objekten basierende semantisch partitionierte Objekte
●Open Hub Destinations mit DB-Tabellen (ohne Datenbankverbindung) oder
Drittanbieterwerkzeugen
Folgende Objekte werden für die Ausführung von Transformationen in SAP HANA nicht
unterstützt:
●Queries als InfoProvider
●ABAP-Routinen (Regeltypen Routine, Merkmals-, Start-, End- und Expertenroutine)
●Regelgruppen
●Nearline-Verbindungen
●DataStore-Objekte
Für das Lesen aus DataStore-Objekten muss der vollständige Schlüssel angegeben
werden.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 237Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

246. Abbildung 207: HANA-basierte Expertenroutinen
Voraussetzungen für den Verarbeitungstyp
Wenn die Transformation die Ausführung in SAP HANA unterstützt, müssen im
Datentransferprozess die folgenden Voraussetzungen erfüllt sein, damit der
Verarbeitungstyp „SAP-HANA-Ausführung“ verwendet werden kann:
●Die Fehlerbehandlung ist ausgeschaltet.
●Es sind keine Requests im Fehlerstack des Datentransferprozesses vorhanden.
●Es ist keine Liste für die semantische Gruppierung gepflegt, d.h. die Daten werden nicht in
semantischen Gruppen extrahiert und fortgeschrieben.
●Wenn das Ziel des Datentransferprozesses ein DataStore-Objekt ist, ist auf der
Registerkarte „Verbuchung“ die Option „Weiterverarbeitung auch ohne Stammdaten“
ausgewählt.
●Wenn das Ziel des Datentransferprozesses eine Open Hub Destination ist, handelt es sich
bei der Destination um eine Datenbanktabelle oder ein Drittanbieterwerkzeug.
●Wenn die Quelle des Datentransferprozesses ein DataStore-Objekt ist, ist auf der
Registerkarte „Extraktion“ der Parameter zur DeltaInit-Extraktion aus „aktiver Tabelle (mit
Archiv)“ nicht gesetzt.
●Wenn die Quelle des Datentransferprozesses eine DataSource ist, erfolgt die
Datenextraktion aus der PSA. Auf der Registerkarte „Extraktion“ ist in den Parametern der
DataSource unter „Datenextraktion“ die Option „Aus PSA“ ausgewählt.
Verarbeitungstyp prüfen und festlegen
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 238Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

247. Der Verarbeitungstyp ist beim Anlegen des Datentransferprozesses voreingestellt, wenn die
Voraussetzungen dafür erfüllt sind oder die Verarbeitung in SAP HANA aufgrund der
Transformation erforderlich ist. Beim Bearbeiten des Datentransferprozesses können Sie das
eingabebereite Kennzeichen „SAP-HANA-Ausführung“ setzen. Das System führt dann eine
Prüfung durch. Wenn eine oder mehrere der Voraussetzungen nicht erfüllt sind, ist das
Setzen des Kennzeichens nicht möglich, und das System zeigt ein Dialogfenster mit
Meldungen zu den Inkompatibilitäten an.
Wenn das Kennzeichen „SAP-HANA-Ausführung“ im DTP gesetzt ist und Sie eine Änderung
am DTP vornehmen, die mit der SAP-HANA-Ausführung nicht kompatibel ist (z.B. das
Aktivieren der Fehlerbehandlung), hebt das System die Markierung des Kennzeichens auf und
zeigt ein Dialogfenster mit Meldungen zu den Inkompatibilitäten an. Über die Option
Verfügbarkeit prüfenkönnen Sie im Anzeigemodus prüfen, ob die Verarbeitung in SAP HANA
möglich ist.
Parallelisierung der Verarbeitung
Requests werden in parallelen Prozessen verarbeitet. Vom Hauptprozess wird für jedes
Datenpaket ein paralleler Prozess abgeleitet. Dieser parallele Prozess führt die Extraktion und
Verarbeitung der Daten durch. Auf der Registerkarte „Extraktion“ ist das Feld „parallele
Extraktion“ ausgewählt. Siehe SAP-Hinweis 1935460.
Notiz:
Für Datentransferprozesse, die bei der Verarbeitung im ABAP-Server den
Verarbeitungstyp „Extraktion und Verarbeitung parallel außer Delta Init.“
verwenden würden, gilt bei Verwendung des Verarbeitungstyps „SAP-HANA-
Ausführung“ Folgendes: Die Option „Parallele Extraktion“ auf der Registerkarte
„Extraktion“ ist ausgewählt, und Full-Requests oder Deltainitialisierungs-Requests
werden aus der aktiven Tabelle parallel extrahiert und verarbeitet.
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 239Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

248. Abbildung 208: HANA-basierte Expertenroutinen 2
Im Folgenden ist aufgeführt, welche Auswirkungen eine Änderung der Transformation auf
einen aktiven Datentransferprozess mit dem Verarbeitungstyp „SAP-HANA-Ausführung“ hat:
●Wenn nach einer Änderung der Transformation die Ausführung in SAP HANA nicht mehr
unterstützt wird, ändert das System den Verarbeitungstyp des DTP in einen für den ABAP-
Server geeigneten Verarbeitungstyp und aktiviert den DTP erneut.
●Wenn die Transformation inaktiv ist, setzt das System den DTP ebenfalls auf inaktiv.
●In den meisten anderen Fällen bleibt der DTP aktiv.
●Wenn sich durch Änderungen in Transformationen der Fehlerstack ändert, aktiviert das
System den DTP erneut.
Wenn nach einer Änderung der Transformation (oder durch Erfüllung einer anderen
Voraussetzung im DTP, z.B. Ausschalten der Fehlerbehandlung) die Ausführung in SAP HANA
möglich wird, wird der Verarbeitungstyp „SAP-HANA-Ausführung“ im DTP nicht automatisch
eingestellt. Er muss stattdessen durch den Benutzer über das Kennzeichen „SAP-HANA-
Ausführung“ festgelegt werden.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 240Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

249. Abbildung 209: Transformationen anlegen und Attribut- und Textstammdaten mit DTP laden (Übung)
Abbildung 210: Transformationen anlegen und Bewegungsdaten mit DTP laden (Übung)
Lektion: Erläutern der Details von Datentransformation und Datentransferprozess (DTP) in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 241Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

250. ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●die Möglichkeiten von Datentransformationen und Datentransferprozess in SAP Business
Warehouse powered by HANA erläutern
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 242Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

251. Kapitel 6
Lektion 2
Erläutern von InfoObject-Erweiterungen für
SAP Business Warehouse powered by SAP
HANA
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion werden InfoObject-Erweiterungen für SAP BW erläutert. Darüber hinaus
erfahren Sie, wie Sie virtuelle Stammdaten basierend auf einem SAP-HANA-Modell anlegen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA erläutern
InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA
Abbildung 211: InfoObjects mit hoher Kardinalität (HANA-spezifisch)
Merkmal mit hoher Kardinalität (mehr als 2 Milliarden Datensätze)
Verwenden Sie die Option „Hohe Kardinalität“ nur, wenn Sie erwarten, dass der SID-
Nummernkreis in Höhe von 2 Milliarden nicht ausreicht. Legen Sie das Merkmal andernfalls
ohne die Eigenschaft „Hohe Kardinalität“ an.
Wenn die Eigenschaft „Hohe Kardinalität“ festgelegt ist, hat das Merkmal weder persistente
SID-Werte noch eine SID-Tabelle. Das bedeutet, dass es nur in InfoProvidern verwendet
werden kann, die den Schlüsselwert und nicht den SID-Wert der enthaltenen Merkmale
speichern.
Einschränkungen
©Copyright. Alle Rechte vorbehalten. 243Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

252. Merkmale mit hoher Kardinalität können in den folgenden Elementen nicht verwendet
werden:
●InfoCubes
●Übergeordnete InfoObjects eines geklammerten Merkmals
●Navigationsattribut
●Hierarchien
●SAP-HANA-Analyseprozesse
Die Eigenschaft „Hohe Kardinalität“ wird nur für die Datentypen CHAR und NUMC mit der
Länge >= 10 unterstützt.
Abhängigkeiten
Während des Reportings müssen SID-Werte bei Bedarf als lokale SIDs angelegt werden. Dies
kann die Antwortzeiten der Queries beeinträchtigen.
Abbildung 212: Generierung von SAP-HANA-Views
Externe SAP-HANA-View für BW-Objekte
Sie können dieses Kennzeichen verwenden, um anzugeben, ob eine externe SAP-HANA-View
für das BW-Objekt generiert wird.
Wenn das Kennzeichen gesetzt ist, wird eine externe SAP-HANA-View generiert. Diese
externe SAP-HANA-View wird nicht von der BW-Laufzeit verwendet, kann aber als native
SAP-HANA-Zugriff sschnittstelle für BW-Modelle und -Daten verwendet werden. Das SAP-
HANA-Paket, in dem die externe SAP-HANA-View implementiert ist, kann in der Transaktion SPROfestgelegt werden. Zusätzlich zur SAP-HANA-View werden die entsprechenden BW-
Berechtigungen in die SAP-HANA-Berechtigungen repliziert und automatisch (über Rollen)
dem SAP-HANA-Datenbankbenutzer hinzugefügt, der dem BW-Benutzer entspricht.
Abhängigkeiten
Eine externe SAP-HANA-View kann für die folgenden Objekttypen generiert werden:
●CompositeProvider
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 244Librer?a= ERm https://libreriaerp.com/us [email protected] Librer?a= ERm https://libreriaerp.com/us [email protected]

253. ●Query
●Query als InfoProvider
●DataStore (klassisch und advanced)
●InfoCube
●InfoObject
SAP-HANA-Views aus dem BW-System heraus generieren
Beim Aktivieren der BW-Objekte, die Sie anlegen möchten, können Sie SAP-HANA-Views mit
identischen Strukturen generieren. Sie können so Szenarien anlegen, bei denen im BW-
System modellierte Daten mit Daten, die in SAP HANA mithilfe von SAP-HANA-Werkzeugen
modelliert wurden, zusammengeführt werden (gemischte Szenarien).
Folgende Objekte werden unterstützt:
●SAP-HANA-optimierte InfoCubes
●DataStore-Objekte
●InfoObjects
●Queries als InfoProvider
●CompositeProvider
●Lokale CompositeProvider im BW-Workspace und Queries
Beim Generieren von SAP-HANA-Views werden BW-Daten in SAP HANA publiziert. Die SAP-
HANA-Views zeigen direkt auf die Daten und Tabellen, die von BW verwaltet werden. BW-
Daten können daher direkt in SAP HANA konsumiert werden. Darüber hinaus wird so eine
übersichtliche Schnittstelle zwischen dem von BW verwalteten Schema und einem Bereich
außerhalb von BW, der von anderen Werkzeugen oder von einer anderen Benutzergruppe
verwaltet wird, bereitgestellt. Diese Schnittstelle zeigt deutlich an, wo die Services im BW-
System enden und wo die manuellen Erweiterungen oder die Erweiterungen durch
Drittanbieterwerkzeuge beginnen. Es ist nicht möglich, generierte SAP-HANA-Views manuell
zu ändern. Die von BW generierten SAP-HANA-Views können vom System jederzeit
überschrieben werden, wobei alle manuellen Änderungen verloren gehen würden.
Sie können jedoch weitere SAP-HANA-Views auf Basis dieser generierten Views anlegen.
Diese werden dann in einem anderen Content-Paket gespeichert.
Bei Generierung von SAP-HANA-Views aus dem BW-System heraus können Sie SAP-HANA-
Views generieren, ohne dazu den SAP HANA Modeler verwenden zu müssen. Sie können über
SQL-Frontends auf BW-Daten zugreifen. Alle Anwendungen, die SAP-HANA-Views lesen
können, können die Daten verarbeiten (z.B. SAP BusinessObjects Analysis, Edition für
Microsoft Office, SAP BusinessObjects Web Intelligence, SAP BusinessObjects Explorer, SAP
Lumira und BI-Clients von Drittanbietern).
Beim Ausführen einer Query auf der SAP-HANA-View werden die Daten direkt aus SAP HANA
angefordert, ohne dass das BW-System angesprochen wird.
Die Generierung von SAP-HANA-Views aus dem BW-System heraus wurde als Schnittstelle
für eigenständige Data Marts implementiert. Die SAP-HANA-Views sind nur für spezielle
Szenarien geeignet. Diese SAP-HANA-Views sind Teil des BW-InfoProvider-Lebenszyklus. Sie
werden mit den entsprechenden BW-Objekten transportiert. Das Zielsystem sollte über eine
SAP-HANA-Datenbank verfügen. Andernfalls geht die Eigenschaft, dass eine SAP-HANA-View
vorhanden ist, verloren.
Lektion: Erläutern von InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 245Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

254. Beim Aktivieren eines BW-Objekts mit der SAP-HANA-View werden alle abhängigen SAP-
HANA-Views ebenfalls aktiviert. Wenn im Zusammenhang mit einer von Ihnen angelegten
SAP-HANA-View ein Fehler auftritt, führt dies zu einer Warnung, und das BW-Objekt wird
aktiviert. Die Analyseberechtigungen in SAP HANA werden während der Aktivierung der BW-
Objekte erzeugt und mit den Analyseberechtigungen in BW abgeglichen.
Zum Verwalten von SAP-HANA-Views aus BW-Objekten heraus steht die Transaktion
RS2HANA_ADMIN zur Verfügung. Diese Transaktion bietet eine Übersicht über sämtliche
BW-Objekte mit einer externen SAP-HANA-View sowie verschiedene Verwaltungs- und
Prüffunktionen.
Abbildung 213: Virtuelle Stammdaten
Wenn Sie in einem VirtualProvider basierend auf einem SAP-HANA-Modell virtuelle
Navigationsattribute und Texte verwenden möchten, müssen Sie virtuelle Stammdaten
anlegen. Die Schritte sind unter „Anlegen virtueller Stammdaten“ beschrieben.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 246Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

255. Abbildung 214: XXL-Attribute (nicht HANA-spezifisch)
Auf der Registerkarte „XXL-Attribute“ können Sie die XXL-Attribute für das Merkmal
festlegen. Diese Registerkarte wird nur angezeigt, wenn Sie auf der Registerkarte
„Stammdaten/Texte“ das Kennzeichen „Unterstützt XXL-Attribute“ setzen.
XXL-Attribute sind XXL-InfoObjects, die dem Merkmal logisch zugeordnet werden. In XXL-
InfoObjects können Sie zusätzliche Informationen zu einem Merkmal als Datentyp STRING
oder XSTRING sichern. XSTRING ist ein vordefinierter Byte-artiger ABAP-Typ mit variabler
Länge. Dieser Typ stellt die dynamische Zuordnung von Speicher sicher.
Sie können den Typ der Daten durch einen MIME-Typ weiter spezifizieren. Es werden
zahlreiche Formate unterstützt, z.B. verschiedene Dokumentarten, Audio- oder Video-
Dateien, Texte und Bilder. Sie können die XXL-Attribute entweder auf der Registerkarte „XXL-
Attribute“ oder über die Transaktion RSD1 anlegen.
Anlegen virtueller Stammdaten
Sie möchten in einem VirtualProvider basierend auf einem SAP-HANA-Modell virtuelle
Navigationsattribute und Texte verwenden. Dazu müssen Sie virtuelle Stammdaten anlegen.
1.Wählen Sie in der Data Warehousing Workbench im BereichModellierungden Eintrag
InfoObjectsaus.
2.Wählen Sie im Kontextmenü Ihres InfoObjectCatalogs den EintragInfoObject anlegen.
Ordnen Sie einen Namen und eine Beschreibung zu, und wählen SieSichern. Das
Bearbeitungsbild für dasInfoObjectwird angezeigt.
3.Nehmen Sie die erforderlichen Einträge für Ihr InfoObject vor.
4.Wählen Sie auf der RegisterkarteStammdaten/Texteals Stammdatenzugriff SAP HANA
Attribute Viewaus.
Lektion: Erläutern von InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA
©Copyright. Alle Rechte vorbehalten. 247Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

256. 5.Geben Sie ein SAP-HANA-Paket und eine SAP HANA Attribute View an.
6.Wählen SieSAP-HANA-Verknüpfungen vorschlagen.
7.Markieren Sie die SAP-HANA-Attribute, zu denen Sie Vorschläge generieren möchten,
und wählen Sie „Übernehmen“. Es wird eine Vorschlagsliste angezeigt. Die Attribute des
SAP-HANA-Modells werden in Ordnern angezeigt. Die Vorschläge sind unter diesen
Ordnern aufgeführt. Zeigen Sie die Strategie zur Vorschlagserstellung an.
8.Wählen Sie jeweils einen passenden Vorschlag für Attribute, Texte und Klammerung (soweit vorhanden) aus. Wenn keines der vorgeschlagenen InfoObjects geeignet ist,
können Sie das Attribut zunächst unzugeordnet lassen und es später manuell zuordnen.
Wenn Sie Texte (TXTSH, TXTMD, TXTLG) ausgewählt haben, wird auf der Registerkarte
Stammdaten/Textedas entsprechende Kennzeichen für Texte gesetzt.
9.Zum manuellen Zuordnen von Attributen wählen SieHANA-Verknüpfungen pflegen .
10.Wählen Sie jeweils die passenden SAP-HANA-Attribute für Attribute, Texte und
Klammerung (soweit vorhanden) aus.
11.Sichern und aktivieren Sie das Merkmal.
Sie können das Merkmal nun mit virtuellen Stammdaten in Ihrem VirtualProvider verwenden.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●InfoObject-Erweiterungen für SAP Business Warehouse powered by SAP HANA erläutern
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 248Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

257. Kapitel 6
Lektion 3
Administrieren von DataStore-Objekten
(advanced)
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird das Administrieren von DataStore-Objekten (advanced) erläutert.
Darüber hinaus erfahren Sie, wie Sie die Requests eines DataStore-Objekts (advanced)
löschen und komprimieren.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●DataStore-Objekte (advanced) administrieren
Administrieren von DataStore-Objekten (advanced)
Über die Funktion „DataStore-Objekt administrieren“ können Sie technische Informationen
zum Inhalt eines DataStore-Objekts anzeigen. Sie können administrative Aufgaben wie das
Löschen von Requests ausführen. Voraussetzung dafür ist, dass das DataStore-Objekt aktiv
ist.
Abbildung 215: Administration – Request-Verwaltung für DSO (advanced)
1.In der Data Warehousing Workbench: Öffnen Sie das Kontextmenü Ihres Advanced
DataStore-Objekts, und navigieren Sie zuModellierung – InfoProvider →Administrieren.
©Copyright. Alle Rechte vorbehalten. 249Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

258. 2.Es werden alle Requests angezeigt, die in das DataStore-Objekt geladen wurden. Sie
können die Requests nach Tag, Monat oder Jahr gruppieren. Der Status wird kumuliert
angezeigt. Das DM-Kennzeichen zeigt an, ob die Deltas in weitere angeschlossene
InfoProvider fortgeschrieben wurden. Bei Full-Updates oder wenn kein InfoProvider
angeschlossen ist, wird kein Kennzeichen angezeigt. Die TSN
(Transaktionsfolgenummern) werden monoton aufsteigend angezeigt.
3.Wählen Sie den Request aus, um die Detailsicht aufzurufen. Hier können Sie Details zu
einzelnen Lade-Requests anzeigen. Sie können auch Protokolle anzeigen und den Monitor
aufrufen.
4.Sie können Lade-Requests aktivieren. Um mehrere Lade-Requests über einen einzelnen Aktivierungs-Request zu aktivieren, wählen SieAktivieren.
5.Sie können Lade-Requests löschen. Sie können mehrere Requests gleichzeitig löschen. Lade-Requests können nicht immer gelöscht werden. Per Doppelklick auf einen Request
können Sie die Details zum Request, ein Prozessprotokoll und eine Historie anzeigen.
6.Wählen Sie im HauptmenüUmfeld – Neue Daten anzeigen , um den Inhalt der
Eingangstabelle anzuzeigen. Wählen SieAktive Daten anzeigen, um den Inhalt der Tabelle
der aktiven Daten anzuzeigen. Wählen SieChange Log anzeigen, um den Inhalt des
Change Log anzuzeigen.
7.Wählen Sie im HauptmenüUmfeld – Aktive Daten löschen , um die Daten aus der aktiven
Tabelle zu löschen und sie bei Bedarf später wieder neu aufzubauen. Dasselbe gilt für die
Daten der Eingangstabelle und des Change Log.
DataStore-Objekt (advanced) – Administration
Abbildung 216: Administration – Alle Daten in DSO (advanced) löschen
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 250Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

259. Abbildung 217: Administration – Request aus DSO (advanced) löschen (Modellvorlage Standard-DSO)
Abbildung 218: Administration – Request von DSO (advanced) mit aktivem Delta-DTP an Ziel löschen
Lektion: Administrieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 251Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

260. Abbildung 219: Administration – Selektives Löschen
Abbildung 220: Administration – Change-Log-Daten für DSO (advanced) entfernen
Nach der Implementierung von SAP-Hinweis 2253065 ist das Programm
RSDSO_REMOVE_REQS_PC in Ihrem BW-on-HANA-System verfügbar. Dieses Programm ruft
intern den Funktionsbaustein M (RSDSO_REMOVE_REQUESTS_API) zum Löschen von
Change-Log-Requests im Batch auf.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 252Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

261. Abbildung 221: Administration – Datenaktivierung für DSO (advanced) (Modellvorlage InfoCube)
DSO-Aktivierung für Standard-DSO
Sie haben Daten in Ihr DSO geladen. Zu jedem Ladevorgang sind die folgenden beiden
Request-IDs vorhanden:
●Lade-Request (zum Zeitpunkt des Ladevorgangs angelegt)
●Aktivierungs-Request (zum Zeitpunkt der Aktivierung angelegt)
Wenn mehrere noch zu aktivierende DTP-Lade-Requests vorhanden sind und Sie nur genau
einen Request aktivieren möchten, können Sie anhand dieser Request-ID selektiv die
entsprechenden Datensätze aus der Tabelle mit den neuen Daten in der Tabelle mit den
aktiven Daten und der Change-Log-Tabelle verarbeiten.
Die DSO-Aktivierung ähnelt der DTP-Ladeverarbeitung, bei der die Tabelle mit den neuen
Daten als Quelle und die Tabelle mit den aktiven Daten sowie die Change-Log-Tabelle als Ziele
fungieren.
Wenn Sie in den DTP-EinstellungenDelta-Requests nacheinander abrufenauswählen, werden
die Delta-Requests aus der Quelle nacheinander verarbeitet, und es werden für jeden Lauf
separate Request-IDs angelegt.
SQL-Ansatz
In der folgenden Liste sind die grundlegenden SQL-Operationen aufgeführt, die beim
Aktivieren des ODS logisch im Backend ausgeführt werden.
●Insert
●Update
●Delete
Lektion: Administrieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 253Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

262. ●Select
●Truncate
Wenn Sie einen aktiven Request löschen, erfolgt ein Rollback. In der folgenden Liste sind die
einzelnen Operationen in Verbindung mit den verschiedenen Datensatzmodi aufgeführt:
●Auf der Tabelle „Aktive Daten“ werden SQL-Operationen wie Insert, Update, Delete und
Select ausgeführt.
●Auf der Change-Log-Tabelle wird nur die Insert-Operation ausgeführt.
●Auf der Tabelle „Neue Daten“ werden SQL-Operationen wie Insert, Select und Truncate
ausgeführt.
Tabelle „Aktive Daten“ und Change-Log-Tabelle vs. SQL
Wie bereits erwähnt werden bei der DSO-Aktivierung die Daten aus der Tabelle „Neue Daten“
in die Tabelle „Aktive Daten“ und die Change-Log-Tabelle übertragen.
Notiz:
Die Aktivierung eines DSO bezieht sich immer auf die Tabelle „Aktive Daten“ (bzw.
fragt diese ab), da es sich bei dem Change Log um einen temporären
Speicherbereich für Delta-Mechanismen handelt. Einige Vorgänge, z.B. das
selektive Löschen, werden nur auf einer Tabelle mit aktiven Daten ausgeführt. Die
Daten verbleiben zwar im Change Log, wenn Sie jedoch dieselben Daten erneut
laden, wird ein neuer Datensatz mit dem Datensatzmodus „N“ angelegt, und der
alte Datensatz, der bereits im Change Log vorhanden ist, wird nicht aktualisiert.
Dies weist darauf hin, dass sich die DSO-Aktivierung nur auf die Tabelle „Aktive
Daten“ bezieht. Um den Datensatzmodus für die Datensätze zu bestimmen, wird
zunächst eine Select-Abfrage auf der Tabelle „Aktive Daten“ ausgelöst, bevor die
Datensätze aus der Tabelle „Neue Daten“ verschoben werden. Je nach
Returncode der Select-Abfrage werden der Datensatzmodus für das Change Log
sowie der Typ der auf der Tabelle „Aktive Daten“ auszuführenden SQL-Operation
bestimmt.
Fall 1: Der Returncode ist NULL.
Für die (in der Tabelle „Neue Daten“ vorhandene) Datensatzkombination wurden in der
Tabelle „Aktive Daten“ keine Einträge gefunden. Sowohl auf der Tabelle „Aktive Daten“ als
auch auf der Change-Log-Tabelle wird eine Insert-Abfrage ausgelöst, und die Datensätze aus
der Tabelle „Neue Daten“ werden an die Tabelle „Aktive Daten“ sowie die Change-Log-Tabelle
(mit DatensatzmodusN) übergeben.
Fall 2: Der Returncode ist NICHT NULL (die Datensätze aus der Quelle wurden nicht storniert
oder gelöscht).
Für die (in der Tabelle „Neue Daten“ vorhandene) Datensatzkombination wurden in der
Tabelle „Aktive Daten“ Einträge gefunden. Die folgenden beiden Aktionen werden ausgeführt:
●Auf der Tabelle „Aktive Daten“ wird eine Update-Abfrage ausgelöst, um die modifizierten
Felder in der Tabelle „Aktive Daten“ zu aktualisieren.
●Auf der Change-Log-Tabelle wird eine Insert-Abfrage ausgelöst. Die bereits in der Tabelle
„Aktive Daten“ vorhandenen Datensätze werden mit dem Datensatzmodus „X“ eingefügt
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 254Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

263. (Kennzahlen werden mit Minus multipliziert). Die Datensätze aus der Tabelle „Neue Daten“
werden mit dem Datensatzmodus „ “ (leer) eingefügt.
Fall 3: Der Returncode ist NICHT NULL (für die Datensätze aus der Quelle ist das Storno- oder
Löschkennzeichen gesetzt).
Für die (in der Tabelle „Neue Daten“ vorhandene) Datensatzkombination wurden in der
Tabelle „Aktive Daten“ Einträge gefunden. Die folgenden beiden Aktionen werden ausgeführt:
●Auf der Tabelle „Aktive Daten“ wird eine Delete-Abfrage ausgelöst, um die Datensätze aus
der Tabelle „Aktive Daten“ zu löschen oder zu stornieren.
●Auf der Change-Log-Tabelle wird eine Insert-Abfrage ausgelöst. Die bereits in der Tabelle
„Aktive Daten“ vorhandenen Datensätze werden mit dem Datensatzmodus „X“ eingefügt
(Kennzahlen werden mit Minus multipliziert), und der aus der Tabelle „Neue Daten“
stammende Datensatz wird mit dem Datensatzmodus „D/R“ eingefügt.
Abbildung 222: Requests eines DSO (advanced) löschen oder komprimieren – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●DataStore-Objekte (advanced) administrieren
Lektion: Administrieren von DataStore-Objekten (advanced)
©Copyright. Alle Rechte vorbehalten. 255Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

264. Kapitel 6
Lektion 4
Einführung zu Prozessketten
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird die als „Prozesskette“ bezeichnete Reihe von Prozessen, die im
Hintergrund eingeplant auf einen Event warten, erläutert. Darüber hinaus erfahren Sie, wie Sie
eine einfache Prozesskette anlegen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●einfache Prozessketten anlegen
Anlegen einer Prozesskette
Abbildung 223: Typischer Datenladezyklus in BW 7.x (Nicht-HANA-System)
Eine Prozesskette ist eine Reihe von Prozessen, die im Hintergrund eingeplant auf einen Event
warten. Einige dieser Prozesse lösen einen separaten Event aus, der wiederum weitere
Prozesse starten kann.
In einem operativen BI-System gibt es eine Vielzahl von Abläufen, die regelmäßig
vorkommen. Im Folgenden ist aufgeführt, zu welchen Zwecken Sie Prozessketten verwenden
können:
Verwendung von Prozessketten
©Copyright. Alle Rechte vorbehalten. 256Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

265. ●Automatisierung der komplexen Abläufe in BW mithilfe der Event-gesteuerten
Verarbeitung
●Visualisierung der Prozesse mithilfe von Netzwerkgrafiken
●zentrale Steuerung und Überwachung der Prozesse
Im Folgenden sind die grundsätzlichen Prinzipien des Konzepts der Prozessketten aufgeführt:
●Offenheit. Die abstrakte Bedeutung von „Prozess“ als ein Ablauf mit definiertem Anfang
und Ende ermöglicht Off enheit hinsichtlich der Prozesstypen, die in eine Prozesskette
integriert werden können. Das Prinzip der Off enheit wird insofern auf das Konzept der
Prozessketten angewendet, als dass sowohl kundeneigene Programme als auch Prozesse
implementiert werden können. Zudem können Sie Prozessketten in andere Prozessketten,
sogenannte Metaketten, einbinden. Dadurch haben Sie die Möglichkeit, Prozessketten aus
dem System, in dem sich die Metakette befindet, oder Prozessketten aus anderen
Systemen zu integrieren. In diesem Zusammenhang wird von lokalen bzw. Remote-
Prozessketten gesprochen.
●Sicherheit. Die Verwendung von Prozessketten bietet eine hohe Prozesssicherheit, die auf
den folgenden Prinzipien der Hintergrundverwaltung basiert:
-Prozesse werden vor ihrem Lauf eingeplant und können mit dem Standard-
Hintergrundmonitor überwacht werden.
-Hintergrund-Events starten nachfolgende Prozesse.
-Kurzdumps und Abbrüche werden erkannt und entsprechend behandelt.
●Flexibilität. Der nachfolgende Prozess muss von seinen Vorgängern sämtliche
Informationen beschaff en, die er für einen korrekten Lauf benötigt. Dies ermöglicht die
Integration neuer Prozesstypen, ohne dass die vorhandenen Typen angepasst werden
müssen.
Integration.
Eine Prozesskette ist ein BI-Objekt mit Transportanschluss und Anschluss an die BI-
Dokumentenverwaltung.
Automatismen
Wenn Sie Prozessketten verwenden, werden die Automatismen der integrierten Prozesse
(z.B. PSA-Daten ins Datenziel fortschreiben oder Daten im DataStore-Objekt aktivieren)
ignoriert und müssen über die Prozesskette implementiert werden. Wenn Sie einen
bestimmten Prozess in einer Kette einplanen, unterstützen Sie durch die Berücksichtigung
solcher Automatismen das automatische Einfügen weiterer relevanter Standardprozesse.
Wenn Sie Datentransferprozesse verwenden, sind die Automatismen aus InfoPackages nicht
mehr verfügbar und müssen über Prozesstypen implementiert werden.
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 257Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

266. Abbildung 224: Event-gesteuerte Verarbeitung durch Prozesskette
Ein SAP-Event ist ein Kennzeichen, das über die TransaktionSM62zum Anzeigen und
Verwalten von Hintergrund-Events angelegt wird. Events dienen zum Auslösen von Jobs in
SAP und zum Verwalten der Abhängigkeiten zwischen mehreren Jobs ohne die Verwendung
von Prozessketten. Der Event selbst führt keine Aktionen aus. Es muss ein Hintergrundjob
zum Warten auf den Event definiert und konfiguriert werden. Sie legen daher über SM36einen
Hintergrundjob an und geben den Namen des neuen Events unter „Startbedingung“ ein. Ein
neuer Hintergrundjob kann immer als periodischer Job definiert werden. Dies ermöglicht
Ihnen, den Job nicht nur einmalig, sondern regelmäßig in der Zukunft auszulösen.
Abbildung 225: Prozessketten in der Data Warehousing Workbench
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 258Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

267. Abbildung 226: Netzwerkgrafik einer Prozesskette
Abbildung 227: Prozesskette: Startprozess, Anwendungsprozess und Sammelprozess
Startprozess – Definition
Mit dem Startprozess können Sie die Startbedingung einer Prozesskette definieren.
Startprozess – Verwendung
Zur direkten Einplanung des Startprozesses sind die Optionen für die Hintergrundsteuerung
verfügbar. Sie können die Prozesskette entweder sofort (bei Aktivierung der Prozesskette),
zu einem bestimmten Zeitpunkt oder nach einem bestimmten Event starten. Wenn Sie die
Prozesskette aktivieren, wird der Startprozess Ihren Selektionen entsprechend im
Hintergrund eingeplant.
Falls die vorhandenen Optionen nicht ausreichen, können Sie den Start der Prozesskette auch
über ein API auslösen. Sie können die Kette über das SAP-NetWeaver-Scheduling-Framework
starten, wo Ihnen umfassendere Einplanungsoptionen zur Verfügung stehen. Sie können den
Start einer Prozesskette auch über eine Metakette auslösen. Wenn die Prozesskette, zu der
Sie die Startbedingung festlegen, in eine andere Prozesskette eingebunden ist, wird dies als
„Metakette“ bezeichnet. Die Prozesskette wird direkt durch diese Metakette gestartet.
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 259Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

268. Notiz:
Wenn Sie den Startprozess über eine Metakette starten, wird er nicht eingeplant,
nachdem Sie die zugehörige Prozesskette aktiviert haben. Der Prozess wird erst
dann gestartet, wenn die Metakette, in die er eingebunden ist, läuft.
Alle anderen Prozesse in einer Kette werden als auf einen Event wartend eingeplant.
Der Startprozess weist folgende Merkmale auf:
●Nur die Startprozesse können ohne einen Vorgängerprozess eingeplant werden.
●Der Startprozess kann nicht Nachfolger eines anderen Prozesses sein.
●Für jede Prozesskette ist nur ein Startprozess zulässig.
●Ein Startprozess kann nur in einer einzigen Prozesskette verwendet werden.
Wenn Sie mehr als eine Startbedingung festlegen möchten, um eine Prozesskette oder einen
Teil einer Prozesskette auszuführen, verwenden Sie zusätzlich zum Startprozess den
Interrupt-Prozess.
Anwendungsprozess – Definition
Anwendungsprozesse sind Prozesse, die in der Prozesskettenpflege automatisiert werden
sollen. Sie stellen Aktivitäten dar, die normalerweise beim operativen Einsatz von BI
ausgeführt werden.
Tabelle 8: Von der Prozesskettenpflege unterstützte Anwendungsprozesse
Anwendungsprozesse sind Prozesse, die in der Prozesskettenpflege automatisiert werden
sollen. Sie stellen Aktivitäten dar, die normalerweise beim operativen Einsatz von BI ausgeführt werden.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 260Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

269. ProzesskategorieAnwendungsprozesstyp
Ladeprozess und Nach-
verarbeitung
●InfoPackage ausführen. Weitere Informationen finden Sie un-
ter „InfoPackages in Prozessketten einbinden“.
Achtung:
Wenn Sie Prozessketten verwenden, werden die
Automatismen der integrierten Prozesse ignoriert
und müssen über die Prozesskette implementiert
werden. Beispiel: Sie wählen im InfoPackage auf
der Registerkarte „Fortschreibung“ die Fortschrei-
bungsarten „Nur PSA“ und „Anschließend in Da-
tenziele“ aus. Sie verwenden dieses InfoPackage
in einer Prozesskette. Die Weiterverbuchung ins
Datenziel erfolgt nicht automatisch. Sie wird nach
dem Ladeprozess ausgeführt, wenn in der Pro-
zesskette der Prozess „PSA lesen und an Daten-
ziel fortschreiben“ eingeplant ist.
●PSA lesen und Datenziel verbuchen. Hierarchie sichern. Sie-
he „Hierarchie über eine Prozesskette laden“→Schritt 7.
●DataStore-Objektdaten fortschreiben (Weiterverbuchung).
Daten in Fremdsysteme exportieren. Siehe „InfoSpoke in
Prozesskette einbinden“ und „InfoSpoke anlegen“.
●Überlappende Requests aus einem InfoCube löschen. Event
Datenänderung auslösen (für Broadcaster). Siehe auch
„Event Datenänderung in Prozesskette einbinden“.
Datenziel-Administration
●Index löschen. Siehe „InfoCube-Performance“→Abschnitt
„Indizes löschen“ und „InfoCube in Prozesskette einbinden“.
●Index aufbauen. Siehe „InfoCube in Prozesskette einbinden“.
●Datenbankstatistik aufbauen. Siehe „InfoCube-Performance“
→Abschnitt „Datenbank-Statistiken“.
●Neue Aggregate füllen.
●Rollup gefüllter Aggregate.
●Komprimieren des InfoCubes.
●ODS-Objektdaten aktivieren. Datenzielinhalte in Full-Modus
löschen.
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 261Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

270. ProzesskategorieAnwendungsprozesstyp
Reporting Agent
●Exception Reporting.
●Drucken im Hintergrund.
●Vorberechnung von Web Templates.
●Vorberechnung von Wertemengen. Weitere Informationen
finden Sie unter „Paket in Prozesskette einbinden“ in der Do-
kumentation zum Reporting Agent.
Andere BI-Prozesse
●Verhalten bei Stammdaten- und Hierarchieänderungen. Zeit-
abhängige Aggregate anpassen. Weitere Informationen fin-
den Sie unter „Aggregat manuell bearbeiten“→Schritt 8.
●Requests aus der PSA löschen.
●Stammdatenattribute und -texte neu organisieren.
Allgemeine Services
●ABAP-Programm
●Betriebssystembefehl
●Prozesskette lokal
●Prozesskette remote
●Workflow (auch remote)
Implementierung eines eigenen Prozesstyps
Sammelprozess – Definition
Ein Sammelprozess fasst in der Prozesskettenpflege mehrere Kettenstränge zu einem
einzigen Strang zusammen.
Sammelprozess – Verwendung
Sammelprozesse werden durch die Prozesskettenverwaltung besonders behandelt. Das
System legt konsistente Variantennamen fest, und es stellt sicher, dass mehrfach eingeplante
Prozesse gleichen Namens alle denselben Event auslösen. Dies ermöglicht das
Zusammenfassen mehrerer Kettenstränge zu einem einzigen Strang und macht eine
Mehrfacheinplanung der eigentlichen Anwendungsprozesse unnötig.
Die folgenden Sammelprozesse sind in der Prozesskettenpflege verfügbar:
●Und-Prozess (Letzter)
Dieser Prozess startet erst, wenn alle Events der vorangehenden Prozesse, d.h.
einschließlich des letzten Events, auf das dieser Prozess gewartet hat, erfolgreich
ausgelöst wurden. Dieser Sammelprozess wird verwendet, um Prozesse zu kombinieren,
und wenn die weitere Verarbeitung von allen vorangehenden Prozessen abhängig ist.
●Oder-Prozess (Jeder)
Der Anwendungsprozess startet nach jedem erfolgreichen Auslösen eines
Vorgängerprozesses. Dieser Sammelprozess wird verwendet, um die mehrfache
Einplanung des eigentlichen Anwendungsprozesses zu vermeiden.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 262Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

271. ●Exor-Prozess (Erster)
Der Anwendungsprozess startet, wenn der erste Event aus einem der Vorgängerprozesse
erfolgreich ausgelöst wurde. Dieser Sammelprozess wird verwendet, um Prozesse parallel
zu verarbeiten und im Anschluss daran weitere unabhängige Prozesse einzuplanen.
Abbildung 228: Von SAP ausgelieferte Prozesse
Abbildung 229: Struktur eines Prozesses (Design-Zeit, Laufzeit) mit Beispiel für
Datentransferprozessausführung
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 263Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

272. Ein Prozess im Kontext von Prozessketten ist ein Vorgang innerhalb oder außerhalb eines
SAP-Systems mit definiertem Anfang und Ende. Es wird zwischen einem Startprozess, einem
Anwendungsprozess und einem Sammelprozess unterschieden.
Um die Abläufe in BW zu automatisieren, werden Prozesse in Prozessketten
zusammengeführt. Die Prozesse werden im Hintergrund eingeplant. Jeder der Prozesse kann
einen oder mehrere Events auslösen, die wiederum andere Prozesse anstoßen.
Ein Prozess weist folgende Merkmale auf:
●den Prozesstyp
Der Typ des Prozesses, z.B. ein Ladeprozess. Der Prozesstyp bestimmt, welche Aufgaben
der Prozess hat und welche Eigenschaften des Prozesses gepflegt werden können. Der
Prozesstyp wird im View RSPROCESSTYPES festgelegt. Weitere Informationen finden Sie
unter „Pflege der Prozesstypen“.
●die Prozessvariante
Die Prozessvariante ist die Bezeichnung des Prozesses. Sie stellt im Kontext der
Prozessketten die zur Definitionszeit festgelegte Konfiguration eines Prozesses eines
bestimmten Typs dar. Eine Variante ist nur im Zusammenhang mit dem Prozesstyp
eindeutig definiert. Ein Prozess kann mehrere Varianten haben. Während des
Ladeprozesses stellt beispielsweise ein InfoPackage eine Prozessvariante dar. Der
Benutzer definiert die Prozessvariante bei der Einplanung des Prozesses. Bei bestimmten
Prozesstypen werden die Varianten intern bestimmt und als GUIDs abgelegt.
●die Prozessinstanz
Die Prozessinstanz ist die Ausprägung des Prozesses. Sie enthält die wichtigsten
Informationen, die in dem Prozess oder in nachfolgenden Prozessen mitgeteilt werden
sollen. Im Ladeprozess ist dies beispielsweise der Name des Requests. Nach Ende des
Prozesses wird die Instanz in das Prozesskettenmanagement übertragen und gesichert.
Die Protokolle für den Prozess werden unter der Prozessinstanz abgelegt. Die Instanz wird
vom Prozess selbst zur Laufzeit ermittelt und in der Regel systemübergreifend und
zeitunabhängig eindeutig festgelegt.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 264Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

273. Abbildung 230: Pflege von Prozessketten – Transaktion RSPC
Arbeitsumgebung für die
Überwachung von Prozess-
ketten
UmgebungsszenarioWeitere Informationen
Überwachung periodischer
Prozessketten (Transaktion
RSPCM)
Mit der TransaktionRSPCM
überwachen Sie den jeweils
letzten Lauf ausgewählter
Prozessketten in einem BW-
System. Rufen Sie diese
Transaktion regelmäßig auf,
um den Status der aktuellen
Läufe für ausgewählte Pro-
zessketten zu prüfen. Sie
können von hier aus die de-
taillierte Protokollsicht für ei-
nen Prozesskettenlauf aufru-
fen.
Aktuelle Läufe von periodi-
schen Prozessketten überwa-
chen
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 265Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

274. Arbeitsumgebung für die
Überwachung von Prozess-
ketten
UmgebungsszenarioWeitere Informationen
App zur Prozesskettenüber-
wachung
Mit der App zur Prozessket-
tenüberwachung können Sie
den jeweils letzten Lauf aus-
gewählter Prozessketten in
einem BW-System überwa-
chen. Auf Ihrem mobilen End-
gerät können Sie die App zur
Prozesskettenüberwachung
verwenden, um den Status
von Prozessketten zu über-
prüfen, Fehler zu analysieren
und fehlgeschlagene Prozes-
se zu wiederholen oder um E-
Mails zu Fehlern zu versen-
den.
App zur Prozesskettenüber-
wachung
Protokollsicht für Läufe einer
Prozesskette in der Prozess-
kettenpflege (Transaktion
RSPC)
Über die Prozesskettenpflege
(TransaktionRSPC) oder die
Prozesskettenpflege für eine
bestimmte Prozesskette
(TransaktionRSPC1) gelan-
gen Sie zur Protokollsicht der
Prozesskettenpflege. Hier
überprüfen Sie die Protokollefür Prozesskettenläufe. Mit
dieser Transaktion können
Sie einen oder mehrere Läufe
für eine Prozesskette in der
Protokollsicht anzeigen.
Anzeige der Protokolle zur
Prozesskette
Prozesskettenpflege für ei-
nen bestimmten Prozessket-tenlauf (TransaktionRSPC1)
Mit dieser Transaktion rufen
Sie die Protokollsicht für die-
sen Lauf auf, indem Sie die
Protokoll-ID eines bestimm-
ten Prozesskettenlaufs ange-
ben.
BW-Monitor im Computing
Center Management System
(CCMS)
Der Alert-Monitor desCCMS
zeigt für Prozessketten die
Läufe eines bestimmten Zeit-
raums mit den zugehörigen
Statusinformationen an. Mit
dem BW-Monitor imCCMS
können Sie Ihre Systemland-
schaft zentral und global
überwachen und externe Mo-
nitoring-Werkzeuge anwen-
den.
BW-Monitor inCCMS
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 266Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

275. Arbeitsumgebung für die
Überwachung von Prozess-
ketten
UmgebungsszenarioWeitere Informationen
Technischer Content Der technische Content stellt
Objekte zur Auswertung von
Prozesskettenstatus bereit.
Verwenden Sie den techni-
schen Content, um Berichte
über die Status der Prozess-
ketten zu erstellen (z.B. im
Rahmen eines Dienstleis-
tungsvertrags als Administra-
tor) oder um für die globale
Überwachung Ihrer System-
landschaft eigendefinierte
Dashboards zu verwenden.
Technischer Content im BWAdministration Cockpit
Abbildung 231: Pflege von Prozessketten – Objektbäume
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 267Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

276. Abbildung 232: Startprozessvariante – Einplanungsoption
Mithilfe eines Startprozesses können Sie die Startbedingung einer Prozesskette definieren.
Zur direkten Einplanung des Startprozesses sind die Optionen für die Hintergrundsteuerung
verfügbar. Sie können die Prozesskette entweder sofort (bei Aktivierung der Prozesskette),
zu einem bestimmten Zeitpunkt oder nach einem bestimmten Event starten. Wenn Sie die
Prozesskette aktivieren, wird der Startprozess Ihren Selektionen entsprechend im
Hintergrund eingeplant.
Falls die vorhandenen Optionen nicht ausreichen, können Sie den Start der Prozesskette auch
über ein API auslösen. Verwenden Sie dabei den Funktionsbaustein
RSPC_API_CHAIN_START. Zum Starten der Kette über das API können Sie das SAP-
Scheduling-Framework verwenden, wo Ihnen umfassendere Einplanungsoptionen zur
Verfügung stehen. Sie können den Start einer Prozesskette auch über eine Metakette
auslösen. Wenn die Prozesskette, zu der Sie diese Startbedingung festlegen, in eine andere
Prozesskette eingebunden ist, wird dies als „Metakette“ bezeichnet. Die Prozesskette wird
direkt durch diese Metakette gestartet.
Alle anderen Prozesse in einer Kette werden als auf einen Event wartend eingeplant.
Für einen Startprozess gelten folgende Besonderheiten:
●Nur die Startprozesse können ohne einen Vorgängerprozess eingeplant werden.
●Der Startprozess kann nicht Nachfolger eines anderen Prozesses sein.
●Für jede Prozesskette ist nur ein Startprozess zulässig.
●Ein Startprozess kann nur in einer einzigen Prozesskette verwendet werden.
Wenn Sie mehr als eine Startbedingung festlegen möchten, um eine Prozesskette oder einen
Teil einer Prozesskette auszuführen, verwenden Sie den Interrupt-Prozess und den
Startprozess.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 268Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

277. Abbildung 233: Beispiel für die Pflege von Prozessvarianten
Abbildung 234: Statusabhängige Prozessfolge in Prozessketten
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 269Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

278. Abbildung 235: Konsistenzprüfung von Prozessketten – Prüfsicht
Um Ihre Prozesskette zu prüfen, wechseln Sie in die Prüfsicht und nehmen gegebenenfalls
erforderliche Korrekturen vor. In der Legende ist die Bedeutung der verschiedenen Farben
erläutert, die bei der Anzeige der Prozesse und Verknüpfungen verwendet werden. Über das
Kontextmenü zu einem Prozess können Sie die als Ergebnis der Prüfung ausgegebenen
Meldungen anzeigen.
Bei der Prüfung berechnet das System die Anzahl paralleler Prozesse dem Aufbau der Kette
entsprechend (Unterketten werden hierbei rekursiv berücksichtigt). Das Ergebnis wird mit
der Anzahl der Hintergrundprozesse auf dem gewählten Server verglichen (oder der
Gesamtzahl der verfügbaren Server, wenn in den Attributen der Prozesskette kein Server
angegeben ist). Wenn die Anzahl der parallelen Prozesse größer als die Anzahl der
verfügbaren Hintergrundprozesse ist, kennzeichnet das System alle Ebenen der
Prozesskette, auf denen die Anzahl der Prozesse zu groß ist. Das System gibt für diese
Ebenen eine Warnung aus.
Abbildung 236: Prozessketten-Protokollsicht
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 270Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

279. Anzeige der Protokolle zur Prozesskette
In der Protokollsicht der Prozesskettenpflege können Sie die Prozesskettenläufe überprüfen.
Aufrufen der Protokollsicht für einen Prozesskettenlauf
Die Protokollsicht einer Prozesskette rufen Sie entweder über die DrucktasteProtokollsichtin
der Symbolleiste der Prozesskettenpflege oder über das Symbol Protokollein der
Symbolleiste des Navigationsbereichs auf. Wenn Sie in die Protokollsicht wechseln, wählen
Sie zunächst den Zeitraum aus, für den Sie die Prozesskettenläufe anzeigen möchten. Im
linken Bildbereich werden Informationen zum Zeitpunkt von Erstellung, Änderung oder
Aktivierung sowie Informationen zu den Läufen angezeigt. Symbole geben den Status der
Läufe an. Ein gelbes Symbol gibt an, dass die Kette aktiv ist, ein grünes Symbol steht für den
erfolgreichen Abschluss der Kette, ein rotes Symbol gibt an, dass die Kette mit Fehlern
abgeschlossen oder abgebrochen wurde. „Unbekannt“ wird angezeigt, wenn der Status nicht
bekannt ist, beispielsweise nach einem Upgrade. Wählen SieSpringen→Anderes Protokoll(in
der Symbolleiste der Prozesskettenpflege), um die Statusanzeige der Läufe zu aktualisieren.
Wählen Sie per Doppelklick auf die entsprechende Zeile die Protokollsicht für einen Lauf aus.
Die Protokollsicht zu einem ausgewählten Lauf können Sie über das Menü „Ansicht“
auffrischen. Über die Legende erhalten Sie Informationen zum Status der Prozesse und
Verknüpfungen.
Notiz:
Je nachdem, ob die Kette seit dem letzten Lauf verändert wurde oder nicht,
können Sie in der Protokollsicht zu einer Prozesskette die Prozesse anzeigen, die
noch nicht ausgeführt wurden. Wenn die Kette seit dem zu überprüfenden Lauf
nicht verändert wurde, werden in der Protokollsicht zu diesem Lauf die noch nicht
ausgeführten Prozesse grau angezeigt. Darüber hinaus wird die Verknüpfung zu
solchen Prozessen gestrichelt angezeigt, wenn der Event noch nicht ausgelöst
wurde. Wenn die Kette seit dem zu überprüfenden Lauf jedoch verändert wurde,
werden die noch nicht ausgeführten Prozesse und die noch nicht ausgelösten
Events in der Protokollsicht zu diesem Lauf nicht angezeigt.
Zusammenführen mit aktiver Version
Wenn die Kette seit dem zu überprüfenden Lauf verändert wurde, können Sie die noch nicht
ausgeführten Prozesse überAnsicht→Aktive Versiongrau anzeigen. Dies ist hilfreich, wenn
die Kette nach einem Fehler fortgesetzt werden soll, selbst wenn sie seitdem neu aktiviert
oder eingeplant wurde.
Meldungen zu einem Prozess anzeigen
Über „Meldungen anzeigen“ im Kontextmenü zu einem Prozess rufen Sie das Protokoll auf.
Die Protokolle werden in einem Dialogfenster auf den Registerkarten „Kette“, „Batch“ und
„Prozess“ angezeigt:
●Die Registerkarte „Kette“ enthält Informationen zu Start und Ende des Prozesses sowie
zur erzeugten Instanz.
●Auf der Registerkarte „Batch“ werden die Protokolle für den Job, in dem der Prozess
ausgeführt wurde, in der SAP List Viewer Grid Control angezeigt. Über die Drucktaste
„Batch-Monitor“ rufen Sie die Jobübersicht zu Ihrem Job auf.
●Die Registerkarte „Prozess“ enthält die prozessbasierten Meldungen. Diese Registerkarte
wird angezeigt, wenn der Prozesstyp ein eigenes Protokoll schreibt oder wenn für den
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 271Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

280. Prozesstyp das Interface IF_RSPC_GET_LOG oder IF_RSPC_CALL_MONITOR
implementiert ist. Bei Prozessen, für die ein spezieller Monitor angebunden ist (z.B. beim
Laden von Daten über InfoPackages oder bei Datentransferprozessen), können Sie über
„Prozess-Monitor“ zu diesem Monitor wechseln.
Notiz:
Wenn Sie für den Datentransferprozess (DTP) in der DTP-Pflege das Kennzeichen
Alle neuen Daten Request-weise aus der Quelle abholengesetzt haben, wird nach
der Verarbeitung des DTP-Requests geprüft, ob in der Quelle noch weitere
Requests vorhanden sind. In diesem Fall wird ein weiterer DTP-Request erzeugt
und verarbeitet. Im Protokoll zu einem Prozesskettenlauf, der einen solchen DTP
enthält, wird über den Prozessmonitor eine Liste der DTP-Requests angezeigt, die
innerhalb des Prozesskettenlaufs alle Quell-Requests abgerufen haben. DTPs, die
vor SAP NetWeaver 7.0 SPS12 angelegt wurden, weisen ein anderes Verhalten
auf. Wenn Sie das Kennzeichen setzen, wird der erste Request der Quelle mit nur
einem DTP-Request abgerufen. In diesem Fall zeigt der Prozessmonitor nur
diesen einen DTP-Request an.
Protokolle zu einem Prozesskettenlauf löschen
Wenn Sie die Protokolle zu einer Prozesskette und den zugeordneten Prozessen löschen
möchten, wählen SieProtokoll→Löschen. Auf dem nächsten Bild wählen Sie das aktuell
angezeigte Protokoll aus. Sie können auch den Zeitraum angeben, für den Sie das Protokoll
löschen möchten. Wählen SieAusführen. Es werden alle Hintergrundjobs sowie die Kopf- und
Detailprotokolle des Prozessketten-Frameworks gelöscht. Wenn Sie das KennzeichenFehler
ignorierensetzen, fährt das System bei Auftreten eines Fehlers mit dem Löschvorgang fort.
Wenn Sie das Kennzeichen nicht setzen, wird der Löschvorgang abgebrochen. Nach
Abschluss des Löschvorgangs erhalten Sie eine Liste der gelöschten Protokolle. Der
gelöschte Lauf wird in der Protokollsicht nicht mehr angezeigt und kann auch nicht
wiederhergestellt werden.
Protokoll zur Prozesskette neu auswählen
ÜberSpringen→Anderes Protokoll(in der Symbolleiste der Prozesskettenpflege) können Sie
das Protokoll zu dieser Prozesskette neu auswählen. Die Übersicht über die
Prozesskettenläufe wird entsprechend Ihrer Zeitauswahl aktualisiert. Die Status der Läufe
werden ebenfalls aufgefrischt.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 272Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

281. Abbildung 237: Überwachung von Prozesskettenläufen – Fehleranalyse
Abbildung 238: Überwachung von Prozesskettenläufen – Prozesse reparieren/wiederholen
Sie können jeden abgebrochenen Kettenprozess (jede Instanz) neu starten, wodurch
wiederum der Lauf der Kette beendet wird. Der Prozess kann entweder automatisch oder
manuell wiederholt werden.
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 273Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

282. Je nach Prozesstyp können Sie einen Prozess wie folgt starten:
●Ein Prozess kann repariert werden, und die abgebrochene Instanz wird anschließend
erneut ausgeführt. Auf diese Weise können Sie Prozesse neu starten, die nicht mit einer
neuen Instanz wiederholt werden könnten, da die zu bearbeitenden Daten mit der Instanz
verbunden sind (beispielsweise bei einem Datentransferprozess). Ein
Datentransferprozess kann beispielsweise nicht mit einer neuen Request-Nummer
wiederholt werden, da die Daten selbst an den Request gekoppelt sind.
●Ein Prozess kann wiederholt werden. In diesem Fall wird eine neue Instanz erzeugt.
Der Neustart eines Prozesses in einem Prozesslauf kann entweder manuell über die
Protokollsicht (Bild „Prozesskettenpflege“) gesteuert werden oder mithilfe der Optionen in
der Plansicht (Bild „Prozesskettenpflege“) automatisiert werden.
Voraussetzungen
Sie können einen abgebrochenen Prozess erneut starten, wenn dies für den entsprechenden
Prozesstyp möglich ist. In der Plansicht der Prozesskettenpflege können Sie festlegen, ob ein
Prozess repariert oder wiederholt werden kann, nachdem er abgebrochen wurde. Wählen Sie
dazuEinstellungen→Prozesstypen pflegen (in der Tabelle RSPROCESSTYPES).
Achtung:
Ändern Sie nicht die Einstellungen für die SAP-Prozesstypen. Dies könnte zu
Inkonsistenzen in den durch den Prozess verarbeiteten Daten führen.
Abgebrochene Prozesse manuell wiederholen oder reparieren
Wählen Sie in der Protokollsicht der betreffenden Prozesskette über das Kontextmenü zum
abgebrochenen ProzessWiederholenoderReparieren.
Notiz:
Wenn ein Prozess nach dem Abbruch nicht repariert oder wiederholt werden
kann, fehlt der entsprechende Eintrag im Kontextmenü in der Protokollsicht der
Prozesskettenpflege. In diesem Fall können Sie die nachfolgenden Prozesse
starten. Sie finden einen entsprechenden Eintrag im Kontextmenü dieser
Folgeprozesse.
Abgebrochene Prozesse automatisch wiederholen oder reparieren
1.Wählen Sie in der Plansicht der Prozesskette über das Kontextmenü zu den Prozessen, für
die Sie die Automatisierung einstellen möchten, die OptionAutomatische Wiederholung.
2.Geben Sie im Dialogfenster die folgenden Informationen ein, und wählen SieWeiter:
●Geben Sie im FeldSekundenan, wie lange das System mindestens warten soll, bis es
den abgebrochenen Prozess wiederholt oder repariert.
●Geben Sie im FeldAnzahl der Wiederholungenan, wie oft der Prozess wiederholt oder
repariert werden soll.
3.Sichern und aktivieren Sie Ihre Prozesskette.
4.Bei künftigen Prozesskettenläufen werden die abgebrochenen Prozesse den
vorgenommenen Einstellungen entsprechend wiederholt.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 274Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

283. Abbildung 239: Neuer Prozesskettenmonitor in SAP BW 7.4 SP8
Mit der Prozessketten-App können Sie als BW-Administrator jederzeit und überall die letzten
Läufe von Prozessketten überwachen.
Die App greift auf die Funktion zur Überwachung periodischer Prozessketten (Transaktion
RSPCM) eines BW-Systems zu. Sie ermöglicht Ihnen, in der TransaktionRSPCMausgewählte
Prozessketten über ein intuitives Web-Interface zu überwachen, ohne sich dazu an einem
BW-System (SAP GUI) anmelden zu müssen. Sie können auf einfache Weise fehlgeschlagene
und verzögerte Prozessketten identifizieren, Fehleranalysen durchführen, E-Mails mit
Fehlerinformationen versenden und Prozesse reparieren.
Die App zur Prozesskettenüberwachung ist ein Web-basierter Monitor, der auf SAPUI5
basiert. Nachdem Sie die Konfigurationsschritte ausgeführt haben, können Sie die App in
einem Web-Browser auf Ihrem Endgerät (Desktop-PC, Tablet oder Smartphone) starten. Die
Verbindung zwischen dem BW-Backend und der App wird über Gateway hergestellt. Die
Verbindung basiert auf dem OData-Protokoll. Die Funktionen und die Daten zur
Prozesskettenüberwachung werden über einen OData-Service bereitgestellt.
http|https://<Host des BW-Systems>:<http-Port|https-Port>/rspcm_web
Beispiel: https://vmw9460.wdf.sap.corp:50000/rspcm_web
Notiz:
Sie können der Adresse die folgenden Werte hinzufügen, um die App mit
bestimmten Parametern zu starten: ?<Parameter 1>=<Wert>&<Parameter
2>=<Wert>.
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 275Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

284. Wenn Sie die App in einer bestimmten Sprache und für einen bestimmten Mandanten des
BW-Systems starten möchten, lautet der Aufbau der Adresse wie folgt:
http|https://<Host des BW-Systems>:<http-Port|https-Port>/rspcm_web?sap-
client=<Mandant des BW-Systems>&sap-language=<Sprachschlüssel des BW-Systems>.
Beispiel: https://vmw9460.wdf.sap.corp:50000/rspcm_web?sap-client=000&sap-
language=EN
Aus dem BW-System (SAP GUI) heraus starten Sie die App wie folgt:
●Data Warehousing Workbench (TransaktionRSA1)
Administration→Monitore→Prozessketten-App.
●TransaktionRSPCM_WEB.
Im Folgenden sind die grundlegenden Funktionen des Prozesskettenmonitors aufgeführt:
●Anzeige von Listen der letzten Läufe periodischer Prozessketten, unterteilt in
fehlgeschlagene, verzögerte, aktive und alle Prozessketten
●Navigation innerhalb der Liste der Prozesse einer Prozesskette. Der aktuelle
Prozessstatus (erfolgreich ausgeführt, fehlgeschlagen und nicht ausgeführt) wird über
entsprechende Symbole angezeigt.
●Filtern der Prozesse einer Kette nach Status
●Anzeige der Fehlerprotokolle für alle fehlgeschlagenen Prozesse innerhalb einer Kette
●Reparieren einer Prozesskette durch Aufruf der entsprechenden Funktion
●Anzeige der Protokolle für einen Prozess einer Kette mit der Möglichkeit, bei Bedarf
zwischen Job-Protokoll und Prozessprotokoll zu wechseln
●Reparieren eines Prozesses oder einer Unterkette durch Aufruf der entsprechenden
Funktion
●Überspringen eines Prozesses oder einer Unterkette durch Aufruf der entsprechenden
Funktion
●Versenden einer E-Mail mit Informationen zum ausgewählten Prozess durch Aufruf der
entsprechenden Funktion
●
endgerätespezifische Konfiguration der Listanzeige (über Auswahl der gewünschten
Spalten)
Technische Voraussetzungen
●Die für die Nutzung der App relevanten Softwarekomponenten sind in Ihrer SAP-
NetWeaver-7.4-Installation enthalten:
-SAP Business Warehouse (Support Package Stack 8 oder höher)
-Gateway
-SAPUI5
●Die Benutzer der App haben von ihrem Gerät aus Zugang zu den Daten im BW-Backend-
System.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 276Librer?a= ERm https://libreriaerp.com/us [email protected] Librer?a= ERm https://libreriaerp.com/us [email protected]

285. HANA-optimierte Prozessketten
Abbildung 240: Prozesskette – Vergleich klassisch vs. HANA-optiert
Obsolete Prozesstypen beim Einsatz der SAP-HANA-Datenbank
Die folgenden Prozesstypen werden beim Einsatz der SAP-HANA-Datenbank nicht benötigt:
●Initiales Füllen neuer Aggregate
●Explorer-Eigenschaften von BW-Objekten aktualisieren
●Hochrollen gefüllter Aggregate/ BWA-Indizes
●Zeitabhängige Aggregate anpassen
●Datenbankstatistik aufbauen
●Index aufbauen
●Index löschen
Wenn Sie die SAP-HANA-Datenbank einsetzen, können diese Prozesstypen in der
Prozesskettenpflege nicht mehr ausgewählt werden. Bestehende Prozessketten müssen
nicht modifiziert werden. Die entsprechenden Prozessvarianten führen in den Ketten keine
Aufgaben aus und werden nicht mit Fehlern beendet.
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 277Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

286. Abbildung 241: Prozesskette – Vergleich klassisch vs. HANA-optiert 2
Abbildung 242: Prozesskette – Vergleich klassisch vs. HANA-optiert 3
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 278Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

287. Abbildung 243: Obsolete Prozesstypen bei Einsatz von SAP HANA
Im Folgenden sind die bei Einsatz von SAP HANA obsoleten Prozesstypen aufgeführt:
●Initiales Füllen neuer Aggregate
●Rollup gefüllter Aggregate
●Zeitabhängige Aggregate anpassen
●Explorer-Eigenschaften von BW-Objekten aktualisieren
●Datenbankstatistik aufbauen
●Index aufbauen
●Index löschen
●BW-Accelerator-Indizes auffrischen
Lektion: Einführung zu Prozessketten
©Copyright. Alle Rechte vorbehalten. 279Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

288. Abbildung 244: Einfache Prozessketten anlegen – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●einfache Prozessketten anlegen
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 280Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

289. Kapitel 6
Lektion 5
Erläutern von SAP-HANA-Delta-Merges in SAP
Business Warehouse (SAP BW)
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion werden der SAP-Delta-Merge und seine Vorteile erläutert. Darüber hinaus
erfahren Sie, wie Sie einen Delta-Merge in SAP BW durchführen.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●SAP-HANA-Delta-Merges in SAP BW erläutern
SAP-HANA-Delta-Merge in SAP BW
Abbildung 245: SAP HANA – Einfügen nur in Delta
Der Spaltenspeicher nutzt effiziente Komprimierungsalgorithmen, die alle relevanten
Anwendungsdaten im Speicher ablegen. Schreiboperationen mit diesen komprimierten Daten
sind teuer, da sie eine Reorganisation der Speicherstruktur erfordern. Das Aktualisieren und
Einfügen von Daten in eine sortierte Spaltenspeicher-Tabelle ist sehr kostspielig, da die
Sortierreihenfolge neu erzeugt werden muss und jedes Mal die gesamte Tabelle reorganisiert
©Copyright. Alle Rechte vorbehalten. 281Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

290. wird. SAP hat diese Tabellen daher auf einen Main-Speicher (leseoptimierte, sortierte
Spalten) und mehrere Deltaspeicher (schreiboptimierte, nicht sortierte Spalten oder Zeilen)
aufgeteilt. Alle Änderungen werden in einem separaten Bereich, dem Deltaspeicher, abgelegt.
Der Deltaspeicher existiert nur im Hauptspeicher. Beim Einfügen von Delta-Einträgen werden
nur Delta-Log-Einträge in die Persistenzschicht geschrieben. Eine regelmäßig ausgeführte
Datenbankaktivität führt den Deltaspeicher mit dem Main-Speicher zusammen. Diese
Aktivität wird als Delta-Merge bezeichnet. In der Abbildung „SAP HANA – Einfügen nur in
Delta“ sehen Sie die verschiedenen Stufen der Datenspeicherung. Hier wird zwischen Main- Speicher und Deltaspeicher unterschieden.
Abbildung 246: Delta-Merge-Phasen
Wenn Sie eine SAP-HANA-Datenbank einsetzen, werden Datenänderungen zunächst in einem
für den Schreibzugriff optimierten Deltaspeicher abgelegt. Anschließend werden die
Änderungen über einen Delta-Merge in den Main-Speicher übertragen. Datenänderungen
zunächst in einem für den Schreibzugriff optimierten Deltaspeicher in der Datenbank
abgelegt. Der größte Teil der Daten wird jedoch in einem stark komprimierten Format im
Main-Speicher abgelegt, der im Hinblick auf Speicherplatz und Leseperformance optimiert
ist. Ein Delta-Merge dient zum Übertragen von Änderungen aus dem Deltaspeicher in den
Main-Speicher. Zunächst wird über eine asynchrone Prüfung ermittelt, ob ein Delta-Merge
erforderlich ist.
Die Prüfung und der bei Datenänderungen während eines Ladeprozesses im Data Warehouse
erforderliche Delta-Merge werden entweder automatisch vom System durchgeführt oder
müssen manuell ausgelöst werden. Dies ist vom jeweiligen Objekttyp abhängig:
●Nach der Aktivierung für Standard-DataStore-Objekte (klassisch) erfolgt eine
automatische Prüfung, um zu ermitteln, ob ein Delta-Merge durchgeführt werden kann.
Dies gilt auch für DataStore-Objekte, die zu einem semantisch partitionierten Objekt
gehören.
●Nach dem Schreiben von Daten in die PSA für DataSources erfolgt eine automatische
Prüfung, um zu ermitteln, ob ein Delta-Merge durchgeführt werden kann.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 282Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

291. ●Für schreiboptimierte DataStore-Objekte (klassisch), Standard-InfoCubes und SAP-
HANA-optimierte InfoCubes werden die Prüfung und der Delta-Merge nicht automatisch
durchgeführt. Dies gilt auch für Objekte, die zu einem semantisch partitionierten Objekt
gehören.
●Im Datentransferprozess (DTP) wird auf der RegisterkarteVerbuchungdas Ankreuzfeld
Datenbankmerge auslösenangezeigt, das den Delta-Merge nach erfolgreicher
Verarbeitung des DTP-Requests steuert. Das Ankreuzfeld ist standardmäßig markiert.
●Für DataStore-Objekte (advanced) ist das AnkreuzfeldDatenbankmerge auslösen
standardmäßig markiert. Nach der Aktivierung wird automatisch geprüft, ob ein Delta-
Merge durchgeführt werden kann.
Abbildung 247: Delta-Merge-Verwaltung in SAP BW
Lektion: Erläutern von SAP-HANA-Delta-Merges in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 283Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

292. Abbildung 248: Option zum Auslösen von Delta-Merge
Auslösen von Delta-Merge über Prozesskette
In Ausnahmefällen ist ein Delta-Merge nach der Verarbeitung eines DTP-Requests aufgrund
möglicher Lastverteilungsprobleme nicht zu empfehlen. In solchen Fällen kann der Delta-
Merge alternativ über einen Prozesstyp ausgelöst werden.
Kontext
Nur in Ausnahmefällen, die zu Problemen bei der Lastverteilung führen, empfehlen wir, die
Markierung des Ankreuzfelds im DTP aufzuheben und den Prozesstyp „Delta-Merge“ zum
Auslösen des Delta-Merge zu verwenden. Ein Beispiel hierfür ist ein Objekt, in das Daten aus
mehreren Quellen geladen werden und für das erst am Ende des gesamten Ladeprozesses
überprüft wird, ob ein Delta-Merge durchgeführt werden soll.
Notiz:
Stellen Sie sicher, dass durch den DTP oder den Prozesstyp immer ein Delta-
Merge ausgelöst wird. Wenn kein Delta-Merge erfolgt, verbleiben die Daten im
Deltaspeicher. Dies führt im Lauf der Zeit zu Speicherproblemen und wirkt sich
negativ auf die Leseperformance aus.
Sie befinden sich in der Plansicht der Prozesskette, in die Sie den Prozess einbinden wollen.
Der Prozesstyp „Delta-Merge auslösen“ ist in der Prozesskategorie „Ladeprozess und
Nachverarbeitung“ verfügbar. Im Folgenden sind die Schritte zur Ausführung dieser Aufgabe
beschrieben:
1.Fügen Sie den ProzesstypDelta-Merge auslösenmit Drag&Drop an einer geeigneten Stelle
in der Prozesskette ein.
2.Es wird ein Dialogfenster angezeigt. Um eine neue Prozessvariante anzulegen, wählen Sie die Drucktaste „Anlegen“.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 284Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

293. 3.Geben Sie einen Namen und eine Beschreibung für die Prozessvariante ein, und wählen
Sie die Drucktaste „Weiter“.
4.Geben Sie auf dem Pflegebild für die Prozessvariante den Typ und den Namen des Objekts
für den Delta-Merge an.
5.Sichern Sie Ihre Eingaben, und kehren Sie zur Plansicht der Prozesskette zurück.
6.Verknüpfen Sie den Prozess mit den gewünschten Ladeprozessen.
Abbildung 249: Vor und nach dem Delta-Merge
Wenn Sie eine SAP-HANA-Datenbank einsetzen, werden Datenänderungen zunächst in einem
für den Schreibzugriff optimierten Deltaspeicher abgelegt. Der größte Teil der Daten wird
jedoch in einem stark komprimierten Format im Main-Speicher abgelegt, der im Hinblick auf
Speicherplatz und Leseperformance optimiert ist. Ein Delta-Merge dient zum Übertragen von
Änderungen aus dem Deltaspeicher in den Main-Speicher. Zunächst wird über eine
asynchrone Prüfung ermittelt, ob ein Delta-Merge erforderlich ist. Bei Überschreiten eines
bestimmten Schwellenwerts wird der Delta-Merge im Deltaspeicher durchgeführt. Bei
Lesezugriff en werden die Daten aus dem Main-Speicher und dem Deltaspeicher gelesen und
die Ergebnisse zusammengeführt.
Tabelle 9: Delta-Merge
Die Prüfung und der bei Datenänderungen während eines Ladeprozesses im Data Warehouse
erforderliche Delta-Merge werden entweder automatisch vom System durchgeführt oder
müssen manuell ausgelöst werden. Dies ist vom jeweiligen Objekttyp abhängig:
Lektion: Erläutern von SAP-HANA-Delta-Merges in SAP Business Warehouse (SAP BW)
©Copyright. Alle Rechte vorbehalten. 285Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

294. ObjekttypDelta-Merge
Standard-DataStore-Objekt
SAP-HANA-optimiertes DataStore-Objekt
Nach der Aktivierung wird automatisch ge-
prüft, ob ein Delta-Merge durchgeführt wer-
den kann. Dies gilt auch für DataStore-Objek-
te, die zu einem semantisch partitionierten
Objekt gehören.
Persistent Staging Area (PSA) Nach dem Schreiben von Daten in die PSA
erfolgt eine automatische Prüfung, um zu er-
mitteln, ob ein Delta-Merge ausgeführt wer-
den kann.
Schreiboptimiertes DataStore-Objekt
Standard-InfoCube
SAP-HANA-optimierter InfoCube
Die Prüfung und der Delta-Merge werden
nicht automatisch ausgeführt. Dies gilt auch
für Objekte, die zu einem semantisch partiti-
onierten Objekt gehören. Im Datentransfer-
prozess (DTP) wird auf der Registerkarte
„Verbuchung“ das Ankreuzfeld „Delta-Merge
auslösen“ angezeigt, das den Delta-Merge
nach der Verarbeitung des DTP-Requests
steuert. Das Ankreuzfeld ist standardmäßig
markiert.
Abbildung 250: SAP-HANA-Delta-Merge in SAP BW durchführen – Übung
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●SAP-HANA-Delta-Merges in SAP BW erläutern
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 286Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

295. Kapitel 6
Lektion 6
Einführung zu Business-Intelligence-Content
(BI Content)
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird der Business-Intelligence-Content (BI Content) vorgestellt. Es wird
erläutert, worum es sich bei dem BI Content handelt und wo dieser aktiviert werden kann.
Darüber hinaus wird der erweiterte SAP-HANA-optimierte Business Content beschrieben.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●den BI Content und die BI-Content-Aktivierung erläutern
●den erweiterten SAP-HANA-optimierten Business Content beschreiben
BI Content
Abbildung 251: Business-Content-Aktivierung und Metadata Repository
Hinweise zur Einführung
Der BI Content und BI-Content-Erweiterungen sind vorkonfigurierte, auf konsistenten
Metadaten basierende rollen- und aufgabenbezogene Informationsmodelle im SAP Business
©Copyright. Alle Rechte vorbehalten. 287Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

296. Warehouse. Der BI Content stellt ausgewählten Rollen im Unternehmen die Informationen zur
Verfügung, die diese Rollen zur Erfüllung ihrer Aufgaben benötigen.
Diese Informationsmodelle umfassen Rollen, Arbeitsmappen, Querys, InfoSources,
InfoCubes, DataStore-Objekte, Kennzahlen, Merkmale, Fortschreibungsregeln sowie
Extraktoren für SAP-Anwendungen.
BI Content und BI-Content-Erweiterungen:
●können ohne Modifikationen in spezifischen Branchen verwendet werden
●können angepasst, d.h. verfeinert oder vergröbert werden
●können als Vorlage oder Beispiel für kundendefinierten BI Content und BI-Content-
Erweiterungen dienen
Darüber hinaus wird in SAP Business Warehouse Demo-Content bereitgestellt, der
Beispieldaten umfasst und als Anschauungsmaterial verwendet werden kann.
Einführungshinweise
Der BI Content von SAP Business Warehouse ermöglicht eine schnelle und kostengünstige
Einführung. Er stellt zudem ein Modell bereit, das bei der Einführung als Richtlinie verwendet
werden kann. Dieses Modell baut auf den Erfahrungen aus anderen Einführungen auf.
Funktionen
Unter dem Sammelbegriff „BI Content“ stellt SAP Business Warehouse vorkonfigurierte
Objekte bereit. Diese Objekte beschleunigen die Einführung von SAP Business Warehouse, da sie fertige Lösungen für den Bedarf an betriebswirtschaftlichen Informationen liefern.
Der BI Content umfasst die folgenden Komponenten:
●DataSources (hauptsächlich mit dem Backend ausgeliefert)
●Prozessketten
●InfoObjects
●InfoSources
●Transformationen
●InfoProvider (InfoCubes und DataStore-Objekte)
●Variablen
●Data-Mining-Modelle
●Querys
●Arbeitsmappen
●Web Templates
●Rollen
●Aggregationsebene
●Planungsfunktion
●Planungsfunktionstyp
●SAP Crystal Reports (BI-Content-Erw.)
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 288Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

297. ●SAP BusinessObjects Dashboards (BI-Content-Erw.)
Abbildung 252: Business-Content-Aktivierung und Upgrade-Versionen
Abbildung 253: Erweiterter SAP-HANA-optimierter Business Content
SAP-HANA-optimierter BI Content
SAP-HANA-optimierter BI Content kombiniert die Funktionen eines Enterprise Data
Warehouse in einem unter SAP HANA ausgeführten SAP-NetWeaver-BW-System mit
explorativen und interaktiven Echtzeitanalysen unter Verwendung der In-Memory-Datenbank
von SAP HANA. Das neue Datenmodell folgt den Empfehlungen für die skalierbare
Lektion: Einführung zu Business-Intelligence-Content (BI Content)
©Copyright. Alle Rechte vorbehalten. 289Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

298. Schichtenarchitektur (Layered Scalable Architecture, LSA++), die für die Ausführung von BW
unter SAP HANA optimiert wurde.
Voraussetzungen: Schalter
●Um SAP-HANA-optimierten BI Content verwenden zu können, müssen Sie Ihr BW-System
auf einer SAP-HANA-Datenbank ausführen.
●Um SAP-HANA-optimierten BI Content zu aktivieren, müssen Sie den SchalterSAP-HANA-
optimierter BI Content (BW / HANA)(/IMO/BW_CONTENT) einschalten.
Notiz:
Weitere Informationen finden Sie im SAP Help Portal unter http://help.sap.com.
Suchen Sie dort nach „Business Functions einschalten“.
Quellsystem-ID
Bevor Sie Daten in die BW-DataStore-Objekte für SAP-HANA-optimierten Content laden,
müssen Sie die Quellsystem-ID pflegen. Die zweistellige Quellsystem-ID (0GN_R3_SSY) wird
den BW-DataStore-Objekten für SAP-HANA-optimierten Content hinzugefügt. Sie dient dazu,
quellsystemabhängige Objekte (z.B. konsolidierte InfoObjects wie 0GN_CUSTOM) zu füllen,
und ermöglicht die Ermittlung des Systems, aus dem die Daten geladen wurden.
Im Folgenden sind die Schritte zum Pflegen der Quellsystem-ID beschrieben:
1.Öffnen Sie die Data Warehousing Workbench, und wählen SieRSA1 -> Werkzeuge ->
Zuordnung Quellsystem zu Quellsystem-ID.
2.Geben Sie die entsprechenden Werte in der Spalte „Quellsystem-ID“ ein.
Sie können auch über die TransaktionSE16prüfen, ob die zweistellige Quellsystem-ID in der
Tabelle RSSOURSYSTEM für Ihr System und Ihre Landschaft definiert wurde.
Abbildung 254: Vereinfachung der Architektur für komplexe Berechnungen in gemischten Szenarien
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 290Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

299. Abbildung 255: Vereinfachung der Architektur für komplexe Berechnungen in gemischten Szenarien –
Vereinfachung
Abbildung 256: Business Functions in BI CONT für den SAP-HANA-optimierten Content
Der SAP-HANA-optimierte BI Content folgt den Empfehlungen der LSA++. Das Datenmodell
stellt gegenwärtig folgende Funktionen bereit:
●Drei-Schichten-Ansatz für das Enterprise Data Warehouse:
-Die Daten werden in die Open-Operational-Data-Store-Schicht übernommen. Die PSA
dient als Grundlage für die historischen Daten. In dieser Schicht sind keine
Transformationen oder Aggregationen definiert. Für diese Schicht werden BI-Content-
DSOs bereitgestellt, wenn die Daten in mehrere DSOs der EDW-Kern-Schicht geladen
Lektion: Einführung zu Business-Intelligence-Content (BI Content)
©Copyright. Alle Rechte vorbehalten. 291Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

300. werden. Die Struktur der DSOs in der Open-Operational-Data-Store-Schicht entspricht
der Struktur der verbundenen DataSources.
-Die Daten werden dann harmonisiert und in die EDW-Kern-Schicht übertragen. Die
DataSource und die DSOs der EDW-Kern-Schicht sind durch eine InfoSource
verbunden. Zwischen der Open-Operational-Data-Store-Schicht und der InfoSource
wird keine Transformationslogik angewendet. Die gesamte Harmonisierungs- und
Transformationslogik wird zwischen den InfoSources und den DSOs der EDW-Kern-
Schicht angewendet. Sie können mehrere Quellen der Open-Operational-Data-Store-
Schicht mit dem Datenfluss des SAP-HANA-optimierten BI Content verbinden, ohne die
vordefinierten EDW-Transformationen zu verlieren. Dies kann hilfreich sein, wenn Sie
mehrere Quellsysteme anschließen müssen. Für SAP-HANA-optimierten BI Content werden keine InfoCubes mehr benötigt. Diese werden durch In-Memory-optimierte
DataStore-Objekte ersetzt, die für das Reporting verwendet werden können.
-In einer Corporate-Memory-Schicht wird die vollständige Historie der geladenen Daten
abgelegt. Diese dient als Quelle für Rekonstruktionen, ohne dass dabei erneut auf die
Quellen zugegriff en werden muss. Das Corporate Memory wird unabhängig von der
Aktualisierung der EDW-Kern-Schicht gefüllt.
-Für das Reporting wird eine virtuelle Data-Mart-Schicht verwendet. In dieser Schicht vorhandene InfoProvider enthalten keinerlei Daten. Stattdessen beschreiben sie, auf
welche Daten zugegriff en wird und wie diese Daten semantisch für den Benutzer
aufbereitet werden. CompositeProvider werden in dieser virtuellen Data-Mart-Schicht als InfoProvider verwendet und greifen auf die Daten der DataStore-Objekte zu. Je nach
Anwendungsfall werden auch Daten aus SAP HANA Information Models gelesen und
mit bereitgestellten Daten in BW vermischt. Alle BI-Content-BEx-Querys werden
zusätzlich zu den CompositeProvidern bereitgestellt.
●Letzte Aktualisierung. Das InfoObject „Letzte Aktualisierung“ (0UPD_DATE) ist für alle
DataStore-Objekte verfügbar. Anhand dieser Informationen können Sie das Datum der
letzten Aktualisierung für einen bestimmten Datensatz ermitteln. Dies ist hilfreich beim
Laden der Daten und ermöglicht einzelne Lookups oder Wiederherstellungen.
Konsolidierte InfoObjects
Der SAP-HANA-optimierte BI Content stellt, sofern möglich, konsolidierte InfoObjects in
seinem Datenmodell bereit. SAP BW verwendet konsolidierte InfoObjects zur Integration und
Harmonisierung von Informationen aus verschiedenen SAP-Komponenten in einem
standardisierten (konsolidierten) Datenmodell (z.B. 0MATERIAL aus SAP ERP und
0CRM_PROD aus SAP CRM).
Die konsolidierten InfoObjects können Informationen zu Duplikaten in den Stammdaten
speichern und so ein konsolidiertes Reporting mithilfe einer Gruppen-ID ermöglichen.
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●den BI Content und die BI-Content-Aktivierung erläutern
●den erweiterten SAP-HANA-optimierten Business Content beschreiben
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 292Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

301. Kapitel 6
Lektion 7
Einführung zu S4/HANA
ÜBERBLICK ÜBER DIE LEKTION
In dieser Lektion wird erläutert, wie Online Analytical Processing (OLAP) und Online
Transaction Processing (OLTP) wieder zusammengeführt werden und in welchem
Zusammenhang dies zu S4/HANA steht. Darüber hinaus wird S4/HANA Analytics betrachtet,
und es wird beschrieben, wie SAP BW powered by HANA durch S4/HANA Analytics ergänzt
wird.
LERNZIELE DER LEKTION
Am Ende dieser Lektion können Sie:
●die Strategie zur Zusammenführung von OLAP und OLTP im Kontext von S/4HANA
beschreiben
●S/4HANA Analytics als Ergänzung zu SAP BW powered by HANA beschreiben
Einführung in S/4HANA
Abbildung 257: SAP – „The Next Big Thing“
Die SAP Business Suite 4 SAP HANA (kurz SAP S/4HANA) ist ein Business-Suite-Angebot,
das auf SAP HANA aufbaut. In der Vergangenheit waren SAP-Produkte so konzipiert, dass
ihre Ausführung auf verschiedenen Datenbankplattformen, z.B. von Oracle, Microsoft und
IBM, möglich war.
Die Plattform SAP HANA ist seit 2010 verfügbar, und SAP-Anwendungen wie SAP ERP und
die SAP Business Suite konnten sowohl auf der SAP-HANA-Datenbank als auch auf anderen
Datenbanken ausgeführt werden. Die SAP Business Suite 4 läuft jedoch ausschließlich auf der
©Copyright. Alle Rechte vorbehalten. 293Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

302. SAP-HANA-Datenbank. Daher werden beide Produkte zusammen als Paket angeboten: SAP
S/4HANA. Das Angebot soll alle geschäftskritischen Prozesse eines Unternehmens
abdecken. Es integriert die Funktionen aus Lösungen für Geschäftsbereiche und Branchen
und ermöglicht darüber hinaus die Reintegration bestimmter Teile von SAP-Business-Suite-
Produkten wie SAP SRM, CRM und SCM.
Finanzabteilungen müssen die Möglichkeiten neuer Technologie nutzen, um mit neuen und
sich entwickelnden Geschäftsmodellen Schritt zu halten und den Entscheidungsträgern in
ihren Unternehmen aktuelle entscheidungsrelevante Erkenntnisse zu liefern. Mit SAP S/
4HANA Finance können Sie eine einheitliche Sicht auf alle Finanz- und Betriebsdaten
erzeugen, flexible und leicht verständliche Berichte bereitstellen, Prozesse automatisieren
und die finanziellen Auswirkungen bestimmter Geschäftsoptionen mithilfe von
Echtzeitanalysen, Vorhersage und Simulation sofort auswerten – in einer
benutzerfreundlichen Umgebung mit attraktivem Design.
Abbildung 258: SAP S/4HANA: die Business Suite der nächsten Generation
SAP S/4HANA baut auf dem Erfolg der SAP Business Suite powered by SAP HANA auf – mit
einer komplett neu gestalteten Suite.
SAP S/4HANA läuft auf SAP HANA und ermöglicht daher drastische Vereinfachungen wie ein
vereinfachtes Datenmodell (keine Indizes, keine Aggregate, keine Redundanzen) und
Innovationen (z.B. eine offene In-Memory-Plattform für Vorhersagen, Empfehlungen und
Simulationen mit leistungsfähigen Anwendungen).
SAP S/4HANA bietet folgende Vorteile:
●SAP S/4HANA wurde mit der Benutzungsoberfläche von SAP Fiori entwickelt, die eine
durchgängige Benutzerführung und hohe Benutzerfreundlichkeit sowie sofort verfügbare
Informationen auf jedem Gerät bietet.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 294Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

303. ●Durch die Ausrichtung auf das „Internet der Dinge“ und Geschäftsnetzwerke unterstützt
SAP S/4HANA die Echtzeit-Zusammenarbeit in der vernetzten Wirtschaft.
●SAP S/4HANA ermöglicht eine flexible Auswahl des Betriebsmodells (On Premise, Cloud
und Hybrid).
●SAP S/4HANA macht die Einführung leicht (geführte Konfiguration und einfache
Integration – von der Suche nach der Lösung über Cloud-Testversionen bis zur
Implementierung mit vorkonfigurierten Best Practices).
Abbildung 259: Vereinfachtes Datenmodell
Lektion: Einführung zu S4/HANA
©Copyright. Alle Rechte vorbehalten. 295Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

304. Abbildung 260: Bestandsführung – Verbesserung durch Eliminierung von Aggregaten
Das Ergebnis der Neugestaltung ist eine Belegtabelle für Materialbelege:
●Zusammenführung von Kopf- und Positionsebene (Vermeidung von Joins)
●Grundlage für die dynamische Aggregation
●Semantisch korrigierte Materialstammdatentabelle
Umleitung:
Aggregattabellen werden nicht physisch gelöscht. Die Umleitungsfunktion (Transaktion SE11)
leitet jeden Tabellenzugriff an die neue Persistenz um. Grund: Kompatibilität mit Legacy-Code
(z.B. Kunden- und Branchencode).
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 296Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

305. Abbildung 261: Materialbewertung
S/4HANA unterstützt sämtliche Bewertungsmethoden einschließlich der folgenden:
●Standardpreis (S-Preis)
●Gleitender Durchschnittspreis (V-Preis)
●Istkalkulation (in einigen Ländern wie Brasilien obligatorisch)
Bessere Performance, insbesondere bei der Massenverarbeitung (z.B. retrograde Entnahme
in der Serienfertigung).
Im Allgemeinen gibt es weniger zu bebuchende Tabellen (Aggregate) und keine Updates zu
kumulativen Werten im Materialstamm.
Nur für S-Preise: Der Durchsatz wird erhöht, da keine Anwendungssperren mehr vorhanden
sind (parallele Updates werden sortiert).
Um bei der Istkalkulation die Bestandsbewertung zu Istkosten und verbesserte Durchsätze zu
ermöglichen, können Kunden anstelle eines gleitenden Durchschnittspreises die
Istkalkulation (basierend auf dem Material-Ledger) verwenden.
Verringerung des Speicherplatzbedarfs
Das Reporting basiert nicht mehr auf Material-Ledger-Tabellen, die nur materialbezogene
Daten enthalten und keine Informationen zu Finanzdimensionen (z.B. Profitcenter und
Funktionsbereich) liefern können. Das neue Reporting basiert auf dem einheitlichen
Buchungsbeleg, der Material- und Finanzdaten miteinander kombiniert.
Lektion: Einführung zu S4/HANA
©Copyright. Alle Rechte vorbehalten. 297Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

306. Abbildung 262: DIMP-Lösungen – Mehrwert für logistische Prozesse
Abbildung 263: Speicherplatzbedarf
Eine Verringerung von 593 GB auf 8,4 GB bietet weitaus mehr Vorteile als nur eine einfache
Reduktion der Speicherkapazität. Sie können:
●die Anwendung auf einem mobilen Gerät ausführen
●den Datenfluss durch Ihre Geschäftsanwendungen erhöhen
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 298Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

307. ●die Reaktionszeiten verkürzen
●mehr Daten auf dem Bild anzeigen (z.B. Statistikdaten direkt in einem Erfassungsbild)
●Sicherungen und Aktualisierungen beschleunigen
●Daten schneller wiederherstellen
Abbildung 264: SAP Fiori Launchpad
Das SAP Fiori Launchpad ist ein rollenbasierter, personalisierter UI-Client, der Benutzern den
parallelen Zugriff auf SAP-Fiori-Apps und herkömmliche Benutzungsoberflächen ermöglicht.
Das Launchpad basiert auf SAPUI5 und kann daher auf mehreren Geräten, die nach dem
responsiven Designansatz konzipiert sind, und auf mehreren Plattformen (z.B. SAP
NetWeaver Application Server, (ABAP Stack), SAP Enterprise Portal und SAP HANA Cloud
Platform) genutzt werden. Zur Straffung der Implementierungsprozesse wird das SAP Fiori
Launchpad mit vordefiniertem Content ausgeliefert.
Das SAP Fiori Launchpad ist auf die beiden zentralen UI-Clients – SAP Enterprise Portal
(verfügbar) und SAP NetWeaver Business Client (geplant) – abgestimmt.
Die Abstimmung mit dem SAP Enterprise Portal erfolgt durch Ausführung der SAP Fiori Launchpad User Experience innerhalb des SAP Enterprise Portal (wird auch als Fiori-
Framework-Seite bezeichnet) bei gleichzeitiger Nutzung der bewährten Portalinfrastruktur
und von Best Practices.
Die Abstimmung mit dem SAP NetWeaver Business Client for Desktop (NWBC) mit dem SAP-
Fiori-Launchpad-Design ist für künftige Releases geplant.
Dieser Client ist entsprechend der einfachen, intuitiven SAP Fiori User Experience konzipiert
und unterstützt gleichzeitig bewährte UI-Technologien wie Web Dynpro ABAP und SAP GUI
for HTML.
Lektion: Einführung zu S4/HANA
©Copyright. Alle Rechte vorbehalten. 299Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

308. Abbildung 265: OLTP vs. OLAP
Abbildung 266: Nachteile der Trennung
Abbildung 267: Transaktionen und Analysen auf einer zentralen In-Memory-Plattform
Geschäftsanwendungen wurden vor Jahrzehnten als Aufzeichnungssysteme eingeführt – zur
Erfassung von Kundenaufträgen, Störmeldungen und Journalbuchungen und für andere
Aufzeichnungen von Geschäftsvorgängen. Die Mitarbeiter der einzelnen Geschäftsbereiche
benötigten Zugang zu diesen Informationen, um beispielsweise Entscheidungen hinsichtlich
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 300Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

309. Preisfindung, Planung und Prioritäten treffen zu können. Die IT-Abteilungen bauten später auf
völlig anderen Plattformen Systeme zur Unterstützung des Analysedesigns auf. Separate
Systeme für separate Aufgaben auf separaten Plattformen – in der Theorie erscheint dies
logisch. Angesichts der unterschiedlichen Anforderungen der Datenerfassung gegenüber der
Datenanalyse stellten separate Plattformen über viele Jahre hinweg den anerkannten Ansatz
zur Gewährleistung einer guten Performance von Transaktionen und Analysen dar. In der
Praxis führt jedoch die Notwendigkeit der Übertragung von Daten zwischen zwei separaten
Plattformen, die als Grundlage der beiden unterschiedlichen Arten von Systemen dienen, zu
Verzögerungen bei der Informationsbereitstellung. Darüber hinaus werden aufgrund der
Trennung von Analysen und Quelldaten die Möglichkeiten zur Verknüpfung von Erkenntnissen
und Aktionen verringert. Für Unternehmen bedeutet es ein erhebliches Risiko, wenn
Entscheidungsträger gezwungen sind, sich auf veraltete oder unzureichende Daten zu
verlassen, oder wenn sie keinen Bezug zwischen Analyseergebnissen und Quelldaten
herstellen können.
Heutzutage können Unternehmen Transaktionen in Echtzeit mit Analysen verknüpfen, um
das beste Verfahren zur Beschaffung aktueller Informationen zu einer sich schnell
verändernden Situation zu ermitteln. Anstelle getrennter Transaktions- und
Analyseanwendungen auf separaten Plattformen kann eine zentrale
Datenverwaltungsumgebung sowohl für Aufzeichnungs- als auch für Entscheidungssysteme
– eine gute Performance beider Systemarten vorausgesetzt – folgende Vorteile bieten:
●Benutzer können die neuesten Daten sofort nach der Erfassung aufrufen und analysieren
und müssen nicht erst auf einen Datentransfer warten. Dadurch wird die Hauptursache
einer verzögerten Verfügbarkeit von Informationen behoben. Durch den Wegfall des
Mehraufwands für mehrere Plattformen können die Datenverwaltung in der IT und die
Daten-Governance des Unternehmens vereinfacht werden.
●Da Benutzer sofortigen Zugriff auf Daten haben, ist es den Mitarbeitern im Unternehmen
möglich, schneller geschäftskritische Entscheidungen auf Grundlage aktueller
Informationen zu treffen. Darüber hinaus können Geschäftsprozesse beschleunigt werden,
wenn beispielsweise den Contact-Center-Mitarbeitern während einer Interaktion die
neuesten Kundendaten in übersichtlicher Form zur Verfügung stehen. Auf Grundlage der
letzten Kundenaufträge oder sogar von Aufträgen, die sich noch in Bearbeitung befinden,
können sofort Cross-Selling-Empfehlungen erstellt werden.
Lektion: Einführung zu S4/HANA
©Copyright. Alle Rechte vorbehalten. 301Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

310. Abbildung 268: SAP S/4HANA Analytics – Architektur
SAP S/4HANA kombiniert Transaktionen mit Analysen und ermöglicht so operatives
Reporting zu aktuellen Bewegungsdaten. Dieses Konzept wird durch die SAP Core Data
Services für operatives Reporting in Echtzeit unterstützt. Die Inhalte werden in Form eines
virtuellen Datenmodells (VDM) dargestellt, das auf den Bewegungsdaten- und
Stammdatentabellen von SAP S/4HANA basiert. Core Data Services (CDS-Views) werden in
der ABAP-Schicht des S/4HANA-Systems entwickelt, gepflegt und erweitert. Der eigentliche
Lesevorgang und die Transformation innerhalb der SAP-HANA-Datenbankschicht erfolgen
über die systemgenerierten SQL-Runtime-Views in SAP HANA.
SAP konzentriert sich auf die Erstellung eines VDM mithilfe der CDS-Views, um das operative
Reporting im Kontext von S/4HANA zu unterstützen (und alle übrigen ABAP-bezogenen
Standards zu ersetzen).
Die Vorteile dieses Ansatzes bestehen in der vollständigen ABAP-Integration, was
beispielsweise die Wiederverwendung bestehender Reporting-Berechtigungen ermöglicht.
Die Analyse-Engine (eine eingebettete BW-Funktion) unterstützt die Anzeige komplexer
Hierarchien. Diese Vorteile erlauben das Erstellen weiterer Anwendungsfälle für dieses VDM.
S/4HANA Analytics unterstützt nicht nur das generische operative OLAP-Reporting, sondern
auf Basis derselben Modelle auch Szenarien mit eingebetteten Hybrid-Anwendungen für
Transaktionen und Analyse wie SAP Embedded BI oder SAP Smart Business Cockpits. Der
Lesezugriff auf die Suche oder Infoblätter wird ebenfalls unterstützt. Darüber hinaus sind
neue Extraktoren für die Bereitstellung von EDW-Daten in BW geplant, um die Konsistenz
zwischen den Modellen sicherzustellen.
Kapitel 6: SAP Business Warehouse (SAP BW) – erweiterte Themen
©Copyright. Alle Rechte vorbehalten. 302Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

311. Abbildung 269: Core-Data-Services-Views (CDS-Views)
Abbildung 270: SAP S/4HANA Analytics und SAP BW
ZUSAMMENFASSUNG DER LEKTION
Nun können Sie
●die Strategie zur Zusammenführung von OLAP und OLTP im Kontext von S/4HANA
beschreiben
●S/4HANA Analytics als Ergänzung zu SAP BW powered by HANA beschreiben
Lektion: Einführung zu S4/HANA
©Copyright. Alle Rechte vorbehalten. 303Librer?a ERP https://libreriaerp.com/us [email protected] Librer?a ERP https://libreriaerp.com/us [email protected]

312. Kapitel 6
Überprüfung des Lernerfolgs
1.Nennen Sie das fehlende Feld:DataSource→Transformation→
__________→Transformation→InfoProvider.
2.Welche Funktion hat der Datentransferprozess?
3.Für welche der folgenden Objekttypen kann eine externe SAP-HANA-View generiert
werden?
Wählen Sie die richtigen Antworten.
X
ACompositeProvider
X
BQuery
X
CDataStore
X
DDatentyp
4.Welche Funktion hat eine Prozesskette?
©Copyright. Alle Rechte vorbehalten. 304Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]

313. Kapitel 6
Überprüfung des Lernerfolgs - Antworten
1.Nennen Sie das fehlende Feld:DataSource→Transformation→
__________→Transformation→InfoProvider.
InfoSource
2.Welche Funktion hat der Datentransferprozess?
Der Datentransferprozess ist ein Objekt, das bestimmt, wie Daten zwischen zwei
Persistenzobjekten in SAP BW übertragen werden.
3.Für welche der folgenden Objekttypen kann eine externe SAP-HANA-View generiert
werden?
Wählen Sie die richtigen Antworten.
X
ACompositeProvider
X
BQuery
X
CDataStore
X
DDatentyp
4.Welche Funktion hat eine Prozesskette?
Eine Prozesskette automatisiert die komplexen Abläufe in BW mithilfe der Event-
gesteuerten Verarbeitung.
©Copyright. Alle Rechte vorbehalten. 305Librer?a ERm https://libreriaerp.com/us [email protected] Librer?a ERm https://libreriaerp.com/us [email protected]