[SharePoint 2013] – Installation des Office Web Apps 2013 avec SharePoint Server 2013

 

Bonjour à tous.

Un nouvel article pour vous montrer comment installer et configurer les Office Web Apps 2013 couplées à SharePoint Server 2013.

Pour l’histoire, les Office Web Apps sont arrivées dans leur deuxième version : nous avons les Office Web Apps 2010 et 2013 à ce jour. Ces OWA vont nous permettre, couplées à SharePoint, d’ouvrir des documents Word, Excel, PowerPoint et OneNote directement dans le navigateur, sans utiliser les composants clients Office. Ce qui peut être évidemment très pratique lors les collaborateurs utilisent des plateformes hétérogènes de types tablettes iPad, Android, des téléphones mobiles ou encore des postes de travail sous MacOS ou une distribution Linux.

Il faut bien intégrer pour commencer qu’à chaque version de SharePoint correspond une version des Office Web Apps :

• SharePoint 2010 (Foundation ou Server) => Office Web Apps 2010
• SharePoint 2013 (Foundation ou Server) => Office Web Apps 2013

Coté Licencing, vous pourrez installer ces OWA (2010 ou 2013) suivant le type de licences que vous possédez pour le pack Office. Si vous possédez les packs Office (en volumes) version 2010 vous pourrez éditer les fichiers Office. Si vous ne les possédez pas, vous pourrez seulement lire des documents Office via les OWA.

 

De plus, avec la version 2010 des OWA, il était possible d’installer ce composant logiciel sur le même serveur que le serveur SharePoint (en le boostant un peu…). Avec la version 2013, ce n’est plus possible et ces composants s’installe sur un serveur dédié, rattaché au même domaine que SharePoint. Il y a quelques contraintes supplémentaires comme de ne pas avoir installé le pack Office sur ce serveur. Pour plus de renseignements : http://technet.microsoft.com/fr-fr/library/jj219458.aspx

 

Pour l’architecture utilisée pour cet article, j’ai 3 machines virtuelles (VM) :

• 1 contrôleur de domaine : DOMAIN
• 1 serveur SharePoint Server 2013 Enterprise (EN) : SP2013-DEV
• 1 serveur Office Web Apps 2013 : SPOWA2013

Ces trois serveurs sont rattachés au même domaine : DEMO, sont installés sous Windows Server 2012 ou Windows Server 2008R2 (EN) et à jour :

 

Et oui… une belle débauche de mémoire et de processeurs…

 

Je précise que mes machines Active Directory & SharePoint étaient déjà installées et fonctionnelles avant l’installation d’Office Web Apps.

Première étape installer et configurer Windows Server 2012 (et mettre à jour !), je ne détaillerai pas cela dans cet article.

 

1/ Préparation du serveur pour Office Web Apps 2013

 

Lorsque le serveur a été installé et configuré, il faut commencer par télécharger les Office Web Apps 2013. Pour cela, vous pouvez télécharger la Preview ici : http://www.microsoft.com/en-us/download/details.aspx?id=30358 ou ici http://www.microsoft.com/fr-fr/download/details.aspx?id=35489. Vous pourrez également télécharger l’iso depuis votre compte MSDN ou Technet.

 

Connectez vous ensuite à votre serveur OWA avec un compte du domaine qui est administrateur local du serveur (dans mon cas, c’est le même que le compte d’installation de SharePoint : DEMO\spadmin).

 

Il faut ensuite exécuter un script PowerShell sur le serveur OWA en lançant la commande en administrateur. Pour cela, rendez-vous sur les “tuiles” de Windows Server 2012, repérez la tuile Windows PowerShell :

 

Faites un clic-droit sur la tuile :

 

Et cliquez sur “Run as administrator” :

 

Vous pouvez avoir l’UAC qui se déclenche, on clique sur “Yes” :

 

Et PowerShell 3.0 :

 

Nous allons lancer un script permettant d’installer et de configurer les rôles et services nécessaires sur le serveur pour OWA 2013. Vous trouverez des informations complémentaires ici : http://technet.microsoft.com/fr-fr/library/jj219455.aspx.

On copie / colle le script :

 

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices

 

Le script d’installation se lance et devrait durer… moins de 3 minutes :

 

Mais que fait ce script me direz-vous ? Il se charge d’installer le rôle Web Server de Windows Server 2012 (installer IIS), et active sur ce rôle les différents protocoles, utilitaires qu’utiliseront les OWA 2013.

Lorsque le script est terminé, redémarrer le serveur OWA 2013. En allant dans le gestionnaire du serveur, on voit tout de suite le nouveau rôle IIS qui apparait :

 

 

 

Les extensions et fonctionnalités activées :

 

2/ Installation des Office Web Apps 2013

 

Maintenant que les prérequis sont installés, il va falloir installer les binaires des Office Web Apps 2013. Pour cela il faut monter l’iso téléchargé précédemment sur la machine virtuelle et lancer le setup d’installation :

 

Pour cela, on se rend dans l’explorateur de fichier et on fait un clic-droit sur le lecteur DVD avec l’iso monté, puis “Install or run program from your media” (s’il ne démarre pas tout seul).

Encore une fois, l’UAC peut s’activer, on clique sur “Yes” :

 

Le contrat de licence apparait, on sélectionne la case à cocher en bas, puis on clique sur “Continue” :

 

On nous demande ensuite d’indiquer l’emplacement d’installation des binaires. Je conserve l’emplacement par défaut : C:\Program Files\Microsoft Office Web Apps et on clique sur “Install Now” :

 

L’installation débute… on patiente :

 

L’installation est terminée, on clique sur “Close” :

 

En option, vous pouvez également installer les languages packs pour OWA 2013. Pour plus de renseignements, visitez ceci : http://technet.microsoft.com/fr-fr/library/jj219455.aspx => Etape 3.

 

 

3/ Déploiement des Office Web Apps

 

L’étape suivante consiste à créer l’application Web qui permettra d’afficher nos documents. Il existe plusieurs types de configurations suivant votre besoin : http ou https, équilibrage de charge, etc.

Dans mon cas, je reste dans un périmètre interne, tous les utilisateurs se connectent en http. Pour corser un peu le tout, nous allons créer l’application en PowerShell. Pour cela, on reprend notre console PowerShell lancée en administrateur et on exécute :

New-OfficeWebAppsFarm –InternalURL "http://servername" –AllowHttp -EditingEnabled

 

Où :

• New-OfficeWebAppsFarm : permet de créer la ferme OWA 2013
• InternalURL : adresse du serveur courant, dans mon cas http://spowa2013
• AllowHttp : puisque je reste en http
• EditingEnabled : puisque je veux permettre de lire / modifier les documents

Cela donne :

New-OfficeWebAppsFarm –InternalURL http://spowa2013 –AllowHttp -EditingEnabled

 

Un avertissement vous stipule que pour utiliser le mode édition de document des OWA 2013, il faut que vos utilisateur aient les licences adéquates. Pour savoir si vous pouvez utiliser le mode édition, je vous renvoie vers : http://technet.microsoft.com/fr-fr/library/ff431682.aspx#license.

Pour faire simple, vous avez les licences pour Office 2013, vous pouvez éditer. Sinon la lecture des fichiers est “offerte” par Microsoft.

 

Pour configurer les licences à utiliser, reportez vous à : http://technet.microsoft.com/fr-fr/library/jj219627.aspx.

Dans mon cas, je choisis donc “Yes” (Y) :

 

La configuration se poursuit. A la fin, un résumé apparait :

 

Remarque MSDN : Si des composants de .NET Framework 3.5 ont été installés puis supprimés, il est possible que vous rencontriez des messages de type « Exceptions de service web (500) » ou « Erreur interne du serveur (500.21) » lorsque vous exécutez des applets de commande OfficeWebApps. Pour résoudre ces problèmes, exécutez les exemples de commandes suivants à partir d’une invite de commandes avec élévation de privilèges afin de supprimer les paramètres susceptibles de gêner le fonctionnement normal d’Office Web Apps Server :

%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –iru
iisreset /restart /noforce

 

 

4/ Vérification que tout est ok…

 

Pour cela, nous allons utiliser le service de discovery des Office Web Apps en se connectant tout simplement sur une URL :

http://servername/hosting/discovery

 

Dans mon cas :

http://spowa2013/hosting/discovery

 

Je lance donc simplement un navigateur (IE 10 ici) et on entre l’adresse ci-dessus. Si Office Web Apps Server fonctionne comme prévu, vous verrez s’afficher un flux XML de découverte WOPI (Web app Open Platform Interface). Les premières lignes de ce fichier doivent se présenter comme dans l’exemple suivant : :

 

Et ce n’est pas fini…

 

 

5/ Configurer SharePoint Server 2013 pour Office Web Apps 2013

 

Il nous reste maintenant à faire le lien entre notre ferme SharePoint Server 2013 et les Office Web Apps 2013. Et encore une fois… une bonne dose de PowerShell !

Cependant, nous n’allons pas utiliser la console PowerShell 3.0 de Windows Server 2012, mais le SharePoint Management Shell de SharePoint Server 2013… un outil bien connu des administrateurs SharePoint !

Lançons donc la console SharePoint Management Shell, sur le serveur SharePoint bien entendu !

 

Puis toujours dans cette console, on lance la commande :

New-SPWOPIBinding -ServerName <WacServerName> -AllowHTTP

 

Dans mon cas (attention aux paramètres suivant ceux fixés lors de la configuration des OWA : http / https en particulier) :

New-SPWOPIBinding –ServerName SPOWA2013 -AllowHTTP

 

 

Le Shell vous liste un ensemble de connections WOPI disponibles :

 

Puis on exécute :

Get-SPWOPIZone

 

Dans les résultats vous devez avoir absolument :

 

Internal-https

 

Et bien sûr nous voudrions avoir du http ! Nous allons donc modifier cette zone avec la commande :

Set-SPWOPIZone –zone “internal-http”

 

Et on relance avec Get-SPWOPIZone pour vérifier que cela a bien été pris en compte :

Maintenant nous avons :

 

Internal-http

 

 

Ca sent la fin… mais pas tout de suite. Il nous reste à autoriser l’authentification OAuth sur http pour que cela fonctionne. Pour cela on éxécute :

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

Si cela renvoie “False” dans la console, alors il faut forcer la valeur à “True” :

$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
$config.Update()

 

On relance une petite vérification :

 

(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp

La valeur renvoyée doit être maintenant à “True” :

Pour plus d’informations : http://technet.microsoft.com/fr-fr/library/ff431687.aspx.

 

 

6/ Vérification de la configuration globale

 

Pour vérifier… il faut tester ! Nous allons donc nous connecter sur un de nos sites SharePoint avec un compte utilisateur / collaborateur (pas d’administrateur, super admin etc.)

 

J’ajoute quelques documents de type Office… dans une bibliothèque de documents :

 

On clique sur un des fichiers (PowerPoint pour ma part)… et ça marche !

 

Et du Word :

 

Et de l’Excel :

 

Et un OneNote :

 

Notez à chaque fois la présence des boutons dans le ruban pour éditer les documents, les sauvegarder etc. Ca marche plutôt bien !

 

Grâce aux Office Web Apps 2013, nous avons aussi la prévisualisation des documents (dans la bibliothèque de documents et dans la recherche) :

 

 

Si vous avez activé l’édition / création des documents depuis OWA 2013, lorsque vous cliquez sur le bouton Nouveau document Word, vous pourrez créer vos document directement en Web !

 

 

Voilà, c’est fini !

[SharePoint 2013]–Nouvel outil : SharePoint Color Palette Tool

Avec la sortie de la nouvelle version de SharePoint 2013, nous avons vu (encore) son design général changé. Ce design reprend les principes de Modern UI dictés par Microsoft et repris sur l’intégralité des plateformes : Windows 8, Windows Phone, Xbox.

Nous retrouvons donc dans SharePoint en particulier les Tuiles bien connues, et d’autres un peu moins “Visibles” au premier abord.

SharePoint 2013 apporte également son lot de nouveau thèmes graphiques natifs sur lesquels on peut personnaliser le jeu de couleurs, l’icône, et même la navigation latérale via les materpages oslo.master & seattle.master. Cet éditeur de thèmes permet quand même bien des personnalisations, mais il se peut que cela ne suffise pas !

Dans ces cas là, on peut utiliser le Design Manager permettant d’importer des découpages html pour les convertir en masterpages, les canaux, etc. (voir mon article : SP2013–Design Manager).

 

Pour nous permettre d’aller plus loin, mais sans recourir à SharePoint Designer, aux CSS, aux masterpages, Microsoft nous propose un nouvel outil fraichement releasé : SharePoint Color Palette Tool ! Les prérequis sont Internet Explorer 8 ou supérieur et le Framework 4.5.

Pour ceux qui le connaitraient, pour SharePoint 2010 nous avions Theme Builder renommé Open XML Theme Builder et disponible récemment sur CodePlex : Open XML Theme Builder.

 

Voyons ensemble à quoi cela ressemble !

 

On télécharge l’outil ici : SharePoint Color Palette Tool (1,1Mb).

Et on l’installe (ici sur une machine Windows 8 Enterprise x64 en anglais) :

 

On lance le setup, “Next” :

 

On accepte les termes du contrat de licence et “Next” :

 

On choisit l’emplacement d’installation, puis “Next” :

 

Résumé des information, “Next” :

 

L’installation est terminée, on coche “Launch the program”, “Finish” :

 

Le programme se lance :

 

Premières impressions… plutôt bonnes ! On retrouve sur la gauche un ensemble de contrôles “couleur” avec prévisualisation et code couleur RGB. Au centre, une prévisualisation du résultat (on reprend le thème général de SharePoint 2013) et tout en haut le choix du layout (oslo ou seattle), en dessous un affichage des warnings & erreurs. Sur la droite, un contrôle permet de placer une image en fond, de choisir un jeu de couleurs originel, et au centre un outil permettant de tester le contraste appliqué…

 

Première chose que je vérifie… qu’est-ce que génère cet outil ? En faisant File > Save, on me propose de sauvegarder un fichier *.spcolor :

 

Ce fichier spcolor n’est autre qu’un fichier XML :

 

Qu’il faudra importer dans SharePoint 2013, pour en savoir plus, direction MSDN : http://msdn.microsoft.com/en-us/library/jj945889.aspx

En fait on retrouve une certaine analogie entre ce fichier spcolor et les css, mais seulement pour la partie couleurs. En effet, on ne retrouve dans ce fichier aucun information sur la masterpage, le layout etc. Donc les paramètres dans l’outil Color Palette ne servent qu’à la prévisualisation, pas au paramétrage du thème en lui-même.

Notons également que dans la zone de gauche, on a des sous items sur lesquels on pourra modifier les couleurs :

 

A mon avis, cela va être difficile de faire un jeu de couleur correct dès le premier essai ! Il y a beaucoup de couleurs à paramétrer…

 

Avec 3 ou 4 clics, on arrive à quelque chose… ou pas ! (Notez les warnings…)

 

A bientôt !

SP2010–Remplacer les formulaires–Part 2

Bonjour à tous.

Dans la partie précédente, nous avons vu comment créer trois modèles de listes SharePoint 2010 (fonctionnera également avec 2007 et 2013, Server ou Foundation). Avec ces modèles nous avons déployé pour chacun d’eux une instance : Pays, Villes et Commandes.

Le tout bien sûr “packagé” dans une solution SharePoint avec Visual Studio 2010. Ainsi nous avons utilisé une “Feature” pour déployer le tout qui, lorsqu’elle s’active, déploie les modèles, créée les instances de ces listes et remplit les listes Pays et Villes avec un ensemble de données.

Dans cette nouvelle partie, nous allons tenter de remplacer les formulaires standards :

• DispForm.aspx
• NewForm.aspx
• EditForm.aspx

Dans le but de surcharger leur comportement, principalement au niveau des listes déroulantes : la liste des villes disponibles sera filtrée en fonction du pays qui sera sélectionné.

Pour compléter, vous pourriez également faire appel à quelques projets CodePlex fournissant ces listes déroulantes liées par le biais de champs personnalisés (Custom Fields) qui sont réutilisables et en soit plus “propres”. Je vous propose une autre méthode, sans passer par ces fonctionnalités additionnelles, plus dans le cas d’un usage unique.

1/ Comprendre la structure – le pourquoi…

Avant d’entamer la phase technique du développement/déploiement, il est essentiel de comprendre comment fonctionnent les formulaires standards, où ils sont déployés, etc.

Vous pouvez utiliser SharePoint Manager 2010 ou SharePoint Designer 2010 pour explorer la structure utilisé par les listes pour rediriger l’utilisateur vers ces fameux formulaires lorsqu’il souhaitera ajouter/modifier/voir les propriétés d’un élément/document dans une liste/bibliothèque de documents SharePoint. La structure est plutôt simple. Elle se compose de :

• Un répertoire racine : RootFolder. Ce répertoire est créé par défaut.
• Des sous-répertoires créés par les utilisateurs
• Des items/documents créés par les utilisateurs
• Un répertoire particulier : “Forms” qui contient les formulaires en question pour les bibliothèques de documents
• Pour les listes, les formulaires en questions sont placés directement dans le RootFolder.

Il m’est arrivé, bien souvent, de reprendre des projets SharePoint, par les biais de missions de conseil, d’assistance et je vois assez régulièrement des développeurs ayant essayé de “surcharger” ces formulaires en créant leurs propres formulaires (par copier/coller)… ayant des nom différents. Et en général… :

• DispForm.aspx devient DisForm2.aspx
• NewForm.aspx devient NewForm2.aspx
• EditForm.aspx devient EditForm2.aspx

Et moi…. ça ne me convient pas ! En effet, les anciens formulaires restent disponibles, ils ne sont pas masqués… et restent donc accessible pour quelqu’un d’observateur qui saura assez rapidement appeler ces url et pourra donc se passer des règles de gestion que l’on souhaite imposer. Nous allons voir maintenant comment écraser ces fichiers standards en déployant notre solution SharePoint et les associer à nos listes Villes et Commandes.

2/ Déployer des Formulaires personnalisés

Reprenons notre solution. On remarque tout de suite que nous n’avons aucun fichier “aspx” dans les répertoires de la solution (répertoires des listes en particulier).

Première manipulation : utiliser SharePoint Designer 2010 pour récupérer les fichiers “aspx” originaux.

On commence donc par lancer SharePoint Designer 2010 (de préférence en 32bits ), on se connecte donc sur le site et utilise l’explorateur pour atteindre notre liste, Villes par exemple (via l’explorateur à gauche “All Files > Lists > Villes”) :

On remarque tout de suite la présence des fichiers qui nous intéressent. Manipulation assez simple, on ouvre chacun des fichiers (en mode Avancé : clic droit sur chaque fichier > Ouvrir en mode avancé) et on copie/colle le contenu de chacun dans un fichier (avec Notepad ou autre) le but étant de sauvegarder chacun de ces fichiers dans le répertoire de la solution, à l’intérieur du dossier concernant notre liste et bien sûr avec le nom qui va bien… :

On copie le contenu du fichier…

Dans un Notepad :

On sauvegarde dans les répertoires Windows des définitions des listes Villes et Commandes, puis on inclut les fichiers dans la solution SharePoint :

Les nouveaux fichiers sont inclus :

Il reste ensuite une dernière manipulation à faire, sur chacun de nos fichiers aspx ajoutés dans la solution, nous allons faire un clic-droit > Propriétés :

Et nous allons changer la propriété “Deployment Type” en “ElementFile” (on peut vérifier le répertoire de déploiement qui doit pointer vers le répertoire de sortie de la feature dans le répertoire 14 (SharePointRoot) :

On reproduit ceci sur chacun des fichiers aspx. Vous pouvez vérifier dans le fichier “SharePointProjectItem.spdata” (celui au niveau de la déclaration du modèle de liste) que les modifications ont bien été apportées :

Notre solution est donc enrichie avec ces nouvelles pages. Toutefois, si l’on déploie ces nouvelles pages aspx directement, l’instance déployée n’utilisera pas directement nos nouvelles pages. Pour cela, nous allons devoir modifier le fichier Schema.xml pour chacune de ces listes, au niveau du nœud “Forms” (tout à la fin du fichier) :

<Forms>
<Form Type=”DisplayForm” Url=”DispForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
<Form Type=”EditForm” Url=”EditForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
<Form Type=”NewForm” Url=”NewForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” />
</Forms>

Chaque formulaire/page est associé à notre liste SharePoint par le biais d’un nœud <Form />.

Nous allons modifier chacun de ces nœuds <Form /> pour indiquer à SharePoint qu’il doit utiliser nos pages et pas celles par défaut. Nous allons donc supprimer l’attribut SetupPath pour faire pointer chacun des formulaires vers nos pages custom.

Nous allons également ajouter quelques attributs :

• Path=”NewForm.aspx” => Chemin relatif vers le fichier NewForm.aspx dans notre solution
• Default=”TRUE” => Page par défaut
• UseDefaultListFormWebPart=”False” => Ne pas utiliser le WebPart Standard
• WebPartOrder=”1″ => Le WebPart sera placé en premier dans la zone de WebParts (il n’y en aura qu’un dans la page de toute manière)

Ce qui donne :

<Form Type=”NewForm” Url=”NewForm.aspx” Path=”NewForm.aspx” WebPartZoneID=”Main” Default=”TRUE” UseDefaultListFormWebPart=”False” WebPartOrder=”1″>

</Form>

Nous allons ensuite ajouter le WebPart de type ListFormWebPart dans la page NewForm.aspx pour afficher le formulaire standard. Il existe plusieurs méthodes que vous retrouverez sur Google, Bing ou autre.

Pour ma part, je vais choisir une méthode moins traditionnelle qui consiste à placer ce WebPart directement dans la déclaration de l’association du formulaire d’ajout d’élément et notre page custom (toutes les méthodes sont possible, celle-ci n’est pas meilleure !… juste différente). Nous allons ajouter un tag <WebParts> directement dans le <Form/> précédent, qui contiendra la déclaration du WebPart de type ListFormWebPart. Certains ont déjà du croiser ce type de déclaration, très utilisé lorsqu’on déploie des pages web avec des Modules. On obtiendra :

<Forms>
…
<Form Type=”NewForm” Url=”NewForm.aspx” Path=”NewForm.aspx” WebPartZoneID=”Main” Default=”TRUE” UseDefaultListFormWebPart=”False” WebPartOrder=”1″>
<WebParts>
<AllUsersWebPart WebPartZoneID=”Main” WebPartOrder=”1″>
<![CDATA[
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
<Assembly>Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
<TypeName>Microsoft.SharePoint.WebPartPages.ListFormWebPart</TypeName>
<PageType>PAGE_NEWFORM</PageType>
</WebPart>]]>
</AllUsersWebPart>
</WebParts>
</Form>
</Forms>

On déclare ici un WebPart de type Microsoft.SharePoint.WebPartPages.ListFormWebPart dans la zone “Main”. Notez également le tag PageType qui a la valeur PAGE_NEWFORM indiquant qu’il s’agit bien de ce WebPart dans le mode de rendu “New” (nouvel élément). Vous trouverez ici les valeurs possibles pour cette énumération : http://msdn.microsoft.com/fr-fr/library/microsoft.sharepoint.pagetype(v=office.12).aspx

On reproduit cela pour chacun des formulaires, sur nos listes Villes et Commandes :

Mais me direz-vous, nous avons copié les pages NewForm, DispForm et EditForm avec SharePoint Designer et ce WebPart devrait être déjà présent dans les pages… Oui tout à fait, c’est pour cela que nous allons le supprimer !

On ouvre donc un à un chacun des fichiers NewForm.aspx, EditForm.aspx et DispForm.aspx (pour les listes Villes et Commandes) et on recherche :

<WebPartPages:ListFormWebPart runat=”server” __MarkupType=”xmlmarkup” ……… </WebPartPages:ListFormWebPart>

On sélectionne le tout et on supprime tout le contenu de cet élément (l’élément y compris) :

On sauvegarde le tout.

Pour préciser pourquoi on ne conserve pas ce WebPart dans les pages, vous avez peut être remarque qu’il possédait la propriété ListId. Malheureusement, cette propriété est valorisée avec un GUID qui représente l’identifiant unique de la liste… et qui sera différent à chaque redéploiement de notre Solution. Impossible donc de packager ce composant directement avec le bon GUID. Vous pourrez par contre utiliser l’attribut ListName valorisé avec l’url relative de la liste.

Il nous reste à compiler, déployer… Pour vérifier que les fichiers sont bien déployés et écrasent bien les fichiers natifs, il faut changer un peu le contenu de la page (le bon vieux test du TOTO dans la page )…

Pour cela, j’ai choisi le formulaire NewForm.aspx de la liste de Commandes. Dans le ContentPlaceHolder “PlaceHolderPageTitle”, j’ajoute un TOTO :

On compile avec Visual Studio et on déploie sur notre plateforme SharePoint. Une fois le tout déployé, je me dirige vers ma liste de Commandes dans le navigateur, je clique sur nouveau :

On retrouve bien le TOTO dans le titre de la fenêtre !!! (Bien sûr on supprime le TOTO et on redéploye).

Ca c’est fait.

3/ Modifier le comportement des pages

Nos pages étant maintenant déployées, nous allons modifier leur héritage natif pour les faire hériter de classes contenues dans notre propre assembly (DLL). Pour cela, nous allons créer une classe C# pour chacun des pages NewForm, DispForm & EditForm, et ce pour chacune de nos listes (donc 6 classes dans mon cas).

En général, je créé un répertoire Pages à la racine de mon projet (les pages sont compilées dans la DLL et le fichier .cs n’est pas déployé). Une fois le dossier créé, j’ajoute 6 classes :

Ensuite, nous allons faire hériter chacune de ces classes de “WebPartPage” et ajouter “using Microsoft.SharePoint.WebPartPages” :

Ensuite, dans chacune des pages aspx, nous allons :

• Ajouter tout au début :  <%@ Assembly Name=”$SharePoint.Project.AssemblyFullName$” %>
• Modifier le Inherits pour pointer vers notre assembly :

Inherits=”Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint, Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c”

devient

Inherits=”DEMO1.Pages.CommandesNewForm,$SharePoint.Project.AssemblyFullName$”

Où :

• DEMO1.Pages.CommandesNewForm = Namespace + nom de la classe
• $SharePoint.Project.AssemblyFullName$ : nom complet de l’Assembly, valorisé par Visual Studio avant le déploiement.

On recommence la manipulation sur chacune des 6 pages aspx:

On compile/déploie à nouveau le tout. Pour tester que le code-behind est bien appelé, on peut passer en debug sur la solution et vérifier que la méthode OnLoad() est bien appelée :

Et voilà !

Je me décide enfin à publier cet article…, je continuerai la suite un peu plus tard ! Au programme, personnalisation du comportement des formulaires !

Wait & see (pas trop longtemps j’espère ) !

SP2010-Remplacer les formulaires – Part 1 – Template de Liste

Bonjour à tous.

Cela fait maintenant quelques semaines que je n’ai pas bloggé, je profite d’une petite “accalmie” pour publier un article qui vous montrera comment déployer des formulaires NewForm.aspx; EditForm.aspx et DispForm.aspx dans SharePoint 2010 (fonctionnera également avec SharePoint 2007 & 2013).

Bien souvent, quand je me déplace chez des clients ou que je reprend des développements qui ont été réalisés, je m’aperçois que ces formulaires ont été ré-implémentés et redéployés par le biais d’une solution SharePoint, ce qui est plutôt bien. Ce qui me choque en général, c’est que ces formulaires ne viennent pas remplacer “physiquement” les existants mais s’ajoutent aux formulaires existants, avec des nouveaux noms : newform2.aspx, editform2.aspx ou encore dispform2.aspx.

Si des utilisateurs (malins) connaissent les url vers les formulaires natifs, ils pourront toujours les utiliser !!! Et ça, c’est vraiment pas bien !

Je vais donc tenter de vous expliquer comment remplacer ces formulaires (les écraser en fait) par le biais d’une solutions SharePoint… et sans utiliser du C# => Chalenge

Nous essaierons d’utiliser au maximum les API natives de SharePoint et les fichiers XML de déploiements supportés.

Dans un second temps, j’aimerai également vous montrer comment remplacer/overrider le comportement natifs des contrôles dans ces formulaires… mais ça sera pour un prochain article !

Première chose, se connecter sur une collection de sites, un site et créer une liste. Dans mon cas ce sera une liste custom… et même une seconde liste que je créée par avance pour la suite de l’article. Je vais également créer une colonne de type lookup (recherche d’éléments déjà présents sur le site) qui “reliera” mes deux listes… Et encore une troisième qui utilisera elle aussi une colonne de type lookup :

On aura donc trois listes avec leurs attributs :

• Pays contiendra le nom du pays, sa surface et son nombre d’habitants
• Ville contiendra le nom de la ville, le pays d’appartenance, sa surface et son nombre d’habitants
• Commande contiendra le titre de la commande, le montant, le pays et la ville. Dans un premier temps on utilisera deux lookup, pointant sur chacune de listes pays & ville. On remplacera plus tard ce comportement par des listes déroulantes liées et pré-filtrées. On sélectionnera le pays et cela filtrera la liste des villes proposées. Mais tout cela dans un second temps.

1/ Commençons par créer une solution avec Visual Studio 2010

NB : il faudra travailler un maximum en utilisant les noms internes des objets (List, Site, Web, Field) afin d’éviter les problème de renommage de ces objets (display name). On utilisera donc au maximum les staticName, internalName ou encore Name lorsqu’il seront disponibles sur ces éléments.

Commençons donc par la création de notre solution SharePoint dans Visual Studio 2010 que j’appelle DEMO1, de type “Empty SharePoint Project” :

On renseigne l’url du site de déploiement (debug) et on choisit une solution de type “Farm” :

La solution est créée, elle est vide ou presque :

Nous allons ensuite faire un clic droit sur le projet et ajouter un nouvel élément (Add New Item), de type SharePoint > 2010 > List Definition et on la nomme “Pays”. Cliquer sur “Add” :

Un assistant se lance pour nous aider à créer la structure générale de ce nouvel élément. Ainsi, on renseigne le nom d’affichage de notre modèle de liste. “Pays” dans mon cas, et on choisit le modèle “Custom List” qui est basique et conviendra très bien à notre exemple. Je choisis également de créer une instance lorsque la “Feature” déployant notre solution sera activée. On clique sur “Finish” :

La structure générale de la liste est créée :

On observe tout de suite que Visual Studio n’a pas créé 1 seul fichier mais bien un ensemble. Dans le “Répertoire” Pays, on retrouve 2 fichiers XML :

1. Elements.xml : décrit à SharePoint comment déployer le modèle lors de l’ajout de ce modèle
2. Schema.xml : décrit la structure des éléments à déployer : colonnes, vues, etc.

Dans le sous dossier ListInstance1, on retrouve également un fichier XML “Elements.xml” qui décrira comment créer une instance de cette liste à partir du modèle lors de l’activation de la Feature : nom de la liste, url, visibilité, etc.

Nous allons ensuite reproduire 2 fois ces manipulations pour créer deux nouvelles listes : Ville et Commandes :

J’ai pris le soin ici de renommer correctement les instances dans l’explorateur de solutions.

2/ Modifier les modèles de liste – Elements.xml

Notre structure générale est créée. Passons maintenant à l’enrichissement de ces modèles en les personnalisant, en ajoutant de nouvelle colonnes, etc.

Pays

Pour la liste pays, nous devons :

• Ajouter les colonnes Surface, NbrHabitants
• Masquer le modèle dans la galerie (les utilisateurs/power users ne pourront pas créer de nouvelles instances à partir de ce modèle)
• personnaliser par-ci, par-là

Commençons par le fichier Elements.xml du modèle de liste :

<ListTemplate
Name=”Pays”
Type=”10000″
BaseType=”0″
OnQuickLaunch=”TRUE”
SecurityBits=”11″
Sequence=”410″
DisplayName=”Pays”
Description=”My List Definition”
Image=”/_layouts/images/itgen.png”/>

Nous allons commencer par modifier les attributs existants :

• Name=”Pays” => cela me convient
• Type=”10000” (attention il ne faudra pas avoir un autre modèle sur la plateforme portant ce numéro)
• BaseType=”0” => cela me convient (on aura 1 pour les bibliothèques de documents)
• OnQuickLaunch=”TRUE” => Je change en FALSE, la liste n’apparaitra pas pas défaut dans la barre de navigation rapide “QuickLaunch”
• SecurityBits=”11″ => OK
• Sequence => aucune importance, le modèle sera masque dans la galerie des modèles de liste (ordre de tri dans cette galerie)
• DisplayName=”Pays” => OK
• Description=”My List Definition” => On donne une description
• Image=”/_layouts/images/itgen.png”/ => Je vais changer pour fournir une image un peu plus sympa, que je déploierais grâce à la solution dans 14/TEMPLATES/IMAGES/DEMO/monimage.png

On ajoutera les attributs :

• Category=”Custom Lists” => pas obligatoire
• DisableAttachments=”TRUE” => on désactive les pièces jointes
• FolderCreation=”FALSE” => on désactive la création de répertoires
• Hidden=”TRUE” => On masque le modèle dans la galerie
• VersioningEnabled=”FALSE” => on désactive le versioning

Ce qui donne :

ListTemplate
Name=”Pays”
Type=”10000″
Category=”Custom Lists”
DisableAttachments=”TRUE”
FolderCreation=”FALSE”
Hidden=”TRUE”
VersioningEnabled=”FALSE”
BaseType=”0″
OnQuickLaunch=”FALSE”
SecurityBits=”11″
Sequence=”410″
DisplayName=”Pays”
Description=”Modèle de liste pays”
Image=”/_layouts/images/demo/pays.png”/>

Notez également qu’il vous sera possible de “localiser” les noms (Name, Description par exemple) pour faire la traduction automatique suivant la langue du navigateur/UI.

Ville

Nous allons effectuer les mêmes manipulation sur le fichier Elements.xml du modèle de liste Ville :

<ListTemplate
Name=”Ville”
Type=”10001″
Category=”Custom Lists”
DisableAttachments=”TRUE”
FolderCreation=”FALSE”
Hidden=”TRUE”
VersioningEnabled=”FALSE”
BaseType=”0″
OnQuickLaunch=”FALSE”
SecurityBits=”11″
Sequence=”410″
DisplayName=”Ville”
Description=”Modèle de liste ville.”
Image=”/_layouts/images/demo/villes.png”/>

Commandes

Pour la liste commande, on reproduit les mêmes manipulations, sauf que ne masquera pas ce modèle pour pouvoir créer de multiples instances de cette liste. Nous modifierons également l’attribut OnQuickLaunch à TRUE :

<ListTemplate
Name=”Commandes”
Type=”10002″
Category=”Custom Lists”
DisableAttachments=”TRUE”
FolderCreation=”FALSE”
VersioningEnabled=”FALSE”
BaseType=”0″
OnQuickLaunch=”TRUE”
SecurityBits=”11″
Sequence=”410″
DisplayName=”Commandes”
Description=”Modèle de liste commandes.”
Image=”/_layouts/images/demo/commandes.png”/>

3/ Modifier les modèles de liste – Schema.xml

Maintenant, il nous faut modifier les 3 fichiers Schema.xml pour ajouter les nouvelles colonnes sur chacun de nos 3 modèles.

Pays

Dans notre liste pays, nous allons ajouter deux colonnes supplémentaires : Surface & NbrHabitants. Pour cela, on ouvre le fichier Schema.xml du modèle de liste Pays :

Dans cette structure XML, on distinguera 4 parties principales :

• ContentTypes : déclaration des types de contenus associés à la liste, ici celui élément (Item)
• Fields : métadonnées/colonnes/champs associés à ce modèle de liste
• Views : Vues disponibles sur ce modèle de liste
• Forms : formulaires d’ajout/modification/affichage de chaque élément de cette liste

Nous allons modifier principalement les <Fields /> pour ajouter les deux colonnes. Ici plusieurs écoles s’affrontent. Vous pouvez partir de rien, aidé par l’IntelliSense de Visual Studio ou alors créer une liste et ces colonnes dans SharePoint et utiliser SharePoint Manager 2010 pour récupérer le schéma généré par SharePoint. Pour sa facilité, je choisirai la seconde option, mais en restant vigilant sur le flot de XML généré…

J’ai donc créé une liste “pays” dans SharePoint et créé les colonnes demandées.

On prendra soin également de choisir le type de champ le plus pertinent pour nos données : texte, monnaie, nombre, recherche, etc.

Voila donc le formulaire d’ajout d’un pays :

Vous trouverez de quoi télécharger SharePoint Manager 2010 sur CodePlex : SharePoint Manager 2010.

On lance SharePoint Manager 2010, et on explore l’arborescence de nos sites jusqu’à arriver sur notre liste “Pays” :

Dans la section de droite, vous trouverez un onglet “SchemaXml” avec l’ensemble du schéma :

On repère rapidement, dans la section <Fields> que nos deux champs créés précédemment apparaissent :

• <Field Type=”Number” DisplayName=”Surface” Required=”FALSE”… />
• <Field Type=”Number” DisplayName=”NbrHabitants” Required=”FALSE” … />

Ce sont ces deux nœuds XML qu’il va falloir intégrer au fichier Schema.xml. On copie donc ces deux lignes et on les colle dans Schema.xml, dans le nœud <Fields></Fields> :

Petite option supplémentaire, on peut directement ajouter ces deux champs dans les différentes vues proposées par notre modèle de liste Pays. Pour cela, dans Schema.xml, on ouvre le nœud <Views>, on y trouve deux nœuds <View></View>. Une des vues sera utilisée pour les terminaux de type mobiles, et l’autre pour l’affichage par défaut dans le navigateur de cette liste “Pays”. Nous allons directement modifier la vue commençant par :

<View BaseViewID=”1″ Type=”HTML” WebPartZoneID=”Main”

Et ajouter dans le sous-noeud <ViewFields> deux nouvelles lignes (en copiant/collant 1 existante) et en modifiant l’attribut Name avec les noms de noms champs. Je supprime également le Field Attachments correspondant aux pièces jointes que j’ai désactivé dans la déclaration du Template (voir Elements.xml précédent) :

        <ViewFields>
<FieldRef Name=”LinkTitle”></FieldRef>
<FieldRef Name=”Surface”></FieldRef>
<FieldRef Name=”NbrHabitants”></FieldRef>
</ViewFields>

Attention, l’ordre a son important, les premières lignes deviendront les premières colonnes dans l’affichage. On obtiendra donc :

Notez également le nœud <OrderBy> au dessous qui vous permettra d’ordonner votre liste sur les noms des pays, alphabétiquement. Je modifie donc :

        <Query>
<OrderBy>
<FieldRef Name=”Title”></FieldRef>
</OrderBy>
</Query>

C’est tout pour ce modèle de liste. Passons maintenant à l’instance qui sera créé à partir de ce modèle. Pour cela, on se rend dans l’explorateur de solution et on ouvre le fichier Elements.xml de l’instance de la liste Pays :

Dans ce dernier, nous allons encore modifier la structure XML pour paramétrer l’instance de la liste Pays qui sera automatiquement créée lors de l’activation de la feature (nous y reviendrons…).

On modifie pour obtenir :

<ListInstance Title=”Pays”
OnQuickLaunch=”FALSE”
TemplateType=”10000″
Url=”Lists/Pays”
Description=”Liste des pays”>
</ListInstance>

Notez que le TemplateType est le même que celui définit dans le <ListTemplate>, c’est très important ! Sinon SharePoint ne saura pas quel modèle utiliser pour créer l’instance. Pour l’url, ma liste sera accessible à l’adresse :

• http://MONSERVEURSHAREPOINT/MONSITE/Lists/pays

Ville

Nous allons reprendre les mêmes manipulations pour ce modèle de liste. Nous allons utiliser également SharePoint Manager 2010 pour récupérer les nœuds XML des colonnes.

Nous utilisons SharePoint Manager 2010, récupération des nœuds XML, copier/coller, etc.

Dans le Schema.xml, nous  ajoutons donc :

<Fields>
<Field Type=”Number” DisplayName=”Surface” Required=”FALSE”…

<Field Type=”Number” DisplayName=”NbrHabitants” Required=”FALSE”…

<Field Type=”Lookup” DisplayName=”Pays” Required=”TRUE”…

</Fields>

Jusqu’ici, nous n’avions eu que des colonnes texte ou nombre. Nous venons d’ajouter un nouveau type de colonne, le type “Lookup” (Recherche d’information déjà présentes sur le site). Ces champs permettent de référencer des données qui sont stockées dans une autre liste/bibliothèque SharePoint. Si l’on regarde les différents attributs proposés, on note :

• List=”{1f675688-39f5-441d-bdb7-19f7c3dce646}”
• ShowField=”Title”

Ce sont ces deux attributs qui établissent la relation entre la liste Ville et la liste Pays et plus particulièrement la colonne “Title” de la liste Pays. Lorsque nous déploierons cette solution/feature, SharePoint ne saura pas faire le lien entre ces deux listes, parce que, tout simple le GUID de la liste Pays va être régénéré !!! Et oui… il va donc falloir remplacer ce premier attribut “List” par autre chose (et si possible pas de code C# qui recréera cette relation).

Après un petit tour dans le SDK de SharePoint, on s’aperçoit qu’il est possible de remplacer ce GUID par l’adresse relative de cette liste : Lists/Pays. On obtient donc :

<Field Type=”Lookup” DisplayName=”Pays” Required=”TRUE” EnforceUniqueValues=”FALSE” List=”Lists/Pays” ShowField=”Title”

Pour la vue par défaut de cette liste, nous effectuons également les modification afin que ces champs apparaissent dans la vue :

C’est tout pour ce modèle de liste. Passons maintenant à l’instance qui sera créé à partir de ce modèle. Pour cela, on se rend dans l’explorateur de solution et on ouvre le fichier Elements.xml de l’instance de la liste Ville :

Dans ce dernier, nous allons encore modifier la structure XML pour paramétrer l’instance de la liste Ville qui sera automatiquement créée lors de l’activation de la feature (nous y reviendrons…).

On modifie pour obtenir :

<ListInstance Title=”Villes”
OnQuickLaunch=”FALSE”
TemplateType=”10001″
Url=”Lists/Villes”
Description=”Liste des villes.”>
</ListInstance>

Notez que le TemplateType est le même que celui définit dans le <ListTemplate>, c’est très important ! Sinon SharePoint ne saura pas quel modèle utiliser pour créer l’instance. Pour l’url, ma liste sera accessible à l’adresse :

• http://MONSERVEURSHAREPOINT/MONSITE/Lists/villes

Commandes

Pour cette dernière liste, nous allons reproduire exactement les mêmes étapes mais cette fois-ci, nous aurons deux champs de type “lookup”.

Dans le schema.xml nous aurons donc :

<Fields>
<Field Type=”Currency” DisplayName=”Montant” Required=”TRUE” … />
<Field Type=”Lookup” DisplayName=”Pays” Required=”TRUE” …  List=”Lists/Pays” ShowField=”Title” … />
<Field Type=”Lookup” DisplayName=”Ville” Required=”TRUE” List=”Lists/Villes” ShowField=”Title” … />

</Fields>

C’est tout pour ce modèle de liste. Passons maintenant à l’instance qui sera créé à partir de ce modèle. Pour cela, on se rend dans l’explorateur de solution et on ouvre le fichier Elements.xml de l’instance de la liste Commandes :

Dans ce dernier, nous allons encore modifier la structure XML pour paramétrer l’instance de la liste Commandes qui sera automatiquement créée lors de l’activation de la feature (nous y reviendrons…).

On modifie pour obtenir :

<ListInstance Title=”Commandes”
OnQuickLaunch=”TRUE”
TemplateType=”10002″
Url=”Lists/Commandes”
Description=”Liste de commandes.”>
</ListInstance>

Notez que le TemplateType est le même que celui définit dans le <ListTemplate>, c’est très important ! Sinon SharePoint ne saura pas quel modèle utiliser pour créer l’instance. Pour l’url, ma liste sera accessible à l’adresse :

• http://MONSERVEURSHAREPOINT/MONSITE/Lists/Commandes

Certains diront qu’il y a des attributs qui ne seront pas utilisé dans notre structure XML (Schema.xml, Elements.xml), je vous laisse vous reporter au SDK, Technet et autre pour faire le tri….

4/ Créer le package de déploiement

Il nous reste une étape, et pas des moindres, créer la solution, la feature qui permettra de déployer nos modèles de listes. Pour cela, Visual Studio nous aide bien (et c’est tout à son honneur quand on a connu SharePoint 2003 & 2007…).

Nous allons donc nous rendre dans le répertoire Features où nous remarquons qu’une feature est déjà disponible :

On double-clique, l’assistant de configuration des features apparait :

Aucun des modèles/instances n’est ajouté à la feature. Commençons par cela, on utilise les “flèches du milieu” pour faire passer les éléments de gauche à droite :

Nous allons également renommer la feature, donner une petite description, etc. Il vous sera également possible d’ajouter une petite icone pour distinguer plus rapidement vos features.

Chose importante, je souhaiterai que mes listes Pays & Villes ne soient créées (leurs instances plus particulièrement) que sur le site à la racine de la collection (RootWeb). Pour cela, le plus simple et de changer le Scope (Etendue) en Site (Collection de sites).

Et c’est tout… Bien sûr suivant le projet et les éléments qui le composent, vous choisirez peut être d’utiliser plusieurs fonctionnalités, avec des scopes différents…

5/ Le test !

C’est parti pour le test… vous pouvez utiliser F5 (mode debug… qui ne débuggera rien ici !) ou alors le clic droit sur le projet, Build, Deploy. Ce choisis la seconde option.

Vous aurez peut être une erreur lors du déploiement vous disant que Pays et Pays se déploie dans le même emplacement. En effet en regardant les chemins (path) de déploiement on s’aperçoit que les instances se déploient dans le même répertoire que la définition. Je renomme dans les modèles de liste :

Vous obtiendrez peut être cette fenêtre de warning :

Elle vous informe tout simplement qu’une liste avec le même nom “Pays” existe deja. On coche “Do not prompt me again for these items” puis on clique sur “Resolve automatically”…

Déploiement réussi :

Il faudra également ajouter les images correspondant aux miniatures de nos listes. J’ai fait quelques petits changements dans les Elements.xml des modèles en modifiant l’attribut Image :

• Image=”/_layouts/images/demo/pays16x16.png”/
• Image=”/_layouts/images/demo/villes16x16.png”/
• Image=”/_layouts/images/demo/commandes16x16.png”/

Voila ce que cela donne dans le menu “View all site content” :

Rendons nous sur chacune des liste afin de vérifier :

• La déclaration des vues/affichages (colonnes présentes, tris)
• La déclaration des colonnes créées

Coté affichage, rien à signaler. Par contre si on lance le formulaire d’ajout d’un pays/ville/commandes, le formulaire ne présente que le champ Titre !!! Effectivement, c’est un comportement particulier de SharePoint voire étrange que l’on constate ici.

Premier réflexe, ajouter les attributs :

ShowInNewForm=”TRUE” ShowInEditForm=”TRUE” ShowInDisplayForm=”TRUE”

Sur chacun des champs. Mais cela n’aura aucun effet. Nous aurons alors deux choix :

• Recourir à un type de contenu SharePoint
• Supprimer les types de contenu

En général, je me tourne vers la première option. Mais dans notre cas, aucun intérêt de créer des types de contenu (ContentTypes) vu qu’on ne les utilisera qu’une seule fois (pour Pays & Ville) et qu’on ne réutilisera pas non plus la structure de Commandes (si ce n’est pour créer de nouvelles listes de commandes => et pas des sous-enfants).

Voila donc comment faire fonctionner tout cela. Première opération, supprimer les sections <ContentTypes>…</ContentTypes> ou tout du moins le contenu => <ContentTypes/> dans les 3 Schema.xml :

On sauvegarde le tout et on redéploie… et là, magique :

5/ Charger des données

Une petite dernière chose, avant de passer à la suite… Les listes étant créées, elles seront supprimées, recréées à chaque déploiement depuis Visual Studio. Pour ne pas perdre trop de temps à se recréer un jeu de test, nous pouvons remplir ces listes directement depuis leur définition. C’est ce qu’on appelle les RowData.

Nous allons commencer par ajouter des données dans Pays puis Ville. Cette méthode est aussi très pratique pour remplir automatiquement des listes de paramètres stockées dans SharePoint (ici notre liste de Pays ne change pas tous les jours…). Voila comment faire.

Dans chacun des fichiers Elements.xml des instances de nos listes, nous allons ajouter un bloc de XML :

<ListInstance Title=”Pays”
OnQuickLaunch=”FALSE”
TemplateType=”10000″
Url=”Lists/Pays”
Description=”Liste des pays”>
<Data>
<Rows>
<Row>
<Field Name=”"></Field>
</Row>
</Rows>
</Data>
</ListInstance>

En résumé, les nœuds XML :

• Data : ensemble des données à ajouter
• Rows : collection des lignes (ensemble d’enregistrements)
• Row : 1 ligne d’enregistrement
• Field : champ à valoriser pour l’enregistrement courant.

Donc pour un pays, on aurait (données recueillies sur www.france.fr) :

    <Data>
<Rows>
<Row>
<Field Name=”Title”>France</Field>
<Field Name=”Surface”>543965</Field>
<Field Name=”NbrHabitants”>65350000</Field>
</Row>
</Rows>
</Data>

En on recréée une structure Row pour chacun des pays. J’en ajouterai une petite dizaine pour les tests.

On remarque tout de suite que les pays sont triés sur le nom (alphabétique) alors dans le Schema.xml :

        <Row>
<Field Name=”Title”>France</Field>
<Field Name=”Surface”>543965</Field>
<Field Name=”NbrHabitants”>65350000</Field>
</Row>
<Row>
<Field Name=”Title”>Espagne</Field>
<Field Name=”Surface”>505911</Field>
<Field Name=”NbrHabitants”>46754784</Field>
</Row>
<Row>
<Field Name=”Title”>Angleterre</Field>
<Field Name=”Surface”>130395</Field>
<Field Name=”NbrHabitants”>52234000</Field>
</Row>

Nous allons faire la même chose avec les Villes. Petite différence, le champ lookup qui pointe sur la liste des Pays… Et c’est donc un peu différent. En effet, les champs lookups doivent être renseigné avec ID;#Valeur :

         <Row>
<Field Name=”Title”>Marseille</Field>
<Field Name=”Surface”>240</Field>
<Field Name=”NbrHabitants”>850602</Field>
<Field Name=”Pays”>1;#France</Field>
</Row>
<Row>
<Field Name=”Title”>Madrid</Field>
<Field Name=”Surface”>608</Field>
<Field Name=”NbrHabitants”>3413271</Field>
<Field Name=”Pays”>2;#Espagne</Field>
</Row>

Attention, l’ID et celui dans SharePoint (et donc dans l’ordre d’insertion qui correspond à l’ordre dans l’Element.xml de la liste Pays !)

Et voilà ! Puisque les listes sont supprimées à chaque déploiement, nous n’auront pas besoin de remplacer les ID dans les fichiers Elements.xml.

Dernière vérification, la liste de commandes est-elle bien renseignée ?? Bien sûr que oui !

Par contre on voit tout de suite que Barcelone n’est pas en Allemagne…

Et donc… prochain article… ré-implémenter le comportement de ce formulaire… et faire communiquer nos deux liste déroulantes !

SP2013–Navigation par Métadonnées

 

Bonjour @Tous.

 

Je viens de tester une nouvelle fonctionnalité apportée par SharePoint 2013 en termes de navigation : la navigation par métadonnées.

Dans SharePoint 2010, on pouvait baser sa navigation sur la hiérarchie des objets composant une collection de sites (sites, sous-sites, bibliothèques), on encore ajouter de la navigation par métadonnées sur une bibliothèque de documents par exemple, ou encore établir soi-même cette navigation en administrant chacun des liens dans une sorte d’arborescence pas toujours pratique…

 

Avec SharePoint 2013, Microsoft nous propose de gérer cette navigation au niveau de l’application de service de métadonnées gérées (Managed Metadata) en créant une arborescence qui pourra être partagée entre plusieurs application Web, collection de sites, etc.

Ici encore un effort sur la mutualisation des ressources (partagées) et une centralisation de l’interface d’administration au travers de celle proposée normalement pour administrer la hiérarchie des magasins de termes, groupes, ensembles de termes et bien sûr termes.

Voyons comment ça marche…

 

1/ Premièrement, il faut bien sûr avoir créé le service de métadonnées gérées sur notre plateforme, je vous invite à lire un précédent article : http://kazoumoulox.wordpress.com/2012/07/19/sp2013-managedmetadata/

 

2/ Nous allons maintenant nous rendre sur notre collection de site créée sur le port 80 de mon serveur, dont le site racine est du type “Team Site” :

 

Puis nous nous rendons sur les paramètres du sites (Site settings) :

 

Dans les paramètres de ce site, nous voyons immédiatement que le menu “Navigation” n’apparait pas encore, on nous propose seulement d’administrer les liens de la barre supérieure (horizontale).

 

Pour les aficionados de SharePoint, vous vous souviendrez que le menu “Navigation” n’est affiché que si les fonctionnalité de publication sont activées sur cette collection de site… Nous allons donc les activer, dans le menu “Site collection features”. On recherche la fonctionnalité “SharePoint Server Publishing Infrastructure” :

 

On clique sur “Activate”, on patiente… La fonctionnalité est activée :

 

4/ Revenons dans les paramètres du site, le menu “Navigation” apparait bien :

 

Cliquez sur le lien… Par défaut la navigation par métadonnées n’est pas activée, on la sélectionne donc dans “Global Navigation” (navigation supérieure) et dans “Current Navigation” (navigation latérale) :

 

5/ Juste en dessous, on retrouve un contrôle que l’on connait bien, le treeview présentant les données présentes dans l’application de service de métadonnées gérées :

 

Le term store est assez vide, on retrouve seulement les métadonnées créées dans un post précédent… nous allons donc créer un nouveau Term Store qui hébergera notre navigation. On clique alors sur le lien “Term Store Management Tool”, un nouvelle page s”ouvre sur la console de gestion des termes :

 

On créée alors un Group, un Term Set…

 

Si vous observez les paramètres du Term Set, dans l’onglet “INTENDED USE”, vous trouverez des checkbox permettant de déclarer ce Term Set comme éligible à la gestion de la navigation. Nous allons bien sûr cocher ces checkbox et sauvegarder.

 

Puis on créée quelques termes :

 

 

On remarque tout de suite un onglet “NAVIGATION” dans lequel on se rend et qui propose des options comme la possibilité d’afficher ce terme dans la navigation globale ou courante, le lien associé à ce terme (page appelée sur le clic) :

 

Ou encore un second onglet “TERM-DRIVEN PAGES” qui permet lui d’utiliser des URL friendly (courtes, simples). En fait, le premier onglet vous permet de choisir si vous utiliserez un lien direct ou si vous utiliserez  ce qu’ils appellent les “TERM-DRIVEN PAGES” et il faudra alors se rendre sur l’onglet associé pour paramétrer ce lien (friendly url + lien réel appelé).

 

Il faudra donc faire un choix au niveau de chacun des termes.

 

6/ Dans mon cas, je suis curieux de tester le “TERM-DRIVEN” donc je sélectionne ce mode pour le terme “HR” :

 

Et je me rend donc dans l’onglet “TERM-DRIVEN PAGES”. Je renseigne la “friendly URL” : /hr (par défaut) et change la cible (Change target page for this term) :

 

Je vous passe la création des termes, url, etc. Et on revient donc sur la page d’administration de la navigation, nos nouvelles étiques sont bien chargées :

 

7/ On valide et on se rend sur la page d’accueil du site. On voit tout de suite apparaitre les nouvelles navigations supérieure et latérales :

 

8/ En enrichissant un peu plus le magasin de termes…

 

On parvient rapidement à créer une navigation structurée, avec plusieurs niveaux, des url simples…

 

En conclusion, c’est une belle surprise que cette navigation par métadonnées, cela répond à des problématiques souvent posées dans l’utilisation de SharePoint 2007 & 2010 et qui trouvent enfin solution… sans développement ! Cela reste très simple à gérer, dans des interface d’administration que l’on connait & maitrise. Evidemment ces termes peuvent toujours être utilisés comme métadonnées pour la gestion documentaire.

SP2013–Configuration du service de métadonnées gérées

Nous poursuivons la configuration de la nouvelle ferme SharePoint 2013 avec le déploiement de l’application de service de métadonnées gérées (Managed Metadata).

 

1/ Nous nous rendons donc dans l’administration centrale de SharePoint :

 

Puis il faut se rendre dans la section “Manage service applications” :

 

Puis cliquer sur le bouton “New” du ruban et sélectionne “Managed Metadata Service” :

 

2/ L’assistant de création du service se lance, on remplit les paramètres :

• Nom du service
• Nom de la base de données associée
• Pool d’application avec son compte géré

 

Une fois terminé, le nouveau service s’affiche :

 

3/ Il faut maintenant mettre en place la sécurité sur ce service; on clique sur la ligne du service et sur le bouton “Administrators” dans le ruban :

 

4/ On essaie ensuite de se rendre sur la page d’administration de cette nouvelle application de service, mais bien sûr cela ne fonctionne pas… vous l’aurez noté, nous n’avons pas encore démarré le service sur le serveur !! (pour les yeux avisés…)

 

5/ Il faut alors se rendre sur la page d’accueil de l’administration centrale et cliquer sur “Manage services on server” :

 

Il faut repérer le service “Managed Metadata Web Service” et cliquer sur “Start”. Après quelques secondes, le services est dans le statut “Started” :

 

 

6/ Nous retournons ensuite sur la page d’administration de l’application de service, et là, plus d’erreur. Il nous faut maintenant ajouter quelques groupes, terms set, terms afin d’avoir un peu de données disponibles :

 

7/ Et enfin, tester le tout dans une nouvelle colonne de type métadonnées gérées sur une bibliothèque de documents :

 

En conclusion de ce post, il n’y a que peu de nouveautés concernant cette application de service, le design change mais les fenêtres restent les mêmes avec les mêmes paramètres.

On notera seulement deux petites différences

• Lors de la configuration du magasin de termes, dans SharePoint 2010 nous pouvions seulement utiliser les langues (language packs) qui avaient été installées sur le serveur. Maintenant nous pouvons utiliser d’autres “locales” :

 

• lors de la création des termes set et des terms, un nouveau menu fait son apparition “Pin Term With Children”. Apparemment il permet de réutiliser et lier des termes dans les différents terms sets :

 

Encore une fois, les administrateurs formés à SharePoint 2010 ne seront pas déstabilisés. L’organisation des menus, options et contrôles n’a pas changé entre la version 2010 et cette version Preview 2013.

SP2013–Configuration du service de profils utilisateurs

Dans la continuité du précédent article sur l’installation de SharePoint 2013, nous poursuivons l’installation/configuration avec le déploiement du service de profils utilisateurs (User Profile).

 

1/ Pour commencer, il faut se rendre dans la console d’administration de SharePoint 2013 (Central Admin) :

 

Puis on clique sur “Manage service applications” pour accéder à la page de gestion des applications de service :

 

L’application de profils utilisateurs n’est pas encore créée. On va donc utiliser le bouton “Nouveau” en haut à gauche et sélectionner “UserProfile Service Application” dans la liste des services proposés:

 

On accède alors à la page permettant de configurer le service avant sa création. Tout cela ressemble beaucoup à SharePoint 2010, rien de nouveau, seulement une présentation métro-like. On remplit les champs :

• Nom du service : UserProfile Service Application
• On créé un nouveau pool d’application : UserProfileAppPool
• On configure le compte d’accès géré (dans mon cas j’en créé un nouveau, il n’était pas encore déclaré : labs\spserviceapps)
• Je conserve les noms de base de données proposés, cela me convient.

 

Et enfin on lance la création, cela peut prendre quelques minutes (2 dans mon cas…) :

 

Le service est créé, sans erreur :

 

Il apparait maintenant dans la liste des applications de service :

 

2/ Nous allons maintenant configurer un peu de sécurité sur cette nouvelle application de service, en renseignant les comptes administrateur et les permissions. On sélectionne donc la ligne de l’application de service UserProfile (on ne clique pas sur le lien ).

Je renseigne donc l’administrateur :

 

On valide la fenêtre, et on clique maintenant sur le lien pour se rendre sur la page d’administration du service… et là erreur !

 

Effectivement, petit oubli de ma part, il faut démarrer les services sur le serveur. On repart donc sur la page d’accueil de la Central Admin, on clique sur “Manage services on server” :

 

On accède à la page permettant de démarrer/stopper les services en cours sur les serveurs.

Nous allons donc démarrer les deux services liés à l’application de service UserProfile. On commence par “User Profile Service”, puis “User Profile Synchronization Service” :

 

Il faut renseigner le compte de synchronisation avec l’Active Directory (attention à la délégation “Replicate Directory Changes” obligatoire pour le compte de synchronisation, idem qu’avec SharePoint 2010) :

 

Le service va mettre quelques minutes à démarrer, il va être dans l’état “Starting” puis “Started” si tout se passe bien !

 

3/ On revient alors sur la page d’administration de l’application de service… Ca fonctionne !

 

4/ Je vais maintenant configurer la connexion pour la synchronisation avec l’Active Directory. Je me rend donc dans le menu “Configure Synchronization Connections”. Tout est exactement pareil qu’avec SharePoint 2010…

 

New…

Je complète les paramètres demandés :

• Nom de la connexion
• Type : Active Directory
• Nom de la forêt : Labs
• Compte d’accès pour la synchronisation

 

Et enfin on utilise le bouton “Populate” pour récupérer les utilisateurs, groupes, etc. dans nom contrôleur de domaine :

 

On valide… La connexion est créée !

 

Il faut maintenant configurer la planification de la synchronisation, pour cela on utilise le menu “Configure Synchronisation Timer Job” :

 

Première remarque, la navigation dans la Central Admin (depuis les pages d’administration des applications de service par exemple) n’a pas été améliorée dans cette Preview, il faut souvent remonter à la page d’accueil et re-parcourir les menus… dommage, cela aurait été un gain de temps précieux et une facilité d’utilisation accrue pour les administrateurs.

 

5/ Ensuite, nous allons créer tout ce qu’il nous faut pour utiliser les MySites. Rien de bien compliqué, nous nous rendons sur la page de création des collections de sites (Application Management > Create site collection) et nous créons une nouvelle collection de sites de type MySite Host :

 

On remplit les paramètres :

• Nom de la collection de sites : MySite
• Web Site address : <Url de mon serveur>/sites/MySites
• Template de site : My Site Host dans la section “Enterprise”
• Administrateurs

 

La collection de sites est créée :

 

6/ On se rend ensuite sur la page d’administration de l’application de service UserProfile et nous allons configurer les My Sites :

 

On clique sur “Setup My Sites”. Il faut principalement remplir le champ “My Site Host” avec l’adresse (Url) de la collection de sites précédemment créée :

 

On valide puis on retourne sur la page d’administration du service :

 

7/ Cela sent la fin… il nous reste tout de même à lancer une première synchronisation complète de l’Active Directory. On utilise le lien “Start Profile Synchronization”. Pensez à cocher “Start Full Synchronization”, et “OK” :

 

La synchronisation démarre, on le remarque à droite, dans la zone “Profile Synchronization Settings” :

 

A la fin, la synchronisation est en “Idle”, l’opération est terminée… 39 profils synchronisés dans mon cas, cela semble correct :

 

8/ Dernière étape… TESTER ! Je me rend donc sur mon site “Intranet” créé sur le port 80 et je clique sur le menu “About Me” :

 

On accède à notre user profile !

 

En bilan de cette configuration, les connaisseurs diront qu’il n’y a pas grand chose de neuf sauf dans le design. A l’usage, il est certains que certains problèmes ont du être corrigé… mais il faudra attendre de pouvoir déployer en production sur de grandes infrastructures pour s’en apercevoir. Cela reste toutefois rassurant pour les administrateurs qui ne se sentiront pas “perdu” lors de la mise en place du service, les automatismes pourront être conservés !

 

Prochain article… wait & see

SharePoint 2010 & Visual Studio 2012–Step 5–Nouveautés & Ma première application Silverlight avec OData

Bonjour à tous.

Encore un nouveau billet concernant les nouveautés de Visual Studio 2012 RC pour le développement SharePoint 2010. Petit rappel :

• Installation de Visual Studio 2012
• Création d’un modèle de bibliothèque
• Création d’un type de contenu
• Création d’une colonne de site et association avec un content type

Nous allons rentrer plus en détail dans le développement avec la création d’un WebPart Silverlight permettant de requêter des données par le biais de OData.

Mais me direz-vous, qu’est-ce que OData ? Je vous conseille pour cela un peu de lecture glanée sur le Web :

• OData – Introduction à l’Open Data Protocol
• Open Data Protocol
• Développer et consommer un service OData pour SharePoint 2010
• Using the OData REST API for CRUD Operations on a SharePoint List
• Walkthrough : Creating a Silverlight WebPart that displays OData for SharePoint

Pour résumer, c’est la possibilité d’interroger des données au travers d’un WebService (http/https) via un protocole défini et standardisé retournant du JSON ou ATOM (du XML de reste). Je vous laisse vous documenter sur ce sujet.

Revenons à notre thèmes principal. Comment créer ce WebPart Silverlight, le packager et le déployer dans SharePoint 2010 en utilisant Visual Studio 2012. C’est ce que nous allons voir !

(Je précise que Silverlight n’est pas ma tasse de thé !)

1/ Créer le WebPart dans la solution.

Je vous rappelle que nous avions laissé la solution dans cet état au précédent billet :

Nous avons déjà créé une colonne de site, un content type et un modèle de bibliothèque de documents.

Pour créer notre WebPart Silverlight, commençons par faire un clic-droit sur le projet, puis “Add > New Item”

Dans la fenêtre qui s’ouvre, sélectionner “Silverlight WebPart” et nommons le “WPSilverlight” puis cliquer sur “Add” :

Une nouvelle fenêtre s’ouvre, sélectionner “Create a new…” si ce n’est pas déjà fait. Cela va créer un nouveau projet dans la solution actuelle, de type Silverlight qui abritera tout le projet permettant d’implémenter le contrôle Silverlight. Le projet sera compilé puis les binaires seront copiés dans la solution SharePoint automatiquement. Pratique !

On paramètre donc le nom du projet, le répertoire de création du projet, le langage (C#) puis la version de Silverlight (5.0 dans mon cas, 4.0 est aussi disponible). Puis cliquer sur “Finish” :

Après quelques secondes, le nouveau projet est créé et le designer Silverlight se charge :

Dans le projet SharePoint, une nouvelle fonctionnalité (feature) est créée et référencera tous les fichiers utiles pour notre projet Silverlight en particulier les fichiers XML permettant de référencer notre WebPart dans SharePoint. On retrouve donc le fichier “Elements.xml” et “WPSilverlight.webpart” dans cette feature :

Le fichier “Elements.xml” va permettre de déclarer le que SharePoint doit utiliser le fichier “WPSilverlight.webpart” mais également le fichier XAP produit par le projet Silverlight :

Et dans le fichier “WPSilverlight.webpart” on déclare à SharePoint comment déployer notre WebPart contenu dans la solution. On va par exemple indiquer dans quelle catégorie placer le WebPart, ses dimensions par défaut, son nom dans la galerie de WebParts ou encore un éventuel message d’erreur qui pourra apparaitre lorsque l’utilisateur ne parviendra pas à ajouter ce composant sur une page :

2/ Voyons maintenant ce fameux projet Silverlight :

Un bon nombre de références sont déjà ajoutées au projet, essentielles aux WebParts Silverlight pour SharePoint 2010.

Cependant un certain nombre de références vont nous être utilises afin de requêter en OData des données provenant de SharePoint. Nous allons donc ajouter deux références au projet Silverlight :

• System.Windows.Data
• System.Data.Services.Client

Pour cela, clic-droit sur le répertoire “References” dans le projet Silverlight puis “Add Reference” :

Nous allons rechercher nos deux références dans les Assemblies déjà disponibles sur le serveur :

3/ Notre projet référence maintenant les bonnes Assemblies. Il va falloir ajouter une référence vers le WebService SharePoint 2010 afin de requêter ces données (créer la DataSource).

Pour cela, nous allons ajouter un “Service Reference”. Clic-droit sur le projet, “Add Service Reference” :

Une fenêtre s’ouvre où nous allons saisir l’URL du WebService en question… nous ne la connaissons pas encore, mais cela reste simple ! Pour cela, nous allons juste entrer l’URL de notre site SharePoint. Dans mon cas http://sp2010demo  et on clique sur “Go”. Visual Studio 2012 va rechercher tout seul le service qui doit être exposé par SharePoint :

Une fois trouvé, Visual Studio va rajouter seul le bout d’URL manquant, vous n’avez rien à faire. Il va donc rajouter : /_vti_bin/ListData.svc et présenter le service (Panel de gauche) disponible. Il vous suffit de nommer votre nouveau service (“ServiceReference”) et cliquer sur “OK”.

La référence au service est bien ajoutée au projet Silverlight dans la solution :

4/ Nous allons essayer de compiler la solution afin de vérifier qu’il n’y a aucun problème. Dans mon cas j’ai quelques centaines d’erreurs qui remontent (337 pour être exact) !

Rien de grave, en fait en ajoutant nos références aux Assemblies, le compilateur s’y perd un peu mais rien de dramatique. Afin de supprimer ces erreurs, il vous suffira de supprimer deux références qui ont été ajoutées à la création du projet :

• Microsoft.Data.OData.SL
• Microsoft.Data.Services.Client.SL

On sélectionne donc ces deux références et on les supprime :

On compile, pas d’erreur… c’est la fête :

5/ La référence au service de requêtage des données est ajoutée, nous allons maintenant créer la fameuse DataSource qui nous permettra de “binder” les données provenant de SharePoint à un contrôle Silverlight de manière automatique. Pour cela, on sélectionne la référence au service puis on se dirige sur le menu “DATA” puis “Show Data Sources” :

Sur la gauche, une boite à outils s’ouvre présentant la DataSource récupérer par la référence au WebService SharePoint et on voit immédiatement les listes et bibliothèques SharePoint de notre site apparaitre :

Et là… rien de plus simple ! Ouvrons notre fichier MainPage.xaml contenant la fenêtre principale de notre application Silverlight…

On choisit une liste dans la DataSource (dans mon cas “Premiereliste” qui est l’instance de liste créée lors du déploiement de ma solution SharePoint, à partir du modèle) :

Un coup de Drag&Drop (glisser-déposer… ) et c’est gagné !

Immédiatement, Visual Studio ajoute une DataGrid “bindée” sur notre DataSource dans la fenêtre du designer Silverlight.

il nous reste à fixer les dimensions, aligner, … faire du beau quoi !

Oh que c’est beau…

6/ Et ce n’est pas encore fini, maintenant il nous reste à mettre en place le mécanisme de chargement Asynchrone de notre DataGrid. Pour cela, nous allons faire un tout petit peu de code.

Ouvrons donc le fichier C# associé à notre MainPage.xaml (F7 depuis le designer Silverlight).

Première chose, ajouter les “usings” adéquats :

• using SilverlightProject.ServiceReference //(référence vers le service créé tout à l’heure)
• using System.Windows.Data
• using System.Data.Services.Client

On enregistre, compile. Tout est ok.

Ensuite nous allons créer 3 attributs à la classe :

• private IntranetDataContext context;
• private CollectionViewSource collviewsource;
• DataServiceCollection<PremiereListeItem> premierelistitems = new DataServiceCollection<PremiereListeItem>();

Et enfin implémenter deux méthodes, celle proposée par Visual Studio (UserControl_Loaded) puis dans un seconde temps une deuxième (premierelistitems_LoadCompleted).

La première sera appelée lorsque le UserControl Silverlight aura été chargé (à la fin du chargement du contrôle) et la seconde à la fin du chargement des données depuis la DataSource et qui bindera les données avec le contrôle.

Je ne détaille pas le code, ce n’est pas vraiment pertinent pour l’exemple.

private void UserControl_Loaded_1(object sender, RoutedEventArgs e)
{
    context = new IntranetDataContext(new Uri("http://sp2010demo/_vti_bin/ListData.svc"));
    if (!System.ComponentModel.DesignerProperties.GetIsInDesignMode(this))
    {
       collviewsource = (System.Windows.Data.CollectionViewSource)this.Resources["premiereListeViewSource"];
       premierelistitems.LoadCompleted += new EventHandler<LoadCompletedEventArgs>(premierelistitems_LoadCompleted);
       premierelistitems.LoadAsync(context.PremiereListe);
    }           
}

private void premierelistitems_LoadCompleted(object sender, LoadCompletedEventArgs e)
{
    if (e.Error == null)
    {
       collviewsource.Source = premierelistitems;
    }
    else
    {
       MessageBox.Show(string.Format("Une erreur s'est produite : {0}", e.Error.Message));
    }
}

Bien sûr il faut compiler. Tout doit être Ok. Il nous maintenant à déployer sur notre site SharePoint 2010. Mais avant cela nous allons vérifier que le debug pour les application Silverlight est bien activé. Pour cela, il faut se positionner sur le projet SharePoint, clic-droit, “Properties” :

Dans la partie SharePoint, il faut vérifier que la checkbox “Enable Silverlight debugging…” soit bien cochée. On sauve, compile.

Puis on déploie comme vu dans les précédents billets (F5 pour debugger) :

6/ Le navigateur s’ouvre sur l’accueil de notre site SharePoint. Il nous faut éditer la page d’accueil pour ajouter le composant WebPart :

Dans le ruban, Insérer > Composant WebPart :

Dans la galerie de WebParts, le notre apparait bien dans la section “Custom” => SharePointProject1 – WPSilverlight. On cliquer sur “Ajouter” :

Le WebPart est ajouté :

On sauvegarde la page :

7/ Aucune donnée n’apparait. Normal, la liste est vide ! Ajoutons donc un petit document de test :

Revenons sur la page d’accueil :

Le document que nous venons d’ajouter apparait bien. Vous pouvez directement debugger votre projet Silverlight depuis Visual Studio 2012 au besoin.

Plutôt simple non ? qu’est-ce qu’à ajouté Visual Studio 2012 sur ce mini-développement ? Principalement de nouvelles interface qui ont été intégrées au niveau des DataSources. On peut maintenant requêter très facilement des données SharePoint au travers des services OData et utiliser la source de données produite dans plusieurs type de projet. Cela ne se limite pas au Silverlight. En effet, on pourrait très bien créer une application cliente Métro/WPF qui présenterait ces données de la même manière. Un bon point pour VS2012 !

SharePoint 2010 & Visual Studio 2012–Step 4–Nouveautés & Ma première colonne de site

 

Dans les précédents épisodes, nous avons vu comment installer Visual Studio 2012 sur notre serveur SharePoint 2010 puis comment créer un modèle de bibliothèque de documents et enfin créer un type de contenu à l’aide des divers assistants proposé par l’IDE :

• Installation de Visual Studio 2012
• Création d’un modèle de bibliothèque
• Création d’un type de contenu

Nous allons maintenant voir comment créer une colonne de site avec la nouvelle interface de Visual Studio 2012. Nous en étions resté au point où la solution Visual Studio contenait un modèle de bibliothèque de documents et un type de contenu personnalisé.

 

1/ Nous allons maintenant ajouter une nouvelle colonne de site. Pour cela, il faut faire un clic-droit sur la solution “Add > New Item” :

 

Dans la fenêtre de sélection du modèle d’item, on sélection “Site Column” et on nomme cette colonne. On prendra soin de nommer cette colonne sans espace, caractères accentués, ponctuation, etc.

 

Je vous rappelle que dans Visual Studio 2010, cette option n’existait pas. Nous commençons donc directement avec une nouveauté !

2/ On valide cette fenêtre en cliquant sur “Add”. La fenêtre se ferme et nous arrivons directement sur le fichier XML (“Elements.xml”) contenant la déclaration de la colonne de site. Malheureusement il n’y a pas d’assistant comme pour les types de contenu ou les modèles de listes.

Il va donc falloir directement éditer le fichier XML, mais nous conservons l’usage de l’IntelliSense qui va nous être bien pratique :

 

On peut noter que grâce au fichier XML, nous avons accès à tous les paramétrages de cette colonne comme le nom d’affichage (“DisplayName”), nom interne ‘(“Name”), le type, etc.

Nous n’avons pas non plus d’assistant pour choisir le groupe de classement dans lequel sera classé notre colonne, il faut le faire dans le XML.

 

Donc mis à part l’entrée dans le menu de sélection du type d’item, rien ne change pour la création de colonnes de site (on a tout de même une icone particulière dans l’arborescence de la solution pour ces colonnes de site, et 1 fichier Elements.xml par colonne).

 

Si nous jetons un coup d’œil à la feature, la colonne apparait bien :

 

3/ Essayons d’associer cette nouvelle colonne de site au type de contenu créé précédemment. Pour cela, nous allons rouvrir la définition du type de contenu et sur l’onglet “Columns”, nous avons une interface permettant de rechercher des colonnes de site existantes :

 

On recherche notre colonne de site :

 

Elle apparait bien dans la liste des colonnes proposées (et pourtant elle n’est pas encore déployée sur le site SharePoint. Visual Studio propose donc les colonnes existantes sur le site et celles provenant de la solution courante).

 

On valide et on enregistre la modification :

 

4/ Il nous reste à vérifier qu’en associant ce type de contenu à notre définition de bibliothèque de documents la nouvelle colonne de site apparaisse bien. Pour cela, on rouvre la déclaration du modèle de bibliothèque :

 

Et nous utilisons le bouton “Content Types” en bas de page. On reconnait l’interface déjà utilisée dans les précédents billets :

 

On recherche notre type de contenu en pointant sur le texte “Click here to add a content type”. Ce contrôle va nous permettre de rechercher les types de contenu disponibles. Ici Encore Visual Studio 2012 se base sur les types de contenu déjà déployés dans SharePoint 2010 mais également sur les types de contenu référencés dans la solution Visual Studio 2012:

 

On valide et on va spécifier que ce type de contenu est le type de contenu par défaut disponible sur cette bibliothèque (en utilisant le bouton “Set as Default”) :

 

 

On valide cette fenêtre. Dans la définition de ce modèle de bibliothèque, on voit tout de suite que la colonne de site créée et associée au type de contenu remonte dans la définition :

 

5/ Pour bien faire les choses, il nous reste à déployer le tout. On reprend la manipulation décrite dans un précédent billet :

 

Clic-droit sur la solution > Deploy :

 

Visual Studio nous précise qu’il y a des conflits lors du déploiement (l’instance de liste a déjà été déployée). Je choisi “Resolve Automatically” et Visual Studio supprime l’instance qui était déjà créée et redéploye le package :

Cette résolution d’erreur de déploiement est la même que celle utilisée par Visual Studio 2010.

 

Le déploiement est terminé :

 

On retrouve bien le tout dans SharePoint 2010 :

La colonne de site :

 

Le type de contenu :

 

Et dans le type de contenu, l’association de la colonne de site :

 

On retrouve également l’instance de la liste créée à partir du modèle de bibliothèque :

 

En conclusion, peu de nouveauté pour la création de nouvelle colonnes de site. On notera toutefois qu’avoir une icône spéciale dans l’arborescence est assez agréable (pour une fois ce n’est pas l’icône associée aux fichiers XML ).

 

De plus, au final l’ensemble combiné est agréable d’utilisation, on se retrouve facilement dans les menus et le fait que Visual Studio sache récupérer ce qui est déjà implémenté dans SharePoint mais également le contenu dans la solution (dans le menu d’association notamment) est un vrai plus. Les nouvelles interface sont harmonisée bien que de mon point de vue il manque un “assistant avancé” entre le mode facile et l’édition directe de XML.

Mais plus je joue avec l’interface, plus il me tarde la sortie finale de Visual Studio 2012 !!!

Au projet épisode… un peu de… Silverlight (une fois n’est pas coutume…). Stay Tuned !

SharePoint 2010 & Visual Studio 2012–Step 3–Nouveautés & Mon premier type de contenu

 

Dans les derniers épisodes, nous avons vu comment installer Visual Studio 2012 sur notre serveur SharePoint 2010 puis comment créer un modèle de bibliothèque de documents :

• Installation de Visual Studio 2012
• Création d’un modèle de bibliothèque

Nous allons maintenant voir comment créer un type de contenu avec Visual Studio 2012.

 

Rappelez-vous, dans le précédent billet, nous avions laissé Visual Studio dans cet état :

Notre modèle de bibliothèque “PremiereListe” était créé dans la solution Visual Studio.

 

1/ Ajoutons un nouveau type de contenu. Pour cela, clic-droit que la solution, “Add > New Item” :

 

Dans la fenêtre de sélection du modèle d’”Item”, nous allons choisir “Content Type” et lui donner un nom :

 

2/ Une nouvelle fenêtre se lance permettant de sélectionner le type de contenu parent à celui que nous allons créer. Pour l’exemple, on sélectionne “Document” :

 

 

Et cliquer sur “Finish”. Toujours aucune nouveauté jusqu’ici. Après avoir validé notre configuration, nous arrivons enfin sur quelque chose de nouveau.

4/ En effet, un nouvel assistant va nous aider à configurer notre type de contenu là où avant nous devions recourir à du XML pour associer des colonnes de site à un type de contenu, paramétrer le groupe de classement, etc.

On distingue 2 onglets : Columns et Content Type.

 

5/ Le premier onglet Columns va nous permettre d’associer des colonnes de sites existantes à notre nouveau type de contenu. Nous ne pourrons pas créer de nouvelles colonnes de sites directement depuis cette interface. Pour cela nous devrons recourir à un autre moyen que nous verrons bientôt !

 

Le fonctionnement est très simple, dans la première colonne, on recherche la colonne de site voulue, Visual Studio 2012 remonte automatiquement le type de cette colonne. Nous pourrons spécifier si cette colonne sera obligatoire lors de la saisie faite par l’utilisateur dans l’interface Web de SharePoint :

 

L’interface est simple et intuitive, elle fonctionne exactement comme celle permettant de créer des modèles de listes… on n’est pas perdu !

 

6/ Le second onglet est lui aussi très simple. On retrouve le paramétrage général du type de contenu.

On retrouve le nom du type de contenu, sa description et le groupe dans lequel il sera classé. Petite déception dans cette Release Candidate, impossible de créer notre propre groupe pour classer les types de contenu. On est obligé de choisir dans la liste des groupes existants.

Quelques paramètres supplémentaires : hériter des colonnes du parent, lecture seule du type de contenu et masquer ce type de contenu dans le bouton “Nouveau” des listes/bibliothèques auxquels il sera associé.

 

Pour résoudre le problème de la création d’un nouveau groupe de classement, il nous est possible d’accéder au XML généré (“Elements.xml”) et d’éditer directement ce XML en utilisant en plus l’IntelliSense :

 

7/ Et pour en revenir au billet précédent… comment référencer ce nouveau type de contenu dans notre modèle de bibliothèque de documents précédent ? C’est très simple, pour cela il nous suffit de rouvrir la définition du modèle de bibliothèque de documents et de cliquer sur le bouton “Content Types” :

 

Puis de retrouver dans la liste déroulante :

 

Il est également possible de le paramétrer comme type de contenu par défaut sur notre modèle en utilisant le bouton “Set as Default” (en sélectionnant le bon type de contenu).

 

Pour résumer, Microsoft a intégré des petits assistant simples et pratiques dans sa nouvelle version de Visual Studio (2012 RC) qui vont nous faire gagner du temps et simplifier la création de pas mal d’éléments. On regrettera toutefois de devoir recourir au XML pour les paramétrages avancés !

Mais c’est déjà une belle avancée ! vivement la sortie de la version finale de Visual Studio 2012 !

 

Prochain billet, la création de colonnes de site ! Stay Tuned !