Dans la plupart des développements SharePoint, il est nécessaire de stocker des paramètres applicatifs (chemin d’un répertoire temporaire, url d’un web service, clé de série d’un composant tiers, etc.). Le reflexe habituel des diverses équipes que j’ai pu côtoyer est de créer de nouvelles entrées dans la section AppSettings du Web.Config. Je préfère en général utiliser une autre approche que nous allons évoquer aujourd’hui, le property bag.

Tout d’abord, pourquoi faudrait-il éviter de stocker un paramètre dans le Web.Config ?

• Déployer le paramètre provoque un redémarrage de l’application web
• Modifier sa valeur provoque aussi un redémarrage de l’application web
• La valeur est inaccessible hors du contexte la web application : la central admin, aux SPJobDefinition, scripts PowerShell, etc. ne pourraient pas y accéder de manière directe 
• Le paramétrage à répliquer sur chaque frontal de la ferme (risque d’erreur de saisie)
• Problématiques liées aux backup/restore

Dans SharePoint, la quasi totalité des paramètres se configurent à l’aide l’interface web (centrale admin, ou paramètres du site pour les fonctionnels) ou de lignes de commandes (stsadm ou PowerShell). Il parait donc naturel de faire de même avec les développements spécifiques. Je stocke donc toujours mes paramètres applicatifs dans le property bag.

Les avantages sont multiples :

• Les paramètres peuvent être associés à un périmètre précis : Application web, mais aussi ferme, collection de sites, site, liste et élément de liste.
• Ils peuvent être modifiés sans nécessiter de redémarrage de l'application web
• Ils sont persisté dans la base de données SharePoint, et sont donc backupés avec
• Ils sont administrables par interface graphique (dev) ou par ligne de commande PowerShell
• Les modifications n’ont pas à être faites sur chaque serveur

Administration par ligne de commande PowerShell

Afin d’éviter le développement d’une page de configuration pour ces paramètres, on aurait pu proposer une administration avec PowerShell. Voici un exemple qui récupère et redéfinit un paramètre :

Administration avec une interface générique

Le projet communautaire SharePoint Property Bag Settings permet l’administration de tous les property bags de la ferme depuis l’administration centrale.

L’interface proposée est générique, efficace, mais réservée aux administrateurs de ferme.

Téléchargement :

• http://pbs.codeplex.com pour la version 2007
• http://pbs2010.codeplex.com pour la version 2010

Administration personnalisée avec une interface spécifique

Pour une interface administration personnalisée, on pourra développer une CustomAction et une page applicative, ou tout simplement une web part. C’est l’approche que j’utilise le plus souvent. En voici un exemple.

Déclaration de la custom action :

On obtient alors une nouvelle dans les paramètres du site :

Page applicative cible :

Pour la partie graphique de la page, on peut s’inspirer des pages présentes nativement dans 14\TEMPLATE\LAYOUTS, comme SiteNavigationSettings.aspx. Cela permet de conserver le look & feel de SharePoint.

Enregistrement des données dans le property bag :

protected void Validate_Click(object sender, EventArgs e)

{

    if (!Page.IsValid)

        return;

    //Récupération du property bag de la collection de sites

    SPPropertyBag properties = Site.RootWeb.Properties;

    //Enregistrement des valeurs

    properties["Account_GoogleAnalytics"] = txtGoogleAnalytics.Text;

    properties["Account_ShareThis"] = txtShareThis.Text;

    properties["Search_Site_Url"] = txtSiteSearch.Text;

    properties["Search_Catalog_Url"] = txtCatalogSearch.Text;

    properties["WebService_Catalog_Url"] = txtTrainingWebServiceUrl.Text;

    //Persiste les modifications dans la base de données

    properties.Update();

    //Redirection vers l'URL source

    SPUtility.Redirect(Web.Url, SPRedirectFlags.UseSource, HttpContext.Current);

}

Récupération de la valeur d’un paramètre :

//Récupération de l'adresse du web service

String catalogServiceUrl = site.RootWeb.Properties["WebService_Catalog_Url"];

Autres alternatives

Nous avons parlé du web.config, du property bag, mais il existe 2 autres options intéressantes pour le stockage de paramètres : le Hierarchical Object Store, et les listes SharePoint.

Vous trouverez ici un comparatif de ces 4 techniques  : http://msdn.microsoft.com/en-us/library/ff649798.aspx

Arnault Nouvel
Winwise