SAP Referenzarchitektur

SAP Layered Scalable Architecture

Konventionelles DBMS

SAP Layered Scalable Architecture++

SAP HANA DBMS

Der Übergang zwischen den Welten ist nicht abrupt vollzogen worden, über Zwischenversionen (7.x) sind die Features sukzessive Eingeführt worden.

Beide Architekturen sind strukturell identisch. Die Unterschiede resultieren aus den universelleren Datenflusselementen und Fähigkeiten der SAP HANA Datenbank.

Unterschiede in den Welten

Jenachdem wie es mir als alten Rentner einfällt wird die Liste ergänzt.

Aus meiner Sicht als Rentner ein nicht zu unterschätzender Punkt für die Architektur des Systems. SAP kann das Datenbankmanagement an die eigene Bedürfnisse anpassen und muss sich nicht mit einem vorgegebenen Standard begnügen. Dieses betrifft auch die Einbeziehung der Datenbank in die Anwendungen.

In der klassischen BW-Welt praktisch ausgeschlossen: Die direkte Verwendung der Datenbankfunktionalität aus einem Datenfluss heraus. Klassische BW-Systeme bestehen aus einer Datenbank und einem ABAP-Layer, in dem die Engines für den Betrieb des Systems implementiert sind. BW ist ein Offset hierfür. Direkte Zugriffe wie sie im Datenfluss von SAP BW4/HANA möglich sind, waren in der klassischen Welt nicht möglich.

Die Trennung zwischen ABAP-Layer und Datenbank löst sich.

Sind bestimmt durch die Fähigkeiten und Struktur der Datenbank und den daraus resultierenden Modellierungselementen.

Layered Scalable Architecture (LSA)

Konventionelles DBMS

Elemente:

  • InfoObject
  • HybridProvider
  • InfoCube
  • DataStore Objekct
  • PSA
  • CompositProvider
  • MultiProvider
  • InfoSet
  • VirtualProvider

Datenzugriff Quellsysteme:

  • PUT

Layered Scalable Architecture ++ (LSA++)

SAP HANA DBMS

Elemente:

  • InfoObject
  • Advanced DataStore Object
  • Open ODS View
  • CompositProvider

Datenzugriff Quellsysteme:

  • GET

Ebenen SAP Layered Scalable Architecture++ (LSA++)

Layer können, müssen aber nicht verwendet werden.

LSA

Bereich, in dem eine Kopie der eingegangenen Daten abgelegt wird um eine Historie der Daten zu bekommen. Das Corporate Memory dient dazu, den Datenbestand ohne Zugriff auf die Quellsysteme wieder Aufbauen zu können.

Die Datentemperatur der Daten im Corporate Memory ist kalt, so dass HANA die Daten aus dem Arbeitspeicher auf das Datenarray auslagern kann.

Notwendig ist ein Corporate Memory dann, wenn die Quelle nicht in der Lage ist historische Daten zu liefern oder dieses nicht in ausreichender Qualität kann. Dieses ist oft bei Transaktionalen Systemen wie ERP-Systen der Fall, wo nicht benötigte oft ausserhalb der Quelle inr Archivsystemen aufbewahrt werden um gesetzliche Aufbewahrungsfristen zu erfüllen.

Ebene auf der die eingeganenen Daten aus den Quellsystemen bereinigt und harmonisiert werden.

Fuktional ist die Ebene in beiden Welten gleich.

Ebene der für das Reporting bereitgestellten Daten entsprechend den Vorgaben des Business. Funktional ist die Ebene in beiden Welten gleich, unterscheidet sich jedoch durch die Fähigkeiten der verwendieten Modellierungselemente

  • LSA: Reporting Layer
  • LSA++: Architected Data Marts

In beiden Welten werden die Daten über die Business Transformations aus den persistenten Ebenen des Enterprise-Data-Warehouse-Layer aufbereitet.

Modellierung:

  • LSA: InfoCube, MultiProvider, CompositProvider
  • LSA++: CompositProvider, aDSO
Schlagwörter: ,
Close Menu
error: Content is protected !!