Telefon+49 4154 9895-90 |
Mailinfo@x-perion.de
  • Willkommen bei X-perion

    Treten Sie ein

  • SAP Forum 2017
    SAP Forum 2017
  • 3,2,1,0 … SAP S/4HANA, all engines running! <p> We have a lift off!
    3,2,1,0 … SAP S/4HANA, all engines running!

    We have a lift off!

  • Ein Beratungshaus mit vielen Erfolgsgeschichten

    Karriere machen bei X-perion

  • BWonHANA bei der Rheinenergie AG - <p> eine Success-Story
    BWonHANA bei der Rheinenergie AG -

    eine Success-Story

SAP IM4G Abrechnung Messstellenbetrieb
SAP IM4G Abrechnung Messstellenbetrieb
Smart Billing
Smart Billing
SAP S/4 HANA FAQ
SAP S/4 HANA FAQ
SAP BWonHANA
SAP BW/4 HANA
SAP Common Layer
SAP Common Layer
SAP Convergent Invoicing (CI)
SAP Convergent Invoicing (CI)
SAP Business Object Tools
SAP Business Object Tools
Datenschutz im SAP-System
Datenschutz im SAP-System

SAP BW on HANA – FAQ

Stand: Januar 2017

 

Was ist SAP BW on HANA?

SAP BW on HANA

BW auf HANA ist zunächst ein „normales“ SAP NetWeaver BW. Die BW Applikation läuft wie gewohnt auf einem ABAP basierenden Applikationsserver. Die Datenbank jedoch wird gestellt von (der In-Memory-Datenbank-Appliance) SAP HANA.

SAP HANA Datenbank

SAP HANA Datenbank

In letzter Zeit wird seitens SAP wieder verstärkt ein historisches Synonym für BW on HANA verwendet: BW powered by HANA. Dies soll sicherlich der sprachlichen Abgrenzung zu BW/4HANA (BW for HANA) dienen!?

Was sind die kritischen Aspekte beim Betrieb eines SAP BW auf einer konventionellen Datenbank wie bspw. von Oracle?

SAP BW auf konventionellen Datenbanken

Kurz gesagt: Leistungsfähigkeit (Performance). Wobei die Blicke der Nutzer/ Konsumenten bzw. der Betreiber/ Betreuer eines SAP BW durchaus unterschiedlich fokussieren.
Seitens der Akzeptanz des BW durch die Nutzer/ Konsumenten (FrontEnd) ist die „analytische Performance“ des BW besonders heikel. Die entsprechenden Erwartungen werden heutzutage besonders bestimmt durch die Tendenz zu hoher Detail-Schärfe und Echtzeit-Nähe der Daten.
Besonders kritisch für die Betreiber/ Betreuer (BackEnd) einer analytischen Applikation gestaltet sich dagegen die „Staging Performance“. Dies inkludiert Überlegungen zur Daten-Redundanz sowie system-technischen „Hygiene“.

Welche generellen Vorteile bietet BW on HANA?

Vorteile SAP BW on HANA

Aus Sicht FrontEnd: Aussicht auf unmittelbare Antwort von veränderlichen „Anfragen“ (Queries) an die beliebig detailreiche Datenbasis.

Aus Sicht BackEnd: Aussicht auf schlichteres Datenhandling sowie redundanzarme Persistierung (Aufbewahrung). Die Daten-Bestückung des BW kann (wieder) in den entsprechenden Zeitfenstern vollendet bzw. aktuelles Staging (echtzeit-naher Daten) überhaupt in Erwägung gezogen werden.

Was ist der Unterschied zwischen BW on HANA und BW mit BWA?

Unterschied BW on HANA und BW mit BWA

BWA – BW Accelerator ist der technologische Vorreiter für SAP HANA. Ein gelegentlich noch anzutreffendes Synonym für BWA ist BIA: Business Intelligence Accelerator.

Ein BW mit „side-by-side“ BWA macht schon seit geraumer Zeit die Potentiale RAM-basierter Datenbereitstellung zugänglich. Dafür werden ausgewählte Daten-Portionen quasi in den BWA-Server repliziert. Profiteur sind insbesondere Abfragen (Queries) auf Basis umfangreicher Datenmengen.
Daneben/ Zusätzlich wird jedoch weiterhin ein Verbund aus der eigentlichen BW Applikation und einer konventionellen Datenbank benötigt. Daten-Staging (und auch die Abfragen auf nicht replizierte Daten) selbst bedienen sich also – anders als BW on HANA – konventioneller Datenbank-Services.

Mit einer Migration von BW zu BW on HANA wird der BWA obsolet.

Wie verändert HANA die analytische Performance des BW?

HANA analytische Performance

Ein typischer analytischer Prozess im BW wird bestimmt durch Aktivitäten zur Sammlung und Verknüpfung der Daten von der Datenbank (Query), dem Transport der Daten im Netzwerk und schließlich der Aufbereitung im entsprechenden FrontEnd.
Bei Performance-Problemen im Netzwerk und beim FrontEnd selbst kann HANA nicht unmittelbar helfen.
Bleiben die Query-Operationen. Diese profitieren in erster Linie von optimal zugänglichen Daten in einem (gefühlt) unerschöpflichen Arbeitsspeicher. Darüber hinaus kann HANA ausgewählte Query-Statements selbst darstellen. So bietet HANA Möglichkeiten, um Ausnahme-Aggregationen von Kennzahlen direkt auf Ebene der Datenbank abzuwickeln.

Dagegen ist es naheliegend, dass bestimmte etablierte Operationen nicht ohne weiteres von HANA (bzw. BWA) übernommen werden können – bspw. klassische UserExit abarbeitende Vorgänge wie die Bestückung virtueller Merkmale/ Kennzahlen.

Welcher Releasestand des BW ist notwendig für ein BW on HANA?

Welcher Releasestand für BW on HANA

Seit BW 7.3 ist die Kombination mit einer HANA-Datenbank allgemein zugänglich. Seit Releasestand 7.4 sind die Anstrengungen der SAP zur Integration von BW-Applikation und HANA unübersehbar. Beispiele dafür sind die HANA optimierte Aktivierung von DSO-Requests oder auch der HANA prozessierte Datentransfer durch Transformationen.

Wie läuft die Migration zu BW on HANA ab?

Migration zu BW on HANA

Ein Migrationsprozess beinhaltet typischerweise folgende Schritte: Upgrade des SAP BW / Unicode-Umstellung (optional) / Heterogene Systemkopie (Migration)

Die seit einiger Zeit zur Verfügung stehende Direct Migration Option (DMO) vereint die drei oben genannten Schritte in einem.  Um ein vorhandenes SAP BW-System mittels DMO nach HANA zu migrieren, müssen u. a. folgende Voraussetzungen erfüllt sein: Vorlage-BW mit Releasestand >= 7.00 SP29 und eingerichtetem 7.x BW Authorisierungskonzept / ABAP und (soweit vorhanden) JAVA Stack auf separaten Servern (kein Dual-Stack).

Was ist mit dem Java Stack für BW on HANA?

Java Stack

Eine Java Instanz (BI JAVA für BW) ist weiterhin relevant für BEx Web und BI Consumer Services (BICS). BICS hat zentrale Bedeutung für den uneingeschränkten Zugang zu BW-Daten. BICS für BW besteht dabei aus zwei Teilen: JAVA und ABAP. Verschiedene BI Java Prozesse in BOE (BO Enterprise) verwenden Java BICS für den Zugriff auf das BW.

Auf der HANA kann BI JAVA für BW laufen, soweit ein (halbwegs) aktuelles Release von SAP NetWeaver 7.4 vorliegt. Eine separate Datenbank für den NetWeaver JAVA Stack ist dann hinfällig.

Was ist von der neuartigen Aktivierung von Daten in DSO-Objekten zu halten?

DSO-Objekte

SAP implementiert eine HANA optimierte DSO Aktivierung mit vielfacher Beschleunigung des (regelmäßig performance-kritischen) Aktivierungsvorgangs. Die HANA optimierte Aktivierung wird generell für alle Standard-DSO unterstützt. Die eine Zeit lang für das Release 7.3 vorgesehene Konvertierung eines Standard-DSO nach HANA optimiertes DSO (mit nicht persistiertem Change Log) ist nicht mehr relevant.

Ein wichtiger Zusammenhang zwischen DSO-Aktivierung und Abfrage-Performance ist zu beachten. Die „Delegation“ von OLAP-Operationen in die HANA Datenbank verlangt die Existenz von SIDs. Um also bei OLAP-Operationen auf DSO-Objekten von HANA profitieren zu können, müssen bereits bei der DSO-Aktivierung die SIDs „gezogen“ werden. Dies sollte jedoch gem. der Eingangsbemerkung kein Problem (mehr) darstellen.

Welches Modell-Konzept steckt hinter dem Begriff „HANA-optimierter Cube“?

HANA-optimierter Cube

Der „klassische“ Cube (genauer: InfoCube) im BW wird bekanntlich repräsentiert von einem erweiterten Stern-Schema: zusammengesetzt aus zwei Fakten-Tabellen (E-Tabelle mit lese-optimierter Partitionierung; F-Tabelle mit lese-/schreib-optimierter Partitionierung), Dimensionstabellen (als „Gruppierungs-Rahmen“ für die Merkmale) und schließlich die übergreifend nutzbaren Merkmals-Tabellen selbst (differenziert in Tabellen für Attribute, Texte, usw.).

Ein solches Schema bietet sich optimal für konventionelle Datenbanken an.

Für die Persistierung in HANA kann das Schema vereinfacht werden: auf nur noch eine Fakten-Tabelle, welche direkt in die Merkmals-Tabellen „verlinkt“. Dabei ist HANA in der Lage, auf der Fakten-Tabelle gleichermaßen performant zu lesen, zu schreiben und zu löschen.

HANA-optimierter Cube

HANA-optimierter Cube

Eine Ausnahme für die Dimensionen gilt jedoch: Es gibt weiterhin physisch eine Paket-Dimension. Dies ist vorteilhaft hinsichtlich schneller, request-scharfer Entfernung von Daten aus dem Cube. Die Lade-Performance wird dagegen von der Paket-Dimension kaum beeinflusst.

Welche Grenzen gelten für die Modellierung von HANA-optimierten Cubes?

Grenzen von HANA-optimierter Cubes

Für HANA-optimierte Cubes gelten die bekannten quantitativen Beschränkungen: maximal 233 Kennzahlen und 248 Merkmale.

Wie verhält es sich mit der Komprimierung von Requests bei HANA-optimierten Cubes?

Komprimierung von Requests bei HANA-optimiertern Cube

Es gibt weiterhin die Möglichkeit der InfoCube-Komprimierung – also der Aggregation von Daten, welche sich schlüssel-technisch nur durch die Request-ID (Request-ID > 0, Request-ID = 0) unterscheiden. Für die Faktentabelle eines HANA-optimierten Cubes finden dazu automatisch angelegte Partitionen für komprimierte und un-komprimierte Requests Verwendung.

Die Bedeutung der InfoCube-Komprimierung hat allerdings im Vergleich zu konventionellen Cubes abgenommen. Vereinfachend lässt sich sagen, dass nur bei sehr datenreichen Cubes eine Wirkung erkennbar wird. Dies hat mit dem sogenannten MERGE Prozess der Fakten-Tabelle eines HANA-optimierten Cubes zu tun. Dieser MERGE Prozess vereinigt „on-the-fly“ die (in den beiden Partitionen organisierten) komprimierten bzw. un-komprimierten Fakten-Daten. Hier gilt: Je kleiner die Partition mit den un-komprimierten Fakten-Daten (Request-ID > 0), desto schneller der MERGE.

InfoCube-Komprimierung wird in HANA als optimierte „stored procedure“ abgewickelt.

Welche Vorteile birgt ein HANA-optimierter Cube für die Modellierung und Beladung?

Vorteile HANA-optimierter Cube

Gemäß des bisherigen Sprachgebrauchs bilden alle Merkmale eines HANA-optimierten Cubes eine „Line-Item“ Dimension ab. Die Dimension steht als „Gruppierungs-Rahmen“ weiterhin zur Verfügung, repräsentiert jedoch nun lediglich Meta-Daten. Es erfolgt keine physische „Materialisierung“ auf der Datenbank.
Die Anordnung der Merkmale auf den Dimensionen des Cubes kann damit uneingeschränkt einer fachlichen Sichtweise folgen. Anpassungen bei der Modellierung – bspw. die Verschiebung eines Merkmales auf eine andere Dimension – sind ohne Einfluss auf die Nutzdaten möglich.

Vor dem Einsatz von HANA wurde ein großer Teil der Lade-Zeit für die Bildung der Beziehungen zwischen Fakten-Tabelle und Dimensionen (also die IDs der Dimensionen) verwendet. Diese Operationen werden bei einem HANA-optimierten Cube obsolet.

Wie funktioniert die Konvertierung von existierenden BW InfoProvider in
HANA-optimierte BW InfoProvider?

Konvertierung von BW Infoprovidern

Die Konvertierung ist optional und kann massenhaft – oder auch selektiv für jeden Provider einzeln – vorgenommen werden. Die Konvertierung läuft dabei direkt auf dem befüllten Provider ab.  Eine gesonderte Aus- bzw. Zwischenlagerung der Nutzdaten ist nicht notwendig.

Hinweis: Ein neu angelegter Cube ist unter BW on HANA grundsätzlich immer HANA-optimiert. Dies gilt auch für die Entstehung im Rahmen einer “After-Import” Methode.

Sind Aggregate relevant für BW on HANA?

BW on HANA Aggregate

Nein, auf das Management von Aggregaten (Sub-Cubes) bzw. BWA-Indizes (BW mit BWA) kann verzichtet werden. Damit können Schritte bei der Datenbereitstellung entfallen, die in konventionellen BW Installationen regelmäßig die analytische Nutzbarmachung spürbar verzögern bzw. behindern.

Kann es in Erwägung gezogen werden, auf Cubes zu Gunsten von DSO-Objekten zu verzichten?

Verzichten auf Cubes

Das Reporting auf (entsprechend eingerichteten) DSO-Objekte sollte unter HANA keine Performance-Nachteile aufweisen. Dies legt den Gedanken nahe, auf die InfoCube-Schicht grundsätzlich zu verzichten und so das Daten-Staging zu vereinfachen.

DSO-Objekte

DSO-Objekte

Auch die neuartigen Möglichkeiten zur Planung (BW-IP) auf Basis von DSO und zur Arbeit mit den neuartigen DSO-Objekten ab BW 7.4 (Advanced-DSO: Keine Limitation auf 16 Schlüssel-Elemente) werden die Daseinsberechtigung von Cubes (fakten-zentrierte Modellierung) weiter erodieren.

Welche Daten/ BW-Tabellen werden zeilen- bzw. spaltenorientiert persistiert?

zeilen- bzw. spaltenorientierte Tabellen

BW on HANA entscheidet selbstständig über die zeilen- bzw. spaltenweise Behandlung der Daten. Grundsätzlich lässt sich sagen: Alle Daten in Tabellen, die nicht BW generiert sind, werden zeilenweise aufbewahrt – bspw. die RSMON* Tabellen. Die Ablage von Nutzdaten dagegen erfolgt spaltenweise: bspw. Fakten-Tabellen, aktive Tabellen von DSOs, PSA Tabellen.

Damit gilt: Auch Daten in (zunächst) nicht HANA-optimierten Cubes werden spaltenweise organisiert.

Wie ergibt sich die seitens SAP proklamierte „Komprimierung“ des Nutzdaten-Bestandes bei der Umstellung auf BW on HANA?

„Komprimierung“ des Nutzdaten-Bestandes

Neben dem Effekt der spaltenorientierten „Einlagerung“ der Daten vor allem aus dem Wegfall-per-se (konventionelle Indizes; Aggregate) und dem Wegfall-per-Konvertierung (Cube Dimensionstabellen) von Konstrukten.

Ist der Upgrade von BW 3.x Objekten zu BW 7.x Objekten notwendig, um BW on HANA benutzen zu können?

Upgrade von BW 3.x Objekten zu BW 7.x Objekten

Die einzige zwingende Aktivität ist zunächst die Migration der 3.x Berechtigungen auf den 7.x Standard. Alle anderen Objekte (wie bspw. Datenfluss-Objekte Fortschreibung und Übertragung) werden unter BW on HANA unverändert funktionieren.

Um allerdings die volle Bandbreite an Möglichkeiten nutzen zu können, empfiehlt sich die Verwendung von 7.x Objekten. Spätestens jedoch auf dem Weg von BW on HANA zur nächsten BW-Generation (BW for HANA bzw. BW/4HANA, siehe gesonderte FAQ) können 3.x Objekte nicht mehr angesprochen werden.

Was geschieht mit Prozessketten, die nun nicht mehr relevante Prozess-Schritte enthalten ?

Prozessketten mit nicht relevanten Prozess-Schritten

An dieser Stelle aufzuzählen sind insbesondere: Roll-up (Aggregate, BIA), Löschung und Wiederaufbau von InfoCube (Faktentabellen-)Indexes und Attributsänderungslauf (ChangeRun). Prozessketten mit diesen „Items“ sollten angepasst werden.

Besondere Beachtung verdient der Prozess-Schritt zur Aktivierung von Stammdaten. Dieser wird bei BW-on-HANA durch eine zusätzliche Einstellung am Stammdaten-DTP (Stammdaten aktivieren) ausgelöst.

Wie sieht es aus mit ABAP und der ABAP-basierten Entwicklung  auf BW on HANA?

ABAP-basierte Entwicklung

BW ABAP Code wird voll unterstützt – ob in Transformationen, Programmen, UserExits, usw. – unabhängig von der darunter liegenden Datenbank.

Es ist dabei jedoch zu beachten, dass HANA nicht per-se eine bessere Performance beim Zugriff auf Daten garantiert. Um ein Beispiel aufzuführen: Einzelsatz-Zugriffe auf spalten-basierte Tabellen sind mit beträchtlichen „Overhead“ seitens HANA verbunden, welcher sogar gänzlich kontra-produktiv wirken kann.

Es ist naheliegend, dass Quelltext in der Zukunft direkt auf der Datenbank geschrieben bzw. ausgeführt wird (code-to-data) – bspw. als „stored procedures“ (SQLScript). Solche Prozeduren sind dann von der Applikation aus mittels ABAP Managed Database Procedure aufzurufen.

Auf diesem Weg können ABAP-Routinen „substituiert“ werden, um bspw. eine HANA-Transformation zu ermöglichen („Re-Programmierung“ zu Gunsten ABAP Managed Database Procedure bzw. SQL-Script).

Macht der Übergang auf BW on HANA Anpassungen bei den bestehenden BEx Auswertungen nötig?

Anpassung von bestehenden BEx Auswerungen

BEx Queries können – wie sie sind – einfach weiter benutzt werden. Auch die Konvertierung von InfoCubes zu HANA-optimierten Providern zieht keine Anpassungen der BEx Queries nach sich.

Profitieren die Query-Rückmeldezeiten von BW on HANA im Vergleich zum BWA?

Performance der Query-Rückmeldezeiten

Eigene Erfahrungen zum Thema: Queries in BW on HANA werden mindestens so schnell ausgeführt werden wie BWA unterstützte Queries. Weitere Verbesserungen sind von HANA daraus zu erwarten, dass HANA-optimierte Cubes ohne (ggf. umfangreiche) Dimensionstabellen auskommen. InfoSets profitieren enorm hinsichtlich Datenbank-Zugriff. Die Performance von DSO nähert sich der von InfoCubes an.

Werden neue Werkzeuge bzw. Software-Tools relevant?

Neue Werkzeuge bzw. Software-Tools

Ja – HANA Studio!  Dieser Eclipse-basierte IDE-Client (Integrated Development Environment) bietet exklusive Services hinsichtlich Management der HANA Datenbank, Berechtigungen sowie Erzeugung und Modifizierung von Daten-Modellen. So können bestimmte  (neue) BW-Objekte – wie bspw. CompositeProvider und Advanced DSO – ausschließlich über die Eclipse-Erweiterung „BW Modeling Tools“ erzeugt und verändert werden.

Was ist die SAP HANA Data Warehousing Foundation ?

SAP HANA Data Warehousing Foundation

SAP HANA DWH Foundation ergänzt die Data Warehouse (DWH) Fertigkeiten von BW on HANA und nativem HANA Enterprise Data Warehouse (EDW)

Applikationsansatz (SAP BW)

SAP BW als Applikation stellt alle benötigten DW-Services und ein integriertes Repository zur Verfügung. Für Modellierung, Monitoring sowie DW-Management werden keine weiteren Werkzeuge benötigt, obschon solche integriert werden können.

SAP S/4HANA 24.1

Quelle: SAP SE 2015

SQL-Ansatz (Natives SAP HANA EDW)

Im Datenbank-fokusierten SQL-Ansatz werden diverse lose miteinander verbundene Werkzeuge für die notwendigen Aufgaben mit getrennten Repositories benötigt. Die Kombination der Werkzeuge (u.U. best of breed) stellen das Data Warehouse dar.

SAP S/4HANA 24.2

Quelle: SAP SE 2015

Mit der SAP DWH Foundation 1.0 werden Werkzeuge für Datenmanagement und –verteilung (DDO Data Distribution Optimizer) in großen SAP HANA Usecases ausgeliefert. Hinzu kommt ein Tool für Data Lifecycle Management (DLM) in nativen SAP HANA Data Warehouses. Ergänzt werden soll die SAP DWH Foundation in späteren Releases um Funktionalitäten hinsichtlich Monitoring (Data Warehouse Monitor) und Scheduling (Data Warehouse Scheduler).

SAP S/4HANA 24.3

Quelle: SAP SE 2015

Ist SAP HANA DWH Foundation eine neue Data Warehousing Lösung der SAP?

Nein, bei SAP HANA DWH Foundation handelt es sich um eine Sammlung von Werkzeugen, die spezifische Aufgaben wie bspw. Data Management in großen SAP HANA Usecases wie bspw. SAP BW oder native SAP HANA Data Warehouses unterstützt.

Können die Werkzeuge der SAP HANA DWH Foundation für alle Applikationen genutzt werden?

Die Werkzeuge aus dem Baukasten der SAP HANA DWH Foundation sind Datenbank-Tools und werden daher auf Datenbank Ebene eingesetzt. Applikationen wie SAP BW haben jedoch für bestimmte Aufgaben (in diesem Fall bspw. das Data Lifecycle Management) eigene Methoden, die nicht überschrieben werden sollten.

Was ist der Unterschied zwischen dem Data Distribution Manager aus der SAP HANA DWH Foundation und der entsprechenden Standardfunktionalität des SAP HANA Studio?

SAP HANA Studio stellt grundlegende Funktionen zur Reorganisation bereit. Für sogenannte large scale landscapes werden zusätzlich bestimmte Administrationsfunktionen im Zusammenhang mit Scale-Out Systemkonfigurationen benötigt, die Bestandteil von Data Distribution and Optimization (DDO) sind.

Benötigt man mit SAP S/4HANA noch ein SAP BW?

SAP S/4HANA SAP BW?

Um es vorwegzunehmen: S/4HANA wird ein Data Warehouse – und insbesondere das SAP BW – nicht ersetzen können.
Die Wahrnehmung des SAP BW ist oft verengt auf den Aspekt der analytischen Performance. S/4HANA verspricht eine bisher ungesehene Exzellenz beim Handling von operativen Daten in Echtzeit. So scheint es naheliegend, neben dem prozess-getriebenen auch gleich das analytische Datenmanagement in der S/4HANA zu verorten.

Aber ein BW im Verständnis eines Data Warehouse ist mehr als analytische Performance. Ein Data Warehouse ist vor allem eine integrative Instanz: für technisch heterogene Daten-Produzenten, für die „Verschränkung“ dieser Daten zu repräsentativen Sichten, für die Harmonisierung von Kennzahl-Interpretationen, für die Historisierung und Zeitreihen-Persistierung, für die unabhängige Bewältigung richtig großer Datenmengen (big data) und nicht zuletzt für die Autorisierung von Nutzerzugriffen.

Die informationstechnische Realität lässt aus unserer Erfahrung kaum zu, die Da-seinsberechtigung des BW als integrative Instanz in Frage zu stellen. Um nur einige Aspekte zu nennen: S/4HANA beherbergt in der Regel nicht sämtliche Daten mit Reporting-Relevanz. Historische Datenstände werden auf Ebene Prozess-System nicht dauerhaft persistiert – Zeitreihen-Betrachtungen sind also nicht ohne weiteres darstellbar. Das Verständnis von Kennzahlen (bspw. Marge) ist unternehmensweit uneinheitlich und entsprechend different abgebildet. Die Verarbeitung von Multi-Millionen Tupeln zu analytischen Zwecken behindert spürbar die Fähigkeit zur IT-technischen Abwicklung der Geschäftsprozesse. Die Berechtigungssystematik fokussiert den Zugang zum System auf die Prozesse – und eben nicht auf (prozess-übergreifendes) Reporting.

Quelle: SAP SE

Quelle: SAP SE

Was ist der Unterschied zwischen BW on HANA und BW/4HANA (BW for HANA)?

Von SAP BW on HANA zu SAP BW/4HANA

SAP BW on HANA integriert bereits seit Version 7.4 HANA-exklusive Features in die bestehende SAP BW Welt und erweitert bestehenden Daten-Logistik-Objekte wie InfoCubes und DSOs um HANA-eigene Modellierungs-Objekte: Advanced-DSOs und Composite Provider. Die klassischen Modellierungsobjekte werden weiterhin über die SAP GUI entwickelt, für die HANA-eigenen Objekte stehen die BW Modeling Tools im Eclipse zur Verfügung. Ab BW 7.5 SPS4 offeriert SAP nun für bestehende Anwendungen die Möglichkeit, die nächste Generation des SAP BW anzustreben: SAP BW/4HANA (BW for HANA) bzw. SAP BW 7.5, Edition for SAP HANA Add-On (siehe dazu gesonderte FAQ).

Quelle: SAP SE

Quelle: SAP SE

SAP BW 7.5, Edition for SAP HANA ist auf einem bestehenden SAP BW 7.5 on HANA mittels speziellem Add-On zu realisieren. Die Weiterentwicklung der „klassischen“ Modellierungsobjekte ist in der Edition for SAP HANA zwar grundsätzlich nicht mehr möglich, Lesezugriffe bleiben jedoch bis zur manuellen Aktivierung des Add-Ons erhalten. Mit der Add-On Aktivierung wird schließlich der Modus „B4H“ (BW/4HANA) erreicht. Die BEx Suite wird sodann obsolet. Zudem dürfen ausschließlich BW/4HANA-kompatible Objekte die Daten-Logistik zusammensetzen. Zur Unterstützung der Übertragung von „klassischer“ Datenlogistik in BW/4HANA-kompatible Objekte wird seitens SAP ein Transfer-Tool entwickelt und im Rahmen des Add-Ons ausgebracht. Schlussendlich kann ein entsprechend kompatibles („B4H“) BW 7.5 on HANA auch system-technisch zu einem BW/4HANA „konvertiert“ werden. Hierbei findet eine „Entkopplung“ vom NetWeaver statt.
Selbstverständlich kann ein SAP BW/4HANA auch „frisch“ installiert werden. Ob „frisches“ BW/4HANA oder über den Zwischen-Schritt Add-On: Mit der Konzentration auf HANA-kompatible Objekte (Advanced DSO, Composite Provider, …) geht u.a. die endgültige Etablierung der BW Modeling Tools im Eclipse einher, die mittelfristig die SAP GUI für die Daten-Logistik-Modellierung vollständig ablösen sollen. Zudem ist angekündigt, dass alle Administrations-Tools zukünftig auf SAPUI5 basieren.

Quelle: SAP SE

Quelle: SAP SE

Kontakt

In einem persönlichen Gespräch informieren wir Sie gerne ausführlicher. Bitte kontaktieren Sie Bettina Holz unter:
Tel: +49 4154 9895-90 oder
bettina.holz@x-perion.de