Daten per OData Interface konsumieren–Teil 2

In Teil zwei geht es darum, die WebAPI Schnittstelle aus “Daten per OData Interface liefern–Teil 1” zu benutzen. Zur Erinnerung, wir hatten ein ASP.NET MVC/WebAPI Projekt mit dem Entity Framework und dem Scaffolding Wizard mit einer OData v3 Schnittstelle zusammengebaut, welche Daten im OData Format liefert.

Interface nach Azure WebApps deployen

Voraussetzung für die Nutzung in meinem Beispiel in weiterer Folge ist, dass die OData Schnittstelle – sprich das Webprojekt – als Azure Website, pardon, als Azure Web App, wie der neue Name lautet, läuft und von überall erreichbar ist. Auch SQL Azure könnte die Daten direkt liefern, jedoch muss dafür die SQL Server Firewall den Client und dessen IP kennen und durchlassen. Ein eigenes Interface macht also fast immer Sinn, abgesehen davon, dass dieses natürlich beliebig anpassbar ist, dazu später mehr.

Das Webprojekt wurde also in eine Azure Web App deployt (Howto siehe hier) und steht über die URL .azurewebsites.net/odata/RatingAverages">.azurewebsites.net/odata/RatingAverages">https://<appname>.azurewebsites.net/odata/RatingAverages bereit.

Power…was?

Daten in Textform sind die Basis. Anwender benötigen diese aber natürlich in visuell hübsch aufbereiteter Form. Als Entwickler gibt es nun viele Methoden, das umzusetzen.

Eine Variante wäre etwa ein Webinterface (wir haben ja ASP.NET MVC ins Projekt integriert) und etwa eine Javascript-Bibliothek für die Darstellung zu verwenden. Javascript-Bibliotheken für Visualisierungen gibt es reichlich, einige Ideen hierfür wären etwa morris.js, jChartFXGallery, jquery plugins for html5 canvas oder jster.net, um nur einige zu nennen.

Und dann gibt es auch Anwender, die sich Auswertungen gerne selbst nach ihren eigenen Bedürfnissen zusammenstellen. Das klappt etwa mit Microsoft Excel oder PowerBI. Diese Varianten haben den Vorteil, dass sie nicht selbst entwickelt werden müssen und von Power-Usern bevorzugt werden. Die Datenlieferung per OData haben wir ja bereits umgesetzt und somit die Voraussetzungen dafür.

In diesem Teil 2 verlassen wir die Developer-Schiene, um dieses Mal etwas über den gewohnten Tellerrand zu blicken und uns die Möglichkeiten der Datenanalyse mit dafür gebauten Systemen anzusehen. In Teil 3 wird es dann wieder Developer-lastiger…

Variante 1: OData in Excel weiterverwenden

Sehen wir uns die Nicht-Programmierung-Lösung Nummer eins an: Microsoft Excel.

Dies funktioniert mit unserer OData v3 Schnittstelle out-of-the-box. Ein rascher Hinweis: Excel unterstützt derzeit OData v4 NICHT, daher habe ich auch in Teil 1 den Scaffolding Wizard für OData v3 benutzt, der klappt.

Wie funktionierts? Nun, ganz einfach:
In ein Datasheet wird über das Menü Data / From Other Sources / From OData Data Feed ausgewählt…

…und die Adresse des OData Datafeeds angegeben. Der Scaffolding Wizard hat auch ein Interface für die Abfrage der Feeds angelegt und wir können einfach das Routing für die Webadresse/odata/ angeben.

/oadata liefert uns eine Get-Schnittstelle, nämlich unsere implementierte Methode für die den Controller RantingAverages. Hier können wir nun die gewünschte Schnittstelle auswählen, bei uns gibt es nur eine:

Und der letzte Schritt: Optionen zum Speichern der Datenquelle. Diese belassen wir mit den Vorgaben, ganz nach dem Motto: Next, Next, Finish.

Die Daten werden einfach nach $A$1 in das aktuelle Blatt “importiert”.

Das Ergebnis wird aus dem Datenschema ausgelesen und in Excel eingefügt – in Wahrheit werden die Daten nun abgefragt und verknüpft.

Das ist auch der Clou an dieser Lösung: Eine Änderung an den Daten in der SQL Azure Datenbank schlägt sofort “durch” und die Excel-Tabelle holt sich beim Klick auf den Refreh-Button die Daten erneut von der Schnittstelle.

In meinem Szenario würde der proof-of-concept zum Beispiel so aussehen: In SQL Azure wird eine bestimmte Session mit neuen Daten aktualisiert:

UPDATE [Session] SET [Speaker] = 'Toni Pohl', [SessionTitle] = 'Awesome Session'  WHERE ID = 1153

Nun in Excel Refresh anklicken – und voila: Die Änderungen sind sofort sichtbar.

Coole Sache. Daten können auf diesem Weg einfach aktualisiert werden. Dieser Vorgang ist für den Endanwender einfach nachvollziehbar und die aktuellsten Daten können im “self-service” abgerufen werden.

Nun kann mit den Daten weitergearbeitet werden, etwa eine Pivot-Tabelle erstellt werden und so weiter.

Power-User werden euch dafür lieben…

Variante 2: Power BI

Für viele noch ein ganz unbekanntes Blatt ist PowerBI – nun in Version zwei. In Version Eins war PowerBI in Office 365 in einem eigenen SharePoint-Portal integriert. Das gibt es nun nicht mehr, sondern stattdessen das neue Power-BI Portal unter der allgemeinen Adresse https://powerbi.microsoft.com/ .

Die Idee: PowerBI liest Daten aus einer Datenquelle (Dataset), lässt den Anwender diese in verschiedensten Varianten verknüpfen und ansprechend ausgeben (Reports). Zusammengefasst werden die Reports in Übersichten (Dashboards).

Die Registrierung kann mit einem Microsoft Account oder einem Org-Account (AAD Konto) erfolgen. Bei Verwendung eines Office 365 Kontos und einer Lizenz, erscheint PowerBI auch im AppLauncher. Praktisch.

Die Basis-Infos sind unter Microsoft Power BI Support nachzulesen, die ersten Schritte sind hier beschrieben.
Sehr spannend finde ich u.a., dass Daten aus verschiedenen Fremdsystemen wie etwa Microsoft Dynamics, Google Analytics, Salesforce, SendGrid, Visual Studio Online, Webtrends, Zendesk, usw. weiterverwendet werden können. Die folgende Grafik zeigt einige der möglichen Dienste für die Datenlieferung. Damit lassen sich schon interessante Visualisierungen durchführen.

Der einfachste Weg ist, das eigene Excel-File (aus Variante 1) upzuloaden. Alternativ können auch bereits upgeloadete Daten aus OneDrive verwendet werden. Nun funktioniert das Erstellen der Reports ähnlich wie beim Pivotieren in Excel: Durch Markieren der gewünschten Spalten und Auswahl der Darstellungsart.

Die Formatierungsmöglichkeiten sind aus meiner Sicht – im Vergleich zu Excel – noch sehr beschränkt, aber die Lösung wird sich voraussichtlich rasch weiterentwickeln. Ein Vorteil von PowerBI ist natürlich das Weitergeben der Ergebnisse.

Weitere Datasets können auch aus diesen Quellen bezogen werden – wir könnten also auch direkt gegen unsere SQL Azure Datenbank aus Teil 1 gehen… (es sind nur die Connection-Daten Serveradresse, Datenbank und User Credentials erforderlich und los gehts).

Weitere Möglichkeiten bietet die Power BI Desktop-Version. Diese kann aus dem Webportal rechts oben mit dem kleinen Download-Pfeil heruntergeladen werden – wie auch Power BI for Mobile, der Analysis Services-Connector und das Power BI Personal Gateway.

Sobald diese installiert ist, kann hier etwa wieder unser ODatafeed verwendet werden.

Die Daten werden dann geladen und analysiert…

…und können nun wieder visualisiert werden.

Schön ist auch, dass Reports ge-share-d werden können (Publish) und so anderen Benutzern über das Web bereitgestellt werden können.

Power BI für Entwickler

Für Entwickler gibt es eine API – derzeit als Beta. Das Power BI Developer Center liefert die Dokumentation hierzu, im Power BI Developer Blog findet ihr Artikel zur Verwendung.  

Die Authentifizierung erfolgt natürlich über OAuth2, der API Endpoint lautet derzeit https://api.powerbi.com/beta/myorg/datasets/… mal ansehen und testen.

PowerBI bietet eine Fülle an Möglichkeiten. Für alle jene, die sich weiter über die Funktionalität informieren möchten, stehen hier einige Videos bereit – und natürlich die Spielwiese, PowerBI einmal selbst auszuprobieren. Ich selbst habe auch erst ein wenig in PowerBI hineingeschaut, ich bin sicher, es gibt hier noch viel zu entdecken.

Nach diesem kurzen Exkurs werden wir in Teil 3 unsere OData Schnittstelle in einer SharePoint App weiterverwenden und selbst visualisieren.

Viel Spaß beim Experimentieren!