Article d’origine publié le lundi 3 décembre 2012

Le recours à un contexte pour représenter l’utilisateur actuel dans la recherche a été introduit dans FAST Search pour SharePoint 2010. Si vous souhaitez en savoir plus sur ce procédé dans SharePoint 2010, consultez le billet suivant : http://blogs.technet.com/b/speschka/archive/2009/12/09/using-custom-properties-to-create-a-fast-search-for-sharepoint-2010-user-context.aspx. Comme SharePoint 2013 n’offre pas tout à fait la même fonctionnalité, nous devons la remplacer par une autre fonctionnalité intitulée « segmentation d’utilisateur ». Mais plutôt que de vous expliquer ce que sont les segments d’utilisateur et leur mode de fonctionnement, je vais simplement vous inviter à prendre connaissance du formidable travail accompli par un membre de notre équipe de recherche : http://blogs.msdn.com/b/adaptive_experiences_in_sharepoint_2013/archive/2012/11/14/set-up-user-segmentation-to-drive-adaptive-experiences-in-a-product-catalog-in-sharepoint-2013.aspx. Je vous encourage vraiment à lire ce billet de blog qui est très bien expliqué et qui comprend un exemple illustrant l’utilisation de la segmentation d’utilisateur.

Je n’ai pas du tout l’intention de m’attribuer les mérites du travail précédemment effectué, mais voici ce qui a motivé ma décision. Quand vous lirez ce billet, vous verrez qu’il mentionne la nécessité d’écrire un composant WebPart personnalisé qui détermine les segmentations d’utilisateur à appliquer à la requête actuelle, puis qui les ajoute à celle-ci. Le blog décrit aussi l’ajout d’une segmentation d’utilisateur basée sur une propriété du navigateur. Ce que j’ai décidé de faire, c’est d’écrire un composant WebPart qui ajoute une segmentation d’utilisateur basée sur le service de l’utilisateur actuel. Pour ceux d’entre vous qui ne le savent pas, lorsque vous importez un profil à partir d’Active Directory dans SharePoint 2013, les valeurs de service uniques sont automatiquement importées dans un magasin de termes spécial. Voici qui constitue un excellent choix pour faire des personnalisations basées sur le service de l’utilisateur actuel.

À ce stade, vous vous demandez peut-être pourquoi ne pas simplement utiliser des audiences si l’objectif est de présenter du contenu basé sur le service d’un utilisateur. C’est une bonne question, et voici la différence entre les deux. Le ciblage d’audience n’est en fait qu’un simple interrupteur : vous montrez un composant WebPart ou vous ne le montrez pas. Avec la segmentation d’utilisateur, je peux extraire cette information du profil ou de tout autre endroit, et personnaliser le contenu affiché. Comme j’utilise une règle de requête, je peux exécuter une ou plusieurs requêtes supplémentaires pour un utilisateur, ajouter un résultat promu ou encore modifier le classement d’une requête, par exemple pour cibler certains contenus et les faire figurer plus haut dans les résultats de recherche en fonction du service de l’utilisateur. Voici donc quelques-unes des fonctionnalités très utiles liées à la recherche dans SharePoint 2013.

Pour vous aider à utiliser cette fonctionnalité, je joins à ce billet mon projet Visual Studio dans son intégralité (assembly du composant WebPart compilé, solution et code source) pour le composant WebPart qui ajoute le service de l’utilisateur actuel à la segmentation d’utilisateur. Après, vous pouvez en faire ce que vous voulez : vous pouvez soit l’utiliser tel quel, soit vous en servir comme base pour affiner ou écrire vos propres composants WebPart pour la gestion de la segmentation d’utilisateur. Lors de la lecture du billet mentionné ci-dessus, tenez compte des points suivants concernant l’utilisation de la segmentation d’utilisateur et de ce composant WebPart :

  • Lorsque vous créez la règle de requête, celle-ci est configurée par défaut pour interroger le catalogue du site de publication. Si vous choisissez cette option, vous n’obtiendrez aucun résultat de recherche. Au lieu de cela, sélectionnez l’option consistant à interroger « Toutes les sources ». L’image de la configuration de la règle de requête dans le billet illustre bien ceci, mais cela n’est pas indiqué dans la légende. Étant donné que vous devez modifier le comportement par défaut pour que l’opération fonctionne, je me permets de vous le signaler.
  • Dans le billet, il est indiqué d’utiliser un autre composant WebPart pour afficher les résultats du contenu que vous mettez en surbrillance lors de l’utilisation de la segmentation d’utilisateur. Dans ce cas (et le billet y fait allusion), mon composant WebPart hérite de ContentBySearchWebPart. Vous pouvez donc utiliser le contrôle pour définir la segmentation d’utilisateur et afficher le contenu mis en surbrillance. La seule différence avec ce qui est décrit dans le billet, c’est que lorsque vous ajoutez le composant WebPart à la page, vous avez une valeur différente dans la propriété Paramètres pour le composant WebPart. Dans les paramètres, affectez à la propriété « Les résultats de la requête sont fournis par » la valeur « Ce composant WebPart ».

C’est tout ce que vous avez besoin de savoir. J’espère que vous trouverez des scénarios intéressants pour mettre en pratique la segmentation d’utilisateur dans vos recherches. Dans mon cas, au moment de l’écriture de ce billet, je recherchais à faire suivre une formation spéciale aux employés qui appartenait à un service « Executive ». Désormais, quand ils arrivent sur la page où mon composant WebPart est utilisé, la bannière suivante et un lien pour suivre une formation spéciale leur sont présentés :

Ce billet de blog a été traduit de l’anglais. La version originale est disponible à la page Using User Context (AKA Segmentation) in Search with SharePoint 2013.