Navigation et filtrage de métadonnées
Dernière modification : lundi 19 avril 2010
S’applique à : SharePoint Server 2010
Dans cet article
Navigation et filtrage des métadonnées
Conseils
Programmabilité de la fonction Navigation et filtrage des métadonnées
La fonction Navigation et filtrage des métadonnées permet de filtrer les affichages de listes Microsoft SharePoint Server 2010 par les métadonnées de leurs éléments. Un propriétaire de liste peut utiliser cette fonction pour promouvoir des champs dans la liste en tant que champs de navigation clés, et les utilisateurs affichant ces listes voient une interface utilisateur de filtrage qui leur permet de filtrer l’affichage de la liste actuelle pour afficher les éléments avec les valeurs souhaitées dans ces champs. La fonction Navigation et filtrage des métadonnées fonctionne avec des index au niveau de la liste pour prendre en charge une expérience de navigation continue, même dans les très grandes listes qui contiennent des dizaines de millions d’éléments. Cette fonction favorise l’utilisation des métadonnées et le balisage en vous assurant que, lorsque les éléments sont bien balisés sur plusieurs champs, ils sont par nature plus détectables que les éléments de la liste qui ne sont pas balisés.
Navigation et filtrage des métadonnées
La fonction Navigation et filtrage des métadonnées inclut :
Une nouvelle interface utilisateur de navigation et de filtrage des affichages de listes en fonction des métadonnées des éléments de la liste.
Un processus qui crée les index de liste automatiquement, en fonction des champs promus en tant que champs de navigation dans la liste.
Un processus qui sélectionne le meilleur index pour la requête en cours d’exécution afin d’éviter la limitation d’affichage de la liste, lorsque cela est possible.
Nouvelle interface utilisateur
La nouvelle interface utilisateur inclut les hiérarchies de navigation et les filtres clés :
Les hiérarchies de navigation sont des champs qui apparaissent dans la vue arborescente, lorsqu’un utilisateur affiche la liste parente. L’utilisateur peut explorer les valeurs incluses dans ce champ, comme une structure de dossiers, et cliquer dessus pour afficher les documents correspondant aux valeurs. Comme une bonne structure de dossiers, un bon champ de hiérarchie de navigation répartit le contenu en segments plus faciles à gérer.
Les filtres clés sont des champs qui figurent au-dessous du niveau arborescent. Il s’agit de filtres supplémentaires qui permettent de limiter le contenu de l’affichage actuel.
Création d’index automatique
Dans la page Paramètres de navigation de métadonnées d’une liste, vous pouvez également spécifier si les index sont créées automatiquement sur la liste pour correspondre à votre hiérarchie de navigation et aux champs de filtrage clés actuellement sélectionnés. Si ce paramètre est activé (comme c’est le cas par défaut sur une liste), lorsque la page de paramètres de navigation de métadonnées est enregistrée :
Les index de colonne unique sont créés sur tous les champs de filtrage clés pris en charge, à l’exception du champ Type de contenu et du champ Choix.
Les index composés sont créés sur toutes les combinaisons de hiérarchies de navigation et de filtres clés prises en charge.
Il est recommandé pour la plupart des scénarios de laisser le paramètre qui spécifie si les index sont créés automatiquement sur la liste en fonction de votre hiérarchie de navigation et des paramètres de champs de filtrage clés actuellement sélectionnés, car si aucun index n’est créé sur une liste, toutes les requêtes sur cette liste sont non indexées. Les requêtes non indexées ne sont pas prises en charge sur les listes Microsoft SharePoint Server 2010 importantes, ni sur les listes qui contiennent plus d’éléments que la quantité définie dans le seuil de requête d’affichage de liste du site. Dans certains scénarios avancés, il peut être approprié de désactiver ce paramètre et de configurer manuellement les index. Les aspects importants à prendre en considération incluent :
SharePoint Server 2010 prend en charge un maximum de 20 index par liste. La fonction Navigation et filtrage des métadonnées ne peut pas créer un index si dans cet espace de 20 index il n’y a pas suffisamment de place pour toutes les combinaisons admissibles à partir de la hiérarchie de navigation et des champs de filtrage clés sélectionnés.
La création de nouveaux index au sein d’une liste volumineuse est interdite, sauf si vous êtes administrateur de batterie de serveurs ou que vous travaillez dans une fenêtre de service.
Types d’index et champs pris en charge
Le tableau 1 récapitule les types de champs qui peuvent participer à la navigation de métadonnées et selon quelle capacité.
Tableau 1. Types de champs pouvant prendre part à la navigation de métadonnées
Type de champ |
Pris en charge en tant que hiérarchie de navigation ? |
Pris en charge en tant que filtre clé ? |
Prend en charge l’index de colonne unique ? |
Prend en charge l’index composé ? |
|---|---|---|---|---|
Type de contenu |
Oui |
Oui |
Oui |
Oui |
Choix (valeur unique) |
Oui |
Oui |
Oui |
Non |
Métadonnées gérées (valeur unique) |
Oui |
Oui |
Oui |
Oui |
Métadonnées gérées (valeur multiple) |
Oui |
Oui |
Oui* |
Non |
Personne ou groupe (valeur unique) |
Non |
Oui |
Oui |
Oui |
Personne ou groupe (valeur multiple) |
Non |
Oui |
Non |
Non |
Date et heure |
Non |
Oui |
Oui |
Oui |
Nombre |
Non |
Oui |
Oui |
Oui |
Notes
*Les champs de recherche à valeurs multiples sont automatiquement indexés en fonction de la façon dont ils sont stockés dans la base de données et, par conséquent, ne comptent pas pour la limite de 20 index. Toutefois, ils ne peuvent pas participer aux index composés.
Requêtes indexées
La fonction Navigation et filtrage des métadonnées détermine au mieux l’index le plus bénéfique à chaque chargement d’un affichage de liste. Chaque fois que l’utilisateur charge un affichage de liste, ou qu’il l’actualise en appliquant un nouveau filtre, en effaçant un filtre ou en appliquant un tri sur un champ, une certaine logique en arrière-plan examine la demande et détermine la manière d’interroger la base de données qui évite la limitation de grande liste. Cela n’est pas toujours simple ; une requête peut être exécutée de plusieurs façons et chaque façon peut produire des résultats différents. Le processus fonctionne comme suit :
Lorsque l’utilisateur accède à une page d’affichage de liste, ou actualise un affichage de liste, la page exécute une requête Langage CAML (Collaborative Application Markup Language) sur la liste pour récupérer les éléments qui sont affichés dans le composant WebPart Affichage de liste. Cette requête peut inclure un ou plusieurs filtres, qui proviennent des valeurs sélectionnées dans une hiérarchie de navigation, d’une ou plusieurs sélections de filtres clés, d’un ou plusieurs filtres spécifiés dans la définition de la vue, ou d’un ou plusieurs filtres spécifiés dans les filtres de colonnes du composant WebPart Affichage de liste. Si la liste actuelle est volumineuse, cette requête CAML peut générer une SPThrottledQueryException, ce qui signifie que la requête n’est pas sélective. En d’autres termes, elle examine plus d’éléments dans la base de données que le seuil de requête d’affichage de liste défini par l’administrateur. Si cette exception se produit, les étapes 2 et suivantes sont exécutées.
La navigation des métadonnées examine chacune des opérations (ou clauses) de filtrage dans la requête CAML et détermine celles ayant des index correspondants créés sur la liste qui peuvent être utilisés pour répondre à cette opération. Par exemple, s’il existe un index sur la colonne Modifié par et que l’affichage de liste en cours filtre sur la colonne Modifié par, cet index peut être utilisé par la requête.
Pour chacune de ces combinaisons index/filtre valides, la navigation des métadonnées réécrit la requête CAML actuelle pour utiliser cet index.
La fonction Navigation et filtrage des métadonnées tente ensuite d’exécuter chacune de ces requêtes indexées jusqu’à ce qu’elle en trouve une qui ne génère pas une SPThrottledQueryException. Si toutes les requêtes provoquent cette exception, elle construit et exécute une requête de secours.
Notes
La fonction Navigation et filtrage des métadonnées est activée par défaut sur la plupart des sites créés dans SharePoint Server 2010. Ce processus se produit pour chaque liste de ces sites, que la fonction soit effectivement configurée ou non.
Requêtes de secours
Si la fonction Navigation et filtrage des métadonnées détermine que la demande actuelle de l’utilisateur ne peut pas être exprimée en tant que requête indexée qui soit sélective, elle construit et exécute une requête de secours. Une requête de secours est une version modifiée de la requête utilisateur d’origine qui interroge seulement une partie de la liste au lieu de la liste entière. Les requêtes de secours sont destinées à montrer à l’utilisateur un ensemble de résultats partiel utile, même lorsque la requête d’origine n’a pas été exécutée en raison de la limitation de grande liste. Les requêtes de secours peuvent également servir d’avertissement aux propriétaires de liste que la distribution des données dans la liste est asymétrique et que certaines requêtes que les utilisateurs exécutent ne peuvent pas retourner un ensemble complet de résultats, ce qui signifie que les utilisateurs peuvent être empêchés d’accéder au contenu dont ils ont besoin. Les requêtes de secours retournent de temps à autre des résultats 0 si aucun des éléments dans la partie de la liste analysée par la requête ne contient des résultats correspondant à la requête utilisateur d’origine.
Dans la mesure où les résultats d’une requête de secours ne sont qu’un ensemble partiel des éléments que l’utilisateur demande, l’utilisateur est averti par un message à l’écran qu’il ne visualise qu’un ensemble partiel de résultats et qu’il doit appliquer des filtres supplémentaires pour afficher un ensemble complet. Chaque fois qu’un utilisateur spécifie un filtre supplémentaire, le moteur de requête dispose d’une nouvelle possibilité de trouver une combinaison filtre/index sélective qui ne génère pas une SPThrottledQueryException. Il existe deux types de requêtes de secours, par ordre de préférence : les requêtes de secours indexées et les requêtes de secours simples.
Requêtes de secours indexées. Ce type de requêtes de secours fonctionne sur l’un des index de la liste, en examinant les N éléments les plus récemment créés qui correspondent à la valeur filtrée dans cet index. Pour utiliser la sémantique de requête de secours indexée, la requête utilisateur doit disposer d’un filtre sur une colonne indexée et cette combinaison filtre/index doit respecter certaines contraintes supplémentaires. Seuls les types de combinaisons filtre/index répertoriées dans le tableau 2 peuvent participer à une requête de secours indexée :
Tableau 2. Combinaisons filtre/index autorisées dans les requêtes de secours
Type d’index
Requêtes prenant en charge le secours indexé
Type de contenu
Une valeur
Une seule valeur de choix
Une valeur
Une seule valeur de métadonnées gérées
Une valeur
Plusieurs valeurs
Valeurs multiples de métadonnées gérées
Une valeur
Plusieurs valeurs
Une seule valeur de personne ou de groupe
Une valeur
Date et heure
Une valeur
Une plage de valeurs
Nombre
Une valeur
Une plage de valeurs
Index composé avec date et heure, et une seule valeur de métadonnées gérées
Une valeur dans la colonne Métadonnées gérées
Une seule valeur ou une plage de valeurs dans la colonne Date et heure
Index composé avec un nombre et une seule valeur de métadonnées gérées
Une valeur dans une colonne Métadonnées gérées
Une seule valeur ou une plage de valeurs dans la colonne Nombre
Index composé avec type de contenu et une seule valeur de métadonnées gérées
Une valeur dans la colonne Métadonnées gérées
Une valeur dans la colonne Type de contenu
Index composé avec personne ou groupe et une seule valeur de métadonnées gérées
Une valeur dans la colonne Métadonnées gérées
Une valeur dans la colonne Personne ou Groupe
Type de contenu, composé et indexé avec date et heure
Une valeur dans la colonne Type de contenu
Une seule valeur ou une plage de valeurs dans la colonne Date et heure
Type de contenu, composé et indexé avec un nombre
Une valeur dans la colonne Type de contenu
Une seule valeur ou une plage de valeurs dans la colonne Nombre
Type de contenu, composé et indexé avec personne ou groupe
Une valeur dans la colonne Type de contenu
Une valeur dans la colonne Personne ou Groupe
Notes
Dans le tableau 2, « Une valeur » signifie un filtre exprimable par une clause dans CAML telle que 10. « Plusieurs valeurs » signifie un filtre exprimable par une clause dans CAML telle que 1011. « Une plage de valeurs » signifie un filtre exprimable par une clause dans CAML telle que 2010-02-04T08:00:00Z.
Pour certaines combinaisons indexées, il est impossible d’utiliser une requête de secours indexée si la requête n’est pas dans le format spécifié. Par exemple, si un index composé existe sur un champ de taxonomie de valeur unique et un champ date, mais que la requête utilisateur comprend plusieurs valeurs du champ de taxonomie dans une clause CAML, une requête de secours simple est exécutée au lieu d’une requête indexée.
Requêtes de secours simples. Les requêtes n’ayant pas de clause de filtrage indexé qui prennent en charge un secours indexé doivent exécuter une requête de secours simple. Une requête de secours simple fonctionne sur les N éléments supérieurs les plus récemment créés dans la liste. Si aucun de ces N éléments ne correspond aux paramètres de la requête utilisateur, aucun résultat n’est retourné.
Notes
Dans les requêtes de secours indexées et les requêtes de secours simples, N signifie (seuil de requête d’affichage de liste * .20). Le seuil de requête d’affichage de liste peut être configuré par un administrateur, mais le multiplicateur .20 n’est pas modifiable.
Conseils
La navigation des métadonnées est particulièrement adaptée aux champs de métadonnées gérées ; leur robustesse, leur nature hiérarchique et leur adaptabilité les rend efficaces dans la division du contenu de la liste en segments plus faciles à gérer.
Le tableau de bord Développeur peut être utilisé sur les pages d’affichage de liste avec la navigation de métadonnées pour voir la requête CAML et SQL derrière chacune des requêtes indexées et de secours qui ont été exécutées pour une requête utilisateur.
Certains administrateurs peuvent souhaiter traiter une requête de secours comme un avertissement signalant que les données dans une liste ne sont pas bien réparties en fonction des index et des valeurs de champs, et qu’une certaine redistribution des données est nécessaire pour que les utilisateurs de la liste soient en mesure d’accéder aux documents dont ils ont besoin. Si la journalisation détaillée est activée, les entrées de journal ULS sont écrites à chaque exécution d’une requête de secours. Une règle d’intégrité peut être développée pour intercepter ces entrées de journal et afficher un avertissement signalant ce fait à l’administrateur afin qu’une action puisse être entreprise.
Programmabilité de la fonction Navigation et filtrage des métadonnées
Le modèle d’objet pour la navigation et le filtrage des métadonnées se trouve principalement dans l’espace de noms Microsoft.Office.DocumentManagement.MetadataNavigation. Il inclut les types suivants.
Tableau 3. Modèle de programmation de navigation et de filtrage des métadonnées
Type |
Description |
|---|---|
Effectue le suivi de l’état des contrôles de navigation des métadonnées et du composant WebPart Affichage de liste lors d’une requête HTTP. |
|
Représente une hiérarchie d’objets MetadataNavigationItem. |
|
Représente un objet SPItem qui est associé à un objet MetadataNavigationHierarchy. |
|
Représente un filtre clé utilisé pour filtrer la navigation des métadonnées vers un sous-ensemble significatif et exploitable. |
|
Configure les paramètres sur un objet MetadataNavigationItem sur un objet SPList qui contrôlent l’affichage des hiérarchies et des filtres de métadonnées sur les affichages de liste. |