Articles Tagués ‘SharePoint 2010’

Je trouvais important dans ce blog de revenir sur des notions élémentaires de SharePoint, peu importe la version, afin d’évoluer progressivement vers des notions plus complexes.

Je vais tenter de vous expliquer brièvement les notions « Ghosted », UnGhosted », « ReGhosted », « Ghostable » et « GhostableInLibrary »

La plupart des éléments en SharePoint sont stockés en base de données mais certaines pages ne le sont pas, elles sont présentes sur le file system.

Ghosted or Not, that’s the question !

Nous simplifierons donc la notion en disant qu’une page est Ghosted lorsqu’elle n’a pas été customisé et donc qu’elle sera chargé directement à partir du file system.

Elles seront chargées en cache et réutilisées dans l’ensemble des sites afin d’augmenter les performances.

UnGhosted signifie donc que l’élément a été customisé et que les changements effectués, en différence avec l’élément original, sont quant à eux stockés en base de données.

Une requête effectuée sur une page customisée (UnGhosted) retournera une combinaison de données entre le file system et la base de données. La partie Ghosted sera quant à elle, stockée en cache sur les Web Front-End afin d’améliorer les performances.

ReGhosted signifie par contre un changement de UnGhosted to Ghosted (ex: Reset to definition).

Ghostable, UnGhostable et GhostableInLibrary

Lorsque l’on définit un module afin de déployer un ou plusieurs fichiers vers SharePoint, l’attribut Type peut avoir 2 valeurs:

  • Ghostable
  • GhostableInLibrary

Les deux valeurs signifient que le fichier est mis en cache en mémoire sur les WFE mais GhostableInLibrary mentionne que le fichier sera mise en cache comme un élément de la liste et donc par cela, pourra être manipulé comme tout autre fichier (Check In, Check Out, …).

Tous les changements effectués sur ce fichier seront eux seuls stockés en base de données.

Si, par contre, aucune valeur n’a été renseignée pour l’attribut Type, le fichier sera considéré comme UnGhostable et sera stocké entièrement en base de données, sans mise en cache.

Publicités

Suite à mon article précédent, parlant de Site Definition, je souhaitais aborder la mise en place d’un Site Provisioning.

Site Provisioning ?

Par le terme « Site Provisioning », nous considérons l’action de mettre en place un ensemble d’éléments, permettant la création d’un site, par exemple, template du site, lists, webparts, features, sécurité,…

Il est intéressant d’effectuer du provisioning à partir d’un site definition, en ne modifiant que le WEBTEMP*.XML, et donc en ne modifiant pas le fichier ONET.XML (Sujet traité dans un prochain article).

C’est ce cas que nous allons voir maintenant.

Création de notre premier Site Provisioning

Dans Visual Studio 2010, créez un projet de type « Site Definition » et modifiez le fichier WEBTEMP.XML et ONET.XML, comme mentionné dans mon article précédent.

Ajoutez une Classe (.cs), que vous nommerez « MYSD_ProvisioningProvider ».

Ajouter les références à SharePoint (Microsoft.SharePoint.dll) et ajouter les directives suivantes:

using Microsoft.SharePoint;
using Microsoft.SharePoint.Navigation;
using Microsoft.SharePoint.Publishing;

Il suffit simplement de définir l’héritage avec la classe SPWebPRovisioningProvider et d’implémenter la méthode Provision().

C’est dans cette méthode que nous allons travailler.

Voici un exemple :

class MYSD_ProvisioningProvider : SPWebProvisioningProvider
{
public override void Provision(SPWebProvisioningProperties props)
{
SPWeb currentWeb = props.Web;
currentWeb.ApplyWebTemplate(« MYSD#1 »);
currentWeb.RoleDefinitions.BreakInHeritance(true,true); //Break Inheritance and maintain role assignments
currentWeb.Update();
}
}

Ce code applique le Web Template, renseigné dans le fichier ONET.XML, au site en cours de création.L’héritage de sécurité est brisé mais les rôles déjà définit sont recopiés.

Une fois notre ProvisioningProvider créé, nous allons modifier le WEBTEMP*.XML pour utiliser ce provider et non directement le fichier ONET.XML, qui lui sera appelé ultérieurement dans le code.

<?xml version= « 1.0″ encoding= « utf-8″?>
<!– _lcid= « 1033″ _version= « 12.0.4518″ _dal= « 1″ –>
<!– _LocalBinding –>
<Templates xmlns:ows= « Microsoft SharePoint « >
<Template Name= « MYSD » ID= « 10001″>
<Configuration ID= « 1″ Title= « My Site Definition » Hidden= »TRUE »  ImageUrl= »/_layouts/images/MYSD.GIF «  Description= « My SD Site «  DisplayCategory= « Custom  »  >
</Configuration>
</Template>

<Template Name= « MYSD_ProvisioningProvider » ID= « 10002″>
<Configuration ID= « 1″ Title= « My Site Definition » Hidden= »FALSE »   ImageUrl= »/_layouts/images/MYSD.GIF «  Description= « My SD Site «  DisplayCategory= « Custom  »  
ProvisionAssembly= »Assembly Reference »
ProvisionClass= »MyNameSpace.MYSD_ProvisioningProvider »>
</Configuration>
</Template>
</Templates>

Nous voyons que deux templates sont définis dont un seul utilise le site définition créé auparavant.L’autre référence notre assembly et notre classe MYSD_ProvisioningProvider.Vous remarquerez que le premier template référence sa configuration comme cachée (HIDDEN=True), ce qui veut dire, qu’on ne la verra pas dans la liste des templates.

Nous ne verrons que le deuxième template, avec aussi le nom « My Site Definition », vu que les deux templates ont le même TITLE.

En Bref, lorsque que nous souhaiterons créer un nouveau site, nous choisirons ce deuxième template (seul visible), qui appellera la méthode Provision(), appliquera notre premier template et modifiera la sécurité !!!

Et voilà !

Il vous sera alors possible de définir votre propre code dans le ProvisioningProvider en fonction de vos besoins.

Dans un prochain article, j’aborderai la problématique d’un ProvisioningProvider pour multiples site definitions.

« Site Definition ? » me direz-vous. Mais, c’est quoi? Pour les experts SharePoint, vous n’apprendrez rien mais, pour ceux qui commencent ou qui n’ont jamais eu l’occasion d’aborder le sujet, voici un petit compte-rendu.

Site Definition ?

Le « site definition« , de par son nom, définit les éléments principaux permettant la création d’un site.Il est représenté par un ensemble de fichiers XML, présents dans le hive SharePoint (12 ou 14 suivant la version).

Pour un site definition (pas vraiment, mais pour l’exemple, on dira que oui), 2 fichiers doivent être créés:

  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\1033\XML\WEBTEMP*.xml, où * représente une combinaison de lettres rendant le fichier unique (ex:WEBTEMPMYSDxml).
  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\ où on trouvera un folder XML et un fichier default.aspx, représentant la page par défaut du site.

Dans le folder XML, on trouvera un fichier ONET.XML, contenant la définition de :

  • Barres de Navigation
  • Lists
  • Features Site et Web
  • WebPart
  • Module, permettant le déploiement de contenu en base de données
Création de notre premier « Site Definition »

Pour créer notre premier site definition, nous ne commencerons pas « from scratch », nous ferons comme tous les professionnels, nous reprendrons un existant, que nous allons copier, renommer et modifier, et ceci dans l’ordre, sinon ça ne marchera pas 😉

Dans le répertoire SiteTemplates, mentionné plus haut, nous allons trouver un répertoire nommé STS.Copions ce répertoire et collons-le à la même place, renommons-le en « MYSD ».

Dans le répertoire « C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\1033 », copions le fichier WEBTEMP.XML, collons-le à la même place, renommons-le « WEBTEMPMYSD.xml ».

Ouvrons-le avec Visual Studio, ou même NotePade et voyons ce qu’il contient:

<?xml version= »1.0″ encoding= »utf-8″?>
<!– _lcid= »1033″ _version= »12.0.4518″ _dal= »1″ –>
<!– _LocalBinding –>
<Templates xmlns:ows= »Microsoft SharePoint »>
<Template Name= »MYSD » ID= »10001″>
<Configuration ID= »1″ Title= »My Site Definition » Hidden= »FALSE »  ImageUrl= »/_layouts/images/MYSD.GIF » Description= »My SD Site » DisplayCategory= »Custom »  >
      </Configuration>
   </Template>
</Templates>

Lors de la modification du fichier WEBTEMPMYSD.xml, les points suivant sont à prendre en compte:

  • L’ID du template doit être supérieur à 10000.
  • Le nom du template (NAME) doit être identique au nom du répertoire contenu dans SiteTemples (MYSD dans notre cas).
  • L’ID de la configuration est important car il devra correspondre à l’ID contenu dans le fichier ONET.XML.
  • Title représente le titre du template disponible dans la liste des templates disponibles.
  • DisplayGroup contient la catégorie dans lequel le nom du site définition apparaîtra, lors de la demande de création d’un nouveau site.Par défaut, nous trouverons les catégories Collaboration, Meetings, Enterprise, Publishing en SharePoint 2007 et Blank & Custom, Collaboration, Content & Data, Search, Tracking, Web Databases sous SharePoint 2010.

Après un IISRESET, nous verrons apparaître dans la liste des site definitions disponibles, une nouvelle entrée nommé « My Site Definition », du titre du template  lors que nous créerons un nouveau site.

Telle que nous l’avons créé, notre nouveau site sera identique à un Team site.

Vous me direz : « Faire tout ça pour ça ! » ET bien, c’est déjà un début.

L’article suivant se concentrera sur le fichier ONET.xml et la page default.aspx, afin de personnaliser un peu plus notre site.