Integrieren von SQL Azure in SharePoint 2010 und Windows Azure
Integrieren von SQL Azure in SharePoint 2010 und Windows Azure
Dieser Beitrag ist eine nützliche Ergänzung zu meiner fünfteiligen Serie zum CASI Kit (Claims, Azure and SharePoint Integration, Integration von Forderungen, Azure und SharePoint).
· Teil 1: Eine Einführung in das gesamte Framework und die Lösung. Es wird erläutert, welche Themen in der Serie behandelt werden.
· Teil 2: Anleitungen zum CASI Kit. Zunächst wird WCF als Front-End für alle Daten festgelegt. Es kann sich hierbei um Datasets, XML, benutzerdefinierte Klassen oder einfaches HTML handeln. In Phase 1 wird die Unterstützung von Forderungen für den WCF-Standarddienst festgelegt. Dadurch kann das Benutzertoken aus SharePoint abgerufen und über die Grenzen von Anwendungen oder Rechenzentren hinweg an benutzerdefinierte WCF-Anwendungen gesendet werden. In Phase 2 wird die Liste aller Schritte erläutert, die Sie ausführen müssen, um diese typische lokale WCF-Anwendung in eine in Windows Azure gehostete Anwendung umzuwandeln. Nachdem diese Aufgabe ausgeführt ist, ist das Back-End vorbereitet, um eine Umgebung mit mehreren Anwendungen und mehreren Rechenzentren mit integrierter Authentifizierung zu unterstützen.
· Teil 3: beschreibt die benutzerdefinierte Toolkitassembly, die das Bindeglied zwischen der Forderungen unterstützenden WCF-Anwendung in der Cloud und der SharePoint-Farm darstellt. Die Verwendung der Assembly wird erläutert, zudem wird das einfache benutzerdefinierte Steuerelement vorgestellt, das Sie erstellen müssen (ca. 5 Zeilen Code). Und es wird beschrieben, wie dieses Steuerelement in einer Seite im _layouts-Verzeichnis zum Abrufen und Rendern von Daten im Webpart gehostet werden kann. Der vollständige Quellcode für das Beispiel des benutzerdefinierten Steuerelements und der _layouts-Seite wird ebenfalls veröffentlicht.
· Teil 4: Das im CASI Kit enthaltene Webpart. Es stellt eine sofort einsatzfähige Lösung ohne Code bereit, die das Einbinden und Verbinden mit einer asynchronen clientseitigen Abfrage ermöglicht, mit der Daten aus einem in einer Cloud gehosteten Dienst abgerufen und dann im Webpart angezeigt werden. Darin integriert sind Bindungen, sodass Sie Anpassungen vornehmen und eigene JavaScript-Funktionen zum Rendern der Daten verwenden können.
· Teil 5: Eine kurze Erläuterung einiger Beispielanwendungen, die andere häufig verwendete Szenarien für das Verwenden des benutzerdefinierten Steuerelements zeigen, das in Teil 3 beschrieben wird. In einer Anwendung wird das Steuerelement zum Abrufen von Benutzer- oder Konfigurationsdaten und zum Speichern dieser Daten im ASP.NET-Cache verwendet. Anschließend wird es in einem benutzerdefinierten Webpart verwendet. Im anderen Szenario wird das benutzerdefinierte Steuerelement zum Abrufen von Daten aus Azure und zum Verwenden dieser Daten in einer benutzerdefinierten Aufgabe verwendet. In diesem Fall handelt es sich um einen benutzerdefinierten SharePoint-Zeitgeberauftrag. Der vollständige Quellcode für diese Beispielanwendungen wird ebenfalls veröffentlicht.
Mit dem CASI Kit habe ich Richtlinien und Tools bereitgestellt, mit deren Hilfe Sie einfach und rasch eine Verbindung mit Windows Azure über SharePoint 2010 herstellen können, während das Token des aktuellen Benutzers mit gesendet wird, sodass Sie sehr präzise Sicherheitsentscheidungen treffen können. In der ursprünglichen, vom CASI Kit verwendeten WCF-Anwendung wurde eine hartcodierte Auflistung von Daten verwendet, die offen gelegt wurde. In einem nachfolgenden Build (der in den Beiträgen zum CASI Kit nicht dokumentiert ist), habe ich ein Upgrade für den Datenteil ausgeführt, sodass Daten mithilfe der Windows Azure-Tabellenspeicherung gespeichert und abgerufen werden. Nun habe ich dies noch verbessert, indem ich die Daten in SQL Azure erstellt habe, und die WCF-Anwendung in Windows Azure die Daten dort abruft. Das Ergebnis ist nun tatsächlich eine Anwendungssuite in mehreren Clouds: Windows Azure, SQL Azure und (vorgeblich) SharePoint Online. Dieser Beitrag enthält nun einige Tipps für die Arbeit SQL Azure, sodass Sie es rascher in die Bereitstellungsprojekte integrieren können.
Integrationstipps
1. Zum Öffnen von SQL Azure-Datenbanken mit SQL Server Management Studio muss ein Upgrade auf SQL 2008 R2 durchgeführt werden. Technisch kann SQL Server 2008 ausgeführt werden, hierzu müssen dann jedoch einige Problemumgehungen ausgeführt werden. In 2008 R2 ist all dies schon vorbereitet, und Sie werden die besten Erfahrungen machen. Wenn Sie wirklich 2008 verwenden und die Problemumgehungen ausführen möchten, finden Sie hier weitere Informationen: https://social.technet.microsoft.com/wiki/contents/articles/developing-and-deploying-with-sql-azure.aspx. Dieser Artikel enthält einige gute Tipps, daher ist er auf jeden Fall lesenswert.
2. Planen der Verwendung von T-SQL zum Ausführen aller Aufgaben. Die Grafiktools stehen zur Verwendung in Datenbanken, Tabellen, gespeicherten Prozeduren usw. in SQL Azure nicht zur Verfügung. Wieder habe ich hier etwas Nützliches herausgefunden, da ich kein ausgesprochenes Genie in puncto T-SQL bin: zunächst muss eine lokale SQL Server-Datenbank erstellt werden. Im SQL-Verwaltungstool werden zwei Verbindungen erstellt: eine zur lokalen SQL-Instanz und eine zur SQL Azure-Instanz. Tabellen, gespeicherte Prozeduren usw. werden in der lokalen SQL-Instanz erstellt, sodass hierzu die Grafiktools verwendet werden können. Dann verwende ich das Skript [beliebiges SQL-Objekt] As…CREATE to…New Sql Query Window. Dadurch wird das SQL-Skript zum Erstellen der Objekte generiert, und anschließend kann das Skript in ein Abfragefenster eingefügt werden, das für die SQL Azure-Datenbank geöffnet ist.
3. Dieser Punkt ist sehr wichtig: Das Standardtimeout ist häufig zu kurz, um eine Verbindung mit SQL Azure herzustellen. Sie können den Wert bei Verwendung der .NET SqlClient-Klassen in der Verbindungszeichenfolge ändern. Fügen Sie einfach Connection Timeout=30; hinzu. Falls Sie SQL Server Management Studio verwenden, klicken Sie auf die Schaltfläche Erweitert (Advanced) in dem Dialogfeld, in das Sie den Servernamen und die Anmeldinformationen eingeben, und ändern Sie den Wert auf mindestens 30. Der Standardwert sind 15 Sekunden, wobei häufig ein Fehler auftritt, mit 30 Sekunden scheint es aber gut zu funktionieren. Leider besteht keine Möglichkeit, das Verbindungstimeout für einen externen Inhaltstyp (d. h. eine BDC-Anwendungsdefinition) zu einer SQL Azure-Datenquelle zu ändern.
4. Verwenden Sie zum Herstellen einer Verbindung mit den Datenbanken nicht das Administratorkonto (d. h. das Konto zum Erstellen der eigentlichen Datenbank). Erstellen Sie ein separates Konto zur Verwendung mit Daten. Leider bietet SQL Azure nur Unterstützung für SQL-Konten, daher kann die Identität des anfordernden Benutzers nicht direkt verwendet werden, um Entscheidungen über den Zugriff auf Daten zu treffen. Sie können dies umgehen, indem Sie eine WCF-Anwendung verwenden, die als Front-End für die Daten in SQL Azure verwendet wird, und indem Sie die forderungsbasierte Authentifizierung in Windows Azure verwenden, wobei es sich exakt um das vom CASI Kit verwendete Modell handelt. Zudem müssen zum Erstellen einer Anmeldung nur ein paar Schritte ausgeführt werden, mit deren Hilfe eine Verbindung mit den Daten einer spezifischen Datenbank hergestellt werden kann. Hier ein Beispiel:
-create the database first
CREATE DATABASE Customers
-now create the login, then create a user in the database from the login
CREATE LOGIN CustomerReader WITH PASSWORD = 'FooBarFoo'
CREATE USER CustomerReader FROM LOGIN CustomerReader
-now grant rights to the user
GRANT INSERT, UPDATE, SELECT ON dbo.StoreInformation TO CustomerReader
-grant EXECUTE rights to a stored proc
GRANT EXECUTE ON myStoredProc TO CustomerReader
Weitere Beispiele und Details einschließlich Informationen zum Festlegen von Rechten auf Serverebene für Konten in SQL Azure finden Sie unter https://msdn.microsoft.com/en-us/library/ee336235.aspx.
5. Sie müssen für jede vorhandene Datenbank Firewallregeln in SQL Azure erstellen, damit die Kommunikation für verschiedene Clients ermöglicht wird. Falls Sie die Kommunikation für andere Azure-Dienste zulassen möchten, müssen Sie die MicrosoftServices-Firewallregel erstellen (dies kann SQL Azure für Sie erledigen, wenn Sie zunächst die Datenbank erstellen). Sie gibt einen Startbereich von 0.0.0.0 bis 0.0.0.0 an. Falls Sie diese Regel nicht erstellen, ist das Lesen, Hinzufügen oder Bearbeiten von Daten aus den SQL Azure-Datenbanken für keine Ihrer Windows Azure-Anwendungen möglich. Zudem sollten Sie eine Firewallregel erstellen, um die Kommunikation mit beliebigen Servern zu ermöglichen, die zum Weiterleiten an das Internet verwendet werden. Wenn Sie z. B. einen Kabel- oder DSL-Router oder einen RRAS-Server verwenden, dann möchten Sie bestimmt die externe Adresse oder NAT-Adresse für Dinge wie RRAS verwenden.
Mit diesen Tipps sollten Sie Ihre Daten gut einrichten und ausführen können.
Datenzugriff
Der Zugriff auf die Daten über Ihren benutzerdefinierten Code (Windows Azure WCF, Webpart usw.) ist zum Glück fast identisch mit dem Abrufen von Daten von einem lokalen Server mit SQL Server. Es folgt ein kurzes Codebeispiel, anschließend werden einige Teile des Codes etwas ausführlicher erläutert:
//set a longer timeout because 15 seconds is often not
//enough; SQL Azure docs recommend 30
private string conStr = "server=tcp:foodaddy.database.windows.net;Database=Customers;" +
"user ID=CustomerReader;Password=FooBarFoo;Trusted_Connection=False;Encrypt=True;" +
"Connection Timeout=30";
private string queryString = "select * from StoreInformation";
private DataSet ds = new DataSet();
using (SqlConnection cn = new SqlConnection(conStr))
{
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = new SqlCommand(queryString, cn);
da.Fill(ds);
//do something with the data
}
Tatsächlich gibt es hier mit Ausnahme der Verbindungszeichenfolge nicht viel zu erklären. Wichtig anzumerken sind hier die folgenden möglichen Unterschiede zu einer typischen Verbindung mit einem lokalen Server mit SQL Server:
· server: stellen Sie dem Namen der SQL Azure-Datenbank “tcp:” voran.
· Trusted_Connection: Sollte auf false festgelegt sein, da keine integrierte Sicherheit verwendet wird.
· Encrypt: Sollte true sein für alle Verbindungen mit einer in einer Cloud gehosteten Datenbank.
· Connection Timeout: Wie oben bereits beschrieben beträgt das Standardtimeout 15 Sekunden, was häufig nicht ausreicht. Ich habe den Wert daher hier auf 30 Sekunden festgelegt.
Ein weiteres Szenario, das ich hier kurz erwähnen möchte, ist die Datenmigration. Sie können das im Lieferumfang von SQL Server enthaltene BCP-Tool zum Verschieben von Daten von einem lokalen Server mit SQL Server zu SQL Azure verwenden. Die Basisroutine zum Migrieren von Daten lautet wie folgt:
1. Erstellen einer Formatdatei. Sie wird sowohl zum Exportieren der lokalen Daten als auch zum Importieren der Daten in die Cloud verwendet. In diesem Beispiel erstelle ich eine Formatdatei für die Tabelle Region in der Test-Datenbank, und diese Datei wird in der Datei region.fmt gespeichert.
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Exportieren der Daten aus dem lokalen SQL. In diesem Beispiel werden Daten aus der Region-Tabelle in der Test-Datenbank in eine Datei mit dem Namen RegionData.dat exportiert. Ich verwende die in Schritt 1 erstellte Formatdatei region.fmt.
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. Importieren der Daten in SQL Azure. Hierbei ist folgender Punkt wichtig: Wenn Sie Daten in die Cloud importieren, MÜSSEN Sie @serverName in den Benutzernamenparameter einschließen. Andernfalls wird beim Import ein Fehler auftreten. In diesem Fall werden Daten in die Region-Tabelle in der Customers-Datenbank in SQL Azure importiert. Ich importiere Daten aus der Datei RegionData.dat, in die ich meine lokalen Daten exportiert habe. Der Servername (der -S-Parameter) ist der Name der SQL Azure-Datenbank. Als Benutzernamen ( -U-Parameter) verwende ich wie oben erläutert das Format Benutzername@Servername. Ich lege fest, dass die in Schritt 1 erstellte Formatdatei region.fmt verwendet wird, und ich habe eine Batchgröße ( -b-Parameter) von 1000 Datensätzen gleichzeitig festgelegt.
bcp Customers.dbo.Region IN RegionData.dat -S foodaddy.database.windows.net -U speschka@foodaddy.database.windows.net -P FooBarFoo -f region.fmt -b 1000
Hiermit beende ich diesen Beitrag. Ich hoffe, Sie erhalten einen guten Überblick über den grundlegenden Mechanismus zum Erstellen einer SQL Azure-Datenbank und zum Herstellen einer Verbindung mit dieser Datenbank sowie zum Verwenden der Datenbank auf der SharePoint-Website. Nebenbei sei erwähnt, dass ich das CASI Kit zum Abrufen dieser Daten über mein Windows Azure WCF-Front-End zu SQL Azure und zum Rendern der Daten auf der SharePoint-Website verwendet habe. Bei der Erstellung habe ich die Schritte meines Blogs zum CASI Kit befolgt, sodass ich alles zuvor Veröffentlichte getestet und überprüft habe, und ich fand es insgesamt hilfreich. Ich habe in Teil 3 einige kleine Korrekturen vorgenommen und einen kurzen Abschnitt zur Problembehandlung hinzugefügt. Insgesamt habe ich jedoch 30 Minuten zum Erstellen eines neuen benutzerdefinierten Steuerelements und vielleicht 15 Minuten zum Erstellen eines neuen Visual-Webparts benötigt. Ich habe das CASI Kit-Webpart zum Anzeigen einer Gruppe von SQL Azure-Daten aus der WCF-Anwendung verwendet, und im Visual-Webpart habe ich eine Instanz des benutzerdefinierten Steuerelements programmgesteuert erstellt, um ein Dataset abzurufen. Anschließend habe ich es an ein ASP.NET-Raster gebunden. Dies alles habe ich auf einer übersichtlichen Beispielseite zusammengestellt. Die Seite könnte noch erweitert werden, um Daten auf einfache Weise in einer Vielzahl verschiedener Arten anzuzeigen. So sieht diese Seite aus:
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Integrating SQL Azure with SharePoint 2010 and Windows Azure.