Mit der Einführung von SAP sind noch keine Architekturvorgaben von SAP gegeben worden. Es gab also keinen Standard, so dass jeder machen konnte was er wollte. Ich hatte damals einige Diskussionen mit Beratern, die gerne für jeden Report ein eigenes Staging haben wollten. Was bei der damaligen Leistungsfähigkeit der Hardware durchaus Sinn ergeben kann. Ein Unterschied war, dass Daten bereits bei der Beladung verändert werden konnten. Hierfür gab es im Quellsystem ein Exit.
Architekturen
- Layered Scalable Architectur für das klassische SAP BW und BW on HANA
- Layered Scalable Architectur ++ für SAP HANA
Vorgaben für Architekturen
- Datenqualität und -konsitenz
- Vermeidung von Redundanzen / Inseln
- Wiederverwendbarkeit von Objekten und Daten. Dieses betrifft vor allem auch Stammdaten
- Wartungsfähigkeit der Anwendung
- Single Point of Truth (Spot)
- Begrenzung des Berechtigungsbereiches
Der Einsatz aller in den Referenzarchitekturen aufgezeichnetten Ebenen ist nicht Pflicht, Ebenen, die nicht benötigt werden oder keinerlei relevanz besitzen, können weggelassen werden. Dieses betrifft u. a. das Corporate Memory. Alle Daten im Warehouse zu speichern kostes Speicherplatz. Für eine Speicherung sollten schon Gründe vorliegen (Backup)
Layered Scalable Architecture
- Vereinheitlichung der Architekturgrundlagen für BW-Anwendungen
- Beschränkung der Entwicklung auf das BW-System
Enterprise-Data-Warehouse-Schicht
Vereinheitlichung und Qualitätssicherung
Data-Aquisation-Schicht
- Speicherung der aus den Quellsystemen ankommenden Daten
- Ursprünglich musten die Daten über die PSA verbucht werden, ab Version ??? konnte dieses geschehen
- Zum Einsatz kommen für die persistente Speicherung DSO
Quality & Harmonization – Layer
- Geschäftsunabhängige Änderungen an den Daten
- Vereinheitlichung der Daten (Harmonisierung)
- Sicherstellung der Datenqualität
Data-Propagation-Layer
- Enthält die aufbereiteten Daten in einer anwendungsneutralen Form
- Speicherung in DSO
- InfoObjekte mit Stammdaten zählen zum Data-Propagation-Layer
Corporate Memory
- Enthält die vollständige Historie der in das System geladenen Dateien in einer anwendungsneutralen Form
Architected-Data-Mart-Layer
Bereich, in dem die Geschäfslogik auf die Daten angewendet werden soll. Aufbereitung der Daten für die einzelnen Reportinganforderungen.
Operational Data Store
- Spielwiese, um ausserhalb der Architektur Daten für das Reporting aufzubereiten, z. B. für Adhoc-Abfragen
Business-Transformation-Layer
- Anwendungsspezifische Aufbereitung der Daten
- Hierzu kann z. B. die Aufteilung eines Datenbestandes auf berechtigungsrelevante Teilanwendungen sein
Reporting Layer
- Enthält die Architected Data Marts, also die Ebene reportingfähiger Daten
- Auf Objekten des Reporting Layers kann direkt ein Reporting aufsetzen, lt. Empfehlung von SAP sollte dieses aber nicht erfolgen
- Realisiert durch InfoCubes mit persistenter Datenspeicherung
Virtualization-Layer
- Entkopplung der Queries von der persistenten Datenspeicherung um eine flexibleren und wartungsfreundlicheren Aufbau zu haben
- Zum Einsatz kommen MutliProvider und InfoSets
HANA
Weniger, dafür universellere Strukturelemente
Operational-Data-Store-Layer
Betrachtet man das Schema LSA++ und vergleicht es mit dem LSA fällt auf, dass die LSA Layer als Teilmenge enthalten sind. Der auffälligst Unterschied liegt darin, das die Persistenzläyer Open ODS, EDW Propagation Layer und Architected Data Marts vom virtuellen Layer erreichbar sind und damit dem Reporting zur Verfügung stehen.
Open Operational Data Store Layer
- Übernimmt die gleiche Aufgabe wie der Data-Aquisation-Layer im LSA mit einigen Unterschieden
- Daten des Open ODS können bereits dem Reporting zur Verfügung gestellt werden
- Die Daten müssen ab BW/4HANA 2.0 nicht mehr zwangsweise als InfoObject angelegt sein, sondern können auch Feldbasiert definiert werden
- Schnittstelle zu den Quellsystemen
- Aufnahme der Daten in aDSO
- Auf den Operational-Data-Store-Layer kann direkt reported werden, wenn das aDSO entsprechend konfiguriert ist
- Open ODS Views
EDW Transformations
- Gleiche Funktion wie im LSA
EDW Propagation Layer
- Gleiche Funktion wie im LSA
Corporate Memory
- Gleiche Funktion wie im LSA
Business Transformations
- Gleische Funktion wie im LSA
Architected Data Marts
- Gleische Funktion wie im LSA der Reporting Layer
- InfoSet und InfoCube werden ersetzt durch aDSO
Virtual-Data-Mart-Layer
- Gleiche Funktion wie der Virtualization-Layer im LSA
- Entkopplung von persistenten Daten und Reporting
- Multiprovieder wird ersetzt durch CompositProvider