24.8.2009BLOB caching (promiňte, ale počeštěné “kešing” nebo “kešování” nebo “využití mezipaměti” mi nějak nesedí) je, v souvislosti s SharePoint platformou velmi málo známá věc. Provozujete-li SharePoint ve scénáři serverové farmy (myslím opravdovou serverovou farmu s front-end aplikačními a back-end databázovými servery, ne tedy v tom smyslu, ve kterém toto označení používá Microsoft pro jakékoliv instalace, kdy SharePoint nevyužívá integrovaný DB stroj), pak čtěte pozorně. Trocha teorie na úvod BLOB je zkratkou z “Binary Large Object”. BLOB je datový typ pro ukládání binárních dat do databází, jedná se typicky o AV soubory, dokumenty apod. Vřele doporučuji k přečtení studii z Microsoft Research “To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?”, která je ke stažení zde. Ze studie vyplývá, že binární objekty větší než 1 MB je výhodnější ukládat na FS (díky bohu za FILESTREAM v SQL Serveru 2008), objekty menší než 256 KB je naopak výhodnější ukládat do databáze. Mezi tím je tak trochu mlhavý prostor a v něm silně záleží na druhu aplikace. Pokud se data často přepisují, tak je lepší spíše FS (lépe se vyrovnává s fragmentací), pokud se data nepřepisují, tak je lepší DB. Co myslíte, že je rychlejší? Tahat binární soubory z DB back-end serverů, nebo si je “nakešovat” (hm, tady se tomu počeštěnému tvaru holt nevyhnu) na FS front-end serveru a klientům je poskytovat odtud? :-) Říkáte-li si “Pche, použiju radši FILESTREAM.”, tak ano, klidně, máte-li SQL Server 2008, skvělá volba. BLOB caching však mohou všichni využít hned a jak uvidíme, skutečně velmi jednoduše. Takže jak na to? V souboru web.config dané SharePoint webové aplikace vyhledejte tento řádek:
<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="false"/>
a hodnotu jeho parametru enabled změňte na true. Parametr maxSize="10" určuje velikost cache a pozor, hodnota je v GB! Zbytek je asi jasný, cesta, typy souborů... Doplnit můžete ještě parametr max-age, např. s hodnotou 43200 (udává se v sekundách, zde tedy nastavení pro 12 hodin – max-age=”43200”), kterou určíte hodnotu max. stáří souborů. Po editaci a uložení souboru web.config není třeba ani reset IIS, vše hned funguje, soubory se v cache ukládají hezky do stromové struktury kopírující topologii vašeho portálu s velmi originální příponou “cache”. :-) Kdy se to může pokazit? Máte-li SharePoint s jedním front-endem, pak nikdy. Cache bude jedna a chová se tak, jak má. Dojde-li ke změně souboru uloženého na SharePointu, změní se i cache. Provozujete-li však v rámci SharePoint farmy více front-endů, tak každý z nich bude mít svou vlastní cache. Někdy je tedy nutné cache resetovat a to na všech front-end serverech najednou. Jak na to? S pomocí této adresy http://mojewebapplikace:mujport/_layouts/objectcachesettings.aspx (samozřejmě si to upravte dle vašeho nastavení) zobrazte stránku “Object cache settings” a ejhle – volbou “Force all servers in the farm to flush their object caches” docílíte požadovaného stavu, kdy na všech front-end serverech v rámci farmy dojde k vyprázdnění obsahu cache. Pokud tuto volbu na stránce “Object cache settings” nevidíte, tak buď nainstalujte SP2 ( :-) ), nebo použijte tento bezplatný doplněk: MOSS 2007 Farm-Wide BLOB Cache Flushing Solution. Další doporučené odkazy Configure disk-based cache settings - http://office.microsoft.com/en-us/sharepointserver/HA101762841033.aspx
How to automatically reset/clear the Blob Cache/Disk Cache - http://msdnrss.thecoderblogs.com/2009/05/25/how-to-automatically-resetclear-the-blob-cachedisk-cache-programmatically/ 23.8.2009Dovolím si říci, že datová komprese je v rámci IIS tak trochu zapomenutým pojmem. Když se IT administrátorů na tuto funkci ptám, většina z nich dokáže rámcově říci k čemu je to dobré, ale překvapivě velmi málo z nich ji skutečně na svých webových serverech používá. Proč? No to víte, ve výchozím nastavení to není zapnuté. A ikdyž to zapneme v rámci grafického rozhraní IIS konzoly, tak to nefunguje, nebo to nefunguje tak, jak chceme a pokud to možná i funguje, nevíme jak. :-) A přitom je to tak snadné a při správném a citlivém nastavení i užitečné! Komprimovat ano či ne? Ano, ale s rozmyslem! Klasickou komprimaci souborů jistě znáte, “sbalením” do ZIP, RAR či jiných archivů se zmenšuje jejich datový objem. Možná víte, že i Microsoft Office Open XML transparentně používá ZIP kompresi (přejmenujte si libovolný DOCX, PPTX, XLSX soubor na ZIP a již víte, kde je zakopán pes). Tento článek tedy popíše, jak podobnou kompresi dat využít i v okamžiku jejich přenosu mezi webovým serverem a klientem. Zjednodušeně řečeno funguje komprese tak, že nahrazuje opakující se sekvence bajtů. Výhodné je tedy využít ji pro textová data (soubory typu HTML, CSS, JS…). Naopak nevhodné je snažit se kompresi využít pro již jednou komprimované soubory (JPEG, GIF, MP3, WMV, ZIP…). Fajn, kompresí tedy šetříme přenesené datové objemy mezi serverem a klientem, ovšem nic není zadarmo. Pozor si musíte dát na procesorovou zátěž daného web serveru. Je-li již nyní váš web server na tom s procesorovým časem bídně, zapnutí komprese mu moc nepomůže. Co na to SharePoint a jak HTTP komprese funguje? V rámci SharePoint portálů můžeme velmi snadno využívat předpřipravené nástroje pro tvorbu nových řešení a služeb, zároveň máme nicméně velmi malou kontrolu nad tím v jaké finální podobě se HTML kód posílá na stranu klientů. Pamatujte, že SharePoint využívá jak statické, tak dynamické soubory. Téměř všechno z “_layouts” a “_vti_bin” je statické (kromě několika přítomných ASPX a ASMX stránek), a všechno z rootu je dynamické, neboť se buď jedná o ASPX stránky či obsah poskytovaný pomocí owssvr.dll (ISAPI extension využívaný mimo jiné při vytváření či mazání SharePoint seznamů, http://www.server.com/subweb/_vti_bin/owssvr.dll?Cmd=NewList a vykreslování HTML obsahu.). Při nastavování HTTP komprese je tedy třeba zohlednit jak statický, tak dynamický obsah. Ostatně typickou skupinu typů souborů, u nichž kompresi zapínáme, vidíte níže v ukázce skriptu. Přijde-li na IIS požadavek, dojde nejprve ke kontrole, zda klient kompresi podporuje a jaké podporuje její typy, a to pomocí HTTP hlavičky Accept-Encoding. Umí-li server používat klientem podporované typy komprese, tak svou odpověď zkomprimuje příslušným kompresním algoritmem (GZIP, DEFLATE) a odešle odpověď klientovi. Zároveň mu pomocí hlavičky Content-Encoding sdělí, jaký kompresní algoritmus pro komprimaci odpovědi použil. Je-li klientem poptáván statický obsah, IIS 6.0 nejprve ověří, zda byl daný obsah již dříve požadován a je tedy uložen v komprimované podobě v lokální mezipaměti (cache, standardně %Windir%\IIS Temporary Compressed Files). Není-li komprimovaná verze v mezipaměti nalezena, pak server odešle klientovi nekomprimovanou verzi obsahu a na pozadí provede jeho komprimaci a uložení do lokální mezipaměti, odkud je při dalších požadavcích klientům opětovně poskytován. Dopad na zátěž procesoru tedy není velká, protože procesor nemusí data znovu komprimovat. Dynamický obsah však “kešován” serverem není, IIS neukládá komprimované verze dynamického výstupu do mezipaměti. Přijde-li tedy na server požadavek na dynamický obsah, pak data, která server klientovi posílá, jsou znovu generována a komprimována vždy při každém požadavku, což znamená nárůst procesorové zátěže. A pozor – chcete-li využít kompresi i pro soubory uložené v dokumentových knihovnách, pak vězte, že se de-facto jedná o data poskytovaná již zmíněnou owssvr.dll knihovnou, tedy o data dynamická, a do výčtu typů souborů tedy musíte přidat DLL, namísto DOC apod. V tom případě však ještě pečlivěji sledujte procesorovou zátěž a rovněž mrkněte sem: http://support.microsoft.com/?id=841120 Kompresní stupeň Ve výchozím nastavení je kompresní stupeň u statického obsahu nastaven na 10. V předchozích řádcích jsme si však již objasnili, že u statického obsahu se zvýšení procesorové zátěže, zejména tedy u SharePoint portálů, standardně obávat příliš nemusíme. Ve výchozím nastavení je kompresní stupeň u dynamického obsahu nastaven na 0. Maximální hodnota je, podobně jako u statického obsahu, 10. 0 znamená bez komprese, 10 je komprese maximální, ovšem zároveň s největší procesorovou zátěží. Obecně je doporučováno u dynamického obsahu používat kompresní stupně od 4 do 7. Dobré je rovněž poznamenat, že mezi stupni 9 a 10 je jen minimální rozdíl ve velikosti přenášených dat, nicméně znatelný rozdíl v procesorové zátěži. Na stupeň 10 tedy zapomeňte rovnou a hlavně sledujte čítače procesorové zátěže. Kompresní stupeň lze u dynamického obsahu nastavit např. takto: - CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "7"
- CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "7"
HTTP komprese a IIS 6.0 a IIS 7.0 HTTP komprese se drobně odlišuje mezi IIS 6.0 (Windows Server 2003) a IIS 7.0 (Windows Server 2008). U IIS 6.0 se HTTP komprese nastavuje pro typy souborů dle jejich přípon, zatímco v IIS 7.0 se komprese nastavuje s využitím MIME typů. IIS 7.0 rovněž přichází s dalšími novinkami, jako je schopnost dynamického zapínání či vypínání komprese v závislosti na využití procesoru. Příklad skriptu na zapnutí komprese pro IIS 6.0:
cd c:\inetpub\adminscripts REM Zapnuti globalni komprese pro dynamicky a staticky obsah
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoDynamicCompression true
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression true REM Nastaveni kompresniho stupne komprese dynamickeho obsahu
cscript.exe adsutil.vbs set w3svc/filters/compression/gzip/hcdynamiccompressionlevel "7"
cscript.exe adsutil.vbs set w3svc/filters/compression/deflate/hcdynamiccompressionlevel "7" REM Urceni typu souboru
cscript.exe adsutil.vbs set w3svc/filters/compression/gzip/hcscriptfileextensions "css" "js" "asp" "exe" "axd" "aspx" "ascx" "ashx" "asmx" "xml"
cscript.exe adsutil.vbs set w3svc/filters/compression/deflate/hcscriptfileextensions"css" "js" "asp" "exe" "axd" "aspx" "ascx" "ashx" "asmx" "xml" iisreset
pause
Příklad nastavení komprese pro IIS 7.0: Nejprve do IIS 7.0 přidejte pomocí Server Manager konzole roli “Dynamic Content Compression”. V IIS 7.0 je ve výchozím nastavení komprese statického obsahu zapnuta a komprese dynamického obsahu je vypnuta. Zapneme ji tedy takto: APPCMD.EXE set config -section:urlCompression /doDynamicCompression:true
Dále nastavíme stupeň komprese: APPCMD.EXE set config -section:httpCompression -[name='gzip'].staticCompressionLevel:9 -[name='gzip'].dynamicCompressionLevel:7
A následně určíme kdy bude komprese využívána vzhledem k aktuální procesorové zátěži (zde kompresi povolujeme při procesorové zátěži v rozsahu 20-75%): APPCMD.EXE set config –section:httpCompression /dynamicCompressionDisableCpuUsage:75
APPCMD.EXE set config –section:httpCompression /dynamicCompressionEnableCpuUsage:20 Ukázka z praxe Velikost přenášených dat souboru core.js je při použití komprese zmenšena z 266 KB na 59 KB.   
Odkazy na závěr 22.8.2009(Tento článek, včetně dalších dílů, byl původně psán pro Microsoft TechNet Blog, na kterém byl zveřejněn v dubnu 2009.) Náš miniseriál věnovaný platformě Microsoft SharePoint dnes zakončíme povídáním o licencování tohoto řešení. Jak nakoupit? Dovolím si říci, že není situace či požadavek zákazníka, na který by společnost Microsoft neměla připravenu odpovídající variantu či způsob nákupu licencí. Chcete pořídit licence SW spolu s novým HW? V pořádku, máme licence OEM. Chcete získat samostatný upgrade pro Windows či Office, nebo si domů pořídit licenci „pro studenty či domácnosti“? OK, máme krabicová balení. Hodláte pořídit více licencí najednou a zajímáte se o rozličné možnosti platby za licence? Pak zvolte některý z multilicenčních programů, nabízející jednorázové nákupy licencí, či nákupy formou splátek či pronájmu. Jak tedy pořídit licence zvoleného SharePoint řešení a jaká licenční pravidla musíme respektovat? Windows SharePoint Services 3.0 (WSS) Jsou zdarma, kupovat tedy nebudete nic. Nebo že by ano? Online z webu http://download.microsoft.com si volně stáhnete instalační balíček WSS včetně případných jazykových balíčků „Language Pack“ a vesele instalujete. Dobře, tohle je zdarma. Ovšem kam instalujete? No samozřejmě že na Windows Server, konkrétně 2003 nebo 2008, typicky v edicích Standard či Enterprise. No a Windows Server již zdarma není. Windows Server vyžaduje svou licenci serverovou a licence Windows Server CAL (Client Access License) pro všechny uživatele či zařízení, kteří přímo či nepřímo přistupují k instanci serveru. Tímto přístupem myslíme i přístup k WSS portálu, to pro určení nutnosti nákupu licencí Windows Server CAL úplně stačí. Onen Windows Server nemusí být uživatelem využit nijak jinak (třeba jako souborový server apod.), přesto by bez Windows Serveru WSS portál nebežel, takže uživatelé k instanci Windows Serveru „přistoupili“ a licence Windows Server CAL potřebují. Máte-li tedy ve firmě samé Windows Server 2003 a k nim licence Windows Server CAL a pro WSS potrál pořídíte nový HW a s ním Windows Server 2008, pak potřebujete i nové Windows Server 2008 CAL licence, pozor na to! Snad jedinou výjimkou, kdy pro Windows Server s nainstalovanou WSS službou nepotřebujete licence Windows Server CAL, je situace, kdy vytváříte WSS portál anonymně dostupný pro uživatele přistupující k tomuto portálu výhradně prostřednictvím sítě Internet. Tento scénář však asi příliš častý nebude. A pokud to přeci jen chcete udělat, raději mi napište, ať dořešíme detaily. Licence Windows Serveru jsou pro nákup dostupné jako OEM licence (pořizují se spolu s HW), dále v rámci libovolného z multilicenčních programů Microsoft, nebo v rámci krabicového balení SW. A co databáze, kam WSS ukládá svá data? Použijete plnohodnotný SQL Server? Prima, z technického pohledu dobrý nápad. Ovšem i SQL Server musí být řádně licencován. Buď licencemi procesorovými (pokud na WSS přistupují řádově desítky uživatelů), nebo licencí serverovou a licencemi SQL Server CAL. Říkáte si, že stačí jeden SQL Server CAL, protože přece z technického pohledu WSS „sahá“ do SQL DB jedním účtem, jednou identitou (tou, která je nastavena ve vlastnostech fondu aplikací WSS v rámci IIS, což je typicky „Network Service“ při Basic instalaci či vlastním účtem při Advanced instalaci)? No, řekněme, že z technického pohledu máte pravdu, licenčně je to však bezpředmětné. Proč? Oficiální pravidla říkají: „Hardware nebo software, který používáte pro sdružování připojení; přesměrování informací; snížení počtu zařízení nebo uživatelů, kteří mají přímý přístup k produktu nebo ho používají; snížení počtu prostředí operačního systému, zařízení nebo uživatelů, které produkt přímo spravuje; (někdy označováno termínem multiplexování nebo sdružování), nesnižuje požadovaný počet licencí jakéhokoli typu.“ Poněkud kostrbaté? Možná. Avšak docela výstižné. Možná lépe pochopitelná je další věta z licenčních pravidel: „Musíte získat a přiřadit licenci CAL každému zařízení nebo uživateli, kteří přímo nebo nepřímo přistupují k instancím serverového softwaru.“ No a to je právě ono. Již jsem o tom v jednom z předchozích odstavců hovořil. Bez SQL Serveru, pokud jej tedy používáte, by váš WSS portál prostě neběžel. Uživatelé přistupující k WSS portálu z licenčního pohledu nepřímo (prostřednictvím služeb WSS) přistupují i k instanci SQL Serveru, kde má WSS své databáze. Nutnost nákupu licencí SQL Server CAL pro všechny přistupující uživatele, případně licencí procesorových, je tedy zřejmá. 
Zkráceně řečeno: máte-li WSS nainstalován s integrovaným DB strojem, vystačíte si jen s licencí Windows Serveru a licencemi Windows Server CAL. Použijete-li pro WSS DB klasický SQL Server, pak musíte licencovat i jej. Microsoft Office SharePoint Server 2007 (MOSS 2007) Vše, co je napsáno v předchozích odstavcích textu ohledně nutnosti licencování Windows Serveru a SQL Serveru při použití se službou WSS, platí i pro MOSS 2007 s jedním „drobným“ rozdílem – MOSS 2007 na rozdíl od WSS není zdarma. MOSS 2007 je typickým příkladem serverového produktu, který je licencován v licenčním režimu „Server + CAL“. Dalšími takovými serverovými produkty jsou např. Exchange Server, Project Server, zde již několikrát zmíněný Windows Server a řada dalších. Licencování MOSS 2007 má následující principy: Pro server (HW zařízení nebo server typu blade), na kterém hodláte MOSS weby provozovat, potřebujete serverovou licenci MOSS 2007. „Stačí“ vám jedna pro každý server (HW). Hodláte-li tedy např. vytvořit MOSS farmu s dvěma servery (na prvním provedete „Complete“ instalaci a na druhém „Web Front End“), tak potřebujete dvě serverové licence MOSS 2007. Pro všechny přistupující uživatele či pro všechna zařízení dále potřebujete licence MOSS 2007 CAL (Client Access License). Proč hovořím o přistupujících uživatelích či zařízeních? Licence MOSS 2007 CAL jsou dostupné ve dvou variantách – v režimu „na uživatele“, tedy User CAL a „na zařízení“, tedy Device CAL. Variantu User CAL zvolte v případě, že vaši uživatelé využívají pro přístup k MOSS portálům více zařízení, mají např. stolní PC a zároveň notebooky. Licencujete tedy uživatele (ne uživatelské účty, těch mějte, kolik chcete, ale uživatele, fyzické osoby) a z kolika zařízení tito uživatelé přistupují k MOSS portálům a rovněž také odkud k nim přistupují vám může být jedno. Variantu Device CAL naopak zvolte, pokud vaši uživatelé např. pracují ve směnném provozu a u omezeného počtu počítačů se střídá více uživatelů. V tomto režimu tedy počítáte pouze počty zařízení (stolní PC, notebook, PDA...), ze kterých uživatelé přistupují k vašim MOSS portálům a kolik těch uživatelů je, je vám jedno. Pro úplnost dodejme, že licence User CAL a Device CAL stojí stejně a samozřejmě že je můžete vzájemně kombinovat. Výše uvedená pravidla platí obdobně i pro Windows Server a licence Windows Server CAL. 
Říkáte si, že je to docela jednoduché? To rád slyším. Vězte ale, že u MOSS a licencí CAL potřebujete znát ještě jednu další licenční „dobnost“. Slyšeli jste již něco o tzv. MOSS Enterprise funkcích a MOSS Enterprise CALech? Licenční pravidla říkají: použijete-li v rámci MOSS funkce typu „E-forms, spreadsheet publishing and data integration functionality“, tak potřebujete kromě licencí MOSS 2007 Standard CAL navíc i licence MOSS 2007 Enterprise CAL. Věc se nám tedy poněkud komplikuje. Vězte, že u MOSS 2007 máme jednu edici serverovou (tedy jeden typ serverové licence), ovšem dvě edice CAL – tzv. Standard CAL (dostupné v režimech User a Device) a Enterprise CAL (také dostupné v režimech User a Device). K využití následujících scénářů stačí MOSS 2007 Standard CAL licence: - Collaboration
- Enterprise content management
- Workflow
- My Sites
- Profiles and personalization
- Enterprise search
Licence MOSS 2007 Enterprise CAL pak navíc potřebujete pro uživatele nebo zařízení, kteří v rámci MOSS portálu využívají: - Business Data Catalog
- Excel Services
- Report Center
- InfoPath Forms Services
- PerformancePoint scorecarding and dashboarding
Ono slovíčko „navíc“ je nesmírně důležité. Enterprise CAL licence jsou doplňkové CALy, které potřebujete navíc ke CALům Standard, pokud máte na MOSS portálu zapnuté „Enterprise“ funkce (Central Administration > Operations > Enable Enterprise Features) a využíváte tedy výše uvedené čtyři scénáře. 
Zdůrazňuji, že MOSS 2007 Enterprise CAL licence potřebujete navíc k licencím MOSS 2007 Standard CAL jen pro ty uživatele (User CAL) či pro ta zařízení (Device CAL), která využívají zmíněné „enterprise“ funkce. Uživatelé, přistupující na kolekce webů či weby, kde „enterprise“ funkce nejsou dostupné, mohou mít „jen“ MOSS 2007 Standard CAL licence. Využíváte-li však „enterprise“ funkce rozličně v rámci celého portálu a nejste-li schopni efektivně přístup uživatelů k „enterprise“ funkcím omezit, pak potřebujete MOSS 2007 Enterprise CAL licence, kromě licencí MOSS 2007 Standard CAL, pro všechny uživatele (nebo pro všechna zažízení). Ony „enterprise“ funkce jsou z uživatelského pohledu právě „ty zajímavé“, mnohdy tedy není možné ani žádoucí přístup uživatelů k těmto funkcím omezit, „enterprise“ funkce se aktivují na všech webech a MOSS 2007 Enterprise CAL licence se tedy spolu s MOSS 2007 Standard CAL licencemi kupují pro všechny uživatele, čímž se cena takového řešení „trochu“ zvyšuje (MOSS Enterprise CAL licence stojí cca 80% ceny MOSS Standard CAL licencí). 
Licence MOSS 2007 jsou pro nákup dostupné v rámci libovolného z multilicenčních programů Microsoft, nebo v rámci krabicového balení SW. Zapomínat bychom následně neměli ani na licencování SQL Server, který máte pravděpodobně pro vaše MOSS portály použít jako DB úložiště (nemáte-li MOSS nainstalován s integrovaným DB strojem). Licencování SQL Serveru by v pohodě vystačilo na samostatný článek, my si zde jen stručně řekneme, že SQL Server budete pravděpodobně licencovat tzv. „procesorovými licencemi“, tedy licencemi pořízenými pro všechny fyzické či virtuální procesory, které využívá instance OS, na které SQL server provozujete. Máte-li MOSS portál přístupný pro méně než 28 uživatelů (což nepředpokládám), pak pro vás bude výhodnější licencovat SQL Server v licenčním režimu Server + CAL. Zájemci o další informace týkající se licencování SQL Serveru si mohou z mého blogu stáhnout podrobnou licenční prezentaci na toto téma. Licence SQL Serveru jsou pro nákup dostupné v rámci libovolného z multilicenčních programů Microsoft, nebo v rámci krabicového balení SW. Microsoft Office Forms Server 2007 (MOFS 2007) Licencování tohoto produktu má stejná licenční pravidla a principy, jaké jsme popsali u MOSS 2007 s jedním podstatným rozdílem – u MOFS 2007 neexistují žádné Enterprise CALy. Jedná se tedy o klasický produkt licencovaný dle licenčního režimu Server + CAL svou licencí serverovou a licencemi CAL ve variantách User a Device. Licence MOFS 2007 jsou pro nákup dostupné v rámci libovolného z multilicenčních programů Microsoft, nebo v rámci krabicového balení SW. Elektronické formuláře, které na MOFS serveru využíváte, můžete velmi snadno vytvářet a publikovat z aplikace InfoPath 2007. Tu buď získáte jako součást edicí Microsoft Office 2007 Professional Plus, Enterprise nebo Ultimate, nebo ji můžete pořídit i samostatně. Microsoft Office SharePoint Server 2007 for Internet Sites Toto je specifická licence MOSS 2007, určená pro SharePoint portály publikované do sítě Internet. Technicky se jedná o klasický MOSS 2007 s dostupnými „enterprise“ funkcemi, ovšem licenčně je tento produkt omezen pouze pro data publikovaná do sítě Internet (nic z dat na tomto portálu uložených nesmí být dostupné pouze pro interní uživatele firmy vlastnící tuto serverovou licenci). Licencování tohoto produktu je docela jednoduché – k dispozici je pouze licence serverová, nejsou zde žádné licence CAL. Licence Microsoft Office SharePoint Server 2007 for Internet Sites jsou pro nákup dostupné v rámci libovolného z multilicenčních programů Microsoft, nebo v rámci krabicového balení SW. A ještě dodatek k sadám Microsoft Office 2007. Není Word jako Word, není Excel jako Excel. V přehledové tabulce uvidíte, že tři největší sady Microsoft Office 2007, tedy edice Professional Plus, Enterprise a Ultimate podporují tzv. „pokročilé funkce“. O co se jedná? Chcete-li přímo z Office aplikací iniciovat SharePoint pracovní postupy a vykonávat akce jimi předepsané, chcete-li z Excelu publikovat na SharePoint sešity s využitím SharePoint Excel Services a sdílet je takto online, chcete-li z aplikace PowerPoint publikovat snímky prezentací do knihovny snímků serveru SharePoint, pak potřebujete jednu ze tří uvedených edicí sad Microsoft Office 2007 podporujících tzv. pokročilé funkce. Dámy a pánové, vážení čtenáři, těmito řádky končíme náš miniseriál věnovaný platformě Microsoft SharePoint. Doufám, že jste uvedené informace shledali užitečnými. Uvítám vaši zpětnou vazbu a budete-li chtít, můžeme v rámci TechNet blogu v psaní o SharePoint technologiích pokračovat, témat je jistě dost a dost. 21.8.2009(Tento článek, včetně dalších dílů, byl původně psán pro Microsoft TechNet Blog, na kterém byl zveřejněn v dubnu 2009.) Třetí díl TechNet miniseriálu věnovaného platformě Microsoft SharePoint pojednává o základním stavebním kamenu řízené tvorby informací, tedy o „typech obsahu“, tzv. Content Types. Podobně jako jsem velkým zastáncem využívání kolekcí webů, viz. minulý článek, tak i k typům obsahu mám, řekněme, vřelý vztah. :) Škoda jen, že standardně nefungují zcela tak, jak bychom chtěli, ale nevadí, téměř vše se dá vyřešit. Takže vzhůru do toho! K čemu je to dobré? Představme si následující scénáře: pracovníci obchodního oddělení ukládají do dokumentových knihoven obchodní nabídky, podklady pro výběrová řízení, členové projektových týmů sdílí projektovou dokumentaci, zápisy z porad, výrobní firma na produktových webech pracuje na specifikacích návrhů produktů, atd. Všechny tyto činnosti si přímo říkají o vytvoření opakovatelně využitelných typů obsahu, s definovanými šablonami dokumentů, metadaty, s panely informací pro editaci metadat a nastavenými sledy prací (říkejme raději workflow) pro opakované využití v různých částech portálu a pro řízené schvalování takto strukturovaně vytvářeného obsahu. No a o to právě jde. Jednou vytvořený typ obsahu opakovaně používáme v různých částech portálu a také v jednom seznamu (např. dokumentové knihovně) používáme různé typy obsahu. Pojďme to ale vzít hezky od začátku. Typ obsahu je opakovaně využitelná kolekce nastavení, vlastností a činností, které přiřazujete jistému druhu záznamů. S využitím typů obsahu můžete definovat schéma pro jednotlivé druhy záznamů. Toto schéma však není vázáno na jeden konkrétní seznam a jeho „datovou strukturu“. U WSS 2.0 jsme schéma definovali vždy v rámci konkrétních seznamů pomocí jejich sloupců. S WSS 3.0 a samozřejmě tedy i u MOSS 2007 a MOFS 2007 toto omezení padá. Schéma tedy může být opakově použito u různých seznamů (pod pojmem seznamem myslím dokumentové knihovny, knihovny formulářů, nebo klasické seznamy typu kalendář, kontakty, úkoly atd.). Jeden typ obsahu stylu dokument tedy může být přiřazen více dokumentovým knihovnám, typ obsahu stylu událost může být přiřazen více seznamům typu kalendář apod. A také naopak – seznamy služby SharePoint již nejsou omezeny pouze na jedno datové schéma, kterému by musely všechny ukládané záznamy vyhovět, neboť jednomu seznamu je možné přiřadit více typů obsahu, z nichž každý může mít jedinečné datové schéma definované pomocí metadat. Typy obsahu tedy v zásadě umožňují: - ukládat jeden typ obsahu (s definovanou strukturou metadat) do více seznamů
- ukládat více typů obsahu (s rozličnými strukturami metadat) do jednoho seznamu
Typ obsahu může obsahovat: - Strukturu metadat definovaných pomocí tzv. sloupců webu („Site Columns“). Sloupce webu přiřazené k typu obsahu rozšíří strukturu sloupců definovaných u konkrétního seznamu, kterému je typ obsahu přiřazen. Samotné sloupce webu jsou opakovaně použitelné definice či šablony sloupců, které lze přiřazovat seznamům a typům obsahu v rámci jednotlivých kolekcí webů.
- Vlastní formuláře pro vytvoření, editaci či zobrazení typu obsahu.
- Přiřazená workflow, využitelná např. pro schvalování záznamů, připojení komentářů či téměř cokoliv jiného. Akce workflow mohou být spouštěny automaticky při vytvoření záznamu dle definovaného typu obsahu či při jeho změně.
- U typů obsahu stylu dokument nastavitelnou šablonu dokumentu, na základě které bude výsledný dokument vytvořen.
- U typů obsahu stylu dokument vlastní šablonu panelu informací pro přímou editaci metadat v rámci prostředí aplikací Microsoft Office 2007. Tento panel informací je de-facto formulářem aplikace Microsoft Office InfoPath 2007, máte-li tedy tuto mocnou aplikaci nainstalovanou, pak editaci formulářů nic nebrání.
- Libovolné další informace potřebné pro vlastní řešení přidružené k typu obsahu s využitím XML schématu. Programátoři jistě uvítají web http://msdn.microsoft.com/en-us/library/ms463449.aspx s detailními informacemi.
Druhy typů obsahu Ikdyž to možná není zcela podstatné, neodpustím si informaci o typech obsahu – rozeznáváme dva druhy typů obsahu: typy obsahu na úrovni webů a typy obsahu na úrovni seznamů. Typy obsahu na úrovni webů chápejte jako opakovaně využitelné šablony a typy obsahu na úrovni seznamů jako instance těchto šablon. Typy obsahu vytváříme na úrovni webů (v praxi spíše na úrovni kolekcí webů), odtud tedy onen název. Kolekce webů či web, v jehož rámci je typ obsahu (a příslušné sloupce webů) vytvořen, zároveň určuje rozsah využitelnosti daného typu obsahu. Typy obsahu na úrovni seznamů jsou vlastně něco jako instance typů obsahu na úrovni webů, přiřazené konkrétnímu seznamu. Po přiřazení typu obsahu danému seznamu je do něj typ obsahu zkopírován, včleněn a stává se z něj typ obsahu na úrovni seznamu. Typ obsahu na úrovni seznamu můžete následně upravit tak, aby byl odlišný od rodičovského typu obsahu na úrovni webu, což ovšem neznamená, že tím automaticky ztrácí vazbu na svůj rodičovský typ obsahu uložený na úrovni webu. Typy obsahu je možné vytvářet na základě jiných typů obsahu, mezi typy obsahu tedy může vzájemně fungovat dědičnost. Ta také funguje, jak jsem již naznačil, mezi šablonou typu obsahu uloženou na úrovni webu a typem obsahu na úrovni seznamu. Při změně typu obsahu vytvořeného na úrovni webu je změna definice promítnuta do všech seznamů v rámci kterých je daný typ obsahu přiřazen. Velmi užitečné! A další věc – užitečné je vytvořit i typy obsahů druhu složka. I to je typ obsahu s přidruženými metadaty, který, jak již název napovídá, umožňuje na úrovni seznamů vytvářet složky s vlastní sadou metadat. S využitím typů obsahů a jejich metadat můžete následně vytvářet v rámci seznamů vlastní zobrazení (view) a filtrovat tak např. zobrazované záznamy dle vlastních kritérií. Typy obsahu a rozsah jejich dostupnosti Rozsah využitelnosti typů obsahu v závislosti na místě jejich vytvoření je hezky popsán na MSDN webu zde http://msdn.microsoft.com/en-us/library/ms441146.aspx a věřím, že toto samotné téma není třeba příliš rozvádět. Jednoduše řečeno: web či kolekce webů, v jejímž rámci typ obsahu vytvoříte, vymezuje oblast jeho využití, jeho dostupnosti. Může to v praxi však znamenat jeden problém – chceme-li napříč více kolekcemi webů využívat jednotná metadata (sloupce webů) a typy obsahu, tak to standardně prostě nejde. :( Někteří z mých klientů právě kvůli tomuto faktu nevyužívají kolekce webů, což přináší zase jiné nevýhody popsané v minulém článku. Jak z toho ven? Buď najměte schopného programátora, nebo kupte hotové řešení. Jedno z nich, téměř dokonalé s názvem SharePartXXL Taxonomy Extension, nabízí firma SharePartXXL International GmbH, více informací najdete na jejich webu http://www.sharepartxxl.com. Typy obsahu, sloupce webu a BDC Jedním ze scénářů, o který si typy obsahu, přesněji řečeno tedy sloupce webů, přímo říkají, je propojení s nástrojem „správce obchodních dat“, alias Business Data Catalog. Co to je? BDC umožňuje propojovat (pomocí XML definičních souborů aplikací) seznamy serveru SharePoint s externími datovými zdroji. Při vkládání nové obchodní nabídky do dokumentové knihovny tedy můžeme pomocí BDC sloupců k danému dokumentu přímo vkládat informace z externího systému, který ony informace sdružuje, řekněme CRM systému apod. Fajn, tohle je „jednoduché“ (možná by o BDC mohl být jeden z dalších článků), ovšem opět je zde ve spojení se sloupci webů jeden „malý“ problém – sloupce webů standardně neumí být typem BDC. :( Na jednom z obrázků na konci tohoto článku uvidíte, které datové typy se pro sloupce webů nabízí, BDC mezi nimi bohužel není. No ale nevadí, SharePoint 2007 již nějakou dobu na trhu je a tato skutečnost samozřejmě nevadí jen nám. Existuje tedy opět řešení a opět je od třetí strany – zdarma si od Aarona Robertsona můžete stáhnout a upravit jeho řešení zde: http://www.sharepointblogs.com/aaronrh/archive/2007/12/21/free-sharepoint-business-data-catalog-column.aspx. Znáte-li lepší, ozvěte se, uvítám to. :) A nyní obrázková dokumentace, hezky krok za krokem: Dokumentová knihovna nabízí po svém vytvoření standardně dva typy obsahu – nový dokument a nová složka. 
Použití vlastních typů obsahu je nutné u seznamů nejprve zapnout v upřesňujícím nastavení. 
Na stránce Nastavení daného seznamu je poté možné v oddílu „Typy obsahu“ přidávat nové typy obsahu a měnit jejich nastavení. 
Na stránce Nastavení webu definujeme nové sloupce webu (metadata) a vlastní typy obsahů. 
Při tvorbě nového sloupce webu můžeme využít celou řadu datových typů, bohužel ne typ BDC. Na ukázce použitý typ vyhledávacího sloupce slouží k vrácení dat z jiného zvoleného sloupce jiného seznamu. 
V tomto případě budeme získávat hodnoty ze sloupce Nadpis seznamu Produktové skupiny. 
Nově vytvořené sloupce webů doporučuji ukládat s využitím vlastních skupin sloupců webu. Usnadníte si tak jejich třídění. 
V galerii typů obsahu vidíte standardní typy obsahu dostupné po instalaci serveru SharePoint. Všimněte si např. typů obsahu dokument, kontakt apod., ty jsou využity ve výchozím nastavení u dokumentové knihovny a seznamu kontaktů jako výchozí položky pro tvorbu nového záznamu. 
Tvorba nového typu obsahu – určujeme název, nadřazený typ obsahu a skupinu. 
Stránka s nastavením typu obsahu. 
Přidání sloupců webu k novému typu obsahu. 
Přidání vlastní šablony dokumentu k novému typu obsahu. 
Pro vytvoření vlastního panelu informací pro daný typ obsahu klikněte na volbu „vytvořit novou vlastní šablonu“, ne na volbu „upravit tuto šablonu“. 
Aplikace Microsoft Office InfoPath 2007 s upraveným formulářem, který bude po opublikování (všimněte si odkazu v pravém dolním rohu aplikace) tvořit nový panel informací u typu obsahu. 
Po opublikování formuláře zavřete aplikaci InfoPath, vraťte se na stánku s nastavením panelu informací, zaškrtněte volbu pro zobrazování panelu informací při otevření dokumentu a vše potvrďte tlačítkem OK. 
A jsme zpátky v nastavení dokumentové knihovny, kde přidáváme nový typ obahu. 
V nastavení dokumentové knihovny je následně v oddílu Typy obsahu možné upravit pořadí typů obsahu (do nabídky Nový). První typ obsahu v pořadí je zároveň výchozím typem obsahu u daného seznamu. 
A zde již nabídka Nový s novým typem obsahu „Projektová dokumentace“. Typy obsahu Dokument a Složka jsem tam nechal záměrně pro orientaci, je však samozřejmě možné je následně z daného seznamu smazat. 
Ukázka šablony dokumentu u našeho typu obsahu Projektová dokumentace. Všimněte si panelu informací (formulář aplikace InfoPath) s našimi metadaty (sloupci webů) a použitými datovými poli přímo v dokumentu. 
Vybíráme hodnoty v informačním panelu. Stejné hodnoty se zároveň pomocí datových polí vkládají i do dokumentu. 
Při pokusu o uložení dokumentu Word automaticky nabídne jako výchozí místo knihovnu dokumentů, ze které jsme šablonu typu obsahu otevřeli. Nebude-li některé z povinných polí na panelu informací vyplněno, dokument nebude možné uložit. 
U dané dokumentové knihovny následně jednoduchou úpravou zobrazení přidáme např. do výchozího zobrazení „všechny dokumenty“ naše dva vlastní sloupce webu (spolu s typem obsahu se staly součástí definice schématu sloupců tohoto seznamu). 
A jsme ve finále – v dokumentové knihovně je uložen nový dokument vytvořený na základě vlastního typu obsahu, dokument má vyplněná metadata. Zároveň vidíte i seznam „Produktové skupiny“, ze kterého sloupec webu „Produktová skupina“ dotahuje data. 
Metadata můžeme editovat i ve webovém prohlížeči. 
Nová složka vtvořená na základě vlastního typu obsahu stylu „složka“ s vlastními metadaty. 
A zde nabídka „Nový“ s vlastními typy obsahu „Produktová dokumentace“ stylu dokument a „Rok 2009“ stylu složka. Pro orientaci jsem u této dokumentové knihovny ponechal i původní typy obsahu „Dokument“ a „Složka“, ty je samozřejmě možné jednoduše smazat. 
Dámy a pánové, tolik k povídání o základním stavebním kamenu strukturované a řízené tvorby informací na platformě Microsoft SharePoint – typech obsahu. Příště náš SharePoint miniseriál zakončíme vydatným povídáním o licencování produktů z rodiny SharePoint a souvisejících technologií. 20.8.2009(Tento článek, včetně dalších dílů, byl původně psán pro Microsoft TechNet Blog, na kterém byl zveřejněn v dubnu 2009.) 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 http://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 http://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 http://intranet/hr, http://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: http://intranet/departments/hr a http://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 http://intranet vytvoříme obyčejný podřízený web „projekt1“? Adresa tohoto webu by byla http://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 http://intranet/projekt2. Vedle sebe tedy máme obyčejný podřízený web http://intranet/projekt1 a samostatnou kolekci webů http://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. http://intranet/obchod, http://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 (http://intranet.company.com je v EN, http://intranet.company.com/czech/web je v CZ, http://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: http://intranet.firma.cz 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.) http://intranet.firma.cz/obchod Top Level Web Site / Sub Site nebo Site Collection? To i to, takto to nepoznáte. :-) http://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“: http://intranet.firma.cz/oddeleni/obchod
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 spravované cesty „projekty“: http://intranet.firma.cz/projekty/efs
http://intranet.firma.cz/projekty/iso http://intranet.firma.cz/weby/praha/obchod
Top Level Web Site / Managed Path / Site Collection / Sub Site http://emeaportal.company.com/sites/czech/salesdepartment
Top Level Web Site / Managed Path / Site Collection / Sub Site http://emeaportal.company.com/sites/czech/salesdepartment/prague
Top Level Web Site / Managed Path / Site Collection / Sub Site / Sub Site http://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ů. Příště 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. 19.8.2009
(Tento článek, včetně dalších dílů, byl původně psán pro Microsoft TechNet Blog, na kterém byl zveřejněn v dubnu 2009.)
O platformě Microsoft SharePoint bylo napsáno již hodně slov, málo v češtině, mnoho v angličtině. Po několika letech praktických zkušeností se zaváděním SharePoint produktů do firemního prostředí a se školením těchto technologií rozhodl jsem se, i díky výzvě ze strany společnosti Microsoft, sepsat formou čtyřdílného seriálu na pokračování své zkušenosti a především praktická doporučení. Věřím, že tato aktivita může přispět k evangelizaci (Zajímavé slovo, že? Ale obyčejné „osvěta“ prostě tak nezní.) této úžasné „platformy“. Tváří v tvář si pak můžeme o SharePointu povídat na kurzech a konzultacích, které na toto a další témata vedu v Počítačové škole Gopas. WSS, MOSS, MOFS, aneb vysvětlujeme zkratky a rozdíly Platforma Microsoft SharePoint je jedním ze základních stavebních kamenů produktové rodiny „systém Microsoft Office 2007“ (EN: Microsoft Office System 2007). „Systém Microsoft Office 2007 je soubor aplikací, serverů a služeb, které slouží k tvorbě řešení usnadňujících sdílení informací, jejich řízenou tvorbu a zpřístupňuje je odkudkoliv a kdykoliv.“, říká jedna z použitelných marketingových definic, která docela dobře vystihuje podstatu věci. Jde především o řízenou tvorbu a správu informací! K této větě se v mé sérii článků budu opakovaně vracet. Pochopíte proč. Začněme ale od začátku, tedy rozlišením produktů. Windows SharePoint Services 3.0 (WSS):
Microsoft Windows SharePoint Services napomáhá týmům sdílet informace, spolupracovat na dokumentech a shromažďovat týmové znalosti. Jedná se o základní stavební kámen každého Sharepoint řešení. Z pohledu uživatele (zjednodušeném pohledu, ale nám stačí) zajišťuje WSS funkčnost na úrovni seznamů, jako jsou knihovny dokumentů, knihovny formulářů, knihovny obrázků, wiki stránky, dále seznamy oznámení, kontaktů, úkolů a projektových úkolů, týmové kalendáře, diskusní vývěska, průzkumy a řešené problémy. Možné je samozřejmě vytvářet i vlastní seznamy. Tyto seznamy sdružujeme do týmových webů a ty pak do kolekcí webů (o struktuře portálu ale až někdy později, tedy hned zítra :)). Microsoft Office SharePoint Server 2007 (MOSS):
MOSS 2007 je integrovaná sada snadno ovladatelných serverových aplikací, které zvyšují efektivitu organizace, neboť umožňují komplexně spravovat informační obsah, a získávat tak vyšší obchodní hodnotu z informačních zdrojů, zrychlit interní a externí obchodní procesy, u nichž je zapotřebí sdílení informací, efektivně získávat a prezentovat informace a díky tomu přijímat kvalifikovanější rozhodnutí, sdílet obchodní informace s vyšší důvěrou v jejich zabezpečení v rámci organizace i mimo ni a poskytnout oddělení IT jedinou, integrovanou, rozšiřitelnou platformu pro správu intranetových, extranetových a internetových aplikací v celé organizaci. (Trochu komplikované, že? No ale je to tak.)
Jinými slovy a pochopitelným jazykem – nad rámec funkcí poskytovaných službou WSS představuje MOSS komplexní informační portál, zastřešující jednotlivé týmové weby a kolekce webů, nabízející navíc pokročilé vyhledávání v rozličných datových zdrojích, integrovaná workflow pro automatizaci procesů, možnost propojení portálu s externími datovými zdroji a následnou prezentaci těchto dat pomocí funkce správce obchodních dat, základní nástroje pro vyhodnocování obchodních dat pomocí KPI seznamů, výpočtové a formulářové služby umožňující prezentovat online Excelové sešity a InfoPath formuláře (sloužící samozřejmě i pro sběr dat), možnosti pro archivaci dokumentů, osobní weby a pokročilou správu webového obsahu. Microsoft Office Forms Server 2007 (MOFS):
Usnadňuje týmům a organizacím publikování a správu formulářů v centrálním umístění. Tyto formuláře pak lze otevírat a vyplňovat pomocí webového prohlížeče nebo přímo v aplikaci InfoPath 2007. Informace shromážděné v těchto formulářích lze snadno opakovaně používat v celé organizaci a v rámci obchodních procesů, protože formuláře aplikace InfoPath podporují oborový standard XML a mohou používat libovolné vlastní schéma definované uživatelem.
Tedy – MOFS 2007 je řešením pro online publikované formuláře (vytvářené ideálně z aplikace InfoPath 2007) s funkcionalitou WSS doplněnou o formulářové služby. Zajímá-li vás podrobný popis rozdílů mezi uvedenými produkty, tak podrobná tabulka s detailním popisem je k dispozici ke stažení zde, nebo ve formě online přehledu zde. Důvody pro nasazení Existuje jistě mnoho argumentů, proč nasadit produkty z rodiny SharePoint. Nepochybně by to vydalo na samostatný a docela slušně velký článek, nebo spíše články. Následující scénáře a vlastnosti jsou mé oblíbené, z praxe nejčastěji používané a klienty chtěné: - Řízená tvorba a sdílení dokumentů a informací a jejich archivace
(Tvorba dokumentů a záznamů s využitím „typů obsahu“ ; schvalování dokumentů a záznamů v rámci workflow a integrace tohoto procesu s aplikacemi Microsoft Office; upozorňování na změny; verzování dokumentů; připojování metadat k záznamům a dokumentům a jejich následné třídění a filtrování; nastavování „zásad správy informací“, jako jsou popisky, auditování, doba vypršení platnosti a čárové kódy; přesouvání dokumentů a záznamů do archivu. Podporuje částečně WSS a plně MOSS platforma.) - Centra schůzek pro efektivní sdílení dat z pracovních porad
(Samostatné weby pro firemní porady či týmové schůzky, s možností opakování jejich konání a časově odlišeným ukládáním informací a dokumentů k těmto týmovým aktivitám. Vynikající věc pro odstranění neustálého posílání emailů s informacemi o poradách, emalů se zápisy z porad apod. Podporuje WSS i MOSS platforma.) - Interaktivní webové formuláře usnadňující sběr dat
(I bez znalosti programování, v aplikaci InfoPath 2007 jednoduše vytvořitelné formuláře publikovatelné na MOSS weby, s možností jejich online prohlížení, editování, ukládání, sdílení, schvalování, verzování, atd. atd. Podporuje MOSS a MOFS platforma.) - Publikační portál pro vytváření webového obsahu
(Pamatujete na Content Management Server? Tady ho máme. Publikační weby pro tvorbu a sdílení webového obsahu s připraveným schvalováním pomocí workflow a „ritch-text“ editací obsahu. Podporuje opět MOSS platforma.) - Vyhledávací portál zpřístupňující data z rozličných datových zdrojů
(MOSS jako celofiremní centrální vyhledávací server indexuje data samotného SharePoint serveru (textové záznamy, ale i dokumenty v dokumentových knihovnách a jejich metadata), dále pak souborové servery, Exchange veřejné složky, Lotus Notes databáze a libovolné interní i externí weby. Zásuvnými moduly typu iFilter lze rozšiřovat schopnosti indexace o další typy souborů, jako jsou např PDF dokumenty apod. Mimochodem v této souvislosti doporučuji iFilter od firmy Foxit Software, ten od Adobe je děsnej.) V dalších dílech se některými výše uvedenými scénáři využití platformy SharePoint seznámíme blížeji. Nyní ale zpět k názvu tohoto článku: SharePoint není pro všechny Není nic horšího, než firma s nasazeným SharePointem, kam za půl roku přijdu a vidím, že to nikdo nepoužívá.
Není nic horšího, než firma s nasazeným SharePointem, kam za půl roku přijdu a vidím, že to všichni používají, ale bez jakékoliv vize a plánu.
Není nic horšího, než SharePoint, který nikdo neřídí a který nikdo nekontroluje.
Není nic horšího, než nasazování SharePointu tzv. „hurá stylem“, tedy bez rozmyslu a bez analýzy procesů a činností.
A není nic horšího, než Basic instalace. (Tedy aspoň někdy.) K SharePointu je třeba dospět! Co tím myslím? Často vídávám na kurzech nebo konzultacích nadšené administrátory či IT manažery, kteří vidí a chápou výhody SharePoint platformy, uvědomují si přínosy, které nasazením SharePointu jejich firma a uživatelé získají a sní o tom, jak snadno a rychle budou moci zavádět a vytvářet nové služby a řešení, usnadňující jejich uživatelům a vlastně i samotným IT pracovníkům práci. Ano, to vše je pravda, tohle umíme, SharePoint je mocný produkt. Jen samotné nadšení pro věc ale nestačí. Samotná technologie toho mnoho nezmění, obvzláště je-li takto komplexní. SharePoint si přímo říká o změnu firemních procesů, nebo spíše o jejich vytvoření, nastavení, optimalizaci a skloubení s jím poskytovanými mocnými nástroji. V opačném případě je přínos malý, či dokonce dojde ke zhoršení stavu. Jednoduše řečeno – kde byl nepořádek před SharePointem, bude i po něm, pokud se nezmění chování uživatelů, pokud nedojde ke sladění procesů a technologií. Není nic horšího, než firma s nasazeným SharePointem, kam za půl roku přijdu a vidím, že to nikdo nepoužívá.
Ano, i to se může stát. Firma koupí licence, nasadí SharePoint a tím to skončí, na další kroky není čas, peníze, chuť, priority jsou jinde, jsme utopeni v každodenních operativních činnostech, dotáhnout to do konce jaksi není kdy... problém především menších firem (nebo že by nejen těch?), kde jsou IT pracovníci zahlceni každodenními činnostmi, bez prostoru na koncepční práci a tvorbu komplexních řešení.
Doporučení: Nestíháte-li pořádně ani běžné činnosti, do SharePointu se nepouštějte. A pokud přeci jen, tak s pomocí externího konzultanta, který vám přinese know how, které byste jinak sami pracně a dlouhodobě získávali. Nestačí jen vědět k čemu je to dobré a jak to funguje, nutné a klíčové je vědět jak to budeme či chceme používat! Není nic horšího, než firma s nasazeným SharePointem, kam za půl roku přijdu a vidím, že to všichni používají, ale bez jakékoliv vize a plánu. Není nic horšího, než SharePoint, který nikdo neřídí, který nikdo nekontroluje. Není nic horšího, než nasazování SharePointu tzv. “hurá stylem”, tedy bez rozmyslu, bez analýzy procesů a činností.
SharePoint a ani žádná jiná sebelepší technologie, toho sám o sobě ve vaší firmě mnoho nezmění! Nemáte zavedené procesy pro tvorbu a sdílení informací? Tedy dokumentů, ale i procesů pro rezervaci zdrojů? A co rozhodovací činnosti, schvalování a workflow? Pak vězte, že po půl roce používání SharePointu bude na vašem portálu podobný nepořádek, nebo spíše ještě větší nepořádek, než na stávajících souborových serverech a datových úložištích.
SharePoint přináší možnosti a prostředky, jak tyto činnosti dělat lépe. Nejsou-li ale zavedena pravidla a neřídí-li se jimi uživatelé (nejen ti koncoví, ale i řídící), pak to nemá smysl!
Doporučení: Proveďte analýzu procesů a činností, zamyslete se nad ideálním způsobem tvorby informací. Popište procesy tvorby dokumentů, sestavte pracovní toky (workflow), řekněte JAK chcete pracovat. Až poté tvořte vaše portály a implementujte potřebné nástroje. Prvotní analýza se opravdu vyplatí! A není nic horšího, než Basic instalace.
Nenechte se nalákat na nejsnazší způsob instalace. Co je snadné, není vždy správné (s principem “Okemovy břitvy” ale souhlasím). Bez pochopení přínosů a slabin jednotlivých způsobů instalace raději ani nespouštějte setup.exe! Následné řešení možných problémů bývá mnohdy složitější, než reinstalace. No a každopádně – náprava stavu bude drahá.
Doporučení: Je-li to jen trochu možné, zvolte vždy „Advanced“ instalaci, nad jejímž procesem máte plnou kontrolu. A přečtěte si postupy a návody, na Netu je k tomuté tématu informací víc než dost. J V této souvislosti bohužel nemohu doporučit SharePoint online instalační videa (dají se i stahovat) dostupná na Microsoft TechNet webu: http://technet.microsoft.com/en-us/office/sharepointserver/dd353225.aspx. Zveřejněná videa o instalaci MOSS jsou bohužel obsahově chybná a tak, jak to jejich autor předvádí, rozhodně MOSS instalovat nedoporučuji. Ostatní videa jsou ale celkem OK. K dispozici je nyní již několik desítek video ukázek věnovaných jak administraci SharePoint prostředí, tak využití z pohledu uživatele. Tolik tedy na úvod. Snad vás výše uvedené řádky zaujaly. Příště si budeme podrobněji „povídat“ o plánování struktury SharePoint portálů a výhodách kolekcí webů a vy zatím „sjíždějte“ ta videa. |
|
|
|
|