Faire marcher le SessionState Provider basé sur Azure Table Storage

Je suis en train de lire Azure In Action et comme c’est une version “Early Access” il contient bien sûr des inexactitudes ce qui est normal vu le rythme d’évolution de la plate-forme Windows Azure. Dans le chapitre 6 les auteurs abordent le problème de la gestion des sessions dans une application web. Si vous dépassez le cadre de l’instance unique, Azure n’offre ni le fournisseur “Out-of-Process” habituel (le mode StateServer) ni le mécanisme de “sticky session” qui permet de lier une session particulière à une serveur particulier.

La solution explorée dans le livre est celle du stockage de l’état de la session dans Azure Table Storage, une forme de persistance reposant sur des Tables mais sans schéma avec un système de partition, Azure offrant une API REST pour accéder aux données (il existe aussi une librairie client managée avec un provider LINQ). On va donc stocker la session sous forme sérialisée dans Windows Azure Blob avec une référence dans Azure Table. Comme ça si une des instances du WebRole est indisponible, l’utilisateur de l’application ne verra pas sa session disparaître car elle est stockée indépendamment du serveur utilisé pour procéder sa requête.

Microsoft offre sous forme d’exemple une librairie (il faut télécharger les Additional C# Samples) contenant une classe (TableStorageSessionStateProvider) qui implémente un SessionState Provider qui interagit avec les services Table/Blob d’Azure. Tout ce qui faut faire c’est mettre à jour son fichier web/config pour utiliser ce provider :

1: <sessionState mode=“Custom” customProvider=“TableStorageSessionStateProvider”>

2: <providers>

3:

4: <add name=“TableStorageSessionStateProvider”

5: type=“Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider”

6: allowInsecureRemoteEndpoints=“true”

7: accountName=“devstoreaccount1”

8: sharedKey=“Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoG

9: MGw==”

10: containerName=“sessionstate”

11: applicationName=“ProviderTest”

12: blobServiceBaseUri=“http://ipv4.fiddler:10000”

13: tableServiceBaseUri=“http://ipv4.fiddler:10002”

14: sessionTableName=“Sessions” />

15: </providers>

16: </sessionState>

Si vous regardez l’exemple fourni avec le provider il y a beaucoup de settings dans le fichier de définition du rôle mais ils ne sont plus nécessaire. Ici j’utilise des paramètres spécifiques (ipv4.fiddler et allowInsecureRemoteEndpoints=“true”) car lors de l’exécution je recevais une exception (Microsoft.WindowsAzure.StorageClient.StorageClientException) et Fiddler m’a renseigné sur le dialogue entre mon application et Azure Storage :

1: GET http://127.0.0.1:10002/Tables(‘Sessions’)

2: RESPONSE : HTTP/1.1 400 One of the request inputs is out of range.

C’est un code erreur un peu générique mais en regardant de plus près la documentation de l’API il semblerait que les URI de base ont changé entre :

1: blobServiceBaseUri=“http://ipv4.fiddler:10000/"

2: tableServiceBaseUri=“http://ipv4.fiddler:10002/"

et

1: blobServiceBaseUri=“http://ipv4.fiddler:10000/devstoreaccount1"

2: tableServiceBaseUri=http://ipv4.fiddler:10002/devstoreaccount1

devstoreaccount1 étant le nom du service (qui a toujours la même valeur pour la fabrique de développement. Avec cette petite modification, le provider marche comme prévu.