Condividi tramite


Abilitazione dell'archivio dati in Ricerca federata di Windows

Viene illustrato come abilitare l'accesso all'archivio dati da parte di 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 che create sul vostro server web deve soddisfare i due requisiti seguenti.

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

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

    L'esempio seguente mostra 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 di richieste di POST 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

In Windows 7 non è prevista alcuna sintassi di query specifica. Il provider OpenSearch accetta qualsiasi termine immesso dall'utente nella casella di input in Esplora risorse e lo codifica nell'URL. A tale scopo, 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 si aspettano che termini separati vengano considerati implicitamente combinati tramite un'operazione AND. Ad esempio, una query per "Microsoft Windows" deve restituire solo i risultati che contengono sia "Windows" che "Microsoft".

Protocolli di autenticazione supportati

Ricerca federata di Windows supporta l'autenticazione basata su Windows e può fornire credenziali ai servizi Web tramite i protocolli seguenti:

  • NTLM.
  • Kerberos.
  • Basic (solo tramite https).
  • Altri provider di supporto per la sicurezza installati in Windows che offrono capacità di query aggiuntiva. Consultare la documentazione di SSP Interface SDK per rimanere aggiornati sull'eventuale aggiunta 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. Tuttavia, non si è limitati ai mapping predefiniti degli elementi RSS o Atom standard e può includere elementi XML personalizzati nello spazio dei nomi Windows per ognuna delle proprietà. Ad esempio, è possibile aggiungere elementi XML personalizzati all'interno dell'elemento elemento per fornire metadati aggiuntivi a Windows. È anche possibile mappare elementi da altri namespace XML, ad esempio iTunes

Esempio di output di 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 in Windows Federated Search" e "Mapping di proprietà personalizzate" in Creazione di un file di descrizione OpenSearch nella ricerca federata di Windows.

Mappatura automatica delle proprietà della shell di Windows

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

<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 esatti delle proprietà della shell di Windows e includere l'URI (Uniform Resource Identifier) esatto, come illustrato nell'esempio seguente:

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

Informazioni sulle proprietà di sistema della shell di Windows

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 di 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 sulla mappatura delle proprietà, vedere "Elementi estesi in Ricerca federata di Windows" in Creare un file di descrizione di OpenSearch in Ricerca federata di Windows.

Informazioni su come Windows esegue il mapping degli elementi ai tipi di file

La ricerca all'interno dell'interfaccia utente di Esplora Risorse consente agli utenti di considerare i risultati come file quando un elemento RSS punta a un file memorizzato 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 un collegamento e gli utenti possono eseguire azioni su di esso, ad esempio creando un collegamento o aprendolo nel browser.

Il diagramma di flusso seguente mostra 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 i passaggi seguenti 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 usata nel percorso (.ext in questo esempio).

Se l'elemento utilizza l'enclosure RSS standard o elemento media:content, il provider OpenSearch presuppone che l'elemento sia un file e identifichi l'estensione del nome file come indicato di seguito:

  • Se la proprietà System.FileExtension della Shell di Windows è stata mappata per l'elemento, il provider usa tale estensione di file.
  • Se la System.FileExtension proprietà della Shell di Windows non è stata mappata, il provider utilizza l'attributo Type specificato nell'enclosure o nell'elemento di contenuto. Questo elemento deve contenere una stringa MIMEType, ad esempio "image/jpeg". Se il MIMEType è associato a un'estensione di file registrata nel computer client, l'elemento viene considerato come un file di tale tipo. Se il MIMEType non è associato a un'estensione di file registrata nel computer client, l'elemento viene considerato come un tipo di collegamento Web. Il provider di OpenSearch non tenta di analizzare l'attributo URL per individuare l'estensione del nome file.
  • Se il MIMEType è associato a un'estensione di file registrata nel computer client, il provider determina se l'estensione del file è un tipo di file Web noto (.htm, .html, .asp, .aspx, .php, .swf, 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 il MIMEType "text/html" è associato all'estensione del nome di file .htm, tale elemento viene considerato come un collegamento Web anziché come tipo di file .htm.

Evitare potenziali barriere all'abilitazione di 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 Ricerca federata di Windows 7.

    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 OpenSearchcompatibile e chiama tali API in background.

    Alcuni esempi includono la Biblioteca 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.

Esistono tuttavia alternative che possono evitare barriere all'abilitazione di un archivio dati. Di seguito sono riportate alcune di queste alternative:

Per scrivere un servizio Web intermediario quando non è possibile modificare il servizio Web per l'origine dati esistente oppure il servizio Web fornisce un'API personalizzata:

  1. Scrivere un servizio web intermediario che possa accettare una query di Windows 7.
  2. Connettiti all'origine dei dati e recupera i risultati dell'interrogazione.
  3. Riformattare 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. A tale scopo, è possibile fornire 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 un OpenSearch descrizione 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 o indici aziendali proprietari:

  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 sul lato client se non funziona una soluzione solo sul lato server:

  1. Scrivere un'origine dati lato client OpenSearch che si trova tra il provider OpenSearch di Windows e l'origine dati esterna.
  2. Usare l'API interfaccia IOpenSearchSource di in Windows SDK per creare un file con estensione searchconnector-ms configurato in modo appropriato tramite cui 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, la tua implementazione può fornire un'interfaccia utente di autenticazione personalizzata e connettersi all'origine dati utilizzando la sua API proprietaria.

Nota

Aprire un file con estensione .osdx crea un file con estensione .searchconnector-ms (connettore di ricerca) nella directory %userprofile%/searches e inserisce un collegamento nella cartella %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 alla ricerca federata in Windows

Collegamento del Tuo Servizio Web in Windows Federated Search

Creazione di un file di descrizione OpenSearch in Windows Federated Search

Seguire le migliori pratiche nella Ricerca Federata di Windows

Distribuzione di Connettori di Ricerca in Windows Federated Search