Univerzita Karlova v Praze

Univerzita Karlova v Praze

Matematicko-fyzikální fakulta

DIPLOMOVÁ PRÁCE

Bc. Michal Foltýn Využití systémů Content Management ve státní správě Katedra softwarového inženýrství

Vedoucí diplomové práce: prof. RNDr. Jaroslav Král, DrSc.

Studijní program: Informatika, softwarové systémy 2010

Na tomto místě bych rád poděkoval rodině za jejich podporu a důvěru. Děkuji svému vedoucímu prof. RNDr. Jaroslavu Královi, DrSc. za jeho ochotu, věcné připomínky a rady. Poděkování patří také Rastislavu Maskaľovi ze společnosti Xperiensis, Ondřeji Koppovi ze společnosti CESA a Pavlu Pelantovi a Jiřímu Bartákovi z Generálního ředitelství cel za možnost psát diplomovou práci o prostředí Celní správy.

Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce.

V Praze dne 06.12.2010

Michal Foltýn

Obsah

1

Úvod ............................................................................................................................. 11 1.1 Cíl práce ................................................................................................................. 11 1.2 Terminologie ......................................................................................................... 12 2 CMS .............................................................................................................................. 15 2.1 Popis ...................................................................................................................... 15 2.1.1 Vytváření obsahu ........................................................................................... 17 2.1.2 Správa obsahu ................................................................................................ 18 2.1.3 Publikace ........................................................................................................ 18 2.1.4 Prezentace ..................................................................................................... 19 2.1.5 Integrace s externími systémy ....................................................................... 19 2.2 Využití CMS ve státní správě ................................................................................. 19 2.2.1 Celní správa České republiky ......................................................................... 20 2.2.2 Ministerstvo zahraničí České republiky ......................................................... 21 2.2.3 Ministerstvo financí České republiky ............................................................. 22 2.2.4 Ministerstvo průmyslu a obchodu ................................................................. 23 2.3 Využití CMS v soukromé sféře............................................................................... 24 2.4 Srovnání CMS systémů .......................................................................................... 25 2.4.1 Komerční nebo OpenSource CMS systémy ................................................... 26 2.4.2 Použité vývojové prostředí ............................................................................ 26 2.4.3 CMS systémy dle rozsahu .............................................................................. 27 2.4.4 CMS systémy dle cílové skupiny uživatelů ..................................................... 27 2.4.5 Dle implementace administračního prostředí ............................................... 27 3 Srovnání MCMS a MOSS .............................................................................................. 29 3.1 Popis Microsoft Content Management System 2002 ........................................... 29 3.2 Popis Microsoft Office Sharepoint Server 2007 .................................................... 31 3.2.1 Nevýhody ....................................................................................................... 34 3.3 Srovnání................................................................................................................. 36 3.3.1 Vytváření stránek ........................................................................................... 36 3.3.2 Schvalování .................................................................................................... 37 3.3.3 Publikace ........................................................................................................ 37 3.3.4 Způsob ukládání dokumentů a obrázků ........................................................ 37 3.3.5 Přístupnost ..................................................................................................... 38 3.3.6 Vyhledávání.................................................................................................... 38 3.4 Použití MCMS na Celní správě .............................................................................. 38 4 Analýza migrace ........................................................................................................... 41 4.1 Cíl ........................................................................................................................... 41 4.2 Požadavky.............................................................................................................. 42 4.3 Rozdělení rolí......................................................................................................... 43 4.4 Design webových stránek ..................................................................................... 44 4.4.1 Šablony........................................................................................................... 46 4.4.2 Lokalizace ....................................................................................................... 47

4.5 Topologie ...............................................................................................................47 4.5.1 Operační systém.............................................................................................48 4.5.2 Databázový systém ........................................................................................48 4.5.3 Webové servery .............................................................................................49 4.5.4 Databázové servery........................................................................................49 4.5.5 Servery pro indexování a vyhledávání ...........................................................49 4.5.6 Redakční prostředí .........................................................................................50 4.5.7 Výsledné doporučení fyzické architektury .....................................................50 4.6 Možnosti migrace dat z MCMS do MOSS ..............................................................51 4.6.1 Migrace dat pomocí nástroje v MOSS............................................................51 4.6.2 Migrace dat pomocí API .................................................................................52 4.6.3 Manuální migrace ..........................................................................................52 4.7 Způsob provedení migrace dat..............................................................................53 4.7.1 Migrace stávajících aplikací............................................................................54 4.8 Školení uživatelů ....................................................................................................54 4.9 Časové termíny migrace ........................................................................................55 5 Migrace ........................................................................................................................ 57 5.1 Postup migrace ......................................................................................................57 5.1.1 Předpoklady ...................................................................................................57 5.1.2 Postup ............................................................................................................57 5.1.3 Nedostupnost webových stránek při migraci ................................................58 5.1.4 Postup při neúspěchu migrace ......................................................................58 5.2 Shrnutí migrace .....................................................................................................58 5.2.1 Časový průběh migrace ..................................................................................59 5.2.2 Ponaučení.......................................................................................................61 5.2.3 Návrhy na zlepšení .........................................................................................61 5.2.4 Výsledky migrace z pohledu Celní správy ......................................................62 5.2.5 Budoucí vývoj .................................................................................................63 6 Framework pro integrované aplikace do MOSS .......................................................... 65 6.1 Cíl ...........................................................................................................................66 6.2 Požadavky ..............................................................................................................67 6.3 Terminologie .........................................................................................................68 6.3.1 Tvorba a struktura stránek v ASP.NET ...........................................................68 6.3.2 Stránky v MOSS ..............................................................................................68 6.4 Analýza ..................................................................................................................70 6.4.1 Dostupné produkty na trhu ........................................................................... 70 6.4.2 Způsob integrace do MOSS ............................................................................ 70 6.4.3 Výběr aplikace pro zobrazení na stránce .......................................................71 6.4.4 Způsob vývoje aplikací ve frameworku ..........................................................72 6.4.5 Ověřování práv ...............................................................................................72 6.4.6 Logování, audit ...............................................................................................73 6.4.7 Rozšiřitelnost..................................................................................................73 6.5 Popis architektury .................................................................................................73 6.5.1 Eos.Core .........................................................................................................74 6.5.2 Eos ..................................................................................................................74 6.5.3 Eos.Components ............................................................................................74 6.5.4 Knihovny projektu Microsoft Enterprise Library ...........................................75

6.5.5 Způsob integrace aplikací .............................................................................. 75 6.5.6 Webová část................................................................................................... 76 6.5.7 Předek všech aplikačních stránek .................................................................. 76 6.5.8 Popis databáze ............................................................................................... 77 6.6 Podpora Microsoft Sharepoint Server 2010 ......................................................... 80 7 Uživatelská dokumentace ............................................................................................ 81 7.1 Předpoklady .......................................................................................................... 81 7.2 Instalace šablony do Microsoft Visual Studio ....................................................... 81 7.3 Vytvoření aplikace ................................................................................................. 81 7.3.1 Popis struktury projektu ................................................................................ 83 7.4 Přidání stránky do aplikace ................................................................................... 83 7.5 Konfigurace ........................................................................................................... 85 7.5.1 Konfigurace logování ..................................................................................... 86 7.5.2 Konfigurace cachování ................................................................................... 87 7.5.3 Konfigurace stránek a oprávnění ................................................................... 87 7.5.4 PortalSecurityDB.xml ..................................................................................... 88 7.5.5 SPActiveDirectory.xml.................................................................................... 89 7.6 Vložení css stylů a js skriptů .................................................................................. 90 7.7 Metody a vlastnosti poskytující framework.......................................................... 90 7.7.1 Logování ......................................................................................................... 91 7.7.2 Cache.............................................................................................................. 92 7.7.3 Audit ............................................................................................................... 93 7.7.4 Security Provider ............................................................................................ 93 7.7.5 Poznámky k vývoji aplikací ............................................................................. 94 7.8 Rozšíření frameworku ........................................................................................... 94 7.8.1 Nahrazení implementace vlastním řešením .................................................. 95 7.9 Dependency Injection ........................................................................................... 96 7.9.1 Použití Unity ................................................................................................... 97 7.9.2 Konfigurace Unity .......................................................................................... 97 7.9.3 Aliasy typů v Unity ......................................................................................... 98 7.9.4 Definice napojení v Unity ............................................................................... 98 7.9.5 Integrace do zdrojového kódu ....................................................................... 99 7.9.6 Přímý požadavek na objekt ............................................................................ 99 7.9.7 Napojení pomocí konstruktoru.................................................................... 100 7.9.8 Napojení pomocí Dependency atributů ...................................................... 100 7.9.9 Napojení pomocí InjectionMethod.............................................................. 101 8 Administrátorská dokumentace ................................................................................ 103 8.1 Instalace webové části ........................................................................................ 103 8.2 Konfigurace ......................................................................................................... 103 8.3 Nasazení aplikace na webové servery ................................................................ 104 8.4 Přidání aplikace do stránky ................................................................................. 104 9 Závěr .......................................................................................................................... 107 9.1 Využití výsledků diplomové práce....................................................................... 107 10 Literatura ................................................................................................................... 109

Název práce: Využití systémů Content Management ve státní správě Autor: Bc. Michal Foltýn Katedra (ústav): Katedra softwarového inženýrství Vedoucí bakalářské práce: prof. RNDr. Jaroslav Král, DrSc. E-mail vedoucího: [email protected] Abstrakt: Content Management systémy umožňují jednoduché vytváření a správu webových stránek i bez odborných programátorských znalostí. Práce popisuje využití těchto systému na Celní správě a navrhuje postup migrace z jednoho redakčního systému do druhého. Framework pro vývoj webových aplikací umožňuje vkládat tyto webové aplikace do redakčního systému a tím rozšiřovat jeho možnosti. Klíčová slova: redakční systém, migrace, sharepoint, webové aplikace, framework

Title: The applications of Content Management Systems in e-government Author: Bc. Michal Foltýn Department: Department of Software Engineering Supervisor: prof. RNDr. Jaroslav Král, DrSc. Supervisor’s e-mail address: [email protected] Abstract: Content management systems allow easy creation and management of web pages even without expert skills. Thesis describes application of these systems at Customs Administration of Czech republic and proposes serie of steps required to migrate web pages from one system to another. Framework for developing web applications enables to integrate these applications into content management system and extend its functionalities. Keywords: content management systems, CMS, migration, sharepoint, web applications, framework

1 Úvod Content Management systémy (CMS) hrají v dnešní době velmi významnou roli v podnikovém prostředí. Staly se nedílnou součástí procesu udržování informací na webu, sdílení informací s veřejností i mezi zaměstnanci a velkou mírou přispívají k zefektivňování práce. Mezi nejzákladnější funkce CMS patří bezesporu velmi jednoduché vytváření a správa obsahu na webových stránkách. V 90. letech a začátkem 21. století byli za obsah stránek odpovědné IT oddělení, které mělo na starosti tvorbu a aktualizaci webových stránek. S příchodem CMS systémů se tato role přesunula na zaměstnance, kteří jsou za danou oblast v podniku zodpovědní. Administrátoři z IT oddělení přešli z role zodpovídání za obsah na webových stránkách do role technické podpory, která řeší problémy a nesnáze ostatních uživatelů. Toto bylo možné pouze za předpokladu, že pro vytváření stránek není nutné znát HTML kód, tak jak tomu bylo dříve. CMS systémy přišly s jednoduchou správou obsahu stránek a jednoduchým vytvářením bez nutnosti znalosti HTML pouze za použití funkcí, které uživatelé již znají z textových editorů, jako např. Microsoft Word, OpenOffice, apod. Toto velmi usnadnilo tvorbu obsahu, jelikož je možné publikaci informací na webové stránky delegovat uživatelům, kteří jsou za danou informaci zodpovědní. Informace se mění prakticky každou minutou a mít možnost rychle a pružně reagovat na každou změnu v nabídce služeb, ve vydávání tiskových zpráv, v úpravě cen atd. se stává klíčové. Změny je třeba publikovat v jednom okamžiku na všech místech a to s jistotou, že se na nic nezapomene a vše bude opravdu jednotné. Je tedy třeba rychle a hlavně bez chyb zvládnout distribuci totožných informací na různé části rozsáhlé webové prezentace. Stejně jako v podnikových procesech je CMS využíváno i ve státní správě. Zde našlo CMS uplatnění stejně dobře jako v soukromé sféře a to hlavně díky své organizační struktuře, kde každé oddělení a každý odbor je zodpovědný za svou agendu a také zodpovědný za obsah informací, které lze směřovat na webové stránky, tak aby byly přístupné široké veřejnosti.

1.1 Cíl práce Cílem této diplomové práce je ukázat konkrétní použití CMS systému ve státní správě a provést analýzu migrace redakčního systému MCMS do systému MOSS a shrnout výsledky migrace s ohledem na prostředí na Celní správě. Analýza má za cíl popsat optimální způsob migrace rozsáhlého systému. Při psaní práce bude kladen důraz na provedení srovnání původní technologie MCMS s novým systémem MOSS. Zároveň je cílem ukázat změny v procesech na Celní správě po 11

migraci na nový systém a jaké kroky byly nutné provést při migraci z jednoho systému do druhého. Samostatnou kapitolu tvoří návrh a implementace frameworku, který umožní vkládat další webové aplikace do redakčního systému a tím možnosti systému rozšířit o libovolnou funkčnost. Cílem je navrhnout takový způsob, který umožní vyvíjet aplikace pro MOSS bez nutnosti znalosti nebo přítomnosti prostředí MOSS a zároveň zajistit jednoduché vložení aplikace do prostředí MOSS.

1.2 Terminologie Pro srozumitelnost dalšího textu se již předpokládá znalost některých termínů, které se při správě obsahu používají. Uvedené termíny jsou ponechány bez překladu v anglickém jazyce, protože tyto termíny jsou již velmi zavedené a definování českých ekvivalentů by pouze přineslo nedorozumění mezi stávajícími uživateli a čtenáři. Tabulka 1.1 obsahuje výčet termínů, které jsou v této práci použity.

12

Název CMS MCMS MOSS WSS MSSQL Active Directory WYSIWYG

Redakční prostředí

Produkční prostředí Administrační prostředí Editace stránek „onSite“ Editace stránek „offSite“ Schvalování Autor / editor Schvalovatel Publikace Content Job Publication Web Content Management Systems Podweb, podprojekt

QA – Quality Assurance

Popis Content Management System – systém pro správu obsahu Microsoft Content Management System 2002 Microsoft Office Sharepoint Server 2007 Windows Sharepoint Services Microsoft SQL Server Adresářová službu společnosti Microsoft akronym anglické věty „What you see is what you get“, česky „co vidíš, to dostaneš“. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce vzhledově totožná s výslednou verzí dokumentu.1 Prostředí, které slouží pro vytváření obsahu. Obvykle je umístěno na samostatném serveru, který není přístupný z internetu, a mají na něj přístup pouze oprávnění autoři. Prostředí určené pouze pro zobrazování obsahu uživatelům. V tomto prostředí nelze měnit obsah. Jedná se o prostředí, ve kterém probíhá úprava stránek, např. přímo na stránce nebo v samostatné aplikaci. Editace stránek probíhá ve stejném prostředí, ve kterém dochází k zobrazení stránky. Editace stránek probíhá v samostatném prostředí, které je určené pouze pro editaci. Proces, při kterém oprávněný uživatel rozhodne, zda může být obsah stránky zobrazen pro všechny uživatele. Uživatel, který má oprávnění vytvářet a měnit obsah stránky Uživatel, který má oprávnění schvalovat nebo odmítat obsah stránek Proces, při kterém je obsah stránky umístěn do produkčního prostředí, tak aby byl viditelný pro všechny uživatele. Termín zavedený v Microsoft Sharepoint pro publikaci obsahu z jednoho serveru na druhý Množina redakčních systémů, které mají pokročilé funkce pro správu obsahu a propojení s ostatními systémy. Samostatná část v systému, která je nezávislá od ostatních částí a obsahuje vlastní stránky, dokumenty a nastavení, které jsou odděleny od ostatních podwebů. Cílem této aktivity je dohlédnout, že dodávaný softwaré má odpovídající kvalitu. Tabulka 1.1: Terminologie

1

Zdroj: http://cs.wikipedia.org/wiki/WYSIWYG

13

Redakčními systémy v této diplomové práci jsou myšleny Web Content Management systémy, pokud není explicitně uvedeno jinak. Text obsahuje anglické výrazy, které jsou ponechány bez překladu do českého jazyka, pokud jsou tyto termíny již obecně používány a zavedeny.

14

2 CMS CMS je zkratka z anglického Content Management System (systém pro správu obsahu), je označení pro software zajišťující správu dokumentů, nejčastěji webového obsahu pomocí redakčního prostředí.

2.1 Popis Redakční systém umožňuje uživatelům vytvářet a editovat webové stránky bez nutnosti znalosti programovacího jazyka. Cílem redakčního systému je uživatelům nabídnout jednoduchou možnost vkládání obsahu na webové stránky bez nutnosti znalosti technického provedení. Redakční systém nabízí základní podporu procesů, kdy mohou různí zaměstnanci obsah vytvářet a jiní mohou provádět editaci nebo schvalování obsahu. Pokročilé redakční systémy se nazývají Web Content Management systémy (WCMS), které jsou určeny pro velké podniky a statní organizace. Tyto systémy nabízí pokročilé funkce, rozsáhlejší podporu možných procesů a integraci s dalšími podnikovými systémy, např. ERP systémy. V dalším textu je pod pojmem redakční systém myšleno WCMS, pokud není explicitně zmíněno jinak. Mezi základní funkce CMS patří:2 •

• • • • • • •

tvorba, modifikace a publikace dokumentů prostřednictvím webového rozhraní využitím jednoduchého online WYSIWYG editoru nebo jednoduchého systému formátování textu (není nutná znalost HTML) řízení přístupu k dokumentům se správou uživatelů a přístupových práv správa diskusí či komentářů, ať už k publikovaným dokumentům nebo obecných správa souborů správa obrázků, případně galerií kalendářní funkce statistika přístupů schvalování obsahu před zveřejněním

Klíčové vlastnosti:3

2

Zdroj: Wikipedia, http://cs.wikipedia.org/wiki/Systém_pro_správu_obsahu

3

Zdroj: Devit, http://www.devit.cz/sluzby/portalova-reseni/tabid/158/Default.aspx

15

• • • • • • • • • •

Uživatelské role – plná kontrola nad oprávněním spravovat portál, každý uživatel má předem specifikované oprávnění pro různé akce Správa dokumentů - sdílení a správa dokumentů pouze pro pověřené uživatele Oznámení - ideální pro novinky webu, komunikaci a upozornění na plánované akce Diskusní fóra - diskuze pro klienty i interní zaměstnance Skupinové plánování - plánování událostí a sdílení pro celý team pro lepší přehled vytíženosti zaměstnanců Správa uživatelů - přidat, upravit, smazat uživatele, přiřazení práv pro každého uživatele individuálně Správa databáze – plná kontrola nad správou databáze a objekty databáze Události – publikace událostí a plánovaných aktivit společnosti nebo jedince Průzkum mínění – provádění veřejných průzkumů Úkoly – správa a přiřazení úkolu pro tým/jednotlivce

Redakční systém umožňuje uživatelům vytvářet a editovat webové stránky bez nutnosti znalosti programovacího jazyka. Uživateli je umožněno se soustředit pouze na obsah a základní formátování textu, bez možnosti měnit vzhled celých stránek. Obvykle je uživateli povoleno měnit pouze určitou část stránek. Vzhled stránek je definován pevně a umožňuje zajistit jednotný vzhled všech stránek. Důležitou funkcí je správa dokumentů a obrázků. Všechny soubory, na které je odkazováno na webových stránkách, jsou uloženy v systému a je umožněno je snadně přidávat, měnit, mazat a přehledně zobrazovat. To s sebou přináší značné zjednodušení při správě a také je možné přehledně zobrazit, které dokumenty jsou aktivní (tzn., že existuje odkaz na dokument na webových stránkách) a které již ne. Výhody CMS systému se začnou projevovat při růstu společnosti. U menších společností o několika zaměstnancích není nutné pro zveřejňování informací na webu využívat služeb CMS systémů, protože stránky bývají většinou statické a úpravu webu může provádět jeden zaměstnanec, který se domluví s ostatními, jaké informace by se měly na webu zveřejnit. Při růstu společnosti a s tím spojený větší počet zaměstnanců vzniká zásadní problém, jak tyto skupiny zaměstnanců budou spolu komunikovat a podílet se na tvorbě a úpravě obsahu. Jak zmiňuje Pavel Novák, Account manager společnosti Et Netera ve svém článku Co řeší systémy pro správu obsahu ve firmách z oblasti služeb?: Možností samozřejmě je posadit všechny zúčastněné do velké místnosti, aby u sebe vzájemně seděli a společně spolupracovali, ale kýžený efekt to pravděpodobně nepřinese. V praxi se jako správné řešení ukazuje odlišení jednotlivých fází životního cyklu obsahu od počátečního nastavení (administrace), vznik či úpravu (editaci), přes schvalování

16

(workflow – řízený oběh dokumentů včetně souvisejících úkolů), zveřejnění (publikaci) po verzování (zachování historie s možností návratu ke starším verzím). 4 Mezi důležité funkce CMS systému patří i možnost rozdělení uživatelů do jednotlivých skupin. Mezi tyto skupiny patří: Administrátoři, Editoři, Schvalovatelé, Čtenáři. Každá skupina přesně definuje možnosti, které uživatel může v systému provádět. Editor je obvykle zodpovědný za tvorbu a úpravu obsahu. Schvalovatel provádí kontrolu nové vytvořeného nebo upraveného obsahu. Jak dále zmiňuje Pavel Novák ve svém článku. "Jednotliví pracovníci organizace se takto mohou na výsledku podílet při současné práci, aniž by museli sedět v sedmi lidech u jednoho počítače. Po nastavení jednotlivých práv a schvalovacích procesů v administraci CMS každý pracovník ví, jakým způsobem musí svou část připravit, publikovat a systém automaticky upozorňuje jednotlivé skupiny v rámci společnosti na možnost schválení a vystavení dané informace na internetu." Další výhodou CMS systému je oddělení designu od obsahu. Toto umožňuje kdykoliv změnit vzhled stránek pouhou úpravou na jednom místě. Takže v případě potřeby změny vzhledu stránek není třeba měnit vůbec obsah, ale upravují se např. pouze CSS styly. Tato vlastnost ušetří výrazně více času, než kdyby každá stránka byla v systému zcela nezávislá, i co se týká designu. 2.1.1

Vytváření obsahu

V popředí CMS systému stojí vytváření obsahu. CMS jsou navrhnuty tak, aby vytváření stránek mohl provádět i uživatel, který neovládá HTML kód ani další jazyky a technologie, které používají experti na tvorbu webových stránek. Toho je docíleno tak, že vytváření obsahu probíhá v textovém editoru, který se podobá textovým editorům, na které jsou uživatelů zvyklí. Tato vlastnost je zásadní pro úspěch CMS jako nástroje pro publikování informací na webu. Umožňuje totiž rozdělit jednotlivé části webu zaměstnancům, kteří jsou za danou oblast zodpovědní. Tito zaměstnanci poté mohou vytvořit stránky na webu způsobem totožným s vytvářením dokumentů např. v Microsoft Word. CMS systémy také umožňují spravovat strukturu webu. Editor má možnost rozhodnout, do které sekce se stránky umístí a navzájem stránky propojit mezi sebou. Mnoho systémů umožňuje stránky jednoduchým způsobem přemisťovat i při zachování odkazů. Podle místa editace stránek, lze CMS systémy rozdělit do dvou skupin: 1. „onSite“ – úprava stránek probíhá ve stejném prostředí jako je produkční verze

4

Zdroj: Pavel Novák, Et netera: http://www.etnetera.cz/cz/2174-clanky_a_komentare/CMS_sluzby_PNo_ITSYST.html

17

2. „offSite“ – pro úpravu stránek je nutné přejít do samostatného nástroje V případě „onSite“ editace, může editor měnit stránky ihned při prohlížení stránek. Obvykle je to řešeno přítomností tlačítka, které po stisknutí přepne uživatele do editačního režimu, ve kterém je možné ihned měnit text. Jedná se o intuitivní možnost editace stránek, kdy se zobrazí na stránce textové pole a obsah je možné ihned měnit. V případě „offSite“ editace musí editor do zvláštního nástroje, který je nasazen na zvláštním prostředí. Obvykle se jedná o administrátorský nástroj, který je určen pouze k editaci a nikoliv k zobrazení výsledného obsahu. Pro zobrazení výsledného obsahu je nutné přejít na živou verzi stránek. 2.1.2

Správa obsahu

Jakmile je stránka vytvořena, je uložena do databáze. Databáze obsahuje veškerý obsah webu spolu s dalšími pomocnými údaji. Databáze umožňuje CMS systému poskytovat řadu užitečných funkcí: • • •

verzování stránek – všechny změny, které byly na stránce provedeny od počátečního vytvoření, jsou v databázi uloženy a je možné se k nim kdykoliv vrátit uložení nastavení práv – umožňuje zajistit, aby uživatel měl práva pouze na ty stránky, na které dostal oprávnění umožňuje integraci s ostatními informačními systémy

Mezi důležitou funkci patří podpora pracovních postupů. Příkladem pracovního postupu je např. schvalování. Když autor dokončí vytváření stránky, informace o vytvoření je automaticky zaslána vedoucímu, poté právnímu oddělení a nakonec správci webu. Pokud všichni v tomto řetězci stránku schválí, stránka je automaticky zveřejněna na webu. Tímto postupem je docíleno, že stránka, která je publikovaná, prošla zevrubnou kontrolu. Schvalování je typickým příkladem pracovního postupu. Některé CMS systémy umožňují definici vlastních pracovních postupů, což může být výhodné pro společnosti, které by chtěli své interní procesy integrovat do systému. 2.1.3

Publikace

Jakmile je finální obsah uložen v databázi, může být posléze publikován na webové stránky. CMS obvykle umožňují dvojí způsob publikace: 1. okamžitá publikace 2. pravidelně v předem definovaném čase

18

CMS systémy obvykle umožňují publikovat na více serverů zároveň. To přináší obrovskou výhodu a jistotu, že jeden obsah bude publikován na všech serverech stejně. Toto umožňuje zajistit, abych obsah byl konzistentní na všech serverech. Jelikož publikace je zaměřena na obsah, umožňuje autorům se koncentrovat pouze na obsah a ponechává prezentaci obsahu čistě na CMS. Administrátor se naopak může soustředit pouze na úpravu prezentační části, aniž by se musel kontrolovat všechny stránky. 2.1.4

Prezentace

CMS systémy také poskytují řadu funkcí, které zvyšují kvalitu a užitečnost celého webu. Jako příklad může posloužit automatické vytvoření navigace na stránkách, kdy CMS systém dokáže veškeré potřebné informace získat ze svého úložiště. Další užitečnou funkcí bývá podpora více internetových prohlížečů nebo podpora přístupnosti pro uživatele s těžkým zdravotním postižením. Tyto funkce mohou společnostem ušetřit významné množství času, jelikož jsou automaticky podporovány CMS systémy. Některé CMS systémy jsou navrženy modulárně, a tedy lze jejich funkce rozšiřovat pomocí dalších přídavných modulů. Existující moduly mohou ušetřit čas pro vývoj a rozšířit funkčnost dle požadavků. 2.1.5

Integrace s externími systémy

Pokročilé redakční systémy umožňují propojení systému s dalšími podnikovými systémy jako Intranet, Extranet, ERP systémy, apod. Mnohé systémy již podporují takovou integraci nebo umožňují integraci doimplementovat. Příkladem integrace může být podpora synchronizace s intranetem, kdy informace umístěné na intranetu je nutné zobrazit i na veřejné prezentaci nebo naopak. Tím je zajištěno omezení redundance dat a značné zjednodušení při správě takového obsahu.

2.2 Využití CMS ve státní správě Tato kapitola popisuje využití různých redakčních systémů ve vybraných orgánech státní správy.

19

Název

Redakční systém (výrobce)

Ministerstvo dopravy

MCMS 2002 (Microsoft)

Ministerstvo financí

RedDot (OpenText Web Solutions Group)

Ministerstvo kultury

WebToDate (Macron)

Ministerstvo obrany

WebToDate (Macron)

Ministerstvo práce a sociálních věcí

YCMS (vlastní produkt)

Ministerstvo pro místní rozvoj

Kentico v4.0 (Kentico)

Ministerstvo průmyslu a obchodu

WebToDate (Macron)

Ministerstvo spravedlnosti

Vlastní publikační systém (Telefónica O2)

Ministerstvo školství, mládeže a tělovýchovy

Marwel (QCM)

Ministerstvo vnitra

SystemIdea (eCommerce.cz)

Ministerstvo zahraničí

jNetPublish (EtNetera)

Ministerstvo zdravotnictví

Vlastní publikační systém (Kaktus)

Ministerstvo zemědělství

jNetPublish (EtNetera)

Ministerstvo životního prostředí

CMS vytvořený v prostředí Lotus Notes

Tabulka 2.1: Přehled použitých redakčních systémů ve státních orgánech

2.2.1

5

Celní správa České republiky

Celní správa České republiky je bezpečnostním sborem zajišťující výkon kompetencí v oblasti správy cel a některých daní, jakož i dalších svěřených nefiskálních činností ve prospěch státu i jeho občanů. Je podřízena Ministerstvu financí ČR a skládá se z generálního ředitelství cel, 8 celních ředitelství a jejich 54 podřízených celních úřadů s vymezenou územní působností.6 Celní správa od roku 2004 do roku 2009 používala redakční systém MCMS 2002 od společnosti Microsoft. Tvorba stránek probíhala odděleně na vyhrazeném redakčním prostředí. Z tohoto prostředí poté probíhala v pravidelných intervalech publikace na provozní prostředí. Byla zde možnost spustit publikaci okamžitě. Oprávnění k této činnosti měl pouze správce webu. Redakční systém byl využíván pro tvorbu a správu obsahu pro internetové stránky Celní správy. Za jednotlivé části webových stránek byly odpovědní různí lidé. Byly zde nastaveny 5

Zdroj: webové stránky jednotlivých státních orgánů a oddělení informatiky na ministerstvech (stav ke dni 17.10.2010) 6

Zdroj: webové stránky Celní správy http://www.celnisprava.cz

20

základní role, Editor a Schvalovatel. Tyto role ovšem ve většině případů splývaly, takže Editor a Schvalovatel byla tatáž osoba. Jednotný vzhled byl dán pevně schválenými styly a šablonami. Jelikož šablony umožňovaly vkládání HTML kódu, docházelo často k porušení jednotného vzhledu a často stránky porušovaly i základní pravidla pro tvorbu stránek (různé barvy, velikost a typ písma, apod.). Systém až do samotného konce podporoval pouze prohlížeč Internet Explorer a nesplňoval standardy webových stránek. Systém byl hojně využíván a svým jednoduchým přístupem k tvorbě a úpravě stránek postačoval pro zobrazování informací pro veřejnost. Redakční systém byl rozšiřován dalšími webovými aplikaci, které byly do něj integrovány. Nebylo zde propojení s žádnými dalšími systémy, i přestože se při nasazení počítalo s propojením s intranetovým portálem běžícím na prostředí WSS 2.0. V roce 2009 byl nahrazen technologií Microsoft Office Sharepoint Server 2007. O této migrací pojednává i tato diplomová práce. Informace byly získány od odboru 12 – oddělení informatiky. Kontaktní osoba Pavel Pelant, vedoucí oddělení informačních a komunikačních technologií Celní správy. 2.2.2

Ministerstvo zahraničí České republiky

Ministerstvo zahraničí pro správu svých webových stránek používá redakční systém jNetPublish od společnosti ETNetera s.r.o. Systém byl nasazen koncem roku 2008. Před systémem jNetPublish byly stránky spravovány pouze IT oddělením, které provádělo přímo editaci stránek. Stránky byly napsány v jazyce ASP. Migrace byla provedena exportem dat do XML souborů, ze kterého následně byly importovány vybrané stránky. Část stránek byla migrována ručně nebo byla vytvořena zcela nová. Redakční systém je nasazen přímo na provozním prostředí. Tedy není zde dedikované redakční prostředí. Důvodem je snaha o ušetření za licence a hardware. Výhodou řešení je okamžitá publikace stránek. "Na systému jNetPublish oproti předchozímu řešení oceňujeme především snadnou editaci stránek, existenci šablon a rozdělení jednotlivých částí do podprojektů, které mohou být samostatně spravovány. Výhodu vidíme i v možnosti mít stránky rozpracované a vracet se k nim později, “ zmiňuje Michal Kurka, správce webových stránek Ministerstva zahraničí.

21

Systém není propojen s žádnými dalšími systémy. V současné době není ani požadavek na integraci s jinými systémy. Intranetový portál, je i z důvodu bezpečnosti, zcela oddělen a nezávislý. Redakční systém nebylo zatím třeba rozšiřovat funkcionalitou samostatných webových aplikací. "Vzhledem k proprietární povaze systému dochází v některých případech k nemožnosti rozšíření systému o funkce, které bychom potřebovali. Ocenili bychom více administrátorských funkcí. Některé činnosti nemůžeme provádět a musíme tyto činnosti delegovat na dodavatele," shrnul nevýhody systému Michal Kurka. Martin Pizinger, který má starosti obsah stránek velvyslanectví ve Washingtonu oceňuje na systému možnosti přechodu do editačního režimu. "U systému oceňuji, že při potřebě editace stránky můžu do editačního režimu přejít přímo z dané stránky a nemusím využívat oddělený projekt pro editaci." I přes některé nedostatky je Ministerstvo zahraničí se systémem spokojeno. Informace byly získány od Michala Kurky, správce webových stánek Ministerstva zahraničí. 2.2.3

Ministerstvo financí České republiky

Ministerstvo financí používá od roku 2003 redakční systém RedDot od společnosti OpenText ve verzi 7. V roce 2011 je plánován přechod na novější verzi 10. Před rokem 2003 byly stránky ministerstva vytvářeny a spravovány přímo v HTML kódu bez přítomnosti jakéhokoliv redakčního systému. Jak uvedla Renata Pavoučková, šéfredaktorka internetových stránek, výhody současného systému nelze porovnat a výhody spatřuje ve všech standardních funkcích redakčního systému. Na tvorbě obsahu se podílí 45 redaktorů, kteří mají každý svého zástupce pro případ dovolených, nemoci, apod. Redaktoři ovšem nevytvářejí stránky přímo v systému, nýbrž připraví obsah a v PDF formátu zašlou šéfredaktorce a jejímu týmu. Redakční tým poté obsah zpracuje a vytvoří v redakčním systému novou stránku. Výhodou je zajištění jednotného vzhledu a také přísná kontrola formy a obsahu stránek. Nevýhodou je značná pracnost, kdy každá stránka musí být zpracována z PDF formátu do redakčního systému. Důvodem pro tento proces je pracovní vytížení redaktorů, kteří mají jiné úkoly než tvorbu obsahu. Redakční tým tvoří 3 lidé, kteří zároveň schvalují a publikují. Konečné schválení má vždy šéfredaktor. Systém podporuje tvorbu šablon a za dobu jeho používání byly vytvořeny šablony, které dnes značně usnadňují práci se stránkami a umožňují zajistit jednotný vzhled a rozložení stránek. 22

Redakční a produkční je odděleno a mezi těmito prostředími probíhá automatická publikace. V současné době nejsou internetové stránky propojeny s žádnými dalšími systémy. Externí aplikace jsou do systému integrovány odkazem a běží na samostatných webových adresách. Do současné chvíle nebyly definovány pravidla pro vzhled externích aplikací. "Velkou nevýhodou je zastaralost současného systému, který neumožňuje pokročilejší správu stránek a provázání jednotlivých částí stránek. Uvítala bych možnost editace obrázků přímo v redakčním systému, tak aby nebylo nutné přecházet do jiné aplikace," uvedla Ing. Renáta Pavoučková, šéfredaktorka webových stránek, která poskytnula informace o redakčním prostředí a procesech na Ministerstvu financí. 2.2.4

Ministerstvo průmyslu a obchodu

Ministerstvo průmyslu a obchodu (MPO) používá pro zobrazení informací na webových stránkách redakční systém WebToDate od společnosti Macron. Tento systém je na MPO nasazen od roku 2005. Před rokem 2005 byly stránky editovány ručně v HTML. Migrace na nový systém proběhla manuálně, kdy bylo nutné všechny stránky vytvořit znovu v novém systému. Jak uvedl Ing. Jindřich Ptáček, vedoucí odboru informatiky na MPO. "Manuální migrace nám umožnila revidovat obsah stránek a vytvořit přehlednější strukturu stránek." Redakční systém využívá pro ukládání dokumentů samostatný systém DMS od společnosti Corpus. Do toho systémů je 150 redaktory vkládán obsah, který má být zobrazen na webových stránkách. Tento obsah je ve formátu Microsoft Word. Při publikaci dochází k automatické konverzi z Microsoft Word dokumentu do HTML a přenosu do redakčního systému. Tedy redakční systém se stará pouze o zobrazení dat, které jsou mu předány ze systému DMS. Po této konverzi dochází ke kontrole stránek ze strany 30 gestorů, kteří reprezentují jednotlivé odbory. Po schválení ze strany gestorů, dochází ke zobrazení stránky na internetu. Kromě již zmíněných rolí, je zde definována role redaktorů oborových stránek, kteří mají na starosti rozložení a obsah jednotlivých oborových stránek. Oborových redaktorů je celkem 8. Speciální role je vyhrazena pro redaktora hlavní stránky, šéfredaktora, který se stará o strukturu hlavní stránky. "Výhody systému spatřujeme zejména v možnosti vytváření obsahu v programu Microsoft Word. To přináší ulehčení práce pro jednotlivé autory, kteří jsou na práci v Microsoft Word zvyklí. Na druhou stranu dochází občas k potížím při konverzi dokumentů do HTML," shrnul výhody Ing. Jindřich Ptáček. Webové stránky nejsou přímo propojeny s žádnými externími systémy. Webové stránky jsou propojeny s portálem BusinessInfo, a to pomocí RSS. MPO je s redakčním systémem spokojeno. 23

Informace poskytl Ing. Jindřich Ptáček, vedoucí odboru informatiky na Ministerstvu průmyslu a obchodu.

2.3 Využití CMS v soukromé sféře Redakční systémy jsou stejně jako ve státní sféře i hojně používány v privátní sféře. Stejně jako ve státní správě, tak i společnosti požadují snadnou a jednotnou správu svých webových stránek. Požadavky na redakční systém v privátní sféře obvykle závisí na velikosti společnosti a jejím zaměření. Velké společnosti mají podobné požadavky jako státní orgány a dochází zde k často k rozsáhlým investicím do komplexních redakčních systémů. Malé společnosti naopak kladou důraz na co nejnižší náklady a nevyžadují funkce Enterprise redakčních systémů. U malých společností často není vyžadovaná funkčnost redakčních systémů. Mnohdy dostačuje manuální úprava stránek.

Název ČEZ Škoda auto RWE Transgas a.s.

Počet zaměstnanců 5000-9999 20000-200000 1000-1499

Telefónica 02 CZ ČEPRO, a.s.

5000 – 10000 500 – 999 100 - 199

Kapsch Telematic Services

Popis EdeeCMS - FG Forrest, a. s. MOSS 2007/2010 RedDot – OpenText Web Solutions Group jNetPublish - EtNetera Miranda - Qbizm MOSS 2007 7

Tabulka 2.2: Použitý redakční systém ve společnostech dle velikosti

Tabulka 2.2 ukazuje, že je velmi obtížné hodnotit výběr redakčního systému podle počtu zaměstnanců. Na příkladu redakčního systému MOSS lze vidět, že si jej vybrala jak společnost o mnoha zaměstnancích, tak i společnost s řádově nižším počtem. Pro srovnání by šlo použít i jiné metriky, např. roční obrat, oborové zaměření společnosti, typ informací poskytovaných na internetových stránkách, počet aktualizací stránek, apod. Provedení kompletního srovnání využití CMS systémů v privátní sféře není cílem této diplomové práce a rozsahem by odpovídalo samostatné práci.

7

Zdroj: internetové stránky společností

24

2.4 Srovnání CMS systémů Provést srovnání existujících systému CMS je velmi obtížné vzhledem k množství CMS systémů na trhu. Webové stránky, které se zabývají srovnáváním dostupných CMS systémů, obsahují ve své databázi srovnání 1151 CMS systémů.8 Základní srovnání 6 volně šířených redakčních systémů provádí ve své bakalářské práci Jan Havelka z Masarykovy univerzity v Brně. Autor se zaměřuje na základní srovnání funkčností 6 redakčních systémů, které se dnes používají většinou u menších a středně velkých projektů. Ve své práci porovnává výhody a nevýhody jednotlivých redakčních systémů, ale jeho zaměření je pouze na volně šiřitelné systémy. Velkou výhodou redakčních systémů je, že většinu velmi kvalitních a propracovaných najdeme na Internetu zdarma, takže nás pořízení webové prezentace nemusí stát žádné nebo velmi malé (v případě dokoupení rozšiřujících doplňků) finanční prostředky, než kdybychom si nechali vypracovat web na zakázku od odborné počítačové firmy. Pokusů o srovnání redakčních systému lze na internetu najít početné množství. Hodně uživatelů k tomu využívají blog, kde popisují, který redakční systém je nejvhodnější a proč. Ovšem ve většině případů se jedná o srovnání pouze těch systémů, které jsou volně dostupné, a tedy srovnání není objektivní a přesné. Důvod je zřejmý, že obyčejní uživatelé hledající jednoduchý redakční systém pro správu svých stránek obvykle nechtějí vkládat do nákupu redakčního systému finanční prostředky. V tomto odstavci je provedeno základní srovnání, do jakých kategorií se současné CMS systémy dělí. Provedení komplexní analýzy všech CMS systémů není cílem této práce a rozsahem by odpovídalo samostatné diplomové práci. Cílem tohoto srovnání není snaha o zjištění nejlepšího dostupného CMS systému na trhu. Určení takového systému je velmi obtížné, protože existuje mnoho různých metrik, které lze použít. Pro detailní porovnání lze odkázat na stránky CMSMatrix, které rozdělují redakční systémy podle 145 různých parametrů, jako např. systémové požadavky, bezpečnost, podpora, snadnost použití, výkon, správa, flexibilita, zabudované funkce. CMS systémy lze rozdělit do několika samostatných kategorií a vždy záleží na potřebách konkrétní instituce, na jejich personálním složení, odborných znalostech a dalších požadavcích. CMS systémy lze rozdělit do následujících kategorií:

8

Hodnota ke dni 4.10.2010. Zdroj: http://www.cmsmatrix.org

25

2.4.1

Komerční nebo OpenSource CMS systémy

Komerční systémy jsou ty systémy, které vyžadují počáteční finanční náklady. Licencování těchto systémů se může lišit podle počtu uživatelů, počtu procesorů nebo se může jednat pouze o jednorázovou investici. Opensource systémy většinou žádnou počáteční investici nevyžadují. Oproti komerčním aplikacím zákazník má k dispozici zdrojové kódy, které může dle svých potřeb upravit. Výhodou vlastnictví zdrojových kódů je možnost jakoukoli část systému modifikovat, za předpokladu, že má k tomu prostředky. U komerčních aplikací toto nebývá obvyklé, nicméně existují i společnosti, které po zakoupení produktu dodávají i zdrojové kódy. Společnosti, které nabízí komerční aplikace, obvykle poskytují i technickou podporu. Tato možnost může mít rozhodující vliv na výběr produktu, protože v případě poruchy, je možné kontaktovat společnost a včas zajistit opravu. U opensource produktů je možné se pouze spolehnout na různá diskusní fóra případně zaplatit za technickou podporu jiné společnosti, která se tomu věnuje. Při rozhodování mezi komerčním a opensource systémem je nutné vzít na vědomí i další investice, které s nákupem systému souvisí. Systémy bývají obvykle vázány na určitý operační systém nebo databázový stroj. Pokud systém vyžaduje např. databázi MSSQL nebo Oracle, je nutné počítat i s úhradou licence za tyto databáze. Stejně tak je nutné vzít v potaz odbornou znalost administrátorů. Pokud administrátoři již pracovali s daným produktem, nebude nutná výrazná investice do školení. Další důležitou věcí při rozhodování hraje i předchozí zkušenost s produktem, stejně jako s dodavatelem. 2.4.2

Použité vývojové prostředí

Systémy lze také rozdělit dle použitého vývojového prostředí. Při výběru systému je nutné se ptát: • • •

na jakém hardware daný systém poběží jaký operační systém bude nainstalován jaká je odborná znalost IT oddělení, případně kdo bude zajišťovat technickou podporu

Při výběru systému je nutné předem na tyto otázky odpovědět, protože v opačném případě by bylo v některých případech nutné vynaložit další finanční i časové prostředky. Z velké části se dnešní CMS systémy dají rozdělit na systémy, které běží pod operačním systémem Linux a na systémy běžící pod operačním systémem Windows. Pokud například společnost má na svých serverech nainstalován operační systém Linux a její administrátoři se specializují pouze na Linux, je nutné při výběru CMS systému vybírat pouze ty CMS systémy, které podporují operační systém Linux. V opačném případě, by bylo nutné nakoupit licence Windows, provést školení administrátorů, případně zaměstnat administrátory se znalostí operačního systému Windows, což by znamenalo další finanční i časové výdaje. 26

Další možností je umístit CMS systém na servery jiné společnosti. Tento typ se nazývá hostovaný a umožňuje podnikům výrazně ušetřit za provoz CMS systému, kdy nejsou nutné počáteční investice do licencí, serverů a zaškolení administrátorů. Nevýhodou této služby je omezená kontrola nad vlastními daty, protože veškerá data se nachází na serveru jiné společnosti. Také pokud je nutné provádět specifické úpravy na serveru, kde daný software běží, v některých případech takové úpravy hostingové společnosti neumožňují. 2.4.3

CMS systémy dle rozsahu

Na trhu existuje velké množství CMS systémů, které poskytují různé množství funkcí. Při výběru systému je nutné si nejprve uvnitř společnosti ujasnit, jaké funkce vedení a uživatelé společnosti od CMS systému očekávají. Lze tím předejít koupi těch produktů, které buď dané funkce neobsahují (a nelze je tam dodatečně implementovat) nebo ty produkty, které obsahují zbytečně moc funkcí, které nebudou využity. Důležitou roli při výběru systému hraje i jeho rozšiřitelnost. Většina CMS systému je navrhnuta obecně tak, aby vyhovovala co největšímu spektru uživatelů. Pro některé společnosti funkce, které CMS systémy nabízejí, mohou být dostačující, pro ostatní nikoliv. V tom případě je nutné do výběru zahrnout pouze ty systémy, které lze např. pomocí dodatečných modulů dále rozšiřovat. 2.4.4

CMS systémy dle cílové skupiny uživatelů

Dalším faktorem, který je důležitý při výběru systému, je odborná znalost uživatelů. Pokud CMS systém bude využíván pouze velmi zřídka a pouze omezeným počtem uživatelů není nutné vybírat systémy, které mají propracovaný systém přístupových práv. Pokud naopak bude CMS systém využíván velkým množství uživatelů s různým stupněm odbornosti, je nutné vybírat takový systém, který má např. propracovanou správu přístupových práv, uživatelsky nejpřívětivější textový editor a několika stupňové schvalování. 2.4.5

Dle implementace administračního prostředí

CMS systémy lze také rozdělit podle implementace administračního prostředí. Obvykle se u CMS systému implementace řeší dvěma způsoby: 1. veřejné a administrační prostředí je společné 2. veřejné a administrační prostředí je oddělené

Veřejným prostředím se myslí prostředí, které vidí běžný návštěvník stránek. Ať už se jedná o internetové stránky, které navštíví libovolný uživatel, nebo intranetové stránky pro zaměstnance.

27

Administrativním prostředím se myslí prostředí, ve kterém lze pouze upravovat obsah, vkládat soubory a jiným způsobem upravovat obsah nebo chování systému. Každá možnost má své výhody a nevýhody. Výhodou společného prostředí je především jednoduchost a přímočarost. Není nutné přecházet na jiné stránky a pro uživatele se tato možnost jeví více intuitivní. Pokud uživatel chce upravit obsah, klikne na stránce na tlačítko upravit a stránka přejde do editačního režimu. Uživatel ihned vidí, jak se změny, které provedl, promítnou na stránce. Výhodou odděleného prostředí je především určité nasměrování myšlení uživatelů, že pokud chtějí změnit obsah, musí přejít do jiného prostředí. Předejde se tak unáhleným úpravám obsahu stránek.

28

3 Srovnání MCMS a MOSS Tato kapitola se věnuje srovnání dvou redakčních systémů, které jsou součástí této diplomové práce. V dalších částech bude popsána analýza migrace ze systému MCMS do systému MOSS.

3.1 Popis Microsoft Content Management System 2002 Microsoft Content Management System byl CMS systém vydaný v roce 2002 společností Microsoft. Podpora MCMS skončila v roce 2005, kdy byl vydán poslední servisní balíček č. 2. V roce 2007 byl systém nahrazen technologií Sharepoint, kdy byl vydán produkt Microsoft Office Sharepoint Server 2007. Ve srovnání s dnešními systémy se jedná o jednoduchý CMS systém, který ovšem poskytoval solidní základ pro další rozšiřování a to především díky podpoře technologie .NET. Samotné jádro systému je napsáno v ASP.NET za využití MSSQL databáze. Microsoft Content Management Systém je podnikový redakční systém, který společnostem umožňuje rychle a efektivně vytvořit, nasadit a spravovat dynamické internetové, intranetové a extranetové webové stránky. Díky integraci s Visual Studiem, podporou pro správu kódu a integraci s ostatními serverovými produkty společnosti Microsoft, MCMS umožňuje vývojářům vytvářet webové stránky, které potom mohou být spravovány IT a business uživateli. IT oddělení může centrálně spravovat vzhled, procesy a zabezpečení. Business uživatelé mohou vytvářet, spravovat a publikovat svůj vlastní obsah za pomocí aplikací, se kterými již běžně pracují, jako např. Microsoft Word, Excel a Internet Explorer. MCMS běží na Windows Server 2003 a vyšším.9 MCMS se dodává jako sada komponent a administračních stránek. Tedy po instalaci není systém funkční a vyžaduje naprogramování jednotlivých stránek. Tento přístup má výhodu ve značné flexibilitě a umožňuje společnostem si přizpůsobit webovou prezentaci zcela dle vlastních potřeb bez nutnosti úprav již předpřipraveného systému. Na druhou stranu zprovoznění systému vyžaduje netriviální implementaci webové prezentace za použití dodaných knihoven a stránek. V dnešní době není tento přístup rozšířený a dává se přednost systémům, které již po instalaci umožňují práci se systémem. Mezi základní funkčnosti dnešních redakčních systémů již patří podpora vyhledávání. MCMS od počátku vyhledávání nepodporovalo a bylo nutné ji řešit samostatně za použití separátních produktů třetích stran (např. Microsoft Search, Tovek, apod.).

9

Zdroj: MCMS 2002 White Paper - http://www.microsoft.com

29

Systém nepodporuje přímou publikaci obsahu z jednoho serveru na druhý. Publikaci je nutné řešit vlastní funkčností, která zařídí export obsahu z redakčního systému do pevně stanoveného formátu SDO souboru a na cílové destinaci provést import. V době vydání, tzn. v roce 2002, se jednalo o poměrně výkonný redakční systém, který umožňoval nasadit redakční systém na vlastní webové stránky a pomocí něho stránky spravovat. V pozdějším cyklu svého života již ale postrádal funkčnost, která se od redakčních systémů vyžadovala (např. vyhledávání, publikace). Následující výhody a nevýhody jsou převzaty z prezentačních materiálů společnosti Microsoft a zkušeností s používáním systému na Celní správě. Mezi nejdůležitější funkce patří: •

• •

• • •

umožnění jednoduchého vytváření stránek bez znalosti HTML. Toto umožnilo předat odpovědnost za obsah a vytváření stránek na osoby k tomu určené a odlehčení zodpovědnosti IT oddělení oddělení obsahu od prezentační části – editoři stránek měli oprávnění měnit pouze obsah stránek. Vzhled stránky byl pevně daný a mohl ho měnit pouze administrátor schvalování obsahu – uživatelé s příslušným oprávněním měli možnost obsah schválit a tím povolit zobrazení obsahu pro všechny uživatele nebo odmítnout a vrátit autorovi k přepracování možnost publikace – tato funkce umožnila mít samostatné prostředí pro editaci stránek (redakční prostředí) a samostatné prostředí pro veřejný přístup (produkční prostředí) rozšiřitelnost – API a dokumentace k API umožňovala systém dále rozšiřovat tvorba šablon – v prostředí Microsoft Visual Studio bylo možné vytvářet šablony pro jednotlivé typy stránek

Nevýhody: • • • • • • • •

náročná instalace – celý MCMS tvořily pouze dll knihovny a samostatné UserControls pro zobrazení administračního panelu. K administraci dále sloužily 3 samostatné aplikace. podpora vyhledávání nebyla součástí MCMS - bylo nutné řešit samostatným produktem autentizace byla vázána pouze na Active Directory nebo lokální uživatelské účty chybějící podpora pro vícejazyčný obsah šablony dokumentů byly statické – jednotlivé části šablon nebylo možné přesouvat chybějící podpora pracovních postupů – např. schvalovací postup byl pevnou součástí systému a nebylo možné ho měnit (implementovat např. vícestupňové schvalování apod.) chybějící podpora RSS chybějící automatická publikace obsahu na jiný server – obsah bylo možné exportovat do SDO souboru a potom pomocí vlastní funkcionality soubor přenést na druhý server, kde ručně provést import

30

3.2 Popis Microsoft Office Sharepoint Server 2007 Microsoft Office Sharepoint Server vyšel v balíku Microsoft Office v roce 2007 jako společný nástupce technologie WSS 2.0 a MCMS. Sharepoint Server je postaven na nové verzi technologii WSS 3.0. MOSS tuto technologie výrazně rozšiřuje a přináší nové možností nasazení a využití. Microsoft Windows SharePoint Services je univerzální technologie, která umožňuje organizacím a obchodním jednotkám všech velikostí zvýšit efektivitu obchodních procesů a zlepšit produktivitu týmů. Díky nástrojům pro spolupráci, které uživatelům umožňují zůstat připojeni i za geografickými hranicemi a hranicemi organizace, poskytuje služba Windows SharePoint Services uživatelům přístup k informacím, které potřebují. WSS 3.0 je podmnožinou MOSS a je určen především pro intranetové prostředí. Microsoft Windows SharePoint Services nabízí společné licencování s Windows Server, což ji činí velmi vhodnou pro nasazení v intranetu. WSS nicméně není CMS systémem, protože nepodporuje následující vlastnosti: • •

publikování článků schvalování článku před zveřejněním

Microsoft Office Sharepoint Server staví na základu WSS 3.0 a dále rozšiřuje jeho možnosti. Obrázek 3.1 ukazuje architekturu MOSS a umístění WSS v této architektuře.

31

¨ Obrázek 3.1 – Architektura WSS a MOSS 2007

10

MOSS vyžaduje operační systém Windows Server a databázový stroj MSSQL. Jiné operační systémy a databázové stroje nejsou podporovány. MOSS 2007 přinesl značnou řadu vylepšení, tak aby jeho využití bylo možné i ve velkých podnicích a orgánech státní správy11.

10

Zdroj: http://msdn.microsoft.com

11

Zdroj: Dokumentace k MOSS 2007: http://msdn.microsoft.com/en-us/library/bb931736(office.12).aspx

32

Jádro MOSS je postaveno na technologii ASP.NET 2.0 za použití vlastností typických pro ASP.NET jako jsou webové části, master page. To umožňuje vývojářům a administrátorům zjednodušit seznámení se systémem, protože využívá stejné prvky jako jiné webové aplikace v ASP.NET. Pro podporu různých procesů uvnitř podniků umožnuje MOSS implementovat vlastní pracovní postupy. Jako příklad lze uvést schvalování dokumentů. Pokud organizace má svůj vlastní postup pro schvalování dokumentů, např. dokument musí nejprve schválit nadřízený, poté právní oddělení a nakonec správce webu. Pracovní postup může být použit na libovolnou činnost nad stránkou a dokumentem. To umožňuje řadu procesů v podniku zautomatizovat a značně zefektivnit a ulehčit práci. Jednoduchým, ale užitečným vylepšením je existence koše pro smazané dokumenty. Pokud omylem dojde ke smazání dokumentu, je možné jej obnovit z koše tak, jak je to běžné u operačních systémů. MOSS v implementaci koše zašel ještě dál, když implementoval ještě druhý koš, který je viditelný pouze oprávněným uživatelům (např. nadřízeným) a může tak obnovit dokument i když byl první koš již vysypán. Zásadní novinkou v MOSS bylo integrované vyhledávání. To umožňovalo rychle a snadno zavést podporu vyhledávání v obsahu webové prezentace. Integrované vyhledávání je řešeno použitím Microsoft Search Server, který umožňuje nakonfigurovat indexování a vyhledávání dle vlastních potřeb. Pro zefektivnění práce v týmu nad dokumenty, byla zavedena notifikace změn (vytvoření, smazání, úprava), kdy při změně dokumentu byla odeslána zpráva předem definované skupině uživatelů. Tedy uživatele nemuseli pravidelně sledovat a zjišťovat, zda došlo ke změně dokumentu, ale byli automaticky upozorněni např. emailovou zprávou. MOSS přinesl pokročilé verzování dokumentů a stránek. MOSS umožňuje, pokud to organizace vyžaduje, uchovávat vedlejší a hlavní verze dokumentů. Vedlejší verze značila stupeň rozpracovanosti dokumentu nebo stránky. Hlavní verze ukazovala počet hlavních verzí dokumentů, které byly publikovány. Toto umožňuje detailnější přehled o změnách v dokumentech a ponechání dokumentů ve stavu rozpracovanosti, jejichž stav zatím není viditelný pro veřejnost. Jakmile byl dokument schválen a odeslán k publikaci, byla nastavena hlavní verze, která byla posléze viditelná i pro veřejnost. Mezi další funkce patří automatická podpora RSS a podpora vlastních autentizačních mechanismů. Pokud má organizace vlastní řešení ukládání uživatelských účtů, je možné velmi snadno zajistit podporu autentizace a autorizace uvnitř MOSS za použití vlastních datových úložišť. Pro podporu jednoduchého vytváření obsahu je možné definovat znovupoužitelný obsah, který je možné rychle vložit na stránce. To ulehčí práci editorům a také zamezí vložení chyb.

33

Publikace byla zcela přepracována a nyní umožňuje provést publikaci na libovolný počet produkčních prostředí. Konfigurace umožňuje definovat cílovou destinaci, rozsah obsahu, který má být publikován (zda celý web nebo jenom jeho část) a také jak často je možné publikaci vykonat. Pro rychlou publikaci je možné dokument nebo stránku označit pro rychlou publikaci, která je vykonávána každých 15min. Při rychlé publikaci se provede publikace pouze označených dokumentů a nedochází tak ke zbytečnému zatížení zdrojů jak na redakčním, tak produkčním prostředí. Pokud jsou možnosti konfigurace nedostatečné, API poskytuje metody a vlastnosti, kterými je možno naimplementovat vlastní řešení publikace. Mezi základní vlastnosti dnešních webových prezentací patří podpora vícejazyčného obsahu. Vícejazyčný obsah je zde řešen tzv. variacemi, kde každá variace představuje jeden jazyk. Jednotlivé jazykové verze jsou zcela odděleny a každá stránka má vlastní verzi pro každý jazyk. Tedy ve svém důsledku může stejná stránka být zcela rozdílná v každém jazyce. MOSS poskytuje podporu pro automatické vytváření stránek ve všech variacích. Po vytvoření stránky v hlavní variaci, dojde k automatickému vytvoření stránky ve všech variacích s obsahem, který je totožný s hlavní variací. Poté již zbývá stránky v ostatních variacích přeložit. Tak je zajištěn stejný vzhled stránek ve všech jazykových variantách. Editor má zde ovšem možnost tento vzhled změnit, pokud je to vyžadováno. Pro podporu dnes již velmi rozšířených mobilních zařízení byla implementována funkčnost pro zobrazení stránek na mobilních zařízeních. Toto umožňuje administrátorům a správcům webu definovat jakým způsobem se budou informace zobrazovat. MOSS poskytuje zobrazení obsahu pro mobilní zařízení na samostatných stránkách, které jsou určeny výhradně pro mobilní zařízení. Při vývoji byl kladen velký důraz na možnosti rozšiřitelnosti systému a z toho důvodu je poskytováno API, které programátorům umožňuje přistupovat přímo k datům a vlastnostem MOSS. Ve svém důsledku to umožňuje implementovat vlastní řešení jednotlivých funkčností, pokud standardní funkčnost není dostatečná. Jako zástupce redakčního systému pro velké organizace i MOSS přináší rozsáhlé možnosti integrace s ostatními systémy, jako např. intranet, extranet, ERP a další. To umožňuje zobrazovat a měnit data z jednotlivých systémů na jednom centrálním systému. Pro tyto účely se používá funkčnost nazvaná Business Catalog. 3.2.1

Nevýhody

V této sekci je vypsáno několik hlavních nevýhod, které MOSS jako CMS systém v současnosti má. Tato práce nemá za cíl zevrubnou analýzu této technologie, nicméně jelikož je tato práce založena z větší části na využívání MOSS jako CMS systému, je zde nutné současně uvést i nevýhody.

34

1. příliš rozsáhlý systém co do počtu funkcí Microsoft SharePoint byl navrhnut tak, aby vyhovoval co největšímu spektru firemních zákazníků a zároveň, aby bylo možné jej upravovat a dále rozšiřovat. U některých funkcí je ale zřejmé, že jim chybí větší provázanost se systémem jako takovým, a že zde byla nejspíše snaha o co největší počet funkcí. To s sebou přináší obtížnější konfiguraci, jelikož je nutné mnoho funkcí spravovat. 2. uložení dokumentů v databázi U většiny nových CMS systémů začíná převažovat způsob ukládání dokumentů mimo databázi. Samotné dokumenty jsou uloženy mimo databázi, většinou na file serveru, v NAS nebo SAN. V databázi jsou uloženy pouze metadata, které obsahují nejdůležitější informace o souboru (jako např. link na soubor, index, apod.). Tento přístup se osvědčil hlavně při optimalizaci vyhledávání i výkonu samotné databáze. SharePoint ukládá všechny data, tzn. soubory do databáze. 3. nové verze dokumentů se ukládají jako celé soubory Jelikož SharePoint je úzce spjat s Microsoft Office, jsou veškeré dokumenty ukládány jako celek. Když dojde ke změně dokumentu, tak SharePoint uloží celý dokument znovu jako novou verzi, i když například došlo ke změně pouze jednoho slova. Opačným přístupem je ukládání pouze změn od originálního souboru. V tom případě, když dojde ke změně slova v dokumentu, je uloženou pouze minimální množství dat. 4. velké množství úprav a jejich náročnost Ihned po instalaci je zřejmé, že je nutné provést poměrné velké množství úprav tak, aby stránky vypadaly dle představ zákazníka. Tyto úpravy nicméně jsou náročné, a pokud společnost nedisponuje odborníkem na SharePoint, tak mohou vyžadovat i velké množství času. 5. chybějící podpora přístupnosti Tato chybějící podpora je velmi zásadní pro státní organizace, kterým novela z roku 2006 zákona č. 365/2000 Sb. o informačních systémech veřejné správy nařizuje, že webové stránky musí být přístupné pro uživatele s těžkým zdravotním postižením. Existují však možností, kterými lze docílit, že stránky budou přístupné, nicméně vyžadují poměrně značné úsilí. 6. komerční produkt bez možnosti přístupu ke zdrojovým kódům Vzhledem ke komerční povaze projektu nejsou k dispozici zdrojové kódy systému. Při potřebě o důkladnou analýzu specifické funkčnosti není možnost nahlédnout do zdrojových kódů a tak lépe porozumět systému. V případě problémů je nutné se spoléhat na diskuze nebo na oficiální podporu ze strany společnosti Microsoft, která je ovšem placená.

35

3.3 Srovnání Provést srovnání MCMS a MOSS je obtížné provést objektivně, jelikož MOSS vznikl jako nástupce MCMS, kdy byly do MOSS implementovány pouze ty součásti, které se osvědčily. Jedná se o srovnání technologie z roku 2002 a technologie z roku 2007. Spousta vlastností, které v MCMS chybějí, se v dnešní době jeví jako zásadní, ale v roce 2002 byly teprve v zárodku Následující tabulka 3.2 přináší srovnání MCMS a MOSS. Tabulka neobsahuje všechny známé funkce CMS systému, nýbrž pouze ty funkce, které jsou pro CMS zásadní nebo hojně využívány. Tabulka poskytuje informace o tom, které součásti byly automaticky implementovány v systému (v angličtině out-of-the-box) a které by bylo nutné samostatně doimplementovat.

Funkce

MCMS 2002

MOSS 2007

Vyhledávání

Vlastní implementace

OOTB

Navigace

Vlastní implementace

OOTB

Formulářová autentizace

Vlastní implementace

OOTB

Podpora schvalování

Vlastní implementace

OOTB

Administrační rozhraní

OOTB

OOTB

Podpora šablon

OOTB

OOTB

WYSIVEG editor

OOTB

OOTB

Podpora RSS

Vlastní implementace

OOTB

Verzování

OOTB

OOTB

Tvorba šablon

Microsoft Visual Studio

Microsoft Visual Studio / Sharepoint Designer

Publikace na jiný server

Vlastní implementace

OOTB

Tabulka 3.2 – srovnání MCMS a MOSS

Následující kapitoly přináší rozepsané srovnání základních funkcí redakčního systému. Obsahuje výčet pouze těch funkcí, které obsahují obě dvě technologie. 3.3.1

Vytváření stránek

U vytváření stránek je vzhledem k povaze akce rozdíl pouze ve vzhledu. MOSS oproti MCMS přináší přehlednější výběr šablony s popisem a náhledem a možností editace URL

36

stránky, např. aby URL stránky bylo generováno automaticky z názvu stránky. Tak lze docílit jednotného pojmenování pro potřeby SEO. 3.3.2

Schvalování

Schvalovací proces je podporován v obou systémech. MCMS nabízí pouze jednoduchou formu procesu schvalování, kdy existuje pouze jednoúrovňové schvalování, tzn. nelze nastavit posloupnost lidí, kteří musí stránku schválit předtím, než bude publikována. Systém postrádá podporu notifikace na schválení, takže schvalovatel musí aktivně a pravidelně kontrolovat seznam stránek ke schválení. Není zde možnost posunout termín publikace. MOSS oproti MCMS doznal velkých změn a značně rozšiřuje možnosti schvalování. Je možné nastavit jak sériové tak i paralelní schvalování. Pokud organizace má specifické požadavky je možné naimplementovat vlastní proces schvalování. Existuje notifikace o schválení, a to emailovou cestou. Při schválení je možnost specifikovat datum začátku platnosti stránky. U schvalování lze pozorovat značný rozdíl, kdy MCMS je základní redakční systém a MOSS je již komplexní redakční systém pro velké organizace se značnou flexibilitou a rozšiřitelností. 3.3.3

Publikace

MCMS nenabízí standardní způsob publikace obsahu z jednoho serveru na druhý. Tedy nelze jednoduchým způsobem zajistit publikaci z dedikovaného redakčního prostředí na provozní prostředí. MCMS nicméně poskytuje možnosti exportu obsahu do SDO souborů, které lze posléze neimportovat. Veškerá režie, která spočívá ve vytvoření a přenesení souboru na provozní prostředí, ovšem musí provedena implementací vlastního řešení. MOSS již obsahuje poměrně rozsáhlé možnosti publikace z jednoho serveru na druhý. Funkce se jmenuje Content Deployment a umožňuje různé druhy nastavení od časové periody publikace po nastavení rozsahu obsahu, který má být publikován (zda celý web nebo jenom některé jeho části). Programátorské rozhraní umožňuje další přesnější specifikaci publikace, tak lze docílit splnění různých požadavků firem. 3.3.4

Způsob ukládání dokumentů a obrázků

U MCMS existují dva způsoby ukládání dokumentů a obrázků. První způsob je přímé uložení, kdy není nutný mezikrok pro uložení dokumentu na server. Při tomto způsobu uživatel vybere ze svého disku dokument nebo obrázek, který chce vložit na stránky a systém automaticky soubor uloží do speciálního adresáře v systému a zobrazí na stránce. Druhá možnost je první uložit soubor do adresáře v systému a potom na něj vložit odkaz. 37

První možnost je velmi praktická pro uživatele, protože značně zrychluje vytváření stránek, ovšem při smazání odkazu na stránce nedojde ke smazání samotného dokumentu, tedy systém po čase obsahuje velké množství nepoužívaných dokumentů. To je poté nutné řešit za pomocí vlastních nástrojů, které dokážou zjistit, zda uložený dokument je používán (existuje na něj odkaz) a tedy může být smazán. MOSS nabízí standardní způsob, kdy každá samostatná logická část webových stránek (v názvosloví MOSS je to web) obsahuje samostatný adresář pro ukládání dokumentů a obrázků, které souvisí s daným webem. Tímto způsobem lze zpětně měnit obrázky a dokumenty a jejich změna se projeví na všech stránkách, kde je na soubory odkazováno. Přináší to ovšem komplikace pro editory, kteří musí nejprve soubor uložit na server a až poté vytvořit odkaz na něj. Zvlášť pro běžné uživatele je to ze začátku velká komplikace. Do šablony stránek je ovšem možné vložit vlastní funkčnost, která např. umožní automatické uložení souboru do serverového adresáře a posléze automaticky vložit odkaz na dokument nebo obrázek. 3.3.5

Přístupnost

Novela z roku 2006 zákona č. 365/2000 Sb. o informačních systémech veřejné správy nařizuje, že webové stránky státních orgánů musí být přístupné pro uživatele s těžkým zdravotním postižením. MCMS ani MOSS pravidla pro přístupnost standardně nepodporují a je nutné vyvinout značné úsilí pro splnění těchto pravidel. 3.3.6

Vyhledávání

MCMS neobsahuje podporu vyhledávání, tedy je nutné implementovat vlastní řešení vyhledávání v obsahu (fulltext). Řešením je použití indexovacího a vyhledávacího stroje třetích stran, i tak je nutné při implementaci řešit předání obsahu k indexaci a převzetí a zpracování výsledků vyhledávání. MOSS standardně podporuje vyhledávání v obsahu za použití Microsoft Search Engine. Existuje zde automatické nastavení indexace obsahu a webové částí pro zobrazení výsledků vyhledávání. Nastavení a spuštění vyhledávání je oproti MCMS velmi jednoduché a rychlé.

3.4 Použití MCMS na Celní správě Technologie MCMS byla nasazena na Celní správu v roce 2005 společností Unicorn. Při tvorbě webových stránek bylo nutné implementovat řadu funkčností, které MCMS neobsahovalo. Vyhledávání bylo řešeno použitím indexovacího a vyhledávacího stroje Tovek. Komunikace s Tovek byla řešena samostatnou webovou službou. Indexování obsahu se 38

provedlo jednou po nasazení webových stránek a poté inkrementálně jednou denně, vždy dotazem do MCMS, které vrátilo seznam stránek a dokumentů, které byly změněny. Použití nástroje Tovek se později ukázalo jako velmi rizikové, a to především z důvodu chybějící znalosti daného prostředí. Vzhledem k časté fluktuaci pracovníků, kteří měli na starosti servis webových stránek a tudíž i vyhledávání, chyběli po čase odborníci, kteří by dané implementaci a správě Tovek rozuměli. Formulářová autentizace byla řešena pomocí nástroje Security Provider, což byla webová služba, která ověřovala vůči Active Directory, zda uživatel je autentizován či nikoliv. Nevýhodou MCMS bylo, že podporovala pouze WINNT přístup, nikoliv standardní LDAP, což způsobilo nemalé komplikace při tvorbě a správě této webové služby. Publikace obsahu z redakčního prostředí na produkční se řešilo pomocí několika vlastních komponent (viz obrázek 3.3). První komponenta zajišťovala export nového nebo změněného obsahu z redakčního prostředí MCMS do SDO souborů. SDO soubor je standardní formát, který poskytuje MCMS pro export dat. Druhá komponenta, webová služba, zajišťovala přenos SDO souboru na produkční prostředí. Třetí komponenta byla automaticky spouštěna druhou komponentou a prováděla import SDO souboru pro produkční prostředí. Jak již z návrhu tohoto řešení vyplývá, existovalo příliš mnoho komponent a tudíž i příliš mnoho míst, kde může dojít k chybě. Standardním problémem byla velikost SDO souborů. SDO soubory obsahovaly veškeré nové a změněné stránky a dokumenty za posledních 7 dní. Tyto SDO soubory mohly dosahovat velikosti několika stovek MB a to v případě, kdy za poslední týden docházelo k velkému množství publikace, případně když bylo do systému vloženo větší množství velkých dokumentů. Velikost SDO souborů přinesla několik problémů. Webová služba, která dané SDO soubory přenášela, musela podporovat přenos velkých objemů dat. Cílový server (produkční prostředí) obvykle uchovávalo historii přenesených SDO souborů, což vyžadovalo množství volného místa na disku. Toto samozřejmě přinášelo technický problém, kdy bylo nutné kontrolovat volné místo na disku a v případě nedostatku místo uvolnit. Třetím závažným problémem byla nedeterministické chování MCMS při importu velkého souboru SDO. Velmi často se stávalo, že import SDO selhal, protože MCMS odmítlo tak velký soubor zpracovat. Po několika letech Microsoft vydal opravu, která tuto chybu opravovala.

39

Obrázek 3.3: Schéma publikace MCMS

Schvalování článků mohl provádět pouze jeden člověk. Neexistence vícestupňového schvalování se později ukázala jako nepříjemný problém z důvodu vzhledu existujících stránek. Jelikož prioritou byl obsah stránek a na vzhled nově vytvořeného obsahu se nebral takový ohled, výsledkem byly stránky, které obsahovaly různé sady barev, různé velikosti písma, špatnou čitelnost a srozumitelnost textu a tedy nesplňovaly základní pravidla pro webové stránky. Existence vícestupňového schvalování by tento problém odstranilo, protože před samotnou publikací článku na web, by estetickou část mohl schválit (nebo odmítnout) člověk, který dané problematice rozumí. Další nevýhodou bylo, že za schvalování stránek byl zodpovědný člověk, který nemohl rozumět všem problematikám, které autoři na stránkách popisovali. Pokud např. editor z Hradce Králové, který měl na starosti duševní vlastnictví, vytvořil stránku, tak schvalovatel pouze zkontroloval základní body a stránku schválil. Schvalovatel nicméně neměl možnost poznat, zda text odpovídá dané problematice. Tento problém by se vyřešil existencí vícestupňového schvalování, kdy by danou stránku musel také schválit např. nadřízený daného editora z Hradce Králové. MCMS umožňovalo dvojí způsob uložení obrázků a dokumentů. První způsob byl přes Image (Resource) galerie. Jednalo se o funkčnost systému, kde bylo možné do složky v systému vložit obrázky nebo dokumenty. Implementace připomínala funkci adresářů. Uživatelé mohli do těchto složek vkládat soubory, na které se pak mohli odkazovat ve stránkách tak, že na daný text vložili odkaz na soubor z Image (Resource) galerie. Druhý způsob nicméně přinesl značné komplikace, protože umožňoval uživatelům vložit soubor nebo obrázek přímo do stránky, bez nutnosti ukládání do Image (Resource) galerie. Tento způsob byl pro uživatel velmi jednoduchý a přímočarý, nicméně neexistovala kontrola, na které soubory se stránka odkazovala.

40

4 Analýza migrace Proces migrace dat je zásadní částí každého přechodu webových stránek na novou technologii. Migrace je vyžadována vždy, když existuje obsah, který musí být přítomen i v nových webových stránkách. Migrace s sebou nepřináší pouze otázku přenesení obsahu stránek z jedné technologie do druhé, ale také návrh nových webových stránek, tak aby odpovídal současným trendům a zákonům. Důležitou roli při migraci hraje i školení uživatelů, tak aby byl přechod na novou technologii co nejplynulejší a uživatelé neměli problémy s používáním nového systému. Do procesu přípravy migrace je nutné zapojit co nejvíc lidí z různých částí organizace, tak aby všechny skupiny uživatelů byly v tomto procesu zainteresovány a mohli vznést připomínky již v době přípravy. Analýza a popis migrace se vztahuje k reálné migraci, která proběhla v roce 2009 na internetových stránkách Celní správy České republiky. Migrace se prováděla z technologie MCMS na technologii MOSS. Jelikož se jednalo o 2 rozdílné technologie, nebylo možné proces migrace kompletně zautomatizovat. Analýza obsahuje návrh jednotlivých řešení i diskuzi, proč je dané řešení navrhováno. Při tvorbě analýzy se vycházelo z doporučovaných postupů společnosti Microsoft12 a z případových studií jiných společností13. Uvedená analýza neobsahuje všechny části, které byly v analýze předané Celní správě. Důvodem je vynechání citlivých, případně tajných informací o prostředí Celní správy, jejichž zveřejnění by mohlo ohrozit bezpečnost prostředí.

4.1 Cíl Cílem analýzy migrace je v časovém předstihu popsat postup migrace a včas odhalit problémy, které mohou samotný proces migrace zpomalit či zkomplikovat. Důraz analýzy je na identifikaci rizik, které mohou při migraci nastat a popsat způsoby, jak se na tyto rizika připravit a eliminovat je. Navržený postup migrace by měl být dostatečně podrobný, aby samotná migrace proběhla bez komplikací a v nejkratším možném termínu. 12

Planning MCMS 2002 Application Migration to SharePoint Server 2007: http://msdn.microsoft.com/enus/library/aa480225.aspx 13

Migrating a MCMS to MOSS 2007 Publishing Internet Site White Paper: http://www.vividgroup.com.au/pdf/MCMS2002ToMOSS2007Migration-WhitePaper.pdf

41

Navržená analýza bude sloužit také pro definování požadavků na jednotlivé části stránek, které bude nutné vytvořit před samotnou migrací (šablona pro MOSS, webové části, aplikace, apod.).

4.2 Požadavky Tato sekce popisuje seznam a popis požadavků, které zadavatel vyžadoval. Zde jsou uvedeny hlavní požadavky na systém z uživatelského hlediska. Požadavky byly sestaveny zástupci odboru informatiky, tiskového oddělení, integrační skupiny a webové rady na základě aktuálních zákonů, vyhlášek Celní správy a nedostatků u současného systému. 1. Přechod na technologii MOSS 2007 Zákazník vyžaduje, aby nový systém pro redakční a produkční prostředí internetových stránek používal technologii MOSS 2007. 2. Sjednocení vzhledu webových stránek Jelikož webové stránky byly vytvářeny velkým množstvím lidí s různým estetickým myšlením, docházelo k situacím, že jednotlivé stránky se buď od sebe velmi lišily, nebo obsahovaly nevhodné formátování za použití množství barev a různých velikostí písma. Migrace stránek měla tento problém odstranit a sjednotit všechny stránky. 3. Provést kontrolu obsahu Některé webové stránky byly vytvořeny při nasazení portálu v roce 2004 a od té doby nebyly změněny. Požadavkem Celní správy bylo, aby při migraci mohly odpovědné odbory provést kontrolu a stránky případně aktualizovat. 4. Upravit strukturu menu Nové stránky budou obsahovat podobnou, ale nikoliv stejnou strukturu hlavního menu. Před migraci je nutné dohodnout novou strukturu a při migraci tuto strukturu použít, tak aby stránky patřily do správné sekce. Jednotlivé položky menu musí jít snadno měnit správcem webu. 5. Nutné zachovat archiv tiskových zpráv a roztřídit jej do samostatných sekcí podle data vydání Migrace dat musí zahrnout přenos množství tiskových zpráv od roku 2004 a roztřídit jej do samostatných kategorií podle roku vydání. Pro archiv tiskových zpráv není prioritní revize vzhledu a obsahu stránek. 6. Nové stránky musí mít validní odkazy na obrázky a dokumenty Některé původní webové stránky obsahují odkazy, které již nejsou platné. Při migraci je nutné tyto stránky identifikovat a po konzultaci příslušného odboru na Celní správě zajistit aktualizaci odkazu na správný dokument. 42

7. Nastavení přístupu k jednotlivým částem webu Nový web musí zajistit nastavení oprávnění k vytváření a editaci stránek v jednotlivých částech webu podle oprávnění jednotlivých oddělení. Tedy, aby jednotlivé stránky mohli editovat pouze editoři, kteří jsou ve struktuře Celní správy za informace zodpovědní. 8. Nastavení schvalovacího procesu dle fyzické struktury Celní správy Proces schvalování stránek a nastavení schvalovatelů musí odpovídat struktuře organizace, tak aby stránky vytvořené v jednotlivých odděleních schvalovaly vedoucí těchto oddělení. Poslední článkem ve schvalování musí být správce webu, který dohledné na správnou formu stránek, tak aby vzhled stránek byl jednotný. Nastavení schvalování musí být dále konfigurovatelné dle potřeby. 9. Lokalizace webu do anglického jazyka a vzájemné propojení s českou verzí Pro poskytování informací v anglickém jazyce musí být vytvořen samostatný web, který bude mít stejný vzhled jako český web, ale bude na českém webu nezávislý. Editoři musí mít možnost propojit českou verzi stránky s anglickou, tak aby bylo možné jednoduše přecházet mezi různými verzemi stránek. 10. Šablony stránek Identifikovat typy stránek, které budou vytvářeny na novém webu a připravit šablony těchto stránek, tak aby se minimalizoval čas nutný k jejím přípravám. Šablony musí zajistit jednotný vzhled stránek a nastavit pravidla pro plnění obsahu (definice textových polí, formát textu, definici povolených akcí).

4.3 Rozdělení rolí Následující tabulka č. 4.1 ukazuje seznam zúčastněných firem a lidí, kteří se podílí na migraci na nový systém MOSS. Autor diplomové práce provádí analýzu migrace v koordinaci se všemi níže uvedenými lidmi.

43

Organizace

Jméno

Popis

Celní správa

Pavel Pelant

Vedoucí oddělení informatiky 12

Celní správa

Martin Kubizna

Správce intranetového portálu a aplikací

Celní správa

Jiří Barták

Tiskový mluvčí Generálního ředitelství cel

CESA

Ondřej Kopp

Zástupce systémového integrátora, QA project manager

CESA

Karel Kukačka

Zástupce systémového integrátora

Xperiensis

Rastislav Maskaľ

Zástupce firmy spravující internetové a intranetové stránky Celní správy.

Tabulka 4.1: Rozdělení rolí mezi zúčastněnými společnostmi

Společnost CESA je systémovým integrátorem v prostředí Celní správy. Dále zajišťuje QA služby pro potřeby internetového a intranetové portálu. Provádí část administrátorských úkonů na internetovém a intranetovém portálu. Společnost Xperiensis je dodavatelská firma, která provádí servis internetového a intranetového portálu a je zodpovědná za migraci z prostředí MCMS do prostředí MOSS.

4.4 Design webových stránek Základní požadavky na obsah na hlavní stránce: • • • • •

Nejčastěji vyhledávané informace na původní webu - Úřední desky, Kurzy, Tiskové zprávy, Aktuality, Volné pracovní místa, Vyhláška a Důležité odkazy. Existence odkazů dle zaměření návštěvníka: Občan, Firma, Média Sekce pro přihlášení a vyhledávání Vzhled musí splňovat pravidla pro přístupnost Standardní odkazy na Mapu webu, přepínání mezi grafickým a textovým režimem, RSS

Pro Celní správu bylo společností Xperiensis vytvořeno několik návrhů, ze kterých byl schválen návrh na obrázku č. 4.2. Výsledný návrh prošel připomínkovým řízením, kdy se k návrhu vyjádřila jednotlivá celní ředitelství.

44

Obrázek č. 4.2: Návrh webových stránek

Každé celní ředitelství bude mít vlastní podweb14, který bude spravován výhradně daným celním ředitelstvím. Rozložení a vzhled bude stejný jako na hlavní stránce, tzn. stejné sekce. Tím bude zajištěn jednotný vzhled webů všech celních ředitelství. Obsah jednotlivých webů celních ředitelství bude relevantní pouze k danému celnímu ředitelství. Vzhled samostatných webů Občan, Média, Firmy bude podobný jako hlavní stránka, pouze bude umožněno vkládat nové sekce dle potřeby správce webu. Konkrétní obsah webů bude určen správcem webu po migraci systému. Ostatní stránky, které budou vytvářeny editory, budou mít pevně stanovenou šablonu. Vzhled těchto stránek bude podobný (tzn. barevné spektrum, text, apod.) jako styl hlavní stránky. Každá stránka bude obsahovat textové pole pro vložení obsahu. V editačním režimu bude docházet k zobrazení WYSIWYG editoru. Jednotlivé sekce (Tiskové zprávy, Aktuality, Volné pracovní místa, Často kladené dotazy a Vyhláška) budou na hlavních stránkách celních ředitelství zobrazovat všechny stránky daného typu, které jsou relevantní v daném celním ředitelství. Tedy nacházejí se ve struktuře daného celního ředitelství. Na hlavní stránce Celní správy bude v těchto sekcích zobrazen seznam stránek ze všech celních ředitelství.

14

Podweb (nebo podprojekt) je samostatná část v systému, která je nezávislá od ostatních částí a obsahuje vlastní stránky, dokumenty a nastavení, které jsou odděleny od ostatních podwebů.

45

4.4.1

Šablony

Pro snadné vytváření stránek určitého typu je nutné vytvořit 2 základní šablony: • •

Šablona pro tiskové zprávy Šablona pro vypsání volného pracovního místa

Pro sekce Aktuality, Často kladené dotazy a Vyhláška se použije standardní šablona s textovým polem. Do budoucna se počítá s více šablonami, ale ty budou vytvářeny až při běhu nového systému. Šablony musí zajistit jednotný vzhled všech stránek, které jsou vytvářeny z dané šablony. Zároveň musí být identifikovány části stránek, které jsou stejné na všech stránkách.

4.4.1.1

Tisková zpráva

Šablona tiskové zprávy je určena pro vytváření stránek, které budou obsahovat danou tiskovou zprávu. Stránka tiskové zprávy bude obsahovat: •

•

•

Hlavičku o adresa Generálního ředitelství cel o datum vytvoření tiskové zprávy – bude přednastaveno na aktuální datum o místo vytvoření tiskové zprávy - odpovídá celnímu ředitelství, ve kterém je tisková zpráva vytvořena) o pevně daný titulek TISKOVÁ ZPRÁVA CELNÍ SPRÁVY ČESKÉ REPUBLIKY o Název celního ředitelství nebo Generálního ředitelství cel Text tiskové zprávy o Název (titulek) zprávy o Samotný obsah tiskové zprávy – HTML text včetně obrázků, videa Podpis – automaticky vložen na základě celního ředitelství

Pro potřeby automatického vložení textu bude vytvořen seznam, který bude pro každé celní ředitelství obsahovat následující data: • • • • •

Url celního ředitelství – bude odpovídat URL webu celního ředitelství Název celního ředitelství Město celního ředitelství ve 4. pádě – pro potřeby vložení místa vytvoření tiskové zprávy Podpis – kontakt na tiskového mluvčí daného celního ředitelství Jazyk

46

4.4.1.2

Volná pracovní místa

Šablona pro vytvoření stránky s vypsáním volného pracovního místa pro pracovní poměr. Šablona bude ve formě tabulky, kde první sloupec bude název kategorie a druhý sloupec bude obsahovat hodnotu. První sloupec bude pevně daný, editor bude vyplňovat hodnoty pouze ve druhém sloupci. Následující atributy musí být obsaženy v šabloně: • • • • • • • • •

4.4.2

Název – jednořádkový text Útvar – jednořádkový text Pracovní náplň – víceřádkový text Požadavky – víceřádkový text Poznámka – víceřádkový text Platové zařazení – jednořádkový text Pracoviště – jednořádkový text Předpokládaný nástup - datum Kontakt – víceřádkový text

Lokalizace

Webové stránky Celní správy budou v první fázi obsahovat pouze českou a anglickou verzi. Pro lokalizaci se využije funkčnosti variací v MOSS. Český a anglický podweb budou odděleny, takže obsah českého a anglického webu se může lišit. Redaktor bude mít možnost po vytvoření české verze stránky vytvořit verzi anglickou. Pokud tak učiní, tyto dvě stránky budou propojeny a uživatel při prohlížení jedné verze bude moci kliknutím na druhý jazyk automaticky přejít na verzi na druhém webu. Pokud propojení nebude existovat (tzn., nebude existovat verze v druhém jazyku), bude čtenář při kliknutí na druhý jazyk přesměrován na hlavní stránku dané lokalizace. Design stránek bude stejný, stejně tak i struktura webu a rozložení na hlavní stránce a na stránkách celních ředitelství.

4.5 Topologie Důležitou části analýzy je definice fyzické architektury výsledného systému. Do této architektury spadá specifikace hardwarových požadavků a topologii sítě. Následující kapitoly obsahují návrh topologie sítě. Při tvorbě návrhu se vycházelo z doporučených postupů společnosti Microsoft, tak jak je uvedeno v knize Planning and architecture for Office SharePoint Server 2007.

47

Výsledné zvolené řešení je plně v kompetenci Celní správy. Tato část analýzy vznikla na základě konzultací se systémovým integrátorem, společností CESA, která zajišťuje technickou podporu pro Celní správu. Hlavními otázkami bylo: • • • • • •

4.5.1

kolik serverů bude potřeba a jaké služby budou na nich spuštěny je možné některé servery virtualizovat umístění redakčního prostředí bude redakční prostředí umístěno v DMZ zóně stejně jako produkční nebo bude umístěno v intranetu operační systém na jednotlivých serverech použitý databázový stroj a jeho verze

Operační systém

Při návrhu architektury i výběru operačního systému se vychází z předpokladu, že všechny servery budou nové a tedy nebudou zatíženy existujícími systémy nebo aplikacemi. Tohoto předpokladu se využívá při výběru operačního systémy, kdy je možné určit libovolný serverový operační systém od společnosti Microsoft. Celní správa používá na svých serverech v největší míře Windows Server 2003, který je po několika letech používání osvědčený. Při výběru operačního systémy tedy byla volba mezi osvědčeným Windows Server 2003 nebo jeho novější verzí 2008, která do doby před migrací nebyla na Celní správě ve větší míře používána. Pro nové internetové stránky se doporučuje použít operační systém Windows Server 2008, aby nebylo nutné v budoucnu provádět znovu migraci na tento operační systém. Systém MOSS podporuje i verzi Windows Server 2003, a tak v případě nutnosti je možné použít i tento operační systém. 4.5.2

Databázový systém

Systém MOSS standardně dle dokumentace podporuje databázový server Microsoft SQL Server 2005 a Microsoft SQL Server 2008. Zde platí stejné doporučení jako u operačního systému. Doporučuje se použít nejnovější verzi Microsoft SQL Serveru z roku 2008, tak aby v budoucnu nebylo nutné provádět migraci databází do nového systému.

48

4.5.3

Webové servery

Webové servery budou sloužit ke generování stránek pro koncové uživatele. Služby, které na něm budou umístěny, se mohou rozdělit do 2 kategorií: webové stránky a webové služby. Počet webových serverů je dle doporučených postupů společnosti Microsoft vhodné volit v počtu větším než 1 a servery umístit do společné farmy s load balancing. Tím bude zajištěn chod internetových stránek i při výpadku jednoho ze serverů. Další výhodou je dostupnost webových stránek při instalaci aktualizací, kdy aktualizace mohou být instalovány po jednotlivých serverech, aniž by došlo k výpadku stránek. Důvodem je i rozložení zátěže na více serverů. Minimální doporučované množství serverů jsou 2 webové servery. Při rozhodování o počtu webových serverů je nutné vzít do úvahy i náročnost správy celé webové farmy, která roste s množstvím webových serverů. Důležitým faktorem při rozhodování musí být plánované vytížení internetových stránek a dostupné hardwarové požadavky. 4.5.4

Databázové servery

Při návrhu počtu databázových serverů je nutné si klást stejné otázky jako při analýze počtu webových serverů. Větší počet databázových serverů přináší snížení rizika výpadku. Na druhou stranu s sebou nese zvýšenou náročnost správy. Výkon celé architektury závisí na zvolené technologii a odborných znalostech administrátorů. Minimální doporučovaný počet databázových serverů je 1 server vyhrazený výhradně pro účely databáze. V tomto případě je nutné zajistit pravidelné zálohování a pravidelně aktualizovaný scénář pro případ výpadku databáze (hardwarová porucha, chyba software). Detailní doporučení na hardwarové vybavení databázových serverů lze nalézt v článku Physical topology recommendations.15 4.5.5

Servery pro indexování a vyhledávání

Základní služby pro zajištění vyhledávání v prostředí MOSS jsou: • •

Indexování obsahu Obsluha požadavků na vyhledávání

Obě služby mohou běžet na 1 serveru nebo mohou být odděleny. Zde záleží na počtu dostupných serverů. Obecně je dokumentací doporučováno pro střední a větší podniky mít služby na samostatných serverech pro zajištění maximálního výkonu. 15

Odkaz: http://technet.microsoft.com/en-us/library/cc298578(office.12).aspx

49

Indexování stránek je výkonově náročná činnost, která vyžaduje tzv. crawling všech dostupných webových stránek a jejich následovné indexování a uložení těchto indexů do databáze. Analýza doporučuje mít služby na samostatných serverech pro zajištění maximálního výkonu. Tak je možné zajistit indexování obsahu několikrát denně a umožnit uživatelům najít vždy správné informace. Mezi další důležitou funkci, kterou budou servery provádět je zpracování importu dat z redakčního prostředí. Tento import dat probíhat jednou denně a při něm dojde k publikaci obsahu vytvořeného na redakčním prostředí do prostředí produkčního. 4.5.6

Redakční prostředí

Redakční prostředí slouží pro vytváření a úpravu obsahu, který je posléze publikován na produkční prostředí. Dokumentace MOSS doporučuje umístit redakční prostředí na samostatný server, který bude nezávislý na produkčním prostředí. Nastavením publikace bude docházet k přenosu dat z redakčního prostředí do produkčního. Výhodou tohoto řešení je oddělení místa pro vytváření a úpravu obsahu od prostředí, které obsah zobrazuje. Jelikož u redakčního prostředí se obecně očekává menší zatížení než u produkčního prostředí, je zde možné použít pouze 1 server. Pokud by bylo vyžadováno je možné redakční prostředí umístit na více serverů a tak zvýšit výkon.

4.5.7

Výsledné doporučení fyzické architektury

Výsledné doporučení architektury je možné vidět na obrázku č. 4.3. Vznikl na základě doporučení z předchozích kapitol a společnosti Microsoft.16 Tento návrh je pouze doporučením nikoliv závazným stanoviskem.

16

Microsoft Technet, Design server farms and topologies: http://technet.microsoft.com/library/cc263157(office.12).aspx

50

Obrázek č. 4.3: Návrh topologie internetového prostředí na Celní správě

4.6 Možnosti migrace dat z MCMS do MOSS Tato sekce popisuje různé způsoby migrace dat z technologie MCMS do MOSS. Konkrétní popis migrace webových stránek na Celní správě lze nalézt v kapitole 4.7. Způsob provedení migrace dat. 4.6.1

Migrace dat pomocí nástroje v MOSS

Microsoft Office Sharepoint Server nabízí možnost importu dat z databáze MCMS. Tato funkce nejprve zanalyzuje stav databáze MCMS a v případě úspěchu provede import dat do prázdného webu v systému MOSS. Funkce provede pouze import obsahu, prezentační část není přenesena, z důvodu odlišností mezi technologiemi MCMS a MOSS. Po importu tedy stránky mají standardní vzhled a je nutné vzhled upravit tak, aby odpovídal potřebám organizace. U této funkce velmi záleží, jakým způsobem byl web v MCMS vytvořen. Při použití nestandardních postupů, např. při tvorbě šablon pro MCMS, nemusí import dat dopadnout úspěšně. Výhodou je, že analýza, která proběhne před importem na důležité

51

chyby a nesrovnalosti upozorní, takže je možné sjednat nápravu ještě před samotným importem. Mezi typické chyby při analýze patří duplicita stránek a dokumentů. V takovém případě je nutné pomocí nástroje Site Manager projít obsah databáze a duplicitní záznamy vymazat. Import dat pomocí nástroje v MOSS je poměrně jednoduchý, vyžaduje sice vyčištění databáze před samotným importem, ale lze se na něj spolehnout. Nevýhodou ovšem zůstává výsledný web, který je nutné výrazně upravit, pokud organizace z něj chce vytvořit nový web v systému MOSS. Samostatnou kapitolu tvoří stav webu při použití nestandardních postupů při tvorbě původního webu MCMS. V takových případech společnost Microsoft nezaručuje, že import proběhl. V takovém případě je poté buď web MCMS upravit před tím než se provede import, nebo použít jiný způsob. 4.6.2

Migrace dat pomocí API

Migrace pomocí API vyžaduje vytvoření nástroje, který se pomocí API připojí na původní web MCMS a přenese data opět pomocí API do technologie MOSS. Tento postup vyžaduje expertní znalosti technologie MCMS a MOSS, takže při výběru dodavatelské firmy nebo zaměstnance, se musí jednat o odborníky, kteří mají s oběma technologiemi bohaté zkušenosti, protože tento způsob je co do odborné stránky nejnáročnější. Výhodou tohoto postupu je možnost vytvoření migračního nástroje, který je maximální měrou přizpůsoben prostředí organizace a stavu původního webu. Stejně tak je možné přesně nadefinovat výstupní stav, jak bude výsledný web vypadat a jak v něm budou dané data vypadat. Tento postup je vhodný, pokud původní web v MCMS byl vytvořen nestandardními postupy. Může být vhodný i pro situace, kdy je zapotřebí maximálně přizpůsobit migraci dat. Nevýhodou může být poměrně značná časová investice do vývoje takového nástroje a velké požadavky na tvůrce tohoto nástroje. 4.6.3

Manuální migrace

Tato možnost migrace dat je vhodná pokud žádnou předchozí možnost nelze použít. Manuální migrace ovšem může být nejvíce časově náročná vzhledem k počtu migrovaných stránek. Výhodou tohoto postupu je, že pokud stránky vytvářeli různí uživatelé, může při migraci stránek dojít k sjednocení vzhledu všech stránek po obsahové stránce. Tohoto nelze docílit jiným způsobem. Ovšem při rozhodování je nutné zjistit, kolik stránek v původním webu existuje a kolik lidí by se účastnilo této migrace. V případě velmi obsáhlých stránek je nutné zvážit, zda časová a finanční investice je vhodná a zda by nebylo vhodnější investovat např. do migrace pomocí API.

52

4.7 Způsob provedení migrace dat Jelikož jeden z požadavků na migraci bylo vyčištění a aktualizace obsahu a změna struktury celého webu, bylo dohodnuto, že nový web bude zcela naplněn novým obsahem. Pouze tiskové zprávy od roku 2004 budou migrovány automaticky. Výsledný návrh způsobu migrace vychází z požadavků Celní správy, s ohledem na co nejkratší dobu migrace. Vzhledem k požadavkům bylo zřejmé, že migrace bude vyžadovat součinnost několika lidí a že celou migraci se nepodaří zautomatizovat do jediného nástroje. Výsledkem je tedy návrh, který počítá s kombinací několika postupů: 1. Migrace pomocí nástroje v MOSS Pomocí nástroje pro migraci dat v MOSS bude provedena migrace celého webu MCMS do pomocného webu v MOSS. Před provedením bude provedena analýza databáze pro odhalení duplicit v názvech stránek a dokumentů. Po odstranění duplicit může být provedena migrace. Výsledný web v MOSS bude obsahovat všechny stránky a tiskové zprávy z původního webu. Pomocný web bude sloužit redaktorům jako vzor pro vytvoření nových stránek. 2. Automatická migrace pomocí API Vzhledem k množství tiskových zpráv nebude možné provést tuto migraci manuálně. Pro migraci všech tiskových zpráv bude vytvořen nástroj, který využívá pouze API MOSS a který z pomocného webu, který byl vytvořen v kroku č. 1, načte a rozpozná všechny tiskové zprávy a opět pomocí API ho vloží do nového webu. Tento postup se ukázal jako nejvhodnější, jelikož manuální migrace všech tiskových zpráv by znamenala velké časové zpoždění. 3. Manuální migrace U ostatních stránek se provede ruční migrace. Před migrací budou stránky rozděleny mezi odpovědné odbory. Jednotlivý editoři mají možnost obsah stránek zkopírovat z pomocného webu nebo vytvořit zcela nový obsah. Po vytvoření stránky, editor odešle stránku ke schválení. Při schválení dojde správcem webu ke kontrole, zda stránky odpovídají standardu tvorby obsahu webových stránek. Pokud stránka neodpovídá standardům, je stránka vrácena zpět k přepracování. Manuální migrace je organizačně náročnější, nicméně zajistí, aby stránky měly jednotný vzhled a aby obsahovaly aktuální informace. Důležitou roli při migraci bude hrát především správce webu, který musí postupně provést kontrolu všech stránek. V období plnění obsahu bude docházet k situacím, kdy je nutné zveřejňovat nové informace na původních stránkách. Tak, aby byla zajištěna přítomnost těchto informací i na novém webu, bude vydáno nařízení, že všechny stránky, které se budou vytvářet v původním webu, se musí vytvořit i na webu novém.

53

4.7.1

Migrace stávajících aplikací

Systém MCMS obsahuje externí webové aplikace, které vyvíjejí a spravují dodavatelské firmy. Na prostředí MCMS běží 6 webových aplikací integrovaných do prostředí, dále 4 aplikace běžící mimo prostředí MCMS a 4 webové služby přístupné z internetu. Jednotlivé aplikace spravují a vyvíjí 5 různých dodavatelských společností. Pro zajištění funkčnosti aplikací v novém prostředí musí být zajištěno několik faktorů: 1. Příprava pro spuštění externích aplikací uvnitř MOSS 2. Instalace externích aplikací na testovací server s nainstalovaným prostředím MOSS 3. Otestování aplikací jednotlivými dodavatelskými firmami

Přípravnou fází je instalace a otestování webové části pro spuštění AFP aplikací uvnitř MOSS. Tuto webovou část vyvine společnost Xperiensis s.r.o. Tím bude zajištěna podpora již existujících integrovaných aplikací. Webové služby a aplikace běžící mimo prostředí MOSS jsou standardně podporovány a není nutný vývoj žádného nástroje pro podporu běhu těchto aplikací. Při migraci bude systémovým integrátorem provedena instalace a konfigurace těchto služeb dle nastavení na původním systému MCMS. Pro otestování všech aplikací a služeb bude připraven samostatný server s připraveným prostředím MOSS, kde budou systémovým integrátorem nainstalovány všechny aplikace a služby a následně dojde k otestování aplikací jednotlivými dodavateli. Dodavatelům bude poskytnuta dostatečná doba pro otestování svých aplikací. Při migraci aplikací dojde ke změně nastavení DNS, tak aby po migraci byly všechny služby a aplikace přístupné na stejných adresách jako před migrací.

4.8 Školení uživatelů Při přechodu na novou technologii je nutné zajistit školení uživatelů, kteří budou daný CMS systém využívat. Je vhodné, pokud se jedná o uživatele, kteří používali předchozí systém, tak aby bylo možné dva systémy srovnat a uživatelům ukázat nové funkce, které jim zjednoduší práci. Počet lidí, kteří na Celní správě mají na starosti vytváření a úpravu webových stránek, lze rozdělit do několika skupin: • • •

tiskový mluvčí – celkem 9 osoby zástupci IT oddělení na každém celním ředitelství – celkem 10 osob administrátoři a zástupci odborů na GŘC – celkem 40 osob

54

Vzhledem k počtu lidí, bude nutné školení rozdělit do několika samostatných částí. První fáze bude školení tiskových mluvčí a zástupců IT oddělení pro každé celní ředitelství. Druhá fáze bylo školení pro administrátory a zástupce odborů na GŘC. Doporučený rozvrh školení je 6 školení v rozsahu 1 dne. Návrh osnovy školení: • • • • • • • • • • •

Úvod Přehled novinek MOSS oproti MCMS Co se změní při publikaci Vytvoření nového článku Editace existujícího článku Editace stránek Práce s vícejazyčným obsahem Práce s multimediálním obsahem Schvalování článků Otestování posluchačů o přednášené problematice Prostor pro připomínky a doplňující dotazy

Při školení bude kladen důraz na procvičení základních úkonů, které budou editoři na stránkách provádět. Školení bude probíhat na připraveném prostředí MOSS. Na školení bude možnost otevřít diskuzi na jednotlivé funkce a případně dohodnout změnu funkcí ještě před samotným spuštěním nového systému.

4.9 Časové termíny migrace Následující tabulka č. 4.4 uvádí návrh časového rozložení migrace a rozdělení úkolů mezi jednotlivé zúčastněné organizace. Finální rozložení je v kompetenci Celní správy, tj. zástupců odboru 12 – informatika. Doporučuje se určit osobu, která bude mít zodpovědnost za migraci ze strany Celní správy a která bude provádět kontrolu vykonaných činností a bude koordinovat postup mezi jednotlivými subjekty.

55

Období

Popis

Dodavatel

Březen 2009 – Červenec 2009

příprava prostředí MOSS a aplikace schváleného vzhledu portálu

Michal Foltýn

Květen 2009 – Červenec 2009

Příprava webové části pro aplikace AFP

Xperiensis

Květen 2009 – Červenec 2009

Zajištění hardware a licencí

Celní správa, CESA

Červenec 2009

Příprava testovacího prostředí s MOSS Xperiensis, CESA

Červenec 2009 – Srpen 2009

Testování aplikací

CESA, dodavatelské firmy

Červenec 2009

Instalace redakčního a produkčního prostředí

Xperiensis, CESA

Červenec 2009

Provedení migrace stávajícího obsahu do pomocného webu

Michal Foltýn, Xperiensis, CESA

Červenec 2009 – Říjen 2009

Plnění obsahu

Celní správa

Říjen 2009

Migrace tiskových zpráv

Michal Foltýn

Říjen 2009

Přepnutí na nové prostředí, vypnutí původního MCMS prostředí

CESA

Tabulka 4.4: Časový plán migrace

Úkoly, které je možné provádět samostatně bez návaznosti na jiné úkoly, se mohou časově prolínat. Tak dojde k urychlení celého procesu migrace. Při plnění obsahu je nutné zajistit, aby při vytváření nového obsahu bylo zajištěno vytvoření do obou systémů, tzn. MCMS i MOSS. Časově nejnáročnější a s vysokou mírou rizika zpoždění je proces plnění obsahu. Z návrhu vyplývá, že plnění obsahu bude probíhat přes období dovolených, z toho důvodu byl nastaven delší časový úsek. Při přepnutí stránek do nového systému se předpokládá, že mohou existovat stránky, které nebyly vloženy do nového systému. O přesném termínu spuštění bude rozhodnuto na základě množství vloženého obsahu a celkové připravenosti systému. Specifikace časových termínů byla vytvořena ve spolupráci se všemi zainteresovanými subjekty.

56

5 Migrace Tato kapitola navrhuje postup pro provedení migrace webových stránek Celní správy ze systému MCMS do systému MOSS. Migrací stránek se rozumí celý proces, který začíná přípravou serverů, migrací stávajících dat a plnění obsahu až po samotné vypnutí stávajícího systému a přepnutí na systém nový.

5.1 Postup migrace

5.1.1

Předpoklady

Pro provedení samotné migrace musí být splněno několik předpokladů: 1. Příprava hardware a instalace softwarových součástí dle navržené topologie 2. Existence testovacího serveru s nainstalovaným MOSS a všemi externími aplikacemi. Tyto aplikace následně musí být otestovány dodavateli. 3. Vytvoření šablony webu a jednotlivých celních ředitelství ve formátu pro MOSS.

5.1.2

Postup

1. Připravit redakční prostředí Redakční prostředí je prioritou, protože umožňuje zaměstnancům plnit obsah. Ostatní části prostředí mohou být doinstalovány později. Samotná příprava se skládá: a. Vytvořit novou kolekci webu za použití šablony webu b. Na hlavní stránky vložit předpřipravené webové části, dle návrhu vzhledu webů. c. Nastavit oprávnění pro jednotlivé weby 2. Provést migraci tiskových zpráv z roku 2004 až do současnosti a. Migraci provádět dle postupu z analýzy 3. Připravit produkční prostředí a. Nainstalovat všechny integrované aplikace třetích stran a provést otestování b. Nastavení vyhledávání 4. Nastavit a spustit publikaci celého obsahu redakčního prostředí do prostředí produkčního. 5. Po naplnění obsahu a finálního schválení od Celní správy přepnout stránky na nový systém a. Přepnutí dojde změnou v DNS záznamech

57

5.1.3

Nedostupnost webových stránek při migraci

Při migraci webových stránek Celní správy nedojde k nedostupnosti stránek pro veřejnost. Jelikož migrace probíhá odděleně od stávajících stránek, v žádném bodu migrace nedojde k nedostupnosti starých stránek. Po migraci stránek dojde k přepnutí DNS záznamů na nové servery s novými stránkami a od té chvíle nebudou pro veřejnost dostupné staré stránky a uživatelům se budou zobrazovat pouze stránky z nového systému. 5.1.4

Postup při neúspěchu migrace

Pokud v libovolném kroku migrace dojde ke komplikacím, které neumožní spuštění stránek v novém systému, bude dočasně pokračovat provoz systému původního a to až do té doby, než bude problém vyřešen. Pokud dojde ke zjištění problémů, které zamezují provoz systému až po přepnutí stránek na nový systém, bude obnovena činnost původního systému a to změnou DNS záznamů zpět na MCMS systém.

5.2 Shrnutí migrace Tato sekce popisuje výsledek migrace a také se snaží identifikovat problémy, které při migraci nastaly. Jelikož se jednalo o rozsáhlou migraci dat, která probíhala ze zastaralého systému, který není zcela kompatibilní s novou technologií, předpokládalo se, že při celém procesu migrace dojde ke komplikacím. Důkladná analýza, která provedla zkušební migraci ještě před samotnou ostrou migrací, identifikovala a eliminovala řadu rizik. Analýza navrhla dostatečný časový plán, který počítal i se zpožděním u jednotlivých činností. Přesto došlo k posunutí migrace o 2 měsíce, které nakonec proběhlo v prosinci 2009. Důvody zpoždění: 1. Příliš dlouhá doba mezi školením a začátkem plnění webu. To mělo za následek, že uživatelé některé činnosti ze školení zapomněli, což zbrzdilo proces plnění obsahu. 2. Termín na testování externích aplikací byl prodloužen. Kvůli vytížení dodavatelských firem, došlo k posunutí termínu na testování aplikací. 3. Doba pro plnění obsahu byla několikrát prodloužena. Došlo k situaci, na kterou byl brán ohled při plánování časových termínů a i přesto došlo několikrát k posunům termínu u ručního plnění obsahu. Ukázalo se, že doba dovolených značně zkomplikovala proces plnění obsahu. Samotný obsah byl navíc 58

značně rozsáhlý a většina zaměstnanců toto prováděla nad rámec svých povinností. 4. Změny vzhledu a rozložení stránek po aplikaci vzhledu do MOSS. Jelikož každá změna v rozložení stránek je časově náročnou operací, došlo ke zpoždění, kdy se prováděli změny v průběhu celého procesu migrace. Při samotné migraci nedošlo k vážnějším komplikacím. Po migraci ovšem byly několik hodin nedostupné webové služby, kdy při migraci nebyla provedena úprava DNS záznamů. Postup zvolený v analýze migrace se ukázal jako správný a při vykonávání jednotlivých částí nedošlo k žádným problémům. Výsledek migrace byl stejný, jaký očekávala analýza migrace. 5.2.1

Časový průběh migrace

Následující tabulka 5.1 sepisuje časový průběh migrace a vykonání jednotlivých částí migrace.

59

Datum

Činnost

Vykonavatel

1.7.2009

Dokončení instalace a příprava redakčního prostředí MOSS.

CESA, Celní správa

2.7.2009

Aplikace vzhledu nových stránek do prostředí MOSS. Instalace šablon.

Xperiensis

10.7.2009

Dokončení úpravy vzhledů jednotlivých podwebů, nastavení webových částí, podpora RSS

Xperiensis

18.9.2009

Dokončení úpravy šablon webů a stránek pro podporu přístupnosti

Xperiensis

1.10.2009

Dokončení instalace a příprava produkčního prostředí.

CESA, Celní správa

2.10.2009

Nastavení publikace obsahu z redakčního prostředí do produkčního

Xperiensis

21.10.2009

Dokončení nastavení vyhledávání na produkčním prostředí

Xperiensis

4.12.2009

Provedení migrace archivu tiskových zpráv

Michal Foltýn

10.12.2009

Instalace webových částí pro podporu běhu integrovaných aplikací.

Xperiensis

11.12.2009

Instalace a finální testování integrovaných aplikací na nové prostředí.

CESA

15.12.2009

Schválení obsahu nového webu Redakční radou, povolení k přechodu na nový systém.

Celní správa

16.12.2009

Kontrola obsahu, migrace nově vytvořených tiskových zpráv.

Xperiensis

17.12.2009

Změna DNS záznamů, faktický přechod na nový systém.

Celní správa, CESA

Tabulka 5.1: Časový průběh migrace z prostředí MCMS do MOSS

Následující činnosti probíhali po celou dobu migrace: • • • •

Nastavení práv na jednotlivé podweby zaměstnancům Celní správy Plnění obsahu Drobné úpravy v designu stránek Nastavení schvalovacího procesu u jednotlivých podwebů dle požadavků Celní správy

60

5.2.2

Ponaučení

Při jakékoliv migraci je zcela nezbytná důkladná analýza. Analýza, pokud to situace dovoluje, musí být psána na základě provedení testovací migrace. Jen tak lze identifikovat problémy, které mohou nastat. Pokud součástí migrace je komunikace i s externími dodavatelskými firmami, je nutné počítat s dostatečnou časovou rezervou. Pokud se dodavatelské firmy účastní samotné migrace, je nutné přesně definovat, jaké činnosti jsou vyžadovány a úpěnlivě trvat na dodržení časových termínů. Mezi největší rizika migrace bezpochyby patří součinnost s ostatními společnostmi. 5.2.3

Návrhy na zlepšení

Analýza migrace dostatečně popsala postup migrace a rozdělení jednotlivých rolí mezi zodpovědné osoby. Nicméně při tak rozsáhlé migraci dat nelze postihnout všechny případy a dochází ke zpoždění navržených úkolů. Tato kapitola popisuje návrhy na zlepšení, chyby, kterých se při podobné migraci vyvarovat a rozhodnutí, která analýza migrace navrhovala a ukázala se jako méně vhodná. Analýza, ačkoliv definovala dostatečnou časovou rezervu pro plnění obsahu zaměstnanci, podcenila rozsah a časovou náročnost této úlohy. Mezi hlavní příčiny zpoždění u plnění obsahu patřilo: 1. Plnění obsahu do nového systému bylo nad rámec standardních povinností zaměstnanců 2. Doba plnění obsahu probíhala v čase dovolených (červenec, srpen)

Tyto problémy lze řešit několika způsoby: • • •

Dočasně odebrat některé standardní povinnosti zaměstnance a tak vytvořit časový prostor pro plnění obsahu Pokusit se zaměstnance motivovat finančně nebo různými benefity Dočasně najmout zaměstnance

Výše uvedené návrhy záleží na dostupných prostředcích, času, kapacitních omezení, apod. V přípravné fázi docházelo k nutné součinnosti s ostatními dodavatelskými firmami. Ačkoliv zde nedošlo ke zpoždění, které by způsobilo posun celé migrace, tak došlo k situacím, které analýza dostatečně neodhadla. Při součinnosti s více firmami je nutné zajistit: 1. S dostatečným časovým předstihem definovat průběh prací, tak aby jednotlivé firmy se na to mohli připravit. 2. Přesně definovat termíny a zodpovědné osoby, které provedou kontrolu provedených úkolů. 3. Mít dostatečnou časovou rezervu pro řešení vzniklých problémů.

61

Pokud jsou součástí migrace samostatné funkční celky, které jsou nezávislé na novém systému, je nutné přesně specifikovat postup migrace těchto částí (v tomto případě webové aplikace). Důležité je zajistit následující body: 1. Provést dostatečné otestování na nových serverech a jasně definovat, kdo je za otestování zodpovědný. 2. Specifikovat postup pro případ nefunkčnosti aplikací po migraci.

I přes důkladné a úspěšné otestování může dojít k situaci, že některá aplikace nebude po migraci funkční. Z toho důvodu je nutné mít připravený scénář, který bude definovat postup prací v takovém případě. To je nutné pro zajištění dostupnosti jednotlivých webových aplikací i po migraci celého systému. To lze zajistit např. přesměrováním požadavků na aplikaci na původním serveru. 5.2.4

Výsledky migrace z pohledu Celní správy

Změna redakčního systému s sebou přinesla i změny v procesech na Celní správě. Změny se dotkly především zaměstnanců, kteří jsou zodpovědní za určitou oblast, která je prezentována na webových stránkách. První výraznou změnou bylo rozdělení webových stránek do podprojektů, samostatných podwebů, za které nese zodpovědnost určitý odbor nebo oddělení. Tento záměr byl i při používání původního systému MCMS, ale jelikož MCMS nemělo tak přehledné a intuitivní rozdělení do podprojektů, nikdy nebylo vážněji použito. MOSS přinesl možnost přesně definovat oblasti a k nim určit zaměstnance. Toto je úzce spojeno s nastavením práv, které byly nastaveny zcela od začátku a tak již od spuštění stránek byly práva nastaveny těm správným osobám. Nových změn doznalo i schvalování obsahu, které díky pracovnímu postupu v MOSS umožňovalo nastavit vícestupňové schvalování. Při vytvoření nebo provedení změn na stránce, editor odešle stránku ke schválení. Má možnost napsat poznámku, jaké změny byly provedeny, tak aby usnadnil práci schvalovateli. Schvalovatel, většinou se jedná o vedoucího odboru nebo oddělení, dostane emailem upozornění, že byla vytvořena stránka, která vyžaduje jeho schválení. Vedoucí zkontroluje obsah stránky a rozhodne, zda může být stránka postoupena dále nebo bude vrácena k přepracování. Pokud je stránka v pořádku, proces schvalování postupuje dále ke správci webu, který je poslední článkem procesu. Správce webu rozhodne, zda forma obsahu odpovídá standardům pro vytváření stránek a případně vrátí stránku zpět editorovi. Při schválení stránky správcem webu je stránka zařazena do seznamu pro publikaci a bude v nejbližším běhu publikace zveřejněna na internetových stránkách. Tento nový proces schvalování zajišťuje, že na web jsou umístěny ty správné informace (schválení vedoucím) a jednotný vzhled všech stránek (správce webu). Pro správnou funkčnost tohoto procesu je nutné zajistit, aby editor nebyl zároveň schvalovatelem a správce webu se snažil co nejvíce držet stejný vzhled stránek. 62

Díky vytvořeným šablonám došlo ke sjednocení vzhledu jednotlivých typů zpráv. Příkladem může být tisková zpráva, kde šablona zajišťuje, aby tiskoví mluvčí zadaly pouze relevantní informace. Opakující se text, jako např. titulek, podpis, apod. je vkládán automaticky a tím zrychluje vytváření tiskové zprávy. Nový editor pro vkládání textu usnadňuje zaměstnancům vytváření obsahu, protože je navržen, aby co nejvíce připomínal textový editor, který je na Celní správě využíván. 5.2.5

Budoucí vývoj

Provedením migrace práce na novém systému neskončila. Od rozhodnutí pro provedení migrace bylo zřejmé, že práce na novém systému budou pokračovat i po migraci. Stav po migraci byl základním výchozím bodem pro práci se systémem a zajistil, aby bylo možné systém dále rozšiřovat dle požadavků uživatelů a administrátorů. Následující tabulka ukazuje několik úkolů, které se začaly řešit po provedení migrace. Název Úprava stylů pro existující integrované aplikace Postupné odstranění odkazů na externí aplikace a nahrazení integrovaným řešením Úprava ve vzhledu stránek Vytvoření webových částí pro snadné odkazování na existující stránky v daném podprojektu Přidání nových důležitých odkazů Optimalizace vyhledávání, definování přísnějších pravidel pro indexování Vytvoření manuálního spuštění publikace bez nutnosti přístupu na administrační server Tabulka 5.2: Seznam řešených úkolů po migraci

Budoucí rozšiřování systému je zajištěno, jak použitím možností v MOSS 2007, tak i za použití frameworku Eos, který umožňuje rozšiřovat funkčnosti vlastními webovými aplikacemi.

63

6 Framework pro integrované aplikace do MOSS Prostředí Microsoft Office Sharepoint Server nabízí Celní správě možnosti, jak zjednodušit publikování informací na svých webových stránkách. CMS systémy jsou hojně využívány pro svou schopnost jednoduchým způsobem delegovat vytváření stránek oprávněným osobám a těmto oprávněným osobám co nejvíce ulehčit tvorbu stránek. Jakmile potřeby organizace vyžadují složitější logiku a prosté zobrazení stránky s textem nestačí, je nutné vyhledat řešení, které umožní CMS systém rozšířit. Pokud organizace vyžaduje automatizaci některého ze svých procesů, obvykle výsledkem bývá buď aplikace typu tlustý klient, nebo webová aplikace. Webová aplikace obvykle obsahuje několik stránek a možnosti přechodu mezi těmito stránkami. CMS systémy jsou také příkladem webových aplikací. Když potřeby organizace přesáhnou možnosti CMS systému, je nutné CMS systém rozšířit tak, aby bylo možné do stránek v CMS systému vložit webové aplikace a to takovým způsobem, aby uživatel nepoznal, že se jedná o samostatnou aplikaci. Vložení webové aplikace do jiného systému se nazývá integrace a tyto aplikace se poté nazývají integrované aplikace. S příchodem CMS systému MCMS na Celní správu bylo zřejmé, že funkce CMS systému nebudou dostačující pro potřeby Celní správy. Bylo tedy nutné zajistit, aby dodavatelské firmy, které měly na starosti vývoj externích aplikací, měly možnost jednoduchým způsobem integrovat aplikace do MCMS. Za tímto účelem byl společností Unicorn vytvořen framework pro webové aplikace napsané v prostředí ASP.NET. Framework zajišťoval, po splnění určitých pravidel, že aplikaci lze jednoduchým způsobem vložit do MCMS. Mezi nejdůležitější pravidla patřilo: • • • •

třídy stránek musely dědit určenou třídu z frameworku navigace mezi stránkami probíhala voláním metody z frameworku dodržení jednotných css stylů společné zabezpečení pomocí externí webové služby Security Provider

Snahou tvůrců frameworku bylo vytvořit takový framework, který by v nejmenší možné míře limitoval vývojáře a přesto dokázal zobrazit webové aplikace uvnitř stránek MCMS. Důležitou vlastností frameworku byla skutečnost, že dodavatelské firmy mohly vyvíjet své webové aplikace bez přítomnosti MCMS.

65

Obrázek 6.1: Aplikace Seznam celních útvarů integrovaná do MCMS

Framework AFP byl vyvinut v roce 2004 a v dnešní době již nevyhovuje požadavkům Celní správy ani dodavatelských firem. Dodavatelské firmy jsou v dnešní době velmi omezeny, jelikož nemohou používat všechny nástroje a technologie, na které jsou při vývoji zvyklé a které jsou při vývoji obvyklé. Velkou nevýhodou AFP frameworku v současné době je rychlost, kdy velmi výrazně chybí optimalizace výkonu vnitřních částí AFP frameworku za použití cache.

6.1 Cíl Cílem této části práce je vytvořit nový framework určený pro systém Microsoft Office Sharepoint 2007 a novější, který by Celní správě umožnil integrovat aplikace napsané nad tímto frameworkem do systému a přitom neomezoval vývoj na straně dodavatelských firem. Toto řešení bude rozšiřovat možnosti redakčního systému a umožní do stránek redakčního systému vkládat webové aplikace. Autor diplomové práce v této části sepsal požadavky na softwarové dílo, provedl analýzu a následně implementoval framework. Jednotlivé části práce byly konzultovány se společností Xperiensis a Celní správou. Přestože požadavek na framework vzešel od zástupců Celní správy, cílem je vytvořit framework, který je možné použít i v jiném prostředí a umožnit tak využití frameworku v širším spektru.

66

6.2 Požadavky Tato kapitola obsahuje seznam požadavků, které jsou kladeny na framework. Jedná se o stručný popis požadavků, které mají za cíl nastínit budoucí využití díla. Požadavky byly sepsány na základě konzultací se společností Xperiensis a Celní správou.

1. Jednoduchá integrace aplikací do MOSS Aplikace napsané nad frameworkem musí být schopné jednoduchým způsobem zobrazit na stránce v systému MOSS. 2. Webové aplikace lze vyvíjet i bez nainstalovaného prostředí MOSS Framework musí dodavatelským firmám umožnit vývoj aplikace i bez nainstalovaného prostředí MOSS. Aplikace napsaná nad frameworkem musí jít zobrazit v prostředí MOSS i mimo něj. 3. Framework musí zabezpečit automatické ověřování práv Framework musí zajistit, že při každém přístupu na stránku je ověřeno, že uživatel má k této stránce přístup. 4. Framework nesmí omezovat použití standardních webových technologií Dodavatelské firmy nesmí být omezovány pro použití nástrojů a technologií (kompatibilních s .NET) při vývoji aplikací nad frameworkem. 5. Framework musí být optimalizován Framework musí být optimalizován, tak aby zbytečně nezpomaloval chod aplikací. 6. Dokumentace Dokumentace k frameworku musí být napsána tak, aby byla srozumitelná a bylo možné podle ní postupovat v případě úprav a rozšiřování frameworku 7. Framework musí poskytovat komponenty pro logování a audit Framework musí zajistit, aby všechny aplikace napsané nad tímto frameworkem, měly společný výstup logování a auditu. Z důvodu návaznosti na framework AFP je nutné použít stejný způsob ověřování práv. Při návrhu a vývoji je nutné pamatovat, že framework budou používat i externí dodavatelské firmy. Je tedy nutné se v co největší míře vyvarovat nestandardních řešení při vývoji frameworku. Pokud je nutné použít nestandardní řešení, toto řešení musí být důkladně zdokumentováno. Při vývoji frameworku není nutné vycházet z frameworku AFP, který byl určen pro MCMS. Pro zachování kontinuity práce je pouze nutné převzít logiku ověřování práv. Pro zajištění maximálního užitku je vyžadováno napsat framework od začátku, tak aby bylo možné 67

použít moderní nástroje a technologie a praktiky softwarové architektury. Kompatibilita s frameworkem AFP není vyžadována. Cílem této diplomové práce je navrhnout a implementovat prototyp frameworku, který splňuje výše uvedené požadavky.

6.3 Terminologie Pro správné pochopení návrhu a implementace je nutné porozumět vytváření a struktuře stránek v ASP.NET a uvnitř MOSS. V následujících kapitolách je uveden základní úvod do problematiky, který je nezbytný pro zbytek textu. Detailní popis je mimo rozsah této diplomové práce. 6.3.1

Tvorba a struktura stránek v ASP.NET

Stránky v ASP.NET se dělí do 2 částí: • •

.aspx stránka – obsahuje rozložení stránky v kódu HTML za použití značek, které představují HTML element .cs třída – která definuje logiku pro každou stránku. Zde je možné měnit obsah a zajišťuje manipulaci s elementy stránky

Pro základní aplikace stačí vytvořit aspx stránku, pomocí HTML a serverových značek do ní vložit obsah. Pokud je nutné zajistit jednotný vzhled všech stránek v aplikaci, je vhodné použít tzv. Master stránku, která slouží pro definici jednotné vzhledu a rozložení. Pro zajištění přehlednosti aspx stránek a také podpory znuvupoužitelnosti částí stránek, slouží uživatelské prvky (usercontrols), což jsou samostatné soubory ascx, které lze vkládat do aspx stránek. Usercontrols představují části stránky a lze je vkládat do více aspx stránek. Usercontrols si lze představit jako samostatné funkční celky, ze kterých lze skládat stránky a tak definovat znovupoužitelný obsah. ASP.NET umožňuje tvorbu tzv. Master stránek, které slouží pro definici vzhledu a rozložení stránky. Master stránky jsou šablony, které definují jednotný vzhled a rozložení pro všechny stránky v aplikaci. 6.3.2

Stránky v MOSS

MOSS vychází z technologie ASP.NET a tedy struktura stránek je podobná. Zásadní rozdíl spočívá ve tvorbě stránek. Stejně jako v ASP.NET stránky v MOSS jsou děleny na Master stránky, obsahové stránky .aspx.

68

Master page je pevně definovaná a obyčejný uživatel/editor ji nemůže změnit. Při vytváření stránky si editor vybere šablonu stránky, kterou chce použít. Šablona definuje rozložení webových zón, případně dalších částí.

Obrázek 6.2: Použití Master a Content stránky.

17

Do webových zón může editor vkládat uživatelské webové části a tím definovat obsah. Každá stránka je složena z šablonové stránky (Master page) a obsahové stránky (Content page). Master stránka umožňuje vytvořit konzistentní šablonu pro všechny stránky v aplikaci. Master stránka definuje vzhled a rozložení stránky pro všechny stránky. Obsahová stránka poté definuje obsah, který se zobrazí v jednotlivých částech definovaných v Master stránce. Aby bylo umožněno uživatelům měnit obsah stránek, které obvykle obsahují i dynamické prvky jako obrázky, videa, různé bloky textu, je nutné jim umožnit měnit a vkládat prvky do stránky. To je v .NET frameworku zajištěno webovými zónami a webovými částmi. Webové zóny na stránce definují oblasti, do kterých uživatel může vkládat webové části. Webových zón na stránce může být libovolné množství dle potřeby organizace. Webové části jsou prvky, které plní určitou funkci. Může se jednat o textový editor, o zobrazení konkrétního obrázku, zobrazení videa, tabulky, apod. Webová část může být libovolná funkčnost a díky možnosti implementace vlastní webové části její použití je takřka neomezené. 17

Zdroj: http://interval.cz/clanky/master-pages-v-aspnet-20/

69

6.4 Analýza Při návrhu frameworku je nutné počítat s důkladnou analýzou. Jelikož framework bude zásadním stavebním kamenem aplikací běžících uvnitř MOSS, není možné podcenit libovolnou část. Důležitým faktorem při tvorbě architektury je zamyšlení nad možnými způsoby integrace aplikace do systému MOSS. Zde je nutné vycházet pouze z možností, které umožňuje systém MOSS a programovací prostředí .NET. Pro správný návrh bylo nutné porozumět způsobu práce MOSS se stránkami. Při návrhu se bral velký důraz na použití frameworku a splnění požadavku na co nejmenší omezení pro dodavatelské firmy. Zároveň byla snaha o vytvoření co nejmenšího frameworku, který by plnil pouze dané požadavky a nesnažil se vytvářet funkce, které by si měla zajišťovat aplikace sama. 6.4.1

Dostupné produkty na trhu

Standardní postupy doporučují v případě nutnosti o rozšíření systému použít vlastní webové části. Vývoj webových částí je dobře zdokumentován, nicméně jedná se o nepohodlný způsob vývoje aplikace, jelikož veškeré grafické rozhraní musí být psáno v kódů bez dostupnosti standardních nástrojů. Dalším způsobem běžně doporučovaným je umístění aspx stránek do struktur Sharepointu (konkrétně do složky _layouts). Tento způsob je vhodný pro vývoj aplikací, které mají minimální počet stránek, jelikož při použití více stránek je značně komplikovaná správa navigace mezi stránkami. Podobný způsob řešení, jako navrhuje diplomová práce, je použit v nástroji od původních autorů frameworku AFP. Tento nástroj je ovšem komerční a pro potřeby srovnání nebyl poskytnut. 6.4.2

Způsob integrace do MOSS

Jednotlivé stránky v MOSS se skládají z webových zón, do kterých lze vložit webovou část. Pro vložení aplikace do stránky se tedy jeví jako vhodné použít webovou část, která zobrazí stránky aplikace. Taková webová část bude muset zajistit kompletní správu aplikace, přechod mezi stránkami, správu chyb, apod. Výhodou tohoto řešení bude, že editor si bude moci vytvořit stránku v libovolné struktuře a do ní vložit aplikaci. Tedy řešení bude značně flexibilní a po instalaci nebude vyžadovat součinnost dodavatele nebo správce webu. Jelikož nám framework umožňuje vytvořit vlastní webovou část, můžeme tímto způsobem umožnit zobrazení aplikace uvnitř stránky v MOSS. 70

Důležité je rozhodnout, jakým způsobem dojde k zobrazení aplikace uvnitř webové části. Zde se nabízí několik možností: 1. Zobrazení v IFrame – funkční možnost, ale pro potřeby nevhodná. IFrame dokáže vložit stránku do jiné stránky na základě URL. Nevýhodou je absence podpory ze strany webových standardů a porušení pravidel pro přístupnost. 2. Vložení aplikace do interních struktur MOSS – také funkční možnost, ale nevýhodou je umístění stránek mimo ostatní stránky webu a komplikovaný přechod mezi stránkami. Tento postup není doporučován a pro větší aplikace není vhodný pro příliš velkou režii. 3. Využití možností .NET frameworku pro načtení usercontrolu do stránky za běhu.

Framework .NET umožňuje dynamicky vložit do stránky libovolný usercontrol. To se provádí voláním metody: Page.LoadControl(string relativeUserControlPath)

Parameter relativeUserControlPath je relativní cesta k usercontrol v rámci webového adresáře. Třetí možnost je implementačně nejnáročnější, ale umožňuje kompletní kontrolu u načítání stránek aplikace. Nevýhodou řešení je nutnost mít jednotlivé stránky aplikace umístěné v ascx souborech. 6.4.3

Výběr aplikace pro zobrazení na stránce

Webová část, která bude zajišťovat zobrazení aplikace ve stránce, bude univerzální pro všechny aplikace. Při vložení webové části do stránky bude uživatel vyzván k zadání aplikace, která má být ve webové části zobrazena. Po potvrzení a uložení dojde k načtení prvního usercontrol z dané aplikace. Tímto bude umožněno editorům vytvářet stránky a vkládat do nich dle potřeby aplikace třetích stran. Pokud bude editor vyžadovat změnu aplikace na stránce, přejde do editačního režimu a v nastavení webové části změní aplikaci. Zadání aplikace pro zobrazení ve webové části bude probíhat výběrem aplikace ze seznamu. Seznam aplikací bude načítán z databáze, která obsahuje seznam všech zaregistrovaných integrovaných aplikací.

71

6.4.4

Způsob vývoje aplikací ve frameworku

Jelikož způsob integrace aplikací do MOSS zčásti omezuje vývoj, je nutné při návrhu počítat, že všechny stránky webové aplikace budou definovány v ascx souborech a webová část zařídí zobrazení jednotlivých usercontrols a přechod mezi nimi. Pro přechod mezi stránkami musí být použita speciální metoda, která řekne webové části, aby změnila usercontrol. Ostatní standardní metody přesunu na jinou stránku nebudou povoleny. 6.4.5

Ověřování práv

Při přístupu na každou stránku aplikace bude docházet automaticky ke kontrole, zda aktuálně přihlášený uživatel má na danou stránku přístup. K tomuto kroku bude docházet při žádosti o přechod na novou stránku. Pokud uživatel má právo, bude stránka zobrazena. V opačném případě dojde k zobrazení informace o nedostatečných právech. Všechny uživatelské účty jsou uloženy v adresářové službě Active Directory. Účty mohou být sdružovány do uživatelských skupin, jako např. Administrátoři, Ředitelé, Účetní, apod. Ověřování práv funguje tak, že každá stránka aplikace se nazývá usecase. Pro každý usecase je definován seznam uživatelských skupin Active Directory. Při přístupu na stránku (usecase) framework ověří, zda aktuálně přihlášený uživatel se nachází alespoň v jedné ze skupin, které jsou k danému usecase přiřazeny. Pokud ano, uživateli je zobrazena stránka. V opačném případě je uživateli zobrazena stránka s informací, že na danou stránku nemá dostatečná oprávnění. Pro každou aplikaci je v Active Directory vytvořena samostatná organizační jednotka. Organizační jednotku si lze představit jako adresář, který pouze obsahuje další objekty. Pro každou aplikaci je definován seznam uživatelských skupin, které představují jednotlivé skupiny oprávnění, např. Administrátoři, Běžní uživatelé, apod. V těchto uživatelských skupinách jsou obsazeni jednotliví uživatelé. Tento formát je již zaveden a nebude se měnit. Obsazovaní a vytváření jednotlivých uživatelů, skupin, organizačních jednotek je řešena samostatnou aplikací a je to v kompetenci Celní správy. Pro vytvoření vztahu usecase-skupina bude vytvořena databáze, která obsahovat informace nutné pro ověření práv ve frameworku. Databáze bude obsahovat 4 tabulky: • • • •

Application – seznam všech integrovaných aplikací využívající framework Group – seznam skupin pro každou aplikaci Usecase – seznam usecase pro každou aplikaci UsecaseGroup - vazební tabulka, která nastaví propojení mezi usecase a skupinou.

72

6.4.6

Logování, audit

Framework bude automaticky poskytovat metody pro logování a audit. Interně bude implementována podpora pro Enterprise Library Logging Block, který umožňuje rozsáhlou konfiguraci logování, např. do souboru, databáze, apod. Díky použití Unity bude možné za běhu aplikace změnit implementaci logování. Tak bude zajištěna podpora různých logovacích mechanismů. Audit bude probíhat zapisováním informací do databáze. Metody auditu budou přístupné i klientským aplikacím. 6.4.7

Rozšiřitelnost

Implementace částí frameworku, u kterých se bude předpokládat možné nahrazení jinou implementací, bude řešená pomocí Dependency Injection, tak aby bylo možné snadno, změnou hodnoty v konfiguraci, nahradit libovolnou část vlastním řešením. Tím bude docíleno, že pokud v budoucnu nebude vyhovovat některá funkčnost, lze ji snadno vyměnit, bez nutnosti zásahu do frameworku. Mezi části, které bude možné nahradit vlastní implementací, bude patřit: • • • • •

Logování Audit Cachování Ověřování práv Použitá databáze u ověřování práv

6.5 Popis architektury Framework se skládá z následujících knihoven: • • • •

Eos.Core.dll Eos.dll Eos.Components.dll Knihovny Microsoft Enterprise Library projektu

Všechny aplikace, které jsou vyvíjeny nad tímto frameworkem, musí obsahovat reference na tyto knihovny. Framework byl navržen s co největší snahou o budoucí rozšiřitelnost a spravovatelnost a zároveň se snahou, co nejméně omezovat vývojáře při vývoji aplikací, tak aby každá společnost nebo vývojář mohl používat nástroje, postupy a pravidla, na které je zvyklý. Cílem frameworku je zajistit snadnou integraci aplikací do internetového prostředí Celní správy a zajistit jednotný způsob ověřování, logování a auditu. 73

Stručný přehled důvodů a výhod Eos frameworku: • • • • • •

Automaticky zpřístupňuje další komponenty pro ověřování práv, logování, … Implicitně ověřuje uživatele při přístupu ke stránce Eos striktně nedefinuje strukturu, ale pokud jsou dodržena obecně stanovená pravidla použití, je vývoj rychlejší, nároky na údržbu nižší a aplikace mají obecně vyšší výkon Snadná správa a analýza případných problému Podpora jednotného a přesně definovaného způsobu nasazení těchto aplikací Podpora jednotného logování

Při vývoji frameworku se vycházelo z doporučení na tvorbu frameworku, jak je uvedeno v Adams Brad (2002). Tato doporučení se týkala pojmenování jednotlivých částí a rozdělení jednotlivých části do funkčních celků, tak aby byly srozumitelné jak pro použití, tak i pro budoucí rozšiřování frameworku. 6.5.1

Eos.Core

Knihovna obsahuje abstraktní datové typy a rozhraní, které jsou společné pro všechny ostatní části frameworku. Oddělení rozhraní od samotné implementace už na úrovni knihoven zajišťuje podporu rozšiřitelnosti frameworku. Důležité části frameworku jsou vždy odvozeny od rozhraní, které jsou definovány v této knihovně. Díky použití návrhového vzoru Dependency Injection je možné implementaci těchto částí nahradit později a to pouhou změnou konfiguračního souboru. Vlastní implementace musí být odvozena od daného rozhraní. 6.5.2

Eos

Knihovna obsahuje implementaci rozhraní definovaných v Eos.Core a poskytuje klientským aplikacím metody, vlastnosti a třídy pro podporu integrace do prostředí Celní správy. Knihovna obsahuje implementaci webových částí, do kterých jsou aplikace vkládány a zajišťuje zobrazení a přechod mezi jednotlivými stránkami aplikace. 6.5.3

Eos.Components

Knihovna obsahuje implementaci komponent pro: • • • •

logování (LogProvider) cachování (CacheProvider) audit (AuditProvider) zajištění bezpečnosti (SecurityProvider)

74

Tato knihovna poskytuje aplikacím základní funkce a v případě potřeby je možné implementaci jednotlivých komponent nahradit vlastní implementací. Jednotlivé komponenty jsou dále v dokumentu popsány detailněji. 6.5.4

Knihovny projektu Microsoft Enterprise Library

Enterprise Library je sada knihoven, dostupných zdarma a se zdrojovými kódy od společnosti Microsoft. Knihovny řeší obvyklé programátorské problémy, jako např. logování, cachování, zpracování výjimek, přístup k databázi, apod. Tedy úlohy, které se opakují v každé aplikaci. Výhodou jednotlivých knihoven je ověřená funkcionalita a podrobné možnosti konfigurace. Ve frameworku Eos byly použity následující části z Enterprise Library: • • •

Caching Application Block – podpora cachování Logging Application Block – podpora logování Unity – řešení dependency injection pro snadnou rozšiřitelnost

Všechny části se vyznačují velkou škálou možností konfigurace, tak aby bylo možné provést nastavení dle aktuálních potřeb společností a Celní správy. 6.5.5

Způsob integrace aplikací

Pro integraci do Microsoft Office Sharepoint Serveru se využívá funkcionality webových částí. Byla vyvinuta vlastní webová část pro aplikace napsané ve frameworku Eos, která zajišťuje zobrazení aplikací uvnitř stránky. Tato webová část se stará o zobrazení aplikace, ověření přístupu, přechod mezi stránkami a zcela odstiňuje aplikace od prostředí, ve kterém běží. Tedy při vývoji aplikace není nutné znát problematiku prostředí, ve kterém bude aplikace nasazena. Pro správnou integraci aplikace je nutné, aby všechny stránky aplikace byly umístěny do souborů ascx. Tedy souborů pro uživatelské prvky. Jakákoliv funkcionalita v aspx souborech nebude viditelná ani dostupná na produkčním prostředí. Pro vývoj aplikací byl navržen postup, jak co nejvíce simulovat prostředí MOSS bez nutnosti přípravy vývojového prostředí. Při fázi vývoje framework nevyžaduje umístění vývojového počítače do domény ani přítomnost systému Microsoft Office Sharepoint Server 2007/2010 nebo databáze MSSQL. Pro vývoj aplikace nejsou žádné speciální požadavky a další projekty.

75

6.5.6

Webová část

Webová část EosWebPart zajišťuje zobrazení webové aplikace napsané ve frameworku Eos na stránce. Webová část se stará jak o zobrazení, tak i o zajištění přechodu mezi jednotlivými stránkami aplikace, ověření práv a zobrazení chybových hlášek, které nejsou zachyceny samotnou aplikací. Framework .NET zajišťuje uchování nastavení webové části, tzn. název vybrané aplikace je automaticky uložen. Webová část implementuje vlastní způsob uchování dalších informací, které nejsou standardně .NET frameworkem uloženy. Mezi tyto informace patří především název usercontrol, který je zrovna zobrazen. To se děje za použití ViewState a HiddenField. Nastavení webové části je v prostředí .NET standardně ukládáno do databáze. V databázi je uloženo nastavení webové části pro každého přihlášeného uživatele, stránky a webové části. Framework Eos pro usnadnění vývoje (a odstranění potřeby databáze) implementoval uložení nastavení webových částí do XML souboru. Tedy při vývoji není nutná databáze MSSQL. Webová část se stará o inicializaci EosContext, což je třída, která nese informace, které jsou společné pro všechny instance aplikace, které ve webové části poběží. Jedná se především o výchozí nastavení providerů pro logování, audit, ověřování. Tyto jednotlivé providery mohou aplikace zdědit anebo vlastní konfigurací zajistit použití jiných providerů pro danou aplikaci. Webová část zajišťuje pro každou aplikaci inicializaci třídy ApplicationContext, která obsahuje informace, které jsou určené pouze pro konkrétní aplikaci. Taktéž obsahuje instance jednotlivých providerů, informace o samotné aplikaci, aktuální stránce, přihlášeném uživateli. Jednotlivé vlastnosti a metody jsou popsány v uživatelské dokumentaci. 6.5.7

Předek všech aplikačních stránek

Pro zajištění konzistence a pro umožnění poskytovat aplikacím jednotný přístup k frameworku, musí všechny stránky (usercontrols) aplikace dědit z abstraktní třídy BaseEosUserControl. Tato třída poskytuje přístup k ApplicationContext. Webová část při nahrávání konkrétní stránky aplikace provádí kontrolu, zda usercontrol dědí třídu BaseEosUserControl. Při návrhu architektury byla provedena diskuze ohledně způsobu přístupu k frameworku. Zde byly řešeny především dva typy přístupů: • •

Dědičnost – všechny stránky budou muset povinně dědit předem danou třídu. „Composition over inheritance“ – pro přístup k metodám a vlastnostem frameworku budou muset vývojáři vytvořit instanci třídy frameworku a zavolat metodu nebo vlastnost.

76

Přestože moderní postupy v softwarové architektuře se spíše přiklánějí k použití kompozice, tak ve frameworku Eos byla použita dědičnost. To zajišťuje především snadný přístup k metodám frameworku bez nutnosti znalosti detailní specifikace frameworku. A také pro správnou funkčnost bylo nutné zajistit zavolání některých metod už při inicializaci samotné stránky. Bez dědičnosti by si vývojář musel pamatovat, že musí pro správnou funkčnost zavolat několik metod frameworku (např. OnInit, OnLoad, OnRender, apod.). 6.5.8

Popis databáze

Databáze slouží k uchování informací o aplikacích, skupinách, usecase a právech na usecase. Tato databáze v sobě obsahuje všechny nezbytné informace pro běh aplikací a spolu s adresářovou službou Active Directory tvoří zdroj dat pro autentizaci a autorizaci uživatelů. Struktura databáze navržená v této kapitole vychází z návrhu použitého v softwarovém projektu Security Provider, protože jak softwarový projekt, tak diplomová práce vychází z prostředí Celní správy.

6.5.8.1

Tabulka ApplicationCategory

Kategorie aplikací, kam je možné logicky členit jednotlivé aplikace pro možnost potřebné granularity. Do kategorií jsou přiřazovány jednotlivé aplikace. Tyto kategorie jsou vytvořeny v AD a jsou nadřazenou organizační jednotkou pro aplikace (tabulka Application). • • • •

6.5.8.2

ID – Identifikátor tabulky. Title – Název kategorie související aplikace. Description – Upřesňující popisek kategorie aplikace. ADLocation – Umístění kategorie ve stromu v AD. Cesta je uložena včetně názvu uloženého v Title. V této cestě jsou umístěny jednotlivé aplikace.

Tabulka Application

Seznam aplikací, které využívají framework a tedy mohou být integrovány do MOSS. Na Application.ID jsou následně navázány usecase (tabulka Usecase) i skupiny (tabulka Group). • • • •

Id – Identifikátor tabulky. ApplicationName – Unikátní kód názvu aplikace, který se využívá při volání funkcí ve výkonném kódu klientských aplikací. DisplayName – Celý název aplikace. Description – Upřesňující popis aplikace. Není vyžadován.

77

• • •

•

6.5.8.3

ActiveDirectoryOUName – Název organizační jednotky aplikace v AD. ApplicationCategoryId – Cizí klíč odkazující na ApplicationCategory.ID. IsVisible – příznak pro aktivaci/deaktivaci aplikace. Pokud je příznak nastaven na False, aplikace se nezobrazuje v přehledu aplikací ve webové části pro vložení do stránky. DeployPath – relativní cesta k aplikaci v rámci webového serveru

Tabulka Usecase

Tabulka obsahuje přehled všech usecase aplikace. K těmto usecase se následně přiřazují skupiny. • • • • • • •

6.5.8.4

Id – identifikátor tabulky. ApplicationId – Cizí klíč odkazující na Application.ID. Přiřazuje usecase k aplikaci. UsecaseName – Jednoznačný název usecase v rámci aplikace. Description – Upřesňující popis usecase. Není vyžadováno. RelativePath – Relativní url cesta k usercontrol ve webovém adresáři, který má být zobrazen při přístupu k tomuto Usecase. IsSystemUsecase – Speciální příznak pro administrátory, který umožňuje označit usecase pro specifické použítí např. jako určený pro správu aplikace. IsDefaultUsecase – Identifikuje výchozí usecase v rámci aplikace. V rámci aplikace má nastavenu hodnotu true vždy právě jeden záznam.

Tabulka Group

Tabulka skupin uživatelů. Tyto skupiny odpovídají 1:1 skupinám v AD. K těmto skupinám se následně přiřazují Usecase. • • • • • •

Id – Identifikátor tabulky. ApplicationId – Cizí klíč odkazující na Applications.ID. Přiřazuje skupiny k aplikacím. GroupName – Jednoznačné jméno skupiny. Toto jméno odpovídá názvu skupiny v AD – z toho vychází požadavek na unikátnost přes všechny aplikace. Description – Upřesňující popis skupiny. Není vyžadován. IsSystemGroup – Speciální příznak pro administrátory, který umožňuje označit skupinu pro specifické použití např. jako určenou pro správce aplikace. IsVisible – Příznak určený pro vyšší vrstvy aplikace, zda je skupina aktivní či nikoliv. Umožňuje pro skupinu existující v AD nastavit, že nemá být platná pro přiřazování k usecase, ačkoliv existuje v AD.

78

6.5.8.5

Tabulka UsecaseGroups

Vztahová tabulka typu M:N, která definuje, které skupiny uživatelů mají přístup k jakým usecase. • • •

Id – identifikátor tabulky. UsecaseId – Cizí klíč odkazující na Usecase.ID. GroupId – Cizí klíč odkazující na Group.ID.

Obrázek 6.3: Databázový model

Samotná databáze je ve frameworku reprezentovaná XML souborem, jehož struktura odpovídá struktuře databáze.

6.5.8.6

Rozšiřitelnost

Podpora uložení dat v relačních databázích nebo jiných strukturách je možná implementací rozhraní IPortalSecurityDbProvider, které definuje metody pro přístup k datům databáze. Mapování implementace na rozhraní je řešeno pomocí dependency injection a tedy je možné v konfiguračním souboru změnit implementaci 79

tohoto rozhraní a tím zajistit podporu jiných úložišť dat. Framework standardně obsahuje implementaci pro uložení databáze v XML souboru.

6.6 Podpora Microsoft Sharepoint Server 2010 Ačkoliv primární zadání bylo vytvořit framework pro prostředí MOSS 2007, tak byl při vývoji brán ohled i na nejnovější verzi 2010. Aplikace napsané ve frameworku Eos lze nasadit i na prostředí Microsoft Sharepoint Server 2010 a Sharepoint Foundation 2010.

80

7 Uživatelská dokumentace Uživatelská dokumentace je určena vývojářům, kteří budou framework používat pro vývoj aplikací, které lze integrovat do systému MOSS. I přesto, že framework byl vytvořen pro Celní správu, je jeho použití možné v libovolném prostředí se systémem MOSS. Některé části frameworku jsou specificky navrženy pro účely Celní správy (jako např. ověřování práv), tedy pro nasazení mimo Celní správu by bylo zapotřebí některých změn. Počet nutných změn je značně omezen zvolenou architekturou, kdy je možné části frameworku nahradit vlastním řešením a to pouze změnou konfiguračního souboru.

7.1 Předpoklady • • • •

Microsoft Visual Studio 2008 / 2010 a vyšší Šablona projektu Eos webové aplikace do Visual Studia Balíček s knihovnami frameworku Eos Webový server IIS (není podmínkou)

7.2 Instalace šablony do Microsoft Visual Studio Instalace se provádí zkopírováním souboru EosWebVSTemplate.zip do adresáře: c:\Users\\Dokumenty\Visual Studio 2010\Templates\ProjectTemplates\Visual Web Developer

7.3 Vytvoření aplikace 1. 2. 3.

Knihovny frameworku Eos a Enterprise Library zkopírujte do libovolného adresáře na disku nebo do adresáře, kde bude umístěna nová aplikace. Spusťte Visual Studio a v menu vyberte File | New Project V záložce Visual C# vyberte projekt Eos Web Application

81

Obrázek 7.1: Vytvoření nového projektu pomocí šablony Eos Web Application

4.

Po kliknutí na OK se vytvoří jednoduchá Eos aplikace

Obrázek 7.2: Náhled na strukturu nově vytvořené aplikace

5. 6.

Aktualizujte reference na knihovny frameworku Eos a Enterprise Library. Knihovny najdete v adresáři z kroku č.1 Proveďte build projektu a zobrazte stránku Default.aspx ve webovém adresáři

82

Poznámka: Šablona vytvoří jednoduchou aplikaci, která ukazuje základní funkce frameworku Eos. Po vytvoření projektu jednotlivé stránky můžete editovat nebo zcela nahradit novými.

7.3.1 •

• • • •

Popis struktury projektu _masterPages – složka obsahuje soubory pro určení vzhledu master page. Neprovádějte změny v adresáři. Obsah adresáře nebude nasazován na produkční prostředí. portalSecurityDB.xml – obsahuje informace o aplikaci, usecase, skupinách a oprávnění. SPActiveDirectory.xml – obsahuje informace o uživateli a obsazení uživatele do skupiny Usecases – složka obsahuje všechny stránky aplikace Default.aspx – stránka, která se stará o zobrazení jednotlivých ascx stránek. Tato stránka nebude nasazena na produkční prostředí, tedy změny v ní provedené nebudou dostupné na produkčním prostředí.

Strukturu projektu je možné přizpůsobit vlastním zvyklostem a postupům. Při změně struktury je nutné dbát na následující pravidla: 1. 2.

Při změně umístění ascx souborů s jednotlivými stránkami, je nutné upravit soubor portalSecurityDB.xml, který obsahuje reference na jednotlivé stránky Při změně umístění portalSecurityDB.xml a SPActiveDirectory.xml je nutné upravit web.config a nastavit novou cestu k těmto souborům v klíči EmbeddedSecurity

7.4 Přidání stránky do aplikace Pro přidání nové stránky (usecase) do aplikace postupujte následovně: 1.

Do složky v projektu ve Visual Studiu přidejte nový Web User Control (nazvěte jej např. UC003List.ascx)

83

Obrázek 7.3 – Vytvoření nového usercontrol ve Visual Studiu

2. Přejděte na soubor UC003List.ascx.cs a nastavte, aby třída dědila z

3.

Eos.Controllers.BaseEosUserControl třídy. Upravte soubor PortalSecurityDB.xml, tak aby obsahoval údaj o nové stránce

<Usecase> 3 <UsecaseName>UC003List false <ApplicationId>1 Usecases/UC003List

Příklad předpokládá, že stránka byla vytvořena ve složce Usecases. 4.

Dále nastavte, která skupina bude mít oprávnění přistupovat k usecase

<UsecaseGroup> <UsecaseId>3 1

5.

Pro přechod na nově vytvořený usecase použijte na jiné stránce metodu

84

Navigate("UC003List");

7.5 Konfigurace Konfigurace projektu se provádí úpravou souboru web.config. V sekci configSections musí být definovány následující sekce:

<sectionGroup name="Eos"> <section name="General" type="Eos.Configuration.GeneralSection, Eos"/> <section name="Eos.Web" type="Eos.Configuration.EosWebSection, Eos"/> <section name="Eos.Components" type="Eos.Components.Configuration.EosComponentsSection, Eos.Components"/>

V případě umístění dll knihoven frameworku do GACu, je potřeba uvést plnou cestu včetně verze a klíče (např. Eos, Version=1.0.0.0, Culture=neutral, PublicKeyToken=…) A dále ve web.configu samotná sekce Eos s nastavením: <Eos> <ApplicationContextSettings> <Eos.Web> <jsFiles /> <EosAppSettings ShowErrorDetail="true" /> <Eos.Components> <EmbeddedSecurity>

85

• • • • •

•

7.5.1

applicationName – jednoznačný název aplikace. Musí se shodovat s hodnotou v souboru portalSecurityDB.xml a u nastavení webové části v souboru Default.aspx cssStyleSheets – obsahuje seznam souborů s css styly, které budou vloženy do stránek jsFiles – stejné jako cssStyleSheets, akorát se jedná o javascript soubory AnonymousImpersonation – pokud aplikace běží v anonymním režimu, potom pro ověření práv je použit učet definovaný v atributu ImpersonationUserName EosAppSettings – dodatečné nastavení o ShowErrorDetail – TRUE, pokud se má zobrazit detail chyby (vhodné pro testovací prostředí). FALSE – pokud se má zobrazit obecná hláška informující o chybě (vhodné pro produkční prostředí) EmbeddedSecurity – nastavení pro ověřování práv o PortalSecurityDBXml – relativní cesta k souboru, který obsahuje data o aplikaci, usecase a skupinách o ActiveDirectoryXml – relativní cesta k souboru, který obsahuje data o uživateli a obsazení uživatele ve skupinách

Konfigurace logování

Konfigurace se provádí úpravou sekce ve web.configu. Pro logování se používá komponenta z knihoven Enterprise Library. Detailní nastavení logování lze nalézt na stránkách projektu Enteprise Library18. Následující příklad je zkráceným nastavením a ukazuje jen ty nejzákladnější možnosti nastavení. <listeners> ...

• •

18

fileName – definuje cestu k souboru, kde se budou ukládat zprávy template - definuje informace, které se budou logovat. Uvedené symboly v závorkách jsou zástupné znaky, které jsou nahrazeny skutečnými hodnotami až při zápisu.

Logging Application Block - http://entlib.codeplex.com/

86

•

7.5.2

switchValue – definuje, které typy zpráv se mají ukládat. Možnosti nastavení jsou All, Debug, Info, Warning, Error.

Konfigurace cachování

Konfigurace se provádí úpravou sekce ve web.configu. Pro cachování se používá komponenta z knihoven Enterprise Library. Detailní popis nastavení cachování lze nalézt na stránkách projektu Enteprise Library19. ...

7.5.3

Konfigurace stránek a oprávnění

Framework používá pro přechod mezi stránkami a ověření přístupu 2 XML soubory: • •

PortalSecurityDB.xml – obsahuje data o aplikaci, seznam stránek (usecase), skupin a oprávnění skupin ke stránkám SPActiveDirectory.xml – obsahuje informace o uživateli a obsazení do uživ. skupin

Tyto 2 soubory nahrazují databázi PortalSecurity na MSSQL a Active Directory. Jedná se o zjednodušený model, který obsahuje pouze ty informace, které jsou nutné pro funkci frameworku. Soubory jsou navzájem propojené a to pomocí uživ. skupin, které se nachází v obou dvou souborech. Ověřování práv funguje tak, že každá stránka aplikace se nazývá usecase. Pro každý usecase je definován seznam uživatelských skupin v adresářové službě. Při přístupu na stránku (usecase) framework ověří, zda aktuálně přihlášený uživatel se nachází alespoň v jedné ze skupin, které jsou k danému usecase přiřazeny. Pokud ano, uživateli je zobrazena stránka. V opačném případě je uživateli zobrazena stránka s informací, že na danou stránku nemá dostatečná oprávnění.

19

Caching Application Block - http://entlib.codeplex.com/

87

7.5.4

PortalSecurityDB.xml

<Application> 1 <ApplicationName>SampleWebApp SampleWebApp <Usecase> 1 <UsecaseName>UC001Main true <ApplicationId>1 Usecases/UC001Main.ascx 1 <ApplicationId>1 SampleWebApp_Users <UsecaseGroup> <UsecaseId>1 1

Struktura souboru PortalSecurityDB.xml se dělí na 4 hlavní sekce: •

•

•

•

Application – informace o vyvíjené aplikaci o Id – jednoznačný identifikátor aplikace (v rámci souboru) o ApplicationName – jednoznačný název aplikace (v rámci souboru) o DisplayName – název aplikace pro zobrazení Usecase – informace o stránce (usercontrolu) o Id – jednoznačný identifikátor usecase v rámci souboru o UsecaseName – jednoznačný název usecase (v rámci aplikace) o IsDefaultUsecase – zda se jedná o výchozí usecase (usecase, který bude načten při startu aplikace). Hodnotu TRUE může mít pouze jeden usecase v aplikaci. o ApplicationId – reference na aplikaci, do které usecase patří o RelativePath – relativní cesta k usecase v rámci webového projektu (ve formátu <složka>/<složka>/…/<usercontrol.ascx> Group – informace o skupině o Id - jednoznačný identifikátor skupiny v rámci souboru o ApplicationId – reference na aplikaci, do které skupina patří o GroupName – jednoznačný název skupiny (v rámci souboru) UsecaseGroup – nastavení oprávnění mezi skupinou a usecase

88

o o

UsecaseId - reference na identifikátor usecase GroupId - reference na identifikátor skupiny

Soubor může obsahovat více aplikací, usecase a skupin. Pro vývoj bude většinou postačovat jeden záznam aplikace a více usecase a více skupin. 7.5.5

SPActiveDirectory.xml

<User> 1 eos\b999777 John Test <Email>[email protected] <Password>Heslo#1234 IT SPTest 4616 2412 1 SampleWebApp_Users <UserGroup> <UserId>1 1

Struktura souboru SPActiveDirectory.xml se dělí na 3 hlavní sekce: •

User – informace o uživateli o Id – jednoznačný identifikátor uživatele v rámci souboru o LoginName – přihlašovací jméno uživatele včetně domény o FullName – celé jméno uživatele o Email – emailová adresa uživatele o Password – heslo uživatele o Department – název oddělení o Company – název společnosti o Description – popis (obvykle obsahuje číslo útvaru, ve kterém je uživatel obsazen) o ADOffice – název kanceláře

•

Group – informace o skupině o Id – jednoznačný identifikátor uživatele v rámci souboru

89

o

•

GroupName – jednoznačný název skupiny v rámci souboru
Hodnota musí odpovídat názvu skupiny v PortalSecurityDB.xml

UserGroup – nastavení obsazení uživatele ve skupině o UserId – reference na identifikátor uživatele o GroupId – reference na identifikátor skupiny

7.6 Vložení css stylů a js skriptů Pro vložení reference na soubor s css styly nebo soubor s javascriptem, je nutné v souboru web.config upravit nastavení v sekci Eos.Web. Přidání reference se provádí vložení elementu do příslušné sekce. <Eos> <Eos.Web> <jsFiles>

Sekce cssStyleSheets obsahu seznam souborů s css styly, které se mají vložit do stránky. • •

CssStyleSheetFile – atribut s jednoznačným popisem vkládané reference RelativePath – relativní cesta k souboru

Sekce jsFiles obsahuje seznam souborů s js skripty, které se mají vložit do stránky. • •

JsFile – atribut s jednoznačným popisem vkládané reference RelativePath – relativní cesta k souboru

Všechny uvedené soubory se vkládají do head sekce ve stránce. Reference jsou automaticky vkládány na všechny stránky v aplikaci. Vložení na specifickou stránku (usecase) není v současné verzi podporováno.

7.7 Metody a vlastnosti poskytující framework Framework poskytuje metody aplikacím pomocí třídy BaseEosUserControl. Z této třídy musí být odvozeny všechny usecase (ascx usercontroly). Tedy k metodám a vlastnostem frameworku lze přistoupit ve všech usecase. 90

IWebApplicationContext AppContext { get; }

Vrací aktuální kontext aplikace. Pomocí této property lze přistupovat k dalším providerům. IEosApplication CurrentApplication { get; }

Vrací informace o aktuální aplikaci. Configuration CurrentConfiguration { get; }

Vrací referenci na konfigurace aktuálně spuštěné aplikace. string CurrentUsecase { get; }

Vrací název usecase, který je aktuálně načtený. IUserInfo CurrentUser { get; }

Vrací informace o přihlášeném uživateli. bool IsPostBack { get; }

Vrací informaci, zda aktuální HtmlRequest je PostBack nebo ne. IsPostBack se vztahuje k aplikaci a danému usecase. NameValueCollection ApplicationParameters { get; }

Vrací seznam parametrů, které jsou společné pro celou aplikaci. Definují se na úrovni webové části a jsou sdíleny všemi usecase. NameValueCollection Parameters { get; }

Vrací seznam parametrů, které byly předány při přechodu na usecase metodou Navigate. bool IsUsecaseAuthorize(string usecaseName)

Metoda pro ověření, zda aktuálně přihlášený uživatel má právo na daný usecase. void Navigate(string usecaseName, NameValueCollection parameterCollection)

Metoda pro přechod na jiný usecase s možností předání parametrů, které jsou následně uloženy do property Parameters. void Navigate(string usecaseName)

Metoda pro přechod na jiný usecase. 7.7.1

Logování

Pro logování lze využít přímo metody na usecase (potomci třídy BaseEosUserControl)

91

void void void void void

Log(Exception throwedException) LogDebug(string message, params object[] args) LogInfo(string message, params object[] args) LogWarning(string message, params object[] args) LogError(string message, params object[] args)

Nebo lze také přímo přistoupit k instanci rozhraní ILogProvider uvnitř AppContext: ILogProvider AppContext.LogProvider{ get; }

Rozhraní, které je nyní k dispozici pro logování, má následující definici:

7.7.2

Cache

Pro přístup k instanci pro použití cache, můžete využít vlastnost Cache na každém usecase (potomek třídy BaseEosUserControl). ICacheProvider Cache { get; }

Rozhraní, které je nyní k dispozici pro cachování, má následující definici:

Upozornění: Nepoužívejte standardní cache na objektu HttpContext.Current. 92

7.7.3

Audit

Pro získání instance rozhraní IAuditProvider použijte AppContext: IAuditProvider AppContext.AuditProvider{ get; }

Rozhraní, které je nyní k dispozici pro auditování, má následující definici:

Standardní implementace Auditu pro vývojové potřeby využívá logování se zápisem do kategorie Audit. Pokud je vyžadováno oddělení Logu a Auditu do samostatných souborů, je možné tak učinit změnou konfigurace Logování ve web.configu. Pro detailnější popis vyhledejte dokumentaci k Logging Application Block z Enterprise Library. 7.7.4

Security Provider

Pro získání instance rozhraní ISecurityProvider použijte AppContext: ISecurityProvider AppContext.SecurityProvider{ get; }

Rozhraní má následující definici:

93

7.7.5

Poznámky k vývoji aplikací

Pro správné spuštění aplikace a načtení usecase je nutné, aby ve stránce Default.aspx se u webové části hodnota atributu SelectedApplicationName rovnala hodnotě v souboru PortalSecurityDB.xml. Pro použití Session a Cache je pro správnou funkčnost i po nasazení na produkční prostředí nutné používat pouze objekty na třídě BaseEosUserControl (tedy na všech usecase). Standardní objekty na HttpContext.Current není dovolen a použití těchto objektů může způsobit neočekávané chování při nasazení na produkční prostředí. Nedoporučuje se používání objektu Application ze třídy UserControl / Page. Application slouží pro uchování parametrů. K tomuto účelu je doporučeno používat ostatní metody dočasné persistence (Session, Cache, ViewState). Je nutné se vyvarovat použití Page.IsPostBack. Tato property vrací hodnotu, která vychází z celé stránky, nikoliv aplikace. Pro zjištění, zda se jedná o postback v aplikaci, použijte property IsPostBack přímo na úrovni usecase (je definována v BaseEosUserControl). Pro vložení vlastních css stylů a js skriptů použijte nastavení uvnitř web.config. Jakékoliv jiné řešení není podporováno a nemusí být funkční po nasazení do produkčního prostředí. Pro logování použijte třídy, které dědí ILogProvider. Na produkčním prostředí může být logování nastaveno globálně, a proto vlastní řešení není podporováno. Pokud vám nevyhovuje standardní dodávaná implementace logování, máte možnost naimplementovat vlastní řešení, které implementuje ILogProvider a pomocí Unity jej vložit do frameworku a tím nahradit stávající řešení.

7.8 Rozšíření frameworku Pro nahrazení některých částí frameworku vlastní implementací je nutné vložit do kořene aplikace (do stejného umístění jako je web.config) soubor unity.config v následujícím formátu.

94

<section name="eos.unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection , Microsoft.Practices.Unity.Configuration" /> <eos.unity>

7.8.1

Nahrazení implementace vlastním řešením

Jako příklad nahrazení implementace vlastním řešením je zde uvedeno nahrazení standardního logování v Eos frameworku. Příklad

předpokládá,

že

vlastní

implementace Eos.Custom.LogProvider v knihovně Eos.CustomLogProvider implementuje rozhraní z knihovny Eos.Core.

95

je

umístěna Eos.Custom.

ve

třídě Třída

Eos.Core.ILogProvider

<eos.unity>

Komponenty, které je možné nahradit, uvádí následující tabulka. Vždy je nutné, na dané rozhraní nastavit mapování na třídu, která implementuje dané rozhraní. Všechny rozhraní jsou definována v knihovně Eos.Core.dll. Rozhraní Eos.Core.ILogProvider Eos.Core.ICacheProvider Eos.Core.ISecurityProvider Eos.Core.IEnvironmentProvider

Popis Definuje metody pro logování Definuje metody pro cachování Definuje metody pro ověření přístupu Základní metody specifické pro prostředí Celní správy

Tabulka 7.4: Přehled rozhraní v EOS frameworku

V sekci container je možné specifikovat i vlastní rozhraní a mapování na ně a tak využít princip Dependency Injection i ve vlastní aplikaci. Tato konfigurace je poté uložena v UnityContainer, který je přístupný přes ApplicationContext.

7.9 Dependency Injection20 Dependency Injection (DI) je specifickou technikou převráceného řízení. Převrácené řízení je návrhový vzor, při kterém si objekt nevytváří instance implementací používaných rozhraní sám uvnitř konstruktorů, ale jsou mu poskytovány „zvenčí“ při jeho vytvoření.

20

Text kapitoly Dependency Injection byl převzat z dokumentace softwarového projektu Security Provider na MFF UK. Autor diplomové práce byl součástí týmu, který na softwarovém projektu pracoval.

96

Dependency injection tuto techniku posouvá ještě dále tím, že přenáší zodpovědnost za napojení odpovídajících implementací na interface uvnitř objektů, které je využívají na poskytovatele závislostí, typicky ve formě kontejneru Typická situace tedy obnáší tři aktéry: konzumenta, poskytovatele a poskytovatele závislostí. Konzument je typicky program, knihovna nebo komponenta, která ke své správné funkci potřebuje služby dalších tříd a obsahuje tak odkazy na jejich interface. Konkrétní implementace těchto rozhraní se pak nazývají poskytovatelé a jsou konzumentovi poskytovány podle potřeby poskytovatelem závislostí. Konkrétních implementací dependency injection je mnoho a liší se jak stylem použití tak tím, co nabízejí. Pro implementaci frameworku byl zvolen Unity, který je součástí Microsoft Enterprise Library a umožňuje snadnou změnu vkládaných poskytovatelů i u již zkompilovaných programů pouhou změnou konfigurace. 7.9.1

Použití Unity

Unity poskytuje metody a funkce pro registraci typů a zadávání mapování mezi typy a umí tak tedy konzumentům poskytnout na vyžádání instanci zaregistrovaného typu. Unity nabízí více způsobů jak nadefinovat tyto závislosti, ať už v konfiguraci nebo za běhu programu. V rámci frameworku je využita možnost definice závislostí pomocí atributů tříd a vlastností s nakonfigurováním poskytovatelů externě v konfiguračním souboru. 7.9.2

Konfigurace Unity

Pro správnou funkčnost Unity je nejprve třeba v konfiguračním souboru nadefinovat, jaké typy se mají za jaké rozhraní dosazovat. Prvním krokem je nutnost založení nové sekce a její korektní nadefinování v . V konfiguračním souboru aplikace se poté vytvoří část , která obsahuje veškeré nastavení Unity.

97

<section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection , Microsoft.Practices.Unity.Configuration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

7.9.3

Aliasy typů v Unity

V první sekci konfigurace je třeba nadefinovat aliasy pro používané typy, které se potom dají použít k referencování použitých typů místo plně kvalifikovaných jmen tříd. Ve výše uvedeném příkladu je definováno rozhraní ICache a jeho implementace CustomCache. V atributu type je definovaná plná cesta k rozhrání nebo třídě, která implementuje rozhrání. Cesta je ve formátu: [Jmenný prostor].[Název třídy], [Název knihovny], Version=[číslo verze knihovny], Culture=[jazyková verze knihovny], PublicKeyToken=[podpis knihovny]

7.9.4

Definice napojení v Unity

Druhá sekce konfigurace obsahuje jeden nebo více kontejnerů, z nichž každý představuje pojmenovanou instanci UnityContaineru, tedy správce propojení. V každém kontejneru je pak nadefinováno propojení interfaců s konkrétními typy.

98



Výše uvedený příklad říká, že v případě požadavku na objekt typu ICache se má vrátit nová instance implementace CustomCache. Změnou konfigurace lze i u zkompilovaného programu změnit napojení rozhraní a konkrétních implementací, pouze je třeba, aby implementace již byly součástí zkompilovaného programu. 7.9.5

Integrace do zdrojového kódu

Unity nenačítá konfiguraci automaticky, k jejímu načtení je potřeba inicializovat UnityContainer a předat mu název kontejneru, pro který má konfiguraci načíst. Je tak možné mít v jednom souboru více konfigurací a sdílet ji mezi několika UnityContainery. IUnityContainer myContainer = new UnityContainer(); UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity"); section.Containers["appContainer"].Configure(myContainer);

Po načtení konfigurace je UnityContainer připraven k použití a umí poskytnout implementace nadefinovaných interfaců různými způsoby, například přímým dotazem na UnityContainer, vložením do property konzumenta nebo předáním jako parametru volané funkce konzumenta a jejím vykonáním. V následujících podkapitolách v implementaci frameworku. 7.9.6

budou

probrány

způsoby,

které

jsou

využívány

Přímý požadavek na objekt

Prvním způsobem, jak získat implementaci interfacu je přímý dotaz na poskytovatele propojení, tedy UnityContainer objekt. Stačí specifikovat typ interface a UnityContainer vrátí instanci objektu podle napojení nadefinovaného v konfiguračním souboru.

99

ICacheProvider provider = myContainer.Resolve();

7.9.7

Napojení pomocí konstruktoru

Metoda napojení pomocí konstruktoru se od přímých požadavků na objekt liší tím, že na rozdíl od předchozího případu, kdy se musí o vytvoření a napojení objektů stále postarat programátor, při napojení pomocí konstruktoru stačí požádat UnityContainer o instanci výsledného objektu a ten při tvorbě nové instance objektu automaticky do konstruktoru doplní za interface instance podle mapování definovaného v konfiguraci. public class DataProvider : IDataProvider { private ICacheProvider _cacheProvider; public DataProvider(ICacheProvider cache) { _cacheProvider = cache; } ... }

Pokud je UnityContainer požádán o objekt typu DataProvider (nebo IDataProvider a v konfiguraci je DataProvider namapován na interface IDataProvider), pak při vytvoření automaticky do konstruktoru doplní instanci objektu CustomCache. var _dataProvider = myContainer.Resolve();

7.9.8

Napojení pomocí Dependency atributů

Metoda napojení pomocí atributů je podobná metodě napojení pomocí konstruktorů v tom, že je napojení vytvářeno automaticky UnityContainerem při požadavku na nový objekt. K rozpoznání vlastnosti, na kterou se má napojit implementace nějakého interface stačí označit tuto vlastnost označit atributem [Dependency]. UnityContainer pak vždy, když je požádán o instanci daného objektu automaticky všechny vlastnosti označené tímto atributem napojí na odpovídající implementace podle konfigurace.

100

public class DataProvider : IDataProvider { [Dependency] public ILogProvider Log { get; set;} ... }

Napojení pomocí InjectionMethod

7.9.9

Metoda napojení pomocí InjectionMethod opět vytváří napojení automaticky UnityContainerem při požadavku na nový objekt. Při vytváření nové instance objektu je každá metoda označená atributem [InjectionMethod] spuštěna a jako parametry jsou jí poskytnuty implementace požadovaných rozhraní. public class DataProvider : IDataProvider { private ICacheProvider _cacheProvider; [InjectionMethod] public void InitProviders(ICacheProvider cache) { _cacheProvider = cache; } ... }

101

8 Administrátorská dokumentace Administrátorská dokumentace je určena správcům webu, kteří budou provádět nasazování aplikací, které se mají integrovat do MOSS. Dokumentace popisuje způsob instalace webové části pro zobrazení aplikace na stránce a samotné nasazení aplikace na server s prostředím MOSS 2007. Stejný postup lze zvolit i v prostředí WSS 3.0.

8.1 Instalace webové části Instalace webové části se provádí nasazením balíčku wsp, který je určen pro nasazení vlastních řešení do systému MOSS. Pro tyto účely se používá nástroj stsadm, který se nachází na serveru se systémem MOSS na následující cestě: C:\Program Files\Common Extension\12\bin

Files\Microsoft

Shared\Web

Server

Balíček wsp obsahuje Feature EosWebPart, která definuje webovou část. 1. Na serveru MOSS s administračním webem nasaďte balíček do systému pomocí příkazu Stsadm –o addsolution –filename Stsadm –o deploysolution –filename –immediate – allowGacDeployment –url –allowCasPolicies –force Stsadm –o execadmsvcjobs

Po nasazení balíčku dojde k nasazení Feature EosWebPart. 2. Aktivujte Feature EosWebPart následujícím příkazem Stsadm –o activatefeature –name EosWebPart –url

8.2 Konfigurace Podle přiloženého web.config souboru, upravte hlavní web.config webu. Do adresáře hlavního webu (c:\inetpub\wss\VirtualDirectories\80\App_Data) vložte datové soubory PortalSecurityDB.xml a SPActiveDirectory.xml. Soubory upravte tak, aby odpovídaly prostředí. Vyplňte informace o aplikacích, usecase a skupinách.

103

8.3 Nasazení aplikace na webové servery Tato kapitola popisuje způsob nasazení externí aplikace, která má být integrována do prostředí MOSS. Tento postup je nutné provést na každém webovém serveru farmy. 1. Zkopírujte všechny aplikační soubory do adresáře (např. c:\EosApps\SampleWebApp). 2. V IIS (Internet Information Services) vytvořte ve website MOSS novou aplikaci a nastavte cestu k aplikaci na disku (cesta z kroku č. 1).

Obrázek 8.1: Vytvoření aplikace v IIS

3. Aplikační dll knihovny vložte do GAC. 4. Upravte soubory PortalSecurityDB.xml a SPActiveDirectory.xml, tak aby obsahovaly informace o dané aplikaci a jejích usecase. Nastavte oprávnění pro uživatele. V PortalSecurityDB.xml nastavte u aplikace element VirtualDirectory na cestu k virtuálnímu adresáři, který jste vytvořili v kroku č. 2.

8.4 Přidání aplikace do stránky 1. Přejděte na webové stránky a v libovolném podwebu zvolte Vytvořit stránku 2. Zvolte šablonu, která umožňuje vložit webovou část do stránky (např. Celá stránka, svisle).

104

3. Klikněte do webové zóny a vyhledejte webovou část EosWebPart.

Obrázek 8.2: Výběr webové části

4. Ve webové části klikněte na Upravit | Upravit sdílenou webovou část.

Obrázek 8.3: Vytvoření aplikace v IIS

5. V editačním režimu webové části vyberte ze seznamu aplikaci, kterou chcete na stránce zobrazit.

Obrázek 8.4: Výběr aplikace v editačním režimu webové části

105

6. Klikněte na OK a stránku uložte. Nyní se vám na stránce zobrazí aplikace.

Obrázek 8.5: Náhled na výslednou webovou část s aplikací

Seznam aplikací, který se zobrazí v editorském režimu webové částí je načten ze souboru PortalSecurityDB.xml, který se nachází v hlavním kořenovém adresáři webu (c:\inetpub\wss\VirtualDirectories\80).

106

9 Závěr Diplomovou práci jsem rozdělil na dvě hlavní části: teoretickou a praktickou. V teoretické části jsem se snažil popsat použití a využití redakčních systémů obecně a také v prostředí státní správy. Tuto část jsem podpořil srovnáním použití v různém prostředí a toto srovnání nabízí pohled na způsob správy internetových stránek ve veřejném sektoru. Domnívám se, že část poskytující pohled na způsob správy internetových stránek v orgánech státní správy přináší zajímavý pohled na současnou praxi, a jakým konkrétním způsobem jsou redakční systémy používány. Velká část teoretické části byla věnována analýze migrace webových stránek z jednoho redakčního systému na druhý, kde jsem navrhl postup migrace. Popsal jsem zde také konkrétní kroky, které bylo nutné provést a jaké změny to konkrétně přineslo v organizaci. Výsledek migrace jsem shrnul a upozornil na části, které je možné zlepšit. Praktická část se věnovala návrhu a implementaci softwarového řešení, které umožňuje vytvářet samostatné webové aplikace, které se jednoduchým a přímým způsobem dají vložit do redakčního systému MOSS 2007/2010, a tak rozšířit možnosti systému o libovolnou funkčnost, kterou lze naprogramovat. Toto řešení umožňuje vytvářet webové aplikace bez nutnosti znalosti cílového prostředí, čímž značně urychluje vývoj a neklade odborné požadavky na vývojáře. Při návrhu a implementaci jsem se snažil vycházet ze standardně používaných postupů, tak aby byla možná další rozšiřitelnost. Diplomová práce nepokryla zcela všechny oblasti, kterými se zabývala. Jelikož záběr diplomové práce byl mířen na využití redakčních systémů, nebylo možné provést srovnání všech nebo nejpoužívanějších redakčních systému, jak ve státní, tak privátní sféře. Nepodařilo se získat informace ze všech orgánů celní správy. Tato část vyžadovala spolupráci zodpovědných pracovníků a nepodařilo se vždy zajistit kontakt a schůzku. Softwarová část byla již v zadání specifikována jako prototyp, proto některé části nebyly implementovány. Zde stojí za zmínku zejména podpora Silverlight aplikací a snadnější podpora AJAX technologie. Nicméně architektura navržená v diplomové práci umožňuje další rozšiřitelnost a tedy i budoucí podporu těchto technologií. Domnívám se, že diplomová práce splnila zadání a její obsah může být vhodným nástrojem při plánování migrace nebo při vývoji aplikací pro technologie Microsoft Office Sharepoint.

9.1 Využití výsledků diplomové práce Některé části diplomové práce byly využity v prostředí Celní správy. Jedná se zejména o část věnované migraci dat a frameworku. Analýza migrace sloužila jako výchozí bod pro naplánování jednotlivých částí migrace a rozdělení úloh odpovědným osobám.

107

Prototyp frameworku byl využit jako základ frameworku, který je použit na Celní správě pro rozšiřování redakčního systému Sharepoint o další webové aplikace. Zaslání diplomové práce bylo přislíbeno zástupcům jednotlivých ministerstev, a tak je možné použití výsledků práce i v ostatních orgánech státní správy.

108

10 Literatura [1] Connell Andrew: The Evolution of Web Content Management in the 2007 Version of Microsoft Office (2006) [online]. Dostupné z WWW: https://msevents.microsoft. [2] Devit: Informace o produktu Microsoft Office Sharepoint Server 2007 [online]. Dostupné z WWW: http://www.devit.cz/sharepoint/microsoft-office-sharepointserver-moss-2007/tabid/59/Default.aspx [3] Devit: Informace o produktu Windows Sharepoint Services 3.0 [online]. Dostupné z WWW: http://www.devit.cz/sharepoint/windows-sharepoint-services-30-wss30/tabid/58/Default.aspx [4] Cwalina Krzysztof, Adbrams Brad: Framework Design Guidelines Second Edition (2008) [5] Stewart Ken: The Disadvantages of Microsoft SharePoint 2007 as a Document Management System [online]. Dostupné z WWW: http://changeforge.com/2008/09/01/the-disadvantages-of-microsoft-sharepoint2007-as-a-document-management-system/ [6] Microsoft SharePoint Alternative: Why do you need a Microsoft SharePoint Alternative [online]. Dostupné z WWW: http://www.sharepointalternative.com [7] English Bill, Londer Olga, Bleeker Todd, Shell Shawn: Microsoft Content Management Server 2002 - A Complete Guide (2003). [8] Webb Jeff: Essential SharePoint 2007 - A Practical Guide for Users, Administrators and Developers (2007). [9] Husman Göran: Beginning SharePoint 2007 Administration - Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 (2007) [10] Neimke Darren: ASP.Net 2.0 Web Parts in Action - Building Dynamic Web Portals (2006) [11] Havelka Jan: Modernizace webových stránek s využitím CMS (2009). Bakalářská práce, Masarykova univerzita v Brně, Fakulta Informatiky. [12] Artic Studio: Redakční systém [online]. Dostupné z WWW: http://www.articstudio.net/webove-stranky/redakcni-system/ [13] Wikipedie: Systém pro správu obsahu [online]. Dostupné z WWW: http://cs.wikipedia.org/wiki/Systém_pro_správu_obsahu [14] Wikipedie: Content management system [online]. Dostupné z WWW: http://en.wikipedia.org/wiki/Content_management_system 109

[15] Vít Svatopluk: Rádce pro výběr vhodného redakčního systému (2009) [online]. Dostupné z WWW: http://svatas.blog.root.cz/2009/01/12/radce-pro-vybervhodneho-redakcniho-systemu/ [16] Recenzi.cz: Redakční systém CMS - publikační systémy pro správu obsahu [online]. Dostupné z WWW: http://recenzi.cz/redakcni-system-cms [17] Unicorn, Celní správa: Technická dokumentace Migrace portálu Celní správy (2005). [18] Baroš, Bureš, Foltýn, Ružinský: Programátorská dokumentace, Softwarový projekt MFF UK (2010) str. 22 – 26 [19] Hobbs David: Five Suggestions for a Successful CMS Migration (2009) [online]. Dostupné z WWW: http://www.welchmanpierpoint.com/blog/five-suggestionssuccessful-cms-migration [20] Kitlowski Sarah: ROT Content - A Problem and a Symptom (2009) [online]. Dostupné z WWW: http://www.welchmanpierpoint.com/blog/rot-content-problem-andsymptom [21] Microsoft: Planning MCMS 2002 Application Migration to SharePoint Server 2007 [online]. Dostupné z WWW: http://msdn.microsoft.com/en-us/library/aa480225.aspx [22] Mcms2Moss: Why Migrate from MCMS 2002 to SharePoint Server 2007 [online]. Dostupné z WWW: http://mcms2moss.com/ [23] CmsMatrix: Compare Content Management Systems [online]. Dostupné z WWW: http://www.cmsmatrix.org/ [24] Wikipedia: Wysiwyg [online]. Dostupné z WWW: http://cs.wikipedia.org/wiki/WYSIWYG [25] Devit: Portálová řešení [online]. Dostupné z WWW: http://www.devit.cz/sluzby/portalova-reseni/tabid/158/Default.aspx [26] Microsoft: Dokumentace k Microsoft Office SharePoint Server 2007 [online]. Dostupné z WWW: http://msdn.microsoft.com/en-us/library/bb931736(office.12).aspx [27] Komur Sezai: Migrating a Microsoft Content Management Server Website to Microsoft Office Sharepoint Server 2007 [online]: Dostupné z WWW: http://www.vividgroup.com.au/pdf/MCMS2002ToMOSS2007MigrationWhitePaper.pdf¨ [28] Microsoft: Planning and architecture for Office SharePoint Server 2007 [online]. Dostupné z WWW: http://go.microsoft.com/fwlink/?LinkID=85548

110