Utilizzo di regole di query, tipi di risultati e modelli di visualizzazione per un report di ricerca delle vendite personalizzato in SharePoint 2013
Articolo originale pubblicato martedì 24 luglio 2012
(Dichiarazione standard: la formattazione del blog non è il massimo della chiarezza. Fate un favore ai vostri occhi: scaricate l'allegato ovvero la versione in formato documento di Word di questo testo.)
È vero, il titolo di questo argomento è piuttosto lungo, ma in effetti tratteremo parecchio materiale. SharePoint 2013 include numerose caratteristiche interessanti che vi consentiranno di utilizzare e personalizzare effettivamente i risultati della ricerca come non è mai stato possibile. Non ho intenzione di fornire una panoramica completa di tutte le caratteristiche, né dettagli significativi dei componenti che useremo in questo post perché sono già ampiamente trattati in altre risorse. Presenterò tuttavia un set iniziale di risultati della ricerca, fornendo una breve panoramica di ognuna di queste caratteristiche, quindi illustrerò il loro processo di utilizzo per creare un risultato della ricerca personalizzato e molto interessante che dimostra l'interazione di tutti questi elementi.
Iniziamo innanzitutto con una visualizzazione dell'aspetto dei risultati della ricerca quando eseguo una query per la ricerca di “report delle vendite” (sales reports) nella mia farm (NOTA: questa è una versione Beta 2 e l'aspetto della versione finale potrebbe essere diverso):
Questa è la configurazione predefinita per i risultati della ricerca, il cui aspetto è sicuramente ben organizzato. Abbiamo tuttavia aggiunto queste caratteristiche per consentire la creazione di un'esperienza di ricerca più articolata in SharePoint 2013, pertanto aggiungeremo un po' del nostro scenario. La nostra azienda è costituita da diverse divisioni e alcune di esse si occupano della gestione delle vendite all'interno della divisione stessa. Ogni divisione utilizza un modello di Excel standard per indicare la propria attività di vendita nel tempo. In ogni divisione è inoltre presente una persona responsabile della gestione delle relazioni con i clienti e della segnalazione delle informazioni sulle vendite. Come possiamo quindi utilizzare le caratteristiche di SharePoint per standardizzare e rilevare importanti informazioni sulla divisione e i suoi clienti? Per risolvere questo quesito, adotteremo un approccio ramificato.
Tipo di contenuto personalizzato
Per iniziare, creeremo un tipo di contenuto personalizzato per ogni utente che carica report delle vendite in SharePoint. Inizierò dalla creazione delle colonne del sito che utilizzerò: questi sono i campi che voglio poter analizzare nei miei report di ricerca delle vendite. Per il nostro scenario ho definito le colonne del sito seguenti:
Nome colonna del sito |
Tipo |
Account Manager |
Riga di testo singola |
Subalterni (Direct Reports) |
Numero |
Area di vendita (Sales Region) |
Scelta: Nord America, EMEA, Asia |
Account principali (Top Accounts) |
Riga di testo singola |
Account totali (Total Accounts) |
Numero |
Ho quindi creato un tipo di contenuto che include tutte queste colonne nel sito hub di pubblicazione associato al mio servizio per i metadati gestiti, in modo che venga distribuito a tutti i siti di sottoscrizione nella farm, ovvero nel mio caso tutti i siti in tutte le applicazioni Web.
Il passaggio successivo, che nel mio caso è manuale, è stato di aggiungere questo tipo di contenuto all'elenco dei tipi di contenuto disponibili per la raccolta siti di ogni divisione, nella raccolta documenti in cui vengono tra l'altro archiviati i report delle vendite. Naturalmente è possibile automatizzare questa operazione, ma per brevità l'ho fatto manualmente. Ecco, ho completato il primo passaggio: abbiamo un tipo di contenuto personalizzato e distribuito e, man mano che i report delle vendite vengono aggiunti a queste raccolte documenti, gli Account Manager possono semplicemente identificare un report delle vendite quando viene caricato e vengono compilati i metadati.
Proprietà gestite
Dopo aver popolato i nostri siti con questi report delle vendite, dobbiamo creare proprietà gestite dalle colonne del sito personalizzate presenti nei report. Per gli scopi di questo scenario, in SharePoint 2013 non sono in realtà presenti vere novità rispetto a SharePoint 2010: è necessario eseguire una ricerca per indicizzazione completa per creare proprietà sottoposte a ricerca per indicizzazione, quindi creare proprietà gestite che vengono mappate a quelle sottoposte a ricerca per indicizzazione ed eseguire un'altra ricerca per indicizzazione completa. Dico che non vi è nulla di diverso in questo scenario perché stiamo implementando una soluzione a livello di farm. In SharePoint 2013 è tuttavia disponibile una caratteristica straordinaria che consente agli amministratori della raccolta siti di contrassegnare la propria raccolta siti, o il sito o addirittura un elenco, per una ricerca per indicizzazione completa. In questo modo si evita di dover eseguire una ricerca per indicizzazione completa a livello di azienda quando si desidera effettuare questa operazione a un livello maggiormente mirato, la qual cosa è veramente interessante. Cercherò di trattare questa caratteristica in un altro post, volevo solo far notare che esiste, anche se non è applicabile in questo caso perché l'ambito della nostra soluzione è l'intera farm.
Regole di query
A questo punto abbiamo i report delle vendite che utilizzano un tipo di contenuto personalizzato e abbiamo proprietà gestite popolate con i valori dei metadati da tali report delle vendite. Desideriamo quindi assicurarci che questi elementi vengano rilevati quando un utente esegue una ricerca di qualcosa che dovrebbe includere uno di questi report delle vendite. In SharePoint 2013 è disponibile la caratteristica perfetta a questo scopo, ovvero le regole di query, che include tre componenti principali:
- Condizioni: le condizioni per una regola di query determinano l'attivazione di una regola. Le varianti che è possibile applicare alle regole sono molteplici. Questa è solo una breve analisi, ma le possibilità di utilizzo di queste regole sono ENORMI e infatti molte di queste sono incluse per impostazione predefinita. Un altro aspetto interessante è che se si desidera attivare una regola di query in OGNI risultato della ricerca, basta semplicemente non impostare alcuna condizione. Naturalmente è possibile procedere al contrario e impostare più condizioni. Probabilmente vi accorgerete presto quanto siano infinite le possibilità in questo ambito. Le condizioni che è possibile utilizzare per una regola di query includono:
- Una query che inizia e termina con una parola o una frase particolare.
- Una query contenente una parola di azione (parole definite dall'utente e solitamente corrispondenti a verbi, come "scaricare" e così via).
- Una query contenente una parola presente in un set di termini di metadati gestiti (in questo caso le possibilità sono veramente INTERESSANTI).
- Una query comune in un'altra origine dei risultati, ad esempio risultati di video, di documenti e così via. Può essere un'origine qualsiasi perché le origini dei risultati vengono create e definite dall'utente.
- I risultati contengono un tipo di risultato comunemente selezionato, come discussioni, fogli di calcolo di Excel e così via.
- Regole avanzate, dove è possibile utilizzare espressioni regolari, dividere la query in termini di azione e termini di argomento (ciò che rimane dopo i termini di azione viene rimosso) e così via.
- Azioni: sono le azioni che verranno eseguite quando le condizioni della regola di query vengono soddisfatte. Anche in questo caso sono disponibili tre diverse opzioni. È possibile:
- Aggiungere risultati alzati di livello: funziona in modo analogo a Elementi di maggiore rilevanza in SharePoint 2010 e a Elementi visivi di maggiore rilevanza con ricerca FAST per SharePoint 2010. È possibile aggiungere un nuovo collegamento che verrà visualizzato nella parte superiore di tutti i risultati della ricerca. Il collegamento può inoltre essere visualizzato come collegamento ipertestuale o come immagine, da qui l'analogia con un elemento visivo di maggiore rilevanza.
- Aggiungere un blocco di risultati: si tratta di un blocco in cui viene eseguita una query aggiuntiva e i risultati vengono restituiti e visualizzati insieme ai risultati della ricerca originali. Viene definito blocco perché i risultati sono presentati tutti insieme. È possibile visualizzare il blocco nella parte superiore di tutti i risultati della ricerca oppure frammisto ad altri risultati della ricerca in base a una classificazione. È importante sottolineare che ciò NON SIGNIFICA che viene effettuata una classificazione per pertinenza tra le due query, ma semplicemente che il blocco nel suo insieme sarà classificato con tutti gli altri risultati della ricerca locali. Quando si fa clic su un elemento nel blocco di risultati, l'azione viene registrata localmente e la pertinenza del blocco nel suo insieme aumenta. Di conseguenza, se gli elementi nel blocco ricevono molti clic, nel corso del tempo il blocco inizierà a spostarsi verso l'alto nei risultati perché avrà una pertinenza maggiore rispetto ai singoli risultati che non vengono selezionati altrettanto frequentemente. In realtà sono TANTISSIME le operazioni che è possibile eseguire per configurare il blocco di risultati, ma come ho detto, non ne fornirò una descrizione dettagliata in questo documento.
- Modificare i risultati classificati modificando la query: questa opzione consente di eseguire esattamente l'operazione descritta. La query richiesta può essere aperta e modificata nel modo desiderato. È possibile includere criteri aggiuntivi, rimuovere termini, utilizzare XRANK per modificare la classificazione e altro: le opzioni possibili sono molteplici.
- Pubblicazione: consente di controllare se e quando viene utilizzata una regola di query. È possibile creare, ad esempio, un set di regole che dovranno essere attivate il giorno successivo ai saldi di Natale. Non si desidera però che vengano utilizzate fino al giorno effettivamente specificato. In tal caso, è possibile creare la regola, ma configurarne le pubblicazione in modo che rimanga inattiva. In alternativa è possibile attivare la regola, ma configurarla in modo che non inizi fino a una data particolare e quindi termini in una data successiva.
Ecco, questo è il "breve" resoconto sulle regole di query, vediamo quindi come possiamo utilizzarle nel nostro scenario. A quanto pare esiste una regola di query predefinita che fa proprio al caso nostro. In effetti ho reso la regola inattiva quando ho acquisito la schermata precedente, in modo che possiate comprenderne meglio l'impatto. Nel nostro caso desideriamo creare query che gli utenti possano utilizzare per ottenere un report delle vendite e fare in modo che il report delle vendite della nostra divisione venga visualizzato e notato. Passare quindi alla raccolta dei siti di ricerca, scegliere l'opzione relativa alle impostazioni del sito e fare clic sul collegamento relativo alle regole di query. Nell'elenco a discesa Seleziona un'origine fare clic e selezionare la voce relativa a report locali e risultati dei dati. Verrà visualizzata una regola di query denominata Report e dati. Fare clic sulla regola e scegliere Visualizza dal menu a discesa per vedere come è strutturata la regola. Funziona così:
- Condizione: la condizione relativa alla regola prevede che la query contenga una delle parole seguenti all'inizio o alla fine della query: analisi;cubo;dashboard;dati;database;report;vendite. Come noterete, sono incluse sia la parola report che la parola vendite, pertanto se un utente esegue una query per la ricerca di “report delle vendite”, verrà eseguita questa query. Sembra perfetto: se un utente cerca “report delle vendite”, visualizzerà i report delle vendite della nostra divisione. Nell'ambito di questa regola la corrispondenza viene assegnata ai termini di azione e tutto il resto ai termini di argomento. In questo caso la parola “report” viene assegnata al termine di azione e la parola “vendite” al termine di argomento.
- Azione: l'azione relativa a questa regola prevede semplicemente l'esecuzione di un'altra query basata SOLO sui termini di argomento. Di conseguenza, in base alla condizione precedente verrà eseguita una query distinta solo per "vendite". Verrà aggiunto un blocco che sarà sempre restituito nella parte superiore di tutti gli altri risultati. TUTTAVIA verrà eseguita SOLO la ricerca delle vendite nell'origine relativa a report locali e risultati dei dati. Si tratta di un'origine dei risultati predefinita che in effetti restituisce solo documenti di Excel (file con estensione XLSX, XLS e così via). È dunque una query che esegue una query per la ricerca di “vendite” (sales) solo in documenti di Excel.
- Pubblicazione: la regola è attiva senza limitazioni relative alla data di inizio o di fine, pertanto viene sempre attivata.
Ho riabilitato la regola di query e questo è l'aspetto dei risultati dell'esecuzione di una query per la ricerca di report delle vendite.
Ecco, ora va meglio: la regola di query è stata attivata e ora nella parte superiore dei risultati vengono visualizzati i documenti basati sul tipo di contenuto personalizzato per i report delle vendite. Non sono tuttavia ancora visibili i metadati relativi ai documenti ed è su questo aspetto che concentreremo l'attenzione.
Modelli di visualizzazione
In SharePoint 2010 la visualizzazione di un particolare elemento in modo diverso comporta un processo piuttosto complicato che prevede la modifica di un GROSSO blocco di codice XSLT nella web part Risultati di ricerca. Per fare questo dovete mettere in campo le vostre straordinarie competenze XSLT e tentare di individuare il punto giusto in cui inserire il codice personalizzato in quell'enorme documento. Nel complesso, un'esperienza tutt'altro che piacevole.
In SharePoint 2013 abbiamo a disposizione i modelli di visualizzazione: un miglioramento davvero importante. Non è più necessario ricorrere a XSLT perché ora è possibile creare codice di visualizzazione personalizzato direttamente in HTML! Infatti, per questo documento ho utilizzato Adobe Dreamweaver CS6 per creare il “codice” per il mio modello di visualizzazione personalizzato. Vediamo dunque come funzionano i modelli di visualizzazione.
Con un modello di visualizzazione è necessario tenere traccia di alcuni elementi diversi:
- Proprietà gestite: è necessario specificare quali proprietà gestite si desidera recuperare al momento dell'esecuzione della query. Tali proprietà potranno quindi essere utilizzate nel codice HTML mediante un metodo che descriverò più avanti.
- JS e CSS esterno: se si dispone di file javascript o CSS che si desidera utilizzare nel modello di visualizzazione, è possibile renderli esterni e aggiungerli al modello.
- JS in linea: è possibile utilizzare JS in linea nel modello di visualizzazione, verificando semplicemente che sia inserito dopo il primo <div> all'interno del modello. Anche a questo proposito segue una descrizione più avanti.
- HTML: qui è possibile creare il codice HTML effettivo per il modello di visualizzazione che eseguirà il rendering dei risultati.
Per il nostro modello di visualizzazione rileveremo gli attributi dal tipo di contenuto personalizzato per i report delle vendite che abbiamo creato, in modo che venga visualizzato nei risultati della ricerca come segue:
Per iniziare è opportuno utilizzare sempre come base un modello di visualizzazione esistente per crearne uno nuovo. Passare quindi alla raccolta dei siti di ricerca, scegliere l'opzione relativa alle impostazioni del sito e fare clic sul collegamento relativo a pagine master e layout di pagina. Nella raccolta fare clic sulla cartella dei modelli di visualizzazione, quindi sulla cartella ricerche, che contiene tutti i modelli di visualizzazione predefiniti. Come noterete, numerosi file hanno lo stesso nome, ma un suffisso html o js. A noi interessano i file html, infatti quelli con estensione js vengono generati automaticamente quando si carica un file html. In questo caso, poiché il modello di visualizzazione riguarda i file di Excel, ho utilizzato il file Item_Excel.htm. Ho scaricato una copia localmente, l'ho rinominata in SalesReport.html, quindi ho aperto il file in Dreamweaver.
Aggiungo quindi le proprietà gestite richieste dal modello di visualizzazione in corrispondenza del tag mso:ManagedPropertyMapping presente nel file. Ho aggiunto le mie proprietà alla fine dell'elenco utilizzando lo stesso formato del resto delle proprietà gestite, come illustrato di seguito:
<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title', 'Author':'Author', 'Size':'Size', 'Path':'Path', 'Description':'Description', 'LastModifiedTime':'LastModifiedTime', 'CollapsingStatus':'CollapsingStatus', 'DocId':'DocId', 'HitHighlightedSummary':'HitHighlightedSummary', 'HitHighlightedProperties':'HitHighlightedProperties', 'FileExtension':'FileExtension', 'ViewsLifeTime':'ViewsLifeTime', 'ParentLink':'ParentLink', 'ViewsRecent':'ViewsRecent', 'FileType':'FileType', 'IsContainer':'IsContainer', 'ServerRedirectedURL':'ServerRedirectedURL', 'ServerRedirectedEmbedURL':'ServerRedirectedEmbedURL', 'ServerRedirectedPreviewURL':'ServerRedirectedPreviewURL', 'AccountManager':'AccountManager', 'SalesRegion':'SalesRegion', 'TotalAccounts':'TotalAccounts', 'TopAccounts':'TopAccounts', 'DirectReports':'DirectReports', 'ContentType':'ContentType'</mso:ManagedPropertyMapping>
Come potete vedere, ho aggiunto AccountManager, SalesRegion e così via, tutte le proprietà che ho creato per il tipo di contenuto personalizzato. Mi sono quindi spostato verso il basso dove è presente quanto segue:
<div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="ExcelItem" class="ms-srch-item" onmouseover="_#= ctx.CurrentItem.csr_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.CurrentItem.csr_HideHoverPanelCallback =#_">
_#=ctx.RenderBody(ctx)=#_
<div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div>
</div>
Ho quindi eliminato tutto il testo tra i tag DIV esterni (che ho evidenziato in rosso sopra). Ora posso scrivere il mio codice HTML. Vi sono però tre cose che è opportuno conoscere prima di iniziare:
- Riterrete probabilmente più facile mantenere il tag <style> nella sezione <head> del modello di visualizzazione. Per motivi che non starò a descrivere ora, questi tag verranno eliminati al momento del rendering del modello di visualizzazione, quindi dovrete copiare i vostri tag style e inserirli in un file CSS distinto. Comunque, mentre state effettivamente creando il vostro codice HTML, potete utilizzare e modificare i tag style per assicurarvi che riflettano l'aspetto che desiderate conferire al modello di visualizzazione.
- Come ho accennato, è possibile aggiungere quello che ho definito javascript in linea, il che significa che il codice javascript può essere aggiunto a condizione che si trovi nella posizione corretta. La posizione corretta per un modello di visualizzazione significa che deve essere inserito dopo il primo tag DIV nel modello di visualizzazione e, inoltre, che deve essere collocato tra un set di tag di apertura e chiusura simile al seguente: <!--#_ e _#-->. Descriverò più in dettaglio i tag personalizzati di seguito, ma ora è sufficiente precisare che se il codice javascript non è racchiuso tra questi tag, non verrà eseguito. Una cosa MOLTO interessante a questo proposito è che è possibile utilizzare variabili per definire il codice javascript in linea quando si crea l'HTML che sarà generato. Spiegherò meglio questo aspetto nel prossimo argomento.
- Per generare una proprietà gestita o una variabile dal codice javascript in linea creato, è necessario racchiuderla tra un set di tag di apertura e chiusura simile al seguente: _#= e =#_. Le proprietà gestite sono tutte disponibili in un oggetto denominato ctx.CurrentItem. Per generare ad esempio la proprietà gestita AccountManager, aggiungerò questo tag: _#= ctx.CurrentItem.AccountManager =#_. Nel caso di codice javascript come il seguente: var foo = “L'attuale Account Manager è “ (The current Account Manager is) + ctx.CurrentItem.AccountManager + “.”;, quindi per generare “foo” aggiungerò questo tag: _#= foo =#_. Si avrà così la flessibilità di aggiungere o elaborare i dati in modo funzionale al modello di visualizzazione personalizzato.
Ora che avete compreso il meccanismo per creare il codice HTML, ecco come ho creato il modello di visualizzazione illustrato sopra, aggiungendo questi attributi style nel tag head:
<style>
.ReportDiv
{
float:left;
}
.ReportText
{
font-family: Verdana, Geneva, sans-serif;
font-size: 12px;
}
.ReportHeading
{
font-weight: bold;
}
.LogoImg
{
margin-top: 15px;
width: 118px;
height: 101px;
}
.MasterDiv
{
float:left;
height: 215px;
width: 342px;
background-repeat: no-repeat;
background-image: url(https://sps/sites/search/PublishingImages/SalesReportBackground.PNG);
padding: 15px;
}
.DetailsContainer
{
background-color:#CCC;
}
</style>
L'elemento principale che vale la pena sottolineare è solo che avevo già caricato nel mio sito l'immagine che ho utilizzato per lo sfondo nei dettagli relativi all'account manager, tutto il resto dovrebbe essere abbastanza ovvio. Anche in questo caso, inserendo il tag style nella sezione <head> posso vedere esattamente come apparirà il layout mentre lo sto progettando in Dreamweaver.
Diamo ora uno sguardo all'HTML stesso che ho utilizzato per creare il modello di visualizzazione:
<div>
<div class="ReportDiv">
<img class="LogoImg" src="https://sps/sites/search/PublishingImages/SalesReportLogo.PNG" />
</div>
<div class="MasterDiv">
<!-- Title and link to item -->
<a href="_#= ctx.CurrentItem.Path =#_" class="ReportText">_#= ctx.CurrentItem.Title =#_</a>
<br/><br/>
<!-- Account Manager -->
<span class="ReportHeading ReportText">
Account Manager:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.AccountManager =#_
</span><br/>
<!-- Sales Region -->
<span class="ReportHeading ReportText">
Sales Region:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.SalesRegion =#_
</span><br/>
<!-- Total Accounts -->
<span class="ReportHeading ReportText">
Total Accounts:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.TotalAccounts =#_
</span><br/>
<!-- Top Accounts -->
<span class="ReportHeading ReportText">
Top Accounts:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.TopAccounts =#_
</span><br/>
<!-- Direct Reports -->
<span class="ReportHeading ReportText">
Direct Reports:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.DirectReports =#_
</span><br/>
<!-- Hit Highlighted Text -->
<br/>
<span class="ReportHeading ReportText">
Details:
</span>
<br/>
<span class="DetailsContainer ReportText">
_#= Srch.U.processHHXML(ctx.CurrentItem.HitHighlightedSummary) =#_
</span>
</div>
</div>
Eviterò di parlare delle caratteristiche di formattazione di questo contenuto e mi concentrerò sui dati. Potete vedere dove ho inserito le proprietà gestite utilizzando i tag _#= e =#_. Noterete che si tratta di una pura sostituzione di token, quindi posso utilizzarle direttamente nell'attributo <a> href sopra (anziché eseguire questa operazione con XSLT, che è molto più impegnativa). Il resto dei campi sono semplicemente associati al tag DIV o SPAN per la formattazione. L'unico caso "speciale" in questo codice riguarda HitHighlightedSummary, per cui viene utilizzato un componente di elaborazione predefinito incluso nella funzionalità di ricerca. Al momento non dispongo di un elenco completo di componenti e metodi e del loro funzionamento, ma l'ho aggiunto solo perché se non lo si utilizza, il riepilogo non verrà evidenziato. È quindi opportuno assicurarsi di utilizzare questo metodo a tale scopo.
Ora che tutto funziona, devo eseguire un'altra operazione con questo markup. Copio tutto ciò che è presente tra i tag <style> e li inserisco in un nuovo documento CSS denominato SalesReport.css. Nella mia raccolta di pagine master, nella cartella ricerca nei modelli di visualizzazione, ho creato un'altra cartella denominata styles e ho caricato il file SalesReport.css in file tale directory. Per utilizzarlo nel mio modello di visualizzazione, devo aggiungere un nuovo tag script, che dovrà essere inserito sotto il tag <body> e sopra il primo tag <div>. Per includere il file CSS nel modello di visualizzazione, utilizzo una funzione javascript di SharePoint denominata $includeCSS. Il markup di apertura sarà quindi simile al seguente:
<body>
<script>
$includeCSS(this.url, "./styles/SalesReport.css");
</script>
<div id="Item_SalesReport">
A questo punto il codice è completo, ma come è necessario procedere perché il modello di visualizzazione venga utilizzato?
Tipi di risultati
I tipi di risultati consentono di richiamare i modelli di visualizzazione in base a un set di regole. Le regole sono abbastanza semplici da utilizzare e possono essere attivate per uno specifico tipo di contenuto predefinito, come un messaggio di posta elettronica, un file PDF, un documento di Word, un wiki di SharePoint e così via. Oltre a ciò è possibile utilizzarle solo quando la query riguarda un'origine dei risultati specifica. Infine, è possibile utilizzare qualsiasi proprietà gestita come criteri per la regola, con qualsiasi confronto comune. Ad esempio, è possibile attivare una regola del tipo di risultato solo quando il campo AccountManager contiene “Vice President” se si desidera utilizzare un tipo di visualizzazione diverso per questo ruolo. Nel nostro caso, il tipo di risultato dovrà essere attivato solo quando il tipo di contenuto corrisponde a “>Rapporto delle vendite" (Sales Report). Aggiungeremo quindi una condizione per il tipo di risultato che specifica quando ContentType è uguale a “Sales Report”.
Come potete vedere, potremmo anche aggiungere più valori per la corrispondenza e più proprietà, unendole mediante AND. Per questo scenario non serve altro che ContentType. Dopo aver definito le condizioni, possiamo procedere alla configurazione dell'azione per la regola. Per un tipo di risultato l'azione è solo un elenco a discesa con tutti i modelli di visualizzazione disponibili. Tutto ciò che devo fare per creare il mio tipo di risultato è selezionare dall'elenco il mio modello di visualizzazione per i report delle vendite (Sales Report)e fare clic sul pulsante Salva. Anche in questo caso, se avete dubbi sulla creazione di tipi di risultati, date un'occhiata a tutti i tipi di risultati predefiniti disponibili in SharePoint. Osservando alcuni di quelli esistenti, potrete trarne molte idee interessanti per crearne di nuovi.
Per riepilogare
Ora abbiamo tutto ciò che serve: un tipo di contenuto personalizzato che recupera i metadati necessari, alcune proprietà gestite per estrarre il contenuto e inserirlo nell'indice, una regola di query che assicura la visualizzazione del contenuto dei report delle vendite all'inizio dell'elenco quando un utente esegue una query per la ricerca di “report delle vendite” (sales report), un modello di visualizzazione personalizzato che mostra i metadati recuperati in un formato utile e veramente unico, che non assomiglia lontanamente a un tipico risultato della ricerca, e un tipo di risultato che garantisce l'utilizzo del nostro modello di visualizzazione quando nei risultati della ricerca viene restituito il tipo di contenuto personalizzato. Al termine, il risultato finale sarà simile al seguente:
Qui si conclude l'introduzione ad alcune delle interessantissime caratteristiche di SharePoint 2013 per la presentazione dei risultati della ricerca. Mi auguro che possiate a percepire le potenzialità di queste caratteristiche e che troverete molti modi utili e interessanti per utilizzarle.
Questo è un post di blog localizzato. L'articolo originale è disponibile in Using Query Rules, Result Types and Display Templates for a Custom Search Sales Report in SharePoint 2013