Fonctionnement de la récupération de métadonnées gérées en CAML

Fonctionnement de la récupération de métadonnées gérées en CAML


Les requêtes portant sur une hiérarchie de métadonnées gérées suivent un mécanisme particulier en CAML qu’il est important de connaître si vous êtes amenés à créer vos propres requêtes.

La « TaxonomyHiddenList »

Tout d’abord, dans chaque collection de sites SharePoint, il existe une liste cachée nommée « TaxonomyHiddenList » et accessible par le format d’url suivante :

http://<monsite>/Lists/TaxonomyHiddenList

On retrouve dans cette liste tous les termes utilisés par tous les éléments de la collection de sites. C’est-à-dire?

Exemple:

Imaginez que vous avez défini un type de contenu « Projet » et que vous lui avez assigné une colonne de type métadonnée gérée se basant sur une hiérarchie de valeurs:

Hiérachie de métadonnées gérées

 

Tant que vous n’aurez pas « tagué » d’éléments (c’est-à-dire de projets) dans une des listes (n’importe laquelle permettant d’utiliser le type de contenu) à l’intérieur de votre collection de sites, alors la liste TaxonomyHiddenList restera vide.

En revanche, à l’instant où vous associez une valeur à la propriété, elle apparait instantanément dans cette liste.

Comme tous les éléments dans un liste SharePoint, ceux-ci possèdent un identifiant unique. Dans ce cas précis on parlera de « WssId».

Fonctionnement de la TaxonomyHiddenList

 

Vous remarquez que le numéro d’identifiant « WssId » n’est pas présent. Pour le récupérer, il suffit de regarder du côté de l’URL de l’élément dans la TaxonomyHiddenList.

URL

Alors maintenant, pourquoi est-il important de connaître cet identifiant? Celui-ci sera utilisé lors de la récupération d’éléments sur la base de métadonnée gérée en langage CAML. Imaginons une requête du composant Webpart de requête de contenu:

Include terms under selection CQWP option

 

Amusons-nous à comparer les requêtes CAML derrière ce composant selon que l’option de recherche d’éléments enfant soit sélectionnée ou non.

Comparaison de requêtes

Sans inclusion des types enfants

Sans inclusion

Avec inclusion

Avec inclusion

Vous remarquerez que seule une valeur change.

Analysons maintenant cette requête :

 Correspond à l’identifiant de la colonne « Localisation » de type métadonnée gérée

 Signifie que ce champ doit être traité en tant qu’identifiant unique de colonne de recherche

 Représente l’identifiant « WssId » de la valeur du terme dans la TaxonomyHiddenList. Dans ce cas présent « Montréal » ce qui est logique puisque Montréal est un enfant direct de « Québec ». (Le type «  Counter » signifie que le champ est un auto-incrément généré par SharePoint)

Cette requête correspond au formalisme suivant :

http://msdn.microsoft.com/en-us/library/ff625182(v=office.14).aspx

En passant, il existe une erreur dans l’article MSDN cité ci-dessus. Lorsqu’on y mentionne la méthode GetWssIdsOfKeywordTerm(), il faut comprendre GetWssIdsOfTerm, la première étant pour les mots clés d’entreprise. Le mécanisme permettant de récupérer les WssId associés à un terme dans une même collection de sites est assez obscur et n’est pas vraiment expliqué sur les ressources de TechNet. Cependant, on peut imaginer le processus suivant :

Hypothèse :

SharePoint cherche les enfants du terme recherché directement depuis le magasin de termes,  puis vient chercher les WssId correspondant dans la TaxonomyHiddenList si ceux-ci existent. C’est d’ailleurs en théorie ce que devrait faire la méthode GetWssIdsOfTerm.

Pourquoi dis-je « en théorie » ? Car le script suivant, selon la description et ma compréhension de la méthode, devrait me fournir les identifiants associés au terme pour cette collection de sites.

Malheureusement, au meilleur de ma connaissance, il n’est pas possible de récupérer ces identifiants.

+ There are no comments

Add yours