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
- Éléments standard dans la recherche fédérée Windows
- Éléments étendus dans recherche fédérée Windows
- Previews
- Élément de menu Ouvrir l’emplacement du fichier
- Ressources supplémentaires
- Rubriques connexes
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}&start={startIndex}&cnt={count}" />
</OpenSearchDescription>
Éléments standard dans la recherche fédérée Windows
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}&start={startIndex}&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.
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 :
- Utilise le modèle d’URL pour envoyer la demande au service web.
- 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}&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}&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}&start={startIndex}&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.
Éléments étendus dans recherche fédérée Windows
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.
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).
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 :
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 :
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>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 :
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 :
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 :
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.
Si ce n’est pas le cas, utilisez plutôt l’URL de lien.
L’organigramme suivant montre cette logique.
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 :
Si vous fournissez un mappage à System.ItemFolderPathDisplay, Windows Explorer utilise cette URL
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.
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 :
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.
Rubriques connexes
-
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
-
Déploiement de connecteurs de recherche dans recherche fédérée Windows
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour