Randnotiz: SAP und der Code Pushdown bei SAP HANA

Wenn die SAP ein HANA-Release für ihre Applikationen released, dann bedeutet das entweder neue Funktionalitäten (im Standard) oder eine HANA-Optimierung der bestehenden Prozesse. Das heißt so lange man sich im Standard bewegt, übernimmt die SAP eine HANA-Optimierung bestehender Anwendungen und Prozesse, meist ein sogenannter Code Pushdown. Unlängst ist es kein Geheimnis, dass die wenigsten Kunden sich im Standard bewegen, sondern eigene Anwendungen schreiben oder eigene Prozesse implementieren.

Im Falle BW gestaltet es sich daher wie folgt. Wann immer man den Standard verwenden kann (Nachlesen in Transformationen als Klassiker) sollte man ihn auch verwenden. Im Idealfall wird die Transformation als „HANA-optimiert“ markiert und dann findet kein Datenaustausch zwischen Applikationsserver und Datenbank statt, da die Transformation über einen HANA Analyseprozess komplett in die Datenbank verlagert wird. Nun ist das nicht immer möglich. Einen kundeneigenen Code Pushdown bietet im aktuellen Release (SAP BW 7.4 SP12) die Kombination aus ABAP Managed Database Procedure (AMDP) mit einem Calculation View. Schlüsselfelder werden über Datenpaket an die AMDP übergeben und dienen in der Methode als Selektionsbedingung auf einen Calculation View, welcher alle Informationen zurückliefert. Komplexere Logik kann in der Methode mit SQL oder SQLScript umgesetzt werden, sollte auch dies nicht möglich sein, dann hätte man ABAP in der Transformation (der Klassiker).

Soweit der Code Pushdown im Falle BW. Unabhängig davon wird dies generell verwechselt mit einer Reporting Anforderung: der Virtualisierung (für das Reporting) über SAP HANA. Hierbei gelten diverse weitere Anforderungen, die es zu berücksichtigen gilt. Während man beim kundeneigenen Code Pushdown in Transformationen die Daten persistiert, das BW-Delta berücksichtigt und eine automatische Paketierung hat, welche eine Skalierung der Ressourcen der SAP HANA berücksichtigt, hat man dies bei einer Virtualisierung nicht. Diese Virtualisierung würde ich gerne getrennt betrachten, da es hier durchaus applikationsübergreifende Schnittpunkte ergeben.

Im Falle des ERP hat man eine andere Herangehensweise. Während nach wie vor im SAP BW die Verarbeitung von Massendaten im Vordergrund steht, hat man im ERP eine anwendungsorientierte Logik bzw. prozessgesteuerte Einzelverarbeitung. Aber auch hier kann man dann das Konstrukt aus AMDP einsetzen, um Applikationslogik elegant in die SAP HANA auszulagern. Da man keine paketierten Schlüsselfelder enthält, werden hier Parameterübergaben eine Rolle spielen.

Egal in welcher Applikation man sich für einen kundeneigenen Code Pushdown entscheidet, spielen folgende Überlegungen oder Punkte bei einer Analyse des Optimierungspotentials eine Rolle. Erstaunlich oft analysiert man dieses Potential, wie man es auch ohne SAP HANA machen würde. Lediglich die Umsetzung erfordert SAP HANA Know-How:

  • Inwieweit kann ich generell nun doch Standardfunktionalitäten nutzen, die von SAP supported in die SAP HANA gepushed werden.
  • An welcher Stelle ergeben sich Engpässe bei der Ausführung von kundeneigenen Coding. Wo laufen die Prozesse sehr langsam.
  • Wo kann ich bereits jetzt SELECT…ENDSELECT Schleifen vermeiden. Wo kann ich Datenbankzugriffe reduzieren. Wo wird auf große Tabellen zurückgegriffen.
  • Wie kann ich eventuell Prozesse transpatenter gestalten, da ich ein Direktzugriff auf die Daten durch SAP HANA erhalte.

Verwandte Beiträge

Leave a comment

*