Partager via


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

Décrit comment créer un fichier de description OpenSearch (.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 Windows Explorer.

Cette rubrique contient les sections suivantes :

Fichier de description OpenSearch

Un fichier de description OpenSearch (.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 associez-vous à l’extension de nom de fichier .osdx lors du téléchargement à partir du web. Par exemple, un serveur n’est pas obligé d’utiliser .osdx. Un serveur peut retourner le fichier avec n’importe quelle extension de nom de fichier, comme .xml par exemple, et traité comme s’il s’agissait d’un fichier .osdx s’il utilise le type MIME approprié pour les documents de description OpenSearch (fichiers .osdx).
  • Fournissez une valeur d’élément ShortName (recommandé).

Éléments enfants requis mininum

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

<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>

En plus des é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 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>

Description

Windows utilise la valeur de l’élément Description pour remplir la description du fichier affichée dans le volet d’informations Windows Explorer 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 (un modèle d’URL) qui retourne les résultats au format RSS ou Atom. L’attribut format doit être défini sur application/rss+xml pour les résultats au format RSS ou application/atom+xml pour les résultats au format Atom, comme indiqué dans le code suivant.

Notes

L’élément de format Url et l’attribut de modèle sont communément 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 la recherche qui peut être affichée dans un navigateur web, vous devez fournir un élément Format d’URL=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 s’affiche dans la barre de commandes Windows Explorer, comme illustré 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 exécute une requête.

capture d’écran montrant le bouton de substitution de recherche web.

La restauration de la requête vers l’interface utilisateur web du magasin de données est importante dans certains scénarios. Par exemple, un utilisateur peut souhaiter afficher plus de 100 résultats (le 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 web du magasin de données, telles que le ré-interrogation avec un autre ordre de tri, 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 demande au service web.
  2. Tente de remplacer les jetons trouvés dans le modèle d’URL avant d’envoyer la demande 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 Windows Explorer.
{startIndex} Utilisé lors de l’obtention des résultats dans « pages ».
Remplacé par l’index du premier élément de résultat à retourner.
{startPage} Utilisé lors de l’obtention des résultats dans « pages ».
Remplacé par le numéro de page de l’ensemble de résultats de recherche à retourner.
{count} Utilisé lors de l’obtention des résultats dans « pages ».
Remplacé par le nombre de résultats de recherche par page que Windows Explorer demande.
{language} Remplacé par une chaîne qui indique la langue de la requête envoyée.
{inputEncoding} 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 de faire en sorte que le fournisseur OpenSearch obtienne des pages de résultats supplémentaires 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} jeton ou {startPage} 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 requêtes à l’aide d’un index d’élément, vous pouvez utiliser le {startIndex} jeton dans votre 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 demande. Le fournisseur répète ce processus jusqu’à ce qu’il obtienne suffisamment de résultats pour satisfaire sa limite ou atteigne 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 de 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.

Notes

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

 

Pagination à l’aide de l’index de page

Un index de page identifie la page de résultats spécifiée. Si vous souhaitez que les clients envoient des requêtes à l’aide d’un numéro de page, vous pouvez utiliser le {startPage} jeton dans votre 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 numéro de page. La première demande commence par la première page, comme indiqué dans l’exemple suivant :

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

Notes

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

 

Taille de la page

Vous pouvez configurer votre service web pour autoriser une demande de spécification de 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 le numéro 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 demande. Si la première page de résultats reçue contient moins d’éléments que le nombre demandé, le fournisseur réinitialise la taille de la 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 obligatoire, 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 sous la forme d’un flux RSS ou Atom, le fournisseur OpenSearch doit mapper les métadonnées d’élément dans les flux aux propriétés que l’interpréteur de commandes Windows 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

Mappages par défaut

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

Chemin d’accès XML RSS Propriété De l’interpréteur de commandes Windows (nom canonique)
Lien System.ItemUrl
Titre System.ItemName
Auteur System.Author
pubDate System.DateModified
Description System.AutoSummary
Category System.Keywords
boîtier/@type System.MIMEType
boîtier/@length System.Size
boîtier/@url System.ContentUrl
media:category System.Keywords
media:content/@fileSize System.Size
media:content/@type System.MIMEType
media:content/@url System.ContentUrl
media:group/content/@fileSize System.Size
media:group/content/@type System.MIMEType
media:group/content/@url System.ContentUrl
media:miniature/@url System.ItemThumbnailUrl

 

Notes

En plus des mappages par défaut d’é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és personnalisé dans le fichier .osdx.

 

Mappages de propriétés personnalisées

Vous pouvez personnaliser le mappage des éléments de votre sortie RSS vers les propriétés système de 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, 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 les 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 s’identifie https://example.com/schema/2009 comme espace de noms XML avec le préfixe « example ». Ce préfixe doit réapparaître avant l’élément email .

<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 e-mail 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>

Certaines propriétés ne peuvent pas être mappées, car les valeurs pour elles sont remplacées ultérieurement ou ne peuvent pas être modifiées. Par exemple, System.ItemFolderPathDisplay ou System.ItemPathDisplayNarrow ne peuvent pas être mappés, car ils sont calculés à partir de la valeur d’URL fournie dans les éléments link ou enclosure.

Miniatures

Vous pouvez fournir des URL d’image miniature 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. La fourniture d’images plus volumineuses prend plus de bande passante sans aucun avantage supplémentaire pour l’utilisateur.

Menu contextuel Ouvrir 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édé à cette URL. Votre flux doit fournir une URL personnalisée pour chaque élément afin de garantir que Windows ouvre une URL valide. Pour ce faire, vous pouvez inclure l’URL dans un élément à l’intérieur 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 explicitement définie dans le code XML de l’élément, le fournisseur OpenSearch la définit sur le dossier parent de l’URL de l’élément. Dans l’exemple ci-dessus, le fournisseur OpenSearch utilise la valeur de lien et définit la valeur de la propriété System.ItemFolderPathDisplay De l’interpréteur de commandes Windows sur "https://example.com/".

Personnaliser les affichages Windows Explorer avec des listes de description de propriétés

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

Les zones d’interface utilisateur de Windows Explorer qui peuvent être personnalisées à l’aide de listes de propriétés 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 listes de propriétés

Chaque zone de Windows Explorer est associée à un ensemble de proplists, qui sont elles-mêmes spécifiées en tant que propriétés. Vous pouvez spécifier des listes de propriétés personnalisées pour des éléments individuels dans vos jeux 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 du contenu (lors de la navigation) System.PropList.ContentViewModeForBrowse
Mode d’affichage mosaïque System.PropList.TileInfo
Volet Détails System.PropList.PreviewDetails
Info-bulle (info-bulle de pointage de l’élément) System.PropList.Infotip

 

 

Pour spécifier une liste de propriétés 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 la 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 des propriétés en mode d’affichage du contenu

La liste des propriétés spécifiées dans les proplists System.PropList.ContentViewModeForSearch et System.PropList.ContentViewModeForBrowse détermine ce qui est affiché en mode d’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 dans l’affichage de contenu

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

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 de propriété.

Notes

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 listes de propriétés s’applique à l’affichage des éléments dans les dispositions en mode Affichage de contenu : "~" Dans les exemples précédents, la vue Windows Explorer étiquette 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, la liste de propriétés a "System.Author" qui s’affiche sous la forme "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 simplement comme une valeur, sans l’étiquette.

Previews

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

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.

    Notes

    La propriété doit être fournie dans le flux RSS à l’aide de l’espace de noms Windows Shell ou mappée explicitement dans le fichier .osdx.

     

  2. Si ce n’est pas le cas, utilisez plutôt l’URL de 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 AUTRE URL pour l’aperçu que pour l’élément lui-même. Cela signifie que si vous fournissez différentes URL pour l’URL de lien et le boîtier ou media:content URL, Windows Explorer utilise l’URL de lien pour les aperçus de l’élément, mais utilise l’autre URL pour la détection du type de fichier, l’ouverture, le téléchargement, etc.

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

  1. Si vous fournissez un mappage à System.ItemFolderPathDisplay, Windows Explorer utilise cette URL

  2. Si vous ne fournissez pas de mappage, Windows Explorer identifie si les URL de lien et de boîtier sont différentes. Si c’est le cas, Windows Explorer utilise l’URL de lien.

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

    Notes

    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é.

     

Élément de menu Ouvrir l’emplacement du fichier

Lorsqu’un clique avec le bouton droit sur un élément, la commande de menu Ouvrir l’emplacement du fichier s’affiche. Cette commande dirige l’utilisateur vers le 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 ouvrirait la racine de la bibliothèque de documents dans le navigateur web.

Lorsqu’un utilisateur clique sur Ouvrir l’emplacement du fichier, Windows Explorer 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 » sur 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 Recherche fédérée Windows

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

Bonnes pratiques suivantes dans Recherche fédérée Windows

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