Ja, ich weiß, SAP hat Lumira, und das ist mindestens genauso toll wie Power BI, da braucht man das überhaupt nicht mehr *hüstel*… Aber falls man doch aus irgendeinem Grunde seine Zahlen aus SAP BW (oder Hana) in Power BI auswerten will (vielleicht will man sie ja mit eigenen Daten aus anderen Quellen verbinden), dann will ich kurz beschreiben, wie das grundsätzlich funktioniert.
Wenn man versucht, auf SAP BW als Datenquelle zuzugreifen, wird man unsanft daran erinnert, dass noch eine weitere Komponente auf dem Rechner installiert sein muss, mit dem man den Power BI Desktop zu laufen hat, und zwar die SAP NetWeaver Library!
An dieser Stelle könnte der Test auch schon enden, denn diese Library erhält man in der Regel nur dann, wenn auch die SAP-GUI auf dem Computer installiert ist. Es ist aber nicht unmöglich, sie im SAP Software Download Center auch einzeln zu finden, siehe https://support.sap.com/swdc!
Dann noch ein böser Fallstrick: Power BI muss in der Version installiert sein, 32 oder 64-bit, in der auch diese Library vorliegt. Auf den meisten Clients wird man nur den 32-bit SAP-Client installiert haben, also empfiehlt sich ausnahmsweise mal ein 32-bit-Power BI, obwohl man damit natürlich ganz andere Grenzen bei der Nutzung des Hauptspeichers hat!
Hat man also die Library in der richtigen Version, dann erscheint unter Get Data / Database / SAP Business Warehouse Application Server folgendes Fenster:

Die “System number” entspricht der “Instance” von SAP. Hat man diese Hürde genommen, erscheint das Anmeldefenster:

SAP BW Anmeldefenster in Power BI Desktop

…und mit einem Klick auf “Connect” ist man sofort drauf und sieht eine Liste der vorhandenen Objekte zur Auswahl:

…alles natürlich ordentlich auf Deutsch benannt, weil wir uns als Sprache weiter oben DE gewünscht haben!
Interessant ist das Fenster rechts oben, denn wir laden uns ja bei der Zugriffsform “Import” jeweils die Daten nach Power BI herunter, was natürlich eine ganze Menge werden kann. Wenn ich aber z.B. dort oben im Fenster die Dimension “Sparte” anwähle, kann ich dort alle anderen Exporte z.B. auf die Sparte “High Tech” einschränken, etwa so:

Häufig gebraucht wäre auch eine Einschränkung nach Zeit, und das ist ebenfalls möglich, wie hier:

Was die Ausgabe angeht, sollte man sich aus jeder Dimension einfach mal die benötigten “Properties” heraussuchen, so z.B. beim Datum Kalendermonat (Schlüssel) und Kalenderjahr (Schlüssel). Allerdings funktioniert dies nicht bei allen Dimensionen, aber zu mindestens die Dimension mit dem Anhang “Stufe 01”, die für jede Dimension des Cubes angezeigt wird, ist auswählbar.
Ein besonderes Schmankerl verbirgt sich unter den “Display Options” oben rechts im Navigator-Fenster: dort kann man einstellen, ob man die nutzerfreundlichen Namen oder zusätzlich die technischen Namen der SAP-Objekte sehen möchte, das sieht dann so aus:

Die oben rechts eingestellte “Einschränkung” funktioniert übrigens erst beim eigentlichen Laden der Daten, in der Vorschau sind die eingeschränkten Zeilen noch enthalten.
Hier sieht man die Vorschau im Power BI-Fenster. Sehr praktisch ist, dass man, wenn man noch ein Measure oder ein Attribut vergessen hat, dies unter “Add Items” grafisch hinzufügen kann:

Allerdings gilt auch hier, dass bestimmte Attribute einer Dimension oft einfach nicht ausgegeben werden, die Spalte wird ohne Fehlermeldung dem Ergebnis nicht hinzugefügt. Probieren Sie es ruhig im Einzelfall aus, denn viele Spalten lassen sich hier hinzufügen, die in der Quellabfrage noch nicht erschienen sind!
Die Spaltennamen sind dann zum Teil ziemlich seltsam bzw. so, wie sie aus dem System geliefert werden. Aber das lässt sich ja in Power BI alles gut umbenennen!
Da wir uns vom Kalendermonat sowohl den Namen als auch den Schlüssel geholt haben, können wir die Anzeige ganz leicht dynamisieren. Die ersten drei Zeichen der Monatsbezeichnung enthalten ja den Namen des individuellen Monats, z.B. “JAN 2004”. Wir können uns diesen Teil mit DAX herausschneiden, in einer neuen Spalte:

Monatsname = LEFT('Auftrags-, Liefer- und Umsatzmengen'[Monat]; 3)

Und dann können wir bei dieser Spalte unter Modeling / Sort by Column einstellen, dass sie numerisch nach dem Monatsschlüssel sortiert wird, nicht alphabetisch.
Wer Power BI kennt, weiß, dass eine Datumsspalte sehr sinnvoll ist, schon, damit Power BI daran seine eigene automatische “Zeitlogik” aufhängen kann. Wir können uns diese ganz einfach per DAX berechnen lassen, in der englischen Version liebt er das Format “M/d/yyyy”:

Datum = 'Auftrags-, Liefer- und Umsatzmengen'[Monatsschlüssel] & "/1/" & 'Auftrags-, Liefer- und Umsatzmengen'[Jahr]

Bei einer solchen neuen Spalte lässt sich der Datentyp dann ganz leicht auf “Datum” ändern.
Und dann kann man sich ganz leicht so schicke Auswertungen bauen, wie man sie von Power BI eben kennt, animiert und interaktiv:

Der Nachteil dabei ist natürlich, dass alle Daten des Cubes, auf die unterste Detailebene heruntergebrochen, in eine einzige Tabelle geworfen werden, mit vielen, vielen Spalten. Die schöne, dimensionale Struktur geht dabei verloren, und auch die teilweise komplexen Hierarchien!
Auf der anderen Seite bleibt beim “Import”-Zugriff auf SAP BW der große Vorteil des “Mashups” erhalten, d.h. ich kann die Daten aus der SAP BW-“Tabelle” mit Daten aus beliebigen anderen Datenquellen verknüpfen, wenn Power BI diese lesen kann und es irgendeine Verweis-Spalte gibt, über die diese Verknüpfung funktioniert. Das löst das typische Problem, dass es z.B. immer wieder in der Praxis total relevante Attribute etwa von Materialien oder von Auftraggebern gibt, die in SAP nicht gepflegt werden! Die könnte man nun z.B. in einer Excel-Datei editieren und dann beides dynamisch in der Grafik verknüpfen.
Alternativ zum Import gibt es natürlich auch den Zugriff über DirectQuery! Anfang 2018 ist das noch im beta-Status, aber die Vorteile liegen auf der Hand: bei DirectQuery bleiben alle Daten im SAP BW, und Power BI startet nur dynamisch Anfragen gegen die SAP-Cubes und zeigt die Ergebnisse wie gehabt an. Hier sieht man beim Erstellen der Abfrage, welche Dimensionen und Measures es gibt, etwa so:

Nachteil ist aber, dass nicht alle Eigenschaften der Dimensionselemente zur Verfügung stehen (so gibt es z.B. nicht den Längengrad und Breitengrad des Auftraggebers), und nervig ist auch die recht lange Abfrage-Laufzeit von BW im (unfairen) Vergleich mit den lokal gepufferten Daten in Power BI. Mashups, also das Verbinden mit lokal gepflegten Daten, funktionieren im Direct Query-Modus derzeit (noch) nicht. Auch kann man nur einfachste lokale Berechnungen erstellen (“Neues Measure”), und z.B. keine neuen, mit DAX berechneten Spalten definieren, wie im Import-Modus.

Fazit: der Zugriff auf SAP BW über Power BI funktioniert ziemlich gut, im Großen und Ganzen. Es gibt noch Nickeligkeiten bei einzelnen Funktionalitäten, aber dank “evergreening” werden diese Fehler sicher in einer der nächsten monatlichen Updates von Power BI Desktop beseitigt sein.

Na dann: happy self servicing!