[SP2010 – SP2013] – Stocker des données de configuration

Posted on Updated on

Bonjour à tous,

Lorsque nous développons des applications pour SharePoint, il nous arrive bien souvent de vouloir sauvegarder des données de configuration. Ces données peuvent être de simples valeurs (texte, nombre, heure, timestamp, URL, etc.) mais également des données plus complexes comme des objets métiers.

SharePoint 2010 et 2013 (et 2007) nous offrent un certain nombre de possibilités, plus ou moins adaptées suivant les cas. Je vais essayer d’être exhaustif, mais il y en a certainement d’autres !

1/ Liste de configuration

La première solution est de stocker les paramètres de configuration dans une liste de configuration, hébergée sur un site web SharePoint et même sur la console d’Administration centrale de SharePoint.

Pour cela, l’idée et de créer une définition de liste avec Visual Studio qui comprend principalement 2 colonnes :

  • Une colonne Key (clé) : permettant d’identifier uniquement le paramètre, afin de le retrouver plus facilement via une requête CAML par exemple. Sa configuration pourrait être : type Texte, obligatoire
  • Une colonne Value (valeur) : permettant de stocker la valeur au format texte. Sa configuration pourrait être : type Texte (ou texte multiligne), obligatoire
  • Des colonnes supplémentaires comme une description du paramètre, une langue, etc. peuvent être également de la partie.

L’avantage de créer une définition de liste mais également directement une instance (déployées et créées par une Feature, à la racine de la collection de site généralement) et que l’on connait l’identifiant unique du modèle (souvent 10000, 10001, …) que nous fixons nous-même ainsi que l’URL de l’instance créée. Il nous sera donc plus facile de retrouver cette instance par code.

Nous pourrons aussi déployer des données via la création de l’instance via les Rows proposées dans la déclaration de l’instance.

Un autre avantage est de proposer une interface graphique, via le navigateur pour éditer les données… l’’’interface standard de SharePoint !

Et bien sûr, la sécurité et la gestion des droits seront de la partie pour gérer plus finement ces ensembles de clés/valeurs stockées dans la liste.

On peut également penser à développer une classe de service permettant d’accéder à cette instance de liste, récupérer une valeur, ajouter, supprimer, mettre à jour.

Un inconvénient reste l’accès à cette instance de liste depuis un autre site où il faudra recourir à de l’impersonation, des accès Cross-Site et surtout entre WebApplication etc.

Mais également qu’on ne pourra stocker que des types simples ou bien il faudra sérialiser / désérialiser des objets pour les stocker.

Donc pour résumer :

  • Une solution Visual Studio
  • Une définition de liste
  • Une instance de liste
  • Une colonne clé unique
  • Une colonne valeur
  • Des colonnes supplémentaires
  • Des données poussées lors du déploiement
  • Une classe de service pour les accès par code

Voici un extrait d’une classe de service permettant de récupérer l’instance de la liste en question, il vous restera à développer le Get / Update / Add / Delete :

public class ListHelper
{
public static SPList GetParamsList(SPWeb web)
{
SPList resultList = null;
if (web != null)
{
try
{
SPSecurity.RunWithElevatedPrivileges(() =>
{
using (SPSite currentSite = new SPSite(web.Site.ID))
{
using (SPWeb currentWeb = currentSite.OpenWeb(currentSite.RootWeb.ID))
{
SPList list = currentWeb.GetList(ListConstants.ListUrl);

if (list != null)
resultList = list;
}
}
});
return resultList;
}
catch (Exception ex)
{
throw new SPException(“An error has occured. Please contact your administrator : ” + ex.Message);
}
}
else
return null;
}
}

NB : ListConstants est une classe qui contient des paramètres de configuration de ma solution Visual Studio.

2/ Property Bags

Cette seconde solution est également souvent envisagée par les développeurs. Elle permet de stocker des paramètres à plusieurs niveaux :

  • Farm (SPFarm)
  • Web Application (SPWebApplication)
  • Site Collection (SPSite)
  • Site web (SPWeb)
  • Liste (SPList)

Pour faire simple, le property bag est une Hashtable (clé/valeur), sans paramètre supplémentaire, où l’on pourra stocker des types simples sous forme de texte (ou bien en sérialisant / désérialisant les objets).

Les données sont stockées soit dans la base de données de configuration soit dans la base de données de contenu (suivant objet).

Par contre, SharePoint ne propose aucun accès graphique à ces données (pour l’édition par exemple). Toutefois on peut penser au projet SharePoint Property Bag Settings 2010 disponible sur Codeplex : http://pbs2010.codeplex.com/.

Ici également, il faut penser à l’accessibilité des données à partir d’un autre site, d’une autre WebApplication et donc utiliser de l’impersonation, une classe de service pour accéder aux données.

Voici comment mettre à jour une propriété dans le property bag d’un objet SPWeb :

if(web.Properties[“Key”] == null)
{
web.Properties.Add(“Key”, “Value”);
web.Properties.Update();
}

string storedValue = web.Properties[“Key”];
web.Properties[“Key”] = “NewValue”;
web.Properties.Update();

3/ Session / cookie

La troisième solution est de recourir au stockage de données dans la session de l’utilisateur ou dans un cookie ou dans le Viewstate.

Ici, les objets ne sont donc pas stockés dans SharePoint mais bien dans des objets spécifiques à chaque utilisateur et ne pourront pas être partagés entre-eux. Il faudra donc charger les données, les mettre à jour pour chaque utilisateur.

Cela ne correspond donc pas exactement aux cas fonctionnels précédents, mais il est bon de le citer car c’est parfois bien pratique de stocker des données temporaires et qui peuvent permettre d’accélerer le chargement des pages.

Pour le cas de la session, il vous faudra penser à activer la session ASP.Net sur les serveurs IIS hébergeant SharePoint (http://technet.microsoft.com/fr-fr/library/ff607857(v=office.15).aspx).

La session permet de stocker des type simples sous forme de string et nous devrons sérialiser/désérialiser les objets.

Pour stocker une valeur dans la session de l’utilisateur, on peut utiliser le script suivant :

if(HttpContext.Current.Session[“MyKEY”] == null)
{
HttpContext.Current.Session.add (“MyKEY”, “MyVALUE”);
}

4/ Fichiers de configuration

Quatrième option, utiliser le fichier de configuration de la WebApplication : web.config pour stocker des paramètres, ici aussi de type texte. Pour cela, Microsoft fournit une API permettant d”insérer des clés, de le lire, supprimer. En général, on stocke ces paramètres dans la section AppSettings du fichier, ou en créant une section spécifique (qu’il faudra également penser à créer).

Le simple fait de déployer des paramètres à cet emplacement redémarrera le pool IIS afin qu’ils soient pris en compte. Ce redémarrage se fera automatiquement grâce à un Handler positionné par IIS sur le fichier web.config et donc aucune action du développeur ne sera demandée. Attention que cela ne pose pas de problème aux utilisateurs (indisponibilité de quelques secondes / minutes, le temps du redémarrage).

Quelques bugs ont été constatés lors de l’utilisation de cette méthode. Je vous invite à faire une petite recherche à ce sujet.

Généralement, le développeur déploie ces modifications lors de l’activation d’une Feature :

public override void FeatureActivated(SPFeatureReceiverProperties properties) {

SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;

SPWebConfigModification myModification = new SPWebConfigModification();

myModification.Path = “configuration/appSettings”;    myModification.Name = “add [@key=’mySetting’] [@value=’myValue’]”;

myModification.Sequence = 0;

myModification.Owner = “DOMAIN\OWNERLOGIN”;

myModification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;

myModification.Value = “”;    webApp.WebConfigModifications.Add(myModification);

webApp.Update();

webApp.Farm.Services.GetValue().ApplyWebConfigModifications();

}

Il faut bien sur penser à nettoyer lors de la désactivation de la Feature !

 

5/ Objets persistés : SPPersistedObject

Cette cinquième méthode, de mémoire, est arrivée avec SharePoint 2010. Elle permet de stocker des objets complexes, de manière hiérarchique, dans une source de données globale à la plateforme, et peut donc être partagée entre les utilisateurs. Ces objets seront stockés dans la base de données de configuration de la plateforme SharePoint (base de donnée SharePoint_Config).

C’est donc une méthode évoluée en regard des précédentes ! Quelques contraintes sont toutefois à remarquer. En effet, les objets stockés doivent hériter de la classe SPPersistedObject, une annotation (GUID) doit être précisée sur la classe (identifiant unique de l’objet), un constructeur par défaut et un constructeur avec deux paramètres (string => nom de l’objet, SPPersistedObject => l’objet en lui-même). et enfin vos propriétés personalisées. Rien d’insurmontable donc !

Quelques avertissement cependant : le hierarchical store n’est accessible qu’au Farm Account de la ferme SharePoint, et donc pas à tous les utilisateurs. Pensez donc à utiliser l’impersonation pour accéder aux données !

NB : les timerjobs SharePoint sont exécutés avec ce Farm Account, c’est donc un moyen pratique de stocker les données de configuration pour ces TimerJobs !

[Guid(“4DB9AF54-1339-424A-BE2D-648940610283”)]
public class MyPersistedClass : SPPersistedObject
{
public MyPersistedClass()
{
}
public MyPersistedClass(string name, SPPersistedObject parent) : base(name, parent)
{
}
[Persisted]
string Value1;
[Persisted]
string Value2;
[Persisted]
int Value3;
}

Et pour accéder aux données :

SPFarm farm = SPFarm.Local;
PersistedClass rootClass = new PersistedClass(“MyFirstItem”, farm);
rootClass.Value1 = “BLA BLA BLA”;
rootClass.Value2 = “PLOP PLOP PLOP”;
rootClass.Value3 = 8;
rootClass.Update(); PersistedClass childClass = new PersistedClass(“MyFirstItemChild”, rootClass);
childClass.Value1 = “YOUPI”;
childClass.Update(); SPFarm farm = SPFarm.Local;
PersistedClass retrievedValue = farm.GetChild(“MyFirstItem”);

 

6/ Cache Distribué (SP2013)

Dans cette sixième méthode, nous allons aborder une nouveauté de SharePoint 2013 : le Cache Distribué (Distributed Cache) qui peut être une bonne alternative pour le stockage d’objets complexes.

En effet ce dernier propose de maintenir en cache des données / objets sur une durée fixée et paramétrable lors de l’ajout des données dans ce cache et de partager ces données entre les différents serveurs de la ferme SharePoint, entre les utilisateurs.

Pour utiliser ce cache, je suis tombé sur une classe toute prête (et testée dans un projet) qui vous permet d’ajouter, lire, supprimer et modifier les données stockées. Vous la trouverez ici : https://github.com/Almond-Labs/SP2013-Starter/blob/master/Source/AL.Sharepoint.Core/Cache/CacheManager.cs

Il vous suffira de recréer cette classe dans votre projet Visual Studio, de référencer les assemblies nécessaires (recherchez les dans le répertoire 15) et de compiler. Ca fait gagner du temps…

Avantage également de cette source, l’auteur fournit des méthodes génériques pour stocker des objets… et donc nous pourrons stocker des objets complexes dans le cache, sans les sérialiser.

A noter dans la méthode Put qu’un TimerSpan est passé en paramètre. Il permet de fixer la durée de conservation des données dans le cache distribué :

public static void Put<T>(string key, T value, TimeSpan timeSpan)

Par exemple, nous appelerons la méthode Put qui permettra de stocker l’objet MyObjectInstance de type MyObject pendant 1h30. :

CacheManager.Put<MyObject> (“MyKEY”, MyObjectInstance, 1,30,0);

Cette méthode a donc l’avantage de stocker directement des objets durant une période fixée, partageable entre les utilisateurs.

 

7/ Application de Service

Cette dernière méthode est un peu bourrine plus complexe. Elle demande le développement d’une application de service (Service Application) pour SharePoint, proposant un magasin de données centralisé à toute la ferme SharePoint. (et même entre fermes avec du multi-tenant).

Pour cela, je vous conseille de vous tourner vers Technet : http://msdn.microsoft.com/en-us/library/gg193964(v=office.14).aspx ou encore http://msdn.microsoft.com/fr-fr/library/gg543112(v=office.14).aspx.

Ce n’est pas chose aisée, mais dans certains cas cela peut répondre à votre besoin. Par exemple nous pourrions imaginer que nous souhaitons stocker un catalogue important de données de configuration, spécifiques à chaque utilisateur.

Nous utiliserons pour cela une base de données spécifique déployée par l’application de  services, des WebServices afin d’accéder aux données depuis chacun de sites, WebParts, composants personnalisés ou même des applications SharePoint (Apps). Sans oublier la possibilité de requêter ce service depuis une application métier, sur des terminaux mobiles, etc.

Advertisements

One thought on “[SP2010 – SP2013] – Stocker des données de configuration

    Limozin Lionel (@LimozinLionel) said:
    20 August 2014 at 23:11

    Yop, bon article qui donne une vue exhaustive des solutions ! je voulais faire un article là dessus mais je l’ai jamais fait ! 🙂 du coup je vais faire tourner le tien ! ++

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s