SharePoint Deployment : Feature, Feature, Solution .... mais aussi WebProvisioningProvider
Petit message à tous mes lecteurs développeurs SharePoint
Je répete encore et encore que 90 % du temps, la solution à une problématique SharePoint passera forcement par l'utilisation et la conception d'une Feature.
Et je maintiens
Mais comment déployer physiquement mon dev (via Feature) sur mes serveurs de prod ?
>>> Simple, vous la packagez dans une solution et hop, en ligne de commande STSADM, via l'installer MSI d'Ontolica ou la web interface de TamTam
Mais comment mettre à jour un site déja créé ?
>>> Simple, vous utilisez le Feature Stapling et vous le mappez sur l'identifiant de votre modéle de site
Vous voyez, Feature reste souvent la réponse générique :)
Enfin pour 90 % des cas
...
...
Et je suis tombé dans l'un des 10% de cas : et oui, la nature déteste le vide 
>>> le Stapling et les Features activés par site Definition sont activés trop tôt dans le cycle de création d'un SPWeb.
Dommage, mais alors "Que pouvons nous bien faire ?"
>>>>>>> Simple voyons, il vous reste la solution du WebProvisioningProvider
La SPWebProvisioningProvider est une classe de base permettant de personnaliser la phase de "provisionning" de SharePoint. Elle est d'ailleurs largement utilisé dans le cas de publication de site MOSS (vous savez les modéles entreprises)
Exemple : avec le modèle SPS
<Template Name="SPSPORTAL" ID="47">
<Configuration ID="0" Title="Collaboration Portal" Type="0" Hidden="FALSE"
ImageUrl="/_layouts/1033/images/template_corp_intranet.png"
Description="A starter site hierarchy for an intranet divisional portal. It includes a home page, a News site, ...and is used to host team sites."
ProvisionAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
ProvisionClass="Microsoft.SharePoint.Publishing.PortalProvisioningProvider"
ProvisionData="SiteTemplates\\WebManifest\\PortalWebManifest.xml"
RootWebOnly="TRUE"
DisplayCategory="Publishing"
VisibilityFeatureDependency="97A2485F-EF4B-401f-9167-FA4FE177C6F6" />
</Template>
Il suffit juste de déclarer la DLL signée avec son strong name dans les attributs ProvisionAssembly et ProvisionClass. ProvisionData, lui permet de passer des paramétres externes pour aller encore plus loin dans la personnalisation.
En ce qui concerne la classe, vous ne devez que surcharger la méthode Provision(SPWebProvisioningProperties props) et faire vos propes "actions"
class SiteAction : SPWebProvisioningProvider
{
public override void Provision(SPWebProvisioningProperties props)
{
using (SPWeb web = props.Web)
web.AplyWebTemplate("STS#1"); //if you don't apply a template you will be prompted to select one upon creation
//your own custom things ...
web.Update();
}
}
}
Ainsi, avec votre propre WebProvisioningProvider vous pouvez aisement accéder aux listes crées de votre site et, par exemple, modifier l'héritage des listes et pre paramétrer les sécurités (pardon, SPRoleAssignment) de celle ci. Voir même créer les connexions entre listes vu que les GUIDs existent.
Et quitte à reparler des Features, bien pourquoi pas, activer certaines features "hidden" pour des cas métiers en se passant de script supplémentaires
Une classe bien sympathique non ?
Encore un nouvel incontournable (de plus)
Pour revenir à l'exemple du modèle MOSS Portal, le PortalProvisioningProvider utilise simplement une arboréscence XML de Site Definition pour créer/provisionner un portail MOSS avec News, Document, Report Center, Search Center et Site Directory en une fois. A vous de créer les votres !
Voici quelques annexes pour aller plus loin dans le concept :
Renaud Comte aka TheMit (Je provisionnes, tu provisionnes, SP provisionne ...)
Member of WygTeam
http://www.wygwam.com
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
