Kitabı oku: «Praxishandbuch SAP Business Warehouse mit BW/4HANA», sayfa 3
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.
Ücretsiz ön izlemeyi tamamladınız.
