Condividi tramite


Abilitazione dell'archivio dati in Ricerca federata di Windows

Illustra come abilitare l'accesso all'archivio dati da un servizio Web OpenSearch e come evitare potenziali barriere per farlo.

Questo argomento è organizzato come segue:

Condizioni per l'accettazione della richiesta di ricerca

Il servizio Web OpenSearch creato nel server Web deve soddisfare i due requisiti seguenti:

  • Essere in grado di accettare una GET URL query dal client.

  • Consentire l'incorporamento dei termini di ricerca nell'URL.

    Nell'esempio seguente viene illustrato come un termine di ricerca può essere incorporato in un URL.

    https://example.com/search.aspx?query=terms&param=mysearchword
    

Nota

La ricerca federata non supporta l'invio POST di richieste a un servizio Web.

 

Per altre informazioni sulla creazione di un URL, vedere "Parametri modello URL" in Creazione di un file di descrizione OpenSearch in Ricerca federata di Windows.

Sintassi di query supportata

Non esiste una sintassi di query specifica prevista in Windows 7. Il provider OpenSearch accetta i termini che l'utente immette nella casella di input in Esplora risorse e lo codifica nell'URL. Lo fa in base al modello DI URL descritto in "Parametri modello URL" in Creazione di un file di descrizione OpenSearch in Ricerca federata di Windows.

Gli utenti prevedono che i termini separati vengano considerati in modo implicito ANDed insieme. Ad esempio, una query per "Microsoft Windows" deve restituire solo i risultati che contengono sia "Windows" che "Microsoft".

Protocolli di autenticazione supportati

Windows Federated Search supporta l'autenticazione basata su Windows e può fornire le credenziali ai servizi Web tramite i protocolli seguenti:

  • NTLM.
  • Autenticazione Kerberos.
  • Basic (solo su https).
  • Altri provider di supporto della sicurezza (SSP) installati in Windows che offrono una capacità di query aggiuntiva. Vedere la documentazione di SSP Interface SDK per mantenere l'aggiunta potenziale di altri SSP.

Invio di query e restituzione dei risultati della ricerca in RSS o Atom

Il provider OpenSearch è responsabile del mapping dei valori degli elementi XML alle proprietà di sistema di Windows Shell che possono essere usate dalle applicazioni Windows. Ma non si è limitati ai mapping predefiniti degli elementi RSS o Atom standard e può includere elementi XML personalizzati nello spazio dei nomi di Windows per ognuna delle proprietà. Ad esempio, è possibile aggiungere elementi XML personalizzati all'interno dell'elemento per fornire metadati aggiuntivi a Windows. È anche possibile eseguire il mapping di elementi da altri spazi dei nomi XML, ad esempio iTunes

Esempio di output del feed RSS

L'output del feed RSS di esempio seguente restituisce un elemento.

<rss version="2.0" xmlns:media="https://search.yahoo.com/mrss/" xmlns:example="https://example.com/namespace">
   <channel>
      <title>Search Results</title>
      <item>
         <title>An example result</title>
         <link>https://example.com/pictures.aspx?id=01</link>
         <description>This is a test of the emergency search results system. If this were a real emergency result, you'd be reading something more useful.</description>
         <pubDate>Wed, 1 Oct 2008 23:12:00 GMT</pubDate>
         <media:content url="https://example.com/pictures/picture01.jpg" fileSize="212889" type="image/jpeg" height="768" width="1024"/>
         <media:thumbnail url="https://example.com/thumbnails/picture01.jpg" height="120" width="160"/>
         <example:dateTaken>Mon, 22 Sep 2008 23:12:00 GMT</example:dateTaken>
      </item>
   </channel>
</rss>

Per informazioni più dettagliate sul mapping delle proprietà, vedere le sezioni "Elementi estesi nella ricerca federata WIndows" e "Mapping delle proprietà personalizzate" in Creazione di un file di descrizione OpenSearch in Ricerca federata di Windows.

Mapping automatico alle proprietà di Windows Shell

All'interno degli elementi nel feed RSS, è possibile scegliere di includere altri elementi XML che mappano automaticamente alle proprietà del sistema di Windows Shell. A tale scopo, includere un elemento denominato dopo la proprietà Windows Shell e prefisso con lo spazio dei nomi di sistema di Windows Shell. Nell'esempio seguente viene illustrata la dichiarazione win=" http://schemas.microsoft.com/windows/2008/propertynamespace" dello spazio dei nomi e l'inclusione di un elemento per il mapping win:System.Contact.PrimaryEmailAddressdelle proprietà :

<rss version="2.0" xmlns:example="https://example.com/schema/2009" xmlns:win="http://schemas.microsoft.com/windows/2008/propertynamespace">
...
   <item>
      <title>Someone</title>
      <win:System.Contact.PrimaryEmailAddress>someone@example.com
   </win:System.Contact.PrimaryEmailAddress>
   </item>

Il prefisso dello spazio dei nomi usato qui ("win") è un suggerimento. È possibile usare qualsiasi prefisso. Tuttavia, è necessario usare i nomi delle proprietà di Windows Shell e devono includere l'URI (Uniform Resource Identifier) esatto, come illustrato nell'esempio seguente:

http://schemas.microsoft.com/windows/2008/propertynamespace

Informazioni sulle proprietà del sistema di Windows Shell

Windows definisce un elenco completo di Proprietà di sistema e il formato del tipo di valore necessario per ogni proprietà. La documentazione per la proprietà System.FileExtension Window Shell, ad esempio, specifica che il valore deve contenere il punto iniziale (".docx" e non "docx").

Valori di data e ora

Il formato di data e ora preferito è ISO-8601, come illustrato nell'esempio seguente:

2008-01-16T 19:20:30:.45+01:00

Gli sviluppatori .NET devono usare la classe DateTime con ToString("R") per restituire il formato corretto.

Per informazioni più dettagliate sul mapping delle proprietà, vedere "Elementi estesi nella ricerca federata di Windows" in Creazione di un file di descrizione OpenSearch in Ricerca federata di Windows.

Informazioni su come Mappe Windows elementi ai tipi di file

La ricerca nell'interfaccia utente di Esplora risorse di Windows consente agli utenti di considerare i risultati come file quando un elemento RSS punta a un file archiviato in remoto. L'utente può trascinare e rilasciare elementi sul desktop e l'interfaccia utente di Esplora risorse visualizza l'icona corretta e fornisce il menu di scelta rapida appropriato. Se l'elemento RSS non punta a un file archiviato in remoto, il file viene considerato come collegamento e gli utenti possono eseguire azioni su di esso, ad esempio la creazione di un collegamento o l'apertura nel browser.

Il diagramma di flusso seguente illustra come Windows determina il tipo di file di un elemento.

diagramma di flusso che mostra i percorsi da un elemento alle decisioni per considerarlo come elemento del tipo di collegamento Web o come tipo di file

Il provider OpenSearch esegue la procedura seguente per eseguire il mapping di un elemento a un tipo di file:

  • Identificare se l'elemento deve essere considerato come un file o un collegamento Web.
  • Identificare l'estensione del nome file corretta da usare.

Ad esempio, se l'elemento ha un URL di collegamento che usa un percorso del file system (ad esempio file:///\\server\share\etc\item.ext), il provider OpenSearch considera il collegamento come file e determina il tipo dall'estensione del nome file utilizzata nel percorso (.ext in questo esempio).

Se l'elemento usa l'enclosure RSS standard o l'elemento multimediale MediaRSS:content , il provider OpenSearch presuppone che l'elemento sia un file e identifica l'estensione del nome file come indicato di seguito:

  • Se la proprietà System.FileExtension di Windows Shell è stata mappata per l'elemento, il provider usa l'estensione del nome file.
  • Se la proprietà System.FileExtension di Windows Shell non è stata mappata, il provider usa l'attributo Type specificato nell'enclosure o nell'elemento contenuto. Questo elemento deve contenere una MIMEType stringa, ad esempio "image/jpeg". Se l'oggetto è associato a un'estensione di nome file registrata nel computer client, l'elemento MIMEType viene considerato come un file di tale tipo. Se l'oggetto non è associato a un'estensione di nome file registrata nel computer client, l'elemento MIMEType viene considerato come tipo di collegamento Web. Il provider OpenSearch non tenta di analizzare l'attributo URL per individuare l'estensione del nome file.
  • Se l'oggetto MIMEType è associato a un'estensione di file registrata nel computer client, il provider determina se l'estensione del nome file è un tipo di file Web noto (.htm, .html, .asp, .aspx, .php, .json, .json, .stm). In tal caso, il tipo di file viene considerato come un tipo di collegamento Web; in caso contrario, viene considerato come un tipo di file. Ad esempio, se l'oggetto è associato all'estensione MIMEType "text/html" del nome file .htm, tale elemento viene considerato come collegamento Web anziché come tipo di file .htm.

Evitare potenziali barriere per abilitare un archivio dati

Alcuni archivi dati non forniscono un servizio Web compatibile con OpenSearch, ma possono comunque essere connessi a Ricerca federata di Windows. Tali archivi dati includono:

  • Indici remoti con metodi di autenticazione non supportati in Windows 7 Federated Search.

    Gli esempi includono l'autenticazione basata su moduli e altri metodi di autenticazione personalizzati.

  • Se un archivio pubblico ad alto valore ha API Web pubbliche, chiunque può scrivere un altro servizio Web compatibile con OpenSearch e chiama tali API in background.

    Gli esempi includono la Libreria del Congresso e i database di ricerca medica.

  • Archivi dati aziendali proprietari o indici e archivi di gestione dei contenuti legacy, per i quali potrebbe essere impossibile implementare un front-end.

Tuttavia, esistono alternative che possono evitare barriere per abilitare un archivio dati. Di seguito sono riportate alcune di queste alternative:

Per scrivere un servizio Web middle-man quando non è possibile modificare il servizio Web per l'origine dati esistente o il servizio Web fornisce un'API personalizzata:

  1. Scrivere un servizio Web middle-man che può accettare una query di Windows 7.
  2. Connettersi all'origine dati e recuperare i risultati della query.
  3. Formattare i risultati in formato RSS o Atom.
  4. Restituisce i risultati al client Windows 7.
  5. Si noti che per i servizi dati aziendali e molti servizi dati Internet, potrebbe essere necessario passare le credenziali utente per conto del servizio Web per eseguire il taglio dei risultati in base alle autorizzazioni dell'utente.

Per usare un motore di ricerca esistente quando non è possibile abilitare un archivio dati pubblico:

  1. Usare un motore di ricerca pubblico che supporta già OpenSearch con RSS. È possibile farlo fornendo agli utenti un file con estensione osdx con un modello DI URL che limita i risultati solo a quelli per il dominio specifico.

  2. Vedere l'esempio seguente di una descrizione openSearch per cercare solo il contenuto della Guida per Windows usando una query su live.com.

    <?xml version="1.0" encoding="UTF-8"?>
    <OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
      <ShortName>Windows Help</ShortName>
      <Description>Search Windows Help using the live.com search engine</Description>
      <Language></Language>
      <Url type="text/html" template="https://windowshelp.microsoft.com/windows/search.aspx?=&amp;qu={searchTerms}"/>
      <Url type="application/rss+xml" template="https://api.search.live.com/rss.aspx?source=web&amp;query={searchTerms} site:windowshelp.microsoft.com&amp;web.count=50"/>
    </OpenSearchDescription>
    

Per usare un server di indicizzazione esistente che supporta OpenSearch quando non è possibile abilitare archivi dati aziendali proprietari o indici:

  1. Selezionare un server di indicizzazione esistente che supporta OpenSearch per indicizzare il contenuto, ad esempio sharePoint Search Server.
  2. Creare un file con estensione osdx che limita i risultati dall'indice di SharePoint solo a quelli del server usando la sintassi KeyWord all'interno del modello URL.

Per scrivere un archivio dati lato client se una soluzione solo lato server non funziona:

  1. Scrivere un'origine dati OpenSearch sul lato client che si trova tra il provider Windows OpenSearch e l'origine dati esterna.
  2. Usare l'API interfaccia IOpenSearchSource in Windows SDK per creare un file con estensione searchconnector-ms configurato in modo appropriato tramite il quale Esplora risorse può chiamare l'implementazione con i parametri di query. L'implementazione può quindi restituire i risultati formattati in formato RSS o Atom. In questo modo l'implementazione consente all'implementazione di fornire l'interfaccia utente di autenticazione personalizzata e di connettersi all'origine dati usando l'API proprietaria.

Nota

L'apertura di un file con estensione osdx crea un file con estensione searchconnector-ms (connettore di ricerca) nella directory %userprofile%/search e inserisce un collegamento nella directory %userprofile%/links.

 

Risorse aggiuntive

Per altre informazioni sull'implementazione della federazione di ricerca in archivi dati remoti tramite tecnologie OpenSearch in Windows 7 e versioni successive, vedere "Risorse aggiuntive" in Ricerca federata in Windows.

Ricerca federata in Windows

Introduzione con Ricerca federata in Windows

Connessione del servizio Web in Ricerca federata di Windows

Creazione di un file di descrizione OpenSearch in Ricerca federata di Windows

Procedure consigliate seguenti in Ricerca federata di Windows

Distribuzione di connettori di ricerca in Ricerca federata di Windows