Partager via

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

Explique comment permettre à votre magasin de données d’être accessible par un service web OpenSearch et comment éviter les obstacles potentiels.

Cette rubrique est organisée comme suit :

Conditions d’acceptation de la demande de recherche

Le service web OpenSearch que vous créez sur votre serveur web doit répondre aux deux exigences suivantes :

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

  • Autorisez l’incorporation des termes de recherche 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

Note

La recherche fédérée ne prend pas en charge l’envoi POST de 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

Il n’existe aucune syntaxe de requête spécifique attendue dans Windows 7. Le fournisseur OpenSearch accepte les termes que l’utilisateur entre dans la zone d’entrée de l’Explorateur Windows et l’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 La création d’un fichier de description OpenSearch dans la recherche fédérée Windows.

Les utilisateurs s’attendent à ce que les termes distincts soient traités comme étant 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

La Recherche fédérée Windows prend en charge l’authentification basée sur 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é installés sur Windows qui fournissent une capacité d’interrogation supplémentaire. Consultez la documentation du Kit de développement logiciel (SDK) de l’interface SSP pour tenir compte de l’ajout potentiel d’autres fournisseurs de services partagés.

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

Le fournisseur OpenSearch est chargé de mapper les valeurs d’élément XML aux propriétés système Windows Shell qui peuvent être utilisées par les applications Windows. Toutefois, vous n’êtes pas limité aux mappages par défaut des éléments RSS ou Atom standard et 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 afin de 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és » dans Création d’un fichier de description OpenSearch dans La recherche fédérée Windows.

Cartographie automatique des propriétés du Windows Shell

Dans les éléments de votre flux RSS, vous pouvez choisir d’inclure d’autres éléments XML mappés automatiquement aux propriétés système Windows Shell. Pour ce faire, incluez un élément dont le nom est dérivé de la propriété Windows Shell et précédé du préfixe de 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 indiqué 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 du format de type valeur requis pour chaque propriété. La documentation de la propriété System.FileExtension Window Shell, par exemple, spécifie que la valeur doit contenir le point au début («.docx» et non «docx»).

Valeurs de date et d’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.

Comprendre comment Windows mappe des éléments aux types de fichiers

La recherche dans l’interface utilisateur de l’Explorateur Windows permet aux utilisateurs de traiter les résultats en tant que fichiers lorsqu’un élément RSS pointe vers un fichier stocké à distance. L’utilisateur peut faire glisser-déplacer des éléments vers le bureau, et l’interface utilisateur de l’Explorateur Windows affiche l’icône correcte 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 effectuer des actions sur celle-ci, telles que la création d’un raccourci ou l’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 à des décisions pour le traiter comme un élément de type de lien web ou comme un type de fichier

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

  • Identifiez 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 file:///\\server\share\etc\item.extexemple), le fournisseur OpenSearch traite le lien en tant que 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 media :content MediaRSS , 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é Windows Shell System.FileExtension 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 de contenu. Cet élément doit contenir une MIMEType chaîne, telle que "image/jpeg". Si l'extension MIMEType de nom de fichier est associée à une extension de nom de fichier enregistrée sur l’ordinateur client, l’élément est considéré comme un fichier de ce type. Si l’extension MIMEType de nom de fichier n’est pas associée à 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 l’extension MIMEType de nom de fichier est associée à 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 l’élément MIMEType "text/html" est 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 incluent :

  • Index distants avec des méthodes d’authentification qui ne sont pas prises en charge dans la 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 à valeur élevée possède des API web publiques, tout le monde peut écrire un autre service web compatible avec OpenSearch et appelle ces API en arrière-plan.

    Les exemples incluent la Bibliothèque du Congrès et les bases de données de recherche médicale.

  • Magasins de données ou index d’entreprise propriétaires et magasins de gestion de contenu hérités, pour lesquels il peut être impossible d’implémenter une interface frontale.

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 middle-man 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. Reformatez 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 le découpage 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. Vous pouvez le faire en fournissant à vos utilisateurs un fichier .osdx qui a un modèle d’URL qui limite les résultats uniquement à ceux de votre domaine spécifique.

  2. Consultez l’exemple suivant d’une 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 magasins de données d’entreprise propriétaires ou les index :

  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 uniquement à 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 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 correctement configuré via lequel l’Explorateur Windows peut appeler votre implémentation avec les paramètres de requête. Votre implémentation peut ensuite retourner les résultats mis en forme 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.

Note

L’ouverture d’un fichier .osdx crée un fichier .searchconnector-ms (connecteur de recherche) dans le répertoire %userprofile%/search 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 La recherche fédérée dans Windows.

Recherche fédérée dans Windows

Prise en main de 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

Bonnes pratiques suivantes dans la recherche fédérée Windows

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

 

 

  • Last updated on