Partager via

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

Décrit comment créer un fichier OpenSearch Description (.osdx) pour connecter des magasins de données externes au client Windows via le protocole OpenSearch . La recherche fédérée permet aux utilisateurs de rechercher dans un magasin de données distant et d’afficher les résultats à partir de l’Explorateur Windows.

Cette rubrique contient les sections suivantes :

Fichier de description OpenSearch

Un fichier OpenSearch Description (.osdx) pour La recherche fédérée Windows doit respecter les règles suivantes :

  • Être un document de description OpenSearch valide, tel que défini par la spécification OpenSearch 1.1.
  • Fournissez un modèle d’URL avec un type de format RSS ou Atom.
  • Utilisez l’extension de nom de fichier .osdx ou soyez associé à l’extension de nom de fichier .osdx lors du téléchargement à partir du Web. Par exemple, un serveur n’est pas requis pour utiliser .osdx. Un serveur peut retourner le fichier avec n’importe quelle extension de nom de fichier, par exemple .xml et traité comme s’il s’agissait d’un fichier .osdx s’il utilise le type MIME correct pour les documents de description OpenSearch (fichiers.osdx).
  • Fournissez une valeur d’élément ShortName (recommandé).

Éléments enfants minimum requis

L’exemple de fichier .osdx suivant se compose des éléments ShortName et Url, qui sont les éléments enfants requis minimums.

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
    <ShortName>My web Service</ShortName>
    <Url format="application/rss+xml" 
        template="https://example.com/rss.php?query=
        {searchTerms}&amp;start={startIndex}&amp;cnt={count}" />
</OpenSearchDescription>

Outre les éléments enfants minimaux, la recherche fédérée prend en charge les éléments standard suivants.

Nom abrégé

Windows utilise la valeur de l’élément ShortName pour nommer le fichier .searchconnector-ms (connecteur de recherche) créé lorsque l’utilisateur ouvre le fichier .osdx. Windows garantit que le nom de fichier généré utilise uniquement des caractères autorisés dans les noms de fichiers Windows. Si aucune valeur ShortName n’est fournie, le fichier .searchconnector-ms tente d’utiliser le nom de fichier du fichier .osdx à la place.

Le code suivant montre comment utiliser l’élément ShortName dans un fichier .osdx.

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
    <ShortName>My web Service</ShortName>
    ...
</OpenSearchDescription>

Descriptif

Windows utilise la valeur de l’élément Description pour remplir la description du fichier affichée dans le volet d’informations de l’Explorateur Windows lorsqu’un utilisateur sélectionne un fichier .searchconnector-ms.

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
    ...
    <Description>Searches the example company book catalog</Description>
</OpenSearchDescription>

Modèle d’URL pour les résultats rss/atom

Le fichier .osdx doit inclure un élément de format URL et un attribut de modèle (modèle d’URL) qui retourne des résultats au format RSS ou Atom. L’attribut de format doit être défini application/rss+xml sur pour les résultats mis en forme RSS ou application/atom+xml pour les résultats mis en forme Atom, comme indiqué dans le code suivant.

Note

L’élément de format URL et l’attribut de modèle sont couramment appelés modèles d’URL.

 

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
   ...
        <Url format="application/rss+xml" template="https://example.com/rss.php?query=
            {searchTerms}&amp;start={startIndex}&amp;cnt={count}" />
</OpenSearchDescription>

Modèle d’URL pour les résultats web

S’il existe une version des résultats de recherche qui peuvent être affichés dans un navigateur web, vous devez fournir un élément Url format=text/html et un attribut de modèle , comme indiqué dans le code suivant.

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
    ...
    <Url format="text/html" template="https://example.com/html.php?query={searchTerms}" />
</OpenSearchDescription>

Si vous fournissez un élément Url format="text/html » et un attribut de modèle , un bouton apparaît dans la barre de commandes de l’Explorateur Windows, comme indiqué dans la capture d’écran suivante, qui permet à l’utilisateur d’ouvrir un navigateur web pour afficher les résultats de la recherche lorsque l’utilisateur effectue une requête.

capture d'écran montrant le bouton de survol pour la recherche web.

Le transfert de la requête vers l'interface utilisateur web du magasin de données est important dans certains scénarios. Par exemple, un utilisateur peut souhaiter afficher plus de 100 résultats (nombre par défaut d’éléments demandés par le fournisseur OpenSearch). Si c’est le cas, l’utilisateur peut également utiliser des fonctionnalités de recherche disponibles uniquement sur le site du stockage de données, telles que la nouvelle requête avec un ordre de tri différent, ou le pivotement et le filtrage de la requête avec des métadonnées associées.

Paramètres du modèle d’URL

Le fournisseur OpenSearch effectue toujours les actions suivantes :

  1. Utilise le modèle d’URL pour envoyer la requête au service web.
  2. Tente de remplacer les jetons trouvés dans le modèle d’URL avant d’envoyer la requête au service web, comme suit :
    • Remplace les jetons OpenSearch standard répertoriés dans le tableau suivant.
    • Supprime tous les jetons qui ne sont pas répertoriés dans le tableau suivant.
Jeton pris en charge Utilisation par le fournisseur OpenSearch
{searchTerms} Remplacé par les termes de recherche que l’utilisateur tape dans la zone d’entrée de recherche de l’Explorateur Windows.
{startIndex} Utilisé lors de l’obtention de résultats dans « pages ».
Remplacé par l’index du premier élément de résultat à retourner.
{startPage} Utilisé pour obtenir des résultats sur plusieurs « pages ».
Cela est remplacé par le numéro de page de l’ensemble de résultats de recherche à renvoyer.
{count} Utilisé lors de l’obtention de résultats en « pages ».
Remplacé par le nombre de résultats de recherche par page que l’Explorateur Windows demande.
{langue} Remplacé par une chaîne qui indique la langue de la requête envoyée.
{encodageEntrée} Remplacé par une chaîne (telle que « UTF-16 ») qui indique l’encodage de caractères de la requête envoyée.
{outputEncoding} Remplacé par une chaîne (telle que « UTF-16 ») qui indique l’encodage de caractères souhaité pour la réponse du service web.

 

Résultats paginés

Vous pouvez limiter le nombre de résultats retournés par requête. Vous pouvez choisir de retourner une « page » de résultats à la fois, ou pour que le fournisseur OpenSearch obtienne des pages supplémentaires de résultats par numéro d’élément ou numéro de page. Par exemple, si vous envoyez vingt résultats par page, la première page que vous envoyez commence à l’index d’élément 1 et à la page 1 ; la deuxième page que vous envoyez commence à l’index d’élément 21 et à la page 2. Vous pouvez définir la façon dont vous souhaitez que le fournisseur OpenSearch demande des éléments à l’aide du {startItem} ou du {startPage} jeton dans le modèle d’URL.

Pagination à l’aide de l’index d’élément

Un index d’élément identifie le premier élément de résultat dans une page de résultats. Si vous souhaitez que les clients envoient des demandes à l’aide d’un index d’élément, vous pouvez utiliser le {startIndex} jeton dans l’attribut de modèle d’élément Url, comme indiqué dans le code suivant.

<Url format="application/rss+xml" 
    template="https://example.com/rss.php?query={searchTerms}&amp;start={startIndex}" />

Le fournisseur OpenSearch remplace ensuite le jeton dans l’URL par une valeur d’index de départ. La première demande commence par le premier élément, comme illustré dans l’exemple suivant :

https://example.com/rss.php?query=frogs&start=1

Le fournisseur OpenSearch peut obtenir des éléments supplémentaires en modifiant la valeur du {startIndex} paramètre et en émettant une nouvelle requête. Le fournisseur répète ce processus jusqu’à ce qu’il obtienne suffisamment de résultats pour satisfaire sa limite, ou atteint la fin des résultats. Le fournisseur OpenSearch examine le nombre d’éléments retournés par le service web dans la première page des résultats et définit la taille de page attendue sur ce nombre. Il utilise ce nombre pour incrémenter la {startIndex} valeur des requêtes suivantes. Par exemple, si le service web retourne 20 résultats dans la première requête, le fournisseur définit la taille de page attendue sur 20. Pour la requête suivante, le fournisseur remplace {startIndex} par la valeur 21 pour obtenir les 20 éléments suivants.

Note

Si une page de résultats retourné par le service web a moins d’éléments que la taille de page attendue, le fournisseur OpenSearch suppose qu’il a reçu la dernière page des résultats et cesse d’effectuer des demandes.

 

Pagination à l’aide de l’index de page

Un index de page identifie la page spécifiée des résultats. Si vous souhaitez que les clients envoient des demandes à l’aide d’un numéro de page, vous pouvez utiliser le {startPage} jeton dans l’attribut de modèle d’élément de format URL pour indiquer cela, comme illustré dans l’exemple suivant :

<Url format="application/rss+xml" 
    template="https://example.com/rss.php?query={searchTerms}&amp;page={startPage}" />

Le fournisseur OpenSearch remplace ensuite le jeton dans l’URL par un paramètre de numéro de page. La première requête commence par la première page, comme illustré dans l’exemple suivant :

https://example.com/rss.php?query=frogs&page=1

Note

Si une page de résultats retourné par le service web a moins d’éléments que la taille de page attendue, le fournisseur OpenSearch suppose qu’il a reçu la dernière page des résultats et cesse d’effectuer des demandes.

 

Taille de la page

Vous pouvez configurer votre service web pour permettre à une demande de spécifier la taille des pages à l’aide d’un paramètre dans l’URL. Une requête doit être spécifiée dans le fichier .osdx à l’aide du {count} jeton, comme suit :

<Url format="application/rss+xml" 
    template="https://example.com/rss.php?query={searchTerms}&amp;start={startIndex}&amp;cnt={count}" />

Le fournisseur OpenSearch peut ensuite définir la taille de page souhaitée, en nombre de résultats par page, comme illustré dans l’exemple suivant :

https://example.com/rss.php?query=frogs&start=1&cnt=50

Par défaut, le fournisseur OpenSearch effectue des requêtes à l’aide d’une taille de page de 50. Si vous souhaitez une autre taille de page, ne fournissez pas de {count} jeton et placez plutôt le nombre souhaité directement dans l’élément de modèle Url .

Le fournisseur OpenSearch détermine la taille de la page en fonction du nombre de résultats retournés lors de la première requête. Si la première page des résultats reçus comporte moins d’éléments que le nombre demandé, le fournisseur réinitialise la taille de page pour toutes les demandes de page suivantes. Si les demandes de page suivantes retournent moins d’éléments que demandé, le fournisseur OpenSearch suppose qu’il a atteint la fin des résultats.

En plus des éléments standard, la recherche fédérée prend en charge les éléments étendus suivants : MaximumResultCount et ResultsProcessing.

Étant donné que ces éléments enfants étendus ne sont pas pris en charge dans la spécification OpenSearch v1.1, ils doivent être ajoutés à l’aide de l’espace de noms suivant :

http://schemas.microsoft.com/opensearchext/2009/

Nombre maximal de résultats

Par défaut, les connecteurs de recherche sont limités à 100 résultats par requête utilisateur. Cette limite peut être personnalisée en incluant l’élément MaximumResultCount dans le fichier OSD, comme illustré dans l’exemple suivant :

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/" 
    xmlns:ms-ose="http://schemas.microsoft.com/opensearchext/2009/">
        ...
        <ms-ose:MaximumResultCount>200</ms-ose:MaximumResultCount>
</OpenSearchDescription>

L’exemple précédent déclare le préfixe ms-ose d’espace de noms dans l’élément OpenSearchDescription de niveau supérieur, puis l’utilise comme préfixe dans le nom de l’élément. Cette déclaration est requise, car MaximumResultCount n’est pas pris en charge dans la spécification OpenSearch v1.1.

Mappage de propriétés

Lorsque les résultats sont retournés par le service web en tant que flux RSS ou Atom, le fournisseur OpenSearch doit mapper les métadonnées d’élément dans les flux aux propriétés que Windows Shell peut utiliser. La capture d’écran suivante montre comment le fournisseur OpenSearch mappe certains des éléments RSS par défaut.

capture d’écran montrant les mappages de propriétés rss-to-windows-shell intégrés

Mappings par défaut

Les mappages par défaut des éléments XML RSS aux propriétés système Windows Shell sont répertoriés dans le tableau suivant. Les chemins XML sont relatifs à l’élément d'article. Le préfixe "media:" est défini par l'espace de noms Yahoo Search Namespace.

Chemin XML RSS Propriété Windows Shell (nom canonique)
Lien System.ItemUrl
Titre System.ItemName
Auteur System.Author
date de publication System.DateModified
Descriptif System.AutoSummary
Catégorie System.Keywords
boîtier/@type System.MIMEType
boîtier/@length System.Size
boîtier/@url System.ContentUrl
média:catégorie System.Keywords
media:content/@fileSize System.Size
media :content/@type System.MIMEType
media:content/@url System.UrlDuContenu
media:group/content/@fileSize System.Size
media:group/content/@type System.MIMEType
media:group/content/@url System.ContentUrl
media:miniature/@url System.ItemThumbnailUrl

 

Note

Outre les mappages par défaut des éléments RSS ou Atom standard, vous pouvez mapper d’autres propriétés système Windows Shell en incluant des éléments XML supplémentaires dans l’espace de noms Windows pour chacune des propriétés. Vous pouvez également mapper des éléments à partir d’autres espaces de noms XML existants tels que MediaRSS, iTunes, etc. en ajoutant un mappage de propriété personnalisé dans le fichier .osdx.

 

Mappages de propriétés personnalisés

Vous pouvez personnaliser le mappage d’éléments de votre sortie RSS vers les propriétés système Windows Shell en spécifiant le mappage dans le fichier .osdx.

La sortie RSS spécifie :

  • Un espace de noms XML et
  • Pour tout élément enfant d’un élément, un nom d’élément à mapper.

Le fichier .osdx identifie une propriété Windows Shell pour chaque nom d’élément dans un espace de noms. Les mappages de propriétés que vous définissez dans votre fichier .osdx remplacent les mappages par défaut, s’ils existent, pour ces propriétés spécifiées.

Le diagramme suivant illustre la façon dont une extension RSS est mappée aux propriétés Windows (nom canonique).

diagramme montrant que la combinaison de l’espace de noms xml et du chemin xml produit le nom canonique

Exemples de résultats RSS et mappage de propriétés OSD

L’exemple de sortie RSS suivant identifie https://example.com/schema/2009 comme espace de noms XML avec le préfixe « example ». Ce préfixe doit apparaître à nouveau avant l’élément e-mail .

<rss version="2.0" xmlns:example="https://example.com/schema/2009">
   ...
    <item>
      <title>Someone</title>
      <example:email>Someone@example.com</example:email>
    </item>

Dans l’exemple de fichier .osdx suivant, l’élément de messagerie XML est mappé à la propriété Windows Shell System.Contact.EmailAddress.

<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/"
    xmlns:ms-ose="http://schemas.microsoft.com/opensearchext/2009/">
...
 <ms-ose:ResultsProcessing format="application/rss+xml">
   <ms-ose:PropertyMapList>
     <ms-ose:PropertyMap sourceNamespaceURI="https://example.com/schema/2009/" >
       <ms-ose:Source path="email">
         <ms-ose:Property schema="http://schemas.microsoft.com/windows/2008/propertynamespace" name="System.Contact.EmailAddress" />
       </ms-ose:Source>
     </ms-ose:PropertyMap>
   </ms-ose:PropertyMapList>
 </ms-ose:ResultsProcessing>
...
</OpenSearchDescription>

Il existe certaines propriétés qui ne peuvent pas être mappées, car les valeurs pour elles sont remplacées ultérieurement ou ne sont pas modifiables. Par exemple, System.ItemFolderPathDisplay ou System.ItemPathDisplayNarrow ne peut pas être mappé, car ils sont calculés à partir de la valeur d’URL fournie dans les éléments de lien ou de boîtier.

Miniatures

Les URL d’image miniature peuvent être fournies pour n’importe quel élément à l’aide de l’élément media :thumbnail url=" ». La résolution idéale est de 150 x 150 pixels. Les plus grandes miniatures prises en charge sont de 256 x 256 pixels. Fournir des images plus volumineuses prend plus de bande passante pour aucun avantage supplémentaire pour l’utilisateur.

Ouvrir le menu contextuel de l’emplacement du fichier

Windows fournit un menu contextuel nommé Ouvrir l’emplacement du fichier pour les éléments de résultat. Si l’utilisateur sélectionne un élément dans ce menu, l’URL « parent » de l’élément sélectionné est ouverte. Si l’URL est une URL web, par exemple https://..., le navigateur web est ouvert et accédez à cette URL. Votre flux doit fournir une URL personnalisée pour chaque élément pour vous assurer que Windows ouvre une URL valide. Pour ce faire, incluez l’URL dans un élément au sein du code XML de l’élément, comme illustré dans l’exemple suivant :

<rss version="2.0" xmlns:example="https://example.com/schema/2009" 
    xmlns:win="http://schemas.microsoft.com/windows/2008/propertynamespace">
...
   <item>
      <title>Someone</title>
      <link>https://example.com/pictures.aspx?id=01</link>
      <win:System.ItemFolderPathDisplay>https://example.com/pictures_list.aspx
   </win:System.ItemFolderPathDisplay>
   </item>
...

Si cette propriété n’est pas définie explicitement dans le code XML de l’élément, le fournisseur OpenSearch le définit sur le dossier parent de l’URL de l’élément. Dans l’exemple ci-dessus, le fournisseur OpenSearch utiliserait la valeur de lien et définirait la valeur de la propriété System.ItemFolderPathDisplay de Windows Shell sur "https://example.com/".

Personnaliser les vues de l’Explorateur Windows avec des listes de description de propriétés

Certaines dispositions d’affichage De l’Explorateur Windows sont définies par des listes de description de propriété ou des proplists. Une liste de propriétés est une liste délimitée par des points-virgules, telle que "prop:System.ItemName; System.Author", utilisée pour contrôler l’affichage de vos résultats dans l’Explorateur Windows.

Les zones d’interface utilisateur de l’Explorateur Windows qui peuvent être personnalisées à l’aide de proplists sont illustrées dans la capture d’écran suivante :

capture d’écran montrant les zones d’interface utilisateur de l’Explorateur Windows qui peuvent être personnalisées à l’aide de proplists

Chaque zone de l’Explorateur Windows a un ensemble associé de proplists, qui sont eux-mêmes spécifiés en tant que propriétés. Vous pouvez spécifier des listes de propriétés personnalisées pour des éléments spécifiques dans vos ensembles de résultats ou pour tous les éléments d'un ensemble de résultats.

Zone d’interface utilisateur à personnaliser Propriété Windows Shell qui implémente la personnalisation
Mode d’affichage de contenu (lors de la recherche) System.PropList.ContentViewModeForSearch
Mode d’affichage de contenu (lors de la navigation) System.PropList.ContentViewModeForBrowse
Mode vue mosaïque System.PropList.TileInfo
Volet Détails System.PropList.PreviewDetails
Info-bulle (info-bulle de pointage de l’élément) Info-bulle System.PropList.Infotip

 

 

Pour spécifier une proplist unique pour un élément individuel :

  1. Dans votre sortie RSS, ajoutez un élément personnalisé représentant la liste de propriétés que vous souhaitez personnaliser. Par exemple, l’exemple suivant définit la liste pour le volet d’informations :

    <win:System.PropList.PreviewDetails>
    prop:System.ItemName;System.Author</win:System.PropList.PreviewDetails>

  2. Pour appliquer une propriété à chaque élément des résultats de recherche sans modifier la sortie RSS, spécifiez une proplist dans un élément ms-ose :PropertyDefaultValues dans le fichier .osdx, comme illustré dans l’exemple suivant :

    <ms-ose:ResultsProcessing format="application/rss+xml">
    <ms-ose:PropertyDefaultValues>
      <ms-ose:Property schema="http://schemas.microsoft.com/windows/2008/propertynamespace"
        name="System.PropList.ContentViewModeForSearch">prop:~System.ItemNameDisplay;System.Photo.DateTaken;
        ~System.ItemPathDisplay;~System.Search.AutoSummary;System.Size;System.Author;System.Keywords</ms-ose:Property>
    </ms-ose:PropertyDefaultValues>
  </ms-ose:ResultsProcessing>

Disposition de l'affichage du contenu des propriétés

La liste des propriétés spécifiées dans les propriétés System.PropList.ContentViewModeForSearch et System.PropList.ContentViewModeForBrowse détermine ce qui est affiché en mode Affichage contenu. Pour plus d’informations sur les listes de propriétés, consultez PropList.

Les propriétés sont disposées en fonction des nombres indiqués dans le modèle de disposition suivant :

capture d’écran montrant le modèle de disposition par défaut en mode contenu

Si nous utilisons la liste suivante des propriétés,

prop:~System.ItemNameDisplay;System.Author;System.ItemPathDisplay;~System.Search.AutoSummary;
    System.Size;System.Photo.DateTaken;System.Keywords

Ensuite, nous voyons l’affichage suivant :

capture d’écran montrant l’exemple de disposition des propriétés.

Note

Pour une meilleure lisibilité, les propriétés affichées dans la colonne la plus à droite doivent être étiquetées.

 

Indicateurs de liste de propriétés

Un seul des indicateurs définis dans la documentation des proplists s’applique à l'affichage des éléments en mode "Content View" : "~" Dans les exemples précédents, l’Explorateur Windows affiche certaines des propriétés, telles que Tags: animals; zoo; lion. Il s’agit du comportement par défaut lorsque vous spécifiez une propriété dans la liste. Par exemple, le proplist a "System.Author" qui est affiché sous la forme de "Authors: value". Lorsque vous souhaitez masquer l’étiquette de propriété, placez un "~" devant le nom de la propriété. Par exemple, si la proplist a "~System.Size", la propriété s’affiche en tant que valeur, sans l’étiquette.

Prévisualisations

Lorsque l’utilisateur sélectionne un élément de résultat dans l’Explorateur Windows et que le volet d’aperçu est ouvert, le contenu de l’élément est affiché en préversion.

Le contenu à afficher dans l’aperçu est spécifié par une URL, qui est déterminée comme suit :

  1. Si la propriété System.WebPreviewUrl Windows Shell est définie pour l’élément, utilisez cette URL.

    Note

    La propriété doit être fournie dans le RSS en utilisant l'espace de noms Windows Shell, ou être explicitement mappée dans le fichier .osdx.

     

  2. Si ce n’est pas le cas, utilisez plutôt l’URL du lien.

L’organigramme suivant montre cette logique.

organigramme montrant comment l’Explorateur Windows sélectionne l’URL à utiliser pour les préversions

Il est possible d’utiliser une URL différente pour l’aperçu que pour l’élément lui-même. Cela signifie que si vous fournissez des URL différentes pour l'URL de lien et l'enclosure ou media:content URL, l'Explorateur Windows utilise l'URL de lien pour les aperçus de l'élément, tandis qu'il utilise l'autre URL pour la détection du type de fichier, l'ouverture, le téléchargement, etc.

Comment l’Explorateur Windows détermine l’URL à utiliser :

  1. Si vous fournissez un mappage à System.ItemFolderPathDisplay, l’Explorateur Windows utilise cette URL

  2. Si vous ne fournissez pas de mappage, l’Explorateur Windows identifie si les URL de lien et de boîtier sont différentes. Dans ce cas, l’Explorateur Windows utilise l’URL du lien.

  3. Si les URL sont identiques ou s’il n’existe qu’une URL de lien, l’Explorateur Windows analyse le lien pour trouver le conteneur parent en supprimant le nom de fichier de l’URL complète.

    Note

    Si vous reconnaissez que l’analyse d’URL entraînerait des liens morts pour votre service, vous devez fournir un mappage explicite pour la propriété.

     

Ouvrir l’élément de menu Emplacement du fichier

Lorsqu’un utilisateur clique avec le bouton droit sur un élément, la commande du menu Ouvrir un emplacement de fichier s’affiche. Cette commande permet à l’utilisateur d’accéder au conteneur ou à l’emplacement de cet élément. Par exemple, dans une recherche SharePoint, la sélection de cette option pour un fichier dans une bibliothèque de documents ouvre la racine de la bibliothèque de documents dans le navigateur web.

Lorsqu’un utilisateur clique sur Ouvrir l’emplacement du fichier, l’Explorateur Windows tente de trouver un conteneur parent à l’aide de la logique indiquée dans l’organigramme suivant :

organigramme montrant comment l’Explorateur Windows identifie un conteneur parent

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

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

Suivre les meilleures pratiques 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