Kitabı oku: «Praxishandbuch SAP Business Warehouse mit BW/4HANA»

1 Einführung in SAP Business Warehouse

In diesem Kapitel erhalten Sie eine generelle Einführung in das Thema »Business Intelligence« und einen kurzen Abriss zur Historie von SAP Business Warehouse. Abschließend werden die beiden Produkte SAP BW/4HANA und SAP SQL Data Warehousing kurz dargestellt.

1.1 Einstieg in Business Intelligence

Amazon hat es erfolgreich in seinem Geschäftsmodell eingesetzt: das sogenannte Cross- und Upselling. Mit Cross-Selling ist Folgendes gemeint: Wenn Sie sich auf der Internetseite von Amazon als Benutzer registrieren und nach interessanten Büchern stöbern, so speichert das E-Commerce-Versandhaus die Treffer Ihrer Suche. Sobald Sie das nächste Mal auf die Seite gehen, schlägt Ihnen Amazon weitere Titel vor, die zu Ihren Interessen passen. Unter Upselling ist dagegen zu verstehen, dass Ihnen während Ihrer Suche ein teurerer Artikel oder ein Set, das den gewünschten Artikel enthält, vorgeschlagen werden.

Die diesem Prinzip zugrunde liegende Frage ist: Wie bringe ich als Unternehmen meine Kunden dazu, beim nächsten Online-Besuch nicht nur den gewünschten, sondern eventuell weitere Artikel zu kaufen? Amazon hatte hierzu die entscheidende Idee: Wenn es gelingt, die Suchanfrage der Benutzer zu speichern, über einen Algorithmus verwandte Ergebnisse zu finden und sie dem Interessenten vorzuschlagen, kauft der Kunde eventuell mehr als nur einen Artikel. Die Umsetzung erfolgt mittels einer sogenannten Recommendation Engine [1] bzw. eines Empfehlungsdienstes. Im Hintergrund werden dabei Methoden des Data-Minings aufgerufen, die verwandte oder ergänzende Produkte ermitteln. Data-Mining und Recommendation Engines sind die bekanntesten Beispiele für den Einsatz von Business Intelligence.

Das Gabler Wirtschaftslexikon definiert Business Intelligence wie folgt:

»Sammelbegriff für den IT-gestützten Zugriff auf Informationen, sowie die IT-gestützte Analyse und Aufbereitung dieser Informationen. Ziel dieses Prozesses ist es, aus dem im Unternehmen vorhandenen Wissen neues Wissen zu generieren. Bei diesem neu gewonnenen Wissen soll es sich um relevantes, handlungsorientiertes Wissen handeln, welches Managemententscheidungen zur Steuerung des Unternehmens unterstützt.« [2]

Business Intelligence beinhaltet somit bei Weitem nicht nur die bloße Abfrage von Tabellen und das Anzeigen der Ergebnisse auf einer geeigneten Benutzeroberfläche. Vielmehr ist eines der Ziele, durch den Einsatz von Business-Intelligence-Tools und -Methoden neue Zusammenhänge zwischen Daten zu entdecken, die für die Erschließung neuer Kundenfelder oder die Nutzung alternativer Vertriebswege genutzt werden können.

1.2 Grundkonzepte des Data Warehousing

Neben der Globalisierung hat sich in jüngster Zeit auch die Erkenntnis von der Macht der Daten durchgesetzt. Ein Unternehmen, das in der Lage ist, persönliche Daten von Kunden, wie seine Adresse oder Vorlieben und Interessen, geeignet zu speichern und zu analysieren, hat enorme Wettbewerbsvorteile. So erzielt Facebook den meisten Umsatz nicht mit seiner Webseite oder mobilen App, sondern mit Diensten zur Auswertung der mehr als eine Milliarde Benutzerdaten. In diesem Zusammenhang geriet Cambridge Analytics 2016 in die Schlagzeilen, als herauskam, dass das Unternehmen den Präsidentschaftskandidaten Donald Trump im Kampf um Wählerstimmen mit analytischen Methoden, basierend auf Facebook-Nutzungsdaten, unterstützt habe. Technisch ermöglicht haben dies sogenannte Data Warehouses, die in der Lage sind, sehr große Datenmengen in einer Datenbank zu speichern und die die Möglichkeit bieten, Daten gezielt zu filtern sowie mit statistischen Verfahren der Varianzanalyse oder Stichprobentheorie auf Zusammenhänge zu prüfen. Außerdem lassen sich in kurzer Zeit Rechenoperationen oder Abfragen performant ausführen. 1988 stellte IBM als erstes Unternehmen ein Data Warehouse vor.

1.2.1 Definition Data Warehouse

Das Gabler Wirtschaftslexikon definiert den Begriff »Data Warehouse« als

»… eine von den operativen Datenverarbeitungssystemen separierte Datenbank, auf die nur Lesezugriff besteht. In regelmäßigen Abständen werden aus den operativen DV-Systemen unternehmensspezifische, historische und daher unveränderliche Daten zusammengetragen, vereinheitlicht, nach Nutzungszusammenhängen geordnet, verdichtet und dauerhaft in der Datenbasis des Data Warehouse archiviert. Ziel ist die Verbesserung der unternehmensinternen Informationsversorgung (Wissensmanagement) und damit der Unterstützung strategischer Entscheidungen. Als analytisches System liefert es Informationen zur Problemanalyse – Online Analytical Processing (OLAP) –, die durch die Anwendung von Methoden (z.B. des Data Mining) generiert werden.« [3]

Berichtswesen im Data Warehouse

Im Vordergrund eines Data Warehouse steht weniger das operative als vielmehr das taktische oder strategische Berichtswesen zur optimierten Entscheidungsfindung für das Unternehmensmanagement.

Die Daten aus den operativen Systemen werden in mehreren Schritten verdichtet, vereinheitlicht und geordnet, bis sie für das Berichtswesen im Management den geforderten Aggregierungsgrad aufweisen. Viele Unternehmen betreiben daher in der Praxis ein mehrschichtiges Data Warehouse, wie in Abbildung 1.1 dargestellt.

Abbildung 1.1: Data-Warehouse-Schichten

 Die unterste Ebene enthält sehr detailliert operative Daten aus den angeschlossenen Vorsystemen, wie beispielsweise einem ERP- oder CRM-System. Meist finden sich hier die einzelnen Belege wie Bestellungen, Kundenaufträge oder Buchungsbelege aus der Finanzbuchhaltung.

 In der Ebene Business Transformation (Umwandlung in Fachbereichsdaten) werden die operativen Daten interpretiert, harmonisiert und meist auch auf weniger Details verdichtet. In der Folge könnte das etwa bedeuten, dass nicht mehr der einzelne Buchhaltungsbeleg betrachtet, sondern z.B. ein Kontensaldo ermittelt wird. Auf dieser Ebene sind darüber hinaus zusätzliche Ableitungs- oder Zuordnungsregeln definiert, nach denen die Daten gegliedert werden. Hier kann man hinterlegen, welche Konten einer Tochtergesellschaft welchen Konten des Gesamtkonzerns zugeordnet sind.

 Nach der Business Transformation werden die Daten an die Reporting-Ebene weitergeleitet. Dort stehen sie für das Berichtswesen zur Verfügung. Meist werden die Daten auf der obersten Ebene noch weiter verdichtet, um ein leistungsstarkes Berichtswesen zu ermöglichen. Hier lassen sich letztlich die konsolidierte Bilanz des Konzerns sowie, bei Bedarf, die Bilanzen der Tochtergesellschaft abrufen.

Aus dieser Übersicht wird zum einen deutlich, dass die Daten in einem klassischen Data Warehouse oft redundant gespeichert werden, was viel Speicherplatz erfordert. Zum anderen bietet sich durch den Einsatz eines Data Warehouse die Möglichkeit, auf der Basis von vereinheitlichten und hoch aggregierten Daten zu berichten. Dies entlastet die operativen Systeme.

Basierend auf diesen Annahmen sowie mit zunehmendem Praxiseinsatz wuchs die Erkenntnis, dass Data Warehouses eine spezielle Architektur erfordern, um Insellösungen und Datensilos zu vermeiden.

1.2.2 Corporate Information Factory nach Bill Inmon

Im Jahr 1996 war es Bill Inmon vorbehalten, die Idee einer Corporate Information Factory (CIF) zu veröffentlichen. Sie ist in der vereinfachten Abbildung 1.2 dargestellt.

Abbildung 1.2: Corporate Information Factory

Die Kernidee einer CIF ist, dass Daten aus dem gesamten Unternehmen in einem von Bill Inmon skizzierten Enterprise Data Warehouse (EDW) abgelegt werden und dort nachgelagerten Systemen für Auswertungen zur Verfügung stehen. Im ersten Schritt werden die Daten aus verschiedensten Vorsystemen oder Applikationen extrahiert und in einem Staging-Bereich gespeichert. Hier können sie im nächsten Schritt per Extraktion, Transformation und Laden (ETL) homogenisiert und verdichtet werden, damit sich anschließend weitere Zusammenhänge zwischen ihnen ableiten lassen.

Staging

Die Prozessierung der Daten über Extraktion aus den angeschlossenen Quellsystemen bis hin zur Bereitstellung in Data Marts heißt Staging.

Im Anschluss an das ETL werden die Daten meist in verschiedenen Data Marts des Enterprise Data Warehouse gespeichert. Ein Data Mart kann in diesem Kontext einerseits eine persistente anwendungsspezifische Sicht, andererseits eine für einen bestimmten Organisationsbereich erstellte persistente Sicht auf die Daten sein.

Im Zentrum der CIF steht das Enterprise Data Warehouse, das die Daten an nachgelagerte Systeme liefert. Dies können Decision-Support-Systeme oder sogenannte Departmental Data Marts sein, also abteilungs- oder fachspezifische Data Marts. Die Daten im EDW erfüllen folgende Eigenschaften:

 granular

 integriert

 historisch

1.2.3 Die Referenzarchitektur LSA

Parallel zur Entwicklung der ersten Data Warehouses wuchsen, bedingt durch den Aufstieg von SAP R/3 zum Werkzeug für die unternehmensweite Ressourcenplanung, die Anforderungen an das unternehmensinterne Berichtswesen. Mithilfe des herkömmlichen ERP-Systems waren diese Anforderungen nur noch schwer zu erfüllen.

In der ersten Hälfte des Jahres 1997 ging SAP Business Information Warehouse 1.2A für wenige ausgewählte Kunden an den Start. Bill Inmon hatte dazu mit seiner CIF-Idee architektonisch die Vorarbeit geleistet. Die SAP griff seine Idee auf und nutzte sie für die generelle Strukturierung und Modellierung des eigenen Business Warehouse. Architektonisch war das SAP Business Warehouse bis zur Version 7.5 in die Infrastruktur von SAP NetWeaver integriert. Im Laufe der Zeit entwickelte sich SAP Business Warehouse durch den sogenannten Business Content kontinuierlich weiter, mit dem schnell und einfach betriebliche Prozesse verschiedener Branchen abgebildet werden konnten. Mit der zunehmenden Anzahl an Funktionalitäten und neuen Einsatzgebieten stieg jedoch auch die Komplexität und warf bei den Anwendern Fragen bezüglich der Data-Warehouse-Architektur auf. Die klassische Schichtenarchitektur erwies sich in vielen Belangen als zu starr und wenig flexibel bezüglich Anpassungen und Erweiterungen. Den Fachabteilungen dauerte es oft zu lange, bis eine angeforderte Änderung produktiv gehen konnte.

Mit den Jahren und mit zunehmender Erfahrung im dauerhaften Betrieb eines Warehouse setzte sich die Erkenntnis durch, dass ein Business Warehouse eine zukunftsfähige Architektur benötigt, die mit dem Unternehmen mitwachsen kann. 2009 entwarf SAP eine skalierbare Architektur unter dem Namen Layered Scalable Architecture (LSA), also skalierbare Schichtenarchitektur.

Zentraler Ansatzpunkt war, dass man auch zukünftig in der Lage sein wollte, schnell sowie mit nur wenigen Eingriffen in die existierenden Datenmodelle und Applikationen auf geänderte Anforderungen reagieren zu können.

Abbildung 1.3 stellt die Referenzarchitektur der LSA von SAP in der Übersicht dar.

Abbildung 1.3: LSA-Blöcke (eigene Darstellung)

Die einzelnen Blöcke werden nacheinander durchlaufen, und im Zuge dessen werden die einzelnen Bausteine an den Bedürfnissen und Prozessen des Kunden ausgerichtet. Mit dem Kunden werden innerhalb des Blocks »Bausteine« beispielsweise die Granularität der Schichten definiert und Vorgaben für Datenmodelle sowie Entwicklungsrichtlinien festgelegt. Damit entsteht eine kundenindividuelle LSA, die die Prozesse und die Umgebung des Kunden exakt widerspiegelt. Die LSA bietet somit weit mehr als die reine Schichtenarchitektur des bisherigen Data Warehouse, indem sie alle Prozesse beschreibt, die für den Aufbau sowie für den reibungslosen Betrieb eines Business Warehouse erforderlich sind. Für die Gliederung in einzelne Schichten findet sich in der Referenzarchitektur ein Vorschlag (siehe Abbildung 1.4).

Abbildung 1.4: LSA-Schichtenmodell

Man erkennt hier eine Fünf-Schichten-Architektur. Die Eingangsschicht entspricht dem Staging-Bereich in Bill Inmons CIF (vgl. Abschnitt 1.2.2). Die Ebenen Datenqualitäts- und Harmonisierungsschicht, Datenverteilungsschicht sowie Schicht zu Umwandlung in Fachbereichsdaten entsprechen zusammengenommen grob der ETL aus Bill Inmons CIF. Die oberste Schicht, die Berichtsebene mit den Data Marts der Fachabteilungen, entspricht dem Enterprise Data Warehouse. Das Corporate Memory hält die Daten der Eingangsschicht harmonisiert und in Unternehmensbegrifflichkeiten übersetzt zum Wiederaufbau der Applikationen vor, falls die Daten nicht mehr aus dem Quellsystem geladen werden können. Dies kann der Fall sein, wenn die Daten im Quellsystem aus Datenschutz- oder Archivierungsgründen gelöscht werden mussten.

1.3 Grundlegende Architektur von SAP BW/4HANA

Schon seit Mitte der Siebzigerjahre war das Konzept der spaltenbasierten Datenbanken bekannt, in denen die Daten nicht wie bei herkömmlichen relationalen Datenbanken in Zeilen, sondern in Spalten abgelegt sind. Diese Form der Speicherung eignet sich besonders für Data Warehouses und OLAP-Systeme. Erweitert wurde das Konzept durch sogenannte In-Memory-Datenbanken, wie beispielsweise 1997 durch QlikView.

2007 stellte die SAP ihre erste In-Memory-Lösung unter dem Namen SAP Business Warehouse Accelerator vor. Dabei handelte es sich um zusätzliche Hardware, in der die Daten nicht mehr Zeile für Zeile, sondern in Spalten abgelegt wurden. Mit einem an das BW angeschlossenen Business Warehouse Accelerator konnte die Abfrageperformance deutlich erhöht werden.

In den folgenden Jahren wurde diese Technologie ständig weiterentwickelt. 2010 präsentierte das Hasso-Plattner-Institut in Berlin die neue Lösung SAP HANA. Bei SAP HANA handelt es sich nicht nur um eine reine In-Memory-Datenbank, die in sehr kurzer Zeit auf sehr große Datenmengen zugreifen kann. Es ist vielmehr eine komplette Plattform. Zu dieser gehören neben der SAP HANA Appliance und SAP HANA In-Memory Appliance auch die SAP In-Memory Computing Engine. Die SAP-HANA-Datenbank speichert sowohl Daten aus OLTP- als auch aus OLAP-Systemen.

SAP BW und SAP HANA

SAP HANA wird erst mit SAP BW 7.3 als Datenbank unterstützt. Frühere Releases von SAP BW können nicht mit dieser Technologie genutzt werden.

Mit dem Einsatz der SAP-HANA-Plattform ergeben sich Änderungen an der Layered Scalable Architecture. 2012 veröffentlichte die SAP Anpassungen an der LSA unter der Bezeichnung LSA++. Abbildung 1.5 stellt die Architektur zusammenfassend dar.

Abbildung 1.5: Architektur von LSA++

Ein Bestandteil der Architektur ist u.a. eine virtuelle Data-Marts-Schicht in BW, in der sich die Daten aus den vorhergehenden Schichten als sogenannte externe View in SAP HANA ablegen lassen. Dadurch können Queries mit optimalen Zugriffszeiten auf operationale Daten gebaut werden. Während die LSA noch – überwiegend aus Performancegründen – eine Trennung zwischen Berichtsebene und den operationalen Daten vollzog, entfällt diese Trennung durch den Einsatz von SAP HANA. Mit dieser neuen Datenbanktechnologie von SAP kann auf alle Schichten der LSA++-Architektur gleichermaßen leistungsfähig zugegriffen werden, was letztlich ein operatives und taktisches Berichtswesen zulässt. Die großen Vorteile liegen hier in einer Auflösung des starren Schichtenmodells, das mehrfach redundante Speicherung erzwang, und einem flexibleren Aufbau der Unternehmensberichte auf operationalen und taktischen Daten.

Migration auf SAP BW/4HANA

Eine Darstellung aller Funktionalitäten sowie Migrationsmöglichkeiten von einem Business Warehouse on any DB oder SAP BW on HANA auf SAP BW/4HANA sprengt den Rahmen dieses Buches. Als weiterführende Lektüre verweise ich auf das Buch »SAP BW/4HANA und BW auf HANA«, 2., erweiterte Auflage (Sauer/Riesner, Espresso Tutorials, 2017)

Als Folge der Einführung von SAP HANA als grundlegende Plattform war es nur logisch, SAP Business Warehouse ebenfalls technologisch auf neue Füße zu stellen. Mit der Version 7.5 des SAP Business Warehouse liefert SAP die letzte Version eines auf SAP NetWeaver basierten Warehouse. Weiterentwicklungen oder neue Funktionalitäten sind aktuell für SAP BW 7.5 nicht geplant. Da die neue technologische Basis für SAP Business Warehouse die Datenbank SAP HANA ist, erhielt das neue Produkt auch einen entsprechenden Namen: »SAP BW/4HANA«. SAP HANA dient dabei sowohl zur Speicherung der Daten als auch zur Abwicklung von Logiken im Bereich des ETL oder zur Umwandlung der Fachbereichsdaten. Für die Beschreibung Letzterer stellt SAP HANA beispielweise spezielle mathematische, statistische oder auch String-Verarbeitungsfunktionen zur Verfügung. Aus Gründen der Abwärtskompatibilität verfügt SAP BW/4HANA über einen kleinen ABAP Stack, mit dem der Entwickler Business-Logik in ABAP hinterlegen kann.

1.3.1 Elemente und Struktur von SAP BW/4HANA

Wie in Abbildung 1.5 ersichtlich, können Sie an SAP BW/4HANA verschiedene Quellsysteme anschließen. Dies können andere SAP-Systeme, Dateien, relationale Datenbanken, aber auch Webservices sein.

Die Anbindung der verschiedenen Quellsysteme erfolgt über sogenannte DataSources, die ein Eins-zu-eins-Abbild der Quelldaten darstellen.

Die Eingangsebene der Daten kann in SAP BW/4HANA mit sogenannten Advanced DataStore Objects (aDSO) in der Ausprägung eines schreiboptimierten DSO modelliert werden. Dies sind flache Tabellen, in denen die Daten aus dem Vorsystem unverändert abgelegt, historisiert und im nächsten Schritt über ETL-Methoden an das SAP Business Warehouse übertragen werden können.

Das kleinste Element der Modellierung in SAP BW/4HANA stellt das sogenannte InfoObject dar. InfoObjects lassen sich wiederum nach Merkmalen und Kennzahlen unterscheiden.

Methoden der Datenverarbeitung stehen in SAP BW/4HANA ausschließlich in Form von Transformationen zur Verfügung. Als Lademethode dient der Datentransferprozess. Datenziele einer Transformation heißen in SAP BW/4HANA allgemein InfoProvider. Die beiden wichtigsten Typen der InfoProvider sind das bereits erwähnte aDSO sowie der CompositeProvider. CompositeProvider bieten eine für die mehrdimensionale Analyse optimierte Sicht auf die Daten. Der CompositeProvider vereint technisch die Möglichkeiten einer SQL-UNION und eines SQL-JOIN aus den verschiedenen beteiligten InfoProvidern.

SQL-JOIN

Ein SQL-JOIN liefert aus den Datensätzen zweier oder mehrerer Tabellen einer relationalen Datenbank eine Ergebnistabelle, deren Datensätze Felder der verwendeten Tabellen anhand einer Verbundoperation (JOIN) enthalten.

Beispielabfrage: Liefere mir alle Rechnungen eines Kunden mit Kundennamen, Rechnungsdatum und Rechnungsbetrag.

Das zugehörige SQL zeigt Listing 1.1.

SELECT Kunde.Vorname, Kunde.Nachname, Rechnung.Rechnungsdatum, Sum(Rechnung.Nettobetrag) AS Summe_Netto FROM Rechnung INNER JOIN (Kunde INNER JOIN Kundenrechnung ON (Kunde.Kdnr = Kundenrechnung.Kdnr) AND (Kunde.Kdnr = Kundenrechnung.Kdnr)) ON (Kundenrechnung.Rechnungsnr = Rechnung.Rechnungsnr) AND (Rechnung.Rechnungsnr = Kundenrechnung.Rechnungsnr) GROUP BY Kunde.Vorname, Kunde.Nachname

Listing 1.1: Alle Rechnungen eines Kunden mit Kundendaten

SQL-UNION

Bei einer SQL-UNION werden die Ergebniszeilen von zwei oder mehr Tabellen verkettet.

Beispielabfrage: Liefere mir die Vornamen und Nachnamen aller Kunden und Lieferanten.

Das zugehörige SQL lautet:

SELECT Vorname, Nachname from Kunde UNION Select Vorname, Nachname from Lieferant;

Der CompositeProvider ist somit eine Weiterentwicklung und Vereinheitlichung der aus den SAP-NetWeaver-basierten Versionen des Business Warehouse bekannten InfoProvider-Typen »MultiProvider« und »InfoSet«. Mit der Option, Daten über eine externe View direkt als SAP-HANA-Tabelle bereitstellen zu lassen, können externe Tools ebenfalls auf die Daten in der SAP-HANA-Datenbank zugreifen. Benötigt wird hierfür lediglich ein passender SAP-HANA-ODBC- oder -JDBC-Treiber für die Zieldatenbank.

Der Query Designer dient auch unter SAP BW/4HANA als das Tool, um Daten in aggregierter oder angereicherter Form für ein Reporting zur Verfügung zu stellen. Unter SAP BW/4HANA und SAP BW on HANA hat der Query Designer ein Facelifting erfahren und wird als Eclipse-Plug-in innerhalb der BW Modeling Tools angeboten. Das Anlegen und Ausführen von Queries sprengt allerdings den Rahmen des Buches. Daher empfehle ich für das Arbeiten mit dem Query Designer in Eclipse mein Buch »Schnelleinstieg in den SAP Query Designer mit Eclipse« (Espresso Tutorials, 2017).

1.3.2 Kurzübersicht SAP BW/4HANA

SAP BW/4HANA ermöglicht eine sehr effiziente Integration verschiedenster SAP-Systeme über vorgefertigte Extraktoren, die der Kunde bei Bedarf anpassen kann. Die Architektur von SAP BW/4HANA zeigt Abbildung 1.6.

Abbildung 1.6: SAP-BW/4HANA-Architektur (eigene Darstellung)

Wie in der Abbildung unter zu sehen, ermöglicht SAP BW/4HANA das Einbinden verschiedener externer Quellen (Sources). Dies sind z.B. andere Datenbanken wie Microsoft SQL Server oder Oracle-Datenbanken. Über die Schnittstelle mit SAP Vora kann auch Hadoop, eine Lösung für Data Lakes, angeschlossen werden. Die Operational-Data-Provisioning(ODP-)Schnittstelle überträgt die Daten aus SAP-Quellsystemen per standardisiertem Delta-Handling an das BW-System. Bei ODP handelt es sich um einen Provider-Consumer-Ansatz. Das Quellsystem bietet über die ODP-API die Möglichkeit, dass Daten, wie beispielsweise die Kundenstammdaten, von beliebigen an das Quellsystem angeschlossenen Systemen konsumiert werden können. Die einzige Voraussetzung ist, dass das angeschlossene System die ODP-Schnittstellen-API ebenfalls implementiert hat. Sobald in SAP BW/4HANA ein Datentransferprozess zum Extrahieren der Kundendaten angestoßen wird, registriert sich das BW-System als Consumer beim Kundenstammdaten-Provider im Quellsystem. Über Zeitstempel und Datensatzzeiger kann daher ein sicherer, standardisierter Delta-Mechanismus zur Verfügung gestellt werden. Die ODP-Schnittstelle ersetzt die BICS-Schnittstelle, die aus den SAP-NetWeaver-basierten BW-Systemen bekannt ist, zum Datentransfer zwischen SAP-Systemen. Mit der ODP-Schnittstelle einher geht ein geändertes Verfahren, wie Datensätze im Delta-Init-Verfahren an SAP BW/4HANA übertragen werden. Dies ist eine wesentliche Neuerung in SAP BW/4HANA. Eine detaillierte Betrachtung der ODP-Schnittstelle sprengt jedoch den Rahmen dieses Buches.

Die SAP-HANA-Plattform wiederum besteht aus mehreren Komponenten; die wichtigsten im Zusammenhang mit BW sind die Datenbank (DB), die Calculation Engine (Calc. Eng.) sowie der SAP Smart Data Access (SDA) bzw. die SAP Smart Data Integration (SDI). Über SDA bzw. SDI können relationale Datenbanken angeschlossen und so gezielt einzelne relationale Tabellen oder Sichten auf eine Tabelle zeitgesteuert ins BW geladen werden.

In Abbildung 1.6 unter sind die geeigneten Tools aufgeführt. Aufgaben in der Datenbank sowie Arbeiten mit der Calculation Engine oder SDA erfolgen mit den SAP HANA Modeling Tools.

SAP BW/4HANA Application besteht aus dem eigentlichen Data Warehousing mit einer LSA++-Architektur und dem Analytical Manager für OLAP-Operationen bzw. mehrdimensionale Auswertungen. Daneben steht das Metadata Repository, das die gesamten Metadaten, also im Wesentlichen die Struktur der einzelnen Objekte, verwaltet. Als Schnittstellen zu anderen externen Systemen bietet SAP hier einerseits ODP und andererseits den Open Hub an. Für eine Zusammenarbeit im Team an einer gemeinsamen Aufgabe können Workspaces genutzt werden. Sie erlauben es dem Fachbereich und der IT, gemeinsam an einem Datenmodell zu arbeiten und dies grundsätzlich zu entwickeln, um es nach einer Abstimmung anschließend in das Data Warehousing zu übernehmen. Der Einsatz von Workspaces empfiehlt sich besonders für agile Projektmanagement-Methoden, wie etwa SCRUM.

Oberhalb von SAP BW/4HANA Application sind die Business User Tools angeschlossen. Dabei handelt es sich zum einen um SAP-Analytics-Lösungen, wie etwa SAP Analysis for Microsoft Office oder SAP Analytics Cloud. SAP Lumira wird nicht mehr weiterentwickelt, und der Support dafür wurde 2019 eingestellt. Zum anderen ist hier die Planungskomponente SAP Business Planning and Consolidation (BPC) zu nennen. Die SAP-BW/4HANA-Application-Schicht ist die Schnittstelle für weitere Tools von Drittanbietern für ein formatiertes Berichtswesen oder Management-Dashboards, wie etwa Qlik, Tableau und weitere.

Damit möchte ich den eher theoretischen Teil und die Einführung in SAP BW/4HANA beenden und mich im nächsten Kapitel dem Fallbeispiel zuwenden.

2 Fallbeispiel

In diesem Kapitel lernen Sie das Fallbeispiel mit Lösungsansatz kennen. Es werden kurz der rein feldbasierte, der InfoObject-basierte sowie der Hybrid- oder Mixed-Modeling-Ansatz zur Lösung vorgestellt.

2.1 Aufgabenstellung

Sie arbeiten in der IT-Abteilung eines Unternehmens aus der Energiewirtschaft. Ihre IT-Landschaft ist durch eine Vielzahl von verschiedenen Systemen und Anwendungen geprägt. Für die kritischen Prozesse ist SAP als führendes System gesetzt. Sie haben zahlreiche Kunden, jedoch ist der Markt durch Preiskämpfe geprägt. Über einschlägige Internetseiten kann sich der Verbraucher jederzeit über den günstigsten Stromtarif informieren. Davon ausgehend, dass alternative und erneuerbare Energien in nächster Zeit staatlich günstiger besteuert werden, entschließt sich Ihr Unternehmen, ein neues Stromprodukt speziell für Singles auf den Markt zu bringen. Der Marketing- und Produktabteilung fehlt jedoch eine verlässliche Aussage über einen konkurrenzfähigen Preis für das neue Stromprodukt.

Da der Energiemarkt stark staatlich kontrolliert ist, melden alle Energieunternehmen, im Weiteren »Netzbetreiber« genannt, die Strompreise einer zentralen Stelle, der Bundesnetzagentur. Die Bundesnetzagentur erlaubt verschiedenen Anbietern, diese Informationen zu verarbeiten, um sie öffentlich und auch für Privatverbraucher zur Verfügung zu stellen. Die gestellte Aufgabe von der Marketing- und Produktabteilung beinhaltet daher, eine Liste aller aktuellen Netzbetreiber mit dem aktuell gültigen Preis für einen Single-Privathaushalt mit ca. 2500 kWh Jahresverbrauch zu erstellen. Für unser Beispiel soll die Preisermittlung sehr stark vereinfacht werden. Der Preis soll in einem ersten Schritt nur anhand des Netznutzungsentgelts berechnet werden. Ein Netzbetreiber kann dabei den Strom an verschiedene postalische Orte in Deutschland liefern. Dies sind die sogenannten Liefergebiete. Die von der Marketingabteilung geforderte Liste soll folgende Felder enthalten:

 Postleitzahl Liefergebiet

 Ort Liefergebiet

 Netzbetreibername

 Sitz des Netzbetreibers (Ort)

 Postleitzahl des Netzbetreibers

 Höhe Netznutzungsentgelt (NNE)

2.2 Datengrundlage

Da der gesamte Energiemarkt reguliert ist, können Sie auf einen Anbieter zurückgreifen, der die zur Lösung des Fallbeispiels benötigten Informationen, wie Netzbetreiber auf PLZ-/Ort-Ebene und die zugehörigen Kosten, vorhält. Die Firma ene’t aus Hückelhoven stellt diese mit vielen weiteren zusätzlichen Informationen in Ihrem Downloadbereich zur Verfügung. Unter der URL https://download.enet.eu/uebersicht/datenbanken finden Sie eine Reihe von öffentlich zugänglichen Daten, wie Abbildung 2.1 zeigt.

Abbildung 2.1: Frei verfügbare ene’t-Datenbanken

Laden Sie sich von dieser Seite die ZIP-Datei für Netznutzung Strom als CSV und MSSQL herunter und speichern Sie beide Dateien lokal auf Ihrem PC. Anschließend entpacken Sie die Dateien in einen Ordner Ihrer Wahl. Schauen Sie sich den Ordner mit den entpackten CSV-Dateien kurz an und scrollen Sie etwas die Seite hinunter bis an die Stelle aus Abbildung 2.2.

Abbildung 2.2: Auszug aus ene’t-Dateien

Die vorliegenden Daten enthalten nur einen Ausschnitt der gesamten Datenmenge. Dieser reicht für unser Fallbeispiel jedoch aus. Anhand der Dateinamen sehen Sie, dass das Datenmodell von ene’t normalisiert vorliegt. Die Daten zur Lösung der Aufgabenstellung sind daher auf mehrere Dateien bzw. Tabellen aufgeteilt.

Die Lösung erfordert eine Tabelle, die Ihnen pro Postleitzahl und Ort den aktuellen Netzbetreiber liefert. Für den Sitz des Netzbetreibers und die Postleitzahl des Netzbetreibers benötigen Sie seine Stammdaten. Zum weiteren Verständnis hilft, dass das deutsche Stromnetz in viele kleinere Stromnetze aufgeteilt ist. Jedes dieser kleineren Stromnetze hat eine eindeutige Netznummer zur Identifikation erhalten. Jeder Netznummer ist dabei eindeutig ein Netzbetreiber zugeordnet. Die Preiskalkulation erfolgt über eine Tabelle mit dem Netznutzungsentgelt.

Konkret sind für das Fallbeispiel nur die in Tabelle 2.1 ausgewiesenen ene’t-Tabellen erforderlich:

ene’t-Tabelle	Beschreibung
Netzbetreiber	Stammdaten des Netzbetreibers, wie Adresse, Bundesland, Kontaktdaten, …
Netze	Stammdaten mit Zuordnung des Netzbetreibers zur Netznummer
PLZ_Netzbetreiber	Liste aller Postleitzahlen und Orte mit zugeordneter Netznummer
Netznutzungsentgelt	Netznutzungsentgelt pro Netznummer

Tabelle 2.1: enet’t-Tabellen für Fallbeispiel

Ich möchte die einzelnen Kostenkomponenten kurz näher erläutern und die notwendigen Beziehungen zwischen den benötigten ene’t-Tabellen darstellen, um die entsprechenden Teilkomponenten der Kosten zu erhalten.

Die Ermittlung der Kosten möchte ich Ihnen anhand eines Netzbetreibers in 66111 Saarbrücken exemplarisch zeigen. Öffnen Sie die CSV-Datei für PLZ_Netzbetreiber in Excel. Filtern Sie auf die Postleitzahl 66111. Als Netznummer finden Sie im Feld Netz-Nr. den Wert 66117001.

Für das Netznutzungsentgelt öffnen Sie die zugehörige CSV-Datei Netznutzungsentgelt.csv. Sie stellen fest, dass die Datei aus sehr vielen Spalten mit unterschiedlichen Werten besteht. Diese Datei liegt im Kennzahlenformat vor. Für die Lösung wird nur ein Teilausschnitt benötigt. Das Netznutzungsentgelt soll für Single-Privathaushalte mit einem Eintarif-Drehstromzähler ermittelt werden. Folgende Spalten werden benötigt:

 Netz_Nr

 ID

 GUELTIG_SEIT

 GUELTIG_BIS

 Ms_o_LM_HH_GP

 MS_o_LM_HH_AP

Filtern Sie in der Spalte Netz_Nr wieder auf den Wert 66117001, in der Spalte Status_ID auf 1 und im Feld GUELTIG_BIS auf 31.12.2999. Der Grundpreis ist in der Spalte MS_o_LM_HH_GP, der Arbeitspreis pro kWh in der Spalte MS_o_LM_HH_AP gespeichert. Die Formel zur Berechnung lautet folgendermaßen:

Berechnung Netznutzungsentgelt

Generelle Formel:

»Grundpreis« [€/Jahr] + Verbrauch [kWh/Jahr] * »Arbeitspreis« [Cent/(kWh)] / 100 [Cent/€]

Für die Netznummer 66117001 ermittelt sich demnach das Netznutzungsentgelt wie folgt:

35 [€] + 2500 [kWh] * 5,12 [Cent/kWh] / 100 [Cent/€] = 163,00 €.

Mit diesem Wissen kann prinzipiell ein erster Datenfluss gebaut werden. Für die weitere Modellierung ist noch ein Punkt wichtig: Soll ein rein feldbasierter, ein rein InfoObject-basierter Ansatz oder ein Mixed-Modeling-Ansatz verfolgt werden?

2.3 Feldbasierter Lösungsansatz

Mit SAP BW/4HANA ist ein rein feldbasiertes Modellieren prinzipiell möglich. Beim feldbasierten Modellieren verzichten Sie auf das Anlegen von InfoObjects und nutzen ausschließlich die Felder aus den Tabellen der angeschlossenen Systeme. Dies hat den Vorteil, dass Sie schnell einen Prototypen entwickeln können, um dem Fachbereich die ersten Ergebnisse zu präsentieren. Dies ermöglicht Ihnen auch ein operatives Reporting auf den nahezu unveränderten Quelldaten. Ebenfalls damit verbunden sind Möglichkeiten zum schnellen Verifizieren der Datenqualität durch einen Abgleich mit dem Quellsystem. Das ist wichtig, denn ein häufiger Kritikpunkt an Data-Warehouse-Systemen ist mangelnde oder unzureichende Datenqualität. Insbesondere wenn Sie SAP S/4HANA im Einsatz haben, können Sie sehr schnell Abfragen gegen SAP BW/4HANA und SAP S/4HANA durchführen und die Datenqualität beurteilen. Im einfachsten Beispiel nutzen Sie dazu die SQL-Konsole in Eclipse, führen dort für das jeweilige System die SELECT-Abfrage aus und vergleichen die Ergebnisse.

Doch hat der feldbasierte Ansatz auch ein paar Nachteile, wie z.B. beim Erstellen von Unternehmensberichten. Im Query Designer, dem Tool zur Erzeugung von Queries für InfoProvider, können für Felder keine Variablen angelegt werden und die Felder müssen BW-kompatible Datentypen aufweisen. So scheiden Felder mit datenbankspezifischen Datentypen (z.B. String) als Feld in der Query aus. Diese Felder müssen nach wie vor InfoObjects zugeordnet werden. Für Felder, in denen Variablen zur Selektion der Datenmenge benötigt werden, müssen ebenfalls InfoObjects zugeordnet werden. Der nächste Nachteil liegt in der fehlenden bzw. erschwerten Harmonisierung der Quelldaten. Nur zu oft werden Felder in mehreren Tabellen wiederverwendet und erhalten unterschiedliche Bedeutungen. Oder andersherum: Es werden verschiedene Feldnamen in den Tabellen genutzt, die aber fachlich dasselbe meinen. Harmonisierungen auf Feldebene sind prinzipiell möglich, aber aufwendig. Für Datenharmonisierungen empfehlen sich InfoObjects. Ein weiterer Nachteil von Feldern sind fehlende Stammdaten. Im klassischen Business Warehouse können über InfoObjects zusätzliche Attribute (z.B. zugehörige Adressfelder des Kunden) und Texte (z.B. der volle Name des Kunden) als Stammdaten einfach im Bericht hinzugefügt werden. Dies ist bei Feldern nicht möglich, per se beinhalten Felder diese Information nicht. Für ein Berichtswesen, in dem diese zusätzlichen Stammdaten-Informationen gewünscht werden, müssten die Tabellen immer über einen SQL-JOIN mit den entsprechenden Text- oder Attributtabellen verknüpft werden. Das macht Datenmodelle mit der Zeit sehr unübersichtlich. Welche Vor- und Nachteile bietet im Gegensatz dazu der rein InfoObject-basierte Ansatz?

2.4 Ansatz mit InfoObjects

Wie eben gezeigt, birgt der Ansatz mit InfoObjects einige Vorteile, wie etwa bei der Harmonisierung der Quelldaten sowie für zusätzliche Informationen wie Attribute und Texte zu einem Objekt, wie der Kunde. InfoObjects dienten ursprünglich zur Modellierung von betriebswirtschaftlichen Objekten, wie Kunde, Material oder Buchungskreis. Mit früheren Versionen des Business Warehouse stellte das InfoObject zugleich die kleinste Modellierungseinheit dar. Bei der Übernahme einer Tabelle über einen Extraktor bzw. DataSource musste für jedes Feld ein InfoObject angelegt werden. Bei der Vielzahl an Projekten und Datenmodellen, die in einem Business Warehouse genutzt werden, stieg die Anzahl der InfoObjects schnell auf mehrere Tausend an. Gerade bei DataSources mit mehreren Hundert Feldern war es sehr müßig, für jedes Feld ein neues InfoObject anzulegen. Zudem ist der technische Name des InfoObjects auf 9 Zeichen beschränkt, sodass sehr schnell wenig sprechende technische Namen für InfoObjects angelegt wurden. InfoObjects wurden außerdem gerade in der Eingangsschicht mehrfach redundant angelegt, um spätestens bei den Business Transformations einheitlichen InfoObjects zugeordnet zu werden. Bei der Erstellung musste jedes Mal geprüft werden, ob das InfoObject Stammdaten und Texte oder keines von beiden besitzen sollte. InfoObjects mussten in jeder Schicht der inzwischen klassischen LSA-Architektur zwingend genutzt werden, was einen schnellen und effizienten Aufbau eines Datenmodells oft unmöglich machte. Die nicht eindeutige Verwendung von InfoObjects führte auf Fachseite zu Diskussionen hinsichtlich des passenden InfoObject. Zusätzlich mussten die Attribute und Texte vieler InfoObjects durch regelmäßige Ladeprozesse auf einem aktuellen Stand gehalten werden. Im täglichen Betrieb kam es hin und wieder zu Fehlbeladungen und es wurden Stammdaten erzeugt, die auf Fehler im Quellsystem zurückzuführen waren. Eine Bereinigung von stammdatentragenden InfoObjects ist eine sehr aufwendige Angelegenheit.

Sowohl der rein feldbasierte als auch der InfoObject-basierte Ansatz bergen gravierende Nachteile. Welchen Kompromiss kann es hier geben?

2.5 Mixed-Modeling-Ansatz

Eine weitere Option ist der sogenannte Mixed-Modeling-Ansatz. Dabei bestehen Felder und InfoObjects gleichberechtigt nebeneinander. Über sogenannte starke betriebswirtschaftliche Objekte, wie Kunde, Material oder Buchungskreis, und die notwendigen Attribute werden InfoObjects angelegt. Die Vielzahl von beschreibenden Feldern wird jedoch als Feld ins Business Warehouse übernommen und nicht durch ein InfoObject modelliert. Dieser Ansatz bietet mehrere Vorteile:

 Schnelles Prototyping: Es kann auf Feldebene ein schneller Prototyp für den Fachbereich erzeugt und z.B. über agile Methoden des Projektmanagements im Nachgang weiter verfeinert werden.

 Stammdatentragende InfoObjects: An der Stelle, an der stammdatentragende oder starke betriebswirtschaftliche Objekte im Datenmodell zwingend erforderlich sind, können InfoObjects genutzt werden.

 Vereinfachungen im Betrieb und in der Entwicklung: Die Vielzahl an Ladevorgängen kann deutlich reduziert werden, wenn nur noch starke Objekte verwendet werden und keine Vielzahl an sogenannten Stammdatenprozessketten täglich eingeplant ist. Dies führt insgesamt zu einer Reduktion im Support sowie einer Senkung des TCO. Auch für die Entwicklung bedeutet es eine Vereinfachung, da bei sehr großen DataSources mit mehreren Hundert Datenfeldern nicht mehr zwingend jedes Feld mit einem InfoObject modelliert werden muss.

Eine Einschränkung birgt dieser Ansatz allerdings: Es können in Feldern keine Variablen im Query Designer angelegt werden und die Felder müssen BW-kompatible Datentypen besitzen, um auch in Queries benutzt werden zu können. Dies trifft ebenso auf eingeschränkte Merkmale und Kennzahlen, Filter und Strukturen zu, was dazu führt, dass im Reporting doch sehr häufig InfoObjects genutzt werden müssen.

Dieser Ansatz kann auch bei der Lösung des Fallbeispiels verwendet werden. In Abbildung 2.3 sehen Sie eine grobe Architektur als mögliche Lösung.

Abbildung 2.3: Lösungsskizze

Zum Einbinden der verschiedenen Datenquellen aus CSV-Dateien nutzen Sie eine DataSource. Über die DataSource wird eine sogenannte Shielding InfoSource modelliert, die das Anbinden gleichartig strukturierter Daten aus verschiedenen Quellen ermöglicht. Die InfoSource besteht aus den Feldern der jeweiligen Quelltabelle. Für die Quelltabellen Netzbetreiber, Netze, PLZ Netze und Netznutzungsentgelt wird eine InfoSource angelegt. Aus den beiden erstgenannten InfoSources wird direkt in das jeweils zugehörige, gleichnamige Merkmal Netzbetreiber und Netze fortgeschrieben. Die Modellierung als InfoObject ermöglicht im CompositeProvider Stromkosten einen einfachen Zugriff auf die Attribute und Texte des Netzbetreibers. Über der InfoSource PLZ-Netze liegt ein aDSO vom Typ »schreiboptimiert« nach dem Mixed-Modeling-Ansatz in der Struktur der Quelltabelle. Über der InfoSource NNE liegt aus technischen Gründen ein Standard-aDSO. Die Felder aus dem aDSO PLZ-Netze werden schließlich in ein aDSO Stromkosten vom Typ Standard-aDSO fortgeschrieben. In der Transformation zwischen dem aDSO PLZ Netze und dem aDSO Stromkosten werden aus dem aDSO Netznutzungsentgelt per Regeltyp Nachlesen aus aDSO die Kennzahlen für den Grund- und Arbeitspreis zur Netznummer nachgelesen. Zusätzlich wird aus den Stammdaten des InfoObjects Netze der Netzbetreiber per Regeltyp Stammdaten lesen nachgelesen. Das aDSO Stromkosten enthält dabei alle für das Reporting benötigten Merkmale und Kennzahlen. Es wird dann per Union als PartProvider in den CompositeProvider eingebunden. Über das Mapping können die Felder für den Ergebnisbericht genutzt werden.

Doch bevor es an die konkrete Modellierung geht, folgt im nächsten Kapitel ein Kurzüberblick über Eclipse und die BW Modeling Tools in Eclipse.

3 Arbeiten mit Eclipse

In diesem Kapitel stelle ich Ihnen die Modeling Tools for SAP BW/4HANA and SAP BW powered by SAP HANA, kurz MT-BW, vor. Dabei handelt es sich um die neue Benutzeroberfläche als Alternative zur SAP GUI, mit der Sie sämtliche Konfigurations- und Modellierungsaufgaben innerhalb von SAP BW durchführen können.

3.1 Überblick und erster Einstieg

Mit den Modeling Tools for SAP BW/4HANA and SAP BW powered by SAP HANA (MT-BW) beginnt ein neues Zeitalter für die Anwendungsentwicklung und das Customizing im Business Warehouse. Mit ihnen können Sie alle BW-relevanten Transaktionen innerhalb von Eclipse aufrufen und ausführen. Sie sind als Eclipse-Plug-in verfügbar und weisen damit ebenfalls eine eigene Perspektive in Eclipse auf. Eine Perspektive in Eclipse bestimmt die darstellbaren Aktionen, Sichten auf einzelne Objekte und das Layout innerhalb des Arbeitsbereichs. Für SAP-HANA-basierte Anwendungen dient Eclipse als zentrales, integriertes Entwicklungstool für alle Aufgaben. Die Modellierung eines BW-Datenflusses mit allen beteiligten InfoProvidern sowie des Aufgabenbereichs für Extraktion, Transformation und Laden kann mit den BW-MT in Eclipse erfolgen und anschließend auf dem BW-Server gespeichert werden. Damit besteht für reine BW-Modellierungen nicht mehr die Notwendigkeit, auf SAP GUI zurückzugreifen. In bestimmten Fällen, wie etwa einer Web-Dynpro-Entwicklung, muss jedoch abhängig vom eingesetzten Releasestand der Modeling Tools for BW für einige Transaktionen SAP GUI aufgerufen werden. Starten Sie Eclipse auf Ihrem Desktop. Beim erstmaligen Aufruf werden Sie nach einem Arbeitsverzeichnis gefragt, in dem Sie Ihre Projekte ablegen, wie in Abbildung 3.1.

Abbildung 3.1: SAP HANA Studio Launcher

Setzen Sie das Kennzeichen Use this as the default and do not ask again. Dadurch verhindern Sie, dass Eclipse Sie bei jedem Start nach Ihrem Workspace fragt. Sie können durchaus mehrere definieren und zwischen den Arbeitsverzeichnissen hin- und herwechseln. Dies nutzen Sie z.B., um Ihre Drei-Stufen-Architektur abzubilden. Legen Sie hierzu je einen Workspace für Ihre Entwicklungs-, Konsolidierungs- und Produktivsysteme an.

Geben Sie in wie in Abbildung 3.1 Ihren Ordner an, in dem Sie die Projekte ablegen möchten. Hier im Beispiel wird unterhalb der Dokumente des aktuellen Windows-Benutzers ein neues Verzeichnis Projekte angelegt. Sie benötigen je System mindestens ein Projekt. Für eine Drei-System-Landschaft mit einem Entwicklungs-, Test- und Produktionssystem müssen Sie also mindestens drei Projekte erstellen. Dazu komme ich gleich. Nach dieser Eingabe gelangen Sie auf den Startbildschirm von Eclipse, beim ersten Aufruf mit einer Begrüßungsseite, wie in Abbildung 3.2 gezeigt.

Hier finden Sie im Menü unter File • Workspace die eben angesprochene Möglichkeit, zwischen verschiedenen Workspaces hin- und herzuwechseln.

Zuerst müssen Sie jetzt die BW Modeling Tools aktivieren.

Klicken Sie im Menü der Startseite auf Window • Perspective • Open Perspective • Other … Es wird das Menü aus Abbildung 3.3 angezeigt.

Abbildung 3.2: Eclipse-Startmenü

Abbildung 3.3: BW-Modeling-Perspektive

Wählen Sie BW Modeling aus und bestätigen Sie Ihre Wahl mit Open.

Im Menüband unterhalb des Menüpunkts File wird ein neues Icon für BW Modeling eingeblendet (siehe umrahmtes Icon in Abbildung 3.4).

Abbildung 3.4: Aktive BW Modeling Tools

Wenn dieses Icon bei Ihnen sichtbar ist, haben Sie die Tools aktiviert.

Klicken Sie als Nächstes auf das Icon für BW Modeling (siehe Abbildung 3.4) und verschaffen Sie sich einen Überblick über die in dieser Perspektive verfügbaren Views, indem Sie sich diese über den Menüpfad Window • Show View • Other … (siehe Abbildung 3.5) anzeigen lassen.

Abbildung 3.5: Verfügbare Views in BW-Modeling-Perspektive

Die folgenden Views stehen Ihnen zur Auswahl:

 Admin Page for Document Store – Hier gelangen Sie zur Dokumentenablage, in der Sie zu Ihren modellierten Objekten beliebige Dokumente hinterlegen können.

 BW Job View – Hierüber öffnen Sie die Jobübersicht auf dem BW-Server.

 BW Reporting Preview – So starten Sie eine neue View zur Anzeige von Queryergebnissen in Eclipse.

 Data Preview for DataSource – Hier können Sie sich die Daten der ausgewählten DataSource in einer Vorschau anzeigen lassen.

 InfoProvider – Mit dieser View können Sie alle benötigten InfoProvider anlegen, bearbeiten und löschen.

 Linked Components – Hier gelangen Sie zu einer Übersicht der miteinander verknüpften Objekte.

 Monitor View – Dieser Menüpunkt führt Sie zu einer Monitoransicht für geladene Requests im ausgewählten bzw. aktiven InfoProvider.

 Planning View – Rufen Sie hier den Planungsmodus auf, wie Sie ihn vielleicht vom SAP-NetWeaver-basierten Plan mit der Transaktion RSPLAN kennen.

Um mit den verschiedenen Views arbeiten zu können, benötigen Sie jedoch zuerst ein Projekt.

Projekte in der IDE

Ein Projekt ist die logische Zuordnung Ihrer BW-Objekte, wie InfoProvider, Tabellen, aber auch Queries, zum verbundenen BW-System. Sie können mehrere Projekte innerhalb Ihres Workspace anlegen.

Im nächsten Abschnitt zeige ich Ihnen, wie Sie ein BW-Projekt anlegen.

3.2 Anlegen eines BW-Projekts

Beenden Sie zunächst den Überblick über die vorhandenen Views, indem Sie auf Cancel klicken.

Sie befinden sich nun wieder auf der Eclipse-Startseite (vgl. Abbildung 3.2).

Im Befehlsmenü wählen Sie File • New • BW Project. Das Konfigurationsfenster wird angezeigt.

In diesem Fenster wählen Sie die in der SAP GUI hinterlegten Verbindungen aus oder stellen eine neue Verbindung zu einem SAP-BW-Server her. Zur Neuerstellung einer Verbindung klicken Sie auf den Link new system connection. Bestimmen Sie hier das SAP-BW-System, für das Sie ein Projekt anlegen möchten. Wählen Sie anschließend Next >.

Verbindungen nicht verfügbar

Wenn die in der SAP GUI hinterlegten Systeme nicht als Verbindung in Eclipse angezeigt werden, starten Sie SAP GUI und melden sich am BW-System an. Schließen Sie Eclipse und starten Sie es neu. Legen Sie ein neues BW-Projekt an. Das BW-System, zu dem Sie eine Verbindung herstellen möchten, ist nun in der Liste der verfügbaren Systeme enthalten.

Im nächsten Fenster werden die detaillierten Verbindungsinformationen zu Ihrem System angezeigt. Wählen Sie anschließend den Button Next >. Sie gelangen auf das Anmeldebild, auf dem Sie sich mit Ihrem Benutzer/Passwort am BW-System anmelden. Das Anmeldebild ist in Abbildung 3.6 zu sehen.

Abbildung 3.6: Anmeldebild

Im nächsten sich öffnenden Fenster (siehe Abbildung 3.7) fordert das System den Benutzer auf, im Feld Project Name einen Projektnamen einzugeben. Tragen Sie hier Fallbeispiel ein.

Abbildung 3.7: Projekt »Fallbeispiel«

Eingabe des Projektnamens

Geben Sie den Namen ohne Leer- und andere Sonderzeichen ein. Falls Sie dennoch aus Versehen Leer- oder Sonderzeichen verwenden, erscheint eine entsprechende Meldung, dass der Projektname dieses Sonderzeichen nicht enthalten darf. Als gültige Zeichen sind nur Buchstaben, Zahlen, Binde- und der Unterstrich erlaubt. Das erste Zeichen muss ein Buchstabe sein.

Sie fügen weitere Projekte hinzu, indem Sie das Kennzeichen Add projects to working sets setzen. Dies ist an dieser Stelle jedoch nicht nötig, wählen Sie daher wieder Next >. Im nächsten Fenster fragt das System ab, ob Sie dem Projekt ein weiteres SAP-HANA-System hinzufügen möchten.

Das ist an dieser Stelle nicht notwendig, deshalb ist die Konfiguration des ersten BW-Projekts abgeschlossen. Klicken Sie auf den Button Finish.

In der View Project Explorer wird daraufhin das neu angelegte Projekt angezeigt (siehe Abbildung 3.8).

Abbildung 3.8: Project Explorer

Wie Sie sehen, weist der Project Explorer zusätzlich zum eigentlichen Projektnamen den technischen Namen mit Mandant, Benutzername und Sprache des verbundenen SAP-Systems in Klammern aus.

Zuordnung BW-System zu Projekt

Ein BW-Projekt innerhalb der BW Modeling Tools ist immer eindeutig einem SAP-System mit Mandanten und Benutzer zugeordnet. Sie müssen also für verschiedene Mandanten im Quellsystem immer ein eigenes Projekt erstellen.

Das Projekt meldet sich stets mit dem hinterlegten Benutzer am System an. Eine Änderung des Benutzers ist nicht möglich, dazu müssen Sie ein neues Projekt anlegen.

3.3 Navigieren im Project Explorer

Öffnen Sie das Projekt, indem Sie zum Expandieren des Knotens auf das Sypmbol + neben dem Projekt Fallbeispiel klicken. Daraufhin sehen Sie neue Ordner: Favorites, BW Repository und Data Sources.

Unter Favorites befinden sich Ihre Favoriten, die Sie in Ihrem SAP-BW-System angelegt haben. Uns interessieren vorerst nur die Objekte im Ordner BW Repository, der unter dem Oberbegriff alle InfoAreas sammelt, die InfoProvider enthalten. Klappen Sie diesen Ordner auf, indem Sie auf das Symbol + neben dem Ordner BW Repository klicken. In Abbildung 3.9 sehen Sie eine Übersicht über die vorhandenen InfoAreas mit ihren InfoProvidern.

Abbildung 3.9: Projektübersicht im Project Explorer

3.4 SAP-GUI-Transaktionen aufrufen

Innerhalb von Eclipse können Sie beliebige Transaktionen aufrufen. Wählen Sie hierfür im Menü das Icon zum Öffnen von SAP GUI (siehe markiertes Icon in Abbildung 3.10).

Abbildung 3.10: SAP GUI aufrufen

Alternativ können Sie SAP GUI auch über die Tastenkombination Strg + F6 starten. Öffnen Sie über den Button jetzt die Data Warehouse Workbench (Transaktion RSA1).

Zunächst gelangen Sie jedoch in den SAP GUI Launcher (siehe Abbildung 3.11).

Abbildung 3.11: SAP GUI Launcher

Hier legen Sie fest, in welchem Eclipse-Projekt Sie die entsprechende SAP-GUI-Transaktion ausführen möchten. Voreingestellt ist das aktuelle Projekt. Lassen Sie das Kennzeichen Navigate to editor in Eclipse for supported development objects gesetzt. Es bestimmt, dass Transaktionen in Eclipse geöffnet werden, sofern diese eine Ausführung in Eclipse unterstützen. Wenn Eclipse eine Transaktion nicht unterstützt, wird sie direkt in SAP GUI geöffnet. Bestätigen Sie den SAP GUI Launcher mit OK. In Eclipse öffnet sich eine weitere Registerkarte (siehe Abbildung 3.12).

Abbildung 3.12: SAP GUI in Eclipse

Ebenso erfolgt der Absprung direkt in SAP GUI, wenn Sie in der SAP-Befehlszeile eine Transaktion eingeben, wie etwa RSA1 für den Aufruf der Data Warehouse Workbench.

Geben Sie hier in der Befehlszeile RSA1 ein (siehe Abbildung 3.12). Sie gelangen sofort in die neue Data Warehouse Workbench mit reduziertem Funktionsumfang (siehe Abbildung 3.13).

Abbildung 3.13: »RSA1« in Eclipse

Wie Sie bemerken, fehlt im Gegensatz zu SAP-NetWeaver-basierten BW-Systemen die Datenmodellierung aus dem Funktionsbereich links im Bild. Als erster Punkt ist hier Administration mit der Funktion Process Chains (Prozessketten) gelistet.

Die Beschränkung auf fünf parallele Modi, wie Sie dies von SAP GUI kennen, entfällt. Innerhalb von Eclipse können Sie beliebig viele Transaktionen gleichzeitig öffnen und damit auch mühelos zwischen einzelnen Transaktionen hin- und herschalten. Machen Sie sich mit den BW Modeling Tools in Eclipse vertraut und öffnen Sie beispielsweise weitere Ihnen bekannte BW-Transaktionen.

Damit möchte ich meinen Überblick über die BW Modeling Tools in Eclipse beenden.