Présentation des gestionnaires de protocoles

  • Article

Certaines applications stockent leurs éléments dans des bases de données ou des types de fichiers personnalisés. Bien que Windows Search puisse indexer le nom et les propriétés du fichier, Windows n’a aucune connaissance du contenu du fichier. Par conséquent, ces éléments ne peuvent pas être indexés ou exposés dans l’interpréteur de commandes Windows. En créant un gestionnaire de protocole, vous pouvez permettre l’indexation de ces éléments. Vous pouvez également indexer un format de fichier composé tel qu’un fichier .zip.

Cette rubrique est organisée comme suit :

Indexation de banques de données avec des gestionnaires de protocoles

Lorsque les utilisateurs doivent rechercher des bases de données héritées, des banques de messages ou d’autres structures de données qui ne sont pas pris en charge par Windows Search, vous devez d’abord déterminer si un gestionnaire de protocole existe déjà pour cette banque de données. Cela peut par exemple être un gestionnaire visant à être utilisé par une application telle que SharePoint Server. Si c’est le cas, vous pouvez installer ce gestionnaire de protocole sur le système. Les gestionnaires de protocoles Windows Search utilisent des spécifications de conception similaires à SharePoint Server, et elles peuvent souvent être utilisées de manière interchangeable.

Pour plus d’informations sur le déploiement de Search Server 2008 avec Office SharePoint Server 2007, consultez Recherche fédérée [Search Server 2008].

Banques de données Shell

Avant qu’un développeur tiers de nouveaux formats de fichiers et de banques de données ne puisse faire apparaître ces formats et banques dans les résultats d’une requête dans l’Explorateur Windows, le développeur doit implémenter une source de données Shell. Une source de données Shell est un composant utilisé pour étendre l’espace de noms Shell et exposer des éléments dans une banque de données. Une banque de données est un référentiel de données. Une banque de données peut être exposée au modèle de programmation Shell en tant que conteneur qui utilise une source de données Shell. Les éléments d’une banque de données peuvent être indexés par le système Windows Search à l’aide d’un gestionnaire de protocole. Le gestionnaire de protocole implémente le protocole pour accéder à une source de contenu dans son format natif. Les interfaces ISearchProtocol et ISearchProtocol2 sont utilisées pour implémenter un gestionnaire de protocole personnalisé permettant de développer les sources de données pouvant être indexées.

Si vous souhaitez que les résultats de la requête apparaissent dans l’Explorateur Windows, vous devez implémenter une source de données Shell avant de pouvoir créer un gestionnaire de protocole permettant d’étendre l’index. Toutefois, si toutes les requêtes seront programmatiques (via OLE DB par exemple) et interprétées par le code de l’application plutôt que par l’interpréteur de commandes, un espace de noms Shell n’est pas requis (bien qu’il soit préférable).

Remarque

Une source de données Shell est parfois appelée extension d’espace de noms Shell. Un gestionnaire est parfois appelé extension Shell ou gestionnaire d’extensions Shell.

 

Si vous souhaitez que les utilisateurs voient les résultats de leur recherche dans l’Explorateur Windows, vous devez créer un gestionnaire de protocole et un ou plusieurs des compléments suivants :

  • Un gestionnaire de menus contextuels
  • Un gestionnaire d’icônes
  • Un autre type de gestionnaire de fichiers

Pour obtenir la liste des gestionnaires identifiés par le scénario de développement que vous essayez d’obtenir, consultez « Vue d’ensemble des gestionnaires » dans Windows Search en tant que plateforme de développement. Pour plus d’informations sur la création de gestionnaires, consultez Inscrire des extensions Shell, Menu contextuel et Gestionnaires de types de fichiers.

Gestionnaires de protocoles

Si la banque de données est également un conteneur (comme un dossier de système de fichiers), vous devez implémenter un filtre pour énumérer les URL du conteneur. Si la banque de données contient des données ou des types de fichiers autres que l’un des 200 types de fichiers pris en charge par Windows Search, vous devez implémenter un filtre permettant d’accéder au contenu des éléments de la banque de données et de les indexer. Windows Search utilise le gestionnaire de protocole et la technologie IFilter similaires à ce qu’utilise SharePoint Server. Si vous avez déjà des filtres pour une banque de données et un type de fichier spécifiques installés sur le système indexé, Windows Search peut être en mesure d’utiliser les interfaces existantes pour indexer ces données.

Pour obtenir une vue d’ensemble du processus d’indexation, consultez Le processus d’indexation. Pour plus d’informations conceptuelles sur les gestionnaires de filtres, consultez Développement de gestionnaires de filtres.

Filtres et gestionnaires de protocoles

Les gestionnaires de protocoles donnent à l’indexeur Windows Search l’accès aux banques de données, ce qui permet à l’indexeur d’analyser les nœuds d’une boutique de données et d’extraire les informations pertinentes à indexer. Windows Search, par exemple, comprend des gestionnaires de protocoles pour les banques de systèmes de fichiers et pour certaines versions des deux banques de données Microsoft Outlook. Lors de l’indexation d’e-mails d’Outlook, le gestionnaire de protocole analyse tous les messages dans un ensemble de dossiers Outlook et extrait les informations de chaque message et de chaque pièce jointe. Ces informations sont transmises à l’indexeur pour leur inclusion dans le catalogue Windows Search.

Pour obtenir une vue d’ensemble du Gestionnaire de catalogue et du Gestionnaire d’étendue d’analyse (CSM), consultez Utilisation du Gestionnaire de catalogue et Utilisation du gestionnaire d’étendue d’analyse.

Indexation d’un format de fichier composé

Un format de fichier composé peut être indexé afin que les éléments individuels du fichier puissent être renvoyés en tant que résultats individuels. Un format de fichier composé tel qu’un fichier compressé avec une extension de nom de fichier .zip est essentiellement une banque de données, et peut être traité en tant que tel à des fins d’indexation. L’exemple suivant affiche un fichier .zip dans l’espace de noms du système de fichiers (FILE://c:/test/test.zip) dans lequel il existe à la fois des sous-dossiers et des éléments individuels.

Test.zip 

    |-folder1 

    |    |-folder2 

    |           |- FileX.txt 

    |- FileY.doc

Le gestionnaire de protocole FILE découvre quand FILE://c:/test/test.zip est modifié en surveillant les journaux des modifications du système de fichiers, et il appelle un IFilter inscrit pour les fichiers .zip sur ce fichier lorsque le fichier change, mais il n’a aucune connaissance de la structure interne du fichier .zip lui-même.

Vous devez informer l’indexeur que le format de fichier composé est une banque de données. Il est nécessaire de le faire pour que les éléments individuels soient indexés et récupérés en tant qu’entités uniques. Une fois que vous avez implémenté une source de données Shell et effectué les étapes suivantes, vous disposez d’un gestionnaire de protocole qui peut traiter et exposer les données d’un format de fichier composé (fichier .zip) en tant qu’éléments individuels.

Pour informer l’indexeur qu’un fichier composé est une banque de données :

  1. Créez un gestionnaire de protocole (à l’aide de ISearchProtocol ou ISearchProtocol2) pour les fichiers .zip qui ont la possibilité de se lier au fichier source. Pour plus d’informations, consultez Installation et inscription de gestionnaires de protocoles.

    Par exemple, vous pouvez utiliser un chemin d’accès échappé au fichier .zip comme nom de dossier racine, puis utiliser une syntaxe de hiérarchie comme n’importe quel autre format de fichier.

    .zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfile

    À l’aide des exemples de données ci-dessus pour c:\test\test.zip, les URL uniques sont les suivantes. Avec ces URL, le gestionnaire de protocole a les informations nécessaires pour établir une liaison au fichier .zip et énumérer les URL enfants, y compris les fichiers internes afin qu’ils puissent être liés aux filtres .doc et .txt.

    

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/FileY.Doc 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1/folder2 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1/folder2/FileX.txt

  2. Vérifiez que votre gestionnaire de protocole répond aux deux conditions suivantes :

    • Les URL racines d’un fichier .zip doivent émettre PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) sur les URL qui sont les URL de fichier .zip racines. Par exemple, .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ doit émettre IsClosedDirectory = TRUE. Cela indique à l’indexeur que si la date de cette URL n’a pas changé, il n’est pas nécessaire de traiter les URL enfants.
    • Chaque URL enfant de cette URL doit émettre PKEY_Search_IsFullyContained (System.Search.IsFullyContained) sur les URL enfants de l’URL .zip racine. Normalement, à la fin d’une analyse incrémentielle, l’indexeur traite toutes les URL non visitées comme des éléments devant être supprimés. Mais le fichier .zip racine ne doit pas traiter les URL racines, car rien n’a changé. Émettre cette propriété comme TRUE indique à l’indexeur que si cette URL n’a pas été traitée à la fin d’une analyse incrémentielle, elle ne doit pas être supprimée. Elle ne sera supprimée que si l’élément racine a changé et qu’il n’est pas visité.

Windows Search nécessite une page de démarrage pour un protocole afin de savoir quelles URL analyser de manière incrémentielle et quelles URL doivent être ignorées lorsqu’elles sont trouvées. Mais on ne peut pas commencer par une URL pour chaque fichier .zip, car on ne sait pas où se trouve chaque fichier .zip. Par conséquent, l’URL de la page de démarrage du gestionnaire de protocole .zip doit être en mesure d’énumérer tout ce qui se trouve à la racine des chemins d’accès échappés de tous les fichiers .zip. Ces fichiers .zip ne sont pas nécessairement dans l’espace de noms FILE: et peuvent être une URL de type MAPI qui pointe vers un fichier .zip comme pièce jointe, par exemple.

Pour inscrire une racine en tant que page de démarrage :

  1. Inscrivez une racine telle que .zip:/// en tant que page de démarrage afin que tous les fichiers .zip y démarrent effectivement. Lors du traitement de l’URL .zip racine, votre gestionnaire de protocole doit générer la liste des URL enfants à émettre en interrogeant Windows Search pour toutes les URL avec System.FileExtension = « .zip ».

  2. Échappez ces URL pour supprimer les barres obliques et les renvoyer en tant qu’URL enfants. Un exemple de requête permettant de récupérer les types que vous recherchez peut ressembler à ceci.

    SELECT system.itemurl, System.DateModified FROM SystemIndex 
WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'

  3. Lorsque Windows Search effectue régulièrement une analyse incrémentielle sur votre URL racine .zip:///, vous devez refléter la liste des URL que Windows Search conserve déjà qui sont des URL .zip. Si une suppression est découverte dans la banque native où le fichier .zip est stocké, il n’apparaît pas dans votre énumération et cette branche de l’arborescence dans le fichier .zip est supprimée.

  4. Pour établir une liaison aux données .zip d’un autre gestionnaire de protocole, vous devez idéalement passer par IShellFolder pour lier cette URL au stockage de l’objet, et pour qu’elle ne considère pas toujours que c’est un fichier. Cela vous offre la possibilité d’utiliser des pièces jointes dans des banques de messages, par exemple.

  5. Lors de l’émission d’URL enfants pour chaque fichier .zip, vous devez utiliser PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) pour passer PKEY_DateModified (System.DateModified) du fichier .zip réel afin que l’indexeur analyse le fichier .zip uniquement s’il a changé.

Pour que vos URL .zip soient indexées immédiatement après leur création ou leur modification, et qu’elles ne doivent pas attendre une analyse incrémentielle pour découvrir leur nouvel état, vous pouvez éventuellement surveiller le système de fichiers vous-même pour guetter les modifications de fichier .zip. Toutefois, une telle approche ne fonctionne pas pour d’autres banques de données telles que MAPI.

Pour que vos URL .zip soient indexées lorsqu’elles sont créées ou modifiées :

  1. Création d’un filtre (et implémentation de l’interface IFilter) pour le type de fichier .zip. Pour plus d’informations, consultez Développement de gestionnaires de propriétés pour Windows Search.
  2. Chaque fois que votre implémentation IFilter est appelée, c’est parce que cette URL a été découverte ou modifiée. Ensuite, générez un événement pour l’URL .zip appropriée pour l’URL source, via l’interface IGatherNotifyInline. Cela vous donne la possibilité d’indiquer immédiatement à l’indexeur qu’il existe de nouvelles données à indexer sans avoir à attendre l’analyse incrémentielle.

Développement de gestionnaires de protocoles

Installation et inscription de gestionnaires de protocoles

Notification à l’index des modifications

Ajout d’icônes et de menus contextuels

Exemple de code : extensions Shell pour les gestionnaires de protocoles

Installation et inscription de gestionnaires de protocoles

Création d’un connecteur de recherche pour un gestionnaire de protocole

Débogage de gestionnaires de protocoles