Module #1: La publication

Module #1: La publication



Le premier module à mettre en place constitue la base de votre intranet: La stratégie de publication. Elle définit la manière dont le contenu va être créé et affiché aux utilisateurs. Elle implique donc de définir une gestion des pages et une catégorisation de contenus adaptée.

Dans notre cas, cette adaptation devra se faire selon les concepts de la fonctionnalité de publication intersites de SharePoint.

Rôles concernés et responsabilités

Nous avons identifié les besoins génériques suivant pour le module thématique de publication:

Qui?

Quoi?

Notion(s) clé(s)

Contributeur

[PUB01] Créer, modifier, supprimer du contenu

  • Définition de la structure de gestion de contenu
  • Organisation des catalogues
  • Catégorisation de l’information

Utilisateur

[PUB02] Visualiser les détails d’un contenu

  • Définition de modèle de pages
  • Création de requête de recherche

Utilisateur

[PUB03] Visualiser un ensemble de contenus

Idem

 

 Note importante: L’architecture d’information présentée pour lors de ce cas d’étude évoluera tout au long des différents articles.

La publication en SharePoint

Avant de commencer, expliquons un peu les différences entre les éléments clés des mécanismes de publication en SharePoint 2013 pour bien comprendre les enjeux. Il existe plusieurs moyens de publier du contenu dans cette version:

  • Infrastructure de publication classique SharePoint : présent depuis SharePoint 2007 et basé sur des instances de pages et gabarits liées directement au contenu.
  • Publication intersites (« Cross-Site Publishing » en anglais) : Extension au premier moyen, elle permet la distinction entre les contenus et leurs présentations via l’utilisation de la recherche.

Structure d’une page de publication SharePoint

En SharePoint, dès lors que l’on utilise le procédé de publication classique ou la publication intersites, la structure des pages nécessaire à l’affichage d’informations reste sensiblement identique:

Structure d'une page de publication SharePoint

Structure d’une page de publication SharePoint

 Instance de page : Représente la page physique .aspx présente dans la bibliothèque de pages d’un site de publication SharePoint. Pour rappel, il n’existe aucun endroit où créer des instances de pages autre que cette bibliothèque (sauf par l’intermédiaire d’un « hack »).

 Gabarit de page (« Page Layout » en anglais) : Représente la structure visuelle de la page. Définit notamment les zones pour l’affichage d’informations. Une instance de page est obligatoirement associée à un gabarit de page par défaut et un gabarit peut être utilisé dans plusieurs instances de page.

 Contenu : Représente l’information affichée au sein d’une zone du gabarit. C’est ici que l’on observe les différences dans une approche de publication classique et la publication intersites.

L’infrastructure de publication classique SharePoint

Dans une approche de publication classique, le contenu est affiché par l’intermédiaire de champs de page. Le contenu de ces champs est stocké à même l’élément de page sous forme de métadonnée dans la bibliothèque de pages du site de publication.

Stratégie de publication classique en SharePoint

Stratégie de publication classique en SharePoint

A ce titre, il n’est donc pas possible d’afficher plusieurs informations dans le même champ, la relation établie est donc figée en ce sens qu’une instance de page est obligatoirement liée à ses métadonnées, affichées à travers les champs dans son gabarit.

Le mécanisme de publication intersites

En publication intersites, le contenu est stocké dans une ou plusieurs listes indépendantes, appelées « catalogues » et affiché par l’intermédiaire de composants Web Parts positionnés dans le gabarit associé à la page. La récupération des informations se fait par l’index de recherche et les catalogues peuvent être hébergés dans des collections de sites différentes de celle de publication (mais également dans la même, voire le même site) à travers des sites d’auteurs (« authoring sites »). La publication intersites peut donc être vue comme une extension de l’infrastructure de publication classique de SharePoint dans la mesure où celle-ci est toujours nécessaire pour afficher le contenu quoi qu’il arrive:

Stratégie de publication intersites

Stratégie de publication intersites

Contrairement à la publication classique, il est possible d’afficher des informations provenant de différentes listes depuis la même page physique à travers ses Web Parts et selon le contexte courant.

Le trio instance de page, gabarit et Web Parts forme donc à lui seul un modèle d’affichage générique à l’information. On parle ainside modèle de page (« Page Template »).

Modèle de page = Instance de page + Gabarit de page + Web Parts

Un modèle de page défini une structure générique pour l’affichage dynamique de contenu indépendamment de la source de celui-ci.

Par défaut, lors de la connexion à un catalogue depuis le site de publication, SharePoint vous propose  deux modèles de pages:

  • Une page d’élément : Visualisation des détails d’un élément unique
  • Une page de catégorie : Visualisation de plusieurs éléments appartenant à la même catégorie.

Pour information, vous pouvez choisir d’utiliser une page existante ou bien d’en créer une nouvelle.

Modèles de pages par défaut de SharePoint 2013

Modèles de pages par défaut de SharePoint 2013

Si vous choisissez de créer une nouvelle page dans chacun des cas via l’assistant, SharePoint créera automatiquement pour vous  deux pages contenant chacune un Web Part de type « Réutilisation d’élément de catalogue » (« Catalog Item Reuse » en anglais). À vous ensuite de mettre en forme votre élément.

De manière générale, si vous choisissez d’utiliser la publication intersites pour l’implémentation de votre intranet en SharePoint, vous devrez avant tout définir des modèles de page (autre que ceux générés par SharePoint) qui serviront à standardiser la structure d’affichage de vos contenus indépendamment de leur source.

Dans notre étude de cas, nous avons par exemple défini les modèles de page suivants:

  • Page d’accueil (Home.aspx): Modèle de page utilisé pour la page d’accueil de l’intranet.
  • Page d’élément de contenu (ItemCatalogPageTemplate.aspx) : Modèle de page pour l’affichage d’un contenu unique associé à un lien.
  • Page d’élément de catalogue : (ItemTargetPageTemplate.aspx) :Modèle de page pour la présentation de toutes les nouvelles de l’intranet.
  • Page de catégorie (CatalogCategoryPageTemplate.aspx) :
  • Page de recherche (Search.aspx) : Modèle de page utilisée pour la présentation des résultats de recherche de l’intranet.

Ceux-ci seront expliqués au fur et à mesure de cette série d’articles.

[PUB01] Contributeur : Créer, modifier, supprimer un contenu

Permets à un contributeur de créer un contenu dans le but d’être affiché ultérieurement dans l’intranet.

 

Dans cette étude de cas, les contributeurs de l’intranet seront deux services différents de l’entreprise:

  • Le département des communications qui sera en charge de tous les contenus de l’intranet.
  • Le département des ressources humaines qui s’occupera lui uniquement des contenus liés à son département.

#

Étape

1

Créer la structure de l’intranet

2

Catégoriser le contenu dans les sites d’auteurs

3

Configurer la sécurité

Synopsis

L’utilisation du mécanisme de publication intersites de SharePoint impose une distinction entre la création des contenus et leur affichage. La création de contenu est faite à travers des catalogues hébergés dans des sites d’auteurs tandis que l’affichage est lui réalisé dans un ou plusieurs site(s) de publication.

La réalisation de ce besoin consiste donc principalement à la mise en place de l’architecture d’information et la répartition des contenus dans les différents sites d’auteurs pour permettre la contribution des utilisateurs.

Critères d’acceptation

Les critères d’acceptation ou « Acceptance Criteria » en anglais, permettent de circonscrire le besoin ainsi que ses objectifs :

#

Description

AC0

Les sites d’auteurs et de publication sont accessibles par leur url respectives.

Exemple : Les sites d’auteurs pour les ressources humaines et les communications sont créés.

#

Description

AC1

Il est possible de créer un contenu associé à un unique nœud/lien de la structure du portail. Par conséquent, il n’est pas possible d’associer plusieurs contenus pour un même nœud.

Exemple : Créer le contenu associé à la page « À propos » du menu de navigation.

AC2

Il est possible de créer plusieurs contenus correspondant à une catégorie spécifique de la structure de navigation (ou en dessous de celle-ci).

Exemple : Créer un nouveau contenu de type « nouvelle » et catégorisé « Ressources Humaines ».

#

Description

AC3

Il est possible de mettre à disposition un espace sécurisé de contribution restreint à un groupe de personnes.

Exemple : Les personnes du département « Ressources humaines » ne peuvent pas se connecter sur le site des « Communications » et vice versa.

AC4

Au moins une personne ou un groupe de personnes dispose de la possibilité de créer à la fois des contenus pour les deux scénarios précédents identifiés.

AC5

Il est possible de restreindre la création de contenus à un sous-ensemble de la structure de navigation.

Exemple : ne permettre que la création de contenus de type « nouvelles » catégorisés « Ressources Humaines » pour les contributeurs de ce département.

Étape #1 : Créer les sites d‘auteurs

Le choix des sites d’auteurs dépend principalement des contraintes liées à votre projet et il n’existe pas de règles précises pour leur définition.

  • D’un point de vue technique, un site d’auteurs est un simple site SharePoint contenant des listes hébergeant du contenu destiné à être publiées sur un ou plusieurs sites de publication via les mécanismes de recherche.
  • D’un point de vue fonctionnel, un site d’auteur représente un espace contrôlé de contribution aux contenus de l’intranet. Par exemple, une contribution à travers les différents services de l’entreprise. Nous reviendrons sur la notion de contrôle dans la suite de l’article.

Dans notre cas, les contributeurs seront répartis selon les services de l’entreprise. Ainsi, nous créons un site d’auteurs pour chacun de ces services à l’intérieur de la même collection de sites selon le schéma suivant:

Structure des sites d'auteurs

Structure des sites d’auteurs

 Notes :

  • Il est possible de n’avoir qu’un seul site d’auteurs pour l’intranet. De même, celui-ci pourrait même être le site de publication lui-même. Cependant, même si ce cas se présente, préférez toujours une distinction physique entre le site de publication et le site d’auteur (notamment pour des questions d’évolutivité).
  • Nous utilisons la fonctionnalité de « Host-Named Site Collection » de SharePoint permettant d’assigner une URL de collection de sites à une entrée DNS unique.

La mise en place des sites d’auteurs suit la procédure suivante:

#

Étape

1

Création de la structure des sites d’auteurs

Nous créons une nouvelle collection de sites http://intranet.mycompany.com  qui servira à héberger les sites d’auteurs avec le type « Site de publication » (BLANKINTERNET#0) comme modèle de site:

Création d'un site de publication

Création d’un site de publication

 Pourquoi un site de publication?

Nous utilisons un modèle de site de publication en tant que site racine de la collection pour les sites d’auteurs principalement pour bénéficier, plus tard, des fonctionnalités de variantes et la gestion du multilinguisme. En effet, les variantes de langues SharePoint (« Variations » en anglais) ne sont pas activables sur un site d’équipe à la racine de la collection.

Paramètres de variantes

Paramètres de variantes

En revanche, si le site racine est de type « Site de publication » et qu’il n’existe que des sites d’équipes en dessous, la fonctionnalité de variantes sera disponible également dans ces sites. Nous reviendrons sur ce point plus tard dans le module traitant du multilinguisme.

 Note : Utiliser un modèle de site de publication de type « CMSPUBLISHING#0 », entraine, pour des raisons obscures, un bug au niveau de la page maître du site racine de la collection. Préférez donc le modèle « BLANKINTERNET#0 ».

2

Nous créons les sites d’auteurs « Communications » et « Ressources Humaines » en utilisant un modèle site « Site d’équipe » (STS#0).

Pour cette étape, vous devrez obligatoirement utiliser PowerShell. En effet, SharePoint ne vous laissera pas la possibilité de créer des sites d’équipes sous un site de publication via l’interface graphique:

Impossible de créer un site d'équipe en dessous d'un site de publication

Impossible de créer un site d’équipe en dessous d’un site de publication

En PowerShell

3

Activation de la fonctionnalité de publications intersites

Pour pouvoir bénéficier de la publication intersites sur les sites d’auteurs et pouvoir déclarer des listes SharePoint en tant que catalogue, il est nécessaire d’activer la fonctionnalité «Publication Inter Sites » au niveau de la collection de sites.

Pour ceux qui souhaitent automatiser cette étape, l’identifiant de la fonctionnalité est 151d22d9-95a8-4904-a0a3-22e4db85d1e0.

Activation de la publication intersites sur la collection de sites

Activation de la publication intersites sur la collection de sites

 Note : Il n’est pas nécessaire d’activer cette fonctionnalité sur le site de publication.

4

Activation de la fonctionnalité de publication « Publication SharePoint Server » sur les sous-sites

Nous activons cette fonctionnalité pour pouvoir, bénéficier plus tard, de certaines colonnes de sites ajoutées par celle-ci au niveau des catalogues de contenu.

Activation de la publication SharePoint sur les sous-sites

Activation de la publication SharePoint sur les sous-sites

 

Étape #2 : Catégoriser le contenu

Comme précédemment, dans une approche de publication intersites, la catégorisation des contenus ne peut pas se faire directement sur les pages de la bibliothèque de pages du site de publication étant donné que celles-ci ne constituent que des modèles et ne contiennent aucune donnée.

Cette catégorisation doit donc se faire directement au niveau des sites d’auteurs à travers les catalogues. Or, comment faire le lien entre les contenus de ces sites et les modèles de pages du site de publication ? La réponse est simple : la navigation par taxonomie!

En effet, celle-ci permet de faire le lien entre les contenus des sites d’auteurs et les modèles de pages du site de publication à travers des variables de recherche spécifiques ({Term} et {Term.IDWithChildren} en sont les principales).

Principe de catégorisation de l'information en publication intersites

Principe de catégorisation de l’information en publication intersites

Pour catégoriser le contenu de l’intranet au complet, nous utilisons la stratégie suivante : les catalogues des sites d’auteurs sont associés à un type de contenu principal. Ce type de contenu possède une colonne « Navigation », de type métadonnée gérée, et associée par défaut à un niveau de la hiérarchie de navigation globale de l’intranet permettant ainsi de préciser la catégorie du type de contenu principal.

Stratégie de catégorisation par type de contenu

Stratégie de catégorisation par type de contenu

Les avantages de cette approche sont nombreux :

  • Optimisation de classification : Permet de ne pas surcharger les sites d’auteurs en types de contenus métier (« Nouvelles RH », « Nouvelles Com »). Ainsi avec un minimum de types de contenus principaux partagés par tous les sites d’auteurs, nous pouvons gérer une multitude de catégories « métier » uniquement via les termes de la hiérarchie de navigation de l’intranet.
  • Évolution et maintenance : Permet une grande flexibilité de catégorisation en sous-catégorie via la taxonomie d’entreprise. En effet, la catégorisation « métier » est effectué par l’arbre de taxonomie global et est bien plus facile à maintenir que des types de contenus répartis entre plusieurs sites d’auteurs.
  • Traçabilité : Chaque contenu de l’intranet est obligatoirement lié à un terme de taxonomie dans la hiérarchie de navigation globale de l’intranet. Ce dernier point est particulièrement important car il évite toute perte de contenu dans les sites d’auteurs. Autrement dit, chaque contenu écrit dans l’intranet est obligatoirement catégorisé avec un terme de l’arborescence de navigation.

#

Étape

1

Créer l’arborescence de navigation

Premièrement, nous créons le premier niveau de catégorisation par l’intermédiaire d’un ensemble de termes de taxonomie qui constituera le menu de navigation de l’intranet sur le site de publication. Dans notre exemple, on limitera la navigation de notre intranet de manière très basique:

Arborescence de navigation de l'intranet de cette étude

Arborescence de navigation de l’intranet de cette étude

 Note : Nous définissons le groupe « Portal – Navigation » pour tous les ensembles de termes partagés entre les sites d’auteurs et le site de publication.

Lors de la création, nous spécifions également que cet ensemble sera à la fois utilisé pour la navigation de site (site de publication) et pour la catégorisation (sites d’auteurs).

Configuration de l’ensemble de termes de navigation

Configuration de l’ensemble de termes de navigation

2

Créer les types de contenus

Nous créons ensuite les types de contenus dans les sites d‘auteurs au niveau de la collection de sites. Le deuxième niveau de catégorisation des contenus de l’intranet intervient au niveau des types de contenus partagés entre tous les sites d ‘auteurs. À ce titre, ils doivent être suffisamment génériques pour répondre à la plupart des besoins en matière de contenus.

Nous avons donc défini un certain nombre de types de contenus génériques qui couvrent, de notre point de vue, l’ensemble des contenus d’un intranet de publication en SharePoint au sens large. Pour les déterminer, nous avons réfléchi en termes de cycle de vie de l’information. Ainsi nous distinguons:

  •  Les contenus possédant un cycle de vie long (de l’ordre de plusieurs mois ou année), comme par exemple une page descriptive présentant l’entreprise et ses activités dont le contenu évoluera très peu, voire jamais. Ce type d’information constitue le contenu statique purement informationnel de l’intranet.
  • Les contenus possédant un cycle de vie moyen/court (de l’ordre de quelques jours ou semaines) comme par exemple une nouvelle sur la promotion d’un nouvel employé et dont le contenu ne sera plus pertinent passé quelques jours ou semaines. Ce type d’information constitue la vie de l’intranet grâce à un renouvellement très fréquent.

Les types de contenus que nous utilisons sont donc les suivants :

Cycle de vie court/moyen

  • Nouvelle : Le concept de nouvelle est indissociable d’un intranet car, dans la majorité des cas, il représente son contenu majoritaire. C’est pourquoi nous avons choisi de créer un type de contenu à part entière possédant des métadonnées appropriées comme des images ou vidéos. Ce type de contenu est toujours accédé depuis un catalogue.

Cycle de vie long

  • Élément de contenu: Les éléments de contenu sont liés directement à un seul et unique terme de l’arborescence de navigation. Ils permettent à un contributeur de créer du contenu de page d’accueil, comme une page informative, associée un nœud de navigation particulier. En d’autres termes, un élément d’accueil définit le contenu qui sera affiché lorsqu’un utilisateur naviguera sur le terme en question depuis le menu de navigation. Si vous ne comprenez pas à cet instant de quoi il s’agit, pas de panique, nous aurons l’occasion d’y revenir en détails dans le prochain module : la navigation.

Notre hiérarchie de types de contenus sur les sites d’auteurs de base se présente de la manière suivante:

Hiérarchie de types de contenus d'un intranet de base

Hiérarchie de types de contenus d’un intranet de base

Voici le détail des colonnes:

Champ

Description

Type

Titre

Titre de la nouvelle

Une seule ligne de texte.

Champ par défaut de tout élément de liste de SharePoint.

Navigation

Catégorie de la nouvelle selon l’arborescence de navigation de l’intranet.

Métadonnée gérée.

Associée par défaut à l’ensemble de terme  « Navigation » du magasin de termes.

Configuration de la colonne "Navigation"

Configuration de la colonne « Navigation »

Contenu

Contenu de la nouvelle au format HTML riche.

HTML Riche.

Réutilisation de la colonne de base de SharePoint « PublishingPageContent » (Contenu de la page).

Champ par défaut "PublishingPageContent"

Champ par défaut « PublishingPageContent »

Sommaire

Résumé de la nouvelle en quelques lignes.

Plusieurs lignes de texte.

Image

Image illustrant la nouvelle.

Image de publication.

Réutilisation de la colonne de base de SharePoint « PublishingPageImage » (Image de la page).

Champ par défaut "PublishingPageImage"

Champ par défaut « PublishingPageImage »

Description de l’image

Légende de l’image illustrant la nouvelle.

Plusieurs lignes de texte.

 

L’association des types de contenus des sites d’auteurs selon l’arborescence de navigation se décrit de la manière suivante:

Répartition des types de contenus selon l'arborescence de navigation

Répartition des types de contenus selon l’arborescence de navigation

3

Créer les catalogues dans les sites d‘auteurs

La dernière étape consiste en la création des différents catalogues sur les sites d’auteurs. Nous créons ainsi deux types de catalogues associés chacun a un des types de contenus vus plus haut:

Répartition des types de contenus entre catalogues

Répartition des types de contenus entre catalogues

 Note : L’utilisation du mot « Pages » dans les noms de catalogues est ici intentionnelle. Cela peut vous aider à ce que les utilisateurs assimilent bien que le contenu créé dans ces catalogues sera au final présenté comme une page dans le site de publication. C’est en quelque sorte un moyen simple de leur faire comprendre le principe de la publication intersites. En revanche, pour le nom des types de contenus, nous conservons la notion d’élément de liste SharePoint (« Item »).

La définition de catalogue se fait comme suit:

Définition de la liste en tant que catalogue

Définition de la liste en tant que catalogue

Voici un exemple pour les sites d’auteurs des ressources humaines:

Catalogues de contenus du site des ressources humaines

Catalogues de contenus du site des ressources humaines

 Astuce : Ajoutez des liens rapides vers les catalogues dans le menu rapide (à gauche), cela facilitera la vie des contributeurs.

Étape #3 : Configurer la sécurité

Un des avantages majeurs de la publication intersites est qu’elle permet une répartition et un contrôle de la contribution aux contenus de l’intranet via une organisation en sites d’auteurs.

Là où l’infrastructure de publication classique nécessitait une gestion de la sécurité par dossiers directement dans la bibliothèque de pages, avec à la clé des casse-têtes à n’en plus finir, il est maintenant possible de répartir cette sécurité à des niveaux plus élevés comme des bibliothèques/listes (sous forme de catalogues) ou des sites SharePoint facilitant grandement la maintenance et la gouvernance.

Dans un contexte d’intranet (et dans toute solution de publication), il est au minimum nécessaire de définir une sécurité pour les types de profils suivants :

  • Les contributeurs qui vont participer à la création du contenu sur les différents sites d’auteurs.
  • Les utilisateurs de l’intranet qui vont visualiser ces contenus par l’intermédiaire des modèles de pages du site de publication.

Permissions des contributeurs

 Permissions sur les sites d’auteurs

Les contributeurs doivent disposer au minimum des droits de création, modification et suppression d’éléments sur les différents catalogues des sites d’auteurs. Dans notre cas, nous avons créé un groupe de contributeurs par site d’auteurs auquel nous avons associé les droits de contribution par défaut de SharePoint. Ces permissions sont répliquées par héritage dans tous les catalogues du site:

Configuration des permissions sur les sites d'auteurs

Configuration des permissions sur les sites d’auteurs

Permissions des utilisateurs de l’intranet

 Permissions sur le site de publication

Les utilisateurs doivent disposer au minimum des droits de lecture sur les modèles de pages de la bibliothèque de pages du site de publication:

Permissions sur le site de publication

Permissions sur le site de publication

Permissions sur les sites d’auteurs

Pour visualiser les contenus créés par les contributeurs sur les différents sites d’auteurs, les utilisateurs de l’intranet doivent disposer obligatoirement d’un droit de lecture sur les éléments des catalogues. Pour cela, il existe deux manières de procéder :

  • Si vous disposez de contenus « privés » destinés à n’être visibles que par un groupe restreint d’utilisateurs, définissez des permissions de lecture directement au niveau des catalogues. Ainsi, sur le site de publication, seuls ces utilisateurs ont accès là  visualisation de contenu car la recherche SharePoint tiendra compte de ces permissions. Attention tout de même, ces utilisateurs auront accès à la fois à la visualisation du contenu de l’élément depuis le site de publication (à travers la recherche) mais également à l’élément de catalogue du site d’auteurs associé (c’est-à-dire l’élément dans la liste).
Permissions pour des contenus privés

Permissions pour des contenus privés

  • Si vos contenus sont « publics », c’est-à-dire potentiellement visibles par tous, utilisez alors l’option « Anonyme » dans les paramètres du catalogue du site d’auteurs:
Catalogue "Anonyme"

Catalogue « Anonyme »

Permissions pour des contenus publics

Permissions pour des contenus publics

Cette action aura pour effet de rendre les éléments uniquement visibles à travers la recherche SharePoint. Contrairement à la première situation, les utilisateurs pourront ainsi accéder aux contenus depuis les modèles de pages du site de publication mais non aux éléments du site d’auteurs duquel ils proviennent. Le paramètre « Anonyme » vous permet donc de garder vos sites d’auteurs inaccessibles pour les utilisateurs de l’intranet tout en leur permettant tout de même de visualiser leur contenu sur le site de publication.

Remarque importante : Le fait d’indiquer le catalogue comme « Anonyme », brisera automatiquement l’héritage sur liste. Assurez-vous donc de mettre en place votre sécurité avant de définir les catalogues en tant qu’anonyme:

Attention au bris d'héritage!

Attention au bris d’héritage!

Contrôler la catégorisation de l’information

L’autre sécurité à mettre en place concerne la restriction des possibilités de catégorisation des informations sur les sites d’auteurs. En effet il n’est pas forcément souhaitable que les contributeurs de tous les services de l’entreprise puissent catégoriser l’information n’importe où dans l’arborescence de navigation de l’intranet. Par exemple, un contributeur du site d’auteurs « Ressources Humaines » ne devrait pas pouvoir catégoriser un élément avec un nœud de navigation dédié au service « Communications » et vice versa.

Pour remédier à cela, plusieurs options s’offrent à vous:

 Faire confiance aux contributeurs et espérer que personne ne se trompe de terme de taxonomie dans l’arborescence de navigation.

 Imposer une limite physique aux termes de navigation disponibles lors de la création de l’élément.

Dans notre cas, nous avons opté pour la deuxième solution par l’intermédiaire d’une restriction via une combinaison selon deux critères:

  • Le type d’informations associé aux éléments du catalogue. Par exemple s’il s’agit d’une nouvelle, d’un élément de contenu ou bien d’un élément de catégorie.
  • Le rôle des contributeurs dans le site d’auteurs courant. Par exemple « Ressources Humaines » ou « Communications »

Dans chacun des deux cas, la solution technique reste sensiblement la même : créer un ensemble de termes restreint représentant un agrégat de termes issus de la navigation principale et contenant uniquement des termes autorisés.

Prenons l’exemple du type d’informations « Nouvelle »:

Stratégie de restriction physique de termes de navigation

Stratégie de restriction physique de termes de navigation

Nous créons deux ensembles de termes distincts contenant uniquement les termes autorisés par chacun des services de l’entreprise lors à la création de nouvelles. Ces termes sont des « réutilisations » (i.e. « reused terms ») des termes originalement définis dans l’ensemble de termes global de navigation de l’intranet ». On procède de la même façon pour les deux autres types de contenus des sites d’auteurs.

Pour garder la cohérence au niveau de la navigation par taxonomie utilisée sur le site de publication (qui se base sur un autre ensemble de termes), nous utilisons la fonctionnalité de « réutilisation de termes » fournie par le magasin de termes au lieu de recréer de nouveaux termes. Très pratique, celle-ci permet de conserver l’identifiant unique du terme après réutilisation.  De même, contrairement à la fonctionnalité « Épingler » elle permet de faire une isolation sélective des termes, c’est-à-dire que ceux-ci peuvent être placés dans une hiérarchie cible différente que celle de l’ensemble de termes original.

Ainsi les ensembles de termes définis pour les sites d’auteurs sont les suivants:

Ensemble de termes de navigation globale de l’intranet

Ensembles de termes resteints pour les sites d’auteurs

Ensemble de termes global

Ensembles de termes restreints

Notes:

  • On créer le groupe « Portal – Restricted » correspondant aux ensembles de termes utilisés uniquement dans les sites d’auteurs pour contrôler la catégorisation.
  • Remarque importante: Pour pouvoir conserver la recherche de termes enfants dans la navigation du site de publication, il est impératif de conserver le ou les termes parents de l’ensemble de termes source lors la réutilisation de termes.

C’est notamment le cas du nœud « Nouvelles » comme le montre le principe suivant:

 

Inclusion du terme parent lors de la réutilisation de termes

Inclusion du terme parent lors de la réutilisation de termes

Une fois les ensembles de termes restreints définis, il est nécessaire de configurer la colonne « Navigation » dans les catalogues eux-mêmes en modifiant la configuration par défaut de la colonne de site.

Voici la configuration de cette colonne pour chacun des catalogues de l’étude:

Catalogue

Ensemble de termes associé à la colonne « Navigation »

Site d’auteurs « Communications »

Intranet News Pages

Ensemble de termes "Communications"

Intranet Content Pages

Ensemble de termes "Communications - Content"

Site d’auteurs « Ressources Humaines »

HR News Pages

Ensemble de termes "Human Resources - News"

Ensemble de termes "Human Resources - Content"

Ensemble de termes "Human Resources - Content"

 Pourquoi ne pas créer une colonne de liste « Navigation » directement au niveau des catalogues des sites d’auteurs, si de toute façon, sa configuration sera différente entre les catalogues?

Il est nécessaire d’utiliser une colonne de site, répliquée dans tous les catalogues (grâce au type de contenu) pour permettre la création d’une propriété gérée de recherche de manière automatique. En effet, les colonnes définies à même une liste SharePoint ne génèrent pas de propriété gérée de recherche lors d’une indexation complète. De même, ceci nous permet de n’utiliser qu’une seule propriété gérée pour l’ensemble des catalogues à travers tous les sites d’auteurs selon le principe suivant:

Principe de réutilisation de propriété gérée de recherche pour la navigation

Principe de réutilisation de propriété gérée de recherche pour la navigation

[PUB02] Utilisateur : Visualiser les détails d’un contenu seul

Permets à un utilisateur de visualiser les détails d’un contenu de l’intranet.

Le comportement final souhaité est différent selon que l’on affiche un élément de type « Nouvelle » ou un élément de type « Élément de contenu ».

Nouvelle

La structure d’affichage d’une nouvelle est spécifiée comme suit:

Structure de page pour une nouvelle

Structure de page pour une nouvelle

 La zone d’en tête (« Header Zone ») de la page présente des informations spécifiques de la nouvelle, comme par exemple la date ou l’auteur.

 La zone principale (« Main Zone ») de la page présente le titre et le contenu de la nouvelle.

 La zone de droite (« Right Zone ») représente les sous catégories de l’élément. Cette fonctionnalité sera abordée dans le module #2 : La navigation et le besoin « Utilisateur : Visualiser les sous catégories d’un élément ».

Élément de contenu

La structure d’affichage d’un élément de contenu est spécifiée comme suit:

Structure de page pour un élément de contenu

Structure de page pour un élément de contenu

 La zone principale (« Main Zone ») de la page présente le titre et le contenu de l’élément.

 La zone de droite (« Right Zone ») représente les sous catégories de l’élément. Cette fonctionnalité sera abordée dans le module #2 : La navigation et le besoin « Utilisateur : Visualiser les sous catégories d’un élément ».

 La zone inférieure représente les contenus (« Nouvelles » et « Élément de contenu ») reliés à la nouvelle courante. Cette fonctionnalité sera abordée dans le module #2 : La navigation et le besoin « Utilisateur : Visualiser les contenus reliés à un élément »

#

Étape

Check

1

Créer les sources de résultats de recherche

 

2

Créer le gabarit de page et les modèles de pages

 

3

Créer les modèles d’affichage

 

4

Créer les types de résultats de recherche

 

5

Configurer les Web Parts de recherche dans les instances de pages.

 

Aperçu

Voici un aperçu de la visualisation d’un élément de type « Nouvelle » et d’un élément de type « Élément de contenu ».

Vue d’une nouvelle

Visualisation d'un élément de type "Nouvelle"

Visualisation d’un élément de type « Nouvelle »

Vue d’un élément de contenu

Visualisation d'un élément de type "Élément de contenu"

Visualisation d’un élément de type « Élément de contenu »

Synopsis

Comme vu précédemment, dans une approche de publication intersites, l’affichage des informations se fait grâce à des composants Web Parts disposés dans le gabarit de la page. Cependant, nous allons voir qu’il existe plusieurs possibilités quant au choix des Web Parts à utiliser.

Approche théorique : Le WebPart « Catalog Item Reuse » et ses inconvénients

Si vous en référez aux articles officiels de Microsoft concernant la publication intersites, la théorie veut que, pour afficher les détails d’un élément seul sur une page, il est préconisé d’utiliser le WebPart de type « Réutilisation d’élément de catalogue » ou en anglais « Catalog Item Reuse ».

Web Part "Catalog Item Reuse" dans la galerie de composants Web Parts

Web Part « Catalog Item Reuse » dans la galerie de composants Web Parts

Ce Web Part se contente d’effectuer une requête de recherche sur une seule et unique propriété de l’élément selon le contexte courant et l’afficher « tel quel ». Bien que ce principe soit relativement simple, il présente cependant de nombreux inconvénients que voici :

  • Si vous souhaitez créer un visuel associé uniquement à un type d’élément (par exemple une nouvelle), vous devrez créer obligatoirement un modèle de page à part entière dans la bibliothèque de pages du site de publication. Le problème est que si vous avez des éléments d’affichages en commun entre deux définitions de visuels pour deux types d’information différents, ils devront être dupliqués dans chacun des modèles de page qui leur sont associé. Il s’agit ici donc d’un processus d’affichage à travers 2 couches successives selon le principe suivant:
Processus d'affichage en 2 couches successives

Processus d’affichage en 2 couches successives

  • Vous êtes obligé de créer un composant Web Part « Catalog Item Reuse » pour chacun des champs du type d’information que vous souhaitez présenter dans votre page. Bien qu’il soit possible de mutualiser une seule requête de recherche entre ces différents composants pour une seule et même page, cette solution demeure assez lourde et peu élégante de notre avis.
  • Vous êtes contraint de mettre en forme chacun de ces Web Parts individuellement pour former votre page complète présentant l’élément. De plus, il est impossible de bénéficier de la  fonctionnalité de modèles d’affichage (« Display Template » en anglais) de SharePoint pour ces composants rendant complexe, par exemple, la mise en place de visuel plus élaborés.

Pour tous ces points nous avons donc choisi de suivre une autre approche et donc de ne pas utiliser le composant Web Part « Catalog Item Reuse ».

Notre approche : introduction des types de résultats et modèles d’affichages

Pour l’affichage des informations d’un élément seul en utilisant la publication intersites, nous utilisons les fonctionnalités de types de résultats («Result Types » en anglais). Celle-ci permet, de faire correspondre un contenu, sous plusieurs conditions, dont notamment une source de résultats (« Result Source » en anglais), à un modèle d’affichage particulier définissant le rendu. Les types de résultats sont utilisables uniquement avec le composant Web Part Résultats de recherche (« Search Results » en anglais).  Notre processus d’affichage d’éléments se transforme donc de 2 à 3 couches successives de la manière suivante:

Processus d'affichage en 3 couches successives

Processus d’affichage en 3 couches successives

Ainsi, nous ne faisons plus de distinction physique entre un modèle d’affichage d’un type A et celui d’un type B. Pour nous A et B sont tous deux des éléments ayant la même page modèle physique. La différence d’affichage entre A et B se fait grâce à un modèle d’affichage déterminé par un type de résultat lié au contexte de la page courante.

Les avantages de cette approche sont nombreux:

  • Minimisation du nombre d’instances de pages du côté du site de publication par la consolidationd’éléments communs : Vous regroupez les éléments partagés pour chaque type en un seul modèle de page. A noter que si vos type A et B doivent être affichés de manière totalement différentes (y compris le gabarit de page), vous n’aurez tout de même pas le choix de créer une page modèle physique spécifique.
  • Flexibilité dans les combinaisons d’affichages : Vous permet d’afficher les détails d’un élément d’un type particulier dans plusieurs gabarits différents par l’utilisation des composantes suivantes
    • Modèle d’affichage (« Display Template »)
    • Source de résultats (« Result Source »)
    • Type de résultats (« Result Types »)
    • Web Part de résultats de recherche (« Search Results Web Part »)
  • Permet des visuels élaborés par l’intermédiaire des modèles d’affichages.

Voici la configuration que nous souhaitons réaliser:

Résumé de la configuration pour "Utilisateur: Visualiser les détails d'un contenu seul"

Résumé de la configuration pour « Utilisateur: Visualiser les détails d’un contenu seul »

Critères d’acceptation

Les critères d’acceptation ou « Acceptance Criteria » en anglais, permettent de circonscrire le besoin ainsi que ses objectifs :

#

Description

AC0

Le modèle d’affichage est correctement sélectionné en fonction du type de contenu créé (Page de contenu ou Page de nouvelle)

AC1

Le détail d’un élément est correctement rendu dans le(s) WebPart(s) du modèle de page correspondant.

Astuces  de tests:

Test des modèles d’affichage

Dans les pages modèles créées pour chacun des types de contenus, modifiez la requête de recherche du composant WebPart pour récupérer explicitement un élément de test et générer un résultat. De même, forcez le WebPart à utiliser un modèle d’affichage fixe au lieu des types de résultats.

Test des types de résultats

À ce stade-ci, vous ne disposez pas encore de menu de navigation vous permettant de tester dans les conditions de rendu final. Ici, deux options s’offrent à vous :

  • Utiliser l’outil « Search Query Tool » disponible sur Codeplex (https://sp2013searchtool.codeplex.com/) pour tester les configurations de vos types de résultats :
 des types de résultats avec "Search Query Tool"

des types de résultats avec « Search Query Tool »

Note : Pour récupérer l’Id de votre source de résultats, celle-ci est affichée dans l’URL lorsque vous l’éditez depuis l’application de service de recherche:

Récupération de l'ID d'une source de résultats

Récupération de l’ID d’une source de résultats

  • Modifiez la requête de recherche pour chacune des sources de résultats en spécifiant explicitement un élément déjà indexé et accessible à travers la recherche pour générer un résultat de test.

Étape #1 : Créer les sources de résultats de recherche

La configuration de la source de résultats est la clé de l’affichage dynamique des informations depuis un modèle de page. La requête de recherche configurée doit être suffisamment dynamique pour afficher les informations selon le contexte courant de navigation.

Pour une gestion centralisée, nous avons choisi de créer toutes les sources de résultats depuis l’application de service de recherche dans l’administration centrale.

 Notes sur les sources de résultats:

  • Toutes nos requêtes sont gérées par des sources de résultats. Par soucis de maintenance,  nous n’écrivons AUCUNE requête de recherche au niveau des composants Web Parts eux même.
  • Nous préfixons toutes les requêtes de recherche par l’expression « {?{searchTerms} -ContentClass=urn:content-class:SPSPeople} » qui signifie explicitement que le langage de requête à utiliser sera en KQL (Keyword Query Language). Plus d’informations ici (http://msdn.microsoft.com/en-us/library/office/jj163973(v=office.15).aspx)

Récupération des détails de l’élément courant (Zone principale)

Pour la visualisation des détails d’un contenu unique de l’intranet, nous définissons deux sources de résultats de recherche :

 « Single Catalog Item »: Récupère les éléments accédés à travers un catalogue, comme par exemple les éléments de type « Nouvelles ».

 « Single Target Item »: Récupère les éléments accédés à travers un lien de navigation comme par exemple les éléments de type « Élément de contenu »

Source de résultats

Requête de recherche

Création des sources de résultats

Note : Nous laissons volontairement de côté pour le moment les requêtes de recherche pour ces sources car elles seront expliquées en détails dans le module #2 : La navigation.

Étape #2 : Création du gabarit de page et des modèles de pages

Création du gabarit de page « Target Item Layout »

Nous créons le gabarit de page TargetItemPageLayout.aspx qui sera utilisé pour visualiser les éléments de type « Élément de contenu » sur la base de la spécification précédente:

Gabarit de page TargetItemPageLayout.aspx

Gabarit de page TargetItemPageLayout.aspx

Gabarit de page dans SharePoint

Gabarit de page dans SharePoint

Création du gabarit  de page « Catalog Item Layout »

Nous créons ensuite le gabarit de page CatalogItemPageLayout.aspx qui sera lui utilisé pour visualiser les éléments de type « Nouvelle » sur la base de la spécification précédente:

Gabarit de page CatalogItemPageLayout.aspx

Gabarit de page CatalogItemPageLayout.aspx

Gabarit de page dans SharePoint

Gabarit de page dans SharePoint

Création des instances de modèles de page

Nous créons ensuite deux modèles de page pour la visualisation d’une nouvelle ou d’un élément de contenu

 ItemCatalogPageTemplate.aspx: Modèle de page pour la visualisation d’un élément de type « Nouvelles »

 ItemTargetPageTemplate.aspx: Modèle de page pour la visualisation d’Un élément de type « Élément de contenu ».

Instances des modèles de page dans la bibliothèque de pages

Instances des modèles de page dans la bibliothèque de pages

Étape #3 : Créer les modèles d’affichage

La prochaine étape consiste à créer les modèles d’affichage (« display templates ») qui serviront à la visualisation des métadonnées de l’élément courant (zone principale):

Modèle d’affichage

Nom de fichier

Type

Description

Single News Item Header

Item_SingleNewsItemHeader.html

SearchResults (Item)

Affichage des infos de date et d’auteur d’une nouvelle

Single News Item Content

Item_SingleNewsItemContnet.html

SearchResults (Item)

Affichage des métadonnées d’un élément de type « Nouvelle ».

Single Content Item

Item_SingleContentItem.html

SearchResults (Item)

Affichage des métadonnées de tout autre contenu (types de contenus « Élément de contenu » et « Élément de catégorie »)

Modèles d'affichages d'une nouvelle

Modèles d’affichages d’une nouvelle

Modèle d'affichage pour un élément de contenu

Modèle d’affichage pour un élément de contenu

 Note : Nous distinguons le modèle d’affichage entre une nouvelle et un élément de contenu car, si vous vous en référez aux types de contenus définis dans les sites d’auteurs, ceux-ci ne possèdent pas les mêmes métadonnées et devront donc être présentés différemment.

Ces modèles d’affichages seront utilisés dans les modèles de pages définies plus haut par l’intermédiaire de composants WebParts de recherche.

Modèle d’affichage

Utilisé dans le modèle de page

Single News Item Header

ItemCatalogPageTemplate.aspx

Single News Item Content

ItemCatalogPageTemplate.aspx

Single Content Item

ItemTargetPageTemplate.aspx

Remarques:

  • Les modèles d’affichage de la zone principale doivent être prévus pour occuper tout l’espace de cette zone.
  •  Définissez un rendu d’image dans votre site d’auteur si votre type d’élément à afficher contient une image.
  •  Leur type doit être « SearchResults » car destiné à être utilisée à travers un Web Part « Résultats de recherche », qui est le seul composant supportant la fonctionnalité les types de résultats:
Attention au type de modèle d'affichage

Attention au type de modèle d’affichage

 Modèles d'affichage sur le site de publication

Modèles d’affichage sur le site de publication

Étape #4 : Créer les types de résultats de recherche

Les types de résultats ont pour but de faire correspondre une source de résultats et un type de contenu (issu des sites d’auteurs) à un des modèles d’affichage créés dans l’étape précédente selon le principe suivant:

Result Source + ContentTypeId = DisplayTemplate

Plusieurs choses sont à noter ici:

  • Ceux-ci doivent être créés au niveau du site de publication directement.
  • On utilise par la propriété gérée de recherche « ContentTypeId » comme condition manuelle du type de résultats. N’utilisez pas ceux prédéfinis car ils correspondent aux types de contenus du site courant et non ceux des sites d’auteurs.
Exemple de définition d’un type de résultats de recherche

Exemple de définition d’un type de résultats de recherche

On définit ainsi les types de résultats pour chacun des types de contenus des sites d’auteurs avec les conditions suivantes:

Nom du type de résultat

Source de résultats

Type de contenu

Modèle d’affichage

News Page

Single Catalog Item

News Item

Item_SingleNewsItem.html

Content Page

Single Target Item

Content Item

Item_SingleContentItem.html

Définition des types de résultats sur le site de publication

Définition des types de résultats sur le site de publication

A noter que nous n’utilisons pas de type de résultat de recherche pour les éléments de même catégorie car nous spécifions directement le modèle d’affichage à utiliser à même le WebPart de recherche.

Remarque

Vous avez peut être remarqué ce message lors de la création de votre type de résultats via l’interface SharePoint:

Synchronisation des types de résultats

Synchronisation des types de résultats

Cela signifie qu’après la  création de votre type de résultats, SharePoint scannera automatiquement le modèle d’affichage renseigné et détectera les propriétés gérées ajoutés dans la définition de celui-ci en tant que « Mappings »:

"ManagedPropertyMapping"

En revenant à l’interface de gestion des types de résultats du site, vous verrez ensuite apparaître le message suivant, vous invitant à synchroniser ces propriétés:

Avertissement de synchronisation

Synchronisation terminée

Il est important de noter que si vous ne les synchronisez pas, elles ne contiendront aucune valeur dans votre modèle d’affichage même après une indexation complète de recherche.

Pour éviter cette opération manuelle, préférez l’utilisation de la commande PowerShell New-SPEnterpriseSearchResultItemType et son paramètre –DisplayProperties qui permet de spécifier les propriétés à synchroniser directement lors de la création du type de résultats.

Étape #5 : Configurer les Web Parts

La dernière étape consiste à insérer les différents Web Parts dans le modèle de page et les configurer en fonction des comportements souhaités. Pour rappel, la zone principale servira à afficher les métadonnées de l’élément courant. Nous aurons besoin d’un seul composant Web Part pour le moment pour construire le modèle de page pour la visualisation des détails d’un élément unique:

Disposition des Web Parts pour un élément unique

Disposition des Web Parts pour un élément unique

Nous utilisons des Web Parts de type « Résultats de recherche » et non « Recherche de contenu » car ce sont les seuls qui supportent la fonctionnalité de types de résultats SharePoint.

Web part de résultats de recherche dans la galerie de composants Web Parts

Web part de résultats de recherche dans la galerie de composants Web Parts

Configuration

Valeur

Zone

Zone principale


Source de résultats de recherche

 Single Catalog Item dans le cas de la page « ItemCatalogPageTemplate.aspx »

 Single Target Item dans le cas de la page « ItemTargetPageTemplate.aspx »

Configuration de la requête

 Remarque : N’oubliez pas de supprimer la variable « {searchboxquery} » présente par défaut.


Modèles d’affichages

Utilise les types de résultats

Utilisation de la configuration par défaut


Paramètres généraux

Dans le cas du Web Part de la zone principale, il est préférable de le limiter à 1 pour ne visualiser que les détails de l’élément en cours. Nous verrons par la suite dans le module de navigation, la manière de s’assurer de ne récupérer que les informations de l’élément courant grâce à la navigation par taxonomie.

De même, désactivez toutes les options non nécessaires pour éviter toute pollution visuelle.

Paramètres généraux

[PUB03] Utilisateur : Visualiser un ensemble de contenus

Permets à un utilisateur de visualiser un ensemble de contenus appartenant à une catégorie (nouvelles).

Le comportement souhaité est le suivant:

Structure d'une page de catégorie

Structure d’une page de catégorie

 La zone principale contiendra les éléments de la catégorie courante de navigation (ici les nouvelles).

 La zone de droite contiendra des filtres sur les sous catégories de celle courante.

 La zone d’en tête contiendra le contenu descriptif de la page. Cette fonctionnalité sera abordée lors du module #2 : La navigation et le besoin « Contributeur : Créer du contenu pour un nœud de navigation».

#

Étape

Check

1

Créer les sources de résultats de recherche

 

2

Créer le gabarit de page et les modèles de pages

 

3

Créer les modèles d’affichage

 

4

Créer les types de résultats de recherche

 

5

Configurer les Web Parts de recherche dans les instances de pages.

 

6

Configurer la navigation par facettes

 

Aperçu

Voici à quoi ressemble la page finale de notre cas d’études montrant la liste de toutes les nouvelles:

Visualisation d'un ensemble de contenus d’une catégorie

Visualisation d’un ensemble de contenus d’une catégorie

 Commentaires : Nous utilisons une disposition sous forme de grille pour faciliter la lecture et aussi présenter plus de nouvelles dans une seule et même page. Le menu à droite agit comme filtre dynamique. Il s’agit ni plus ni moins que du mécanisme de raffinement de recherche déjà bien connu en SharePoint et qui sert ici de contrôle navigation contextuelle.

Synopsis

L’affichage d’un ensemble d’éléments correspondant à une catégorie fait principalement référence aux parcours de toutes les nouvelles de l’intranet.  Nous souhaitons obtenir un comportement générique quelle que soit la catégorie sélectionnée.

Critères d’acceptation

Les critères d’acceptation ou « Acceptance Criteria » en anglais, permettent de circonscrire le besoin ainsi que ses objectifs :

#

Description

AC0

Le modèle d’affichage est correctement sélectionné en fonction du type de contenu créé (Page de nouvelle).

AC1

La liste des éléments correspondant à la catégorie courante et également les sous-catégories est correctement rendue dans le(s) WebPart(s) du modèle de page correspondant.

AC2

Il est possible de filtrer par catégorie et par date les éléments affichés dans le modèle de page.

AC3

Il est possible de parcourir les pages de résultats s’il en existe plusieurs.

Note : Les astuces de tests sont les mêmes que pour le besoin [PUB02] Utilisateur : Visualiser les détails d’un contenu seul.

De même, pour tester ici, remplacer simplement la valeur de {Term.IDWithChildren} avec la valeur réelle d’un terme d’une catégorie dans la structure de navigation (voir plus bas).

Étape #1 : Créer la source de la source de résultats de recherche

Récupération des éléments de la catégorie courante (Zone principale)

Le but de cette source de résultats est d’isoler les contenus qui ont été identifiés avec la catégorie courante de navigation mais aussi avec possiblement les sous catégories. Elle va nous permettre notamment d’illustrer quelques concepts de recherche fondamentaux en SharePoint 2013:

  • « Catalog Category Items » : Récupère les éléments associés à la catégorie courante et les sous catégories.

Source de résultats

Requête de recherche

Source de résultats "Catalog Category Items"

Requête "Catalog Category Items"

 Explications

  • GPP|{Term.IDWithChildren} : Cette condition récupère tous les contenus ayant été taggués avec:
    • Soit la catégorie de navigation courante.
    • Soit une sous-catégorie de la catégorie de navigation courante (peu importe le niveau dans l’ensemble de termes).

A ce stade, il est important bien de comprendre cette notion pour pouvoir l’utiliser efficacement dans le reste de notre solution. Pour cela prenons un exemple très simple:

  1. Créez un ensemble de termes dans le magasin de termes avec une hiérarchie à 3 niveaux:
    Exemple de structure hiérarchique

    Exemple de structure hiérarchique

  2. Créez une colonne de site avec le nom « TaxonomyLevel » de type « Métadonnées gérées » associez là à cet ensemble de termes.
  3. Créer une liste « Taxonomy Hierachy » personnalisée et ajouter cette colonne.
  4. Créer trois éléments tagués avec chacun des niveaux de cet ensemble de termes:Éléments dans la liste
  5. Exécutez une indexation complète. SharePoint va créer automatiquement la propriété gérée de recherche « owstaxIdTaxonomyLevel ».
  6. Observez la valeur contenue de cette propriété (avec un outil comme « Search Query Tool » par exemple) correspondant à la colonne de taxonomie pour les trois éléments créés dans la liste:
    Identifiants des termesVoici les valeurs obtenues de la propriété gérée owstaxIdTaxonomyLevel:
    Élément
    Valeur
    Item Level 1
    GP0|#1551a339-7770-41b2-a483-6988cbfd6e27;
    L0|#01551a339-7770-41b2-a483-6988cbfd6e27|Level 1;
    GTSet|#4211218d-8a7a-4eef-a826-ed3267e7c991

    Item Level 2
    GP0|#53764643-85f9-44d6-80c9-5f67a40c7d2f;
    L0|#053764643-85f9-44d6-80c9-5f67a40c7d2f|Level 2;
    GTSet|#4211218d-8a7a-4eef-a826-ed3267e7c991;
    GPP|#1551a339-7770-41b2-a483-6988cbfd6e27

    Item Level 3
    GP0|#7f94f4b0-40f2-4ee7-b8ed-6ee5922e9d50;
    L0|#07f94f4b0-40f2-4ee7-b8ed-6ee5922e9d50|Level 3;
    GTSet|#4211218d-8a7a-4eef-a826-ed3267e7c991;
    GPP|#53764643-85f9-44d6-80c9-5f67a40c7d2f;
    GPP|#1551a339-7770-41b2-a483-6988cbfd6e27

Ce que l’on peut en déduire :

  • GP0 : Représente le terme courant
  • L0 : Même chose que GP0 mais avec le label du terme associé
  • GTSet : Représente l’ensemble de termes du terme courant
  • GPP : Représente tous les parents jusqu’à la racine du terme courant

La recherche des éléments de la catégorie courante ou bien des sous-catégories, s’effectue donc par combinaison de l’identifiant unique du terme issu de la navigation courante (récupéré grâce à la variable Term.IDWithChildren) et le mot clé de hiérarchie « GPP » propres à chaque éléments.

De manière générale, et pour la suite de cet article, voici les variables de recherche utiles, ainsi que leur comportement, lors de la création de solution SharePoint 2013 « pilotées par la recherche »:

La variable de recherche

Est remplacé dans la requête par…

Et recherche sur le token…

{Term}, {Term.ID}

#0+ <GUID du terme>

L0

{Term.IDWithChildren}

# + <GUID du terme>

GP0, GPP

{TermSet}, {TermSet.ID}

<GUID de l’ensemble de termes>

GTSet

 Notes :

  • « GPP|{TermIDWithChildren} » = « GPP|#{Term} »
  • Si vous avez tout suivi, vous remarquerez qu’il n’est pas nécessaire de spécifier explicitement la clé « GPP » avant la variable {Term.IDWithChildren} pour récupérer les éléments des sous catégories. Cependant, pour plus de précautions, nous préférons l’inclure tout de même.
  • Vous trouverez plus d’informations sur les variables de recherche de recherches via la page TechNet dédiée  http://technet.microsoft.com/en-us/library/jj613136.aspx

Étape #2 : Création du gabarit de page et des modèles de pages

Création du gabarit de page « Catalog Category Layout »

De la même manière que l’implémentation du besoin précédent, nous créons un gabarit de page selon la spécification du besoin:

Gabarit de page "Catalog Category  Layout"

Gabarit de page « Catalog Category Layout »

Gabarit de page "Catalog Category  Layout" dans SharePoint

Gabarit de page « Catalog Category Layout » dans SharePoint

Création de l’instance de modèle de page

Nous créons ensuite le modèle de page CatalogCategoryPageTemplate.aspx pour la visualisation des contenus de type « Nouvelles » selon le gabarit précédent:

Création de l'instance du modèle de page pour l'affichage de toutes les nouvelles

Création de l’instance du modèle de page pour l’affichage de toutes les nouvelles

Étape #3 : Créer les modèles d’affichage

Nous créons ensuite les modèles d’affichages correspondants:

Modèle d’affichage

Nom de fichier

Type

Description

Single News Category Result

Item_NewsCategorySingleResult.html

SearchResults (Item)

Affiche les nouvelles sous forme de liste.

Category Filter

Item_CategoryFiltrer.html

Filter

Affiche les filtres d’affinements de recherche pour les nouvelles.

Modèles d'affichage pour la visualisation d'un ensemble de contenus

Modèles d’affichages pour la page des nouvelles

Modèles d'affichage pour une catégorie dans le gestionnaire de conception

Modèles d’affichage pour une catégorie dans le gestionnaire de conception

 Note:

  • N’oubliez pas d’utiliser le bon type de modèle d’affichage pour les affinements de recherche:

"Refinement" Display Template

Étape #4 : Configurer les types de résultats

Pour l’affichage de toutes les nouvelles en zone principale, nous créons un seul type de résultat associé à un modèle d’affichage:

Nom du type de résultat

Source de résultats

Type de contenu

Modèle d’affichage

News Category Items

Category Items

News Item

Item_NewsCategorySingleResult.html

 Création du type de résultat de recherche pour l'affichage de toute les nouvelles

Création du type de résultat de recherche pour l’affichage de toute les nouvelles

Étape #5 : Configurer les Web Parts

Dernière étape de configuration : la configuration des Web Parts sur la page. Nous aurons besoin de deux composants pour construire le modèle de page pour l’affichage de la liste des nouvelles de l’intranet :

  • Web Part de la zone principale : affichera la liste des nouvelles.
  • Web Part de la zone de gauche : permettra de filtrer dynamiquement sur la liste des nouvelles.
Positionnement des Web Parts pour le modèle de page de catégorie

Positionnement des Web Parts pour le modèle de page de catégorie

Les configurations sont les suivantes:

Configuration

Valeurs

Zone

Zone principale

Zone de gauche

Type

Résultats de recherche

Search Results Web Part

Panneau d’affinement

Refinement Panel Web Part

Source de résultats de recherche

« Category Item »

Non applicable

Modèles d’affichages

Utilise les types de résultats

Utilise la configuration des affinements

Utiliser la configuration par défaut

Paramètres généraux

Voici notre configuration arbitraire. Nous gardons la gestion des pages et le nombre de résultats. Notre disposition d’affichage étant sous forme de grille, nous limitions le nombre de résultats par page à 12 (4 lignes de trois nouvelles):

Paramètres généraux

Non applicable

Étape #6 : Configurer la navigation par facettes

La navigation par facettes permet de configurer des filtres de raffinement de recherche en fonction du contexte de navigation courant. Nous les utilisons pour la page de catégorie pour simuler une navigation contextuelle.

Typiquement, une facette est un filtre sur une propriété gérée de recherche qui servira à filtrer les résultats courants. Afin d’éviter de devoir à configurer ces filtres dans le composant WebPart lui-même, leur configuration est centralisée au niveau du site SharePoint laissant ainsi ceux-ci le plus générique possible.

Exemple de la navigation par facettes

Configuration de la navigation par facettes

À ce stade-ci de la réalisation, nous configurons les facettes suivantes:

  • La catégorie de l’élément (sa place dans la hiérarchie de navigation de l’intranet)
  • Sa date de création
Configuration de la navigation par facettes pour la page des nouvelles

Configuration de la navigation par facettes pour la page des nouvelles

 Note : Attention, la configuration de la navigation par facette est accessible uniquement depuis le site SharePoint lui-même et non directement depuis l’application de service de métadonnées gérées.

Onglet de configuration de la navigation par facettes

Onglet de configuration de la navigation par facettes

De même, avant de pouvoir configurer les filtres de raffinement, vous devez activer cette fonctionnalité au niveau de l’ensemble de termes:

Activation de la navigation par facettes sur le terme de taxonomie

Activation de la navigation par facettes sur le terme de taxonomie

Résumé de la thématique

Dans ce premier module, nous avons vu comment mettre en place notre stratégie de publication basée sur la publication intersites pour répondre aux besoins suivants :

  • Contributeur : « Créer. Modifier, supprimer un contenu » (PUB01)
  • Utilisateur : « Visualiser les détails d’un contenu seul » (PUB02)
  • Utilisateur : « Visualiser un ensemble de contenus »(PUB03)

D’un point de vue technique nous avons mis en place :

  • La structure des sites d’auteurs et de publication.
  • Les catalogues et types de contenus de l’intranet.
  • Les bibliothèques d’images.
  • Les modèles de pages à utiliser.

Il s’agit ici de la première étape fondamentale d’une solution de publication. La prochaine consiste à gérer l’accès aux contenus à travers à la navigation. Dans le prochain module, nous verrons donc comment utiliser la navigation par taxonomie de SharePoint 2013 pour s’adapter à notre architecture d’information.

Restez à l’écoute!

Questions fréquemment posées

Pour quoi n’utilisez-vous pas le modèle de site SharePoint de catalogue de produit par défaut?

Nous n’utilisons pas le modèle de site « Catalogue de produit » car il impose un certain nombre de limites comme notamment concernant la gestion du multilinguisme par exemple. (Un exemple parmi beaucoup d’autre : la page VariationRoot.aspx n’est pas définie automatiquement en page d’accueil). L’autre raison est que nous n’adoptons pas l’implémentation standard de la publication intersites comme préconisé par Microsoft, mais une version adaptée à notre cas.

J’ai besoin que le contenu soit affiché instantanément dans mon intranet, si j’ai bien compris,  la publication intersites n’est pas adaptée?

Un amalgame est souvent fait entre les contenus urgents et les contenus planifiés lorsque l’on parle d’affichage instantané dans un portail (internet, extranet, intranet).

Bien souvent, les contenus d’un intranet (nouvelles, articles, etc…) sont identifiés longtemps à l’avance. Par exemple, si vous souhaitez écrire un article à un instant T mais que vous souhaitez qu’il soit publié à T+2, alors il est tout à fait possible de le faire avec notre stratégie, on parle alors de publication contrôlée.

En revanche, le mot « Instantané » rime très souvent avec la notion « d’urgence », c’est-à-dire un événement non prévu qui doit être communiqué rapidement (ex : un problème informatique). Dans ce cas de figure, nous préférons parler d’alertes et avons créé en conséquence une fonctionnalité permettant de créer un communiqué concis sur l’évènement en cours, qui lui sera visible dès sa publication aux utilisateurs. Rien ne vous empêche de créer, par la suite, une nouvelle qui explique le problème plus en détails.

Que se passe-t-il si je souhaite insérer du texte ou du contenu brut à l’intérieur d’un modèle de page comme un texte de bienvenue?

Pour gérer le contenu brut dans un modèle de page, il existe plusieurs possibilités qui présentent chacune leurs avantages et inconvénients :

  • Créer une nouvelle instance de page et inclure dans le gabarit de page une zone Wiki éditable par un contributeur.
  • Gérer ce contenu manière dynamique dans des sites d’auteurs de la même manière que le reste du contenu (« Nouvelle » par exemple). Nous utilisons cette approche, qui sera détaillée dans le module traitant de la navigation.

Votre solution est-elle compatible en Office 365?

Non et la raison est simple : bien que les stratégies de publication intersites utilisées soient valides en Office 365, le gros problème vient de la capacité à automatiser et à reproduire les mêmes développements personnalisés dans la plateforme. En effet, les possibilités sont bien plus restreintes comparées à la version On-Premises de SharePoint 2013. Je ne dis pas que ceci est impossible mais que cela prendrait surement un temps considérable à reproduire. Le portage est donc prévu mais pas pour tout de suite.

De manière générale, c’est à notre sens, ce qui fait défaut à  plateforme dans l’état actuelle : sa difficulté à offrir un cadre de déploiement professionnel pour des solutions de ce genre (qui impliquent bien plus que des Apps!) à fonctionnalités égales. Il est pour nous impensable de réaliser des déploiements manuels chez nos clients pour ce type de projet.

Qu’en est-il de la gestion du changement pour l’utilisateur et le concept de publication intersites?

La publication intersites apporte très certainement un certain nombre de changement radicaux aux outils CMS classiques. On remarque globalement que la gestion du changement induite par cette fonctionnalité est relativement périlleuse, déjà pour les habitués de SharePoint, mais encore plus pour les utilisateurs finaux.

La publication intersites, un concept qui s’explique mal aux utilisateurs…

C’est tout le paradoxe de cette fonctionnalité : une grande amélioration technique de la gestion des contenus de publication dans SharePoint mais un non-sens fonctionnel total pour les utilisateurs de tous les jours.

Un développeur ou un architecte trouvera surement le concept de décentralisation de l’information brillant, nous les premiers, mais qu’en est-il de l’utilisateur « contributeur »? Allez expliquer à votre utilisateur :

  • Que le contenu qu’il est en train de créer ne s’affichera pas instantanément sur le site intranet une fois approuvé et qu’il faudra attendre un temps arbitraire fixé par son administrateur pour qu’il le soit.
  • Que le contenu qu’il est en train de créer sera affiché de manière différente dans le site intranet final dans un gabarit déjà défini pour lui et sur lequel, il n’a pas le contrôle.

La première chose qu’il vous répondra sera surement que son ancien outil de publication, malgré le fait qu’il date de 10 ans, lui, le faisait… Vous aurez beau lui expliquer le concept en long, en large et en travers et les bénéfices qu’il apporte, dans la tête de votre utilisateur cela restera toujours un non-sens fonctionnel. Bien évidemment, il existe des utilisateurs qui comprendrons tout de suite les enjeux et qui seront l’aise avec ça, mais globalement, le principe reste mal compris et davantage conçu pour répondre à des considérations techniques que fonctionnelles.

Avant de commencer un projet utilisant la publication intersites, armez-vos donc de patience et d’une stratégie solide pour convertir vos utilisateurs…

Quels sont, au final, les bénéfices d’utiliser une telle approche par rapport à la publication standard de SharePoint?

Le choix de la publication intersites ne doit pas être pris à la légère dans la conception de votre solution, car elle représente un gros travail d’architecture par rapport à la publication standard.

Cependant un des avantages non négligeable de cette solution est de pouvoir s’appuyer sur la flexibilité qu’offre la brique « Recherche » de SharePoint qui nous permet de modifier la logique d’affichage de contenu de manière très simple à travers des composants natifs (« Out of the box ») facilement modifiables. Lorsque votre projet devient plus compliqué en terme de logique d’affaires, c’est ici que la publication classique trouve ses limites, vous faisant basculer vers des solutions trop personnalisées.

Voici pour vous guider, voici un tableau comparatif des points à considérer pour choisir tel ou tel type de mécanisme de publication dans SharePoint pour votre solution :

Les points qui pourraient vous faire choisir entre…

La publication intersites

La publication standard

  • Ciblage de contenu à réaliser (adaptation de contenus en fonction de caractéristiques de l’utilisateur)
  • Beaucoup de logique d’affaires
  • Beaucoup de types de contenus différents à gérer
  • Intégration à la brique « Collaboration » dans un environnement SP 2013 existant
  • Environnement décentralisé avec de multiples contributeurs
  • Sécurité à gérer au niveau du « tagging » de contenus
  • Évolution UI fréquente
  • Peu de types de contenus à gérer
  • Peu de logique d’affaires
  • Peu de contributeurs
  • Pas de sécurité à gérer au niveau du « tagging » de contenus.
  • Peu d’évolution UI envisagée.

Comme vous l’aurez compris, cette architecture est réservée plutôt aux « gros » projets.

Les scripts utilisés

Voici la liste des commandes et scripts utilisés pour l’implémentation de des besoins de la thématique Publication.

Dynamite-logo4

Action


 

PowerShell


C#


Créer des sources de résultats de recherche

Créer des types de résultats de recherche

Créer des catalogues dans les sites d’auteurs

 

Créer une structure de sites SharePoint

 

Créer une structure de sous sites SharePoint

 

 Attention : Notre Framework est en constante évolution et il se peut que certaines procédures d’installations ou noms de commandes changent. Pour vous tenir au courant des dernières modifications, n’hésitez pas à nous suivre sur GitHub et www.gsoft.com.

De plus si vous souhaitez en savoir plus sur nos pratiques de développement SharePoint, consultez le lien suivant : http://g.gsoft.com/sharepoint/intro

+ There are no comments

Add yours