1. Vous devez impérativement procéder à une mise à niveau vers SQL Server 2008 R2 afin de pouvoir ouvrir les bases de données SQL Azure avec l'outil SQL Server Management Studio. Vous pouvez, certes, techniquement faire fonctionner SQL Server 2008, mais il y a de nombreuses et hasardeuses étapes de contournement à mettre en œuvre pour réaliser cela. Dans SQL Server 2008 R2, tout est déjà intégré et vous pourrez en tirer un meilleur parti. Si toutefois vous souhaitez passer par la voie de l'implémentation de la solution de contournement pour SQL Server 2008, consultez le lien suivant : http://social.technet.microsoft.com/wiki/contents/articles/994.develop-and-deploy-with-windows-azure-sql-database.aspx. Il y a plusieurs conseils judicieux dans cet article qui est donc à découvrir absolument en toutes circonstances.
2. Prévoyez d'utiliser T-SQL pour tout faire. Les outils graphiques ne sont pas disponibles pour fonctionner avec les bases de données, les tables, les procédures stockées SQL Azure, etc. Là encore, une chose que j'ai trouvée très utile, puisque je ne suis pas un vrai spécialiste de T-SQL, est de commencer par simplement créer une base de données SQL Server locale. Dans l'outil SQL Server Management Studio, je crée deux connexions - l'une vers mon instance SQL locale et l'autre vers mon instance SQL Azure. Je crée 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 pour créer mes objets, et je peux ensuite le coller dans une fenêtre de requête que j'ai ouverte vers 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, c'est-à-dire, ajoutez « Connection Timeout=30; ». Si vous utilisez SQL Server Management Studio, cliquez sur le bouton « Advanced » dans la boîte de dialogue dans laquelle vous saisissez le nom du serveur et vos informations d'identification, puis modifiez la valeur du paramètre à au moins 30. La valeur par défaut est de 15 secondes, ce qui est souvent insuffisant, mais une valeur de 30 secondes semble faire l'affaire. Malheureusement, il n'y a pas de méthode pour modifier le délai d'attente de connexion d'un type de contenu externe (c'est-à-dire, la définition d'une application BDC) vers une source de données SQL Azure.
4. N'utilisez pas le compte administrateur de la 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 travailler avec 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 cela en utilisant une application WCF qui met en avant plan les données dans SQL Azure et en utilisant l'authentification basée sur les revendications dans Windows Azure, ce qui correspond exactement au modèle qu'utilise le CASI Kit. En outre, cela demande quelques étapes supplémentaires pour créer un login qui peut être utilisé pour se connecter aux données d'une base de données spécifique. Voici un exemple :
    

   Sélectionnez

   --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
   

5. Vous devez créer des règles de pare-feu dans SQL Azure pour chaque base de données dont vous disposez afin d'autoriser les communications provenant des différents clients. Si vous souhaitez autoriser la communication à partir d'autres services Azure, vous devez alors créer la règle de pare-feu MicrosoftServices (ce que SQL Azure 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 éditer 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 que vous utilisez pour le routage vers l'Internet. Par exemple, si vous disposez d'un câble, d'un routeur DSL ou d'un serveur RRAS, vous voudrez alors utiliser votre adresse externe ou votre adresse NAT pour quelque chose telle que RRAS.

Ceux la devraient être de bons conseils pour rendre vos données opérationnelles.

Accéder aux données elles-mêmes depuis votre code personnalisé - application WCF Windows Azure, web part, etc. - est heureusement plus ou moins similaire à l'extraction des données depuis un serveur SQL Server local. Voici un exemple de code rapide dont j'examinerai ensuite certaines parties plus en détail :

//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, il n'y a pas grand-chose, à l'exception de la chaîne de connexion, qui mérite davantage d'explications. Les principaux éléments qu'il convient de noter, dont notamment les différences d'une connexion classique vers un serveur SQL Server local, sont :

• server : faites précéder le nom de la base de données SQL Azure de « tcp: ».
• Trusted_Connection : devrait avoir la valeur false car vous n'utilisez pas la sécurité intégrée.
• Encrypt : devrait avoir la valeur true pour toute connexion établie vers une base de données hébergée dans le cloud.
• Connection Timeout : comme décrit ci-dessus, le délai d'attente par défaut est de 15 secondes et cela n'est souvent pas suffisant ; à la place je le définis à 30 secondes ici.

Un autre scénario que je voulais mentionner brièvement ici 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 SQL Azure. La routine de base pour migrer des données est comme ceci :

1. Créer un fichier de format : ceci est utilisé à la fois pour l'exportation des données locales et l'importation de celles-ci dans le cloud. Dans cet exemple, je suis en train de créer un fichier de format pour la table Region de la base de données Test, et de l'enregistrer dans le fichier region.fmt.
   bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Exporter des données depuis le serveur SQL Server local : dans cet exemple, je suis en train d'exporter les données de la table Region de la base de données 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. Importer des données vers SQL Azure : la chose principale à noter ici est que lorsque vous êtes en train d'importer des données dans le cloud, vous devez inclure le « @servername » avec le paramètre du nom d'utilisateur ; l'importation échouera sans cela. Dans cet exemple, je suis en train d'importer les données dans la table Region de la base de données Customers de SQL Azure. Je suis en train d'importer du fichier de format RegionData.dat 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 j'ai défini 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 tout pour cet article ! Espérons que cela vous a permis de mieux comprendre les mécanismes de base de la création d'une base de données SQL Azure et de la connexion ainsi que l'utilisation de cette dernière dans votre site SharePoint. À signaler également que j'ai utilisé le CASI Kit pour extraire ces données via mon application « frontend » WCF Windows Azure vers SQL Azure et dont j'ai effectuées le rendu dans mon site SharePoint. J'ai moi-même suivi toutes les instructions figurant dans les cinq premiers articles de la série afin d'effectuer et de valider l'ensemble des opérations qui y sont décrites, et j'ai trouvé que tout était exact, à quelques exceptions près. Il y avait quelques corrections mineures que j'ai effectuées dans la troisième partie ainsi que l'ajout d'une section supplémentaire sur le dépannage. Mais, au total, il m'a fallu 30 minutes pour créer un nouveau contrôle personnalisé et peut être 15 minutes pour créer un composant Visual WebPart. J'ai utilisé le web part du CASI Kit pour afficher un ensemble de données SQL Azure de l'application WCF, et dans le composant Visual WebPart, j'ai créé une instance du contrôle personnalisé par programmation pour extraire un dataset que j'ai ensuite lié à une grille ASP.NET. J'ai tout rassemblé dans une page d'exemple qui me semble effectivement pas mal et qui pourrait être étendue pour afficher assez facilement les données dans plusieurs autres formats. Cette page ressemble à ceci :