Tematický týden: SharePoint technologie – díl 2.
Logická struktura portálu nade vše
Druhý díl TechNet miniseriálu věnovaného platformě Microsoft SharePoint si klade následující cíle: vyjasnit pojmy, tedy názvosloví, a především si říci, jak plánovat logickou strukturu SharePoint portálů, tedy hierarchii kolekcí webů a v nich umístěných webů a dalších podřízených webů.
V uplynulých 5 letech jsem měl tu možnost podílet se na řadě implementací SharePoint serverů jak v rámci malých, tak velkých firem a proto věřím, že níže uvedené praktické zkušenosti a pohledy na věc uvítáte.
Vyjasňujeme pojmy
Než se dostaneme k hlavnímu tématu tohoto článku, tedy k popisu plánování struktury SharePoint portálu, k tomu proč používat (či nepoužívat) kolekce webů, musíme si nejprve vyjasnit pojmy, jinak z toho bude jeden velký zmatek. Následující řádky ale nejsou jen pouhým slovníčkem pojmů, čtěte prosím pozorně, ať se v tom pak neztratíte. :)
SharePoint Web Application = Webová aplikace. Jedná se de-facto o „IIS Web Site“, rozšířenou o službu SharePoint, bežící v rámci IIS na daném portu, využívající nastavený „host header“, přidruženou do daného „fondu aplikací“ (IIS Application Pool) v rámci IIS.
Site Collection = Kolekce webů. Kolekce webů je sada webů v rámci webové aplikace, které mají stejného vlastníka a sdílejí nastavení správy. Každá kolekce webů obsahuje web nejvyšší úrovně a může obsahovat jeden nebo více podřízených webů. Jedná se tedy o celkovou strukturu webu nejvyšší úrovně a všech podřízených webů. V každé webové aplikaci může existovat mnoho kolekcí webů (max. 150 000 v rámci jedné webové aplikace, ale max. 50 000 v rámci jedné obsahové databáze).
Top Level Web Site = Web nejvyšší úrovně. Jedná se o výchozí web (na nejvyšší úrovni) provozovaný v rámci webové aplikace, např. na adrese https://intranet. Pamatujte však, že každá kolekce webů obsahuje právě jeden web nejvyšší úrovně a může také obsahovat jeden nebo několik podřízených webů. Weby nejvyšší úrovně tedy mohou obsahovat mnoho podřízených webů (max. 250 000 webů v rámci každé kolekce webů) a samotné podřízené weby mohou dále obsahovat další podřízené weby (doporučeno je omezovat počet podřízených webů pod jednotlivými weby na max. 2000). Počet vnořených úrovní závisí čistě na požadavcích vašich uživatelů, obecně bych ale řekl, že méně je více.
Site = Web. Web představuje skupinu souvisejících webových stránek, pomocí kterých mohou pracovní týmy pracovat na projektech, organizovat schůzky, sdílet informace, atd. atd. Typickou šablonou webu je tzv. týmový web, ten zahrnuje knihovnu dokumentů a základní seznamy typu kalendář, úkoly, oznámení, odkazy a týmová diskuse.
Někdy se říká, že jeden obrázek je lepší než tisíc slov. Souhlasím, takže tady je:
Managed Path = Spravovaná cesta. Spojovacím bodem pro kolekce webů jsou spravované cesty. Existují dva typy spravovaných cest: „explicit“ a „wildcard“, v češtině tzv. „explicitně zahrnuté“ a „zahrnuté pomocí zástupných znaků“.
O co jde? Např. kořenová „/“ spravovaná cesta je explicitně zahrnuta, což znamená, že ji může využít jen jedna kolekce webů a že zároveň vytváří její identitu. Takto např. přistupujete ke kořenové kolekci webů typu https://intranet. Vytvořit samozřejmě můžete řadu explicitně zahrnutých příkladů spravovaných cest (např. hr, sales...) a použít je pro kolekce webů. Získáte tak strukturu typu https://intranet/hr, https://intranet/sales atd. Zkusíte-li vytvořit další kolekce webů, pak s využitím těchto spravovaných cest již další kolekce webů nebude možné vytvořit.
Naopak spravované cesty, které jsou zahrnuté pomocí zástupných znaků, fungují zcela opačně. Umožňují totiž tvorbu kolekcí webů s využitím opakovatelně použitelných názvů spravovaných cest, které rozšiřují jejich identitu. Výše uvedený příklad s kolekcemi webů „hr“ a „sales“ by tedy s využitím spravované cesty „departments“, kterou vytvoříme jako spravovanou cestu typu „zahrnuté pomocí zástupných znaků“, vypadal takto: https://intranet/departments/hr a https://intranet/departments/sales.
No vida, to již vypadá lépe, že? Nebo ne? ANO, vypadá! A nejen to.
Zamyslete se nad následujícím faktem: co když pod kořenovým webem https://intranet vytvoříme obyčejný podřízený web „projekt1“? Adresa tohoto webu by byla https://intranet/projekt1. Fajn, žádný problém, ale jen na první pohled. Hned vedle totiž můžeme mít samostatnou kolekci webů projekt2, která je vytvořena v rámci explicitně zahrnutého typu spravované cesty projekt2 a má tedy adresu https://intranet/projekt2. Vedle sebe tedy máme obyčejný podřízený web https://intranet/projekt1 a samostatnou kolekci webů https://intranet/projekt2. No a je to tady, zmatek.
Plánování struktury portálu, tedy kolekcí webů, spravovaných cest a jednotlivých webů
Pamatujte, že v jednoduchosti je krása a síla. U SharePoint portálů tohle platí na 100%. SharePoint prostředí musí být logicky členěno, naplánováno a řízeno! Díky naprosté otevřenosti návrhu je velmi snadno možné při používání SharePoint portálů po chvíli dojít do stavu značného zmatku, nejednotnosti, ztrátě vize a struktury. Mít na SharePointu stejný či ještě větší zmatek, než teď možná panuje na vašich souborových serverech, to asi nikdo z vás nechce. Dojít k tomuto stavu bez řízení SharePoint prostředí je ale velmi snadné, až příliš snadné.
Pravidlo první tedy zní: SharePoint prostředí musí mít řízenou (někým spravovanou a někým schvalovanou) strukturu. Tohle je na vás, s tím vám nikdo nepomůže, je to o vašich procesech.
Pravidlo druhé, se kterým vám pomoci mohu, zní: strukturu portálu, jednotlivých kolekcí webů, spravovaných cest a samotných týmových webů plánujte dopředu, s jasnou vizí a rozvahou. Ano, téměř vše se dá napravit, ale znáte to – napravovat něco je mnohdy obtížnější, než to celé udělat znovu.
Právě při plánování struktury portálu začíná ta pravá „sranda“. Existuje řada pohledů na věc. Každá firma je unikátní a je tedy třeba zvolit individuální přístup a pohled na věc. Přesto však společné rysy najdeme vždy a obecné zásady jsou shrnuty do následujících, věřím že užitečných, řádků textu.
Je vaše firma členěna do divizí, týmů, navíc možná s geograficky oddělenými pobočkami? Pravděpodobně ano, snad v každé firmě najdeme klasická oddělení, mezi něž patří např. finance, personalistika, marketing, obchod, výroba, IT, vedení, apod. (záměrně používám podstatná jména, ne přídavná jména („obchod“ a ne „obchodní“), souvisí to s vhodností pojmenovávání spravovaných cest).
Máte centrálu a pobočky? Možná ano a pravděpodobně i na pobočkách jsou pracovníci členěni do oddělení či týmů, pravděpodobně podléhají centrálnímu vedení, sdílí řadu informací (ale mnohé informace chtějí mít jen lokální).
Nebo jste řízeni projektově? Nebo máte mix obojího? V pořádku, to je normální.
A teď se tedy zamyslete nad ideální strukturou vašeho SharePoint portálu. Pamatujte – jednoduchost, přehlednost. Zaměstnanci vaší firmy (všetně vás) chápou strukturu firmy právě podle jednotlivých oddělení, ať již logických (finance, personalistika, marketing, obchod, výroba, IT, vedení...), nebo projektových (projekt1, projekt2), na kterých spolupracují různí lidé z různých oddělení. No a jsme u jádra věci – takto strukturujte i své SharePoint portály.
Michochodem ideální je, je-li zároveň takto (či podobně) strukturována i hierarchie objektů (typicky OU a SG) v rámci služby Active Directory.
Klíčová otázka v rámci SharePoint portálů ovšem zní - používat kolekce webů spolu se spravovanými cestami, nebo jen strukturu webu nejvyšší úrovně a podřízených webů? Odpověď není triviální.
Chceme mít tedy web nejvyšší úrovně a pod ním jen podřízené weby s jednoduchými názvy? Proč ne.
https://intranet/obchod, https://intranet/it, to je jistě přehledné a v pohodě.
V našich podmínkách, tedy u SharePoint serverů či farem obsahujících řádově gigabajty či max. několik málo desítek gigabajtů dat, si na používání kolekcí webů řada firem „nehraje“. Možná že ale jen neví, proč by měly, možná že jen neznají výhody (ale i nevýhody) kolekcí webů.
Jak to tedy s kolekcemi webů opravu je?
Z pohledu administrátora může každá kolekce webů mimo jiné mít:
- Vlastní vlastníky (správce) umožňující delegovat správu:
Vždy při vytváření kolekce webů lze nastavit dva správce dané kolekce webů. Po jejím vytvoření lze však v nastavení správy určit i další správce kolekce webů. Správcem kolekce webů bohužel nemůže být doménová skupina zabezpečení, ale jen jednotlivé uživatelské účty, což je tak „trochu“ škoda. - Vlastní databázi obsahu (Content DB):
Neřešíte-li otázku licencí SQL Serveru, tak i tohle může být jeden z argumentů, proč využívat kolekce webů. Obsahové DB rozdělené mezi více SQL Serverů se někdy hodí. No ale tohle je spíš na celý samostatný článek, tak chcete-li ho, řekněte si. - Vlastní šablonu/y kvót velikosti:
Proč využívat kvóty asi netřeba příliš rozvádět. Zvolit můžete dvě strategie pro tvorbu a používání SharePoint kvót pro kolekce webů. První – každé kolekci webů přidělíte individuální kvótu velikosti. Druhá – vytvoříte šablony kvót (např. „malá“ s odesláním emailového upozornění, když velikost úložiště dosáhne hranice 900 MB a s limitem 1024 MB, „střední“ s limitem 5 GB a upozorněním na hranici 5000 MB a velkou s limitem 10 GB) a tyto šablony následně přiřazujete jednotlivým kolekcím webů. Kombinovat se samozřejmě dá obojí. - Vlastní nastavení jazyka kolekce webů:
Pro SharePoint technologie se zdarma z Microsoft webu dají stahovat jazykové balíčky. Po jejich instalaci získáte možnost vytvářet kolekce webů v různých jazycích. Kořenový web tedy může být např. anglický a kolekce webů v jazycích jiných (https://intranet.company.com je v EN, https://intranet.company.com/czech/web je v CZ, https://intranet.company.com/slovakia/web je v SK atd.) - Vlastní zámky webů:
Umožňují danou kolekci webů nastavit na režim „jen pro čtení“, nebo lze zakázat přidávání obsahu, nebo můžete pomocí zámků kolekcí webů zcela zakázat přístup k dané kolekci webů, aniž byste něco dělali s oprávněním přístupu. Užitečné v řadě případů. - Vlastní SharePoint skupiny zabezpečení, s přiřazenými úrovněmi oprávnění, jejichž členem jsou doménové skupiny zabezpečení či jednotliví uživatelé.
- Vlastní koše kolekcí webů:
Správce kolekce webů může zobrazit a spravovat odstraněné položky v kolekci webů ze stránky Koš kolekce webů. Na této stránce lze zobrazit položky, které se aktuálně nacházejí v koši uživatelů, a položky, které uživatel ze svého koše odstranil nebo které z jeho koše byly po standardně nastavených 30 dnech odstraněny automaticky. Koš kolekcí webů je tedy koš druhé úrovně, jeho velikost je možné omezovat pomocí nastavitelného procentuelního přírůstku nad stanovenou kvótou dané kolekce webů (má-li kolekce webů stanovenou kvótu velikosti 100 MB a koš druhé úrovně 50%, tak koš této kolekce webů může alokovat max. 50 MB).
Z pohledu uživatelů pak kolekce webů přináší tyto výhody:
- Vlastní navigační panely:
Horní panel odkazů a navigace s popisem cesty. - Vlastní typy obsahu:
Opět téma na samostatný článek, hned ten příští. :) Omezení definice metadat, tzv. sloupců webu a samotných typů obsahu na danou kolekci webů může být někdy výhodou, někdy nevýhodou. - Vlastní obory hledání, klíčová slova a doporučené výsledky:
Umožňují na úrovni kolekcí webů pomocí pravidel definovat vlastní zdroje oblastí s nastavenými parametry pro omezení výsledků hledání a klíčová slova se synonymi a nejvhodnějšími dokumenty. - Sady funkcí
Jsou-li pro vás výše uvedené výhody zajímavé, pak používejte kolekce webů, a to, jak jsme si již objasnili, kolekce webů vytvářené s využitím „wildcard“ spravovaných cest. A při plánování jak samotných spravovaných cest, tak názvů kolekcí webů, pamatujte opět na základní věc – jednoduchost. S pomocí spravovaných cest dokážete vytvořit velmi dobře čitelnou strukturu portálu, kterou si uživatelé snadno zapamatují a které porozumí a samotný název kolekce webů (tvořící její adresu) by to pak neměl pokazit.
Zde jsou klasické příklady z praxe:
Web Application s Top Level Web Site a případnými Sub Sites. Určena primárně pro sdílení informací obecné povahy, které mají být dostupné napříč celou firmou, či lidmi k dané Web Application přistupujícími (textové položky v seznamech, dokumenty, ale i Forms a Excel Services, KPI, publikační weby, Centrum záznamů apod.)
https://intranet.firma.cz/obchod
Top Level Web Site / Sub Site nebo Site Collection? To i to, takto to nepoznáte. :-)
https://intranet.firma.cz/oddeleni/obchod
Top Level Web Site / Managed Path / Site Collection
Efektivně využitá spravovaná cesta „oddeleni“ vytváří jednoduše čitelnou strukturu portálu. S využitím spravovaných cest můžete hezky seskupit kolekce webů do jednotné navigační struktury.
Kolekce webů pro firemní oddělení vytvořené v rámci spravované cesty „oddeleni“:
https://intranet.firma.cz/oddeleni/obchod
https://intranet.firma.cz/oddeleni/personalistika
https://intranet.firma.cz/oddeleni/marketing
https://intranet.firma.cz/oddeleni/it
https://intranet.firma.cz/oddeleni/vedeni
Kolekce webů pro projekty vytvořené v rámci spravované cesty „projekty“:
https://intranet.firma.cz/projekty/efshttps://intranet.firma.cz/projekty/iso
https://intranet.firma.cz/weby/praha/obchod
Top Level Web Site / Managed Path / Site Collection / Sub Site
https://emeaportal.company.com/sites/czech/salesdepartment
Top Level Web Site / Managed Path / Site Collection / Sub Site
https://emeaportal.company.com/sites/czech/salesdepartment/prague
Top Level Web Site / Managed Path / Site Collection / Sub Site / Sub Site
https://emeaportal.company.com/sites/czech/prague/salesdepartment
Top Level Web Site / Managed Path / Site Collection / Sub Site / Sub Site
Tolik k povídání o plánování struktury SharePoint portálů. Zaujalo-li vás toto téma, neváhejte se na mne, ideálně prostřednictvím mého blogu nebo TechNet blogu, obrátit s dotazy. Příště, tedy zítra, si budeme povídat o základním principu řízené tvorby informací v rámci SharePoint portálů, tedy o typech obsahu. Těším se opět na vás.
- Kamil Juřík
IT konzultant, vedoucí lektor, Gopas a.s., Microsoft MVP, MCT, MCITP, MCTS
Kamil Juřík, kromě vedení lektorského sboru v Počítačové škole Gopas, vede odborná školení, semináře a konzultace na téma Microsoft SharePoint a Office System. Je nadšeným propagátorem těchto technologií, konzultantem s jasnou vizí a zdravým přístupem k věci. Jako pravděpodobně jediný lektor v Evropě se rovněž profesionálně a s neutuchajícím zájmem noří do tajů licencování a Software Asset Managementu. Tato témata rovněž přednáší na partnerských konferencích a seminářích společnosti Microsoft, je spoluautorem licenčního webu společnosti Microsoft a řady oficiálních licenčních webcastů a dokumentů.