SharePoint - vyhledáváme efektivně

  • Article

Stále něco hledáte? Nemůžete to najít? A přitom víte, že to tam včera přece někde bylo? Bylo by asi vhodné upřesnit, že se bavíme o dokumentech, ale z nadpisu je doufám patrné, že článek nebude pravděpodobně o ztrátách a nálezech, ale o vyhledávání na platformě SharePoint.

Je vidět, že hledání informací patří ke každodenním rutinám většiny z nás, bez hledání si pravděpodobně nelze pracovní den ani představit. S narůstajícím počtem dokumentů (a nejen dokumentů) roste přirozeně také potřeba jejich vyhledání. Snadno. A rychle. A přesně. Nebo řekněme relevantně. Tento článek je zaměřen na vyhledávací technologii na platformě SharePoint 2013, její možnosti, schopnosti, silné stránky atd. SharePoint Search je velice silnou technologií a není v možnostech tohoto článku zachytit vše.

Na úvod ještě upozornění, ne všechny termíny mají adekvátní český překlad a proto článek používá česko- anglickou terminologii. Článek také popisuje obecně technologii Search na platformě SharePoint On Premise, některé nastavení případně obrázky nemusejí odpovídat realitě v prostředí SharePoint Online.

Technologie SharePoint Search je součástí SharePoint farmy, nasazení Search technologie vyžaduje alespoň verzi SharePoint 2013 Foundation. Přesněji, do farmy SharePoint se přidá servisní aplikace „Search Service Application“.

search1
Obrázek 1 Blokové schéma Search

Všímavý čtenář zachytil, a možná je příjemně překvapen, že technologie Search je dostupná již na platformě SharePoint 2013 Foundation. Má sice svá omezení z hlediska možností přizpůsobení, ale jde o totožnou technologii jako je na vyšší edici SharePoint Server 2013. Určité rozdíly jsou u verze SharePoint 2013 Server také i mezi CALy (Standard vs. Enterprise). Přesný výpis rozdílů lze najít na stránce „Service description“ jednotlivých služeb. Odkaz popisuje vlastnosti On Premise řešení: https://technet.microsoft.com/en-us/library/jj819267.aspx\#bkmk\_FeaturesOnPremise.

Příjemně překvapený čtenář bude nyní možná zklamán, neboť budoucnost SharePoint Foundation je momentálně nejistá a není zatím zřejmé, zda verze SharePoint 2016 Foundation vlastně bude či ne.

Search centrum

Máme-li servisní aplikaci Search připravenou, můžeme vytvořit „Search centrum“. „Search centrum“ je web vytvořený podle šablony, která je na první pohled velmi jednoduchá – viz obrázek. „Search centrum“ je jakousi vstupní branou do světa vyhledávání. Jsme-li v prostředí SharePoint Online, Search centrum je vytvořené automaticky na adrese https://<TENANT>.sharepoint.com/search. V On Premise prostředí si adresu volíte sami.

Search centrum doporučuji zkusit editovat a podívat se, jak vlastně nastavení vyhledávání funguje. Ideální je spustit vyhledání nějakého řetězce a stránku s výsledky vyhledávání přepněte do režimu editace. Na stránce naleznete celou řadu web partů, které lze konfigurovat, nejzajímavější je asi konfigurace web partu „Search results“.

search2
Obrázek 2 Domovská stránka „Search Centra“ On Premise

Indexování

Abychom nějaký obsah vůbec vyhledali, musí proběhnout indexování, anglicky „Crawl“.

Indexování je proces, který získává z dokumentů a jejich metadat data neboli obsah. V této fázi server prochází obsah na Vašem SharePointu (a nejen na SharePointu, indexovat lze i externí obsah) a ukládá do indexu. Prochází se (indexuje) vše, kde správce indexování naplánoval. V Online prostředí se indexuje vše automaticky. Čím více indexovatelného obsahu na SharePointu existuje, tím déle se obsah indexu připravuje.

Indexování je jen první část, následuje tzv. „Content Processing“, který s daty provádí různé transformace. Tento popis velmi zjednodušeně odpovídá architektuře, to znamená, že různé komponenty SharePoint Search lze provozovat na různých serverech. (index, content processing, query, admin, crawl, analytics). Na první pohled je tedy jasné, že jde opravdu o robustní technologii, kterou lze dynamicky škálovat podle aktuálních potřeb. Hlavním kritériem pro stanovení kapacitního plánování je počet položek v indexu. Je-li Vaše řešení SharePoint Online, toto vše za Vás řeší provozovatel služby. Jste-li v On Premise prostředí, Search je klíčové správně dimenzovat, přičemž je potřeba mít na paměti, že při průběhu indexování je server relativně dost zatěžován a pokud máte server špatně dimenzován, nebo se v jeden okamžik sejde indexování obsahu a ještě i uživatelské požadavky, server může reagovat pomaleji. SharePoint Server 2013 podporuje tzv. „Continuous crawl“, zátěž proto může být ještě vyšší.

Dedicated Search Front End

Zátěž generovanou během indexování lze oddělit tak, že vyčleníme Front End server pouze pro indexování obsahu. Front End vyčleněný pouze pro indexování je server, na který díky správné konfiguraci nejsou směrovány uživatelské požadavky, ale pouze požadavky serveru provádějící indexování. Indexování tím nemůže ovlivnit uživatele, protože uživatelé interakují s jiným Front End serverem. Zátěž generovanou ostatními komponentami lze rozdělit přidáním dalšího serveru s rolí, kterou chcete oddělit. Dimenzování „Search“ je samozřejmě složitější, jednotlivé komponenty „Search“ mají svá omezení a doporučení a dimenzují se odděleně.

Dedicated Search Farma

Další možností je popřípadě vytvoření tzv. „Dedicated Search Farm“. „Dedicated Search Farm“ je SharePoint farma poskytující servisní aplikaci Search. „Dedicated Search Farm“ je jiná/další SharePoint farma, která poskytuje (nejen) servisní aplikaci „Search Service Application“ a ze které Vaše SharePoint farma poskytující obsah využívá servisní aplikaci „Search“.

Máte-li problém při indexování, řešením může být dedikovaný Front End pro Search, máte-li problém s procesováním, řešením může být „Dedicated Search Farm“. Na obrázku níže je kombinace dedikovaného Front End serveru pro indexování a dedikované servery, kde běží služby Content Processingu.

search3
Obrázek 3 Dedicated Search Front End + server s oddělenými rolemi

Search schema

Nastavení „Search schema“ je klíčové pro správné fungování vyhledávání, resp. pro vyhledání relevantních výsledků. K základním pojmům „Search schema“ patří „Managed properties“ a „Crawled properties“.

Crawled properties

Při indexování SharePoint obsahu se indexují sloupce (metadata) a vznikají tzv. „Crawled properties“, které mohou obsahovat metadata jako je např. „Autor“, „Název“, atp. Obsah „Crawled properties“ nijak ovlivnit nelze, toto si řídí SharePoint sám dle obsahu, který na SharePointu existuje. Jinými slovy, jakmile přidáte sloupec do knihovny, při následném indexování vzniká „Crawled property“.

Managed properties

Aby byl obsah metadat vyhledatelný nastavuje se tzv. „Managed property“. „Managed property“ obsahuje vazbu na jednu či více „Crawled properties“ a definuje vlastnosti vyhledávání, např. jak se mají výsledky mapovaných metadat („Crawled properties“) zobrazit, atp.

Existuje také i možnost nastavit „Crawled property“ tak, aby se obsah sloupce v indexu objevil i bez mapování na „Managed property“, ale tento způsob není doporučován, protože se pak v indexu mohou objevovat nepotřebná data a tím se snižuje výkon. Toto nastavení se provádí přímo na „Crawled property“.

V praxi budete „Managed property“ určitě vytvářet, protože bez nich nelze využít některé další „vychytávky“. Jaké jsou tedy možnosti? Hlavní charakteristika „Managed property“ obsahuje tyto možnosti a nejlépe lze pochopit na konkrétním příkladu.

Příklad: Seznam obsahuje sloupec „Barva“ a obsahem je např. text „Zelená“.

Searchable
  • Je-li nastaveno na TRUE, lze obsah tohoto sloupce vyhledávat, obsah sloupce je uložen v indexu.
  • Vyhledání řetězce „Zelená“ prohledá všechny položky (samozřejmě nejen ve sloupci „Barva“), ve kterých se hledaný řetězec vyskytuje (včetně obsahu tohoto sloupce).

Queryable
  • Je-li nastaveno na TRUE, obsah lze vyhledávat jen pomocí specifického určení názvu „Managed property“. Název „Managed property“ musí být ve tvaru „Managed Property:Obsah“,
  • Např. „Barva:Zelená“.
  • Změna na „True” vyžaduje „Full crawl”.

Retrievable
  • Je-li nastaveno na TRUE, je obsah „Managed property“ zobrazen přímo ve výsledcích vyhledávání

Refinable
  • Tři možnosti nastavení: „No“, „Yes-Active“, „Yes-Latent“
  • Je-li nastaveno na „No“, není aktivní.
  • Je-li nastaveno na „Yes-Active“ – umožňuje využít „Managed property“ jako tzv. „Refiner“ na výsledcích vyhledávání. Refiner je nutné ve web partu manuálně konfigurovat.
  • Je-li nastaveno „Yes-Latent“ – Používá se jako mezistupeň před nastavením stavu „Active“, aniž by bylo nutné později provádět „Full crawl“.
  • Změna nastavení na „Yes“ vyžaduje „Full crawl”.

Sortable
  • Tři možnosti nastavení: „No“, „Yes-Active“, „Yes-Latent“
  • Je-li nastaveno na „No“, není aktivní.
  • Je-li nastaveno na „Yes-Active“ – Umožňuje řazení na základě obsahu „Managed property“
  • Je-li nastaveno „Yes-Latent“ – Pro pozdější změnu stavu bez nutnosti „Full Crawl“
  • Změna na „Yes” nastavení vyžaduje „Full crawl”.

Alias
  • Možnost vytvořit si pro „Managed property“ více aliasů

Výše uvedený seznam nastavení „Managed property“ není kompletní, zmíněné jsou řekněme nejzajímavější nastavení.

Za speciální zmínku stojí „Refiners“, což je grafická komponenta, umožňující zpřesnění výsledků. Ve výchozím stavu lze při vyhledávání používat „Refiners“, např. pro zmenšení časového rozpětí „Modified date“. Podle typu výsledků vyhledávání se zobrazí např. jako „Refiner“ také velikost souboru, atp. Ovládací prvky pro „Refiners“ jsou v levém menu po vyhledání výsledků, viz obr.

search4
Obrázek 4 „Refiners” v praxi, viz levé navigační menu

V prostředí SharePoint Online nelze „Managed properties“ vytvářet. Abyste mohli Search schema modifikovat, v SharePoint Online prostředí můžete využít předvytvořené prázdné nemapované, „Managed properties“ různých datových typů, ke kterým se nastavuje vazba na „Crawled properties“. Pokud chcete využívat „Refiners“, „Managed property“ musí být nastavena jako „Refinable“ a „Queryable“.

Search verticals

Výchozí stav SharePoint Search obsahuje 4 základní vertikály:

  • Everything
  • People
  • Conversations
  • Videos

Vertikály vyhledávání omezují vyhledávaný obsah. Funguje tak, že odkaz vertikály vede na samostatnou stránku s web party, které mají před konfigurované „Query“ (dotazy). Pro konkrétní vertikály tedy můžete definovat například vlastní „Refiners”. Obrázek níže ukazuje náhled výsledků na Videosoubory, v levém navigačním menu je „Refiner“ na dobu trvání videosouboru. Pokud by SharePoint Search vrátil více výsledků, nabízelo by se více možností pro zpřesnění výsledků, v SharePointu v tomto případě jsou uložené soubory pouze do 5 minut délky.

search5
Obrázek 5: Refiners v akci společně s vertikálou

iFilter

SharePoint umí indexovat nejen názvy dokumentů, případně metadata k nim, ale také obsah dokumentů/souborů. Aby SharePoint Search uměl obsahu souborů porozumět, musí být instalován tzv. iFilter, což je softwarové rozšíření. V Online prostředí žádné iFiltry instalovat nelze. Ve výchozím stavu SharePoint podporuje celou řadu typů dokumentů, od verze 2013 je indexován také PDF soubor. Kompletní seznam indexovaných soborů je k dispozici zde: https://technet.microsoft.com/en-us/library/jj219530.aspx.

Nativní podporu indexování obsahu souborů lze v On Premise rozšířit instalováním dalších iFiltrů, ve většině případů ale vystačí výchozí sada. Další iFiltry lze samozřejmě instalovat a tím rozšířit možnosti indexování proprietárních typů soborů (např. DWG, atp.).

Lingvistické vychytávky

V tabulce níže lze dohledat možnosti platné pro český jazyk, včetně některých omezení. Není například možné využít „Fuzzy name matching“, „Company name extraction“ nebo „Spelling variants“, viz https://technet.microsoft.com/en-us/library/jj219499.aspx.

image

K ostatním vlastnostem je k nalezení popis pouze k funkci „Stemming“, vysvětlení je uvedeno příkladem.

  • Stemming – Ze slov „diet“, „diets”, „dieting”, „dieted”, „dietary”, „dietician”, „dieticians”, atd. se vytvoří slovo „diet”.

Result Sources

„Result Sources“ se používají pro omezení typu výsledků, v podstatě jde o definici dotazu, např. podle Content Type ID. „Result Sources“ také například určují, jaký protokol bude použit (SharePoint, Remote SharePoint, OpenSearch, Exchange) a jaký typ výsledku je požadován (SharePoint/People).

  • „Result Sources“ jsou náhradou „Content Sources“
  • Ve výchozím stavu SharePoint obsahuje cca 16 „Result Sources“
  • Například „Result Source“ s názvem „Document“ obsahuje tuto query:

{?path:{Scope}} {?owstaxIdMetadataAllTagsInfo:{Tag}} (FileExtension:doc OR FileExtension:docx OR FileExtension:xls OR FileExtension:xlsx OR FileExtension:ppt OR FileExtension:pptx OR FileExtension:pdf) (IsDocument:"True" OR contentclass:"STS_ListItem")

Display templates

Display templates jsou šablony, které se používají v Search web partech a určují, jak budou výsledky vyhledávání zobrazeny, například které „Managed properties“ budou zobrazeny a jak. Tyto „Display Templates“ lze použít pouze v Search web partech, nikoliv v oblíbeném a známém CQWP (Content Query Web Part). „Display Templates“ jsou uložené pro každou site kolekci a nastavení naleznete v Site settings --> Master pages and page layouts --> Display Templates -->.

Při použití standartních „Content Types“ si možná vystačíte s výchozími „Display Templates“, pokud používáte vlastní „Content Types“, v praxi se setkáte s tím, že výsledky CSWP nebudou zobrazené příliš hezky a budete si muset napsat „Display Template“.

Content Search Web Part

Za zmínku stojí určitě web part s názvem „Content Search Web Part“, který lze do jisté míry považovat za nástupce CQWP – „Content Query Web Part“. V praxi se lze setkávat také se zkratkou CSWP – „Content Search Web Part“. Tento web part je dostupný až na úrovni Enterprise CAL.

Máte-li možnost CSWP využít, vřele doporučuji vyzkoušet, máte možnost Query vytvářet pomocí průvodce, který Vám pomůže sestavit dotaz správně. Významně pomůže i možnost náhledu výsledků přímo ve web partu. Popis možností CSWP by sám o sobě vydal na samostatný článek, proto doporučuji vyzkoušet. Dostupnost: Office 365 Enterprise E3 a E4, Office 365 Education A3 a A4, Office 365 government G3 a G4 a Office 365 Enterprise E3 for Nonprofits. CSWP nelze použít pro veřejnou internetovou prezentaci „Public Website“, ale možnost „Public Website“ již v nových prostředích stejně není a u stávajících bude ukončena cca kolem 03/2017 - https://support.microsoft.com/en-us/kb/3027254.

search6
Obrázek 6 CSWP – konfigurace Content Search web part

Hybrid

SharePoint Search je sice skvělá technologie, ale co když máte jak SharePoint On Premise, tak SharePoint Online? Co když nechcete hledat informace na dvou místech, nejdříve v On Premise a pak ještě v Online prostředí? Odpovědí je hybridní konfigurace, která umožní federovat výsledky z obou prostředí tak, že uživatel pracuje pouze s jedním vyhledávacím centrem. Konfigurace vyžaduje speciální nastavení infrastruktury a je nad rámec tohoto článku (AADSync, popřípadě ADFS). Výsledkem pro uživatele je interakce s jedním prostředím, které vrací výsledky z obou prostředí. Vztah vyhledávání mezi farmami může být jednosměrný (oběma směry) nebo obousměrný. Konfigurací směru určujeme, jaký zdroj dat SharePoint použije pro zobrazení výsledků. Konfiguračně tak lze např. v Online prostředí prohledávat pouze Online obsah, a v On Premise prostředí prohledávat obsah federovaný z obou prostředí.

search7
Obrázek 7 Two-way Hybrid Search topologie

search8
Obrázek 8 Příklad zobrazení výsledků agregovaných z On Premise a Online prostředí

KQL, FQL

SharePoint pro vyhledávání používá strukturovaný dotazovací jazyk KQL - „Keyword Query Language“. Programátoři mohou využít také FQL – „Fast Query Language“. Výchozí dotazovací jazyk je použit KQL, FQL lze využít pouze ve vlastním programovém řešení.

Obecně se vyhledávací řetězec může skládat z jednoho či více klíčových slov oddělených mezerou, „Property restriction“ (omezení pomocí metadat) a operátorů (viz níže). „Property restriction“ ani operátor nemusíte používat, platí však, že čím lepší dotaz zadáte, tím kvalitnější výsledky obdržíte.

Operátory

Výčet možných operátorů:

  • : = <> > >= < <= ..
  • ALL, AND, ANY, NEAR, NONE, NOT, ONEAR, OR, WORDS, XRAN
  • Vhodnou kombinací dotazovaného slova, „Property restriction“ a operátoru lze omezit výsledky
  • Příklad: Hledám řetězec Author: „Urban“
  • „Urban“ je řetězec pro vyhledání
  • „Author“ je Property Restriction
  • Znak dvojtečky je operátor

Ač může seznam operátorů vypadat složitě, stačí začít používat ty nejdůležitější, popřípadě lze využít „Rozšířené vyhledávání“. „Rozšířené vyhledávání“ lze využít po vyhledání výsledků na stránce úplně dole. Na formuláři lze vybrat, jaké vlastnosti mají mít jaké parametry a následně je vytvořena Query a zobrazeny výsledky. Použitá Query je následně vidět a lze tak na reálných příkladech z Vašeho prostředí pochopit použití „Property restriction“ a operátorů.

Příklady KQL

Protože základní znalost KQL může zefektivnit vyhledávání, uvedeme si pár konkrétních příkladů využití:

  • Author:urban
    o Stejné jako Author:URBan
  • docID:HZ54DWRJUCXM-29-3
    o Vyhledávání podle Document ID, na hledání pomocí Document ID existuje také samostatný web part.
  • spsiteurl:finance KPCS
    o Cílí dotaz na web s URL „finance“ a hledá řetězec „KPCS“
  • spsiteurl:"my*" AND urban
    o Cílí dotaz na web s URL „MY*“ (* je zástupný znak) a hledá veškerý obsah, kde se vyskytuje řetězec „urban“.
  • filetype:docx
    o Omezení na koncovku souboru
  • (Size>10000 AND Description:popis)
    o Nalezne dokumenty větší než 10kB, které mají „Managed Property“ Description s obsahem řetězce „Popis“. Nezapomeňte, že v „Managed Property“ může být několik „Crawled properties“.
  • („auto " OR "kolo") AND (title:"výlet" OR title:"cesta")
    o Vyhledá obsah, kde jsou splněné dvě podmínky - kolo nebo auto + výlet nebo cesta.

Na výsledcích vyhledávání lze také vytvářet alerty, tzn., že výsledky vyhovující konfigurovanému dotazu jsou odeslány denně nebo týdně na email uživatele. Upozornit se můžete nechat např. jen na nové položky vyhovující dotazu. S použitím Display templates tak lze vytvářet např. firemní Newslettery.

Best practice

Na závěr pár tipů, jak docílit nejlepších výsledků. Seznam obsahuje jak obecná pravidla, tak konkrétní tipy.

  • Čím lépe je dokument popsán metadaty, tím snáze lze najít
  • Používejte smysluplné názvy souborů/dokumentů
  • Používejte operátory, nejčastěji OR
  • AND je použit automaticky, jsou-li slova oddělená mezerou
  • Operátor musí být velkými písmeny
  • Více instancí stejné vlastnosti používá automaticky OR – author:“Urban“ author:„Novák“ je stejné jako author:“Urban“ OR author:„Novák“
  • Naopak použití jiných vlastností používá AND
  • Používejte uvozovky pro vyhledání přesného řetězce, KPCS CZ a „KPCS CZ“ jsou odlišné tvary
  • Znáte-li metadata, zaměřte se na hledání pomocí metadat - například: Zákazník:„KPCS CZ“
  • Používejte „Rozšířené vyhledávání“
  • Využívejte „Refiners“

Jakub Urban, KPCS CZ