Vývoj nad Microsoft Windows SharePoint Services

Transkript

1 Masarykova univerzita, Fakulta informatiky BAKALÁŘSKÁ PRÁCE Vývoj nad Microsoft Windows SharePoint Services 2007 Jan Svoboda

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně, dne Jan Svoboda i

3 Poděkování děkuji panu Mgr. Petru Steinmetzovi za trpělivost a podporu při vedení této práce a panu Mgr. Miloslavu Kvapilovi za poskytnutí technického zázemí pro její realizaci ii

4 Shrnutí Většina firem v dnešní době pracuje s velkým množstvím informací. Mohou to být různé dokumenty, data (například tabulky s informacemi o zboží, obchodních partnerech), ale i informace o postupech a stavech různých procesů, které ve firmě probíhají. Často bývají rozmístěny na mnoha různých místech dokumenty jsou na souborovém serveru, roztříděné do různých složek (v nichž se zpravidla orientuje jen několik málo lidí), informace o zboží a obchodních partnerech jsou v ekonomickém informačním systému, a vnitřní firemní procesy buď neprobíhají vůbec, nebo probíhají na papíře, nebo v nějakém jednoduchém systému vytvořeném na koleně. K dokumentům nejsou v těchto případech uchovávány žádné doplňující informace, podle nichž by bylo možné je třídit, nebo mezi nimi vyhledávat. Nelze nad nimi také spouštět žádné procesy, jako je například schvalování, verzování 1 a podobně. Může být velmi výhodné různé informace propojit, nebo umístit na víceúčelové úložiště, tak, aby se k nim dostal každý, kdo to k plnění svých povinností potřebuje, a aby s nimi mohl rychle a snadno pracovat. Tato práce popisuje možnosti využití Windows SharePoint Services jako prostředí pro realizaci firemních intranetových portálů, které řeší výše zmíněné nedostatky, a popisuje možnosti vývoje vlastních řešení nad touto platformou. Součástí práce je implementace vzorové aplikace Help Desk, která slouží jako vnitřní firemní podpůrný systém pro řešení problémů zaměstnanců (například s informačními technologiemi). 1 Proces, který umožňuje zachovat různé verze téhož dokumentu, jeho koncepty, finální verze a podobně. To umožňuje snadné obnovení starších verzí dokumentů a spolupráci více osob na tvorbě jednoho dokumentu. iii

5 Klíčová slova Intranetový portál, úložiště dat, podpůrný systém, firemní podpůrný systém, informační systém, dokumenty, schvalování dokumentů, řízení obsahu, vývoj intranetu iv

6 Obsah Prohlášení... i Poděkování... ii Shrnutí... iii Klíčová slova... iv 1. Úvod Představení technologie Architektura Windows SharePoint Services Fyzická struktura služby Logická struktura služby Farma Webová aplikace Kolekce webů Rozšiřování systému Řešení Funkce Možnosti vývoje Řešení založená na standardních vlastnostech prostředí Seznamy Pracovní postupy Ostatní Zabezpečení Shrnutí Microsoft Office SharePoint Designer Editor stránek Pracovní postupy Microsoft Visual Studio (2005/2008) Webové části Event Receivery Návrh řešení

7 4.1 Zadání Doménový model Uživatelské role Funkčnost aplikace Zvolené postupy Seznamy Rozhodovací logika přiřazování úkolů Pracovní postupy Zadávání podnětů k řešení Generování a zobrazování sestav Popis řešení Operační prostředí Počítače Active Directory Konfigurace operačního prostředí Aplikační servery Databáze Windows SharePoint Services Instalace vývojových nástrojů Postup implementace Struktura webu Uživatelské role Seznamy Znalostní databáze Formulář pro zadání nového podnětu k řešení problému Logika výběru řešitele Nastavení přístupových práv upravovaných položek Pracovní postup řešení úkolu Sestavy Nasazení komponent do vývojového prostředí Přenos nasazení do provozního prostředí

8 5.4 Testování Závěr Citovaná literatura Přílohy Příloha 1A Architektura Windows SharePoint Services Příloha 2A Doménový model aplikace Help Desk Příloha 5A Vytvoření u pomocí pracovního postupu Příloha 5B Vytvoření úkolu pomocí pracovního postupu Příloha 5C Obsah CD přiloženého k práci

9 1. Úvod V dnešní době je v různých organizacích uchováváno stále větší množství informací, s nimiž je potřeba pracovat. Čím je informací víc, tím obtížnější pro nás je, se v nich orientovat, a najít přesně ty, které pro svoji práci potřebujeme. Řešení, která byla po dlouhá léta plně dostačující, jako například uchovávání dokumentů na souborových serverech, přestávají stačit, v hojné míře se začínají používat schvalovací procesy v elektronické formě, a čím víc se IT dostává do každodenního života zaměstnanců organizace, tím víc jsou potřeba i další podpůrné služby, které mají za úkol zaměstnancům práci s informacemi usnadnit. Jedním z mnoha řešení této situace je technologie Microsoft Windows SharePoint Services (zkráceně WSS), kterou se tato práce zabývá. V první části práce, nazvané Představení technologie se text věnuje základnímu představení technologie Windows SharePoint Services a popisuje její fyzickou a logickou strukturu. V další části nazvané Možnosti vývoje popisuje způsoby, jakými můžeme pro tuto technologii vyvíjet vlastní aplikace. Tyto první dvě části by měly čtenáři stručně nastínit možnosti využití technologie a ukázat mu, co všechno je možno pomocí tohoto řešení realizovat. V částech Návrh řešení a Popis řešení je potom předveden vývoj nad WSS na příkladu jednoduché aplikace Help Desk určené pro podporu uživatelů firemního Intranetu postaveného na této technologii. V části Návrh řešení je provedena stručná analýza požadavků na takový systém a v části Popis řešení je popsán postup vytvoření vhodného vývojového prostředí, postup implementace a způsob vývoje, které jsem pro jednotlivé komponenty aplikace zvolil. Na závěr je shrnutí práce v kapitole Závěr a dále jsou připojeny přílohy, v nichž jsou doplňující informace pro snažší pochopení těch částí práce, u nichž by mohly vzniknout nejasnosti. 4

10 2. Představení technologie Microsoft Windows SharePoint Services je technologie určená k budování firemních intranetových portálů. Tato technologie běží na operačních systémech Windows, a funguje jako služba WWW 2 v serveru Internet Information Services 3. Grafický model komponent tohoto prostředí je v příloze 1A. 2.1 Architektura Windows SharePoint Services Celé Windows SharePoint Services jsou vytvořeny pro operační prostředí Microsoft.NET Framework Mají veřejný a zdokumentovaný objektový model svých datových úložišť a svojí funkčnosti, takže je velmi snadné je s využitím technologie.net Framework rozšířit, jak je zmíněno v následujících kapitolách, věnujících se vývoji. Jako úložiště svých konfiguračních dat, a dat obsahu je použit Microsoft SQL Server ve verzi 2005 nebo 2000 (lze použít všechny edice, od Express až po Enterprise). Během instalace dojde k vytvoření konfigurační databáze, v níž jsou uložena veškerá nastavení farmy. Pro každou webovou aplikaci se vytváří zvláštní databáze obsahu. Jednotlivé služby, jako např. služba vyhledávání v obsahu 5 si vytváří svoje vlastní databáze, do kterých ukládají data specifická pro ně. Pojmy farma a webová aplikace budou vysvětleny v kapitole Fyzická struktura služby Funkční instalace Windows SharePoint Services je rozdělena na 3 základní části: První částí jsou databázové stroje, v nichž jsou uloženy konfigurace a obsah všech služeb. Tyto databázové stroje mohou být rozděleny na několik částí, podle komponent WSS, nebo mohou být v clusteru pro vyvažování zátěže. Druhou částí jsou podpůrné služby. To jsou služby, jako například časovače, které spouští plánované úlohy pro farmu (viz kapitola 2.3.1), vyhledávací služby, služby pro zpracování dat a podobně. Nejsou nikde vidět, pouze provádí svoje úlohy na pozadí. Třetí částí jsou webové servery, ve kterých běží webové aplikace to je grafické uživatelské rozhraní, které slouží uživatelům pro přístup do WSS. 2 World Wide Web Internetová služba poskytující hypertextové dokumenty, v dnešní době hojně využívaná také jako prezentační vrstva pro Internetové aplikace 3 Internet Information Server služba webového serveru, součást Microsoft Windows Server 4.NET Framework je operační prostředí pro programování aplikací pro systémy Microsoft Windows. Jeho součástí je veliká knihovna nejrůznějších hotových komponent, s nimiž může programátor pracovat, a má vlastní runtime prostředí, takže je svým způsobem podobný například filosofii jazyka JAVA, s tím rozdílem, že jeho multiplatformnost se v pojetí firmy Microsoft vztahuje pouze k operačním systémům Windows 5 Obsahem v tomto případě rozumíme libovolný obsah, kterým můžeme Intranetový portál naplnit, například dokumenty, nebo data, která uživatelé vyplňují do formulářů v systému 5

11 2.3 Logická struktura služby Farma Základem každé instalace Windows SharePoint Services je farma. Farma je logické uspořádání všech komponent, které instalace WSS obsahuje. Běží v ní všechny podpůrné služby WSS, i všechny ostatní služby (databázové servery, webové servery, ové servery, atd.) Na farmu můžeme nasazovat a aktivovat rozšiřující řešení a funkce WSS (viz kapitola 2.4). Na jednotlivých webových serverech ve farmě jsou spuštěny webové aplikace Webová aplikace Webová aplikace je součástí farmy, a je to vlastně životní prostor uživatelského rozhraní WSS. K této webové aplikaci je přidělen tzv. application pool to je samostatně běžící proces, s vyhrazeným paměťovým prostorem a svojí identitou v systému (zpravidla je touto identitou nějaký Active Directory 6 účet). V rámci tohoto procesu běží potom celá webová aplikace a vystupuje vůči okolnímu světu pod identitou application poolu. Pokud tedy budeme chtít hledat nějakou hmatatelnou podobu WSS na serveru, měli bychom začít právě u procesu w3wp.exe, který reprezentuje službu webového serveru, v níž běží webová aplikace WSS. Každá webová aplikace má data umístěna ve dvou úložištích. První z nich je přímo v souborovém systému webového serveru. Zde jsou umístěna statická data, která musí být stejná ve všech instancích webového serveru, které fungují jako prezentační vrstva k dané webové aplikaci WSS. Jsou zde tedy umístěny funkční součásti webové aplikace. Druhé úložiště je umístěno v databázovém serveru, který je už pro všechny instance webového serveru společný, a je zde umístěn obsah tedy data, jako např. dokumenty, seznamy, stránky, atd. Každá webová aplikace má na databázovém serveru svoji vlastní databázi obsahu. V rámci webové aplikace WSS můžeme vytvářet kolekce webů Kolekce webů Kolekce webů je samostatný úložný prostor, ve kterém mohou být umístěny weby. Je to tedy jen jakési logické seskupení webů, v nichž se nachází samotný obsah. Na kolekci webů můžeme také nasazovat a aktivovat rozšiřující funkce pro WSS. 2.4 Rozšiřování systému Windows SharePoint Services můžeme rozšiřovat pomocí řešení a funkcí. 6 Active Directory adresářová služba v prostředí sítí Windows Server. Jsou v ní uchovány veškeré informace o účtech uživatelů a struktuře sítě. Windows SharePoint Services ji standardně využívají pro autentizaci i autorizaci uživatelů. 6

12 2.4.1 Řešení Řešení je balíček několika souvisejících funkcí. Je tvořeno jedním souborem, v němž jsou uloženy funkce, které jsou součástmi daného řešení. Na farmu se nasazuje jako celek, a až po jeho nasazení můžeme jednotlivé funkce selektivně aktivovat Funkce Funkce je komponenta rozšiřující WSS. Přenáší se jako součást řešení. Funkce může být určena pro farmu jako celek, nebo pro samostatnou kolekci webů. Jednotlivé funkce mohou mít definované vzájemné závislosti, takže pokud má například nějaký softwarový produkt podporu WSS, a sám je rozdělený na moduly, můžeme zvlášť instalovat funkci pro podporu modulu jádra, a zvlášť jednotlivé funkce pro podporu jednotlivých dalších modulů produktu, tak, aby nebylo možno nainstalovat podporu modulu bez instalované podpory jádra. Každá funkce obsahuje elementy to může být například webová část, ovládací prvek uživatelského rozhraní, definice pracovního postupu, nebo rozšíření obsahu webové aplikace (stránky,dokumenty, šablony webů nebo seznamů, apod.) 7

13 3. Možnosti vývoje Vzhledem k tomu, jak WSS fungují, můžeme pro ně vyvíjet mnoha způsoby. Úplně nejjednodušší variantou je využití vestavěných nástrojů přímo ve WSS. Zde jsou ale možnosti velmi omezené a jde skutečně o jednoduché úpravy. Dalšími dvěma možnostmi je rozšiřování kolekcí webů vlastním obsahem a vkládání vlastních modulů vytvořených v.net do farmy. Přístup k obsahu ve WSS je velmi jednoduchý, protože webové aplikace WSS podporují WebDAV 7 a FrontPage Server Extensions 8. Z klientů tedy můžeme s obsahem ve WSS pracovat jako s běžným souborovým systémem a libovolně ho upravovat. Vhodnějším, a mocnějším nástrojem je ale Office SharePoint Designer 2007, který je zmíněn v kapitole 3.2. Další výše zmíněnou možností je vkládání vlastních.net modulů. Vzhledem k tomu, že celé WSS jsou vytvořeny v.net, a mají veřejný objektový model, můžeme ho bez omezení využívat a pracovat nad ním. Můžeme buď z vlastních programů přistupovat k instancím objektů v SharePointu, nebo můžeme vytvářet vlastní deriváty objektů WSS a vkládat je do SharePointu jako ovládací prvky, pracovní postupy, a mnoho dalších. Podrobněji jsou tyto možnosti vysvětleny v kapitole Řešení založená na standardních vlastnostech prostředí Technologie Windows SharePoint Services sama, bez nutnosti instalace dalších komponent a vývojových nástrojů, umožňuje do určité míry vývoj jednoduchých aplikací postavených na seznamech a relacích mezi seznamy Seznamy Seznamy jsou obdobou tabulky v SQL serveru. Každý seznam je množina sloupců. Každý sloupec reprezentuje datový typ a jsou v něm uchovány informace k danému záznamu. Při definici sloupce máme na výběr z jednoduchých datových typů, které jsou přímo součástí Windows SharePoint Services, ale máme i možnost si doprogramovat vlastní datové typy (včetně jejich prezentační vrstvy v uživatelském rozhraní SharePointu). Mezi jednotlivými seznamy můžeme tvořit také relace. Relaci vytvoříme tak, že jako datový typ jednoho ze sloupců seznamu vybereme odkaz na položku v jiném seznamu. Ten navíc umí odkazovat na více, než jednu položku a díky tomu můžeme tvořit nejen relace 1:1, ale i relace 1:N a M:N. 7 WebDAV HTTP Extensions for Web Distributed Authoring and Versioning rozšíření protokolu HTTP o možnosti hromadného upravování a správy souborů na webovém serveru. Se soubory na webovém serveru tak můžeme pracovat podobně, jako se soubory na místním souborovém systému. Toto rozšíření je popsáno normou RFC Technologie velmi podobná standardu WebDAV s rozšiřujícími funkcemi, jako je například on-line schvalování a verzování obsahu. 8

14 Na každém seznamu můžeme navíc nastavit schvalování položek (neplést si s pracovním postupem schvalování, jsou to různé věci). Seznamy ve WSS mohou být několika typů. Základním typem, z něhož se jsou zděděny všechny ostatní je obecný seznam, bez rozšiřujících vlastností. Tento obecný seznam umožňuje uchovávat data ve sloupcích. Každý další typ je rozšířením obecného seznamu. Může to být například knihovna dokumentů (to je seznam, který navíc pro každou svoji položku uchovává nějaký dokument určitého typu jeho chování v grafickém uživatelském rozhraní je potom uzpůsobeno tomu, že uchovává dokumenty), seznam úkolů (obdobně jako seznam dokumentů uchovává dokumenty, seznam úkolů uchovává úkoly a k nim informace o stavu splnění apod.) nebo například kalendář (ten funguje jako seznam položek v kalendáři, a v grafickém uživatelském rozhraní se zobrazuje jako obyčejný kalendář). Se všemi těmito seznamy můžeme pracovat z klientských aplikací Microsoft Office, ve většině případů tyto aplikace podporují i rozšířenou funkčnost seznamů (tak, že úkoly a kalendář se v klientské aplikaci chovají jako úkoly a kalendář) Pracovní postupy Pracovní postupy jsou jasně definované postupy, jako je například schvalování, připomínkování, doplňování a upravování informací, a mnoho dalších, které probíhají nad daty v úložišti dat. Windows SharePoint Services mají předdefinovány jednoduché pracovní postupy pro schvalování dokumentů a připomínkování obsahu. Tyto pracovní postupy můžeme využít v případech, kdy známe předem schvalovatele dokumentů (neurčují se dynamicky například na základě organizační struktury, nepřítomností a podobně není potřeba programovat rozhodovací logiku), případně kdy si sám uživatel může vybrat, kdo mu dokument schválí. V komplikovanějších případech je nutné vytvořit si (naprogramovat) vlastní pracovní postup Ostatní Kromě seznamů a pracovních postupů můžeme vytvářet například jednoduché sestavy pomocí aplikování XSLT transformací 9 na datové zdroje vytvořené ze seznamů apod. Vzhledem ke složitosti takových definic je ale v tomto případě výhodnější použít Office SharePoint Designer, který definice vygeneruje v přehledném uživatelském rozhraní Zabezpečení Na každém objektu ve WSS (kolekce webů, weby, seznamy, položky v seznamech) můžeme nastavovat podrobná přístupová práva. Můžeme tedy přidělit přístup k nějakému webu jen určité skupině uživatel, a k jednotlivým položkám na tomto webu přístupy ještě omezit. Tím můžeme dosáhnout například toho, že každý položky vidí, ale jen určitá skupina uživatelů je 9 Popis pravidel, která umožňují transformovat XML dokument přesně definované struktury na libovolný jiný dokument, obvykle v čitelné formě (prostý text, HTML dokument, apod.) 9

15 může upravovat. Případně každý může položku přidat, ale její zveřejnění podléhá schvalovacímu procesu. Zabezpečení ve WSS můžeme nastavovat na objekty v Active Directory (uživatelské účty a skupiny), nebo na skupiny WSS, jejímiž členy mohou být objekty Active Directory. Kromě oprávnění je možné provádět i audit přístupů. WSS umožňují pořizování a uchovávání informací o tom, kdo s jakým dokumentem pracoval, a případně i to, kdo si dokument prohlížel. To se zase může hodit v případě uchovávání důvěrných dokumentů Shrnutí Už s nainstalovanými WSS můžeme tedy tvořit velmi jednoduché webové aplikace, které potom, pomocí pokročilejších vývojových nástrojů můžeme rozšiřovat o další funkčnost. Můžeme vytvořit úložiště dokumentů s mnoha nadstandardními funkcemi, jako je verzování a schvalování obsahu, řízení přístupových práv bez nutnosti vytváření skupin v Active Directory apod. Můžeme vytvořit i jednoduchý informační systém založený na seznamech a relacích mezi nimi (v mnoha případech to stačí). Ve struktuře kolekce webů můžeme dokonce do určité míry okopírovat organizační strukturu, a využít ji jako úložiště pro kalendáře, seznamy úkolů a jednoduché řízení jednotlivých organizačních útvarů, nebo oddělení. Jakákoli vyspělejší funkčnost, jako například složitější pracovní postupy, nebo vlastní rozhodovací inteligence při různých operacích (uložení dokumentu, výběr schvalovatele, kontrola příloh) už ale musí být realizována pomocí pokročilejších nástrojů. Ty jsou zmíněny v následujících kapitolách. 3.2 Microsoft Office SharePoint Designer 2007 Office SharePoint Designer 2007 je aplikace z rodiny Microsoft Office Ve skutečnosti je to nástupce programu FrontPage, což byl původně editor HTML kódu, určený pro tvorbu webů. Co ale už není úplně běžně známým faktem, postupem času se začal orientovat čím dál více na Windows SharePoint Services, až ve verzi Office 2007 došlo i ke změně jeho názvu. Tento program mimo zmíněné úpravy ASPX 10 stránek ve WSS umožňuje pracovat se seznamy jako s datovými zdroji, vytvářet XSLT transformace pro generování sestav, a generovat jednoduché pracovní postupy z předdefinovaných pravidel a akcí Editor stránek Můžeme ho tedy využít například k vložení vlastní stránky do kolekce webů. Můžeme ale upravovat i existující stránky, jako jsou standardní předdefinované formuláře pro zobrazování nebo upravování položek v seznamech. 10 Dynamicky generované webové stránky, vytvořené ve frameworku pro webové aplikace ASP.NET. To je rozšíření technologie ASP o programovatelnost pomocí frameworku.net. 10

16 Není to však pouze HTML editor, umožňuje pracovat i s ASPX kódem, takže můžeme do stránek vkládat webové části, a do určité míry můžeme ve stránkách i programovat Pracovní postupy Office SharePoint Designer můžeme využít pro vytváření jednoduchých pracovních postupů, které jsou složeny z předem připravených podmínek a jednoduchých akcí. Díky tomu můžeme například přidělit úkol nějaké osobě a na základě výsledku průběhu úkolu (vyplnění formuláře, atd.) řídit pracovní postup dál změnou stavu schválení na položce, dalším úkolem, a podobně. 3.3 Microsoft Visual Studio (2005/2008) Další možností, jak vyvíjet pro WSS je programování v.net. Vzhledem k tomu, že celé WSS běží v.net Frameworku, a objektový model WSS je veřejný, můžeme pro ně naprogramovat téměř cokoli, od jednoduchých komponent rozšiřujících jeho grafické uživatelské rozhraní, až po komponenty ovlivňující chování systému uvnitř programované akce prováděné při operacích nad daty v úložišti a podobně. Pomocí tohoto nástroje už můžeme WSS přizpůsobit prakticky bez omezení, záleží pouze na naší fantazii a schopnostech. S využitím objektového modelu WSS můžeme přistupovat k datům obsahu, můžeme nahrazovat nebo doplňovat komponenty systému vlastními, vytvářet pracovní postupy, ovládací prvky uživatelského rozhraní, nebo celé stránky, či weby jako hotové aplikace umístěné v prostředí WSS. Můžeme také WSS použít jen jako rozhraní do úplně jiné aplikace. V následujících částech nastíním několik nejčastějších případů využití Visual Studia pro vývoj nad WSS. Výstupem každého takového vývoje ve Visual Studiu je knihovna, která obsahuje jednu, nebo více tříd prostředí.net. Některé z těchto tříd jsou zděděny z tříd v objektovém modelu WSS a obsahují vlastní kód, který provádí nějaké operace. Při nasazení tohoto řešení do WSS se daná knihovna vloží do Global Assembly Cache 11 na serveru, a v datech WSS se nastaví vazby na knihovnu a její třídu. Pomocí těchto vazeb potom WSS vědí, kam se mají odkazovat a co mají provést při vyvolání akce nebo události Webové části Webová část je funkční součástí technologie ASP.NET. V principu je webová část fragment HTML kódu, který je možné opakovaně vložit na libovolné místo v ASPX stránce jako součást uživatelského rozhraní. WSS umožňují využívat standardní webové části ASPX, ale mají i svoje vlastní, rozšířené o jejich funkčnost. Nejjednodušším případem vývoje komponent WSS ve Visual Studiu je webová část. Z pohledu programátora.net je to třída děděná z třídy SharePoint.WebPartPages.WebPart (nebo můžeme použít obecnější System.Web.UI.WebControls.WebParts.WebPart, která je přímo 11 Global Assembly Cache (zkráceně GAC) - Sdílené úložiště.net Framework v operačním systému, kde jsou uchovávány knihovny, které jsou použitelné libovolnou spuštěnou aplikací. 11

17 součástí ASP.NET někteří tvrdí, že toto řešení je lepší, protože je univerzálnější to ale nemusí být nutně pravda, protože pokud pracujeme v prostředí nativní třídy SharePointu, máme lepší a přímější přístup do jeho objektového modelu). Tato třída obsahuje několik pro nás důležitých metod pro vykreslení obsahu. Při vytváření webové části máme dvě možnosti. Třída WebPart funguje jako webový ovládací prvek, který může mít podřízené ovládací prvky. Buď tedy naplníme WebPart vlastními ovládacími prvky, nebo nahradíme jeho vykreslovací metodu svojí vlastní a generujeme přímo HTML kód. V obou případech je výsledkem blok HTML kódu, který můžeme jako celek webová část vložit kamkoli do stránek ve WSS Event Receivery Velmi užitečnou komponentou, kterou můžeme pro WSS vyvinout je Event Receiver to je vlastní operace, jejíž spuštění můžeme navázat na nějakou událost, která ve WSS probíhá. Tyto události jsou vyvolány vždy při provedení operace nad seznamem, nebo položkou v seznamu. U každého seznamu jsou nastaveny vazby na jednotlivé Event Receivery, což jsou třídy děděné z třídy Microsoft.SharePoint.SPListEventReceiver v případě seznamu, a v případě položky v seznamu z třídy Microsoft.SharePoint.SPItemEventReceiver. Každá z těchto tříd obsahuje několik metod, které určují druh operace, která se nad položkou provádí a volají se buď synchronně (v průběhu operace) nebo asynchronně (po dokončení operace). Zde pouze nahradíme kód dané metody svým vlastním. Vzhledem k tomu, že se nacházíme v třídě WSS, máme přístup k celému objektovému modelu, k seznamu a případně i položce seznamu, nad nimiž byla událost vyvolána a můžeme s nimi pracovat. Můžeme tedy, v případě synchronní operace například zastavit její průběh nebo, v případě asynchronní operace, změnit obsah položky a podobně. 12

18 4. Návrh řešení Poznatky získané v minulé kapitole, vhodné postupy a metodiky řešení problémů předvedu na realizaci jednoduché aplikace Help Desk. 4.1 Zadání Mým úkolem je vytvořit jednoduchou aplikaci Help Desk, do které mohou uživatelé informačního systému zadávat podněty k řešení problémů. U každého takového problému uvede uživatel jeho závažnost, prioritu řešení a zařízení, jehož se problém týká. V tomto případě půjde o technické vybavení kanceláří, ale s drobnými úpravami by bylo možné tuto aplikaci využít například i pro firemní vozový park, nebo pro libovolný jiný systém požadavků v organizaci. Pro realizaci této aplikace jsem si vytvořil stručnou analýzu, v níž je popis datových struktur, uživatelských rolí, možností využívání a základní funkčnosti aplikace. Pro aplikaci bude vytvořena ve webové aplikaci samostatná kolekce webů. Díky tomu bude možno aplikaci jako celek zálohovat a případně přenést do jiného umístění. Zároveň je tím zabezpečena izolace od ostatních aplikací umístěných ve webové aplikaci WSS, a tím i zjednodušené a zprůhledněné nastavení práv a zabezpečení Doménový model V této části je popis datových struktur, na nichž je aplikace Help Desk postavena. Grafické znázornění doménového modelu je v příloze 2A Typ zařízení Abychom mohli hlásit problémy s nějakým zařízením, je vhodné si zařízení rozdělit na několik typů. Každý řešitel se může specializovat na konkrétní druh zařízení (počítač, tiskárna, server) a pomocí takového rozdělení můžeme značně zjednodušit rozhodování při přidělování úkolů řešitelům, nebo jej dokonce plně automatizovat Zařízení Položka Zařízení určuje konkrétní instanci zařízení v provozním prostředí aplikace. To může být například počítač, na kterém se vyskytla závada a uživatel chce zadat požadavek na její řešení. Seznam by měl být v úvodu naplněn všemi zařízeními, u kterých může dojít k problému, mezi požadavky jsem však zařadil i tu možnost, aby si uživatel mohl přidat zařízení sám, vzhledem k udržení pořádku v seznamu musí ovšem toto přidání podléhat schvalovacímu procesu Priorita řešení problému U každého problému se zadává priorita řešení problému. Ta udává přibližný údaj o tom, jak rychle je potřeba problém vyřešit. Na základě tohoto údaje si potom řešitel problémy může seřadit a věnovat se přednostně těm, které mají vysokou prioritu. 13

19 Závažnost problému Závažnost problému říká, jak moc je daný problém závažný. Je to doplňující údaj k prioritě, a můžeme pomocí něho rozlišit například problémy, které brání uživateli ve výkonu jeho práce a návrhy na zlepšení Problém Seznam problémů, které zadávají uživatelé jako podněty k řešení. U každého takového podnětu musí uživatel povinně zadat prioritu řešení, závažnost a zařízení, na kterém problém nastal. Nepovinně může vyplnit preferovaného řešitele, a pokud tak neučiní, systém vybere řešitele sám. Do tohoto procesu může zasáhnout uživatel v roli vedoucí řešitelů. U každého problému evidujeme také jeho stav. To je informace o tom, jak probíhá řešení daného problému. Při vytvoření nového záznamu se automaticky tento stav nastaví na hodnotu NOVÝ Uživatelské role Každý uživatel informačního systému je zařazen do uživatelské role. Tato role má vliv na to, do kterých částí systému má uživatel přístup, a jaké operace může provádět. V tomto případě budu definovat jednotlivé uživatelské role pomocí uživatelských skupin WSS, a do nich zařazovat objekty Active Directory (celé skupiny, nebo přímo konkrétní uživatele). Díky tomu bude možné přenést celou logiku autorizace uživatelů i do jiné struktury Active Directory bez narušení její funkčnosti bude stačit znovu naplnit jednotlivé WSS skupiny uživateli a skupinami. 14

20 Diagram uživatelských rolí je vidět na následujícím obrázku: Uživatel Uživatel je nejnižší role v aplikaci Help Desk. Každý uživatel v této roli může zadávat problémy k řešení. Má povoleno vytvářet nové záznamy v seznamu problémů, a může vytvářet i nové záznamy v seznamu zařízení. Pokud ale přidá záznam do seznamu zařízení, musí tento záznam někdo v roli Řešitel, nebo Vedoucí řešitelů schválit do té doby ho vidí pouze on sám, a uživatelé oprávnění schvalovat nové položky Řešitel Uživatelům v roli Řešitel jsou přidělovány problémy k řešení. Každý takový uživatel má proti roli Uživatel navíc možnost zapisovat do záznamů problémů, které jsou mu přiděleny a právo schvalovat nové položky v seznamu Zařízení. Navíc může zakládat nové položky v seznamu Typy zařízení, které ovšem podléhají schvalovacímu procesu, stejně jako Zařízení, s tím rozdílem, že schvalovat je může pouze Vedoucí řešitelů. 15

21 Vedoucí řešitelů Vedoucí řešitelů vystupuje v aplikaci jako Řešitel, který má navíc možnost zasahovat do záznamů Problémů všech ostatních řešitelů a může přerozdělovat přiřazení úkolů Administrátor Nejvyšší role v aplikaci. Neplatí pro ni žádná omezení, je správcem celé kolekce webů, v níž je aplikace umístěna Funkčnost aplikace V této části je podrobný popis operací, které v aplikaci Help Desk můžeme provádět, a sled akcí, které při provádění těchto operací probíhají uvnitř hostujícího systému Evidence uživatelů V aplikaci jsou evidováni uživatelé a jejich přiřazení do rolí. Role určují přístupy k součástem aplikace a opravňují uživatele k provádění různých operací Evidence zařízení a typů zařízení Aplikace eviduje typy zařízení a jednotlivé instance zařízení tak, jak je to zmíněno v doménovém modelu. Každý uživatel může přidat zařízení, pokud již v systému není, ale přidání takového zařízení podléhá schválení některým z uživatelů v rolu Řešitel. Totéž platí o seznamu typů zařízení, s tím rozdílem, že přidávat záznamy může pouze Řešitel a schvalovat je může pouze Vedoucí řešitelů Evidence priorit a závažností problémů Pro určení priorit a závažností problémů jsou v aplikaci dva patřičně pojmenované seznamy. Tyto seznamy fungují jako pevně dané číselníky, to znamená, že žádná uživatelská role mimo Administrátora nemá možnost do nich jakýmkoli způsobem zasahovat Evidence problémů Nové podněty k řešení problémů může zadávat libovolný uživatel aplikace. Systém po zadání nového problému pomocí své rozhodovací logiky určí vhodného řešitele problému v případě, že si uživatel nevybere řešitele sám. K tomu může sloužit například informace o výchozím řešiteli problémů u jednotlivých typů zařízení. Po zadání nového podnětu k řešení problému a určení řešitele se nastaví přístupy k danému záznamu problému tak, aby jej mohl upravovat pouze uživatel, který je uveden jako řešitel, všichni vedoucí řešitelů a zadavatel položky, ostatní uživatelé buď záznam neuvidí vůbec, nebo ho budou moci pouze číst. Poté se spustí pracovní postup, který vytvoří řešiteli úkol v seznamu úkolů. Při zadávání nového podnětu by měl být uživatel poučen o tom, jak formulář vyplnit a že se má pokusit co nejpřesněji specifikovat problém, aby usnadnil řešiteli práci a tím urychlil vyřešení problému. 16

22 Řešení problémů Po vytvoření podnětu k řešení problému je problém ve stavu NOVÝ. V momentě, kdy se Řešitel pustí do řešení problému, změní informaci o stavu na hodnotu ŘEŠÍ SE. V případě, že musí řešení problému přerušit, a odložit, změní informaci o stavu na hodnotu ODLOŽENO. Až s řešením úkolu skončí, změní informaci na hodnotu HOTOVO. Po takovém uzavření úkolu ještě nastaví informaci o výsledku řešení úkolu to by měl být číselník, který dává na výběr tyto hodnoty: VYŘEŠENO, NELZE VYŘEŠIT, DUPLICITNÍ ZADÁNÍ. Kdykoli v průběhu řešení problému a při jeho uzavírání může řešitel přenést přidělení řešení úkolu na jiného uživatele a připsat k průběhu řešení komentář, v němž informuje uživatele o průběhu řešení problému, případně o výsledku, nebo důvodu, proč problém nevyřešil Znalostní databáze V aplikaci může být umístěna také tzv. znalostní databáze. Ta je vhodná v případech, kdy se nějaký problém často opakuje, a bylo by možné ho vyřešit vhodným informováním uživatelů. Ve znalostní databázi jsou uchovávány časté dotazy uživatelů a odpovědi na ně (mohou je spravovat Řešitelé, nebo Vedoucí řešitelů). Při zadávání nového problému může být potom uživatel upozorněn i na existenci znalostní databáze, a na to, že by se do ní měl nejprve podívat, a až potom, když v ní nenajde řešení, zadat nový podnět Výstupy a sestavy Na hlavní obrazovce (v případě webové aplikace je to úvodní stránka) aplikace je vhodné umístit stručné shrnutí informací o průběhu řešení problémů. Díky těmto informacím si vedoucí pracovníci mohou udělat představu o tom, jak je tým vytížen, jestli nedochází ke zbytečným prostojům v řešení a podobně. Dále je vhodné udělat podrobnější sestavy někde mimo, ve zvláštním, odděleném prostoru, který je přístupný pouze vedoucím pracovníkům (v roli Vedoucí řešitelů). 4.2 Zvolené postupy Seznamy Pro realizaci seznamů budu využívat vestavěných funkcí WSS vytvořím obecné seznamy a v nich sloupce, podle zadání. Na těchto seznamech nastavím vhodná přístupová oprávnění. V případě seznamu Problémů ale funkčnost, kterou nabízí WSS standardně nedostačuje, protože je potřeba nastavovat přístupová oprávnění přímo na položkách seznamu, a to automaticky. V tomto případě vyvinu vlastní Event Receiver, který při každé změně položky (včetně vytvoření) nastaví přístupy tak, jak je řečeno v zadání. Na seznamech Zařízení a Typů zařízení využiji možnosti schvalování položek seznamu. To je standardní vlastnost WSS a stačí ji pouze zapnout a vhodně nakonfigurovat. 17

23 4.2.2 Rozhodovací logika přiřazování úkolů Každému novému podnětu k řešení problému je třeba přiřadit řešitele. V zadání je řečeno, že řešitelem je ten, koho vybere zadavatel, a v případě, že zadavatel nikoho nevybere, aplikace určí vhodného řešitele na základě informací u typu zařízení. Pro tuto operaci vyvinu opět vlastní Event Receiver, který se spustí po provedení operace zmíněné v kapitole Pracovní postupy V aplikaci Help Desk bude jeden pracovní postup. Ten se bude spouštět po vytvoření nového podnětu k řešení problému, a po nastavení přístupových práv a přiřazení řešitele. Tomuto řešiteli pracovní postup vytvoří úkol v seznamu úkolů. Všichni řešitelé potom mohou mít ve svém klientském SW připojen seznam přiřazených úkolů a tím pádem budou neustále informování o tom, co mají dělat. Po splnění úkolu řešitelem se podnět k řešení uzavře a tím pracovní postup skončí. Pro vytvoření tohoto pracovního postupu využiji Office SharePoint Designer, a postup nastavím tak, aby se spouštěl po provedení operací z kapitol a Zadávání podnětů k řešení Pro všechny seznamy se použije pro zadávání nových položek a úpravy stávajících položek standardní formulář. Výjimkou je zadání nového podnětu k řešení, kde bude formulář upraven tak, aby uživatele informoval o existenci Znalostní databáze a upozornil ho na to, že je nutné problém popsat co možná nejpřesněji, aby tím maximálně řešiteli usnadnil práci, což urychlí odstranění problému Generování a zobrazování sestav Sestavy budu generovat pomocí datových zdrojů nad existujícími seznamy. Pro generování použiji XSLT transformace vytvořené v aplikaci Office SharePoint Designer. Sestavy budou zobrazovány jako samostatné stránky v případě samostatných, podrobnějších sestav, a jako webové části, které bude možné vložit kamkoli do uživatelského rozhraní aplikace v případě jednoduchých informativních sestav. 18

24 5. Popis řešení V této kapitole naleznete celý postup realizace, od vytvoření vývojového prostředí a jeho správného nastavení, až po samotnou implementaci aplikace Help Desk. 5.1 Operační prostředí Pro vytvoření operačního prostředí jsem zvolil platformu VMWare Server pro provoz virtuálních počítačů. Díky tomu jsem si mohl vytvořit servery a pracovní stanice podle potřeby, bez nutnosti se omezovat tím, kolik mám k dispozici fyzického hardware Počítače Vzhledem k tomu, že tato aplikace je vytvořena výhradně pro účely demonstrace možností vývoje nad Windows SharePoint Services, nepočítá se s větší než malou zátěží ze strany uživatelů a proto stačí pro všechny služby farmy jeden aplikační server. Operační prostředí jsem proto sestavil podle následujícího obrázku: V operačním prostředí se nachází tři servery a jedna referenční pracovní stanice. Server DC je v roli doménového řadiče Active Directory. Servery APP a DEVEL jsou aplikační servery Windows SharePoint Services. Server APP reprezentuje provozní prostředí, tedy prostředí, ve kterém je nasazena provozní verze aplikace a jsou na něm provozní data. Server DEVEL reprezentuje vývojové prostředí, data na něm jsou výhradně testovací, a může na něm 19

25 být nainstalována verze aplikace ve vývoji. Navíc jsou na serveru DEVEL nainstalovány všechny potřebné vývojové nástroje (Visual Studio, Office SharePoint Designer a rozšíření Visual Studia o šablony projektů pro WSS toto rozšíření není nezbytně nutné, ale velmi výrazně usnadní práci při vytváření nových projektů a automatizaci nasazení a ladění). Počítač CLIENT1 reprezentuje běžnou pracovní stanici v organizaci, je na něm nainstalován klientský operační systém a klientské aplikace (v tomto případě Internet Explorer, který je součástí Windows, a Office 2007) Active Directory Windows SharePoint Services jsou navrženy tak, aby fungovaly v prostředí Active Directory. Pomocí vlastností Active Directory můžeme řídit veškeré přístupy k jednotlivým aplikacím a nemusíme proto zakládat přímo ve WSS uživatelům účty. Na serveru DC jsem tedy po instalaci vytvořil Active Directory doménu nazvanou bp.local (NetBIOS názvem BP) a všechny ostatní počítače do ní přidal. V doméně jsem vytvořil službám účty podle následující tabulky: Název účtu Popis BP\SP_Core Účet pro jádro WSS (konfigurační webová aplikace + systémové služby) BP\SP_Search Identita služby pro vyhledávání ve WSS BP\SP_SearchDB Účet, pod nímž služba vyhledávání sbírá data BP\SP_App Identita webové aplikace, ve které běží Help Desk Konfigurace operačního prostředí Aby se uživatelé mohli k serveru přihlašovat se zachováním určitého komfortu, vytvořil jsem v doméně bp.local DNS záznamy, které ukazují na jednotlivé aplikační servery. Pro provozní webovou aplikaci jsem vytvořil název sp.bp.local a pro vývojovou aplikaci název spdevel.bp.local. Pro to, aby se prohlížeč na klientské straně k webu přihlásil sám tedy aby použil údaje uživatele automaticky, místo toho, aby se na ně ptal při každém otevření prohlížeče, nastavil jsem v Internet Exploreru všechny adresy související s WSS do zóny Místní internet. To je bezpečnostní vlastnost prohlížeče, která zajišťuje, aby údaje uživatele nemohly být odeslány na nedůvěryhodný server. 5.2 Aplikační servery Jak jsem již zmínil v předchozí kapitole, všechny služby aplikačních serverů jsou nainstalovány na jednom počítači. Instalace je provedena dvakrát, jednou pro účely vývoje, a jednou pro provozní prostředí. V obou případech je způsob instalace úplně stejný, ale ve vývojovém prostředí jsou navíc nainstalovány potřebné vývojové nástroje. 20

26 5.2.1 Databáze Jako databázový stroj je použit Microsoft SQL Server 2005 Standard. Z celého produktu SQL Server jsou nainstalovány pouze komponenty databázových služeb, a klientské komponenty včetně základních nástrojů pro konfiguraci databází, nic víc není pro běh WSS potřeba. Z bezpečnostních důvodů byl při instalaci databázový server nastaven tak, aby se uživatelé mohli autentizovat pouze pomocí účtů Active Directory. Jako výchozí collation 12 bylo v nastaveno Latin1 General case insensitive, accent sensitive, kana sensitive, width sensitive to vyžadují WSS pro úspěšnou instalaci. Databázové servery byly instalovány jako výchozí instance 13 na obou počítačích, můžeme se na ně tedy odkazovat názvy APP a DEVEL Windows SharePoint Services Samotná instalace Windows SharePoint Services je velmi jednoduchá. Stačí zvolit způsob instalace (jestli se WSS instalují jako webové uživatelské rozhraní, nebo samostatně) a cestu, kam si WSS budou ukládat své datové soubory. V tomto případě jsem službu instaloval jako webové uživatelské rozhraní (umožní nainstalovat všechny služby, ale konfigurují se ručně) na vývojový, i na provozní server zvlášť. Samotná instalace ještě žádnou službu nespouští, pouze nainstaluje do operačního systému potřebné knihovny, a nachystá operační prostředí tak, aby bylo možné WSS spustit a nakonfigurovat. Po instalaci jsem tedy musel vytvořit farmu WSS, ve které běží rozhraní pro konfiguraci a základní služby, jako například plánované spouštění úloh. Pomocí průvodce konfigurací Windows SharePoint Services jsem na obou serverech (vývojovém i provozním) vytvořil novou farmu, a konfigurační databázi jsem umístil pro každou farmu na vlastní databázový server. Je vhodné zachovat rozumnou konvenci pojmenování databází, v tomto případě jsem použil jako prefix pro názvy databází řetězec SharePoint konfigurační databázi jsem tedy pojmenoval SharePoint_Config. Pro běh služby je navíc potřeba samostatný účet (z bezpečnostních důvodů je vhodné vytvořit neprivilegovaný účet v Active Directory), pro tyto účely jsem vytvořil účet BP\SP_Core. Vzhledem k tomu, že výchozím portem pro protokol HTTP, na kterém jsou běžně provozovány webové služby, je port 80, nechal jsem tento volný pro provoz samotných aplikací, a rozhraní pro konfiguraci jsem umístil na port 81. Autentizaci jsem nastavil na protokol NTLM 14, protože jeho použití je podstatně jednodušší než u protokolu Kerberos a pro účely této práce je plně dostačující. 12 Collation je soubor pravidel v SQL serveru, která určují abecední řazení znaků pro jednotlivá kódování jeho nastavením ovlivňujeme chování SQL serveru při abecedním řazení řetězců v datech 13 Na každém počítači může být nainstalováno několik instancí Microsoft SQL Serveru, z nichž jedna může být výchozí (nepojmenovaná) a všechny ostatní musí mít jedinečný název. Ve formě SERVER, resp. SERVER\INSTANCE se potom můžeme na databázové servery odkazovat. 14 NTLM (NT Lan Manager) je autentizační protokol firmy Microsoft, standardně používaný v systémech Windows. 21

27 Po dokončení průvodce se spustí v operačním systému důležité služby pro běh WSS, a ve webovém serveru se vytvoří nová webová aplikace. Tato webová aplikace slouží pro konfiguraci celé farmy WSS, a kdykoli budeme chtít v budoucnu provést nějaké nastavení, budeme to dělat právě přes toto rozhraní Spuštění služeb V rozhraní pro konfiguraci lze v menu Provoz -> Topologie a služby -> Služby na serveru najít seznam služeb, které jsou pro běh farmy vyžadovány, a také informace o jejich stavu. Výchozí stav po instalaci Windows SharePoint Services je takový, že jsou spuštěny všechny důležité služby kromě Hledání služby Windows SharePoint Services. Tato služba průběžně pořizuje informace o obsahu webů WSS, a při vyhledávání je potom poskytuje uživatelům. Po instalaci není spuštěna proto, že před prvním spuštěním vyžaduje konfiguraci. V tomto případě je potřeba nastavit název databáze, do které si služba ukládá svá data, ten jsem podle výše zmíněné jmenné konvence nastavil na SharePoint_Search. Dále služba vyžaduje dva účty, pod kterými k datům přistupuje. Pomocí prvního z nich přistupuje ke své databázi, a pomocí druhého k datům obsahu. Druhý účet musí mít přístup ke všem datům, ve kterých chceme vyhledávat, ale stačí přístup pouze pro čtení. Je tedy vhodné tyto účty oddělit. Pro službu jsem v Active Directory vytvořil účty BP\SP_Search a BP\SP_SearchDB Vytvoření webových aplikací a kolekcí webů Po zprovoznění farmy WSS jsem vytvořil pro každý server webovou aplikaci. Na serveru APP to byla aplikace na hostname sp.bp.local a na serveru DEVEL to byla aplikace spdevel.bp.local. V každé z těchto webových aplikací jsem vytvořil prázdnou kolekci webů (ze šablony Týmový web, ale to není v tomto případě důležité, protože pro aplikaci Help Desk je vytvořena samostatná kolekce webů). 22

28 5.2.3 Instalace vývojových nástrojů Na server DEVEL jsem navíc nainstaloval tyto vývojové nástroje: Visual Studio 2005 Professional, Office SharePoint Designer a Visual Studio 2005 Extensions for Windows SharePoint Services. 5.3 Postup implementace Celou implementaci jsem nejdříve prováděl ve vývojovém prostředí. Až po dokončení jsem přenesl hotovou aplikaci do provozního prostředí. Pro vývoj jsem na serveru spdevel.bp.local vytvořil prázdnou kolekci webů na adrese Horní panel odkazů kořenové kolekce webů, i kolekce webů aplikace jsem upravil tak, aby bylo pro uživatele snadné a přehledné se mezi těmito dvěma přepínat. Veškeré úpravy, které budou v následujícím textu zmíněny, se vztahují ke kolekci webů vyhrazené pro aplikaci Help Desk, a nebudu ji proto dále zmiňovat Struktura webu Celou implementaci jsem začal přizpůsobením struktury webu. V kolekci webů aplikace jsem proto odstranil vše, kromě prázdné úvodní stránky Uživatelské role Pro řízení přístupu bylo potřeba vytvořit definice, které reprezentují uživatelské role aplikace. Jak jsem již zmínil v zadání, použil jsem pro definici těchto rolí skupiny WSS. Vymazal jsem tedy výchozí definice skupin, které byly u kolekce webů automaticky vygenerovány při vytvoření a nahradil je svými skupinami Administrátoři, Uživatelé, Vedoucí řešitelů a Řešitelé. Do skupiny Administrátoři jsem vložil uživatelský účet, pod kterým pracuji na vývoji aplikace. 23

29 Na kolekci webů jsem pro skupinu Administrátoři nastavil oprávnění Úplné řízení, a pro všechny ostatní skupiny oprávnění Čtení. Tím jsem zajistil to, aby administrátoři mohli zasahovat do všeho a všichni ostatní uživatelé měli k webu přístup, ale nemohli dělat žádné změny. Tam, kde bude potřeba toto chování změnit, nastavím explicitně jiná oprávnění na konkrétních místech (seznamech apod.) Seznamy Přímo v kořenu kolekce webů jsem podle objektového modelu v zadání vytvořil všechny seznamy a nastavil na nich patřičná oprávnění. V tomto případě byla implementace velmi jednoduchá, stačilo nastavit intuitivně oprávnění a pravidla podle zadání. Jednotlivým uživatelským rolím jsem nastavil přístupy a na seznamech Typy zařízení a Zařízení jsem zapnul schvalování obsahu (role schvalovatelů se v tomto případě nastavuje pomocí přístupových práv) Znalostní databáze K vytvoření znalostní databáze jsem využil dva druhy seznamů, které WSS nabízí. Tím prvním je Diskuzní vývěska to je jednoduchá webová diskuze, do které mohou uživatelé přispívat svými dotazy, ostatní mohou na jejich dotazy reagovat, a radit jim, jak řešit problémy. Druhým seznamem je Knihovna stránek wikiwebu 15. Sem mají uživatelé v roli Uživatel přístup pouze pro 15 Klasická wiki site, tak jak ji známe například z projektu wikipedia. Je to knihovna dokumentů, které může určitá skupina uživatelů upravovat, a na venek se chovají jako soustava webových stránek, tak aby jako celek působily jako webová encyklopedie 24

30 čtení, a všichni Řešitelé a Vedoucí řešitelů sem mohou publikovat články o obvyklých problémech a jejich řešení. Podněty pro ně mohou čerpat například z řešených problémů, diskuze, nebo z vlastních zkušeností Formulář pro zadání nového podnětu k řešení problému Formuláře pro zobrazování, úpravu a vkládání položek vytváří WSS automaticky při vytvoření seznamu. Pokud od nich nepožadujeme zvláštní chování, nemusíme je tedy vůbec upravovat. V případě vkládání nových podnětů k řešení problému je ale v zadání požadavek na to, aby byl uživatel upozorněn na existenci znalostní databáze a na nutnost popisovat problémy podrobně. K řešení tohoto bodu jsem využil Office SharePoint Designer. Otevřel jsem si v něm kolekci webů aplikace, a v nastavení příslušného seznamu jsem našel jeho formulář pro vkládání nových položek. Ten jsem si otevřel a formulář upravil jednoduše pomocí editoru webových stránek. V tomto případě je potřeba dávat pozor na to, kam text vkládáme, aby se nenarušila struktura stávající stránky, která je poskládaná z mnoha webových částí Logika výběru řešitele Pro proces výběru řešitele jsem použil Event Receiver. Ve Visual Studiu jsem tedy naprogramoval třídu zděděnou ze SP třídy SPItemEventReceiver. Pomocí této třídy mohu zachytávat události vyvolané nad položkami v seznamu. Kód Event Receiveru nejprve zjistí, jestli uživatel sám vybral řešitele pro zadávaný problém. Pokud ano, nechá řešitele nastaveného a ukončí se, pokud ne, zvolí výchozího řešitele pro typ zařízení, které je u daného problému uvedeno. Tento krok musí proběhnout ještě před nastavením přístupových práv a spuštěním pracovního postupu zadávání úkolů, aby měly tyto následující procesy správné informace o řešiteli problému. Při nastavování vazeb na Event Receiver mu proto musím nastavit vhodnou prioritu. Tento Event Receiver jsem navázal na asynchronní události Změna položky a Vytvoření položky. 25

31 5.3.7 Nastavení přístupových práv upravovaných položek Pro nastavení přístupových práv jsem vytvořil další Event Receiver, který se spouští po tom z kapitoly Opět jde o akci prováděnou při zachycení události vyvolané nad položkou v seznamu, takže je děděn také z třídy SPItemEventReceiver. Tento Event Receiver při svém spuštění vymaže všechna nastavení přístupových práv na dané položce, a nastaví všem uživatelům možnost číst položku, a zadavateli a řešiteli problému umožní položku i měnit. Tím je zajištěno, že do existující položky problému mohou zasahovat pouze oprávnění uživatelé. Navázal jsem ho na stejné události, jako Event Receiver z kapitoly Pracovní postup řešení úkolu K vytvoření pracovního postupu můžeme využít buď Office SharePoint Designer, nebo Visual Studio. V tomto konkrétním případě jsem ale použil Office SharePoint Designer, neboť vytváření pracovních postupů v něm je podstatně jednodušší, a pokud nepotřebujeme provádět vlastní akce, tento postup je plně dostačující. Samotné vytvoření pracovního postupu je v Office SharePoint Designeru realizováno pomocí průvodce. Stačí tedy na kolekci webů vytvořit pracovní postup, navázat ho na konkrétní seznam, v tomto případě je to seznam Problémy a nadefinovat akce pracovního postupu. Vytvořil jsem dvě akce: 1) Odeslat uživateli, který je uveden u problému jako řešitel. Tím zajistím, aby byl uživatel informován o tom, že mu bylo přiděleno řešení problému. 2) Přiřadit úkol uživateli, který je u problému uveden jako řešitel. V tomto případě se pracovní postup chová tak, že se zastaví, a čeká, dokud uživatel neoznačí úkol za dokončený. Tím je zajištěno i hlídání stavu řešení úkolu v uživatelském rozhraní. Obrazovky sejmuté při provádění těchto dvou kroků jsou v přílohách 5A a 5B. Pracovní postup lze nastavit tak, aby se spouštěl automaticky u každé nově vytvořené položky v seznamu. Toho jsem využil, takže stačí, aby uživatel vyplnil formulář, a zbytek procesů se spustí automaticky Sestavy Pro generování sestav jsem využil možnosti generovat dokumenty pomocí XSLT transformací v Office SharePoint Designeru a vestavěných webových částí WSS pro zobrazování jednoduchých sumářů Nasazení komponent do vývojového prostředí Ve Windows SharePoint Services nasazujeme dva druhy komponent. Prvním z nich je obsah, který vytváříme přímo nad funkční instancí WSS a druhým je kód, který nasazujeme v podobě 26

32 knihoven (z fyzického pohledu v podobě funkcí a řešení), a v obsahu na tento kód vytváříme vazby. Vzhledem k tomu, že celý vývoj probíhá ve vývojovém prostředí, a tedy obsah je vytvářen za chodu, tento se nemusí už nasazovat. Do vývojového prostředí tedy musíme nasadit pouze kód. V případě této aplikace, jsou programovanými komponentami Event Handlery. Výsledkem kompilace Event Handleru ve Visual Studiu je DLL knihovna, která obsahuje jednu nebo více tříd prostředí.net. Do WSS se potom taková knihovna nasazuje tak, že se vloží do Global Assembly Cache na serveru, a na daném seznamu se na knihovnu v Global Assembly Cache nastaví vazba. Pokud je v aplikaci použit pracovní postup, který se má spouštět automaticky na základě nějaké akce (vytvoření nebo změna položky v seznamu), toto spouštění se provádí přes vestavěný Event Handler. V tomto kroku jsem musel dát pozor na to, aby proběhly akce z kapitol 5.3.6, a a k jejich provedení došlo ve správném pořadí. K tomu jsem využil program SharePoint Inspector, který je volně šiřitelný a stáhl jsem ho z webu CodePlex. 27