Intégration de SQL Azure avec SharePoint 2010 et Windows Azure
Intégration de SQL Azure avec SharePoint 2010 et Windows Azure
Ce billet de blog est plus utile lorsqu’il est utilisé en complément de la série en cinq parties du Kit CASI (Claims, Azure and SharePoint Integration).
· Partie 1 : vue d’ensemble qui présentait l’intégralité de l’infrastructure et de la solution, et qui décrivait les objectifs de la série.
· Partie 2 : partie réservée aux instructions du Kit CASI. Il faut commencer par faire de WCF la partie frontale de l’ensemble de vos données, qu’il s’agisse de jeux de données, de contenu XML, de classes personnalisées ou simplement de contenu HTML. Dans une première phase, nous faisons du service WCF standard un service prenant en charge les revendications. Cela nous permet de faire passer le jeton d’utilisateur de SharePoint, indépendamment des limites des applications ou des centres de données, vers nos applications WCF personnalisées. Dans une deuxième phase, j’énumère toutes les actions à effectuer pour transférer l’application WCF classique d’un emplacement local à un emplacement hébergé dans Windows Azure. Une fois ce travail terminé, la partie principale est en place pour assurer la prise en charge de plusieurs applications, plusieurs centres de données avec l’authentification intégrée.
· Partie 3 : décrit l’assembly de kit de ressources personnalisé qui permet de connecter votre application WCF prenant en charge les revendications dans le nuage et votre batterie de serveurs SharePoint. J’expliquerai comment utiliser l’assembly, je décrirai le contrôle personnalisé, plutôt simple à créer (environ 5 lignes de code), et j’indiquerai comment héberger ce contrôle dans une page du répertoire _layouts afin de récupérer des données et d’effectuer leur rendu dans un composant WebPart. L’intégralité du code source de l’exemple de contrôle personnalisé et de la page du répertoire _layouts sera également publiée.
· Partie 4 : composant WebPart inclus dans le Kit CASI. Il fournit une solution sans code, prête à l’emploi, qui vous permet de vous raccorder et de vous connecter à une requête asynchrone côté client pour récupérer des données à partir de votre service hébergé dans le nuage, et les afficher ensuite dans le composant WebPart. Il dispose également de raccordements intégrés afin que vous puissiez le personnaliser un peu et utiliser vos propres fonctions JavaScript pour effectuer le rendu des données.
· Partie 5 : brève description de quelques exemples d’applications qui illustrent d’autres scénarios d’utilisation du contrôle personnalisé que vous aurez créé lors de la troisième partie. L’un de ces scénarios consiste à tirer parti du contrôle pour récupérer des données utilisateur ou des données de configuration, les stocker dans le cache ASP.NET, puis les utiliser dans un composant WebPart personnalisé. L’autre scénario consiste à tirer parti du contrôle personnalisé pour récupérer des données en provenance d’Azure afin de les utiliser dans une tâche personnalisée ; dans le cas présent, un travail du minuteur SharePoint personnalisé. L’intégralité du code source de ces exemples d’applications sera également publiée.
Dans le Kit CASI, je vous ai fourni un certain nombre d’instructions et d’outils pour vous permettre de vous connecter facilement et simplement à Windows Azure depuis SharePoint 2010 tout en envoyant le jeton de l’utilisateur actuel, afin que vous puissiez prendre des décisions de sécurité affutées. L’application WCF d’origine utilisée par le Kit CASI avait simplement recours à une collection de données codée en dur qu’elle exposait. Dans une version suivante (non documentée dans les publications du Kit CASI), j’ai mis à niveau la partie consacrée aux données pour que celles-ci soient stockées et extraites dans l’espace de stockage des tables Windows Azure. J’ai procédé à quelques améliorations en créant les données dans SQL Azure et en faisant en sorte que mon application WCF dans Windows Azure y extraie les données. À présent, on peut dire qu’il s’agit d’une suite d’applications multinuage : Windows Azure, SQL Azure et (ostensiblement) SharePoint Online. L’objectif de ce billet de blog est de vous donner quelques conseils d’utilisation de SQL Azure pour que vous puissiez l’intégrer plus facilement dans vos projets de développement.
Conseils d’intégration
1. Vous devez impérativement procéder à une mise à niveau vers SQL 2008 R2 afin de pouvoir ouvrir les bases de données SQL Azure avec l’outil SQL Server Management Studio. Certes, SQL Server 2008 peut fonctionner mais au prix de nombreuses et périlleuses étapes de contournement à mettre en œuvre. Dans 2008 R2, tout est intégré et vous pourrez en tirer un meilleur parti. Si toutefois vous souhaitez implémenter la trajectoire de contournement pour SQL Server 2008, consultez le lien suivant : https://social.technet.microsoft.com/wiki/contents/articles/developing-and-deploying-with-sql-azure.aspx. Cet article contient des conseils judicieux à découvrir absolument en toutes circonstances.
2. Prévoyez d’utiliser T-SQL pour tout faire. Les outils graphiques ne sont pas faits pour fonctionner avec les bases de données, les tables, les procédures stockées SQL Azure, etc. Là encore, puisque je ne suis pas un vrai assistant T-SQL, j’ai trouvé qu’il était judicieux de commencer par créer une base de données SQL Server locale. Dans l’outil SQL Management, je crée deux connexions : la première vers mon instance SQL locale et la seconde vers mon instance SQL Azure. Je crée également les tables, les procédures stockées, etc. dans l’instance SQL locale de manière à pouvoir utiliser les outils graphiques. Ensuite, j’utilise le script [whatever Sql object] As…CREATE to…New Sql Query Window. Cela génère le script SQL permettant de créer mes objets. Je peux ensuite le coller dans une fenêtre de requête que j’ai ouverte dans ma base de données SQL Azure.
3. Ce point est important. Le délai d’attente par défaut n’est généralement pas suffisant pour se connecter à SQL Azure. Vous pouvez le modifier si vous utilisez les classes .NET SqlClient dans la chaîne de connexion. Par exemple, ajoutez "Connection Timeout=30;". Si vous utilisez SQL Server Management Studio, cliquez sur le bouton Avancées dans la boîte de dialogue dans laquelle vous entrez le nom du serveur et vos informations d’identification, puis affectez au paramètre une valeur au moins égale à 30. La valeur par défaut de 15 secondes est souvent insuffisante mais une valeur de 30 secondes est assez satisfaisante. Malheureusement, aucune méthode ne permet de modifier le délai d’attente de connexion d’un type de contenu externe (par exemple, la définition d’une application BDC) vers une source de données SQL Azure.
4. N’utilisez pas le compte Administrateur de base de données pour établir la connexion à vos bases de données (c’est-à-dire, le compte qui vous est attribué pour créer la base de données elle-même). Créez un compte distinct pour traiter les données. Malheureusement, comme SQL Azure ne prend en charge que les comptes SQL, vous ne pouvez pas utiliser directement l’identité de l’utilisateur demandeur pour prendre des décisions sur l’accès aux données. Vous pouvez contourner cet état de fait en utilisant une application WCF qui met en premier plan les données dans SQL Azure et utilise l’authentification basée sur les revendications dans Windows Azure, ce qui correspond exactement au modèle utilisé dans le Kit CASI. Quelques étapes supplémentaires sont également nécessaires pour créer un nom d’accès capable d’établir une connexion aux données d’une base de données spécifique. Voici un exemple :
-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
Pour accéder à davantage d’exemples et à des informations détaillées, notamment à la définition des droits au niveau serveur des comptes dans SQL Azure, voir https://msdn.microsoft.com/en-us/library/ee336235.aspx.
5. Vous devez créer des règles de pare-feu dans SQL Azure pour chaque base de données afin d’autoriser les communications provenant des différents clients. Si vous souhaitez autoriser les communications à partir d’autres services Azure, vous devez créer la règle de pare-feu MicrosoftServices (ce que SQL Azure vous propose de faire pour vous lorsque vous créez la base de données pour la première fois), qui est une plage de départ allant de 0.0.0.0 à 0.0.0.0. Si vous ne créez pas cette règle, aucune de vos applications Windows Azure ne pourra lire, ajouter ou modifier des données depuis vos bases de données SQL Azure ! Vous devez également créer une règle de pare-feu pour autoriser les communications avec les serveurs de tout type utilisé pour le routage vers Internet. Par exemple, si vous disposez d’un câble, d’un routeur DSL ou d’un serveur RRAS, vous voudrez utiliser votre adresse externe ou votre adresse NAT pour un service tel que RRAS.
Les conseils suivants vous seront utiles pour rendre vos données opérationnelles.
Accès aux données
L’accès aux données depuis votre code personnalisé (application WCF Windows Azure, composant WebPart, etc.) est très similaire à l’extraction des données depuis un serveur SQL Server. Voici un exemple de code rapide dont je vais présenter certaines parties de façon approfondie :
//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
}
À ce stade, seul le concept de chaîne de connexion mérite encore quelques explications. Les principales différences d’une connexion classique vers un serveur SQL Server local sont notamment les suivantes :
· server : faites précéder le nom de la base de données SQL Azure de "tcp:".
· Trusted_Connection : doit avoir la valeur false car la sécurité intégrée n’est pas utilisée.
· Encrypt : doit avoir la valeur true pour toute connexion établie vers une base de données hébergée dans un nuage.
· Connection Timeout : comme nous l’avons mentionné plus haut, le délai d’attente par défaut de 15 secondes est souvent insuffisant. Utilisez plutôt la valeur 30 secondes.
Un autre scénario que je voulais mentionner brièvement dans cet article est l’utilisation de la migration des données. Vous pouvez utiliser l’outil BCP fourni avec SQL Server pour déplacer des données d’un serveur SQL Server local vers un serveur SQL Azure. La routine de base de migration des données ressemble à ceci :
1. Création d’un fichier de format : utilisé à la fois pour l’exportation des données locales et l’importation de celles-ci dans le nuage. Dans cet exemple, je crée un fichier de format pour la table Region de la base de données de test, et je l’enregistre dans le fichier region.fmt.
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Exportation des données depuis le serveur SQL Server local : dans cet exemple, j’exporte la table Region de la base de données de test, dans un fichier appelé RegionData.dat. J’utilise le fichier de format region.fmt que j’ai créé à l’étape 1.
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. Importation des données vers SQL Azure. Le point principal à noter ici est que lorsque vous importez des données dans le nuage, vous DEVEZ inclure le paramètre "@servername" avec le paramètre username, faute de quoi l’importation échouera. Dans cet exemple, j’importe les données dans la table Region de la base de données Customers de SQL Azure. J’importe du fichier de format RegionData.dat le fichier dans lequel j’ai exporté mes données locales. Mon nom de serveur (le paramètre -S) correspond au nom de la base de données SQL Azure. Pour mon nom d’utilisateur (le paramètre -U), j’utilise le format username@servername comme décrit plus haut. Je lui demande d’utiliser le fichier de format region.fmt que j’ai créé à l’étape 1 et je définis une taille de lot (le paramètre -b) de 1 000 enregistrements à la fois.
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
C’est terminé ! J’espère que ce blog vous a permis de mieux comprendre la procédure de base de création d’une base de données SQL Azure et de connexion de cette dernière à votre site SharePoint. À signaler également que j’ai utilisé le Kit CASI pour extraire ces données via mon serveur principal WCF Windows Azure vers SQL Azure et que je les restituées dans mon site SharePoint. J’ai moi-même suivi toutes les instructions figurant dans mon blog afin d’effectuer l’ensemble des opérations. Tout était exact, à l’exception de quelques erreurs figurant dans la troisième partie que j’ai corrigées. J’ai également ajouté une section sur la résolution des problèmes. Au total, il m’a fallu 30 minutes pour créer un contrôle personnalisé et environ 15 minutes pour créer un composant WebPart Visual. J’ai utilisé le composant WebPart Kit CASI pour afficher un ensemble de données SQL Azure dans l’application WCF et, dans le composant WebPart Visual, j’ai créé une instance du contrôle personnalisé par programme pour extraire un ensemble de données que j’ai ensuite lié à une grille ASP.NET. J’ai tout rassemblé dans une page d’exemple qui me semble assez satisfaisante et qui pourrait être développée pour afficher très facilement les données dans d’autres formats. Cette page ressemble à ceci :
Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Integrating SQL Azure with SharePoint 2010 and Windows Azure.