Daten per OData Interface liefern–Teil 1
Das OpenData Protokoll hat sich in der IT-Industrie quasi zum Standard für Webschnittstellen entwickelt. Auch hier in codefest findet OData ausreichend Erwähnung. In diesem Beispiel geht es darum, selbst ein OData Interface zu entwickeln und zu konsumieren.
Ich hatte vor kurzem eine Anforderung zur Weitergabe von Daten und die Nutzung von OData über eine WebAPI Schnittstelle war der schnellste und einfachste Weg.
In diesem Artikel möchte ich zeigen, wie einfach – und sogar ohne Programmieren – die Weitergabe von Daten per Entity Framework und mit einem OData Interface ist. Visual Studio erledigt die ganze Arbeit.
Die Anforderung
Daten sollen zentral vorhanden sein und in weitere Folge in PowerBI und in einer SharePoint App konsumiert werden. Die Daten müssen nur gelesen werden, es geht um Auswertungen und Visualisierung der konsolidierten Tabellen.
Die folgende Grafik zeigt den geplanten Flow.
Die Datenquelle
Die Daten liegen in einer lokalen SQL Datenbank vor. Die Daten stammen übrigens von einer Veranstaltung mit Vorträgen (Session) und Bewertungen (Ratings).
Wir lassen die Konsolidierungsarbeit den SQL Server erledigen und erstellen zwei Views, welche die Daten bereits in der Form liefern, wie wir sie benötigen. Die erste View verknüpft drei Tabellen zu einer Ausgabe.
Pro Session gibt es n Zeilen mit einem Rating. Damit wir die Daten gleich im richtigen Format erhalten, baut eine zweite View “vwRatingAverage” auf der ersten auf und gruppiert die Sessions.
Die Ausgabe sieht dann so aus: Pro Session eine Zeile mit Anzahl der Feedbacks und drei Spalten mit den Durchschnittsbewertungen und einer Spalte AvgTotal mit dem Durchschnitt aus den drei Einzelwerten.
Die Session mit ID 1153 hatte also 49 Feedbacks und die Gesamtbewertung von 4.0.
(Die Bewertungen bestehen übrigens aus einer Skala von 1 bis 5, wobei 5 die beste Bewertung darstellt).
Daten zentral erreichbar machen
Damit die Datenbank von Außen (von überall) erreichbar sind, wird die Datenbank nach SQL Azure transportiert. Dies kann mit dem SQL Management Studio erfolgen, wie hier abgebildet – sofern die Datenbank “Azure-konform” ist. Das bedeutet, dass nicht unterstützte Objekte (wie etwa Datenbankdiagramme) und Funktionen aus der SQL Datenbank entfernt werden müssen.
Sollte das Deployment nach Azure Probleme bereiten, kann der SQL Database Migration Wizard helfen.
Am besten ist, danach gleich mit dem Connectionstring und dem SQL Management Studio die Verbindung zum Client zu testen.
Ein neues WebAPI Projekt
Wenn die Datenbank in SQL Azure verfügbar ist – die Firewallregel im SQL Server für die eigene IP-Adresse nicht vergessen – können wir die Daten konsumieren. Hierzu wird ein neues WebAPI Projekt in Visual Studio angelegt. Falls noch etwa für Verwaltungszwecke ein Website hinzugefügt werden soll, belässt man das MVC Template zusätzlich.
Wenn das Projekt erstellt ist geht es mit dem Hinzufügen der Daten weiter.
Entity Framework hinzufügen
Nun wird ein neuer Folder “Data” erstellt und hier drin mit Add / Class und dem Wizard…
…ein ADO.NET Entity Data Model mit Namen “DBModel” hinzugefügt.
Nun wird der Wizard durchgegangen und das Model durch Verbinden mit der SQL Azure Datenbank erzeugt. Zunächst wird der “EF Designer from database” gewählt.
Danach folgt der ConnectionString mit Angabe der Credentials und der Datenbank.
Nun kann das neue Model erstellt werden. Wenn alles geklappt hat, sieht es (in meinem Beispiel) dann mit allen Tabellen und den beiden Views wie folgt aus.
Der Wizard hat die Referenzen zum EntityFramework erstellt und die entsprechenden Einträge in web.config durchgeführt.
Die Daten können nun im Code verwendet werden. Der Weg bis hier war ganz ohne Programmierung, Visual Studio hat die erforderlichen Klassen und Methoden generiert.
OData hinzufügen
Jetzt muss eigentlich nur mehr die OData Schnittstelle gebaut werden. Diese Arbeit kann uns ebenfalls Visual Studio abnehmen. Es wird ein neuer Controller hinzugefügt.
Bei der Frage nach der Art des Controllers (“Scaffolding”) wählen wir hier einfach “Web API 2 OData v3 Controller with actions, using Entity Framework”.
…und wählen ein Model (hier die View vwRatingAverage) aus – und vergeben einen Namen für den neuen Controller.
Der Wizard generiert dann sogleich den Code für die wichtigsten OData Methoden.
Es sind nur noch einige Bibliotheken und die Routen in App_Start / WebApiConfig.cs einzutragen. Diese stehen gleich am Beginn des generierten Files und müssen nur in das Ziel-File hinzugefügt werden.
Das wars’ – wieder ganz ohne Programmieren. Wenn man sich die Methoden des OData Controllers öffnet, sieht man, was generiert wurde: Die Daten können gesendet, geändert und per ID geliefert und gelöscht werden.
Cool, oder?
Ausprobieren
Das Projekt kann nun bereits gestartet werden. Die Startseite wurde bislang nicht umgestellt, also muss noch der Pfad zum OData Controller in der URL hinzugefügt werden: /odata/RatingAverages.
Wenn alles klappt, folgt die Darstellung der Daten (der View aus SQL Azure) im OData-Format, wie hier.
Die Schnittstelle funktioniert. Jede Änderung an den Daten in der SQL Datenbank ist sofort hier abrufbar.
Diese Website kann nun in eine Azure Website ge-publisht werden und steht somit ebenso zentral im Web zur Verfügung.
In Teil 2 sehen wir uns die weitere Konsumentation der Daten aus unserem OData Interface an.