Partie 11: Définir les critères de requête sur les informations

Partie 11: Définir les critères de requête sur les informations


Aperçu de l’article

Notions clés

Les conditions de récupération de l’information dans SharePoint peuvent être soumises à plusieurs contraintes auxquelles nous ne pensons pas forcément. C’est le cas par exemple de la gestion hiérarchique, du multilinguisme ou bien même du ciblage à des catégories d’utilisateurs spécifiques.
Type de contenu
Métadonnées
Recherche

 


A quelles conditions les informations présentes dans la page doivent-elles s’afficher?

Cette étape va permettre de construire précisément les requêtes qui seront utilisées pour la récupération de données en identifiant les champs et types concernés dans la page. Les requêtes sont directement liées aux composants que vous avez déterminé dans les étapes précédentes, ces mêmes composants étant liés à un langage de requête particulier.
Par exemple, dans la fonctionnalité « Rechercher un projet », je veux effectuer une recherche sur la liste de tous les projets existants. Je peux donc définir la requête suivante dans SharePoint:

Tous les projets = Tous les éléments qui sont de type « Projet » dans la collection de site X.

 Soit en CAML:

Soit en KQL:
Comme vous le voyez, la métadonnée qui revient systématiquement dans toutes les requêtes lorsque l’on souhaite isoler un type particulier est le type de contenu (Content Type). C’est elle qui vous garantit la cohérence fonctionnelle de vos informations (à savoir que vous ne récupérez que des éléments dont le type est connu). Mais attention, selon le langage que l’on utilise, il ne s’agit pas de la même propriété.

Dans le cas d’une requête CAML, les champs se caractérisent par le nom interne de la colonne dans SharePoint. Le nom interne est simplement le nom « programmatique » d’une colonne permettant d’y faire référence facilement en évitant les erreurs de syntaxe liées au formatage (accents, espace, etc…). À l’inverse, le nom d’affichage, comme son nom l’indique, est destiné à la visualisation.

Exemple:

Nom interne de référence Nom d’affichage Type
Editor Modified By Personne
ContentType Content Type Texte
FileRef Url Path Colonne de recherche

Vous pouvez retrouver la liste des noms internes de colonnes sur internet. 

En langage de recherche le nom de la propriété correspond à la propriété gérée associée à la propriété crawlé d’une colonne dans SharePoint. Si vous souhaitez en savoir plus sur le fonctionnement des propriétés gérées sous SharePoint, je vous conseille de vous référer à l’annexe Fonctionnement des propriétés de recherche sous SharePoint.

Les requêtes sont le point de départ de cette étape. Cependant, il est possible de se poser quelques questions supplémentaires pour les affiner :

Les éléments récupérés doivent-ils correspondre à la réalité à l’instant « t » dans SharePoint?

  • Y a-t-il un tri à faire sur les éléments?
  • Y a-t-il des contraintes de récupération pour des éléments hiérarchiques?
  • Y a-t-il des conditions impliquant des relations entre les types?
  • Le contenu récupéré doit-il être ciblé ?
  • Y a-t-il des contraintes de récupération multilingue?
  • Les requêtes doivent-elles être centralisées?
  • Y a-t-il des contraintes conditionnelles sur les requêtes?

 A noter que la réponse à la première question vous imposera un choix quant aux composants utilisés dans votre page ainsi que le modèle de requête sous-jacent (CAML ou KQL).

Gestion de la hiérarchie: Types de contenus

Lors de la définition des requêtes, il se peut que vous ayez besoin de récupérer des éléments issus d’un héritage entre types de contenus.

Rappelez-vous du cas précédent:

H<ritage entre les types de contenus

Un projet peut se décliner en plusieurs sous types. Cependant, si je souhaite récupérer la liste de tous les projets, qu’en est-il de la requête? Dois-je mettre autant de conditions que de types de contenus?

En réalité, oui et non.

La hiérarchie dans les types de contenus est implémentée dans SharePoint via un mécanisme d’identifiant commun. Chaque type de contenu possède un identifiant unique sous forme hexadécimale (0x…). Lorsque vous héritez un type de contenu d’un autre, un identifiant unique est calculé pour le type enfant et concaténé à celui du parent pour former un nouvel identifiant unique global. Pour retrouver les types hérités, il suffit alors de rechercher sur les types de contenus qui contiennent textuellement l’identifiant unique du parent dans leur propre identifiant.

Principe de l'identifiant de types de contenu

Il existe toutefois une différence de traitement entre les deux types de langages de récupération de données dans SharePoint (CAML et KQL).

Types de contenus en CAML

Le principe par concordance d’identifiant est utilisé lorsque vous paramétrez le composant WebPart de requête de contenu en indiquant de récupérer les types enfants.

Configuration du CQWP pour la recherche hiérarchique

Si on  exporte ce composant et qu’on observe la requête CAML qui est soumise en arrière, voici ce que l’on obtient:

Recherche hiérarchique en CAML

On constate bien que l’on cherche les éléments dont le type de contenu contient l’identifiant du type de contenu parent via une propriété ContentTypeId.

 Note : Ce comportement est valable pour les versions de SharePoint de 2007 à 2013.

 Remarque : Si vous définissez votre propre requête CAML « à la main », alors il vous faudra requêter sur la propriété ContentTypeId avec l’opérateur « Contains » ou « BeginsWith»  plutôt que ContentType pour reproduire le même comportement car sinon vous chercherez sur le nom du type de contenu plutôt que son identifiant.

Types de contenus en KQL

Pour les propriétés de recherche, le comportement est quelque peu différent selon les versions.

En SharePoint 2010, oubliez-ça!

Par défaut, il n’existe pas de propriété gérée « ContentTypeId ». Il existe toutefois la propriété « ContentType ». Celle-ci pourrait faire l’affaire mais ne ferait qu’une correspondance textuelle des noms dans les types hérités. Par exemple si mon type de contenu parent se nommait « Projet » et mes types enfants « Projet commercial » et « Projet interne », alors oui, ils apparaîtraient dans les résultats de la requête car ils contiennent le nom type parent dans leur propre nom:

 Cette solution fonctionne mais paraît peut acceptable car non robuste et fiable étamt donné que la correspondance est simplement textuelle

Si l’on explore alors davantage les propriétés crawlées,  il existe une propriété nommée« ContentTypeId ». Cependant, lorsqu’on examine d’où elle provient, on s’aperçoit qu’elle correspond à la catégorie « Office » qui représente les métadonnées issues des documents Office (Word, Excel, …) et non les éléments de SharePoint.

Propriété "ContentTypeId" avec SharePoint 2010

Par conséquent, il n’est pas possible de faire une recherche sur cette propriété car il est tout simplement impossible de la récupérer dans le cadre d’un crawl de recherche (à ma connaissance).

En SharePoint 2013, ils y ont pensé!

En SharePoint 2013, les possibilités ont changé. Si l’on regarde toujours du côté des propriétés crawlées on peut voir ceci:

Propriété "ContentTypeId" de SharePoint 2013

Il existe cette fois une propriété pour le schéma SharePoint (ows_ContentTypeId), qui par défaut est associée à une propriété gérée « requêtable » (ContentTypeId).

À noter qu’il existe également une propriété gérée ContentType, correspondant au nom « textuel » du type de contenu de l’élément (Idem qu’en 2010). Attention, ce n’est pas cette propriété que vous devez utiliser dans l’assistant de construction de requêtes, vous n’obtiendrez aucun résultat.

Bug de la propriété ContentType avec SharePoint 2013

Il faut bien utiliser la propriété ContentTypeId avec comme valeur manuelle l’identifiant hexadécimal que SharePoint a gentiment extrait pour vous lors de votre précédente erreur.

Oui vous avez bien compris! Pour faire une recherche sur des types de contenus hiérarchiques en SharePoint 2013 via l’assistant de requête, il faut se tromper une première fois pour pouvoir ensuite utiliser l’identifiant du type de contenu récupéré avec la bonne propriété gérée! Et l’intuitivité me direz-vous? On parle de SharePoint je vous le rappelle .

Recherche hiérarchique en KQL

 Note : N’oubliez pas le caractère wildcard « * » à la fin, ni même l’opérateur « Contains ».

Gestion de la hiérarchie: Métadonnées gérées

Depuis SharePoint 2010, il existe un autre cas de figure incluant de la récupération d’éléments hiérarchiques dans SharePoint que je n’ai pas mentionné pour le moment : les métadonnées gérées.

Je vais enrichir à présent légèrement mon exemple et y ajouter ce concept: J’ajoute une métadonnée gérée dans mon entité « Projet » correspondant par exemple à la localisation géographique du projet. Pour cela je défini les valeurs possibles suivantes pour ma métadonnée:

Illustration de métadonnées gérées multi-niveaux

Les métadonnées gérées me permettant de descendre jusqu’à 7 niveaux, il est intuitif de les définir dans un seul et même terme dans le magasin de termes et de respecter le découpage logique Pays/Province/Région administratives/etc….

Je vais ainsi pouvoir « taguer » mes projets avec le bon niveau de localisation lors de leur création:

Tagging d'un élément

Cependant qu’arrive-t-il dans SharePoint si je souhaite par exemple obtenir tous les projets pour la localisation « Québec »? Prenons le cas avec le langage de requête structurée CAML puis en KQL.

Métadonnées gérées en CAML

En utilisant le WebPart de requête de contenus (2010 et 2013), il vous est possible de spécifier ce comportement assez facilement via une simple propriété à cocher:

Recherche hiérarchique de métadonnées gérées en CAML

Le comportement en arrière est assez complexe. Si vous souhaitez savoir plus précisément ce que fait cette option, je vous conseille de lire le chapitre Fonctionnement de la récupération de métadonnées gérées en CAML.

Métadonnées gérées en KQL

En KQL, les choses sont un peu différentes car ce comportement n’est pas le même en SharePoint 2010 et en 2013.

En SharePoint 2010

En premier lieu, pour construire votre requête, il vous faudra créer une propriété gérée (« Localisation » par exemple) permettant de requêter sur la valeur de la métadonnée gérée (« Québec », « Montréal »). Vous trouverez plus de détails ici.

Cependant, si vous effectuez une requête sur une métadonnée gérée de niveau N, vous vous apercevrez que les éléments identifiés avec les métadonnées correspondant au niveau N-1 n’apparaitront pas dans vos résultats, même en spécifiant l’opérateur « : » (Contient).

Recherche_Hierarchique_SP2010

En KQL, et de manière générale, il n’y pas de notion de WssId  comme on peut le voir pour CAML (Fonctionnement de la récupération de métadonnées gérées en CAML) et par défaut, SharePoint ne sait pas qu’il existe des termes enfants pour le terme recherché.

Il existe une méthode permettant de « feinter » la recherche hiérarchique sur les métadonnées gérées. Il s’agit d’une option dans la définition de la colonne de métadonnée gérée en elle-même permettant de spécifier le chemin complet du terme dans son arborescence de termes en lieu et place d’une valeur unique:

Paramètre de chemin complet pour une colonne de métadonnée gérée

Recherche hiérarchique de métadonnées gérées en KQL

Par ce principe, le moteur de recherche va être capable d’extraire la chaîne complète (après indexation) et donc de pouvoir faire des requêtes hiérarchiques par correspondance textuelle:

Exemple de récupération d'élément avec le chemin complet

L’inconvénient majeur de ce fonctionnement est, comme vous pouvez le constater, que le panneau de raffinement et le formulaire d’affichage de l’élément afficheront à présent le chemin complet du terme. Pour remédier à cela, du moins dans le panneau de raffinement, il est nécessaire d’effectuer un développement personnalisé pour  formater l’affichage, que cela soit fait directement en code serveur ou par le biais de  JavaScript (en ne gardant que le dernier terme par exemple).

En SharePoint 2013

En SharePoint 2013, il existe maintenant des « tokens » permettant d’effectuer des requêtes selon une hiérarchie de termes de taxonomie. Ceux-ci sont générés, sous forme textuelle, dans la valeur de la propriété gérée de recherche, crée automatiquement lors d’un crawl pour les colonnes de types « Métadonnée  gérée » (de la forme owstaxid<nom_de_votre_colonne>). Vous pouvez retrouver une explication du fonctionnement de ces tokens avec d’exemples à l’adresse: http://technet.microsoft.com/en-us/library/jj613136.aspx.

Voici les tokens disponibles:

Token Description
GP0|#<GUID du terme> Permet de récupérer tous les éléments taggués avec un terme particulier
GPP|#<GUID du terme> Permet de récupérer tous les éléments qui sont taggués avec un enfant d’un terme particulier
GTSet|#<GUID du terme> Permet de récupérer tous les éléments taggués avec un terme provenant d’un ensemble de terme particulier.

 Note : Les tokens qui permettent de faire de la recherche hiérarchique via des termes de taxonomie sont GPP et GTSet.

  •  Voici un exemple de leur utilisation :

Soit la configuration suivante:

Exemple d'utilisation des tokens

 Propriété gérée: owstaxidLocalisation

Si à la manière de SharePoint 2010, je cherche explicitement « Localisation : Québec », je n’obtiens aucun résultat:

Pas de résultats

En revanche, si maintenant j’utilise les tokens et notamment celui permettant de rechercher les enfants d’un terme, voici ce que j’obtiens pour le terme « Québec »:

utilisation du token GPP en SharePoint 2013

Et pour l’ensemble de termes « Localisation » au complet:

Utilisation du token GTSet en SharePoint 2013

Si l’on regarde le contenu de la propriété gérée owstaxidLocalisation pour l’élément « Projet Montréal », on observe qu’elle contient les valeurs pour chaque token permettant de replacer l’élément dans sa hiérarchie.

owstaxidLocalisation: GP0|#dfed42d3-0a84-416d-bb97-df13d0615707; “MontréalL0|#0dfed42d3-0a84-416d-bb97-df13d0615707|Montréal; “MontréalGTSet|#28921402-8f33-4ffc-8ef8-25d6d223c0e1; = “Localisation”GPP|#6d5dc0c6-d8f9-4356-b7ed-44abae588410; = “Québec
GPP|#19287779-b54b-43b3-8296-64c2052b21f7 = “Canada

 Note importante : Vous remarquez qu’il est nécessaire de connaître l’identifiant unique du terme pour que cela fonctionne. Pour des requêtes faites par un utilisateur via une boite de recherche, cela paraît un peu difficile. En revanche, si vous utilisez la navigation par taxonomie de SharePoint 2013, ces tokens prennent tout leur sens, car ils permettent d’être combinés à la variable de recherche {Term.IDWithChildren} vous permettant ainsi de créer des pages de catégorie dynamiques de manière simple (dans un composant de recherche de contenu par exemple):

Combiner les tokens de recherche avec la navigation par taxonomie en SharePoint 2013

Gestion des relations

La gestion des requêtes impliquant des relations entre les types est commune dans SharePoint.

Exemple de relations entre types de contenus

Si vous vous rappelez des outils pour connecter des entités entre elles dans SharePoint, ils se composent principalement des métadonnées gérées et de la colonne de recherche. Pour le premier cas, il n’y a rien de particulier à mentionner, ne serait-ce que la création de propriété gérée à faire avant de requêter (voir  pour plus d’informations). En revanche, pour la colonne de recherche, il est intéressant de connaître les comportements par défaut dans SharePoint.

À titre de rappel, dans SharePoint, il est possible d’ajouter des colonnes supplémentaires pour une colonne de recherche. Celles-ci seront ajoutées sous la forme <NomDeLaColonneDeRecherche> :<Propriété> (Exemple : « Projet:ID »)

Ajout de colonnes additionnelles pour une colonne de recherche

Relations en CAML

En CAML, que ce soit dans la définition d’une vue pour un WebPart de liste ou bien d’une requête pour un composant WebPart de requête de contenu, il est possible d’utiliser la colonne de recherche (ou ses colonnes liées) directement:

Gestion des relations en CAML

Relations en KQL

Avec le langage de recherche KQL, il est possible de requêter sur des colonnes de recherche (« Lookup Field »). Cependant, cela n’est pas possible par défaut et il vous faudra effectuer quelques configurations pour y parvenir.

Ces configurations consistent à créer une propriété gérée sur la colonne de type recherche (« Projet » par exemple) qui n’est pas créée automatiquement par SharePoint et d’y agréger les propriétés crawlées correspondant aux colonnes additionnelles que vous avez spécifié lors de la création de ladite colonne de recherche.

Requête sur une colonne de recherche en KQL

Gestion du multilinguisme

Le multilinguisme est quelque chose que l’on rencontre souvent dans les projets SharePoint (encore plus au Québec!). Malheureusement, Microsoft semble avoir une fâcheuse tendance à négliger ce point, laissant la tâche aux développeurs et spécialistes de trouver eux-mêmes des solutions aux lacunes de l’outil dans ce domaine.

Multilingusime avec les métadonnées gérées

Tout d’abord, lorsqu’il est question de récupération d’informations multilingues, on pense principalement aux métadonnées gérées qui sont les seules types de valeurs de colonnes qu’il est possible de traduire dans SharePoint. Pour le reste, la question ne se pose pas puisque cela n’est tout simplement pas possible. OOTB.

Il est en effet possible de créer un terme en plusieurs langues. Cependant, qu’en est-il des différentes requêtes?

Prenons l’exemple suivant:

Rappelez-vous : Précédemment, pour démontrer la récupération de métadonnées gérées de façon hiérarchique, j’ai introduit une nouvelle métadonnée, « Localisation », correspondant à l’emplacement du projet. Bien que cette donnée possède des valeurs de termes sur plusieurs niveaux hiérarchiques, celles-ci sont également traduites en anglais et français.

Exemple d'ensemble de termes multilingue

Contexte:

  • Supposons que la langue du site SharePoint courante est « Français »
  • Ajoutons un nouveau projet avec la localisation « Nouvelle Écosse » (La valeur du terme proposée correspond à la langue courante)

Tag d'un élément avec une métadonnée traduite

 

Comportement en CAML

En CAML, c’est le fonctionnement de la récupération de métadonnées gérées en CAML qui s’applique, de la même manière que pour la recherche hiérarchique. La récupération est faite sur la base d’un identifiant unique de la « TaxonomyHiddenList », qui ne tient pas compte de la langue du terme. Aucun problème en particulier ici pour ce type de requête qui ne tient donc pas compte de la valeur « localisée » du terme mais seulement de son identifiant.

Exemple de récupération d'élément avec le chemin complet Multilinguisme en CAML

 

Comportement en KQL

En KQL et pour les langages de recherche en général dans SharePoint (2010 ou 2013), ça se complique légèrement…

Imaginons le cas suivant :

  • Supposons que je dispose d’une propriété gérée de recherche « Localisation » me permettant de requêter directement sur la valeur de la métadonnée « Localisation ». Pour rappel, le fonctionnement des propriétés gérées sous SharePoint est expliqué dans l’Annexe C.

Voici ce que j’obtiens:

Recherche KQL multilingue

On remarque que si je cherche la valeur « Nouvelle Écosse », aucun résultat n’est trouvé (alors que j’ai bien identifié mon projet avec cette valeur). Cependant, pour la version anglaise, pas de problème, le projet est bien retourné. Pourquoi ce comportement?

Parce que la langue de la métadonnée de l’élément au moment de son enregistrement est celle qui a été choisie lors de la création de la collection de sites !

Langue de la collection de sites

 Notez qu’il n’est pas possible d’en changer après création.

Impossible de modifier la langue après création

Heureusement, il existe des solutions pour remédier à ce problème, et ça se passe ici : Rendre la recherche SharePoint multilingue.

Cas des propriétés de recherche avec SharePoint 2013

En SharePoint 2013, il existe maintenant, des propriétés gérées permettant de déterminer la langue d’un élément (grâce à l‘inclusion de FAST Search dans les fonctionnalités de recherche natives de l’outil).

  • DetectedLanguage
  • Language
  • Languages

Ces trois propriétés permettent donc de déterminer la langue d’un élément. Pour comprendre la manière dont elles fonctionnent, je me suis amusé à comparer leurs valeurs dans différents cas que voici :

Note : Tous les éléments/documents ont étés créés au sein d’un site en « Français »:

Création d'un site en FR

Valeur des propriétés gérées de recherche
Cas de tests DetectedLanguage Language Languages
Document écrit en Anglais ‘en’ ‘en’ ‘en’
Document écrit en Français ‘fr’ ‘fr’ ‘fr’
Document moitié Français et Anglais ‘fr’ ‘fr’ ‘fr’
Élément ‘fr’ ‘fr’ ‘fr’
Titre Description
Français Français
Élément ‘en’ ‘en’ ‘en’
Titre Description
Anglais Anglais
Élément ‘en’ ‘en’ ‘en’
Titre Description
Français Anglais
Élément ‘fr’ ‘fr’ ‘fr’
Titre Description
Anglais Français

Observations:

 

  • La langue de l’élément est indépendante de la langue du site
  • La langue de l’élément est déterminée lors du crawl de recherche selon les champs de contenu. Le titre n’est donc pas pris en compte.

Malheureusement, je n’ai pas trouvé de documentation sur l’algorithme permettant de détecter la langue de l’élément ce qui rend son fonctionnement plutôt obscur.
Et le sélecteur de langue sur le composant de recherche ?
Si vous utilisez la recherche de SharePoint, vous avez peut être remarqué qu’il est possible de filtrer sur une langue spécifique. Autant vous le dire tout de suite, ce sélecteur n’a aucun rapport avec les propriétés gérées vues plus haut…

Sélecteur de langue sur le composant de recherche

Il se contente uniquement de réaliser un tri sur les éléments en fonction de leur langue (paramètre « Culture »). Vous aurez donc toujours des résultats dans plusieurs langues…

Propriété Query.Culture

Réutilisation des requêtes

Durant tout le processus de conception et au fil des besoins que vous traiterez, il se peut fortement que certaines requêtes de données se répètent.

Par exemple, pour « Rechercher un projet »,  il existe une requête qui récupère la liste de tous les projets dans la collection de sites, quel que soit leur type. Mais, si dans un besoin futur, j’ai également la nécessité de récupérer la liste de tous les projets, j’aimerais réutiliser la requête déjà définie pour « Rechercher un projet » au lieu d’en réécrire une autre similaire.

À partir de SharePoint 2007, il est possible de réutiliser des requêtes.

Réutilisation de requêtes CAML

Il n’existe pas à proprement parler un endroit dans SharePoint (quel que soit la version) pour stocker des requêtes avec ce langage. En revanche, il est tout de même possible de réutiliser une requête, non pas en la stockant à un seul endroit, mais en exportant et réutilisant le composant WebPart qui l’utilise. À ce niveau, on parle bien sûr du composant WebPart de requête de contenu qui est le seul nous permettant de définir une requête détaillée (il n’est pas possible d’exporter un WebPart de liste).

Réutilisation de requête CAML

Réutilisation de requêtes KQL

En KQL, il est possible d’enregistrer des requêtes de manière plus structurée.

Pour SharePoint 2007 et 2010, il s’agit de la notion de « périmètres de recherche ». Pour 2013, il s’agit de celle de «  source de résultats ».

Le principe est simple : Isoler, par une requête réutilisable, un sous ensemble de résultats dans lequel il est également possible d’effectuer des recherches. Une sorte de mini index ne contenant que les éléments dont vous avez besoin.

A noter que dans tous les cas, la portée de de votre requête est configurable (sites, collections de sites, ferme entière).

Exemple avec des périmètres de recherche en 2007 et 2010

La réutilisation des requêtes de recherche en SharePoint 2007 et 2010 peut se faire via la fonctionnalité de périmètres de recherche.

Réutilisation des requêtes KQL avec des périmètres de recherche

Exemple avec des sources de résultats en 2013

ResultSource_2013

Remarque :

Il est conseillé d’adopter une nomenclature claire et précise lors de la création d’un périmètre de recherche ou d’une source de résultats permettant ainsi de la distinguer facilement tant au niveau de la portée que des données récupérées.

Gestion du ciblage de contenu

Le ciblage de contenu permet de segmenter l’information sans surcharger les pages. Il permet notamment de distiller l’information aux bonnes personnes selon une ou plusieurs de leur caractéristiques alors qu’ils accèdent tous à la même page.

On observe ce genre de comportements généralement sur de larges intranets pour du ciblage par services ou bien sur des solutions internet pour du ciblage marketing. Il existe, dans SharePoint, plusieurs moyens de réaliser ce ciblage.

La sécurité (toutes versions)

La plupart des composants SharePoint prennent en  compte les permissions appliquées aux éléments qu’ils affichent et ceci, peu importe la méthode d’accès à l’information (langage structuré ou de recherche). C’est le moyen le plus simple de cibler du contenu. Cependant, dans des cas où l’on souhaite cibler le contenu sans nécessairement le restreindre, il faut se tourner vers d’autres solutions.

Les audiences (2007, 2010 et 2013)

Disponibles en 2007, 2010 et 2013, les audiences sont des sous-ensembles de personnes ayant des caractéristiques communes. Il ne s’agit pas ici de permissions mais plutôt de regroupements sous une ou plusieurs caractéristiques partagées.

Elles se basent sur les profils utilisateurs de SharePoint, eux-mêmes pouvant potentiellement être basés sur un Active Directory ou tout autre annuaire compatible, ce qui leur permet ainsi de créer des sous-ensembles sur la base de propriété du profil.

Les audiences sont paramétrables au niveau des sources de données SharePoint comme les listes ou les bibliothèques. Une nouvelle colonne « Audiences ciblées » est créée vous permettant de spécifier un groupe ou une personne pour le contenu que vous êtes en train d’ajouter (c’est donc simplement une métadonnée).

Activation des audiences

Leur utilisation se fait uniquement à travers le composant de requête de contenu qui possède une logique interne permettant de détecter si la personne actuellement authentifiée fait partie de l’audience ou non:

Ciblage de contenu avec les audiences (avec GUID)

À noter que vous devez spécifier le GUID (le nom de l’usager ou du groupe en format lisible par un humain 😉 de l’audience ainsi que la condition « Audience ciblée » et l’opérateur « Contient » pour faire fonctionner cette fonctionnalité.

L’avantage des audiences est qu’elles sont faciles à mettre en place. En revanche, les inconvénients majeurs sont qu’elles ne peuvent être utilisée qu’avec le WebPart de requête de contenu (et donc en langage CAML). Il n’est en effet pas possible d’utiliser les audiences avec le langage de recherche (KQL ou autre) et ceci, quelle que soit la version.

Un autre inconvénient est que le principe d’audience est difficilement utilisable dans le cadre de sites Web publics anonymes, car il n’y a pas de profils utilisateurs.

Les segments utilisateurs (2013)

Les segments utilisateurs sont une nouveauté de SharePoint 2013 uniquement pour la recherche. Avant tout, pour les utiliser, il vous faudra obligatoirement passer par du développement personnalisé. Les segments utilisateurs se basent sur des propriétés de termes personnalisées dans le magasin de termes.

User_Segments

Le développement consiste à dériver un WebPart classique de recherche de contenu pour y faire correspondre une donnée externe (liée à une propriété de profil, la version du navigateur courant, etc.) à l’une de ces propriétés.

Utilisation des segments utilisateurs

Ces segments sont ensuite utilisables par l’intermédiaire de règles de requêtes permettant ainsi de cibler le contenu.

Attention, les segments utilisateurs ne sont pas conçus pour faire du ciblage par inclusion via des arborescences de taxonomie (par exemple cibler tous les utilisateurs d’un pays peu importe leur ville dans ce même pays et ceci via une hiérarchie de termes).

Les variables de recherche dynamiques (2013)

Ce dernier moyen utilise les variables dynamiques de filtres disponibles dans SharePoint 2013 lors de l’élaboration de requêtes basées sur le langage de recherche KQL.

Lorsqu’on parle de ciblage de contenu, on utilisera principalement la variable User.xxx (où xxx étant une propriété de profil). Cette notion est abordée plus loin dans la partie Filtres dynamiques.

Gestion des requêtes conditionnelles

Les requêtes conditionnelles sont des requêtes liées aux requêtes de base pour « étendre » les résultats sous certaines conditions. Il s’agit de promotion de contenu et d’enrichissement des résultats par rapport à une requête de base.

Par exemple, imaginons que pour l’histoire utilisateur « Rechercher un projet », je désire afficher la liste des annonces de l’entreprise qui ont un rapport avec le mot clé entré par l’utilisateur dans sa recherche (par exemple : « commercial »). Il est possible de répondre à  ce besoin par le biais des requêtes conditionnelles. Cependant, les possibilités diffèrent grandement entre SharePoint 2010 et 2013.

  • En SharePoint 2010. Il n’est possible de promouvoir qu’uniquement des liens hypertextes sous certaines conditions et non le résultat d’une requête supplémentaire. Il s’agit de la fonctionnalité de « Meilleurs résultats de recherche ».
  • En SharePoint 2013. Il est maintenant possible d’ « d’enchaîner » des requêtes de recherche ensemble sous certaines conditions pour promouvoir certains résultats grâce à la fonctionnalité de « règles de requêtes » (Query rules). Les conditions peuvent se baser sur le contexte de la requête (pour du ciblage de contenu par exemple) ou sur les mots clés entrés par l’utilisateur.

Création de règles de requêtes

 À noter que ces règles sont indépendantes des composants de recherche de SharePoint.


+ There are no comments

Add yours