Layered, Scalable Architecture (SAP BW)

Eine Einführung

• LSA steht für Layered, Scalable Architecture.
• LSA ist die Referenzarchitektur eines mehrschichtigen Data Warehouses von SAP
• Jede Schicht stellt sozusagen einen Service dar und liefert einen bestimmten Mehrwert
• Die Implementierung sollte erweiterbar sein.

LSA Struktur

	↓ Reporting Frontend
Applikations- schicht	Reporting Layer		Operational Data Store
	Business Transformation Layer
Wiederverwendbare Schichten (Single Point of Truth)	Data Propagation Layer	Corporate Memory
	Quality and Harmonization Layer
	Data Acquisition Layer
	↑ DataSources

Von den genannten Schichten erfüllt jede eine spezifische Aufgabe:

Data Acquisition Layer

• Unterste Schicht → Dient der LSA als Dateneingang
• Schnelles entgegen nehmen granularer Daten in Rohform
• Enthält "breite" extraktion von Daten für ggf. zukünftige Anforderungen
• Langzeitspeicherung findet typischerweise nicht hier, sondern zwecks Performance im Corporate Memory statt
• Umsetzung als PSA oder schreiboptimierte DSOs

Quality and Harmonization Layer

• Bereinigung, Harmonisierung, Transformation von Daten
• Unterschiedliche Quellsysteme auf eine gemeinsame Datenbasis bringen
• Mapping-Tabellen sollten historisiert abgelegt werden, da sich Harmonisierungen über die Zeit ändern

Data Propagation Layer

• Auch Propagator genannt
• Zentrale Schicht der LSA
• Bereitet Daten für Reporting vor
• Harmonisierung von Delta-Verfahren
• Anreicherung von Bewegungsdaten mit Stammdaten
• Speichern der vollständigen Breite der Information
• Häufig Implementierung per Standard-DSO

Business Transformation Layer

• Applikationsaufbereitende Schicht
• Stellt Daten für die Anwendungen in der gewünschten Form bereit
• Einfache und komplexe Berechnungen möglich
• Applikationsgetriebene Schicht
• Granularität ist vom Applikationsbedarf abhängig
• Implementierung per Standard-DSO oder InfoSource, falls keine Persistenz notwendig

Reporting Layer

• Zentrale Berichtsebene
• Stellt Daten für Reporting bereit
• Applikationsgetrieben → Nicht für andere Applikationen wiederverwendbar
• Implementierung per InfoCube, die optional per InfoSet oder MultiProvider verbunden werden

Corporate Memory

• Ist das Unternehmensgedächtnis
• Speichert Daten in der Form zum Ladezeitpunkt
• Führt komplette Historie
• Zweck: Auf Basis der historischen Daten neue Sichten implementieren oder komplett neu aufsetzen
• Daten sollten grundsätzlich unangetastet / untransformiert sein
• Um Speicher zu sparen können die Daten klassisch oder im Near Line Storage archiviert werden

Operational Data Store

• Speichert operationale Daten, z. B. wenn Reporting aus Quellsystem ins BW-Sstem verlagert werden soll.
• Gedacht für Ad-hoc-Auswertungen auf aktuellem Datenbestand
• Implementierung häufig über schreiboptimierte DSOs