Concevoir des applications SharePoint basées sur la recherche
•Transferir como PPTX, PDF•
0 gostou•1,349 visualizações
Concevoir des applications SharePoint basées sur la recherche
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (17)
Semelhante a Concevoir des applications SharePoint basées sur la recherche
Semelhante a Concevoir des applications SharePoint basées sur la recherche (20)
Mais de Franck Cornu
Mais de Franck Cornu (12)
Último
Último (20)
Concevoir des applications SharePoint basées sur la recherche
- 1. Concevoir des applications pilotées par la recherche avec SharePoint 2010 et perspectives avec SharePoint 2013 Franck Cornu & Louis-Philippe Lavoie– Spécialistes SharePoint, Groupe GSoft
- 2. www.sharepointsummit.org Franck Cornu Consultant SharePoint depuis 3 ans Analyse et architecture d’information Développement Infrastructure Vos hôtes Louis –Philippe Lavoie Consultant SharePoint depuis 7 ans Conseil et Architecture Développement http://www.gsoft-group.com/fr http://spdynamite.net/
- 6. www.sharepointsummit.org Deux approches… Collections de sites Sites Bibliothèques et listes Répertoires Types de contenus Métadonnées gérées Trouvabilité de l’information Composants de présentation Concept
- 7. www.sharepointsummit.org Deux approches… Par métadonnées Par emplacement Concept
- 10. www.sharepointsummit.org KQL * Keyword Query Language SQL SQL Query Language FQL FAST Query Language Search Core Results * Afficher des résultats mis en forme Refinement Panel * Naviguer par raffinement successifs Advanced Search Box Créer des requête complexes Search Box Saisir les requêtes Crawled/Managed Properties* Rendre disponible l’information Scopes* Isoler un sous ensemble de résultats Content Sources Cibler le contenu à analyser Crawl Rules Contrôler l’analyse Synonyms * Associer des termes à la requête Langages Composants Configurations * Composants clés du search driven URL * Formaliser la requête Web Best Bets* Promouvoir des résultats La recherche dans SharePoint 2010 Ranking model* Modifier la pertinence des résultats
- 11. www.sharepointsummit.org Les outils avec SharePoint 2010: Par métadonnéesPar emplacement Colonnes de listes Types de contenu sites et collections de sites* Métadonnées gérées Search Driven applications Agrégation de contenu
- 12. www.sharepointsummit.org List View Webpart Content Query WebPart Search Core Results + Refinement Panel Fonctionnalité Mise à jour de contenu Instantanée Instantanée Non instantané (durée du crawl) Personnalisations (Affichage/Comportement) Faible (XSL , Classe « sealed ») Forte (XSL, C#) Très forte (XSL, C#) Flexibilité de filtrage Limitée (Statique) Limitée (Statique) Forte (Dynamique) Périmètre d’utilisation Listes et bibliothèques Listes et bibliothèques Sites et collections de sites Listes et bibliothèques Sites et collections de sites Applications web Couplage avec d’autres composants/fonctionnalités Limitée • Metadata navigation • Webparts connections Faible Forte • Managed Metadata • ContentOrganizer • Location-Based Metadata Defaults • Document ID Service Utilisation Manipulation sur des documents et informations ciblées. Agrégation de contenu ciblé statique. Agrégation de contenu ciblé avec filtrage dynamique. Avantages/Inconvénients
- 13. www.sharepointsummit.org Équipe 1 Équipe 2 Documents Projets Documents Projets Marketing Annonces Portail Content Organizer Location-Based Metadata Defaults Column default value ListView Webparts CQWP Remontée d informations Classification de l information Search Core Results Refinement Panel Search Box Drop Off Library Fonctionnalités annexes SharePoint 2010 Cas d’exemple
- 14. www.sharepointsummit.org Types de données source Crawled property Inclus dans l’index Managed property Requête Résultats attendu Élément de liste ows_Domaine(Text) Non Domaine Domaine:«Marketing» Élément de liste « Projet 1 » Document Word Mail Élément de liste Office:4(Text) Mail:6(Text) Author(Text) Oui Author Author:«Jean Bon» «Jean Bon» Document Word Mail Élément de liste Élément de liste ows_taxId_Domaine(Text) Non owstaxIdDomaine owstaxIdDomaine :«Marketing» Élément de liste « Projet 1 » Auto Auto Auto Manuel Manuel Auto Crawl Crawl Crawled/Managed properties Il est également possible de créer des managed properties automatiquement
- 15. www.sharepointsummit.org Par défaut correspondance exacte Diacritics insensitive Pas de recherche multilingue! <ManagedPropertyName><Operator*><Value> market* interna* marketing Domaine: « Marketing » KQL Langages
- 17. www.sharepointsummit.org * lien Permet de simuler la recherche multilingue Configuration Synonyms
- 18. www.sharepointsummit.org Uniquement des url Configuration Best Bets
- 19. www.sharepointsummit.org BM25 Get-SPEnterpriseSearchServiceApplication | New-SPEnterpriseSearchRankingModel –RankingModelXML {RankingModel.xml} &rm={RankingModel ID} DefaultRankingModelID Get-SPEnterpriseSearchServiceApplication -identity <Search Service Application Name> | Get-SPEnterpriseSearchRankingModel Configuration Ranking models
- 20. www.sharepointsummit.org modèle XML queryDependentFeature Title Department Longueur relative de la propriété (lengthNormalization): Pour ajuster la pertinence relative selon la longueur de contenu d’une managed property (Title vs Body par exemple), queryIndependentFeature UrlDepth* ClickDistance* FileType* categoryFeature Priority Language languageFeature Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataManagedProperty Configuration Ranking model * Fonctionne avec les pages faisant autorité
- 21. www.sharepointsummit.org lien Comportement Affichage Requête fixe Éditeur XSL ( XSLT 1.0) Ajout de termes à la requête Éditeur de paramètres Id de requête du composant Propriétés extraites (Managed properties) … Search Core ResultsComposants de recherche
- 22. www.sharepointsummit.org DYNAMIQUES Filter Category Definition MetadataThreshold NumberOfFiltersToDisplay ows_MetadataFacetInfo ShowCounts extraites dynamiquement Accuracy Index • Si filtres personnalisés, ne fonctionne pas avec le multilinguisme Part 1 Part 2 Part 3 Part 4 Refinement Panel Composants de recherche
- 25. www.sharepointsummit.org Perspectives avec SharePoint 2013 Configurations Composants Comparatifs
- 26. www.sharepointsummit.org KQL Keyword Query Language Search Results * Afficher des résultats mis en forme Refinement Panel * Naviguer par raffinement successifs Search Navigation Contextualiser la recherche Éditeur de requêtes * Créer des requêtes Crawled/Managed Properties* Rendre disponible l’information Import/Export Réutiliser la configuration Result Sources* Cibler le contenu à rechercher Client Type Identifier la provenance des requêtes Synonyms * Associer des termes à la requête Langages Composants Configurations URL * Formaliser la requête Web Query Rules* Promouvoir des résultats Search Dictionnary* Gérer les termes de recherche Result Types Identifier les types de résultats Search Box Saisir les requêtes Query Suggestions Proposer des requêtes Content Search* Afficher des résultats mis en forme Continous Crawl* Mettre à jour les résultats La recherche dans SharePoint 2013 * Composants clés du search driven Ranking model* Modifier la pertinence des résultats FQL* FAST Query Language
- 27. www.sharepointsummit.org Continuous Crawl Full crawl Incremental crawl lien Atténue le frein majeur à l’approche « search driven » par rapport à SharePoint 2010 Configuration
- 28. www.sharepointsummit.org Crawled properties/Managed Properties colonnes de sites lien * Managed properties Configuration
- 29. www.sharepointsummit.org Managed Properties Fonctionnalité Propriété(s)/Détail(s) Propriété(s)/Détail(s) Recherche par texte libre Searchable Inclure dans l’index Utilisation des propriétés dans les requêtes Queryable Utilisables par défaut Affichage de la propriété dans les résultats de recherche Retrievable Fetched Properties (Search Core Results) + XSL Trier les résultats sur la propriété Sortable Modified Date, Relevance Propriété disponible pour le raffinement Refinable Filter Category Definition (Refinement Panel) + XSL Autoriser des valeurs multiples Allow multiple values Allow multiple values Alias de propriété pour les requêtes Alias Requêtes pour les utilisateurs anonymes Safe for Anonymous Prise en compte des accents et de la casse Normalisation des jetons Prise en compte par défaut Correspondance complète sur la propriété Complete Matching *{terme}* (wildcard) Extraction automatique des métadonnées Custom entity extraction ∟ Extraction du nom de la compagnie Company name extraction Comparatif SharePoint 2010/2013
- 30. www.sharepointsummit.org périmètres de recherche source de contenu * * * Scopes toujours supportés Content sources Result Sources Configuration
- 31. www.sharepointsummit.org promouvoir * résultat en primeur blocs de résultats Query Rules Configuration
- 33. www.sharepointsummit.org Query Spelling Company Inclusions/Exclusions lien Search Dictionaries Configuration
- 34. www.sharepointsummit.org Custom Entity ExtractionConfiguration Type Correspondance Casse Nombre Word Extraction Mot exact 5 Word Part Extraction Partie d’un mot 5 Word Exact Extraction Mot exact 1 Word Part Exact Extraction Partie d’un mot 1
- 35. www.sharepointsummit.org sites collection de sites une content source managed properties Display Template JavaScript, HTML et CSS Result Types Configuration
- 36. www.sharepointsummit.org display templates Result Types display template Search Results Configuration
- 37. www.sharepointsummit.org lien • Éditeur de de requêtes displays templates Content Search WebPartComposants de recherche
- 38. www.sharepointsummit.org un Search Results Webpart display templates Managed Properties Display Name Refinement Panel WebPartComposants de recherche
- 39. www.sharepointsummit.org Je veux… Composants/Configurations Spécifier les sources de contenu à analyser Content sources Restreindre un sous-ensemble de résultats Content sources Scopes Promouvoir des résultats Query Rules Best Bets Affiner une recherche par mots clés Refinement Panel Ajouter des filtres de raffinements supplémentaires Refinement Panel (UI Interface) Refinement Panel (Filter Category Definition XML) Afficher des résultats de recherche Search Results WebPart Content Search Search Core Results Mettre en forme des résultats de recherche Display templates XML Configuration (Managed Properties) + XSL Orienter une recherche pour l’utilisateur Search Dictionaries Query suggestions (PowerShell) Équivalence SharePoint 2010/2013
- 41. www.sharepointsummit.org Mise en contexte Contoso Finance Marketing HR Home.aspx Home.aspx Home.aspx Home.aspx Memo Press Release News Job Posting Product Report 1 2 Zone Info 1 Zone Info 2 Contoso Inc3
- 42. www.sharepointsummit.org Quelles sont les informations présentes dans mon application? Comment les informations sont réparties dans mon application? Au sein de cette répartition, où se trouvent les points d’accès à l’information? Pour chacune de ces pages o Quelles sont les types informations possiblement affichables? o Doivent-elles s'afficher de manière groupée (un type d'information mélangé avec d'autre type au sein d'un même visuel)? Pour chacun des regroupements de types ou pour un seul type d'information Il y-a-t-il des contraintes de comportement? • A quelles conditions doivent-elles s'afficher? • Quelles sont les caractéristiques les plus pertinentes sur lesquelles trier l’information présentée? • Il y a-t-il une notion de recherche hiérarchique dans l’information? • Quel comportement si aucune information n’est disponible? Il y'a-t-il des contraintes d'affichage? • Quelles sont les propriétés du type à afficher? • Le type d’information possède-t-il un style graphique particulier? Quelles actions amènent à l'affichage des différents regroupements ou types d'information? Guide du petit architecte
- 44. Thank you for your attention! This presentation will be available on the Quebec SharePoint Summit web site after the event. Merci de votre attention ! Cette présentation sera disponible sur le site internet de SharePoint Summit Québec, après l’événement. franck.cornu@gsoft-group.com louis-philippe.lavoie@gsoft-group.com
- 45. SVP évaluez notre session! Complétez le sondage et courez la chance de gagner une tablette Surface Please rate our session! Fill out the survey and get a chance to win a Surface
Notas do Editor
- #
- Dans la mise en place d’intranets sous SharePoint (peu importe la version), il existe principalement (à mon sens) deux approches quand à la classification et à l’accès à l’information. Pour moi ces deux approches abordent la notion de « Trouvabilité » de l’information, à savoir la capacité d’un utilisateur d’accéder à la bonne ressource sur un site dans un temps défini. La première approche, en grande partie majoritaire, est de supposer que la chose qui caractérise une donnée est l’emplacement de celle-ci et que l’accès à celle-ci doit se faire en fonction de cet emplacement où, plus l’on détaille l’information, plus nous augmentons le niveau de profondeur de l’arborescence. Au niveau de SharePoint cela se traduit via la hiérarchie classique Collections de sites, sites, bibliothèques et listes, et répertoires. La deuxième approche consiste à supposer que ce qui décrit la donnée, sont ses métadonnées, indépendamment de l’emplacement où la donnée se trouve. Ainsi l’accès à l’information se fait via les propriétés. On utilise ici des outils comme les types de contenus et métadonnées gérées par exemple. Bien sûr, la plupart des implémentations ne sont pas soit purement par métadonnées soit purement par emplacement, il s’agit simplement de trouver le compromis entre les deux permettant d’obtenir une trouvabilité optimale. Dans une approche par métadonnées on met dont l’accent davantage sur l’accès à travers les propriétés de l’information. Des outils de présentation du contenu existent sous SharePoint 2010 (et 2013) de manière transversale à ces deux approches.
- Plus le nombre de documents, plus il devient difficile à un utilisateur de retrouver la bonne information de par la profondeur de l’arborescence dans une approche orientée par emplacement. A l’inverse une approche par métadonnées ne tient que peu compte de la volumétrie car s’intéressant aux propriétés.
- Plus le nombre de documents augmente, plus il devient difficile à un utilisateur de retrouver la bonne information de par la profondeur de l’arborescence dans une approche orientée par emplacement. A l’inverse une approche par métadonnées ne tient que peu compte de la volumétrie car s’intéressant aux propriétés. Il est évident que si les utilisateurs mettent beaucoup de temps à trouver ce qu’ils cherchent, c’est probable qu’ils ne reviendront pas souvent. Sur SharePoint et dans le cas d’intranets ou de travail collaboratif, et bien c’est sensiblement la même chose.
- Plusieurs aspect gravitent autour de la recherche dans SharePoint 2010. Voici les plus courant et les plus importants: Les langages de requêtes permettant de filtrer le contenu à remonter. Le KQL est le plus couramment utilisé car étant celui de base de SharePoint (Lorsque vous tapez un terme dans le Search Box, c’est du KQL). Ce langage contient un certain nombre d’opérateurs permettant de réaliser des requêtes complexes voir très complexes. Il est fortement lié à la notion de managed properties et scopes permettant de requêter sur des propriétés particulières à une donnée analysée (crawled property). A privilégier. Le FQL est le langage dédié à FAST Search Server dont la syntaxe est proche de celle de KQL Le SQL est le langage reprenant syntaxiquement les mêmes codes que SQL pour base de données. Devenant obsolète avec SharePoint 2013, il est à oublier pour vos solutions. Les composants permettent quant à eux de présenter, filtrer et naviguer à travers l’information. Le filtrage se fait par l’utilisation des différents langages de requêtes (KQL principalement) La configuration permet de définir les contenus et les comportements de recherche généraux. Ils influencent directement les composants de recherche selon leur configuration.
- Dans le cas d’une navigation par métadonnées il existe plusieurs composants offerts par SharePoint 2010 qui servent à l’agrégation de contenu basé sur les propriétés. En premier, le WebPart de liste classique, lié à l’emplacement permet via les répertoires et les vues de présenter l’information avec un premier niveau de pertinence. Ensuite, à mi-chemin entre les deux approches, on trouve le CQWP qui permet d’agréger de l’information au travers un site ou une collection via un filtre sur des types de contenus et colonnes particulières. Enfin, le Search Core Results, élément majeur de l’approche par métadonnées, couplé au refinement panel, offre une navigation totalement dissociée de l’emplacement. La notion de « Managed properties » apparaît dès lors pour la configuration globale. Il est tout à fait possible, dans une architecture d’information d’intranet, d’utiliser l’ensemble de ces outils à des niveau différents, chacun ayant les forces et leurs faiblesses dans chacun de ceux-ci. Cependant, vous rapprocher du search driven, vous assure une architecture d’informations très bien cadrée et structurée. A noter que les actions sur le document ou l’information en elle-même ne sont possible qu’au niveau le plus bas, c’est-à-dire via le ListView WebPart (Extraction, versions, etc…).
- Ici, je compare les principaux outils de SharePoint 2010 pour la présentation de contenu selon plusieurs critères. Concernant les personnalisations possibles, le ListView WebPart, bien qu’étant modifiable en affichage via une feuille de style XSL, reste très opaque, son comportement n’étant pas modifiable (pour les développeurs, il s’agit d’une classe « sealed » http://msdn.microsoft.com/fr-fr/library/microsoft.sharepoint.webpartpages.listviewwebpart(v=office.12).aspx). En revanche le CQWP et le Search Core Results, restent tout à fait personnalisables, d’une part par les options natives de ces composants mais également par la capacité à contrôler complétement le comportement logique via du code personnalisé.
- Cet exemple illustre comment tirer partie des différents composants d’agrégation de contenu selon le niveau dans la hiérarchie. Couplé aux fonctionnalités de Content Organizer, Location Based Metadata Defaults, et Column Defaut Value, la recherche devient le point central pour l’accès aux documents. 1 seul point d’entrée, 2 flux d’informations contrôlés, 2 niveaux hiérarchiques Un cycle descendant où l’information est classée selon ses propriétés plus ou moins automatiquement via les outils SharePoint. Un cycle ascendant où l’information est présentée selon en fonction des différents niveaux.
- Cette diapositive a pour but de présenter le fonctionnement des crawled properties et managed properties dans la recherche SharePoint 2010. Comprendre ce fonctionnement est important car il va vous permettre de contrôler la manière dont les éléments sont accédés à travers la recherche. Ce tableau illustre 3 cas de figures, s’attardant sur un point particulier à chaque fois. De manière générale, le processus est le suivant: 1. Dans une source de donnée quelconque, vous définissez une propriété (ex: une colonne de site associé à un élément) 2. SharePoint créer automatiquement une crawled property de la forme ows_(nom de propriété) après un premier processus de crawl 3. Pour pouvoir requêter directement sur cette propriété, il vous faut créer ensuite une managed property « mappée » à cette crawled property Si le paramètre « Inclus dans l’index » est à « Oui », cela signifie que lors d’une recherche « Free text » cette propriété sera évaluée sans l’intérmédiaire d’une managed property. Dans le cas d’une propriété de type « Métadonnée gérée », la crawled property associée ainsi que la managed property sont créer automatiquement respectivement« ows_taxId_(nom) » et « owstaxId(nom) » avec le paramètre d’inclusion dans l’index à « Non ». Il est possible de spécifier Pour explication en détails du processus, je vous conseille cette vidéo issue du channel officiel Microsoft: http://go.microsoft.com/fwlink/p/?LinkId=208823
- A noter que par défaut SharePoint utilise la correspondance exacte pour retrouver les informations!
- Les synonymes permettent d’associer des termes de recherche à d’autres par remplacement ou par expansion, mais une de leur utilité (détournée il faut bien le dire) peut être de gérer la recherche multilingue via un ensemble de mots clés d’entreprise traduits en utilisant une expansion. Vous avez peut être remarqué que les métadonnées gérées pouvaient être traduites dans l’application de service. Cependant, il faut savoir que la valeur réelle de la métadonnée sur un document sera dans la langue du magasin de termes par défaut peut importe la langue que vous sélectionnez lors de l’ajout. Exemple: FR(Ressources humaines) EN(Human resources). FR est la langue par défaut, EN la langue d’affichage. Lors de l’ajout d’un document avec la valeur « Human resources », la valeur réelle évaluée par la recherche sera « Ressources humaines » ce qui fait que si vous tapez « Human Resources », vous n’aurez aucun document. Avec une expansion via les synonymes (« Human resources » = « Ressources humaines »), vous pourrez émuler une recherche multilingue :D
- Les paramètres statiques sont destinés à contenir des compteurs et autre métriques. Mettre une managed property de type texte ne fait pas vraiment de sens dans cette catégorie, Les paramètres statiques tels que « ClickDistance », « FileType » et d’autres ne sont accessibles qu’avec FAST Search Server 2010. C’est pour cela que vous ne les trouverez pas dans la version Enterprise ou Standard de SharePoint 2010, Le paramètre UrlDepth est toutefois présent dans toutes les versions et fonctionne de pair avec les pages faisant autorité dans SharePoint. Un poids est une valeur entre 0 et 75. Il est donc possible de dévaluer ou surévaluer une propriété de manière totale et ce ci de manière systématique (statique) ou contextuel (dynamique), http://powersearching.wordpress.com/2013/01/25/explain-rank-in-sharepoint-2013-search/ http://allcomputers.us/windows_server/sharepoint-2010-search---relevancy-and-reporting---custom-ranking.aspx http://technet.microsoft.com/en-us/library/ff607990.aspx http://johanolivier.blogspot.ca/2011/05/improve-sharepoint-search-relevance.html http://books.google.ca/books?id=9BEuldznm-QC&pg=RA3-PA332&lpg=RA3-PA332&dq=static+ranking+parameters++values+Sharepoint+2010&source=bl&ots=xVusSWiWqK&sig=EysMhWixYCeQ0lLvirIGDmiHWZc&hl=fr&sa=X&ei=FORVUevYDMSN0QHy_IDQDw&ved=0CCwQ6AEwADgK#v=onepage&q=static%20ranking%20parameters%20%20values%20Sharepoint%202010&f=false http://allcomputers.us/windows_server/sharepoint-2010-search---relevancy-algorithms.aspx
- Les scopes version 2010 sont toujours accessibles en 2013, mais officiellement désuets La configuration des sources de contenu est quasiment identique En SP2013, la combinaison du moteur d’analyse (Web Analytics) avec la recherche, en plus des ponts avec la composante Sociale, permets de cibler du contenu selon ses statistiques d’utilisation ou de recherche (« Most Popular »), ou par nombre de gens suivant ce contenu (« Most Followed »)
- Les query rules permettent de lier des contenus entre eux de manière très simple et de rendre la recherche encore plus pertinente (à la manière d’un site de vente ne ligne par exemple).
- Les paramètres statiques sont destinés à contenir des compteurs et autre métriques. Mettre une managed property de type texte ne fait pas vraiment de sens dans cette catégorie, Les paramètres statiques tels que « ClickDistance », « FileType » et d’autres ne sont accessibles qu’avec FAST Search Server 2010. C’est pour cela que vous ne les trouverez pas dans la version Enterprise ou Standard de SharePoint 2010, Le paramètre UrlDepth est toutefois présent dans toutes les versions et fonctionne de pair avec les pages faisant autorité dans SharePoint. Un poids est une valeur entre 0 et 75. Il est donc possible de dévaluer ou surévaluer une propriété de manière totale et ce ci de manière systématique (statique) ou contextuel (dynamique), http://powersearching.wordpress.com/2013/01/25/explain-rank-in-sharepoint-2013-search/ http://allcomputers.us/windows_server/sharepoint-2010-search---relevancy-and-reporting---custom-ranking.aspx http://technet.microsoft.com/en-us/library/ff607990.aspx http://johanolivier.blogspot.ca/2011/05/improve-sharepoint-search-relevance.html http://books.google.ca/books?id=9BEuldznm-QC&pg=RA3-PA332&lpg=RA3-PA332&dq=static+ranking+parameters++values+Sharepoint+2010&source=bl&ots=xVusSWiWqK&sig=EysMhWixYCeQ0lLvirIGDmiHWZc&hl=fr&sa=X&ei=FORVUevYDMSN0QHy_IDQDw&ved=0CCwQ6AEwADgK#v=onepage&q=static%20ranking%20parameters%20%20values%20Sharepoint%202010&f=false http://allcomputers.us/windows_server/sharepoint-2010-search---relevancy-algorithms.aspx
- Définition globale (pas de configuration par site) http://technet.microsoft.com/en-us/library/ff607742.aspx Élément permettant de respecter les signes diacritiques dans le dictionnaire des synonymes Description : dans SharePoint Server 2010, les fichiers du dictionnaire des synonymes contiennent un élément <diacritics_sensitive>. Cet élément détermine si les signes diacritiques, tels que les accents, doivent être ignorés ou appliqués par le système de recherche pendant l’extension d’une requête à des termes du dictionnaire des synonymes. Par défaut, l’élément <diacritics_sensitive> est défini sur zéro et ignore les signes diacritiques. Dans SharePoint 2013, l’élément <diacritics_sensitive> n’est pas disponible. Les signes diacritiques sont désormais toujours respectés dans la mise en correspondance des termes de la requête avec les termes du dictionnaire des synonymes. Les variantes diacritiques ne sont pas automatiquement mises en correspondance avec les termes de la requête. Ainsi, un nombre moins important de termes de requête peuvent être étendus aux synonymes. Par exemple, l’entrée du dictionnaire des synonymes <munchen> ne correspond pas au terme de la requête <münchen>. Raison du changement : la fonctionnalité a une utilisation limitée. Le comportement observé dans SharePoint Server 2010 peut être obtenu en ajoutant des variantes diacritiques au dictionnaire des synonymes. Possibilité de migration : mettez à jour les dictionnaires de synonymes qui ne respectent pas les signes diacritiques. Pour ce faire, ajoutez les variantes diacritiques des termes concernés. Mode de remplacement dans le dictionnaire des synonymes Description : le mode de remplacement du dictionnaire des synonymes est déconseillé dans SharePoint 2013. Dans SharePoint Server 2010, vous pouvez classer des entrées du dictionnaire de synonymes en tant qu’extensions ajoutées à la requête en plus du terme d’origine. De la même façon, vous pouvez classer des entrées en tant que remplacements du terme d’origine d’une requête. Dans SharePoint 2013, les remplacements du dictionnaire des synonymes ne sont plus pris en charge. Toutes les entrées du dictionnaire des synonymes sont des extensions et le terme d’origine n’est pas supprimé de la requête. Le terme d’origine de la requête est toujours évalué au moment de la recherche dans l’index. Vous ne pouvez pas supprimer des synonymes ou des mots de l’index. Raison du changement : la fonctionnalité a une utilisation limitée et peut aussi entraîner des effets secondaires involontaires sur la pertinence. Possibilité de migration : aucune fonctionnalité équivalente.
- http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2013/01/08/no-metadata-no-problem-custom-entity-extraction-in-sharepoint-2013.aspx
- Ici plus de query ID, on spécifie explicitement le webpart sur lequel on veux connecter.
- Ici plus de query ID, on spécifie explicitement le webpart sur lequel on veux connecter.