Erstellen einer OpenSearch-Beschreibungsdatei in der Windows-Sammelsuche

Beschreibt, wie Sie eine OpenSearch Description -Datei (OSDX) erstellen, um externe Datenspeicher über das OpenSearch-Protokoll mit dem Windows-Client zu verbinden. Mithilfe der verbundenen Suche können Benutzer einen Remotedatenspeicher durchsuchen und die Ergebnisse im Windows-Explorer anzeigen.

Dieses Thema enthält folgende Abschnitte:

• OpenSearch-Beschreibungsdatei
  • Mininum Erforderliche untergeordnete Elemente
• Standardelemente in der Windows-Sammelsuche
  • Kurzname
  • Beschreibung
  • URL-Vorlage für RSS/Atom-Ergebnisse
  • URL-Vorlage für Webergebnisse
  • URL-Vorlagenparameter
  • Ergebnisse pro Seite
  • Seitennummerierung mithilfe des Eintragsindex
  • Paging mithilfe des Seitenindex
  • Seitenformat
• Erweiterte Elemente in der vernetzten Windows-Suche
  • Maximale Ergebnisanzahl
  • Eigenschaftszuordnung
• Vorschauen
• Menüelement "Dateispeicherort öffnen"
• Zusätzliche Ressourcen
• Verwandte Themen

OpenSearch-Beschreibungsdatei

Eine OpenSearch-Beschreibungsdatei (OSDX) für die Windows-Sammelsuche muss die folgenden Regeln einhalten:

• Seien Sie ein gültiges OpenSearch-Beschreibungsdokument, wie im OpenSearch 1.1-Spezifikation definiert.
• Stellen Sie eine URL-Vorlage mit einem RSS- oder atom-Formattyp bereit.
• Verwenden Sie die Dateinamenerweiterung OSDX, oder werden Sie beim Herunterladen aus dem Web mit der Dateinamenerweiterung OSDX verknüpft. Ein Server ist z. B. nicht erforderlich, um OSDX zu verwenden. Ein Server kann die Datei mit einer beliebigen Dateinamenerweiterung wie z. B. .xml zurückgeben und so behandelt werden, als wäre sie eine OSDX-Datei, wenn sie den richtigen MIME-Typ für OpenSearch Description-Dokumente (OSDX-Dateien) verwendet.
• Geben Sie einen ShortName-Elementwert an (empfohlen).

Minimale Anzahl erforderlicher untergeordneter Elemente

Das folgende Beispiel der OSDX-Datei besteht aus ShortName und Url Elementen, bei denen es sich um die mindestens erforderlichen untergeordneten Elemente handelt.

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

Standardelemente in der Windows-federierten Suche

Neben den minimalen Kindelementen unterstützt die föderierte Suche die folgenden Standardelemente.

Kurzname

Windows verwendet den Wert des ShortName-Elements , um die .searchconnector-ms (Search Connector)-Datei zu benennen, die erstellt wird, wenn der Benutzer die OSDX-Datei öffnet. Windows stellt sicher, dass der generierte Dateiname nur Zeichen verwendet, die in Windows-Dateinamen zulässig sind. Wenn kein ShortName-Wert angegeben wird, versucht die .searchconnector-ms-Datei stattdessen, den Dateinamen der OSDX-Datei zu verwenden.

Der folgende Code veranschaulicht, wie das ShortName-Element in einer OSDX-Datei verwendet wird.

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

Description

Windows verwendet den Wert des Description-Elements , um die im Windows Explorer-Detailbereich angezeigte Dateibeschreibung aufzufüllen, wenn ein Benutzer eine .searchconnector-ms-Datei auswählt.

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

URL-Vorlage für rss/atom-Ergebnisse

Die OSDX-Datei muss ein URL-Formatelement und ein Vorlagenattribute (eine URL-Vorlage) enthalten, das Ergebnisse im RSS- oder Atom-Format zurückgibt. Das Format-Attribut muss auf application/rss+xml für RSS-formatierte Ergebnisse oder auf application/atom+xml für Atom-formatierte Ergebnisse festgelegt werden, wie im folgenden Code gezeigt.

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

URL-Vorlage für Webergebnisse

Wenn eine Version der Suchergebnisse vorhanden ist, die in einem Webbrowser angezeigt werden können, sollten Sie ein URL-Format=text/html Element und ein Vorlagenattribut angeben, wie im folgenden Code gezeigt.

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

Wenn Sie ein Url format="text/html" -Element und Vorlagen-Attribut angeben, wird eine Schaltfläche in der Windows Explorer-Befehlsleiste angezeigt, wie im folgenden Screenshot dargestellt, damit der Benutzer einen Webbrowser öffnen kann, um die Suchergebnisse anzuzeigen, wenn der Benutzer eine Abfrage ausführt.

Der Rückrollvorgang der Abfrage zur Web-UI des Datenspeichers ist in einigen Szenarien wichtig. Beispielsweise kann ein Benutzer mehr als 100 Ergebnisse anzeigen (die Standardanzahl der Elemente, die der OpenSearch-Anbieter anfordert). Wenn ja, möchte der Benutzer möglicherweise auch Suchfeatures verwenden, die nur auf der Website des Datenspeichers verfügbar sind, z. B. eine erneute Abfrage mit einer anderen Sortierreihenfolge oder das Pivotieren und Filtern der Abfrage mit verwandten Metadaten.

URL-Vorlagenparameter

Der OpenSearch-Anbieter führt immer die folgenden Aktionen aus:

1. Verwendet die URL-Vorlage, um die Anforderung an den Webdienst zu senden.
2. Versucht, die in der URL-Vorlage gefundenen Token zu ersetzen, bevor die Anforderung an den Webdienst gesendet wird, wie folgt:
   • Ersetzt die standardmäßigen OpenSearch-Token, die in der folgenden Tabelle aufgeführt sind.
   • Entfernt alle Token, die nicht in der folgenden Tabelle aufgeführt sind.

Paginierte Ergebnisse

Möglicherweise möchten Sie die Anzahl der pro Anforderung zurückgegebenen Ergebnisse einschränken. Sie können jederzeit eine "Seite" von Ergebnissen zurückgeben oder dem OpenSearch-Anbieter zusätzliche Seiten mit Ergebnissen entweder nach Elementnummer oder Seitenzahl abrufen lassen. Wenn Sie z. B. zwanzig Ergebnisse pro Seite senden, beginnt die erste Seite, die Sie senden, am Elementindex 1 und auf Seite 1; die zweite Seite, die Sie senden, beginnt am Elementindex 21 und bei Seite 2. Sie können definieren, wie der OpenSearch-Anbieter Elemente anfordern soll, indem Sie entweder das {startItem}- oder das {startPage}-Token in der URL-Vorlage verwenden.

Paging mit dem Elementindex

Ein Elementindex identifiziert das erste Ergebniselement auf einer Ergebnisseite. Wenn Clients Anforderungen mithilfe eines Elementindex senden sollen, können Sie das {startIndex} token im Vorlagenattribut des Url-Elements verwenden, wie im folgenden Codebeispiel gezeigt.

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

Der OpenSearch-Anbieter ersetzt dann das Token in der URL durch einen Anfangsindexwert. Die erste Anforderung beginnt mit dem ersten Element, wie im folgenden Beispiel veranschaulicht:

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

Der OpenSearch-Anbieter kann zusätzliche Elemente abrufen, indem der {startIndex} Parameterwert geändert und eine neue Anforderung ausgestellt wird. Der Anbieter wiederholt diesen Prozess, bis er genügend Ergebnisse erhält, um seinen Grenzwert zu erfüllen, oder das Ende der Ergebnisse erreicht. Der OpenSearch-Anbieter untersucht die Anzahl der elemente, die vom Webdienst auf der ersten Seite der Ergebnisse zurückgegeben werden, und legt die erwartete Seitengröße auf diese Zahl fest. Sie verwendet diese Zahl, um den {startIndex} Wert für nachfolgende Anforderungen zu erhöhen. Wenn der Webdienst beispielsweise 20 Ergebnisse in der ersten Anforderung zurückgibt, legt der Anbieter die erwartete Seitengröße auf 20 fest. Für die nächste Anforderung ersetzt der Anbieter {startIndex} durch den Wert 21, um die nächsten 20 Elemente abzurufen.

Paging mithilfe des Seitenindex

Ein Seitenindex identifiziert die angegebene Ergebnisseite. Wenn Sie möchten, dass Clients Anforderungen mithilfe einer Seitenzahl senden, können Sie das {startPage}-Token im Vorlagenattribut des URL-Formats verwenden, um dies anzugeben, wie im folgenden Beispiel gezeigt:

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

Der OpenSearch-Anbieter ersetzt dann das Token in der URL durch einen Seitenzahlenparameter. Die erste Anforderung beginnt mit der ersten Seite, wie im folgenden Beispiel gezeigt:

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

Seitenformat

Möglicherweise möchten Sie Ihren Webdienst so konfigurieren, dass eine Anforderung die Größe der Seiten mithilfe eines Parameters in der URL angeben kann. Eine Anforderung muss in der OSDX-Datei mithilfe des {count} Tokens wie folgt angegeben werden:

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

Der OpenSearch-Anbieter kann dann die gewünschte Seitengröße in der Anzahl der Ergebnisse pro Seite festlegen, wie im folgenden Beispiel gezeigt:

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

Standardmäßig stellt der OpenSearch-Anbieter Anforderungen mit einer Seitengröße von 50. Wenn Sie eine andere Seitengröße wünschen, geben Sie kein {count} Token an, und platzieren Sie stattdessen die gewünschte Zahl direkt im Url-Vorlagenelement.

Der OpenSearch-Anbieter bestimmt die Seitengröße basierend auf der Anzahl der Ergebnisse, die für die erste Anforderung zurückgegeben werden. Wenn die erste Seite der empfangenen Ergebnisse weniger Elemente enthält als die angeforderte Anzahl, setzt der Anbieter die Seitengröße für alle nachfolgenden Seitenanforderungen zurück. Wenn nachfolgende Seitenanforderungen weniger Elemente zurückgeben als angefordert, geht der OpenSearch-Anbieter davon aus, dass es das Ende der Ergebnisse erreicht hat.

Erweiterte Elemente in der Windows-verteilte Suche

Neben den Standardelementen unterstützt die Sammelsuche die folgenden erweiterten Elemente: MaximumResultCount und ResultsProcessing.

Da diese erweiterten untergeordneten Elemente in der OpenSearch v1.1-Spezifikation nicht unterstützt werden, müssen sie mithilfe des folgenden Namespaces hinzugefügt werden:

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

Maximale Ergebnisanzahl

Suchverbinder sind standardmäßig auf 100 Ergebnisse pro Benutzerabfrage beschränkt. Dieser Grenzwert kann angepasst werden, indem das MaximumResultCount-Element in die OSD-Datei eingeschlossen wird, wie im folgenden Beispiel gezeigt:

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

Im vorherigen Beispiel wird das Namespacepräfix im ms-ose der obersten Ebene deklariert und anschließend als Präfix im Elementnamen verwendet. Diese Deklaration ist erforderlich, da das MaximumResultCount in der OpenSearch v1.1-Spezifikation nicht unterstützt wird.

Eigenschaftszuordnung

Wenn Ergebnisse vom Webdienst als RSS- oder Atom-Feed zurückgegeben werden, muss der OpenSearch-Anbieter die Elementmetadaten in den Feeds eigenschaften zuordnen, die von der Windows-Shell verwendet werden können. Der folgende Screenshot veranschaulicht, wie der OpenSearch-Anbieter einige der Standard-RSS-Elemente zuordnet.

Standardzuordnungen

Die Standardzuordnungen von RSS-XML-Elementen zu Windows Shell-Systemeigenschaften sind in der folgenden Tabelle aufgeführt. XML-Pfade sind relativ zum Element. Das "media:" Präfix wird durch den Yahoo Search Namespace-Namespace definiert.

Benutzerdefinierte Eigenschaftenzuordnungen

Sie können die Zuordnung von Elementen aus Der RSS-Ausgabe zu den Windows Shell-Systemeigenschaften anpassen, indem Sie die Zuordnung in der OSDX-Datei angeben.

Die RSS-Ausgabe gibt Folgendes an:

• Ein XML-Namespace und
• Für jedes untergeordnete Element eines Eintrags soll ein Elementname zugeordnet werden, um eine Zuordnung vorzunehmen.

Die OSDX-Datei identifiziert eine Windows Shell-Eigenschaft für jeden Elementnamen in einem Namespace. Die Eigenschaftenzuordnungen, die Sie in ihrer OSDX-Datei definieren, überschreiben die Standardzuordnungen, sofern vorhanden, für diese angegebenen Eigenschaften.

Das folgende Diagramm veranschaulicht, wie eine RSS-Erweiterung Windows-Eigenschaften (kanonischer Name) zugeordnet ist.

Beispiel für RSS-Ergebnisse und OSD-Eigenschaftszuordnung

Im folgenden Beispiel wird https://example.com/schema/2009 als XML-Namespace mit dem Präfix "example" in der RSS-Ausgabe identifiziert. Dieses Präfix muss vor dem E-Mail-Element erneut angezeigt werden.

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

Im folgenden Beispiel der OSDX-Datei ist das XML-E-Mail-Element der Windows Shell-Eigenschaft "System.Contact.EmailAddress" zugeordnet.

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

Es gibt einige Eigenschaften, die nicht zugeordnet werden können, da die Werte für sie entweder später überschrieben werden oder nicht bearbeitet werden können. Beispielsweise kann System.ItemFolderPathDisplay oder System.ItemPathDisplayNarrow nicht zugeordnet werden, da sie aus dem URL-Wert berechnet werden, der in den Verbindungs- oder Anlagenelementen bereitgestellt wird.

Miniaturbilder

Miniaturbild-URLs können für jedes Element mithilfe des Elements media:thumbnail url="" bereitgestellt werden. Die ideale Auflösung beträgt 150 x 150 Pixel. Die größten unterstützten Miniaturansichten sind 256 x 256 Pixel. Durch die Bereitstellung größerer Bilder wird mehr Bandbreite benötigt, um dem Benutzer keinen zusätzlichen Nutzen zu bieten.

Kontextmenü "Dateispeicherort öffnen"

Windows stellt ein Kontextmenü namens " Dateispeicherort öffnen " für Ergebniselemente bereit. Wenn der Benutzer ein Element aus diesem Menü auswählt, wird die URL "übergeordnetes Element" für das ausgewählte Element geöffnet. Wenn es sich bei der URL um eine Web-URL handelt, wie z. B. https://..., wird der Webbrowser geöffnet und zu dieser URL navigiert. Ihr Feed sollte eine benutzerdefinierte URL für jedes Element bereitstellen, um sicherzustellen, dass Windows eine gültige URL öffnet. Dies kann erreicht werden, indem die URL in ein Element innerhalb des XML-Codes des Elements eingeschlossen wird, wie im folgenden Beispiel dargestellt:

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

Wenn diese Eigenschaft nicht explizit im XML-Code des Elements festgelegt wird, legt der OpenSearch-Anbieter sie auf den übergeordneten Ordner der URL des Elements fest. Im obigen Beispiel würde der OpenSearch-Anbieter den Linkwert verwenden und den Wert der Windows-Shell-Eigenschaft System.ItemFolderPathDisplay auf "https://example.com/" setzen.

Anpassen von Windows Explorer-Ansichten mit Eigenschaftenbeschreibungslisten

Einige Windows Explorer-Ansichtslayouts werden durch Eigenschaftenbeschreibungslisten oder Proplists definiert. Eine Proplist ist eine durch Semikolons getrennte Liste von Eigenschaften, wie "prop:System.ItemName; System.Author", die verwendet wird, um das Erscheinungsbild Ihrer Ergebnisse im Windows-Explorer zu steuern.

Die Benutzeroberflächenbereiche von Windows Explorer, die mithilfe von Proplists angepasst werden können, werden im folgenden Screenshot veranschaulicht:

Jeder Bereich von Windows Explorer verfügt über einen zugeordneten Satz von Proplists, die selbst als Eigenschaften angegeben werden. Sie können benutzerdefinierte Proplists für einzelne Elemente in Ihren Resultsets oder für alle Elemente in einer Gruppe von Ergebnissen angeben.

So geben Sie eine eindeutige Proplist für ein einzelnes Element an:

1. Fügen Sie in der RSS-Ausgabe ein benutzerdefiniertes Element hinzu, das die anzupassende Liste von Eigenschaften darstellt. Im folgenden Beispiel wird beispielsweise die Liste für den Detailbereich festgelegt:

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

2. Wenn Sie eine Eigenschaft auf jedes Element in den Suchergebnissen anwenden möchten, ohne die RSS-Ausgabe zu ändern, geben Sie eine Proplist innerhalb eines ms-ose:PropertyDefaultValues-Elements in der OSDX-Datei an, wie im folgenden Beispiel gezeigt:

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

Layout des Ansichtmodus von Inhaltseigenschaften

Die Liste der eigenschaften, die in der System.PropList.ContentViewModeForSearch und System.PropList.ContentViewModeForBrowse proplists angegeben sind, bestimmt, was im Inhaltsansichtsmodus angezeigt wird. Weitere Informationen zu Eigenschaftenlisten finden Sie unter PropList.

Die Eigenschaften werden gemäß den Zahlen des folgenden Layoutmusters angeordnet:

Wenn wir die folgende Liste von Eigenschaften verwenden,

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

Dann wird die folgende Anzeige angezeigt:

Eigenschaftenlistenkennzeichnungen

Nur eines der Flags, die in der Dokumentation zu Proplists definiert sind, gilt für die Anzeige von Elementen in Layouts für den Inhaltsansichtsmodus: "~". In den vorherigen Beispielen beschriftet die Windows Explorer-Ansicht einige der Eigenschaften, z. B. Tags: animals; zoo; lion. Dies ist das Standardverhalten, wenn Sie eine Eigenschaft in der Liste angeben. Beispielsweise ähnelt die Proplist "System.Author", die als "Authors: value" angezeigt wird. Wenn Sie die Eigenschaftenbeschriftung ausblenden möchten, platzieren Sie einen "~" vor dem Eigenschaftennamen. Wenn die Proplist beispielsweise hat "~System.Size", wird die Eigenschaft als nur ein Wert ohne Bezeichnung angezeigt.

Previews

Wenn der Benutzer ein Ergebniselement im Windows-Explorer auswählt und der Vorschaubereich geöffnet ist, wird der Inhalt des Elements in der Vorschau angezeigt.

Der inhalt, der in der Vorschau angezeigt werden soll, wird durch eine URL angegeben, die wie folgt bestimmt wird:

1. Wenn die Windows Shell-Eigenschaft "System.WebPreviewUrl " für das Element festgelegt ist, verwenden Sie diese URL.

   Hinweis

   Die Eigenschaft muss im RSS mithilfe des Windows Shell-Namespace bereitgestellt oder explizit in der OSDX-Datei zugeordnet werden.

    

2. Wenn nicht, verwenden Sie stattdessen die Link-URL.

Das folgende Flussdiagramm zeigt diese Logik.

Es ist möglich, eine andere URL für die Vorschau zu verwenden als für das Element selbst. Dies bedeutet, dass wenn Sie unterschiedliche URLs für die Link-URL und die Beilage oder media:content URL bereitstellen, der Windows Explorer die Link-URL für die Vorschau des Elements verwendet, jedoch die andere URL für die Erkennung des Dateityps, das Öffnen, Herunterladen usw.

Wie Windows Explorer bestimmt, welche URL verwendet werden soll:

1. Wenn Sie eine Zuordnung zu System.ItemFolderPathDisplay bereitstellen, verwendet Windows-Explorer diese URL.

2. Wenn Sie keine Zuordnung bereitstellen, ermittelt der Windows Explorer, ob sich die Verknüpfungs- und Anlage-URLs unterscheiden. Wenn ja, verwendet Windows Explorer die Link-URL.

3. Wenn die URLs identisch sind oder nur eine Link-URL vorhanden ist, analysiert Windows Explorer den Link, um den übergeordneten Container zu finden, indem der Dateiname aus der vollständigen URL entfernt wird.

   Hinweis

   Wenn Sie erkennen, dass die URL-Analyse zu inaktiven Links für Ihren Dienst führen würde, sollten Sie eine explizite Zuordnung für die Eigenschaft bereitstellen.

    

Menüelement "Dateispeicherort öffnen"

Wenn ein Benutzer ein Element mit der rechten Maustaste anklickt, wird der Befehl "Dateispeicherort öffnen" angezeigt. Dieser Befehl bringt den Benutzer zum Container oder Speicherort des Elements. Wenn Sie beispielsweise in einer SharePoint-Suche diese Option für eine Datei in einer Dokumentbibliothek auswählen, wird der Stamm der Dokumentbibliothek im Webbrowser geöffnet.

Wenn ein Benutzer auf " Dateispeicherort öffnen" klickt, versucht Der Windows-Explorer, einen übergeordneten Container mithilfe der logik im folgenden Flussdiagramm zu finden:

Weitere Ressourcen

Weitere Informationen zum Implementieren des Suchverbunds in Remotedatenspeicher mit OpenSearch-Technologien in Windows 7 und höher finden Sie unter "Zusätzliche Ressourcen" bei der Sammelsuche in Windows.

Zugehörige Themen

Sammelsuche in Windows

Erste Schritte mit der Sammelsuche in Windows

Verbinden des Webdiensts in der Windows-Sammelsuche

Aktivieren Ihres Datenspeichers in der Windows-Föderierten Suche

Folgen bewährter Methoden in der Windows-Sammelsuche

Bereitstellen von Suchconnectors in der Windows-Sammelsuche