Blog

Logická struktura portálu nade vše

Logická struktura portálu nade vše, že. Téma, které řešíme my všichni. Téma téměř vždy podceňované, opomíjené. „Ono se to nějak udělá, my teď nevíme přesně jak chceme strukturu členit.“, slýchávám až příliš často. „Až se „rozkoukáme“, tak se nad tím zamyslíme.“ Hmm, ano, chápu, pak už ale bývá mnohdy pozdě. Začínáte-li s SharePointem, pak čtěte pozorně, ať se vyhnete typickým chybám. Máte-li již SharePoint, čtěte ještě pozorněji a nebojte se následně učinit rozhodnutí, že je třeba řadu věcí předělat. Vězte, že zdaleka nebudete jediní, drtivá většina portálů, které jsem měl možnost revidovat či shlédnout, a byly jich desítky, má v oblasti logického členění své struktury značné rezervy.

Vyjasňujeme si 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 = SharePoint webová aplikace. Z pohledu IIS (Internet Information Services) se jedná o „IIS Web Site“, rozšířený o službu SharePoint, běžící v rámci IIS na daném portu, využívající případný nastavený „host header“, přidružený do daného „fondu aplikací“ (IIS Application Pool) v rámci IIS. Z pohledu SharePointu je webová aplikace úvodním logickým objektem struktury obsahu. Webová aplikace většinou definuje scénář užití kolekcí webů, které hostuje („Intranet“, provozovaný např. na adrese http://intranet.contoso.com, bude mít v sobě kolekce pro interní práci a data, „Extranet“ (https://extranet.contoso.com) či „Zákaznický portál“ (https://customers.contoso.com) pak data, která chceme sdílet navenek např. pro obchodní partnery či dodavatele, zákazníky. Webové aplikace mohou mít různé režimy ověřování uživatelů (windows integrated, forms-based, custom…), a jak bylo již řečeno, mají vazbu na IIS.
Site Collection = Kolekce webů. Kolekce webů je sada webů sdružených do jednoho logického celku. Každá kolekce webů obsahuje jeden web nejvyšší úrovně (Top Level Site) a může obsahovat jeden nebo více podřízených webů (Sub Site). V každé webové aplikaci může existovat mnoho kolekcí webů (u SP 2013 farmy je podporovaný limit 250 000 kolekcí (mimo MySites kolekcí), ale max. 10 000 kolekcí v rámci jedné obsahové databáze).
Top Level Site Collection = tzv. kolekce nejvyšší úrovně. Jedná se o kolekci webů, která musí být přítomna v každé webové aplikaci. Je založena v explicitně zahrnuté spravované cestě /. (Poznamenejme, že definice kolekce nejvyšší úrovně je drobně matoucí. Z technického pohledu jsou všechny kolekce rovnocenné, neexistuje nic jako nadřízená kolekce a podřízené kolekce, jedna je zkrátka jen založena v / (kořenové) spravované cestě, další kolekce jsou, s využitím spravovaných cest, opticky založeny pod ní.)
Top Level Site = Web nejvyšší úrovně. Jedná se o výchozí web (na nejvyšší úrovni) provozovaný v rámci jednotlivých webových kolekcí, tedy v kolekci nejvyšší úrovně i všech dalších, např. na adrese http://intranet.contoso.com/ nebo http://intranet.contoso.com/projekty/. Každá kolekce webů obsahuje jeden web nejvyšší úrovně a může také obsahovat jeden nebo několik podřízených webů (např. http://intranet.contoso.com/projekty/projekt1, …projekt2 atd.). 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 může obsahovat další základní seznamy typu kalendář, úkoly, oznámení, odkazy a týmová diskuse. Nebo, chcete-li to říci jinak – web je kontejner wiki stránek (pomineme-li weby s aktivními Publishing Features), obsahuje seznamy a knihovny, ty obsahují data.
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 inclusion“ a „wildcard inclusion“, 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ž zjednodušeně řečeno znamená, že se jedná o oddělující znak či řetězec využitelný při zakládání kolekce jen jednou. Založte novou kolekci s využitím explicitně zahrnuté cesty a poté zkuste založit další kolekci se stejnou spravovanou cestou. Nepůjde to.
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 opakovaně použitelných názvů spravovaných cest.
Podívejme se na praktický příklad: chceme založit webové kolekce pro oddělení naší firmy (pro zjednodušení HR, Management, Sales), a kolekce pro výrobky, které vyrábíme (Product1, Product2…).
Webová aplikace má adresu http://intranet.contoso.com. V adrese http://intranet.contoso.com/ existuje samozřejmě kolekce nejvyšší úrovně se svým webem nejvyšší úrovně (domovskou stránku tohoto webu uživatel vidí, když to prohlížeče zadá URL http://intranet.contoso.com).
Pro kolekce jednotlivých oddělení a produktů chceme použít následující adresy:
http://intranet.contoso.com/departments/hr
http://intranet.contoso.com/departments/management
http://intranet.contoso.com/departments/sales
a
http://intranet.contoso.com/products/product1
http://intranet.contoso.com/products/product2
Takto definovovaná podoba URL adres je dobře čitelná, používáme oddělující řetězce „departments“ a „products“, které uvozují co za nimi bude následovat. Přirozeně tak víme, že se jedná o kolekci týmu či výrobku a nestavíme „na jednu úroveň“ kolekce týmů a výrobků, což je stav, kterého bychom docílili při použití cest http://intranet.contoso.com/hr, http://intranet.contoso.com/product1.
Klíčová otázka zní: jaký typ spravované cesty pro naše kolekce máme použít? Explicit inclusion nebo wildcard? Popravdě z technického pohledu je to naprosto jedno. Jde jen o to co je pro nás pohodlnější. Co tím myslím?
Varianta 1: využití explicitně zahrnutých spravovaných cest
Spravovaná cesta typu „explicit inclusion“ by se neměla jmenovat „explicitně zahrnutá“, ale spíše „explicitně založená“, nebo „předem vytvořená“. Chceme-li ji při zakládání kolekce využít, musíme si ji nejprve celou připravit. Do seznamu spravovaných cest tedy nejprve založíme nové cesty (departments/hr, departments/management, departments/sales) a pak kolekce založíme. Ano, jak vidíte, spravovaná cesta v sobě může obsahovat znak lomítko.

Create-SC-ExplicitMP.png

Varianta 2: využití „wildcard“ spravovaných cest
I spravovanou cesta typu „wildcard inclusion“ si musíme předem připravit, do seznamu spravovaných cest ale zadáváme, s trochou zjednodušení řečeno, jen to, co následuje do posledního lomítka v této cestě. V našem případě bychom tedy do seznamu spravovaných cest zadali jen slova departments a products, oddělující řetězce. Následně, při zakládání nové kolekce, bychom tyto wildcard cesty mohli opakovaně použít při zakládání kolekcí, neboť, jak vidíte na následujícím obrázku, při jejich použití následně zadáváme samotnou koncovou cestu kolekce, tedy např. hr, management, product1 apod.

Create-SC-WildcardMP.png

Plánování struktury portálu, tedy kolekcí webů, spravovaných cest a jednotlivých webů

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.
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 a jejich zrcadlení v SharePoint prostředí.
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.
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, i to je běžné a v SharePoint prostředí snadno realizovatelné.
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 většinou právě podle jednotlivých oddělení, ať již logických (finance, personalistika, marketing, obchod, výroba, IT, vedení…), nebo dle projektů (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.

Jak to tedy s kolekcemi webů opravu je? Jaké jsou jejich klíčové výhody a vlastnosti?

Z pohledu administrátora může každá kolekce webů mimo jiné mít:
  • Vlastní vlastníky (správce):
    U každé webové kolekce lze nastavit jednoho „vlastníka kolekce webů“ a neomezený počet správců. Při zakládání kolekce určujete tzv. „primárního správce“, což je vlastník kolekce a „sekundárního správce“. Po vytvoření kolekce lze v jejím nastavení definovat i další správce (doménové uživatelské účty či skupiny).
  • Vlastní databázi obsahu (Content DB):
    Dle našeho názoru jeden z klíčových argumentů pro použití kolekcí. Pamatujte – velikost obsahových databází by neměla přesáhnout několik stovek GB (doporučený limit je 200 GB). V ideálním případě vytvořte pro každou kolekci její vlastní obsahovou databázi a to i v případě, kdy předpokládáte, že v dané kolekci bude třeba jen pár GB dat.
  • Vlastní šablonu/y kvót velikosti:
    Proč využívat kvóty asi netřeba příliš rozvádět. Omezujete tak objem dat, který je do dané kolekce možné uložit. 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í 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.
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:
    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. Máte-li SharePoint Server, pak se vás toto omezení nicméně netýká. S využitím „content type hubu“ můžete typy obsahů publikovat napříč webovými kolekcemi, webovými aplikacemi a dokonce i SharePoint farmami.
  • 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í, čímž myslíme aktivované funkce na úrovni kolekcí webů, např. SharePoint Standard a Enterprise features.
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“ či „explicit inclusion“ 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

http://intranet.firma.cz/
Webová aplikace se svou kolekcí nejvyšší úrovně (/) a v ní webem nejvyšší úrovně. Kořeová kolekce je určena primárně pro sdílení informací obecné povahy, které mají být dostupné napříč celou firmou, či lidmi k dané webové aplikaci přistupujícími.

http://intranet.firma.cz/oddeleni/obchod
Top Level Site Collection / 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.

Další příklady kolekcí webů pro firemní oddělení vytvořené v rámci „wildcard“ spravované cesty „oddeleni“:

http://intranet.firma.cz/oddeleni/personalistika
http://intranet.firma.cz/oddeleni/marketing
http://intranet.firma.cz/oddeleni/it
http://intranet.firma.cz/oddeleni/vedeni

Kolekce webů pro projekty vytvořené v rámci „wildcard“ spravované cesty „projekty“:

http://intranet.firma.cz/projekty/efs
http://intranet.firma.cz/projekty/iso

http://intranet.firma.cz/weby/praha/obchod
Top Level Site Collection / Managed Path / Site Collection

http://emeaportal.company.com/sites/czech/salesdepartment
Top Level Site Collection / Managed Path / Site Collection

http://emeaportal.company.com/sites/czech/salesdepartment/prague
Top Level Site Collection / Managed Path / Site Collection / Sub Site

http://emeaportal.company.com/sites/czech/prague/salesdepartment
Top Level Site Collection / Managed Path / Site Collection

Výše uvedené příklady využívají wildcard spravované cesty. Tohotéž efektu, tedy stejných URL adres, lze samozřejmě dosáhnout i s využitím „explicit inclusion“ spravovaných cest. Pro SharePoint samotný je jedno, jaký typ cesty použijete, jde především o to, co pro vás při jejich zakládání bude snazší. Pamatujte však na jedno – spravovanou cestu nelze změnit! Jakmile tedy jednou založíte kolekci webů v rámci zvolené spravované cesty, nemůžete URL adresu následně jednoduše upravit.
Tolik k povídání o plánování struktury SharePoint portálů. Plánujte pečlivě!
TAGS:
Share:
0 comments on Logická struktura portálu nade vše

Post a comment

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..