Partager via

Activation de votre magasin de données dans recherche fédérée Windows

  • Article

Explique comment permettre à votre magasin de données d’accéder à un service web OpenSearch et comment éviter les obstacles potentiels.

Cette rubrique est organisée comme suit :

Conditions d’acceptation des demandes de recherche

Le service web OpenSearch que vous créez sur votre serveur web doit remplir les deux conditions suivantes :

  • Être en mesure d’accepter une GET URL requête du client.

  • Autorisez les termes de recherche à être incorporés dans l’URL.

    L’exemple suivant montre comment un terme de recherche peut être incorporé dans une URL.

    https://example.com/search.aspx?query=terms&param=mysearchword

Notes

La recherche fédérée ne prend pas en charge l’envoi de POST requêtes à un service web.

 

Pour plus d’informations sur la construction d’une URL, consultez « Paramètres de modèle d’URL » dans Création d’un fichier de description OpenSearch dans la recherche fédérée Windows.

Syntaxe de requête prise en charge

Aucune syntaxe de requête spécifique n’est attendue dans Windows 7. Le fournisseur OpenSearch accepte les termes que l’utilisateur entre dans la zone de saisie de Windows Explorer et les encode dans l’URL. Il le fait en fonction du modèle d’URL décrit dans « Paramètres du modèle d’URL » dans Création d’un fichier de description OpenSearch dans la Recherche fédérée Windows.

Les utilisateurs s’attendent à ce que des termes distincts soient traités comme implicitement AND ensemble. Par exemple, une requête pour « Microsoft Windows » doit retourner uniquement les résultats qui contiennent à la fois « Windows » et « Microsoft ».

Protocoles d’authentification pris en charge

Recherche fédérée Windows prend en charge l’authentification windows et peut fournir des informations d’identification aux services web via les protocoles suivants :

  • NTLM.
  • Kerberos.
  • De base (uniquement sur https).
  • Autres fournisseurs de support de sécurité (SSP) installés sur Windows qui fournissent une capacité d’interrogation supplémentaire. Consultez la documentation du KIT de développement logiciel (SDK) d’interface SSP pour vous tenir informé de l’ajout potentiel d’autres fournisseurs de services partagés.

Envoi de requêtes et retour des résultats de recherche dans RSS ou Atom

Le fournisseur OpenSearch est responsable du mappage des valeurs des éléments XML aux propriétés système Windows Shell qui peuvent être utilisées par les applications Windows. Mais vous n’êtes pas limité aux mappages par défaut d’éléments RSS ou Atom standard, et vous pouvez inclure des éléments XML personnalisés dans l’espace de noms Windows pour chacune des propriétés. Par exemple, vous pouvez ajouter vos propres éléments XML personnalisés dans l’élément item pour fournir des métadonnées supplémentaires à Windows. Vous pouvez également mapper des éléments à partir d’autres espaces de noms XML, tels que iTunes

Exemple de sortie de flux RSS

L’exemple de sortie de flux RSS suivant retourne un élément.

<rss version="2.0" xmlns:media="https://search.yahoo.com/mrss/" xmlns:example="https://example.com/namespace">
   <channel>
      <title>Search Results</title>
      <item>
         <title>An example result</title>
         <link>https://example.com/pictures.aspx?id=01</link>
         <description>This is a test of the emergency search results system. If this were a real emergency result, you'd be reading something more useful.</description>
         <pubDate>Wed, 1 Oct 2008 23:12:00 GMT</pubDate>
         <media:content url="https://example.com/pictures/picture01.jpg" fileSize="212889" type="image/jpeg" height="768" width="1024"/>
         <media:thumbnail url="https://example.com/thumbnails/picture01.jpg" height="120" width="160"/>
         <example:dateTaken>Mon, 22 Sep 2008 23:12:00 GMT</example:dateTaken>
      </item>
   </channel>
</rss>

Pour plus d’informations sur le mappage de propriétés, consultez les sections « Éléments étendus dans la recherche fédérée WIndows » et « Mappages de propriétés personnalisées » dans Création d’un fichier de description OpenSearch dans recherche fédérée Windows.

Mappage automatique aux propriétés de l’interpréteur de commandes Windows

Dans les éléments de votre flux RSS, vous pouvez choisir d’inclure d’autres éléments XML qui mappent automatiquement aux propriétés du système Windows Shell. Pour ce faire, incluez un élément nommé d’après la propriété Windows Shell et préfixé avec l’espace de noms système Windows Shell. L’exemple suivant illustre la déclaration win=" http://schemas.microsoft.com/windows/2008/propertynamespace" d’espace de noms et l’inclusion d’un élément pour le mappage win:System.Contact.PrimaryEmailAddressde propriétés :

<rss version="2.0" xmlns:example="https://example.com/schema/2009" xmlns:win="http://schemas.microsoft.com/windows/2008/propertynamespace">
...
   <item>
      <title>Someone</title>
      <win:System.Contact.PrimaryEmailAddress>someone@example.com
   </win:System.Contact.PrimaryEmailAddress>
   </item>

Le préfixe d’espace de noms utilisé ici ("win") est une suggestion ; vous pouvez utiliser n’importe quel préfixe. Toutefois, vous devez utiliser les noms de propriétés Windows Shell exacts et inclure l’URI (Uniform Resource Identifier), comme illustré dans l’exemple suivant :

http://schemas.microsoft.com/windows/2008/propertynamespace

À propos des propriétés du système Windows Shell

Windows définit une liste complète des propriétés système et le format de type valeur requis pour chaque propriété. La documentation de la propriété d’interpréteur de commandes de fenêtre System.FileExtension , par exemple, spécifie que la valeur doit contenir le point de début (« .docx » et non « docx »).

Valeurs Date et heure

Le format de date et d’heure préféré est ISO-8601, comme illustré dans l’exemple suivant :

2008-01-16T 19:20:30:.45+01:00

Les développeurs .NET doivent utiliser la classe DateTime avec ToString("R") pour générer le format correct.

Pour plus d’informations sur le mappage de propriétés, consultez « Éléments étendus dans la recherche fédérée Windows » dans Création d’un fichier de description OpenSearch dans la recherche fédérée Windows.

Présentation de la Cartes Windows des éléments sur des types de fichiers

La recherche dans l’interface utilisateur windows Explorer permet aux utilisateurs de traiter les résultats comme des fichiers lorsqu’un élément RSS pointe vers un fichier stocké à distance. L’utilisateur peut faire glisser et déplacer des éléments sur le Bureau, et l’interface utilisateur Windows Explorer affiche l’icône appropriée et fournit le menu contextuel approprié. Si l’élément RSS ne pointe pas vers un fichier stocké à distance, le fichier est traité comme un lien et les utilisateurs peuvent y effectuer des actions telles que la création d’un raccourci ou son ouverture dans le navigateur.

L’organigramme suivant montre comment Windows détermine le type de fichier d’un élément.

organigramme montrant les chemins d’accès d’un élément aux décisions de le traiter comme un élément de type lien web ou comme un type de fichier

Le fournisseur OpenSearch effectue les étapes suivantes pour mapper un élément à un type de fichier :

  • Déterminez si l’élément doit être traité comme un fichier ou un lien web.
  • Identifiez l’extension de nom de fichier appropriée à utiliser.

Par exemple, si l’élément a une URL de lien qui utilise un chemin d’accès au système de fichiers (par exemple file:///\\server\share\etc\item.ext), le fournisseur OpenSearch traite le lien comme un fichier et détermine le type par l’extension de nom de fichier utilisée dans le chemin d’accès (.ext dans cet exemple).

Si l’élément utilise le boîtier RSS standard ou l’élément MediaRSS media:content , le fournisseur OpenSearch suppose que l’élément est un fichier et identifie l’extension de nom de fichier comme suit :

  • Si la propriété System.FileExtension Windows Shell a été mappée pour l’élément, le fournisseur utilise cette extension de nom de fichier.
  • Si la propriété System.FileExtension Windows Shell n’a pas été mappée, le fournisseur utilise l’attribut Type spécifié dans le boîtier ou l’élément content. Cet élément doit contenir une MIMEType chaîne, telle que "image/jpeg". Si est MIMEType associé à une extension de nom de fichier inscrite sur l’ordinateur client, l’élément est considéré comme un fichier de ce type. Si le MIMEType n’est pas associé à une extension de nom de fichier inscrite sur l’ordinateur client, l’élément est traité comme un type de lien web. Le fournisseur OpenSearch ne tente pas d’analyser l’attribut Url pour localiser l’extension de nom de fichier.
  • Si est MIMEType associé à une extension de nom de fichier inscrite sur l’ordinateur client, le fournisseur détermine si l’extension de nom de fichier est un type de fichier web connu (.htm, .html, .asp, .aspx, .php, .swf, .stm). Si c’est le cas, le type de fichier est considéré comme un type de lien web ; sinon, il est considéré comme un type de fichier. Par exemple, si est MIMEType "text/html" associé à l’extension de nom de fichier .htm, cet élément est considéré comme un lien web au lieu d’un type de fichier .htm.

Éviter les obstacles potentiels à l’activation d’un magasin de données

Certains magasins de données ne fournissent pas de service web compatible OpenSearch, mais peuvent toujours être connectés à La recherche fédérée Windows. Ces magasins de données sont les suivants :

  • Index distants avec des méthodes d’authentification qui ne sont pas prises en charge dans recherche fédérée Windows 7.

    Les exemples incluent l’authentification basée sur les formulaires et d’autres méthodes d’authentification personnalisées.

  • Si un magasin public de grande valeur a des API web publiques, n’importe qui peut écrire un autre service web compatible avec OpenSearch et appeler ces API en arrière-plan.

    Par exemple, la Bibliothèque du Congrès et les bases de données de recherche médicale.

  • Des index ou des magasins de données d’entreprise propriétaires et des magasins de gestion de contenu hérités, pour lesquels il peut être impossible d’implémenter un serveur frontal.

Toutefois, il existe des alternatives qui peuvent éviter les obstacles à l’activation d’un magasin de données. Voici quelques-unes de ces alternatives :

Pour écrire un service web intermédiaire lorsque vous ne pouvez pas modifier le service web pour la source de données existante ou que le service web fournit une API personnalisée :

  1. Écrivez un service web d’intermédiaire qui peut accepter une requête Windows 7.
  2. Connectez-vous à votre source de données et récupérez les résultats de la requête.
  3. Reformater les résultats au format RSS ou Atom.
  4. Retournez les résultats au client Windows 7.
  5. Notez que pour les services de données d’entreprise et de nombreux services de données Internet, vous devrez peut-être transmettre les informations d’identification de l’utilisateur au nom du service web pour effectuer la réduction des résultats en fonction des autorisations de l’utilisateur.

Pour utiliser un moteur de recherche existant lorsque vous ne pouvez pas activer un magasin de données public :

  1. Utilisez un moteur de recherche public qui prend déjà en charge OpenSearch avec RSS. Pour ce faire, fournissez à vos utilisateurs un fichier .osdx avec un modèle d’URL qui limite les résultats à ceux de votre domaine spécifique.

  2. Consultez l’exemple suivant de description OpenSearch pour rechercher uniquement le contenu d’aide pour Windows à l’aide d’une requête sur live.com.

    <?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
  <ShortName>Windows Help</ShortName>
  <Description>Search Windows Help using the live.com search engine</Description>
  <Language></Language>
  <Url type="text/html" template="https://windowshelp.microsoft.com/windows/search.aspx?=&amp;qu={searchTerms}"/>
  <Url type="application/rss+xml" template="https://api.search.live.com/rss.aspx?source=web&amp;query={searchTerms} site:windowshelp.microsoft.com&amp;web.count=50"/>
</OpenSearchDescription>

Pour utiliser un serveur d’indexation existant qui prend en charge OpenSearch lorsque vous ne pouvez pas activer les index ou magasins de données d’entreprise propriétaires :

  1. Sélectionnez un serveur d’indexation existant qui prend en charge OpenSearch pour indexer votre contenu, tel que sharePoint Search Server.
  2. Créez un fichier .osdx qui limite les résultats de l’index SharePoint à ceux de votre serveur à l’aide de leur syntaxe KeyWord dans le modèle d’URL.

Pour écrire un magasin de données côté client si une solution côté serveur uniquement ne fonctionne pas :

  1. Écrivez une source de données OpenSearch côté client qui se trouve entre le fournisseur Windows OpenSearch et la source de données externe.
  2. Utilisez l’API IOpenSearchSource Interface dans le Kit de développement logiciel (SDK) Windows pour créer un fichier .searchconnector-ms configuré de manière appropriée par le biais duquel les Explorer Windows peuvent appeler votre implémentation avec les paramètres de requête. Votre implémentation peut ensuite retourner des résultats au format RSS ou Atom. Cela permet à votre implémentation de fournir une interface utilisateur d’authentification personnalisée et de se connecter à la source de données à l’aide de son API propriétaire.

Notes

L’ouverture d’un fichier .osdx crée un fichier .searchconnector-ms (connecteur de recherche) dans le répertoire %userprofile%/searches et place un lien vers celui-ci dans le répertoire %userprofile%/links.

 

Ressources supplémentaires

Pour plus d’informations sur l’implémentation de la fédération de recherche dans des magasins de données distants à l’aide des technologies OpenSearch dans Windows 7 et versions ultérieures, consultez « Ressources supplémentaires » dans Recherche fédérée dans Windows.

Recherche fédérée dans Windows

Prise en main avec la recherche fédérée dans Windows

Connexion de votre service web dans la Recherche fédérée Windows

Création d’un fichier de description OpenSearch dans la Recherche fédérée Windows

Suivre les meilleures pratiques dans recherche fédérée Windows

Déploiement de connecteurs de recherche dans la recherche fédérée Windows