Wir bauen für Sie um! – Implementierung und Erweiterung von SAP HANA Live und SAP Smart Business

Getreu dem Motto: Wir bauen für Sie um! Hat die SAP zum zweitägigen Partner Workshop „Implementation/Extensibility of SAP HANA Live and SAP SmartBusiness“ am 19. und 20.11.2014 im Internationalen Schulungszentrum der SAP in Walldorf eingeladen. FIVE1 war natürlich auch dabei. Nicht nur das Schulungszentrum wird modernisiert, sondern auch die SAP Business Suite. Das bekommen wir von der SAP seit geraumer Zeit immer wieder zu hören – Stichwort „Renovation, Innovation and Transformation“ und ganz neu und über allem schwebend „Simplification“.

Umbau_SAP

Was gibt es also neues von der „HANA Front“ zu berichten und wohin geht die Reise?

Zum Einstieg gab es eine Einführung in die SAP Strategie. Das HANA nicht nur eine neue Datenbank ist, sollte sich mittlerweile herumgesprochen haben. Die In-Memory Technologie bzw. HANA ist das Fundament der SAP Strategie um die derzeitigen strategischen (Hype-) Themen Cloud, Mobile, Big Data und Internet of Things zu erschlagen, deshalb spricht man auch von der SAP HANA Plattform. Im Folgenden eine Darstellung der SAP.

SAP HANA Platform - more than just a database

Quelle SAP: SAP HANA Platform – more than just a database

Die SAP HANA Plattform ist auch das technologische Fundament für SAP HANA Live und SAP SmartBusiness. Doch was ist dies nun?

Was ist SAP HANA Live und SAP Smart Business?

Beginnen wir mit SAP HANA Live (siehe auch der Beitrag von meinem Kollegen Sven Zech) als Voraussetzung für SAP Smart Business, bevor wir auf SAP Smart Business eingehen. Als HANA auf der SAP TechEd 2010 von Dr. Vishal Sikka angekündigt wurde, hat er verkündet das Datenredundanzen in den Anwendungen abgebaut werden sollen. Damit sind nicht nur Aggregate im SAP BW gemeint, sondern auch bspw. Summen in der Finanzbuchhaltung im SAP ERP die in separaten Tabellen vorgehalten wurden. Die neue Technologie soll dazu führen, dass man nur noch die Belegdaten in der Datenbank auf physischen Tabellen vorhält und alle Berechnungen, die weitläufig bekannteste wird die Aggregation sein, on the fly durchgeführt werden sollen, da die In-Memory Technologie dies ermöglicht. Auf genau diesem Prinzip basiert SAP HANA Live. Die operative Daten aus den OLTP Systemen werden nach wie vor in physischen Tabellen in der Datenbankschicht vorgehalten. Die Berechnungslogik für verschiedenste Auswertungen, wie z.B. Aggregationen, wird in sogenannten HANA Views abgelegt.

SAP HANA Live Architektur

Quelle SAP: SAP HANA Live Architektur

Zwischenergebnisse müssen nicht mehr persistiert werden. Diese Views stellen also ein rein virtuelles Datenmodell dar. Neudeutsch ein „Virtual Data Model“ (VDM). Alle HANA Views von HANA Live basieren technisch betrachtet ausschließlich auf Calculation Views. Diese Views werden kategorisiert in Private Views, Reuse Views, Value Help Views und Query Views.

Private Views
Private Views stellen eine Abstraktionsschicht dar. Sie kapseln bestimmte SQL Transformationen auf einer oder mehreren Datenbanktabellen oder anderen Views. Sie sind nicht klassifiziert zur Wiederverwendung, da sie keine klare Geschätfssemantik aufweisen und eher für die Verwendung in anderen Views des virtuellen Datenmodells konzipiert werden. Sie sind vergleichbar mit Subroutines oder privaten Methoden in Programmiersprachen. Ein Private View basiert auf Datenbanktabellen, anderen Private Views oder Reuse Views.

Reuse Views
Reuse Views sind das Herz des Virtuellen Datenmodells (VDM). Reuse Views stellen alle relevante Geschäftsdaten der SAP Business Suite in einer gut strukturierten, konsistenten und verständlichen Form bereit. Reuse Views sind für die Wiederverwendung durch andere Views konzipiert und dürfen nicht direkt von Analysetools direkt konsumiert werden.

Value Help Views
Value Help Views biete Wertelisten für sepzifische Business Entitäten, welche von Query Views verwendet werden. Diese werden von den Frontend Tools verwendet um Werthilfen für Eingabefelder bzw. Variablen zur Verfügung zu stellen.

Query Views
Query Views werden für die direkte Verwendung in analytische Anwendungen (z.B. basierend auf HTML5) oder generischen analytischen Werkzeugen (z.B. die Business Objects Tools) entwickelt. Diese Views sind immer die obersten Views einer View Hierarchie und werden nicht dafür entwickelt in anderen wiederverwendet zu werden. Der technische Name des Views endet mit ‚Query‘. Die Ausgabefelder verwenden verständliche Namen, denn jeder mit etwas Berufserfahrung im SAP Umfeld kennt die kurzen DDIC Felder wie BUKRS oder MANDT, welche deutsche Abkürzungen für Buchungskreis und Mandant darstellen. Ziel ist es aber auch Anwender ohne SAP Kenntnisse und ohne deutsche Sprachkenntnissen die schnelle, einfache Verwendung der Query Views in Anwendungen zu ermöglichen. Aus diesem Grund weisen die Felder in den Query Views sprechende Namen auf und dies in 16 verschiedene Sprachen.

View Hierarchie in SAP HANA Live

Quelle SAP: View Hierarchie in SAP HANA Live

Meiner Meinung nach ist dieses Vorgehen nicht so revolutionär wie es dargestellt wird. Man kann sehr viele Analogien zwischen SAP HANA Live und dem SAP BW ziehen. Das VDM kann man mit der LSA vergleichen mit dem Unterschied, dass die Daten der einzelnen Layer nicht mehr persistiert werden. Die physischen Tabellen auf der Datenbank, welche die Daten der OLTP Systeme persistent vorhalten entsprechen dem Data Acquisition Layer aus der LSA. Die Private Views entsprechen dem Data Harmonisation und Quality Layer der LSA und stellen wie weiter oben beschrieben eine Abstraktionsschicht dar um die Daten zu harmonisieren. Die Reuse Views entsprechen etwa dem Data Propagation und Architected Data Mart Layer der LSA, da die Daten wie bereits beschrieben in einer gut strukturierten, konsistent und verständlichen Form bereitgestellt werden. Die Query Views stellen zu guter Letzt den Reporting Layer in der LSA dar. Man kann also sagen das HANA Live best practices, also alt bewährte Konzepte konsequent umsetzt. Eine weitere spannende Analogie zum SAP BW lässt sich feststellen. Das was im SAP BW der BI Content ist, ist nun SAP HANA Live. Und wie der BI Content deckt SAP HANA Live lediglich den SAP Standard ab. Haben die SAP Kunden den Standard im SAP ERP modifziert oder möchten noch zusätzliche Informationen im Reporting, dann muss auch der SAP HANA Live Content erweitert werden. Wobei wir bei der ersten Hands-on wären.

Erweiterung von SAP HANA Live

Jeder SAP Kunde weiß, dass man auf gar keinen Fall SAP ABAP Code im SAP Namensraum ändern sollte, da beim nächsten Upgrade die Änderung wieder verloren geht. So ist es auch bei SAP HANA Live. Sie können zwar die Änderungen direkt in den SAP HANA Live Views durchführen, aber beim Einspielen der nächsten Version sind Ihre Änderungen verloren. Die Erweiterung von SAP HANA Live wird von der SAP angepriesen, dass dies total einfach ist – schließlich ist die SAP Software durch ein oranges Logo nun auch viel einfacher geworden, getreu dem Motto „Run simple“. Die Lösung der SAP ist wirklich einfach – Stichwort „Run simple“ – wer jetzt an User Exits oder irgendwelche abgefahrene, komplexe SAP Guides denkt, die so ungenau beschrieben sind, dass man erst einmal eine mehrwöchige Schulung benötigt, liegt falsch. Es ist wirklich sehr simple – die Lösung heisst Copy & Paste. SAP schlägt vor den ausgelieferten HANA View zu kopieren und dann den kopierten HANA View anzupassen. Also ganz einfach, oder?

Doch nun erst einmal zurück zum Hands-on Beispiel. Die Hands-on Session war in drei Aufgaben unterteilt, die aufeinander aufbauten. Ziel war es einen Bericht zu erstellen, der die Sales Order Volumen gruppiert nach der Weltbank Klassifizierung nach Einkommen. Die Klassifizierung erfolgt über zwei Z-Tabellen, eine mit den Klassifizierungsdaten und die andere mit den Klassifizierungstexten.

Z-Tabellen zur Klassifizierung der Länder nach Einkommen auf Basis der Weltbank

Z-Tabellen zur Klassifizierung der Länder nach Einkommen auf Basis der Weltbank

Nachdem man sich mit dem Trainingssystem verbunden hatte und das HANA Studio in der Modeler Perspektive eingerichtet hat für das Arbeiten mit SAP HANA Live konnte es losgehen.
Im ersten Schritt musste man einen neuen Reuse View anlegen, welche die zwei Z-Tabellen mit einem Join über die Klassifizierung verbindet. In HANA Live, so die Vorgaben, werden ausschließlich Calculcation Views verwendet, so auch in unserer Hands-on Session. Dies ist eine Empfehlung der SAP, da der Calculcation View alle Möglichkeiten aufweist, welche die anderen Views auch haben. Dieser neu angelegte View wird im nächsten Schritt dazu verwendet den HANA Live Content zu erweitern.

View zur Klassifizierung der Länder nach Einkommen auf Basis der Weltbank

View zur Klassifizierung der Länder nach Einkommen auf Basis der Weltbank

Im zweiten Schritt wird eine HANA Live View erweitert. Zunächst kopiert man den Query-View SalesOrderQuery aus dem Paket sap.hba.ecc in das eigene Paket. Dieser View besteht aus mehreren Joins und mehreren Views. Im Join_6 muss man nun die Spalte Country zur Ausgabe des Query Views hinzufügen. Dies geschieht über einen Rechtsklick auf das Feld und im Kontextmenü wählt man „Propagate to semantics“ aus. Dadurch wird das Feld automatisch bei allen darüberliegenden Joins, Projektionen usw. durchgereicht damit es bei der Ausgabe des Views zur Verfügung steht. Dann fügt man einen neuen Join (Join_8) zwischen Projection_3 und Aggregation hinzu. In diesem neuen Join wird der Reuse View aus dem ersten Schritt hinzugefügt mit der Klassifizierungsinformation. Die Projection_3 und wird anschließend mit dem Klassifiezierungsview gejoined anhand der Felder Country. Dann werden die Felder Classification und ClassificationDescr wieder über „Propagate to semantics“ dem Query View als Ausgabefelder bekannt gemacht.

Durch hinzufügen eines Neuen Joins mit dem Reuse View aus Schritt 1 wird der Query View um die Klassifizierung erweitert

Durch hinzufügen eines Neuen Joins mit dem Reuse View aus Schritt 1 wird der Query View um die Klassifizierung erweitert

Im dritten Schritt sollte noch eine Währungsumrechnung eingebaut werden, so dass die Sales Order Informationen in einer vom benutzerdefinierten Währung angezeigt wird. Hierzu legt man einen Input Parameter an zur Eingabe des Währungsschlüssel. In der Projection_3 legt man dann noch zwei neue calculated Columns an zur Anzeige des eingegeben Währungsschlüssel und den Betrag in der umgerechneten Währung. Bei der Spalte Betrag konfiguriert man die Währungsumrechnung. Anschließend werden die Felder dem Query View wieder bekannt gemacht über „Propagate to Semantics“. Ein kleiner Stolperstein gab es im letzten Schritt auch. Man musste noch die neue Spalte der umgerechneten Währung in der Aggregation auf SUM umstellen, damit die Aggregation ausgeführt wird, da beim Bekanntmachen der neuen Spalte im Query View nicht automatisch die Aggregation eingestellt wird.

Einstellung zur Währungsumrechnung in SAP HANA

Einstellung zur Währungsumrechnung in SAP HANA

Für diejenigen, die noch keine Währungsumrechnung in HANA realisiert haben, ist noch wichtig zu erwähnen, dass die SAP typischen Tabellen (TCURR, TCURC, TCURX, TCURF, TCURT und TCURV) für die klassische Währungsumrechnung ebenfalls nach HANA repliziert werden müssen, falls kein BW on HANA oder Business Suite on HANA auf der HANA Appliance installiert ist, welche die Daten in einem HANA Schema vorhält. Soweit zur Hands-on HANA Live Erweiterung – welches Fazit kann man daraus ziehen?

Fazit SAP HANA Live Hands-on

In der Hands-on war es relativ einfach einen bestehenden Query View zu erweitern. Dies lag sicherlich auch daran, dass die Referenten direkt aus der Entwicklung kamen und die Hands-on Session sehr gut vorbereitet hatten und man ein Handout mit sehr detaillierten Angaben hatte was zu tun ist. In der Wirklichkeit gibt es aber leider kein Hands-on Script, dass beschreibt was zu tun ist. Man muss sich in der Praxis zunächst selbst mit dem Query View auseinandersetzen. D.h. Felder finden und den besten Weg ausloten welche Joins anzulegen sind um das gewünschte Resultat zu erhalten. Dies sollte nach einiger praktischen Erfahrung sicherlich zu meistern sein, da bin ich mir sicher. Man sollte aber auch so ehrlich zu sich selbst sein, dass es in der Praxis nicht immer alles so simple ist wie es derzeit dargestellt wird.

Kommen wir zurück zur einfachen Erweiterung der HANA Live Views mittels Copy&Paste. Wie in der Übung praktiziert muss ein Query View in mein eigenes Paket kopiert werden damit dieser gegen evtl. Änderungen durch die SAP geschützt ist, in der Konsequenz muss ich dann aber auch alle anderen Views, welche Bestandteil des Query Views sind, ebenfalls manuell kopieren, oder? Und die kopierten Views im Query View tauschen? Das klingt doch nach sehr viel manueller, stumpfsinniger Arbeit, die dazu noch sehr fehleranfällig ist? Ich habe die Frage an den Experten aus der Entwicklung gestellt. Die Antwort war ernüchternd, dem ist tatsächlich so. Auch gibt es keine geschützten Kundennamensräume, wie man es aus der guten, alten ABAP Welt kennt.

Die Entwickler haben in der Hands-on Session zugegeben, dass es noch hier und da Verbesserungspotential gibt wie z.B. die Variablenverarbeitung. Diese ist noch bei weitem nicht so ausgeprägt wie man Sie aus dem BW kennt, d.h. Customer Exit Variablen, Variablen aus Ersetzungspfad oder aus Analysberechtigungen fehlen noch. Die anwesenden Entwickler bestätigten auch, dass sie derzeit auch noch an der Baustelle der Hierarchien arbeiten, was man bisher nur mit Workarounds, wie z.B. dem Star-Join (seit SP7 verfügbar), realisieren konnte, soll Anfang 2015 mit der Auslieferung der nächsten HANA Revisionen viel einfacher umzusetzen sein. Diesen Weg zu beschreiben wird auch Hasso Plattner,wie zuletzt, auf der hauseigenen Messe SAPPHIRE, nicht müde zu forcieren.

Bei all der Kritik was noch fehlt oder suboptimal ist, muss man jedoch fair bleiben, das Produkt ist noch recht jung und die SAP liefert in sehr kurzen Abständen Updates mit neuen Funktionalitäten. Ich hoffe, dass die SAP die oben genannten Kritikpunkte aufgreift und in den kommenden Releases Lösungen dafür bereitstellt und sich nicht, wie leider in der letzten Zeit auf der ein oder anderen SAP Veranstaltung geschehen, hinter dem neuen Motto „Run Simple“ versteckt und fehlende Funktionalitäten oder nicht ganz zu Ende gedachte Lösungen damit begründet, dass dies nun viel einfacher wäre, weil es so ist wie es ist und dass HANA nun mal nicht SAP BW ist.

Davon abgesehen ist das Konzept des virtuellen Datenmodells für mich immer noch ein Quantensprung – Dank In-Memory bzw. SAP HANA. Wenn man überlegt, was die Umsetzung solch einer Anforderung in der „alten Welt“ bedeutet. Man müsste die ETL Prozesse anpassen, in den meisten Fällen sogar Programmieren, Daten erneut laden zum Testen. Dies geht nun wirklich schneller und einfache, davon bin ich überzeugt. Ich bin begeistert und glaube, dass die SAP auf einem richtig guten Weg und die Vision von In-Memory Computing und der HANA Plattform konsequent umsetzt. Auch andere Datenbankhersteller wie z.B. IBM und Oracle haben mittlerweile erkannt, dass In-Memory Computing nicht nur ein Hirngespinst von Hasso Platter ist und haben ihre eigenen In-Memory Datenbanken in 2013 angekündigt und nun auch im Produktportfolio (siehe IBM BLU Acceleration und Oracles In-Memory Database Option). Die Frage ist, ob die beiden SAP Rivalen nicht den Markteinstieg verschlafen haben und ob Sie den Vorsprung der SAP noch einholen können? Dies wird die Zukunft zeigen.

Doch zurück zu den SAP Kunden, die von dieser neuen Technik profitieren wollen. Wie sieht der Weg aus ins In-Memory Zeitalter der Business Applikationen? Wie bei jeder neuen Technologie gibt es ganz oft ein allzubekanntes Problem. Nämlich, dass es schon so viele SAP Anwendungen gibt und jede Menge Kunden, welche noch in der „Alten Welt“ leben und damit arbeiten. Aus diesem Grund gibt es genügend Kunden, die zum einen nicht den vorgedachten SAP Standard verwenden und somit HANA Live nicht zu 100 Prozent passt und zum anderen ist auch klar, die SAP hat bisher mit HANA Live nur einen kleinen Bereich der SAP Business Suite abgedeckt. Es gibt für die SAP also noch viel zu tun und der laufende Geschäftsbetrieb der SAP Kunden darf natürlich auch nicht gefährdet werden, deshalb hat die SAP, damals noch Dr. Vishal Sikka, das Motto „Innovation without disruption“ ausgerufen. Wie sehen also die Optionen aus für die Verwendung von SAP HANA Live und damit auch für SAP Smart Business aus?

Welche Installationsmöglichkeiten gibt es für SAP HANA Live?

Wenn man zunächst etwas Erfahrung mit SAP HANA Live sammeln möchte um sich zunächst von den Vorteilen überzeugen lassen zu wollen, kann man den bereits bekannten Side-Car Ansatz verfolgen unter Verwendung von SAP Landscape Transformation kurz SLT. Hierzu benötigt man neben der SLT Installation noch eine HANA Appliance, diese kann on-premise im eigenen Rechenzentrum stehen oder alternativ dazu in der HANA Enterprise Cloud. Wenn man dann davon überzeugt ist, kann man mit der Business Suite on HANA im Idealfall auf SLT verzichten. Interessant ist auch, dass mit HANA SP9 Multi-tenancy & workload management support für Produktivsysteme angekündigt sind, d.h. es können mehrere Produktivsysteme und Entwicklungssysteme auf einer HANA Appliance verwendet werden. Man kann also eine große Maschine kaufen und „alles“ darauf installieren. Generell würde ich aber dazu raten mindestens zwei HANA Appliances zu verwenden damit man die neuste HANA Revision nicht auf dem Produktivsystem testet. Soweit zu den Installationsmöglichkeiten von SAP HANA Live.

SAP HANA Live im Sidecar Szenario

Quelle SAP: SAP HANA Live im Sidecar Szenario
* z.B. SAP ERP unterstützt mit SAP ERP 6.0 SP12
** SAP Landscape Transformation (SLT): ist positioniert für Real Time (trigger based) Data Replication von ABAP und Non-ABAP Quellen (nur von SAP NetWeaver unterstützte Datenbanken) Hauptsächlich empfohlen für Real Time Data Replication Business Scenarios

Wird HANA Live das SAP BW ablösen?

Dies ist eine Frage die sehr oft auch im Kontext HANA vs. BW gestellt wird. Die Antwort von der SAP ist hier ganz klar: „Nein wird es nicht!“. – Und dies ist nicht nur dem geschuldet, dass es sehr viele SAP BW Kunden gibt, die natürlich dem Investitionsschutz unterliegen, sondern auch, weil das SAP BW nach wie vor noch für den Enterprise Data Warehouse Prozess und darüberhinaus (Stichwort: Historienaufbau, Datenharmonisierung, Datenarchivierung, Planung, etc.) benötigt wird. Wie bereits zuvor festgestellt, gibt es auch noch etliche Funktionalitäten, welche derzeit nur vom SAP BW zur Verfügung gestellt werden. Die SAP positioniert SAP HANA Live als sinnvolle Ergänzung zu SAP BW on HANA. Dem kann ich nur zustimmen wie folgende Darstellung der SAP unterstreicht.

SAP HANA Live ergänzt SAP BW on HANA sinnvoll.

SAP HANA Live ergänzt SAP BW on HANA sinnvoll.

Vielleicht gibt es den ein oder anderen Kunden bei dem ein Native HANA Data Warehouse möglich oder sogar sinnvoll ist. Trotzallem gibt es noch etliche Kunden, die auch ohne SAP HANA auskommen werden und mit dem SAP BW mit einer traditionellen Datenbank sehr gut leben können. Diese werden vielleicht erst später an die Grenzen der „alten Technologie“ kommen und wollen später umsteigen, so wie Kunden gibt für die sich SAP HANA schon heute lohnt. Schließlich geht es nicht darum das sich neue Technologie rechnen muss – der Business Case muss sich rechnen. Genau dem trägt die SAP Rechnung indem Sie das SAP BW wie wir es kennen umbaut zu einem Data Warehouse mit virtuellem Datenmodell. Die Kunden haben also nach wie vor die Wahlmöglichkeit, ob Sie ein Data Warehouse auf Basis von SAP BW on HANA mit virtuellem Datenmodell (LSA++) präferieren oder ob Sie ein klassisches Data Warehouse mit der klassischen Layerarchitektur (LSA) bevorzugen. Sicherlich gibt es auch ein Mix aus beiden Architekturen, insbesondere in der Übergangszeit von klassischem EDW mit persistenten Layern hin zum neuen State-of-the-Art BW basierend auf SAP HANA mit virtuellem Datenmodell und zero latency Real-time Reporting und allen Vorteilen die SAP HANA mit sich bringt. Als Fazit kann man abschließend sagen, dass Kunden die Wahlfreiheit haben die In-Memory Revolution der SAP zu folgen oder noch abzuwarten bis sich dies für Sie rechnet. Jedenfalls sollte man SAP HANA Live in seine BI Strategie miteinbeziehen.

SAP revolutioniert den Enterprise Data Warehouse Prozess

Quelle SAP: SAP revolutioniert den Enterprise Data Warehouse Prozess

Soweit zum ersten Tag. In meinem nächsten Blog werde ich über SAP Smart Business und den KPI Modeler berichten.

Getagged mit: , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*