Software pro sdílení informací ve firemních týmech

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA POČÍTAČŮ

Bakalářská práce

Software pro sdílení informací ve firemních týmech Tomáš Borovička

Vedoucí práce: Mgr. Jan Stoklasa

Studijní program: Softwarové technologie a management Obor: Softwarové inţenýrství červen 2009

ii

Poděkování Děkuji vedoucímu práce Mgr. Janu Stoklasovi za jeho cenné rady a čas, který této bakalářské práci věnoval. Rodině a přátelům za podporu při jejím zpracování.

iii

iv

Prohlášení Prohlašuji, ţe jsem svou bakalářskou práci vypracoval samostatně a pouţil jsem pouze podklady uvedené v přiloţeném seznamu. Nemám závaţný důvod proti uţití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 12. 6. 2009

............................................................. ....................

v

vi

Abstract The work deals with issue of software for sharing information and cooperation support in company teams. It focuses on Microsoft Windows SharePoint Products and Technologies, which is based mainly on Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. The first part of the work describes the adaptation possibilities offered by Windows SharePoint Services and how it is possible in these products to create their own solutions, such as process management, document sharing, management of various agendas or recording information. The second part of the work is concerned with the deployment of Windows SharePoint Services 3.0 in the chosen company. It describes the analysis of application, which is used in the company. On the basis of this analysis is created design of the solution using Windows SharePoint Services 3.0. Finally, the work describes the implementation and deployment prototype of application.

Abstrakt Práce uvádí do problematiky softwarů pro sdílení informací a podporu spolupráce ve firemních týmech. Zaměřuje se na sadu produktů a technologií Microsoft Windows Sharepoint Products and Technologies, která je zaloţena především na Windows Sharepoint services 3.0 a jejich nadstavbě Microsoft Office Sharepoint Server 2007. V první části práce popisuje, jaké moţnosti přizpůsobení Windows Sharepoint Services nabízejí a jakým způsobem je moţné v těchto produktech vytvářet vlastní řešení, jako je řízení pracovních procesů, sdílení dokumentů a hlavně vedení rozličných agend nebo zaznamenávání informací. Druhá část práce je pak věnována nasazení Windows Sharepoint Services 3.0 ve vybrané firmě. Je popsána analýza aplikace, která je ve firmě pouţívána a na jejím základě je vytvořen návrh řešení pomocí Windows Sharepoint Services 3.0. Nakonec práce popisuje implementaci a nasazení prototypu aplikace.

vii

viii

Obsah 1 ÚVOD Cíl práce Motivace 2 WINDOWS SHAREPOINT SERVICES 3.0 Historie WSS vs. MOSS Vývoj a moţnosti přizpůsobení Architektura Definice a šablony webů (Site Definition, Site Template) Webové části (Web Parts) Komponenty (Features) Datové typy, poloţky, typy obsahu Seznamy (Lists) Moduly a vlastní aplikační stránky (Moduls) Vlastní akce (Custom Actions) Event Handlery (Event Handler) Knihovny dokumentů (Document Library) Pracovní procesy (Workflows)

1 2 2 5 5 6 7 8 11 13 13 14 17 18 19 19 19 20

Řešení (Solutions) 3 ANALÝZA Analýza stávající aplikace Poţadavky Analýza pracovního procesu Doménový model 4 NÁVRH ŘEŠENÍ Definice webu Typy obsahu Seznamy

21 23 23 24 25 28 29 29 29 30

Komponenty a řešení 5 IMPLEMENTACE Komponenty Vlastní poloţky Typy obsahu Seznamy Vlastní aplikační stránky Vlastní akce

31 33 33 34 35 36 39 39 ix

Event Handlery

40

6 NASAZENÍ Instalace WSS Konfigurace WSS Vytvoření webové aplikace Vytvoření kolekce webů Nasazení řešení 7 TESTOVÁNÍ Jednotkové testy Test pouţitelnosti Zátěţové testy

41 41 42 42 42 43 45 45 45 45

8 ZÁVĚR LITERATURA A SLOVNÍK POJMŮ A POUŢITÝCH ZKRATEK A.1 Slovník pojmů A.2 Seznam zkratek B HARDWAROVÉ A SOFTWAROVÉ POŢADAVKY C STRUKTURA SOUBORŮ VE WSS D DEFINICE ELEMENTŮ WSS D.1 Site Definition (onet.xml) D.2 Feature (feature.xml)

47 49 50 50 51 52 53 54 54 55

D.3 Field D.4 Content Type D.5 List definition (schema.xml) D.6 List Template D.7 List Instance D.8 Custom Action D.9 Module D.10 Workflow Template D.11 Solution (manifest.xml) E OBSAH PŘILOŢENÉHO CD

x

56 57 58 59 60 61 62 63 64 65

Seznam obrázků Obr. 2.1: WSS a MOSS

7

Obr. 2.2: Windows Sharepoint Services 3.0 - Developer Map (zdroj Microsoft).

8

Obr. 2.3: Architektura a objektový model serveru (zdroj: msdn.microsoft.com).

9

Obr. 2.4: Objektový model Prostoru webu (zdroj: msdn.microsoft.com)

11

Obr. 2.5: Typy obsahu (zdroj: msdn.microsoft.com)

16

Obr. 3.1: Diagram pracovního procesu.

27

Obr. 3.2: Doménový model.

28

Obr. 4.1: Návrh typů obsahu.

30

Obr. 4.2: Návrh seznamů.

31

Obr. 4.3: Řešení kontakty.

32

Obr. 4.4: Řešení smlouvy o dílo.

32

Obr. 5.1: Features.

33

Obr. 6.1: Diagram nasazení.

41

Obr. 7.1: Výsledek zátěţového testu zobrazovacího formuláře smluv o dílo.

46

xi

xii

Seznam tabulek Tab. 2.1: Vestavěné webové části WSS.

13

Tab. 2.2: Datové typy WSS.

14

Tab. 2.3: Event Receivery WSS.

19

Tab. 5.1: Definice seznamů a jejich instance.

39

xiii

xiv

KAPITOLA 1. ÚVOD

Kapitola 1 Úvod V posledních letech, se stále se rozvíjejícím světem informačních technologií, počítačů a počítačových sítí, investují firmy na celém světě velké úsilí a obrovské finanční prostředky do vývoje a implementace software, který by zefektivnil týmovou spolupráci ať uţ v jednotlivých odděleních, či na celofiremní úrovni. Systémy pro správu informací se staly v poslední době velice populárními a to především portálové systémy, které umoţňují uţivatelům online získávat, nebo ukládat obsah a zároveň zajistit přístup k těmto informacím všem zainteresovaným osobám, ať uţ jsou to zaměstnanci jednotlivých oddělení, věřitelé firem, či komunita nějaké z dnes velice populárních sociálních sítí. Mají k tomu velice pádné důvody. Zákazník reaguje na profesionalitu a pohotovost, dobří lidé jsou základ úspěchu, dalším krokem je dát těmto lidem potřebné nástroje, aby své schopnosti mohli plně uplatnit k získání nových zákazníků a udrţení těch stávajících, k uzavření velkého obchodu, nebo řízení svých projektů, potřebují mít po ruce všechny informace, které s daným procesem souvisí a to v reálném čase a tyto procesy zefektivňovat. Společnosti si dobře uvědomují, jak jsou pro ně tyto nové technologie důleţité, novinkou není spolupráce v pracovních procesech, ale podpora těchto procesů a forma zaznamenávání, sdílení a vyhledávání potřebných informací. Tyto systémy nabízejí svým uţivatelům řadu nástrojů. Wiki stránky Umoţňují jednoduché vytváření webových stránek pomocí značkovacího jazyka a jejich upravování, nebo aktualizaci skupinou lidí. Publikování na webu Tvorba a publikace článků na webu většinou za pomoci WYSIWYG editoru (CMS). Verzování Zaznamenávání změn článků, dokumentů, obrázků v průběhu jejich vývoje. Komunikační nástroje Diskuze, online chaty, emaily. Elektronické kalendáře Umoţňují plánovat a zaznamenávat události, sdílet je s ostatními členy týmu a notifikovat všechny členy, kterých se událost týká. 1

KAPITOLA 1. ÚVOD Management projektů Plánování, sledování a řízení průběhu projektu. Workflow Řízení pracovních procesů na základě jejich metapopisu. Znalostní báze Zaznamenávání, řízení a zpracovávání rozličných druhů informací. Metadata Popisování a značkování dat pro jejich snazší zpracování a vyhledávání. Online tabulkové procesory umoţňují uţivatelům zpracovávat data online, stejně jako v tabulkových procesorech typu MS Excel. Bug a Issue tracking Zaznamenávání chyb a poţadavků. Dokument management Správa a sdílení dokumentů. Tyto nástroje pak tvoří komplexní řešení pro týmovou spolupráci a umoţňují svým uţivatelům zefektivňovat a profesionalizovat své pracovní procesy. Mezi tyto systémy patří i produkty sady Microsoft Sharepoint.

Cíl práce Cílem práce je popsat moţnosti přizpůsobení sady produktů Windows Sharepoint pro práci ve firemním prostředí, vysvětlit jaké nástroje pro vývojáře nabízejí a jaká řešení mohou pomocí těchto nástrojů vytvářet. Velká část práce bude věnována analýze, návrhu, implementaci a nasazení Windows Sharepoint Services 3.0 ve vybrané firmě. Výsledkem by měl být funkční prototyp aplikace poskytující rozhraní pro zaznamenávání a zpracování potřebných agend a sdílení dokumentů, umoţňující nahradit stávající aplikaci, pokrýt procesy, které tato aplikace nezahrnovala, a to za pomocí nástrojů, jeţ Windows Sharepoint Services nabízejí. Prototyp se bude dále vyvíjet dle potřeb firmy, ovšem jiţ mimo rámec této práce.

Motivace Produkty sady Microsoft Windows Sharepoint umoţňují svou robustností a škálovatelností vytvářet firemní řešení od těch nejjednodušších, které vyţadují pouhé sdílení dokumentů a zaznamenávání jednoduchých agend, aţ po velmi specifická řešení vyţadující konkrétní pracovní postupy. Náklady na vývoj na této platformě bývají zpravidla niţší, neţ při vývoji celé aplikace na zakázku. Především u méně sloţitých aplikací je rozdíl velice výrazný, neboť produkty Microsoft Windows Sharepoint dovolují veliké mnoţství funkcionality definovat uţivatelsky bez nutnosti psaní jakéhokoliv kódu. Aţ náročnější řešení vyţadují práci 2

KAPITOLA 1. ÚVOD programátorů, kteří však mají svou práci zjednodušenu velkým mnoţstvím hotových komponent a uţivatelských ovládacích prvků. V dnešní době je drtivá většina zákazníků orientována na cenu produktu a mnohdy podceňují náročnost poţadavků, které na systém mají. Produkty Microsoft Windows Sharepoint nabízejí hotový základ pro portálová řešení a vývojář se tak můţe zaměřit na vytváření business logiky pro zákazníka. Ušetřený čas na vývoj jádra se zpravidla projeví v ceně celého systému, nebo se můţe vyuţít na zdokonalení poţadavků zadavatele. Je potřeba vyvíjet rychle, spolehlivě a s nízkými náklady, to produkty Microsoft Windows Sharepoint z velké části umoţňují. Budoucnost vývoje pro malé a střední podniky je postavena na těchto škálovatelných systémech, které samozřejmě mají své hranice, ale velkou většinu poptávky jsou schopny pokrýt. Ve firmě Tema, s.r.o. je nasazen objednávkový systém vytvořený na zakázku. Systém však v mnoha směrech neumoţňuje potřebnou škálovatelnost a flexibilitu. Vývoj funkcionalit, které jsou na systém kladeny, změny v datovém modelu stávajících agend i přidávání dalších je velice pracné a tudíţ i finančně náročné. Oproti tomu Windows Sharepoint Services 3.0 velkou řadu těchto funkcí nativně nabízejí, jako například podporu pro správu dokumentů, vytváření vlastních datových pohledů, jednoduché přidávání sloupců do existujících seznamů nebo integrace produktů Microsoft Office. Celá firma vyuţívá produkty společnosti Microsoft (Microsoft Windows, Microsoft Office), coţ je v kombinaci s Windows Sharepoint Services velmi silný nástroj. Motivací práce je ukázat, ţe Windows Sharepoint Services 3.0 dokáţou nahradit stávající systém, zahrnout procesy, které tento systém nepokrýval a propojit jednotlivé agendy tak, aby tvořily ucelený pracovní proces. V neposlední řadě zjednodušit a zefektivnit práci s celým systémem.

3

KAPITOLA 1. ÚVOD

4

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0

Kapitola 2 Windows Sharepoint Services 3.0 Historie První produkt, jako předchůdce dnešního Sharepointu, představila společnost Microsoft v roce 1999 a jeho název byl Microsoft Digital Dashboard. Jako první se skládal z webových částí a umoţňoval tak zobrazovat na jedné stránce informace z více datových zdrojů. Uţivatelé si mohli výsledné stránky upravovat dle svých potřeb a zobrazovat jen ty webové části, které pro ně byly zajímavé. To přetrvalo Sharepointu dodnes. Uţ tenkrát bylo počítáno s rozšiřitelností a s vlastním vývojem podle poţadavků zákazníka. V roce 2001 přišel Microsoft se dvěma novými edicemi portálových řešení. Byly to Sharepoint Team Services a Sharepoint Portal Server 2001. Produkt Sharepoint Team services byl odlehčenou a omezenou verzí SharePoint Portal Server, navrţený především pro pouţití v meších firmách a týmech. Postrádal mnoho funkcionalit, které naopak nabízel SharePoint Portal Server. Ten naopak přišel v té době s nezvyklými funkcemi, jako úprava vzhledu za chodu portálu, podpora metadat dokumentů nebo rozsáhlými moţnostmi fulltextového vyhledávání. Velkým rozdílem také bylo odlišné datové úloţiště, jeţ produkty pouţívaly. Sharepoint Portal Server pouţíval úloţiště shodné s produktem MS Exchange, zatímco Sharepoint Team Services

jiţ pouţívaly Microsoft SQL Server.

Dělení na dva rozdílně

vybavené produkty, které v této době vzniklo, udrţuje Microsoft dodnes. Významným milníkem pro produkty a technologie Windows Sharepoint byl rok 2003. Spolu s příchodem Office 2003 přichází Sharepoint Portal Server 2003, uţ ale jako součást rodiny produktů Microsoft Office systém. To umoţnilo výrazně prohloubit integraci s klientskými aplikacemi jako MS Word, MS Excel nebo MS Outlook, coţ se ukázalo jako naprosto klíčové pro celou technologii. Do aplikace jiţ není nutné nahrávat dokumenty přes formuláře webového rozhranní, ale uţivatel můţe vyuţít uloţení dokumentu přímo z klientské aplikace sady Microsoft Office do úloţiště Sharepointu. SharePoint Team Services byly přejmenovány na Windows SharePoint Services 2.0 a staly se součástí produktové rodiny Windows Server. Jejich popularita velice vzrostla poté, co se staly součástí instalace Windows Serveru 2003 R2 a Small Business Severu 2003, který je dodnes nejčastějším řešením pro menší společnosti. Sharepoint byl poprvé postaven na platformě .NET, coţ napomohlo, aby z něho vznikl robustní a rozšiřitelný systém. Oba produkty jiţ vyuţívají úloţiště Microsoft SQL

5

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 Server. V této době se také začíná objevovat velká skupina firem zaměřujících se na vývoj a nasazení této platformy. Posledními produkty sady Microsoft Windows Sharepoint Products and Technologies jsou Windows SharePoint Services 3.0 a Office SharePoint Server 2007. V těchto verzích došlo k velice výrazným změnám a inovacím. Tou největší a nejpodstatnější změnou je sjednocení platforem Sharepoint Serveru a Sharepoint Services. Jsou postaveny na frameworku ASP.NET v2.0 a vyuţívají datového úloţiště Microsoft SQL Server 2005 1 . Jako jediný podporovaný hostitelský systém je Windows Server 20032. Windows Sharepoint Services se staly jakýmsi základem, na kterém je postavený Office Sharepoint Server. To umoţňuje značnou kompatibilitu komponent a snazší přechod z WSS na MOSS. Významným rozšířením je podpora pracovních procesů neboli workflow zakomponováním Windows Workflow Foundation, kdy WSS slouţí jako hostitelské prostředí pro WF programy. Dále pak stojí za zmínku vylepšení moţností zabezpečení oproti Windows Sharepoint Services 2.0, kde bylo moţné definovat přístupová práva pouze na úrovni seznamu, v nové verzi je jiţ moţné omezovat přístup na kaţdý záznam. V Sharepoint Serveru můţeme vyuţít produktu InfoPath, který slouţí k vytváření aplikačních formulářů. Mezi další novinky patří také rozšířené moţnosti vyhledávání, nebo publikování v prostředí internetu. Nyní se připravuje nová verze Windows Sharepoint Services 4.0 a Office Sharepoint Server 2010. Jejich vydání je plánováno na jaro 2010 spolu s novou sadou Microsoft Office 2010. Zatím k těmto produktům není mnoho oficiálních informací. Některé podstatné změny jiţ známé jsou. Je to zejména kompletní přechod na 64 bitovou platformu a nezbytnost pouţití některé z verzí Windows Serveru 2008. Měla by být zlepšena podpora prohlíţečů Firefox a Safari, která v předchozích verzích velmi chyběla. Naopak s končící podporou pro Internet Explorer 6.0 v roce 2010 nebude ani Sharepoint 2010 s IE 6 zcela kompatibilní. Produkty Sharepoint se v průběhu deseti let jejich vývoje staly velmi propracovaným nástrojem pro tvorbu portálových řešení a jistě je čeká velká budoucnost. (1)

WSS vs. MOSS Jak jiţ bylo řečeno, ve verzích 2007 byly sjednoceny platformy Windows Sharepoint Services a Microsoft Office Sharepoint Server. Respektive WSS se staly platformou, na které je postavený MOSS. WSS jsou nabízeny zdarma k produktům Windows Server 2003/2008, zatímco MOSS je licencovaný produkt. MOSS přidává k WSS další sluţby a komponenty, nabízí větší výběr vestavěných webových částí, šablon sítí, seznamů či workflow. Je určen jako řešení pro větší společnosti

1 2

6

Od SP1 mohou vyuţít MSSQL Server 2008. Od SP1 mohou být instalovány na Windows Server 2008.

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 s vyššími nároky a poţadavky, kterým WSS nestačí a jsou ochotny za to zaplatit. Veškeré rozdíly popisuje (2). Vývoj komponent pro oba produkty se neliší. Funkcionalita vytvořená pro nasazení na WSS můţe být stejně tak pouţita pro MOSS. Naopak uţ to platit nemusí, pokud vyuţijeme některé ze sluţeb, které jsou pouze pro MOSS, nemusí být komponenta kompatibilní. Tato práce dále pojednává pouze o WSS.

WSS

Další funkcionalita (Features, WebParts...)

MOSS

Obr. 2.1: WSS a MOSS

Vývoj a možnosti přizpůsobení WSS jsou od svého počátku koncipovány jako prostředí přizpůsobené pro další rozšiřování a vytváření vlastních řešení. WSS ve svém základu nabízejí několik šablon webů a seznamů, které umoţňují zaznamenávat rozličná data. Další šablony jsou pak ke staţení na stránkách podpory WSS. Mnohdy tyto šablony mohou pro vytvoření firemního portálu stačit, pokud je ale potřeba sloţitější a specifičtější řešení, je nutné WSS přizpůsobit a rozšířit podle poţadavků zákazníka. K tomu jsou WSS určeny, při vývoji nabízejí svou obecností velikou flexibilitu a robustností mnoho moţností přizpůsobení. (2) Moţnosti vývoje a přizpůsobení: Vytváření vlastních šablon a vlastních schémat – definice a šablony webů, definice a šablony seznamů, typy obsahu, vlastní datové typy, vlastní poloţky, šablony dokumentů. Kompilované doplňky – webové části, vlastní aplikační stránky, uţivatelské ovládací prvky, master pages, navigační prvky. Zpracovávání událostí – WSS umoţňují reagovat na události vyvolané jednotlivými objekty pomocí event handlerů (například zaloţení, nebo změna záznamu) Workflow a vlastní aktivity – moţnost vytvářet vlastní WF programy a ty svázat s objekty WSS. Práce s objektovým modelem WSS – můţeme přímo pracovat s objektovým modelem WSS, nebo ho vyvolávat pomocí webových sluţeb.

7


Obr. 2.2: Windows Sharepoint Services 3.0 - Developer Map (zdroj Microsoft).

Architektura WSS jakoţto produkt společnosti Microsoft rozšiřuje a vyuţívá ASP.NET framework. Oba pak vyţadují Internet Information Services, které vytváří vrstvu webového serveru. Jako hostitelský operační systém slouţí Windows Server 2003, od jehoţ druhé verze jsou WSS jeho nativní součástí. Sluţba IIS a ASP.NET je první komponentou na nejvyšší úrovni, ze které se WSS skládají. Je to „front-end“ server zpracovávající HTTP poţadavky a generující obsah pro koncové uţivatele. Druhou komponentou je datové úloţiště neboli „back-end server“. Datovým úloţištěm je MSSQL Server, ve kterém jsou vţdy nejméně dvě databáze: Konfigurační databáze – obsahující pouze konfigurační data a informace WSS. Je jediná, centralizovaná pro celou webovou farmu. Obsahová databáze – slouţící jako úloţiště webových stránek, seznamů, knihoven dokumentů a veškerého obsahu tvořícího web WSS. Obsahových databází můţe být více podle mnoţství WSS aplikací nasazených na IIS. Obě komponenty mohou být nainstalovány na jednom fyzickém stroji „stand-alone“ instalace, nebo v serverové farmě, kde můţeme rozkládat zátěţ na databázové i aplikační frontend servery.

8

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 Architektura a objektový model Architektura a objektový model serveru Obrázek 2.2 znázorňuje architekturu a část objektového modelu Windows Sharepoint Services 3.0. Objekty WSS mají hierarchickou strukturu. Níţe uvedený diagram zobrazuje nejvýše postavené objekty v rámci této platformy a jejich vzájemné vazby. (3)

Obr. 2.3: Architektura a objektový model serveru (zdroj: msdn.microsoft.com). 1. Webová farma (SPFarm) - nejvýše postavený objekt v hierarchii WSS, slučuje dohromady jednotlivé servery (objekty SPServer) a sluţby (objekty SPService) ve webové farmě. 2. Server (SPServer) - objekt reprezentující kaţdý fyzický počítač, na kterém běţí nějaká ze sluţeb WSS.

9

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 3. Služba (SPService) - reprezentuje sluţbu instalovanou v serverové farmě (můţe to být například vyhledávací sluţba, databázová sluţba, sluţba časovače atd). 4. Webová služba (SPWebService) - objekt obsahující konkrétní webové aplikace a umoţňující přístup k jejich nastavení. 5. Databázová služba (SPDatabaseServiceInstance) - objekt reprezentující konkrétní databázovou sluţbu, na které mohou být umístěny databáze obsahu. 6. Webová aplikace (SPWebApplication) - reprezentuje konkrétní aplikaci běţící na IIS. Poskytuje přístup k jednotlivým prostorům webu, nebo databázi obsahu. 7. Databáze obsahu (SPContentDatabase) – databáze obsahu webové aplikace. 8. Kolekce stránek (SPSiteCollection) - objekt obsahující jednotlivé weby ve webové aplikaci. Architektura a objektový model prostoru webu Kaţdá webová aplikace obsahuje kolekci webů, ve které je jeden nejvýše postavený, v terminologii WSS nazývaný top-level, web. Další weby pak mohou tvořit stromovou hierarchii, kde kořen je vţdy top-level web. Kaţdý pak obsahuje kolekci seznamů, ze kterých se kaţdý web skládá. Obrázek 2.3 vyobrazuje tuto hierarchickou strukturu objektů prostoru webu. (3)

10


Obr. 2.4: Objektový model Prostoru webu (zdroj: msdn.microsoft.com) 1. Top-level web (SPSite) – reprezentuje nejvýše postavený web a zpřístupňuje kolekci jeho potomků. 2. Web (SPWeb) – reprezentuje konkrétní web ve webové aplikaci. 3. Seznam (SPList) – objekt reprezentuje kaţdý konkrétní seznam na webu. 4. Položka (SPField) – objekt který definuje vlastnosti kaţdého sloupce. 5. Záznam (SPListItem) – reprezentuje jeden záznam v seznamu (úlohu, dokument, obrázek).

Definice a šablony webů (Site Definition, Site Template) Definice webu (Site Definition) se pouţívá k určení vzhledu, vlastností, funkcí a obsahu webu, skládá se z několika souborů umístěných na kaţdém front-end serveru. Šablona webu (Site Template) má velice podobnou funkci jako definice, jedná se o souhrn konfigurací

11

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 a úprav, které byly provedeny oproti definici, zabalený do jednoho souboru a uloţený v galerii šablon. Uţivatel pak můţe vytvářet nové weby zaloţené na tomto vzoru a s nimi pracovat. Hlavní rozdíl mezi definicí a šablonou je v jejich obsahu. Zatímco definice webu obsahuje veškeré struktury a schémata potřebné k vytvoření webu, šablona obsahuje pouze změny, úpravy, nebo konfigurace a tudíţ ke svému běhu potřebuje i definici, ze které byla vytvořena. Druhý rozdíl je pak v jejich zpracování serverem. Definice webu je při startu webového serveru nataţena do jeho vyrovnávací paměti, kde je uchována po celou dobu běhu. Není tedy nutné definici opakovaně načítat z databáze či souborového systému vţdy, kdyţ přijde poţadavek, coţ můţe značně zvýšit výkon aplikace. Jakmile je definice upravena a je z ní vytvořena šablona, situace se poněkud mění, konfigurace je uloţena v databázi obsahu a je nutné při kaţdém poţadavku rozdíly oproti definici z úloţiště znovu načítat. Neznamená to ale, ţe jsou šablony webu pomalé a jejich pouţívání by se měli uţivatelé vyhnout. Vytvoření šablony webu je většinou velmi jednoduché a dá se provést z uţivatelského rozhraní bez nutnosti zásahu do kódu, coţ je jejich velká výhoda. Pokud ale vytváříme sloţitější řešení a provádíme hodně změn oproti základním definicím, je lepší zváţit vytvoření vlastní definice namísto šablony. Definice webu (Site Definition) Definici webu tvoří soubory XML pro definici vlastností a obsahu, APSX pro stránky a formuláře, ASCX jako vlastní uţivatelské ovládací prvky, master page a šablony dokumentů. Srdcem definice webu je soubor onet.xml, který specifikuje uţivatelské rozhraní a určuje potencionální obsah (viz dodatek D.1). Hlavní funkce souboru onet.xml jak je popisuje SDK (4): Definuje navigační lišty domovské stránky a stránek seznamů. Specifikuje seznamy, které se dají na webu vytvořit. Specifikuje šablony dokumentů, které jsou dostupné pro vytvoření knihoven dokumentů. Určuje konfiguraci pouţitých seznamů a modulů. Určuje komponenty Windows SharePoint Services. Definuje patičku pouţitou v emailech. Nastavení, které můţeme přidat do definice webu (4): Specifikovat vlastní CSS soubor, JavaScript, ASPX header. Měnit navigační oblasti pro domovskou stránku a stránky seznamů. Přidávat definice seznamů. Přidávat šablony dokumentů. Určovat konfiguraci seznamů, modulů, souborů, webových částí, kdyţ je vytvářena instance webu.

12

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 Šablona webu (Site Template) Uţivatelé mohou vytvořit šablonu uloţením stávajícího webu v jeho nastavení, nebo pomocí WSS jazyka CAML. Šablona se uloţí do galerie šablon a uţivatel z ní pak můţe kdykoliv vytvořit nový web. Jelikoţ má v sobě šablona pouze změny a nastavení oproti definici sítě, je vţdy nutné, aby definice, ze které byla šablona vytvořena, v prostoru webu existovala.

Webové části (Web Parts) Webová část je základním stavebním prvkem webu WSS. Je to serverový ovládací prvek ASP.NET, který můţeme vloţit do zóny pro webové části .aspx stránky. Webová část je pak spojena se stránkou, v níţ je generována, a vzniká tak jediný fyzický celek. Pouţívají se jako komponenty uţivatelského rozhranní WSS a umoţňují získávat informace z rozličných zdrojů, jako jsou seznamy WSS, XML dokumenty nebo externí datová úloţiště. Při přidávání webové části na stránku se zónou pro webové části se pouţívá manaţer webových částí, který je jejich řídícím prvkem udrţujícím jejich instance a nastavení, a pomocí něhoţ můţeme nastavit vlastnosti a konfiguraci webové části. WSS obsahují několik vestavěných webových částí, které lze konfigurovat a pouţít podle vlastní potřeby (5 str. 100). Webová část

Funkce

Content Editor Web Part

Zobrazení statického HTML

Data View Web Part

Zobrazení formátovaných dat z databáze, XML nebo seznamu WSS

List View Web Part

Zobrazení jakéhokoliv seznamu

Image Web Part

Zobrazení libovolného obrázku

Members Web Part

Zobrazení členů webového prostoru

Page Viewer Web Part

Zobrazení existující webové stránky v IFrame

Tab. 2.1: Vestavěné webové části WSS. Vývoj vlastních webových částí umoţňuje vytvářet specifické aplikace a při zachování obecnosti a zakomponování vhodné konfigurovatelnosti nám nabízí vysokou flexibilitu a znovupouţitelnost. Webové části můţeme nasadit přes uţivatelské rozhraní WSS nebo pomocí modulu a feature, ty budou později podrobně vysvětleny.

Komponenty (Features) Feature je mechanismus pro definici funkcí nebo komponent a jejich nasazení na poţadovaný web, kolekci webů či farmu. Komponenty, které mohou být definovány pomocí feature jsou například definice seznamů, instance seznamů, typy obsahu, vzory stránek, definice sloupců, event handlery, workflow a další. Feature sama o sobě nedefinuje ţádnou funkcionalitu, ale je manifestem pro další elementy, které umoţňuje instalovat do aplikací WSS. 13

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 Kaţdá feature musí být umístěna v samostatném adresáři ve sloţce určené pro features. Kaţdá sloţka pak obsahuje soubor manifestu feature.xml (viz dodatek D.2), který definuje její atributy, jako název, popis, jednoznačný identifikátor, prostor platnosti, závislosti a hlavně cesty k dalším manifest souborům obsahujícím definice jednotlivých komponent a funkcí, ze kterých je feature tvořena. Sloţka pak můţe obsahovat další podporující soubory jako .xml, .aspx, .resx, .dll, .css, obrázky, nebo JavaScript, které jsou nutné ke správné funkci nasazovaných komponent. Feature je tedy základní nástroj pro nasazení vlastních komponent na web WSS.

Datové typy, položky, typy obsahu Základem aplikací pro týmovou spolupráci je flexibilní datový model, který umoţňuje uţivatelům definovat a zaznamenávat rozličné objekty s různými atributy. Ve WSS slouţí k definici těchto objektů seznamy (Lists) a typy obsahu (Content Types), ty umoţňují buď uţivatelsky, nebo pomocí feature a jazyka CAML, definovat, přidávat nebo odebírat sloupce s různým datovými typy a vlastnostmi. Stejně jako je moţné definovat vlastní seznamy a typy obsahu, umoţňují WSS vytvářet vlastní datové typy, nebo sloupce a určovat jejich formát a restrikce. Datové typy (Field Types) Kdyţ vytváříme nový sloupec v seznamu, máme moţnost vybrat z několika datových typů, které nám WSS nabízí (6 str. 92). Datový typ

Popis

Single line of text

Jeden řádek textu

Multiple lines of text

Víceřádkový box

Choice

Výběr z definovaných moţností

Number

Číslo (celé, desetinné)

Currency

Měnová poloţka

Date and Time

Datum, můţe být s časem i bez

Lookup (information already on this site)

Odkaz na poloţku v jiném seznamu

Yes/No

Logická hodnota ANO/NE

Person or Group

Uţivatel, nebo skupina, kteří jsou členy webu

Hyperlink or Picture

URL

Calculated

(calculation

based

on

other Počítaná poloţka

columns) Tab. 2.2: Datové typy WSS. Pokud vestavěné datové typy nestačí k vytvoření poţadovaných poloţek seznamů, je moţné definovat vlastní. Ty nemůţeme vytvářet deklarativně pomocí jazyka CAML, ale musí 14

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 být psány v řízeném kódu a zkompilovány do strong name assembly DLLs, které musí být instalovány do Global Assembly Cache. Psaní v řízeném kódu nabízí daleko více flexibility při vytváření specifických datových typů a umoţňuje provádět velmi specifické validace, coţ je většinou u vlastních typů poţadováno. Vlastní datové typy nasadíme na web WSS pomocí feature a můţeme s nimi kdekoliv v prostoru webu pracovat. Položky (Fields) WSS nabízí v základu mnoho obecných poloţek, především pro práci s dokumenty, kontakty nebo úkoly. Jsou to například Název, Křestní jméno, Příjmení, Verze, Komentář a mnoho dalších. Jsou to obecná pole a ve většině případů nebudou k vytvoření řešení stačit. Je tedy nutné definovat vlastní, které budou splňovat dané poţadavky. Jsou opět dvě moţnosti jak vlastní poloţku vytvořit. První, jednodušší, přes webové rozhraní vytvořit poloţku pomocí webového formuláře. Tento postup vyuţívají především uţivatelé systému, pokud chtějí některý z existujících seznamů rozšířit o další sloupec. Pokud je potřeba s poloţkou pracovat a pouţít ji na více místech, ať uţ v definici seznamu, typu obsahu, nebo jinde, je pro developery lepší definovat ji pomocí jazyka CAML (viz dodatek D.3) a nainstalovat jako feature. Typy obsahu (Content Types) Typ obsahu je schéma, nebo soubor poloţek, které tvoří logický objekt v seznamu, nebo knihovně dokumentů. Tento typ obsahu je pak přenositelný mezi jednotlivými seznamy napříč prostorem celého webu. Můţeme si například vytvořit typ obsahu kontakt, který bude obsahovat poloţky jméno, příjmení, adresa, email, telefon. Pak vytvoříme dva různé seznamy, klienti a dodavatelé, u obou dvou nakonfigurujeme, aby pouţívaly typ obsahu kontakt. Vzniká nám jakýsi polymorfizmus, máme dva různé seznamy, které obsahují homogenní data. Nebo můţe nastat jiný případ. Máme jediný seznam, ve kterém evidujeme více druhů objednávek, které se liší některými poli. Vytvoříme si tedy tolik typů obsahu, kolik máme druhů objednávek. Kdyţ pak vytváříme novou objednávku, máme na výběr, který typ chceme vytvořit a WSS nám nabídne k vyplnění pouze ta pole, které má definovány daný typ obsahu. Typ obsahu musí být vţdy zděděn z některého jiného typu, nejzákladnějším je typ item, který je předkem všech ostatních a obsahuje jen několik nezbytných poloţek.

15


Obr. 2.5: Typy obsahu (zdroj: msdn.microsoft.com) Typy obsahu se dělí na item-based a document-based, podle jejich pouţití. V seznamech se pouţívají item-based typy a v knihovnách dokumentů document-based typy. Typ obsahu, který by šlo pouţít v obou dvou, neexistuje. Je to proto, ţe document-based typy v sobě obsahují některé poloţky pro definici dokumentů, které seznamy obsahovat nemohou. Kromě sdruţování poloţek dovolují typy obsahu na sebe navázat další funkcionality a chování. Typy obsahu umoţňují vyvolávat události, které se mohou zpracovávat event handlery. Mohou na sebe navázat pracovní procesy (workflow), které se spustí při jejich vzniku. Můţeme definovat uţivatelské akce a ty s nimi asociovat. A v neposlední řadě můţeme vyuţít definování vlastních formulářů pro vytvoření, editaci, nebo zobrazení záznamu zaloţeného na typu obsahu. Typy obsahu mohou být velmi uţitečným nástrojem při vytváření vlastních řešení, jelikoţ umoţňují pracovat se záznamy napříč seznamy celého prostoru webu. (definice pomocí CAML viz dodatek D.4)

16


Seznamy (Lists) Seznamy jsou srdcem architektury WSS, veškerá data, veškerý obsah ve WSS je zpracováván a zaznamenáván pomocí seznamů. Jak jiţ bylo řečeno, aplikace pro týmovou spolupráci vyţadují, aby bylo moţno jednoduše uchovávat rozličná data. K tomu je nutné tato data nějak popsat a uloţit, a právě k tomu seznamy slouţí. Popisují data, umoţňují je uchovávat v databázích obsahu WSS a zobrazovat uţivatelům. Seznam reprezentuje v objektovém modelu WSS třída SPList a kaţdý záznam pak třída SPListItem. Přes tyto objekty můţeme pracovat s obsahem seznamu nebo jednotlivými záznamy v řízeném kódu. Ve WSS je moţné definovat vlastní seznamy, určovat jejich obsah a vlastnosti a tak zaznamenávat různé druhy dat. Definice seznamu (List Definition) Definici seznamu tvoří soubor schema.xml (viz dodatek D.5), který určuje jeho vlastnosti i vzhled. Ten pak můţe odkazovat na další soubory, které jsou nutné ke správné funkci, jako například formulářové stránky .aspx pro vytvoření nebo editaci záznamu. Definice seznamu je výrazně sloţitější neţ například definice typu obsahu, jelikoţ musíme kromě poloţek, které seznam obsahuje, definovat i uţivatelské pohledy a formuláře, coţ je obvykle ve výsledku i několik tisíc řádků kódu. Proto je při vývoji seznamů lepší vycházet z jiţ hotových definic WSS a ty upravovat dle potřeby, neţ vytvářet definice znovu od začátku. Vlastní funkce souboru schema.xml jsou (7): Definuje sloupce seznamu. Určuje nebo definuje typy obsahu, které můţe seznam obsahovat. Definuje uţivatelské pohledy. Určuje .aspx stránky pro práci se záznamy (vytváření, editace, zobrazení). Definuje výchozí popis seznamu. Šablona seznamu (List Template) Šablona seznamu obdobně jako šablona sítě, umoţňuje uţivatelům uloţit si nastavený a nakonfigurovaný seznam a ten pak pouţít k vytvoření nového. Stejně jako u šablony sítě i šablona seznamu vyţaduje, aby v prostoru webu existovala definice, ze které byla šablona vytvořena. Šablonu můţeme vytvořit uţivatelsky, uloţením existujícího seznamu do formátu šablony .stp. Tento formát je binární reprezentací jeho konfigurace a případně i obsahu, který můţe šablona téţ obsahovat. Soubor se uloţí do galerie šablon seznamů a šablona se zobrazí na stránce pro jejich vytváření. Seznamy zaloţené na této šabloně je pak moţno vytvářet stejně jako výchozí seznamy WSS. Druhá moţnost jak definovat šablonu je pomocí jazyka CAML (viz dodatek D.6). Takto definovaná šablona referencuje na definici seznamu, kterou umoţňuje v omezené míře konfigurovat, a vytvoří odkaz na stránce pro vytváření seznamů. Dovoluje nastavit atributy jako 17

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 povolení příloh k záznamům, zabezpečení seznamu, kategorie, ve které bude list zobrazen, zda se objeví odkaz v navigačním panelu a podobně. Jsou to většinou všechny atributy, které se dají editovat v uţivatelském rozhraní. V šabloně seznamu uţ není moţné definovat sloupce nebo typy obsahu, k tomu slouţí jeho definice, stejně tak v něm nelze definovat záznamy, které by měl seznam obsahovat. Můţeme pouze určit, zda se přebere obsah z definice seznamu či nikoliv, nebo zda bude umoţňovat práci s typy obsahu. Pokud je nutné definovat počáteční obsah, který není v definici seznamu a není ţádoucí vytvářet novou definici, můţeme ho určit v instanci seznamu. Instance seznamu (List Instance) Instanci seznamu můţeme vytvořit několika způsoby, přes uţivatelské rozhraní WSS na stránce pro vytváření seznamů, pomocí objektového modelu WSS, nebo definicí v jazyce CAML (viz dodatek D.7). Nová instance většinou vzniká v uţivatelském rozhranní WSS, někdy je však potřeba instanci vytvořit jinak. Například výhoda definice v jazyce CAML je ve spojení s jeho přenositelností a snadnou modifikovatelností, moţnost seznam deklarativně naplnit potřebnými počátečními daty. Počáteční data mohou být dána uţ definicí seznamu, to ale většinou není ţádoucí, jelikoţ z definice můţe vznikat veliké mnoţství seznamů, ve kterých mají být počáteční data rozdílná, nebo ve většině případů ţádná. Právě pro konkrétní seznamy, zaloţené na stejné definici obsahující jiná počáteční data se pouţití definování instance jeví jako nejlepší volba. Například v nějaké komponentě, která je nasazována na web, můţe být potřeba vytvořit konkrétní seznam, v takovém případě je logické pouţít instanci seznamu definovanou v CAML a nasadit ji společně v jednom řešení. Instance seznamů můţeme také vytvářet přes objektový model WSS.

Moduly a vlastní aplikační stránky (Modules) Moduly umoţňují nasazovat vlastní aplikační stránky, webové části nebo jakékoliv jiné soubory na WSS. Modul obsahuje odkazy na soubory, které chceme nahrát do adresářové struktury, kde jsou umístěny WSS. V modulu definujeme URL, na které bude soubor dostupný, a cestu v adresářové struktuře, kde budou soubory fyzicky uloţeny. Pomocí modulů můţeme také ukládat webové části do knihoven pro ně určených. Moduly definujeme pomocí CAML (viz dodatek D.9) a nasazujeme pomocí feature. WSS nabízejí velikou flexibilitu v moţnostech modifikace jejich vestavěných webových stránek. Stránky WSS si můţeme přizpůsobit svým potřebám a to samozřejmě ne jen pomocí webových částí ale i přímým zásahem do jejich kódu. Někdy nám však ani tyto přizpůsobení neumoţní dodat potřebnou funkcionalitu, nebo jednoduše není vhodné tyto stránky měnit. WSS dovolují pouţívat vlastní aplikační stránky, jenţ umoţní funkcionalitu rozšiřovat. Mohou to být

18

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 ASP.NET stránky s kódem v pozadí, které pomáhají řešit business logiku, nebo jen umoţňují specifický pohled na data.

Vlastní akce (Custom Actions) Pomocí vlastních akcí můţeme přidávat příkazy do kontextových menu WSS. To nám umoţní zlepšit navigaci na webu a zpřístupnit vlastní aplikační stránky. Kaţdé kontextové menu má identifikátor umístění, pomocí něhoţ určíme, ţe se tam má poloţka zobrazit. Akci můţeme také asociovat s konkrétním seznamem, nebo s typem obsahu a vynutit tak její zobrazení jen ve správném kontextu. Kromě definování vlastních poloţek do kontextových menu, můţeme vestavěné akce skrývat. (definice pomocí CAML viz dodatek D.8)

Event Handlery (Event Handler) WSS umoţňuje odchytávat události nad různými jeho objekty a na jejich základě zpracovávat řízený kód. WSS rozlišují dva typy událostí „before events“ a „after events“. „Before events“ jsou události, které se vyvolávají předtím, neţ akce proběhne, akci je tedy ještě moţné zrušit nebo změnit údaje pro její zpracování. Naopak „after event“ je událost, která se vyvolá aţ po skončení akce a není tedy moţné zrušit nebo změnit její vykonání. Pro zpracovávání událostí je nutné vytvořit třídu zděděnou ze speciálních WSS tříd, tyto třídy se nazývají „event receivery“. Tato třída pak obsahuje metody „event handlery“, které se vyvolávají na základě událostí. Třídy musíme zkompilovat do strong name assembly a nasadit do GAC. Event receivery pak zaregistrujeme pomocí feature. Tabulka 2.3 popisuje dostupné event receivery. Prostor

Popis

Odchytává uţivatelské události nad záznamy, jako přidání, odstranění, změna ... List Odchytává události seznamu. Změna, přidání, odstranění sloupce. Web Události v oblasti webu, jako vytvoření nebo odstranění. Email Odchytávání příchozího emailu pro seznam. Feature Odchytávání aktivace, deaktivace, instalace a odinstalace feature. Tab. 2.3: Event Receivery WSS. Item

Třída SPItemEventReceiver

SPListEventReceiver

SPWebEventReceiver SPEmailEventReceiver SPFeatureEventReceiver

Knihovny dokumentů (Document Library) Knihovna dokumentů je speciální typ seznamu, který má zabudované schopnosti pro práci s dokumenty, tím je myšleno například verzování, publikování, nebo rezervování.

19

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 Knihovny slouţí k uchovávání a sdílení souborů a sloţek. Umoţňují definovat přístupová práva na jednotlivé soubory, stejně jako seznamy na jednotlivé záznamy. Knihovny dokumentů umí kromě uchovávání a sdílení samotných souborů, popisovat tyto soubory metadaty, která pak umoţňují jejich jednodušší zpracování, třídění, nebo vyhledávání. Pokud pracujeme s dokumenty sady Microsoft Office, můţeme navíc s těmito metadaty pracovat uvnitř jednotlivých dokumentů, upravovat pomocí metadat jejich obsah, nebo naopak úpravou obsahu dokumentu změnit metadata dokumentu v knihovně. Seznam reprezentuje ve WSS objekt SPList, knihovnu dokumentů pak objekt SPDocumentLibrary. SPDocumentLibrary je potomek SPList a můţeme k ní tedy přistupovat jako k seznamu. Stejně tak i jednotlivým poloţkám můţeme přistupovat pomocí třídy SPListItem, která je specifická pro SPList a která nám umoţňuje číst metadata záznamu. V knihovně dokumentů je však ještě kaţdý záznam reprezentován pomocí třídy SPFile, pomocí něhoţ pracujeme se samotným souborem.

Pracovní procesy (Workflows) Pracovní procesy neboli workflow jsou v poslední době ve firemních systémech velice oblíbené. Umoţňují řídit uţivatele a vynucovat od nich poţadované vstupy a na jejich základě se rozhodovat o dalším postupu, či výsledku. Programům, které umějí automatizovaně řídit firemní proces, se někdy říká reaktivní programy. Po kaţdém vstupu se většinou provede nějaká dávka kódu, řešící určitou část procesu, a následně se opět čeká na další vstup, nebo se program ukončí, pokud je proces hotov. Pod workflow si tedy můţeme představit sadu aktivit, které se sekvenčně provádějí od startu programu do jeho ukončení v daném pořadí, nebo podle nějakých vazeb. WSS umoţňuje spouštět workflow programy nad svými objekty a slouţí jim jako hostitelské prostředí. Vyuţívá k tomu framework Windows Workflow Foundation, který je součástí .NET Frameworku 3.0, a rozšiřuje ho o vlastní aktivity, které jsou specifické pro tuto platformu. Typické pouţití workflow můţe být například při schvalování dokumentů, kdy se delegují pravomoce podle jejich typu. Aktivity Aktivity jsou základní stavební prvky workflow programů. Aktivita je jakási atomická sada instrukcí, reprezentující jeden krok, který se provádí v průběhu pracovního procesu. Windows Workflow Foundation definuje sadu aktivit pouţitelných ve workflow programech. WSS pak přidává další sadu, která je specifická pro tuto platformu. Pokud nám definované aktivity nestačí, můţeme si libovolně vytvářet aktivity vlastní. Aktivity se ve WWF dělí na aktivity akcí (action activity) a aktivity událostí (event activity). Aktivity akcí jsou aktivity vykonávající většinu práce ve WF programu, jejich event 20

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 handlery se spouštějí dřív neţ je práce dokončena. Naopak aktivity událostí spouštějí svůj kód jako odezvu na nějakou událost, například vytvoření, nebo změna záznamu v seznamu, coţ znamená, ţe jejich event handlery se spouštějí aţ po události. Princip je stejný jako u eventhandlerů reagujících na before a after události. Workflow šablony Workflow se ve WSS skládá z několika souborů, je to samotný workflow program reprezentovaný většinou dynamickou knihovnou, deklarativně pomocí XAML, nebo kombinací obojího. Vývoj workflow programů je však nad rámec této práce, která se bude dále zabývat pouze nasazením a pouţitím WF programů ve WSS. Workflow také obvykle obsahuje asociační formulář, který pouţijeme, kdyţ workflow přiřazujeme k nějakému seznamu, nebo typu obsahu, a instanciační formulář, který se zobrazí při spuštění workflow nad nějakým záznamem. V těchto formulářích, nastavujeme konfigurační atributy workflow programu, které jsou nutné k jeho správné funkci. Samotná workflow šablona je pak definována pomocí jazyka CAML (viz dodatek D.10) a obsahuje popis a metadata, referencující na tyto soubory obsahující výkonný kód WF. Šablony workflow nasazujeme na WSS pomocí feature. Kdyţ šablonu workflow nasazujeme, musíme nejprve instalovat nezbytné dynamické knihovny obsahující WF program do Global Assembly Cache. Poté můţeme instalovat a aktivovat feature obsahující naší workflow šablonu. Workflow program pak můţeme přiřadit k seznamu, nebo typu obsahu a nad jejich záznamy spouštět jednotlivé instance.

Řešení (Solutions) Vývojáři WSS přidali do nové verze sadu funkcí pro zabalení a nasazení uţivatelsky definovaných komponent jako jsou definice sítí, šablony, webové části nebo sestavení, a nazvali ho Solution Framework. Ten umoţňuje zabalit komponenty do jediného souboru řešení. Soubor řešení, neboli Solution file, je komprimovaný balíček, zaloţený na formátu CAB, s příponou .wsp. To nám dává moţnost vytvořit přenositelný a snadno instalovatelný balíček. Balíček řešení můţe obsahovat následující komponenty: definice prostoru webu, definice Features a s nimi spojené soubory a elementy, webové části (*.webpart, *.dwp), soubory šablon, zdroje (Resources), sestavení (DLL), bezpečnostní politiku.

21

KAPITOLA 2. WINDOWS SHAREPOINT SERVICES 3.0 Samotné řešení je definováno manifestem (manifest.xml viz dodatek D.11) obsahujícím metadata, odkazující na další manifesty nasazovaných komponent. Nasazení řešení Nasazení řešení se skládá ze dvou kroků. Prvním je instalace, která zkopíruje .wsp balíček do konfigurační databáze. Druhý krok je samotné nasazení. WSS nainstaluje řešení napříč všemi servery v rámci farmy, coţ udrţuje instalace na jednotlivých front-end serverech konzistentní a usnadňuje tím práci serverovým administrátorům. Balíček řešení v sobě nese potřebná metadata, která WSS umoţní dekompresi CAB souboru a instalaci jednotlivých komponent, které balíček obsahuje. Samotný balíček se vytváří pouţitím utility operačního systému (MAKECAB), které je předán jako parametr soubor .ddf definující vstupní strukturu souborů komponent a výstupní strukturu balíčku .wsp.

22

KAPITOLA 3. ANALÝZA

Kapitola 3 Analýza Kapitola analyzuje stávající aplikaci pro evidenci objednávek ve firmě Tema, s.r.o. a pracovní postup nejen při jejich vytváření, jako podklad pro vytvoření nového systému.

Analýza stávající aplikace Firma Tema, s.r.o. se zabývá návrhem a pokládáním stropních systémů. Ve svých zakázkách obvykle zajišťuje návrh poloţení stropu, dopravu do místa stavby, poloţení za pomocí jeřábu a asistenci odborného technika. Aplikace, jeţ teď firma pouţívá, byla navrţena pro podporu procesu od poptávky zákazníka do ukončení celé zakázky z hlediska zajištění subdodávek, dodání smluv a fakturace. Byla vytvořena na zakázku podle tehdejších potřeb a v průběhu jejího pouţívání několikrát upravována a rozšiřována dle měnících se potřeb a poţadavků firmy.

Aplikace je spíše

evidenčního charakteru, zaznamenává a vytváří objednávky, eviduje klienty a dodavatela a umoţňuje jejich případné další zpracovávání. Některé poţadavky však nebylo moţné splnit, vzhledem k jejich vysoké náročnosti. Aplikace je psána v jazyce PHP a vyuţívá databázové úloţiště MySQL. Aplikaci pouţívá několik uţivatelů v ústředí firmy a je přístupná pouze na lokální síti. Aplikace řeší následující procesy: Zaznamenávání poptávek Pokud přijde do firmy poptávka po sluţbách, jsou do systému zaznamenány nezbytné informace pro vytvoření nabídky. Evidence odběratelů V systému jsou zaznamenáváni veškeří odběratelé, se kterými byla uzavřena nějaká smlouva, nebo pro ně jen byla vytvořena nabídka. U odběratelů se evidují kontaktní informace jako adresa, email, telefon, nebo fax a informace potřebné k moţné fakturaci, jako IČ a DIČ. Evidence dodavatelů Stávající aplikace zaznamenává dodavatele, jejich kontaktní informace a údaje potřebné k vytváření objednávek. Tvorba objednávek Jednou z hlavních funkcí stávající aplikace je tvorba objednávek. V systému jsou vytvářeny různé typy objednávek pro různé dodavatele. Objednávky nejsou ţádným způsobem

23

KAPITOLA 3. ANALÝZA unifikované a dost se od sebe liší, záleţí to na typu objednávky nebo dodavateli, u kterého se zboţí či sluţby objednávají. Kaţdý typ objednávek je zpracováván v samostatném seznamu a má specifický formulář na jejich vytváření. Některé objednávky jsou v systému pouze zaznamenávány a jejich evidence je pak dále zpracovávána. Jiné jsou vytvářeny za účelem zaslání dodavatelům. Objednávky jsou zasílány výhradně v tištěné podobě, systém umoţňuje pouze jejich tisk. Kaţdý typ objednávek má také odlišný tiskový výstup. Typy objednávek: objednávka materiálů, objednávka dopravy, objednávka jeřábů, objednávka Savas, objednávka Goldbeck, objednávka Plaso. Evidence faktur Při objednávce zboţí, nebo sluţeb obdrţí firma od dodavatele fakturu. U několika typů objednávek se tyto faktury zaznamenávají. O fakturách se eviduje pouze číslo faktury, popis a částka, která se pak vyuţívá při výpočtu nákladů na zakázku. Vytváření smluv o dílo Při pokládání stropu je s klientem uzavřena smlouva o dílo. Ta je vytvářena i tištěna z aplikace. Smlouva o dílo je dokument obsahující informace o předmětu smlouvy, zúčastněné osoby, cenu plnění a ostatní smluvní podmínky.

Požadavky Funkční požadavky Evidence dodavatelů Systém bude evidovat dodavatele, od kterých firma odebírá zboţí nebo objednává sluţby. Evidence odběratelů Systém bude evidovat odběratele (klienty), pro které byla vytvořena poptávka / nabídka / zakázka. Evidence poptávek V systému se budou evidovat veškeré poptávky přicházející do firmy. Poptávka obsahuje poptávajícího odběratele, popis poptávky a případnou poznámku pro pracovníka vytvářejícího následnou nabídku.

24

KAPITOLA 3. ANALÝZA Evidence nabídek Na kaţdou poptávku se reaguje nabídkou. Nabídka jiţ obsahuje konkrétní informace, aby bylo moţno vytvořit zakázku. Evidence zakázek Systém bude evidovat vzniklé zakázky. Zakázka na sebe váţe veškeré ostatní objekty nutné k její realizaci (objednávky – subdodávky, faktury, smlouva o dílo…). Evidence objednávek Na kaţdou zakázku vznikají další objednávky a to jak materiálů, tak sluţeb. Objednávek je více druhů a s velkou pravděpodobností jich bude přibývat. Systém musí umět evidovat různé druhy těchto objednávek a musí být do budoucna moţno další druhy jednoduše přidávat. Evidence přijatých faktur V systému je nutno evidovat veškeré přijaté faktury a tyto faktury pak přiřazovat adekvátním zakázkám. Zatím není jasné, jakým způsobem se budou přiřazovat faktury zahrnující více zakázek. Export seznamů do MS Excel Všechny seznamy v aplikaci bude moţno exportovat do aplikace MS Excel, aby mohly být dále zpracovávány. Export kontaktů do MS Outlook Seznamy odběratelů a dodavatelů bude moţno exportovat do aplikace MS Outlook za účelem hromadné korespondence. Sdílené dokumenty Aplikace bude umoţňovat sdílet v týmu dokumenty. Ty bude moţné rezervovat, aby nemohli na jednom dokumentu pracovat dva uţivatelé zároveň. Nefunkční požadavky Systém nahradí stávající aplikaci pro správu objednávek. Systém bude webová aplikace běţící na firemním serveru dostupná všem uţivatelům v rámci firemní sítě. Nebude nutné dokupovat další software.

Analýza pracovního procesu Pracovní proces začíná, kdyţ firma obdrţí poptávku, která můţe být ústní, telefonická, emailem nebo faxem. Tato poptávka je jedním z uţivatelů zaznamenána do systému. K zaznamenání je nutné, aby existoval odběratel, který produkt nebo sluţby poptává. Pokud je to zákazník, který jiţ od firmy sluţby či zboţí odebíral, můţe být poptávka vytvořena. Zákazník, který je nový, musí být nejprve zaznamenán mezi odběratele a aţ poté můţe být 25

KAPITOLA 3. ANALÝZA poptávka vytvořena. O vytvoření poptávky mohou být informováni vybraní uţivatele pomocí emailu. V systému vznikla nová poptávka a zodpovědný pracovník musí vytvořit odpovídající nabídku na základě informací, které z poptávky získal. Zpracovaná nabídka je předána odběrateli k jeho vyjádření. Ten ji buď akceptuje, nebo odmítne s tím, ţe můţe ţádat její přepracování, nebo rovnou ukončit spolupráci s firmou. Pokud ţádá její přepracování, můţe mu firma vyhovět, nabídku přepracovat a zaslat znovu k jeho akceptaci, nebo přepracování odmítnout a proces s odběratelem ukončit. Je-li znám důvod, proč nebyla nabídka úspěšná, je tato informace zaznamenána a vyuţita při kaţdoročním vyhodnocování firemních statistik. Pokud je nabídka akceptována, nic nebrání, aby byla vytvořena zakázka a s odběratelem sepsána smlouva o dílo. Neţ se zahájí jakékoliv práce na zakázce, je nutné, aby odběratel zaplatil zálohu dohodnutou ve smlouvě. Teprve kdyţ jsou peníze připsány na účet firmy, jsou zahájeny práce na zakázce. Ke zhotovení zakázky je ve většině případů nutné objednat subdodávky, jedná se především o objednávky potřebných materiálů, dopravy na místo stavby, jeřábu pro sloţení stropního systému, nebo nezbytných ţelezných konstrukcí. Podle moţností subdodavatelů a termínu ve smlouvě jsou naplánovány práce na zakázce a případně sladěny s ostatními zakázkami za účelem co nejvyšší efektivity a vyuţití jak personálních tak nepersonálních zdrojů. Pokud je vše zhotoveno dle plánu, zakázka je předána odběrateli. Před ukončením procesu je ještě zakázka zhodnocena manaţery firmy, jsou shrnuty náklady na zakázku a vypočítán celkový zisk. Tyto údaje jsou pak vyuţity při stanovení ceny obdobného projektu.

26


Obr. 3.1: Diagram pracovního procesu.

27


Doménový model Na obrázku 3.2 je zobrazen doménový model aplikace. Ukazuje atributy, které se zaznamenávají u jednotlivých agend, a naznačuje mezi nimi logické vazby. class Domain Obj ects Poptáv ka + + + + + +

Datum: date Klient: Kontakt č. nabídky: string Text: string Poznámka: string Místo stavby: string

Kontakt + + + + + + + + + + + + + + + +

Odběratel

«select element» + Místo stavby - okres: string + Místo stavby - psč: string

Nabídka + + + + + + + + + + + + +

BM200: int BM250: int BM320: int ozn. Panelu: string Druh dodávky: string Předpokládaná realizace: date Důvod nezískání: string Platnost cenové nabídky: date Jeřáb: boolean Doprava: boolean Šéfmontáž: boolean Patra: int Balkon: boolean

Jméno/Společnost: string Zodpovědná osoba: string Email: string Adresa: string Město: string PSČ: string Stát: string Telefon: string Fax: string IČ: string DIČ: string Banka: string Číslo účtu: string Kód banky: string www: string Poznámka: string

Dodav atel

«select element» + Stav zakázky: string

Zakázka + + + + + + + + + + + +/ +/ +/ +/ +/ + + +/ + +

ID: int Smlouva SPI: string BM200: int = 0 BM250: int = 0 BM320: int = 0 FP: string FV: string DL: string SPD: string PD: string Doklad železo: string Datum montáže: date Cena panely: double Cena řezy: double Cena filigrány: double Cena ostatní: double Doklad doprava: string Počet aut: int Hmotnost: int Cena doprava: double Cena jeřáb: double Doklad jeřáb: string

Objednávka + + + + +

Č. objednávky: int Datum objednávky: date Datum odeslání: date Poznámka: string Text: string

Faktura + + +

Číslo faktury: string Částka: double Popis: string

«select element» + Typ jeřábu: string

Smlouv a o dílo + + + + + + + + + + +

Obj ednáv ka Sav as

Obj ednáv ka Plaso

Datum uzavření: date ad 1.1: string Patro: int ad 1.2: string ad 2.1 místo stavby: string ad 3.1 místo plnění: string ad 5.1 termín montáže: string Datum zaplacení zálohy: date ad 4.1 záloha: int ad 4.2 doplatek: int Text faktury: string

«select element» + DPH: int + ad 4.1 typ: string

Obr. 3.2: Doménový model.

28

Obj ednáv ka Goldbeck

Obj ednáv ka železo

Obj ednáv ka doprav a + + + + + + + + + + + + + + + + + + + + + +

ID: int Datum objednávky: dat = now() Dodavatel: Dodavatel Místo nakládky: string Datum nakládky: date Čas nakládky: string Datum a čas vykládky: datetime Místo vykládky: string Kontaktní osoba vykládky: string Počet palet: int Druh zboží: string Max. délka panelu: double Váha nákladu: int Dispečer: int Vozidla do 5t: int Smluvní cena do 5t: int Vozidla do 9t: int Smluvní cena do 9t: int Vozidla do 24t: int Smluvní cena do 24t: int Řidiči: string Poznámka: string

+ +

Místo vykládky choice: string Způsob vyložení: string

Obj ednáv ka j eřáby + + + + + + + +

Datum objednávky: date Datum dodání: date Čas dodání: string Místo stavby: string Typ jeřábu: string Operace: string Kontakt: string Poznámka: string

KAPITOLA 4. NÁVRH ŘEŠENÍ

Kapitola 4 Návrh řešení Kapitola stručně popisuje návrh, jak bude řešeno zaznamenávání potřebných agend a které objekty a struktury WSS k tomu budou pouţity.

Definice webu Web bude postaven na základě vestavěné WSS šablony „Blank site“ je to šablona neobsahující ţádné seznamy ani obsah a je tedy vhodná pro řešení, ve kterém se definují seznamy vlastní.

Typy obsahu Pro kaţdou evidovanou agendu se vytvoří jeden typ obsahu, který bude vycházet z datového modelu původní aplikace. Vlastní typy obsahu umoţní se záznamy v seznamech lépe pracovat a také na ně bude navázána další funkcionalita, jako upravené kontextové menu a odkazy na vlastní aplikační stránky pro zobrazení tiskových sestav. Ta by mohla být navázána i přímo na seznamy, ale pouţití typů obsahu zpřehledňuje aplikaci a vytváří dobrý základ pro její budoucí rozšiřování. Aţ na odběratele a dodavatele budou veškeré typy obsahu vycházet ze základního typu item a jejich poloţky budou explicitně definovány. Typy odběratel a dodavatel budou vycházet z vestavěného typu contact, který rozšíří o další nutné poloţky. Díky zdědění poloţek z typu contact budou oba typy kompatibilní s aplikací MS Outlook a bude tak umoţněn jejich import a export. Obrázek 4.1 ukazuje, jaké typy budou vytvořeny a jejich dědičné vazby.

29

KAPITOLA 4. NÁVRH ŘEŠENÍ cmp ContentType Generalize

Item

«ContentType» Poptáv ka

«ContentType» Contact

«ContentType» Nabídka «ContentType» Zakázka «ContentType» Smlouv a o dílo «ContentType» Faktura «ContentType» Obj ednáv ka

«ContentType» Dodav atel «ContentType» Odběratel

Obr. 4.1: Návrh typů obsahu.

Seznamy Kaţdá agenda, jeţ se bude v systému evidovat, bude zaznamenávána v seznamu. Budou vytvořeny definice seznamů na základě vlastních typů obsahu vycházejících z datového modelu původní aplikace. Z některých definic bude moţno vytvořit pouze jednu instanci seznamu, neboť vytvoření více instancí by nedávalo smysl. Naopak u definic objednávek nebo faktur budou uţivatelé vytvářet instancí více a jednotlivé seznamy si dle potřeb a typu objednávek, respektive faktur, ještě přizpůsobovat. Bylo by zbytečné vytvářet pro kaţdý typ objednávky vlastní definici seznamu, jelikoţ si jsou dost podobné a nepatrné rozdíly se vyřeší přidáním sloupců v uţivatelském rozhraní. Stejně tak pro odběratele a dodavatele stačí vytvořit jednu definici seznamu, neboť informace, které se o nich zaznamenávají, jsou shodné. Rozdíl mezi odběratelem a dodavatelem je určen typem obsahu. Pro zajištění kompatibility s aplikací MS Outlook jsou definice seznamů odběratele a dodavatele opět zaloţeny na vestavěné definici WSS contacts. Diagram na obrázku 4.2 zobrazuje definice i konkrétní instance seznamů, které budou vytvořeny jako výchozí obsah webu, včetně základních WSS definic, ze kterých vycházejí.

30

KAPITOLA 4. NÁVRH ŘEŠENÍ

Obr. 4.2: Návrh seznamů.

Komponenty a řešení Kaţdá agenda bude tvořit jeden balíček features. Veškerá funkcionalita bude instalována jako feature nejen z důvodu přehlednosti celého řešení, ale také aby mohla být kdykoliv deaktivována, nebo pouţita na jiném webu. Diagramy 4.3 a 4.4 zobrazují řešení tvořící vţdy jednu agendu, skládající se z jednotlivých features přidávajících potřebnou funkcionalitu.

31

KAPITOLA 4. NÁVRH ŘEŠENÍ Balíček řešení odběratelů a dodavatelů:

Obr. 4.3: Řešení kontakty. Balíček řešení smluv o dílo:

Obr. 4.4: Řešení smlouvy o dílo.

32

KAPITOLA 5. IMPLEMENTACE

Kapitola 5 Implementace Kapitola na konkrétních příkladech ukazuje, jak byly rozšířeny a přizpůsobeny WSS k vytvoření portálového řešení pro sdílení informací v konkrétní firmě.

Komponenty Feature je mechanismus pro definování a aktivaci komponent webu. V projektu je vyuţívám pro nasazení veškerých funkcionalit. To umoţňuje jejich jednoduchou správu, v nastavení sítě se dá jednoduše jakákoliv funkcionalita deaktivovat a opět aktivovat. Všechny vytvořené features mají prefix WSS_TEMA_ pro rozpoznání, ţe patří k danému řešení. V celém řešení je téměř padesát features a kaţdá řeší určitou funkcionalitu aplikace.

Obr. 5.1: Features. Feature pro nasazení definice seznamu poptávek:

Vlastní položky Základní sloupce, které WSS nabízejí, nebyly pro řešení vhodné a bylo výhodnější si definovat sloupce vlastní. Pro kaţdý seznam byla vytvořena feature, která přidává sloupce pouţívané v seznamu do kolekce webů. Její název je vţdy odvozen od agendy, kterou seznam eviduje, její syntaxe je: WSS_TEMA_COLUMNS_AGENDA. Sloupce byly vytvořeny, aby co nejlépe vystihly zaznamenávanou poloţku, svými výchozími hodnotami zjednodušily práci uţivatelům aplikace a restrikcemi znemoţnily zadávat nemyslná data. Níţe je uvedeno několik definovaných poloţek. Sazba DPH ze smlouvy o dílo: 9 19

Stav zakázky: Nová Zahájeny práce Ukončená <MAPPINGS> <MAPPING Value="1">Nová <MAPPING Value="2">Zahájeny práce <MAPPING Value="3">Ukončená Nová

34

KAPITOLA 5. IMPLEMENTACE Problém vznikl při definování odkazových poloţek, takzvaných Lookup fields, to jsou poloţky, které odkazují do jiného seznamu a zobrazují z něho některý z jeho vlastních sloupců. V aplikaci jsou pouţívány ke spojení agend s dodavateli a odběrateli a pro chod systému jsou tyto relace klíčové. Problém je v tom, ţe pokud definujeme poloţku pomocí CAML, musíme zadat unikátní identifikátor seznamu, na který lookup ukazuje. Ten ale v době definice neznáme, WSS totiţ kaţdému seznamu přidělí identifikátor aţ při vytvoření jeho instance a není ţádný způsob jak ho určit dopředu. To velice ztěţuje práci s těmito poloţkami a téměř znemoţňuje vytváření relací pomocí CAML. Řešením je tedy pouţít jinou cestu definice lookup poloţek. První moţností je přidat poloţku přes uţivatelské rozhranní WSS. Řešení je to nejjednodušší, ale určitě ne komfortní při vytváření komplexních řešení. Další způsob je vyuţití objektového modelu WSS a poloţku přidat řízeným kódem. using (SPWeb oSPWeb = properties.Feature.Parent as SPWeb) { SPList fromList = oSPWeb.Lists["Odběratelé"]; SPList toList = oSPWeb.Lists["Zakázky"]; if (!toList.Fields.ContainsField("Odběratel")) { toList.Fields.AddLookup("Odběratel", fromList.ID, true); toList.Fields["Odběratel"].Group = "WSS TEMA"; } }

Pro

přidání

lookup

poloţek

je

pouţita

feature,

se

syntaxí:

WSS_TEMA_LIST_TOLIST_LOOKUP_FromList, tyto features mají registrované event handlery, které při jejich aktivaci vytvoří poloţku a při deaktivaci ji zas odstraní. Poslední nevýhodou je, ţe v řízeném kódu nemůţeme určit pořadí poloţek zobrazovaných na formuláři. Výsledekem je, ţe lookup poloţka je v nich zobrazena na posledním místě. Toto pořadí je ovšem moţno měnit uţivatelsky. Celkem je definováno přes 100 vlastních poloţek, které se pouţívají napříč celým řešením.

Typy obsahu Typy obsahu umoţňují sdruţovat poloţky do jednoho logického objektu. Pro kaţdou agendu, byl vytvořen typ obsahu, který je sloţen ze všech poloţek, jeţ agenda eviduje.

Vlastní typy obsahu jsou odvozeny od základního typu item, který obsahuje pouze poloţku název. Jen vlastní typy odběratel a dodavatel jsou odvozeny od Contacts a to kvůli kompatibilitě s aplikací MS Outlook a moţnostem jejich exportu. Vlastní typy obsahu nevyuţívám k dalšímu dědění nebo polymorfismu, ale především k asociaci s vlastními akcemi. Z jednoho typu obsahu umoţňuji vytvořit jiný převzetím shodných poloţek, například z poptávky můţe být vytvořena nabídka a z nabídky zase zakázka. Do budoucna také předpokládám jejich vyuţití pro rozšíření funkcionality, například vyuţití event handlerů. Funkcionalita se většinou lépe svazuje s typy obsahu, neţ přímo s konkrétními seznamy, a proto je také pouţívám. Vytvořené typy obsahu: Odběratel Dodavatel Poptávka Nabídka Zakázka Smlouva o dílo Objednávka Faktura Nasazení

probíhá

pomocí

feature

se

syntaxí

názvu:

WSS_TEMA_CONTENTTYPE_Agenda.

Seznamy Většina seznamů, které jsou v aplikaci pouţity, jsou vlastní definované seznamy. Základní seznamy, které WSS nabízejí, jsou příliš obecné a pro takto konkrétní aplikaci se nehodí je upravovat. Je tedy nutné vytvořit si vlastní. Pro kaţdý typ agendy byl vytvořen vlastní seznam, ve kterém se budou data uchovávat. Definice seznamů Definice seznamu umoţňuje specifikovat obsah a zobrazení seznamu. Můţeme určit poloţky, které bude seznam obsahovat, typy obsahu, které půjdou v seznamech vytvářet, a definovat formuláře pro zakládání, editaci nebo prohlíţení záznamů. Vytvořené definice vlastních seznamů: 36

KAPITOLA 5. IMPLEMENTACE Kontakty – definice pro evidenci odběratelů a dodavatelů. Poptávky – evidence poptávek. Nabídky – evidence nabídek. Zakázky – evidence zakázek. Smlouvy o dílo – evidence smluv o dílo. Objednávky – definice pro seznamy objednávek, obsahuje základní poloţky, které by měly být v kaţdé objednávce. Podle typu objednávky si pak budou uţivatelé přidávat sloupce do konkrétních instancí seznamů. Faktury – definice pro evidenci, stejně jako u objednávek obsahuje jen základní poloţky a další si budou uţivatelé přidávat dle potřeby a typu faktur. Pokud vytváříme definici seznamu, musíme v něm explicitně definovat veškeré poloţky, které bude seznam pouţívat a to i přesto, ţe je máme definovány v nějaké feature nebo typu obsahu. Definice seznamu musí vţdy obsahovat kompletní definici poloţek. Část definice seznamu objednávek: <MetaData> ...

Součástí definice seznamů jsou i formuláře pro zaloţení, editaci a prohlíţení poloţek. Formuláře pro zaloţení záznamu přebírají hodnoty z querystringu a umoţňují podle toho předvyplnit hodnoty vytvářeného záznamu. Například pokud vytváříme z poptávky nabídku nebo z nabídky zakázku. Do budoucna by měly formuláře obsahovat i další informace, které co nejvíce zjednoduší práci uţivatelům a zpřehlední systém. Například u formuláře zobrazení

37

KAPITOLA 5. IMPLEMENTACE uţivatele jeho dosavadní poptávky, nabídky, zakázky, u formuláře zakázky zda k němu existuje nabídka a podobně. Šablony seznamů Pro kaţdou definici seznamu existuje šablona, která umoţňuje vytvoření seznamu z uţivatelského rozhraní. Většina seznamů se ale bude vytvářet pomocí feature, jsou to seznamy, u kterých můţe existovat jen jedna instance, a jsou nezbytné pro chod systému. Ty se vytváří při jeho zaloţení a jsou na nich závislé další feature. U nich jsou šablony v této aplikaci pro uţivatele zbytečné, protoţe není moţné vytvořit více instancí těchto seznamů, mohly by se ale hodit při nasazení na jiném webu, kde na ně nebude navázána další funkcionalita. Šablony seznamů se vyuţijí u objednávek, kde uţivatel sám vytváří instance seznamů pokaţdé, kdy mu přibude nějaký druh objednávky a stejně tak i u faktur. Syntaxe

názvu

feature

pro

nasazení

šablony

seznamu

je:

WSS_TEMA_LIST_NazevSeznamu. Definice šablony seznamu objednávek:

Instance seznamů Za pomocí feature jsou vytvořeny všechny seznamy, které jsou potřeba k chodu systému. V různých částech aplikace se často pouţívají odkazy URL, nebo přímo názvy k zpřístupnění seznamu, některé feature nemohou být aktivovány, pokud neexistuje určitý seznam. Proto je nutné definovat je pomocí pevných instancí a ne z uţivatelského rozhraní pomocí šablon seznamů. Snahou je také omezit nutnost dodatečných konfigurací v uţivatelském rozhranní na minimum. Syntaxe názvu je: WSS_TEMA_LIST_AGENDA_Instance. Definice instance poptávky: <Elements Id="d1904e96-1e47-4946-baae-f5bc795289bd" xmlns="http://schemas.microsoft.com/sharepoint/">

Instance seznamů:

38

KAPITOLA 5. IMPLEMENTACE Definice seznamu

Instance seznamu

Kontakty

Odběratelé Dodavatelé

Poptávky

Poptávky

Nabídky

Nabídky

Zakázky

Zakázky

Smlouvy o dílo

Smlouvy o dílo

Objednávky

Objednávky Goldbeck Objednávky Savas Objednávky Plaso

Faktury

Faktury přijaté

Tab. 5.1: Definice seznamů a jejich instance.

Vlastní aplikační stránky WSS umoţňuje pouţívat na své platformě vlastní aplikační stránky. Těmi můţeme řešit funkcionalitu, kterou nám WSS jiným způsobem nenabízí. Vlastní stránky jsou v aplikaci pouţívány pro zobrazení tiskových výstupů záznamů. Z aplikace se tisknou nabídky a smlouvy pro odběratele nebo také objednávky pro dodavatele. Kaţdá agenda můţe mít libovolný počet tiskových výstupů. Vlastní aplikační stránky jsou ASP.NET stránky s kódem v pozadí, generujícím obsah podle záznamu v seznamu. Nasazovány jsou jako moduly pomocí feature. Definice modulu tiskové sestavy pro smlouvy o dílo: <Module Name="Smlouva_report" Url="Reports/Smlouvyodilo">

Vlastní akce Vlastní akce umoţňují přidávat příkazy do kontextových menu WSS. V aplikaci pouţívám vlastní akce pro vytváření nových záznamů, nebo pro zobrazení jejich tiskových sestav. Umístění příkazů do kontextových menu velmi zpříjemňuje a usnadňuje vytváření nových záznamů. Například přímo z odběratele je moţné vytvořit poptávku, nabídku nebo zakázku pouhými dvěma kliky myši. Stejně tak lze vytvořit z poptávky nabídku nebo z nabídky zakázku. Vlastní akce jsou přidány všude, kde mohou usnadnit práci se systémem. Definice vlastních akcí odběratele:
39

KAPITOLA 5. IMPLEMENTACE

RegistrationId="0x010600B25DE05743CC44c480C87B5791CEDADC" Location="EditControlBlock" Sequence="10" Title="Vytvořit poptávku">
Event Handlery Event handlery umoţňují odchytávat události záznamů, seznamů, typů obsahu nebo feature. Kaţdý seznam má definovaný event handler, který odchytává jeho události. Ty jsou v aplikaci pouţity pro zabránění odstranění nebo změně některých poloţek, důleţitých k chodu aplikace. Nejdůleţitější event handlery pro aplikaci jsou pro feature, vyuţívám je pro přidání lookup poloţky, kterou není moţné definovat pomocí CAML. Odchytávám událost FeatureActivated a FeatureDeactivating, kde poloţku přidávám, respektive odstraňuji. Syntaxe

názvu

feature

která

obsahuje

event

handlery:

WSS_TEMA_LIST_NAZEVLIST_NazevHandleru a pro handlery feature které přidávají lookup poloţky: WSS_TEMA_LIST_NAZEVLISTU_LOOKUP_LookupPolozka

40

KAPITOLA 6. NASAZENÍ

Kapitola 6 Nasazení Kapitola popisuje nasazení WSS 3.0 a vytvořeného řešení. Na obrázku 6.1 je diagram nasazení WSS. Klientským stanicím stačí k pouţívání WSS webový prohlíţeč. Hardwarové a softwarové poţadavky na server viz dodatek B.

Obr. 6.1: Diagram nasazení

Instalace WSS Windows Sharepoint Services byly nainstalovány na Microsoft Windows Server 2003 Enterprise Edition jako stand-alone instalace. To znamená, ţe všechny potřebné komponenty se nacházejí na jednom fyzickém stroji. Server slouţí jako front-end pro zpracování http poţadavků a zároveň jako back-end server s databázovým úloţištěm. Databázové úloţiště je pouţito MSSQL Embeded Edition, ve kterém se nacházejí jak konfigurační databáze, tak i databáze obsahu. Postup instalace: 1. Instalace Internet Information Services 6. 2. Instalace Microsoft .NET Framework 3.5 (dostačující je i verze 3.0).

41

KAPITOLA 6. NASAZENÍ 3. Povolení Enable ASP.NET 2.0 na IIS. 4. Instalace WSS 3.0 (instalační soubory stáhneme z webu Microsoft, pokud bychom instalovali WSS jako doplněk komponent Windows, který se nabízí, instalovali bychom verzi 2.0).

Konfigurace WSS Po instalaci je vhodné provést některé kroky nastavení. Toto nastavení se provádí v centrální administraci. Centrální administrace je webová aplikace, která je automaticky vytvořena při instalaci WSS. Umoţňuje konfigurovat a vytvářet kolekce webů přes uţivatelské rozhraní. Nastavení odchozích e-mailů Je nutné nakonfigurovat SMTP server, jenţ budou WSS pouţívat. Pokud SMTP server nenastavíme, nebude moţno vyuţívat e-mailových notifikací WSS. Nastavení příchozích e-mailů Můţeme také vyuţít zpracování příchozích e-mailů, coţ umoţní Sharepointu zpracovávat příchozí emailové zprávy, archivovat je, nebo ukládat dokumenty posílané jako přílohy. Nastavení logování a diagnostiky Velice uţitečné můţe být při vývoji nastavení úrovně logování. Můţeme nastavit, co se bude zaznamenávat, jak často a kam se budou logy ukládat. Nastavení antivirové ochrany Nastavíme, zda se mají skenovat dokumenty při downloadu, nebo uploadu a co se provede s infikovanými soubory. Můţeme uţivatelům zakázat stáhnout infikované soubory.

Vytvoření webové aplikace V centrální administraci vytvoříme novou webovou aplikaci, specifikujeme její název, port, na kterém bude dostupná, a umístění na souborovém systému. WSS automaticky vytvoří aplikaci na webovém serveru. Můţeme také specifikovat, zda se na serveru vytvoří aplikační pool, nebo můţeme zvolit některý ze stávajících. Dalším nastavením je zabezpečení, kde nastavíme poskytovatele ověření, nebo zabezpečené připojení protokolem SSL. Posledním podstatným nastavením je název a umístění databáze obsahu a nastavení serveru pro vyhledávání. Po vytvoření webové aplikace je nutné restartovat webový server, pak jiţ můţeme přidávat kolekce webů.

Vytvoření kolekce webů Na stránkách centrální administrace vytvoříme novou kolekci webů ze šablony „Blank site“. Určíme její název, popis, URL, na které bude kolekce dostupná, a zvolíme uţivatele, který

42

KAPITOLA 6. NASAZENÍ bude mít administrační práva ke kolekci. WSS uloţí kolekci do databáze obsahu webové aplikace. Prázdný web je nyní dostupný na zvolené URL.

Nasazení řešení Řešení se instaluje pomocí dávkového souboru, který musí být spuštěn uţivatelem s administrátorskými právy k systému. Obsahuje příkazy pro nahrání potřebných souborů do adresářové struktury WSS, vytvořených dynamických knihoven do GAC, nahrání jednotlivých features do aplikace WSS, kde provede jejich aktivaci. Tím vznikne řešení, které je ihned připravené k pouţití.

43

KAPITOLA 6. NASAZENÍ

44

KAPITOLA 7. TESTOVÁNÍ

Kapitola 7 Testování Kapitola popisuje testy provedené pro ověření správné funkce a stability aplikace.

Jednotkové testy Komponenty WSS nabízejí jen omezené moţnosti testování. Mnoţství komponent se totiţ definuje pouze pomocí jazyka CAML a blackbox nebo whitebox testování tak nepřipadá v úvahu. Komponenty definované pomoci CAML byly ověřovány proti jeho XML schématu, aby byla zajištěna jejich validnost. Jejich funkčnost pak byla ověřována manuálně v uţivatelském rozhraní aplikace. Pro komponenty vyuţívající řízený kód byly napsány blackbox testy ověřující správnost vykonávaného kódu.

Test použitelnosti Test pouţitelnosti byl proveden ve firmě, pro kterou je aplikace vyvíjena. Uţivatelé, kteří test prováděli, byli zaměstnanci firmy, jeţ pouţívají aplikaci, která má být nahrazena. Uţivatelům byly stručně vysvětleny změny v logice a uţivatelském rozhranní oproti původní aplikaci a bylo po nich vyţadováno, aby provedli stejné úkony, které dělají ve stávajícím systému. Cílem bylo ověřit, zda jsou schopni s aplikací pracovat a zda jim umoţní vést potřebné agendy a vytvářet nutné výstupy. Uţivatelé neměli problém přizpůsobit se novému uţivatelskému rozhranní a uvítali zjednodušení, jeţ jim aplikace přináší. Tím bylo ověřeno, ţe dokáţe nahradit stávající systém.

Zátěžové testy I kdyţ není očekáváno velké vytíţení serveru, byly provedeny testy, aby bylo ověřeno, ţe aplikace je schopná pojmout určitý objem dat a zpracovat větší počet poţadavků najednou. Byly provedeny dva typy zátěţových testů: Test objemu (Capacity test) Test objemu byl proveden pomocí nástroje The SharePoint 2007 Test Data Population Tool (WSSDW.exe), který dokáţe do WSS generovat testovací data. Byla vytvořena testovací síť, kde byla kaţdá agenda naplněna 10 000 záznamy. Do knihovny dokumentů pak bylo vloţeno 10GB testovacích souborů. Po nahrání dat byla ověřována rychlost a pouţitelnost aplikace. I přesto, ţe se takové mnoţství záznamů v aplikaci nikdy neobjeví, nebyl zaznamenán ţádný znatelný pokles ve výkonu. 45

KAPITOLA 7. TESTOVÁNÍ Test výkonu (Performance test) Test výkonu byl proveden pomocí nástroje The Web Application Stress Tool. Ten umoţňuje zasílat HTTP poţadavky na server a vyhodnocovat odpovědi zaslané serverem. Testovány byly stránky zobrazující jednotlivé seznamy, stánky zobrazující konkrétní záznamy, editační formuláře a formuláře pro vytvoření nových záznamů. Kaţdou stránku otevíralo současně pět vláken, coţ je přibliţný počet uţivatelů pouţívajících aplikaci. Z testu vyplynulo, ţe zejména editační formuláře a formuláře pro vytvoření nového záznamu se někdy načítají pomaleji, extrémy trvaly i několik sekund.

Obr. 7.1: Výsledek zátěţového testu zobrazovacího formuláře smluv o dílo

46

KAPITOLA 8. ZÁVĚR

Kapitola 8 Závěr Prvním cílem této práce bylo zjistit, jaké moţnosti nabízejí produkty Microsoft Windows Sharepoint Services a Microsoft Office Sharepoint Server v oblasti týmové spolupráce a především moţnosti jejich rozšíření a vlastního vývoje na této platformě. Práce ve své teoretické části popisuje architekturu této platformy a způsoby vytváření a nasazování vlastních řešení. Dalším cílem práce bylo na základě získaných znalostí implementovat prototyp aplikace ve vybrané firmě. Vybrána byla firma Tema, s.r.o., která hledala náhradu za stávající systém pro evidenci objednávek, a poptávala aplikaci umoţňující lepší spolupráci zaměstnanců v rámci podpory prodeje. Byl proveden rozbor aplikace, jeţ firma nyní pouţívá a analýza ustáleného pracovního postupu. Na jejich základě byl vytvořen návrh implementace Windows Sharepoint Services 3.0, který byl proveden, aby co nejvíce vyuţil moţností, jenţ tato platforma nabízí a vytvořil dobrý základ i pro budoucí rozvoj aplikace. Implementace proběhla podle návrhu, kde kaţdá funkcionalita, jeţ systém má, je instalována jako komponenta a je moţno ji kdykoliv deaktivovat přímo z uţivatelského rozhranní aplikace. Stejně tak i do budoucna budou veškeré přidávané funkce instalovány jako komponenty rozšíření. Práce oba své cíle splnila. Byly popsány moţnosti vývoje na platformě Windows Sharepoint Services a ve vybrané firmě byl implementován prototyp aplikace pro týmovou spolupráci a sdílení informací. Prototyp, který by měl v nejbliţší době nahradit stávající aplikaci, se bude dále vyvíjet podle poţadavků zákazníka a připomínek, které přijdou při jeho uţívání. Díky mechanizmům rozšíření, jeţ Windows Sharepoint Services nabízejí, je přidávání dalších funkcí a komponent bezproblémové. Windows Sharepoint Services jsou výborným produktem v oblasti podpory týmové spolupráce. Ve svém základu nabízejí mnoho funkcí a umoţňují jednoduše vést běţné agendy. Sami uţivatelé je mohou upravovat v uţivatelském rozhraní, přidáváním dalších poloţek, nebo vytvářením různých datových pohledů. Avšak při potřebě konkrétních řešení naráţejí vývojáři celkem brzo na jejich hranice a moţnosti přizpůsobení mohou být nedostatečné, nebo přinejmenším jejich řešení neadekvátně sloţité. Největším jejich nedostatkem je špatná podpora relačního přístupu k datům, která je v dnešní době základem většiny aplikací. Proto je velmi důleţité brát při rozhodování pouţití Windows Sharepoint Services v potaz jejich hranice a zhodnotit,

zda

jsou

schopny

splnit

poţadavky,

které

jsou

na

ně

kladeny. 47

KAPITOLA 8. ZÁVĚR

48

Literatura [1]

Kutěj, Tomáš. SharePoint technologie - Historie. http://www.microsoft.com. [Online] Microsoft, 15. 6 2007. [Citace: 1. 6 2009.] http://www.microsoft.com/cze/technet/clanky/sharepoint_tech.mspx.

[2]

Miles Consulting Corp. MOSS 2007 vs. WSS 3.0. Miles Consulting Corp. [Online] Miles Consulting Corp, 2007. [Citace: 15. 5 2009.] http://www.milesconsultingcorp.com/SharePoint-Portal-2007-Version-Comparisonbetween-MOSS2007-and-WSS3.aspx.

[3]

TechNet. TechNet. [Online] Microsoft. [Citace: 1. 5 2009.] http://technet.microsoft.com/en-us/default.aspx.

[4]

Microsoft. Server and Site Architecture: Object Model Overview. msdn. [Online] Microsoft, 2009. [Citace: 1. 5 2009.] http://msdn.microsoft.com/enus/library/ms473633.aspx.

[5]

Microsoft. Onet.xml. msdn. [Online] Microsoft, 2009. [Citace: 1. 5 2009.] http://msdn.microsoft.com/en-us/library/ms474369.aspx.

[6]

Ted Pattison, Daniel Larson. Inside Microsoft Sharepoint Services 3.0. Redmond : Microsoft Press, 2007.

[7]

Kolektiv autorů. Profesional Sharepoint 2007 Development. Indianapolis : Wiley Publishing, 2007.

[8]

Microsoft. Schema.xml. msdn. [Online] Microsoft, 2009. [Citace: 1. 5 2009.] http://msdn.microsoft.com/en-us/library/ms459356.aspx.

[9]

Webcasty. msdn. [Online] [Citace: 10. 1 2009.] http://www.microsoft.com/cze/msdn/webcasts/default.mspx.

[10] Windows SharePoint Services Developer Center. msdn. [Online] Microsoft. [Citace: 1. 5 2009.] http://msdn.microsoft.com/en-us/sharepoint/default.aspx. [11] Grounding.co.za. Grounding.co.za. [Online] [Citace: 1. 5 2009.] http://grounding.co.za/. [12] Microsoft, MSFTInternal a sptdatapop. SharePoint 2007 Test Data Population Tool. Codeplex. [Online] Microsoft, 5. 12 2006. [Citace: 1. 5 2009.] http://www.codeplex.com/sptdatapop. [13] Baer, Bill. Stress Testing Microsoft Office SharePoint Server 2007/Windows SharePoint Services 3.0. Technet. [Online] Microsoft, 2. 7 2007. [Citace: 1. 5 2009.] http://blogs.technet.com/wbaer/archive/2007/08/02/stress-testing-microsoft-officesharepoint-server-2007-windows-sharepoint-services-3-0.aspx. [14] O'Connor, Errin. Mistrovství ve Windows Sharepoint Services 3.0. Brno : Computer Press, 2008. 49

Dodatek A Slovník pojmů a použitých zkratek A.1 Slovník pojmů .NET – Vývojová platforma společnosti Microsoft. After event – Událost, která je vyvolána po té, co nastane nějaká akce. Assembly – V prostředí .NET je to kompilovaný kód (sestavení) buď jako spustitelný soubor, nebo dynamická knihovna. Back-end server – Server s datovým úloţištěm. Before event – Událost, která je vyvolána před tím, neţ nastane nějaká akce. Blackbox testování – Testuje komponenty pouze na základě vstupů a výstupů bez ohledu na jejich implementaci. Dokument management systém – Software pro sdílení, verzování a veškerou správu dokumentů. Event handler – Metoda v event receiveru, která je vyvolána určitou událostí. Event receiver – Třída obsahující event handlery. Front-end server – Aplikační server obsluhující HTTP poţadavky klientů. Global Assembly Cache – Centrální sdílené úloţiště pro .NET assemblies. Internet Infomation services – Sada webových sluţeb vyvíjená společností Microsoft. Jedná se především o webový server, ale také FTP,FTPS nebo SMTP. Stand alone instalace – Instalace, kde je aplikační i datový server na jednom fyzickém stroji. Strong name assembly – Sestavení, které je jednoznačně identifikovatelné pomocí veřejného klíče. Stsadm – Konzolová aplikace pro správu produktů Sharepoint. Whitebox testování – Testy probíhají na základě znalosti implementace komponenty, testuje všechny moţné průchody kódem. Workflow – Pracovní proces.

50

A.2 Seznam zkratek ASP

-

Active Server Pages

CAML -

Collaborative Application Markup Language

CMS

-

Content Management System

DLL

-

Dynamic-link library

GAC

-

Global Assembly Cache

GUID -

Globally Unique Identifier

HTTP -

Hypertext Transfer protocol

IIS

-

Internet Information Services

MS

-

Microsoft

MSSQL-

Microsoft SQL Server

MSDN -

Microsoft Developer Network

MOSS -

Microsoft Office Sharepoint Server

SMTP -

Simple Mail Transfer Protocol

SP

-

Service Pack

SQL

-

Structured Query Language

URL

-

Uniform Resource Locator

WSS

-

Windows Sharepoint Services

WWF -

Windows Workflow Foundation

WYSIWYG - What You See Is What You Get XAML -

Extensible Application Markup Language

XML -

Extensible Markup Language

51

Dodatek B Hardwarové a softwarové požadavky Stand-alone instalace Hardwarové požadavky Komponenta

Minimum

Doporučeno

Procesor

2,5 GHz

2 x 3 GHz

Operační paměť

1GB

2GB

Disk

NTFS, 3GB volného místa

NTFS, 3GB volného místa + místo na prostory webů

Rozlišení

1024 x 768

1024 x 768 +

Síť

56 Kbps mezi serverem a

Vyšší neţ 56 Kbps mezi

klientskými stanicemi

serverem

a

klientskými

stanicemi Softwarové požadavky Operační systém Windows Sharepoint Services 3.0 se instalují na Windows Server 2003 SP1, nebo novější. Windows SharePoint Services 3.0 s SP1 je moţné instalovat na Windows Server 2008. Databázový server SQL Server Embededd Edition někdy nazývána Windows Internal Database (je v základní instalaci instalována automaticky) SQL Server 2000 SP4, nebo Microsoft SQL Server 2005 SP1 a novější Windows SharePoint Services 3.0 s SP1 obsahují podporu pro SQL Server 2008 Ostatní Internet Explorer 6.0 včetně všech aktualizačních balíčků, nebo Internet Explorer 7.0. Internet Information Services 6.0, pro Windows Server 2003 Internet Information Services 7.0, pro Windows Server 2008 ASP.NET v2.0.50727 a Microsoft .NET Framework 3.0, nebo Microsoft .NET Framework 3.5

Instalace v serverové farmě Hardwarové i softwarové poţadavky se liší jen minimálně od stand-alone instalace. Mezi servery ve farmě musí existovat spojení o rychlost 100 Mbps nebo vyšší. Není moţné pouţít Windows Internal Database jako datové úloţiště.

52

Dodatek C Struktura Souborů ve WSS \ADMISAPI Sloţka obsahující soubory pro centrální administraci systému. \BIN Adresář, který obsahuje všechny důleţité binární soubory - dynamické knihovny a aplikace jako třeba STSADM. Obsahuje podadresáře obsahující binární sobory pro různé jazykové mutace. \CONFIG Sloţka obsahující konfigurační soubory a soubory zdrojů (.resx). \Data Sloţka do které se odkládají data indexovací sluţby. \HCCab\LCID Obsahuje mnoţství .cab souborů s definicí a obsahem pouţívaným systémem nápovědy Sharepointu. Kaţdá sloţka je specifická pro jednu jazykovou mutaci. \Help Sloţka obsahující nápovědu pro konfigurační wizard. \ISAPI Sloţka obsahující webové sluţby WSS, dodatečné knihovny, zdroje nebo konfigurační soubory vyuţívané webovými sluţbami. \ISAPI\HELP Adresář obsahuje všechny soubory nápovědy pouţívané WSS. Obsahuje další sloţky pro kaţdý nainstalovaný jazyk. \LOGS Obsahuje soubory logů. \Resources Obsahuje soubor zdrojů core.resx, slouţící k vytváření jazykových lokalizačních balíčků, a další lokalizované soubory zdrojů. \TEMPLATE Adresář obsahující strukturu sloţek, v nichţ jsou soubory tvořící weby WSS, jako definice, šablony, features, webové části, nebo stránky .aspx.

53

Dodatek D Definice elementů WSS D.1 Site Definition (onet.xml) <Modules> <Modules> <ServerEmailFooter>ServerEmailFooter

54

D.2 Feature (feature.xml)

55

D.3 Field <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

56

D.4 Content Type <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

57

D.5 List definition (schema.xml) <MetaData>

58

D.6 List Template <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

59

D.7 List Instance <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> nějaký názaev Pro příklad jméno

60

D.8 Custom Action <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

61

D.9 Module <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Module Name="Nazev" Url="url_modulu">

62

D.10 Workflow Template <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Workflow Name="Název workflow" Description="Popis..." Id="GUID workflow" CodeBesideClass="SPsequentialWF_testing.Workflow1" CodeBesideAssembly="WFassembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=405531eaf796268e" AssociationUrl="_layouts/WF/AssociationForm.aspx" InstantiationUrl="_layouts/WF/InstantiationForm.aspx" > <MetaData> Manual <StatusPageUrl>_layouts/WrkStat.aspx

63

D.11 Solution (manifest.xml) <Solution SolutionId="b7d5cf8e-8456-4a3b-9daa-d7e477855285" xmlns="http://schemas.microsoft.com/sharepoint/"> <SafeControls> <SafeControl Assembly="assembly.class" Namespace="namespace" TypeName="type" Safe="True" />

64

Dodatek E Obsah přiloženého CD /BP – zdrojové texty bakalářské práce. /PROJECTS – zdrojové kódy, projekty Visual Studia 2008. /SOLUTION – balíček řešení určený pro nasazení na WSS. Readme.txt – soubor s popisem CD.

65

Software pro sdílení informací ve firemních týmech

Recommend Documents