> Mobilité > Le meilleur des recherches Sharepoint

Le meilleur des recherches Sharepoint

Mobilité - Par Kevin Laahs - Publié le 24 juin 2010
email

Dans SharePoint, la compréhension de son architecture de recherche vous aidera à planifier un déploiement.

 

Le meilleur des recherches Sharepoint

Microsoft Search Service (MSSearch) est le service de recherche générique utilisé à divers degrés par les produits Microsoft, y compris SharePoint Services et Portal Server. Il prend en charge trois langages d’interrogation : Query Dialect 1, les extensions de texte intégral de SQL Server et Query Dialect 2, ce dernier permettant aux utilisateurs d’exécuter différentes formes de requêtes.

MSSearch crée des index en texte intégral sur le contenu et les propriétés des données structurées et semi-structurées, et permet des requêtes linguistiques rapides sur les données en question. Toutefois, pour qu’un index soit réellement utile, il doit prendre en charge les sources de contenu qui intéressent les utilisateurs (par exemple, partages de fichiers, contenu Web, dossiers Exchange Server, sites SharePoint) et les types de données à l’intérieur de ces sources. Il lui faut aussi des capacités d’extraction sophistiquées. Les applications qui utilisent l’index doivent fournir le contenu à indexer, formater les requêtes utilisateurs et retourner les résultats aux clients.

En conséquence de quoi, ces applications contrôlent dans les faits la globalité du processus de recherche et certaines s’acquittent de cette tâche mieux que d’autres. Par exemple, Portal Server fournit du contenu à indexer à partir de sources multiples, comme les dossiers publics Exchange et les bases de données IBM Lotus Notes, alors que l’indexation en texte intégral de SQL Server fournit du contenu uniquement à partir de tables SQL Server.

MSSearch s’appuie sur plusieurs composants majeurs pour prendre en charge l’indexation en texte intégral. La figure 1 illustre les composants suivants :
• Gestionnaires de protocole — Accèdent aux données via un protocole spécifique ou à partir d’un référentiel particulier. Les gestionnaires de protocole courants peuvent accéder aux données à partir de partages de fichiers, de sites Web, de dossiers publics, de Lotus Notes et de bases de données SQL Server. Le gestionnaire de protocole traite les URL qui lui sont transmises par le collecteur.
• Collecteur — Gère la file d’attente d’URL à accéder au niveau des protocoles. Pour chaque document accédé, le collecteur récupère le flux de contenu du gestionnaire de protocole et le transmet au filtre approprié.

• Filtres, également appelés IFilter — Extraient les informations textuelles à partir d’un format de document spécifique et passent les chaînes de texte et paires propriété/ valeur au moteur d’indexation. Par exemple, l’IFilter Microsoft Office extrait des termes des fichiers Microsoft Word, Excel et PowerPoint. D’autres IFilter fonctionnent avec le langage HTML ou les messages électroniques. Des fournisseurs tiers proposent d’autres filtres spécialisés : par exemple, Adobe Systems fournit un IFilter PDF. En l’absence d’IFilter, le texte dans le fichier ne peut pas être indexé.

• Séquenceurs et lemmatiseurs — Les séquenceurs déterminent les limites des mots dans le flux de caractères de la requête ou du document passé au crible et scindent les mots composés et expressions pour l’index en texte intégral. Un lemmatiseur extrait la forme racine d’un mot donné. Dans certaines langues, cet outil développe la forme racine d’un mot en formes alternatives : par exemple, en proposant courant, couru et coureur pour le mot racine courir.

• Indexeur — Prépare un index inversé du contenu. Ce type d’index est une structure de données avec une ligne par terme. Chaque ligne contient des informations sur les documents dans lesquels le terme apparaît et le nombre d’occurrences ainsi que la position relative du terme dans chaque document. L’index inversé fournit à MSSearch la possibilité d’appliquer des formules statistiques et probabilistes afin de calculer rapidement la pertinence des documents.

• Alertes — Notifient les utilisateurs lorsque du contenu nouveau ou actualisé correspond à une requête qu’ils ont stockée et lorsque des changements ont été apportés à des documents, sites, listes et bibliothèques.

• AutoCat — propose une méthode pour cataloguer automatiquement les éléments d’un site portail avec des éléments existants d’autres zones. AutoCat utilise un Topic Assistant, lequel suggère des emplacements de remplacement pour l’ajout logique d’éléments à des listes ou des bibliothèques de documents.

• Catalogues — Stocke les index en texte intégral au sein du système de fichiers sur le serveur qui exécute le service MSSearch. Les applications interagissent avec MSSearch pour gérer les index et catalogues. Les produits individuels contribuent également à l’architecture de recherche de MSSearch. Par exemple, Portal Server ajoute des alertes à l’architecture et les tiers peuvent fournir des filtres et des gestionnaires de protocole. Néanmoins, les produits n’exploitent pas tous l’ensemble des composants de recherche de MSSearch.

Par exemple, seul Portal Server utilise les alertes, mais tous les produits qui se servent de l’architecture MSSearch tireront parti des IFilter. Maintenant nous cernons mieux l’architecture de recherche, voyons comment SharePoint Services et Portal Server diffèrent dans leur mode d’utilisation de celle-ci. Nous verrons également en quoi cette divergence aboutit à des résultats différents pour les utilisateurs effectuant des recherches sur les sites SharePoint.

Téléchargez cette ressource

Comment sécuriser une PME avec l’approche par les risques ?

Comment sécuriser une PME avec l’approche par les risques ?

Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.

Mobilité - Par Kevin Laahs - Publié le 24 juin 2010