České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Portálové řešení pro ERP software Helios Bc. Jan Sklenář
Vedoucí práce: Ing. Marek Fiala
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika Květen 2009
ii
Poděkování Úvodem chci poděkovat všem, kteří mě v mé činnosti podporovali – především rodině a přítelkyni. Za odborné rady a připomínky patří díky vedoucímu práce, Ing. Markovi Fialovi.
iii
iv
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 20. 5. 2009 ……………………………………………………………….
v
vi
Abstract This project describes design and implementation of web access to ERP system Helios using Windows SharePoint Services. The web access solution facilitates display and modification of data acquired from the ERP system and also simple configuration because of implementation based on modular configurable elements, Web Parts. Efficiency ensured by data caching and application security are the main factors of the solution. Except analysis, design and description of implementation the report also includes basic description of used technologies, web interface performance tests and comparison of the web interface with original client.
Abstrakt Tato práce popisuje návrh a implementaci webového přístupu k ERP systému Helios s využitím Windows SharePoint Services 3.0. Webový přístup umožňuje zobrazování a úpravu dat získaných z ERP systému a snadnou konfiguraci díky implementaci pomocí modulárních konfigurovatelných elementů, takzvaných webových částí. Důraz je kladen na výkonnost zajištěnou efektivním cachováním dat a také na bezpečnost aplikace. Zpráva vedle analýzy, návrhu a popisu implementace obsahuje základní popis použitých technologií, výkonnostní testy webového rozhraní a porovnání webového rozhraní s klasickým klientem. vii
viii
Obsah 1
ÚVOD ................................................................................................................................................... 1
2
POPIS PROBLÉMU, SPECIFIKACE CÍLE..................................................................................... 2 2.1 2.2
3
EXITUJÍCÍ IMPLEMENTACE .............................................................................................................................2 POZNÁMKY K TERMINOLOGII V TEXTU ........................................................................................................2 POUŽITÉ TECHNOLOGIE ............................................................................................................... 3
3.1 OPERAČNÍ SYSTÉM ..........................................................................................................................................3 3.1.1 Microsoft Windows Server 2008 ....................................................................................................... 3 3.2 APLIKAČNÍ VRSTVA .........................................................................................................................................3 3.2.1 Microsoft Internet Information Services 7.0 (IIS 7.0) ............................................................. 3 3.2.2 Microsoft .NET Framework 3.5 ......................................................................................................... 3 3.2.3 ASP.NET 3.5 ................................................................................................................................................ 4 3.2.4 Microsoft Windows SharePoint Services 3.0 ............................................................................... 4 3.2.5 ERP systém Helios Green ...................................................................................................................... 5 3.3 DATABÁZE........................................................................................................................................................5 3.3.1 Microsoft SQL Server 2005 .................................................................................................................. 5 3.4 VÝVOJOVÉ NÁSTROJE ......................................................................................................................................6 3.4.1 Microsoft Visual Studio 2008 Professional .................................................................................. 6 3.4.2 MSDN Library ............................................................................................................................................ 6 3.4.3 Microsoft SharePoint Designer 2007 .............................................................................................. 6 3.4.4 Red Gate’s .NET Reflector..................................................................................................................... 6 3.4.5 Sandcastle ................................................................................................................................................... 7 3.4.6 Nástroje pro vývojáře webového prohlížeče Microsoft Internet Explorer 8 ................ 7 3.5 ZDŮVODNĚNÍ VOLBY TECHNOLOGIÍ .............................................................................................................7 4
ANALÝZA A NÁVRH ŘEŠENÍ ......................................................................................................... 8 4.1 HELIOS GREEN ................................................................................................................................................8 4.1.1 Architektura systému Helios Green ................................................................................................. 8 4.1.2 Datový model Helios Green ............................................................................................................... 10 4.1.3 Funkcionalita Heliosu .......................................................................................................................... 11 4.2 SERVICEGATE A SERVICEGATEADAPTER ................................................................................................ 13 4.2.1 XML zprávy ServiceGate ..................................................................................................................... 14 4.2.2 Základní třídy ServiceGateAdapteru ............................................................................................ 15 4.3 POŽADAVKY NA WEBOVÝ PŘÍSTUP ............................................................................................................ 16 4.3.1 Funkční požadavky ............................................................................................................................... 16 4.3.1.1
Shrnutí funkčních požadavků ............................................................................................................... 18
4.3.2 Nefunkční požadavky........................................................................................................................... 19 4.4 WINDOWS SHAREPOINT SERVICES .......................................................................................................... 20 4.4.1 Architektura Windows SharePoint Services .............................................................................21 4.4.2 Webové stránky ve Windows SharePoint Services .................................................................23 4.4.2.1 4.4.2.2 4.4.2.3
Uložení webových stránek ..................................................................................................................... 23 Site Pages ....................................................................................................................................................... 24 Application Pages ....................................................................................................................................... 24
ix
4.4.2.4
4.4.3
Web Part Pages ........................................................................................................................................... 24
Webové ovládací prvky SharePointu ............................................................................................ 25
4.4.3.1
Webové části ................................................................................................................................................ 25
4.4.4 Zabezpečení a uživatelé v SharePointu ....................................................................................... 26 4.5 NÁVRH UŽIVATELSKÉHO ROZHRANÍ ......................................................................................................... 27 4.5.1 Zobrazení přehledu ............................................................................................................................... 27 4.5.2 Formulářové zobrazení položky .....................................................................................................28 4.5.3 Úprava položky .......................................................................................................................................29 4.5.4 Vytvoření uživatelského rozhraní pomocí webových částí ................................................ 30 4.5.4.1 4.5.4.2 4.5.4.3 4.5.4.4
Webová část WebPartHeliosGrid ........................................................................................................ 31 Webová část WebPartHeliosItem ....................................................................................................... 32 Propojení webových částí ...................................................................................................................... 33 Režimy zobrazení webové části WebPartHeliosItem ................................................................ 35
4.6 NÁVRH DATOVÉ VRSTVY A PŘÍSTUPU K DATŮM...................................................................................... 37 4.6.1 Přístup k ServiceGate ........................................................................................................................... 37 4.6.2 Komunikace se ServiceGate pomocí XML zpráv ......................................................................38 4.6.3 Cachování dat ..........................................................................................................................................39 4.6.3.1
Synchronizace souběžných požadavků ............................................................................................ 41
4.7 BEZPEČNOST APLIKACE .............................................................................................................................. 44 4.7.1 Bezpečnost v rámci SharePoint serveru...................................................................................... 44 4.7.2 Bezpečnost připojení k ServiceGate .............................................................................................. 44 4.7.3 Bezpečnost dat uložených v seznamech SharePointu .......................................................... 45 4.7.4 Bezpečnost z pohledu vlastních webových částí .....................................................................46 5
REALIZACE ..................................................................................................................................... 47 5.1 STRUKTURA APLIKACE ................................................................................................................................ 47 5.2 IMPLEMENTACE DATOVÉ VRSTVY A PŘÍSTUPU K DATŮM ...................................................................... 48 5.2.1 Přístup k seznamu SGConnections .................................................................................................48 5.2.2 Správa připojení k ServiceGate .......................................................................................................49 5.2.3 Asynchronní zpracování dat .............................................................................................................50 5.2.3.1 5.2.3.2 5.2.3.3
5.2.4
ASP.NET model zpracovávání požadavků ...................................................................................... 50 Implementace asynchronních operací ve webovém přístupu ............................................... 51 Důsledky použití asynchronního zpracování ................................................................................ 52
Synchronizace přístupu vláken ke sdíleným datům .............................................................. 52
5.2.4.1 5.2.4.2 5.2.4.3 5.2.4.4
Synchronizace přístupu ke kolekcím ................................................................................................ 52 Synchronizace přístupu ke cachovaným datům .......................................................................... 53 Synchronizace přístupu k připojení k ServiceGate ..................................................................... 54 Implementace synchronizace v .NET Frameworku .................................................................... 54
5.2.5 LINQ ............................................................................................................................................................. 55 5.2.6 Výkonnost .................................................................................................................................................. 56 5.2.7 Neimplementovaná funkcionalita .................................................................................................57 5.3 TVORBA UŽIVATELSKÉHO ROZHRANÍ ....................................................................................................... 58 5.3.1 Webové části ............................................................................................................................................58 5.3.1.1
5.3.2 5.3.3 x
EditorParts webových částí ................................................................................................................... 60
Stránky webových částí ...................................................................................................................... 60 Prvek SPGridView ..................................................................................................................................61
5.3.4 Nástrojová lišta ......................................................................................................................................62 5.3.5 Klientské skripty .....................................................................................................................................63 5.3.6 Application Page pro zobrazení obrázku ................................................................................... 64 5.4 LOKALIZACE .................................................................................................................................................. 65 5.5 DOKUMENTACE ............................................................................................................................................ 66 6
TESTOVÁNÍ .................................................................................................................................... 67 6.1 TESTOVÁNÍ IMPLEMENTACE ...................................................................................................................... 67 6.2 VÝKONNOSTNÍ TESTOVÁNÍ ......................................................................................................................... 68 6.2.1 Síťové schéma testování ..................................................................................................................... 68 6.2.2 Průběh testování ....................................................................................................................................69 6.2.3 Výsledky testování .................................................................................................................................70
7
POROVNÁNÍ WEBOVÉHO PŘÍSTUPU S KLASICKÝM KLIENTEM .................................. 72 7.1 VÝBĚR DAT PRO ZOBRAZENÍ ...................................................................................................................... 72 7.2 OPERACE S DATY .......................................................................................................................................... 72 7.2.1 Vynechané funkce a zjednodušené funkce ................................................................................. 72 7.3 PŘEDNOSTI WEBOVÉHO PŘÍSTUPU ........................................................................................................... 74 7.4 NEVÝHODY WEBOVÉHO PŘÍSTUPU ............................................................................................................ 74
8
ZÁVĚR .............................................................................................................................................. 75
9
BIBLIOGRAFIE ............................................................................................................................... 76
A.
INSTALAČNÍ PŘÍRUČKA ............................................................................................................. 77 A.1 INSTALACE WINDOWS SHAREPOINT SERVICES 3.0 .............................................................................. 77 A.1.1 Instalační balíčky ...................................................................................................................................77 A.1.2 Průběh instalace.....................................................................................................................................77 A.1.3 Dokončení instalace.............................................................................................................................. 78 A.1.4 Povolení anonymního přístupu .......................................................................................................79 A.2 INSTALACE WEBOVÝCH ČÁSTÍ .................................................................................................................... 80 A.3 PŘIDÁNÍ WEBOVÝCH ČÁSTÍ NA STRÁNKU................................................................................................. 80
B.
PŘÍRUČKA VÝVOJE WEBOVÝCH ČÁSTÍ VE VISUAL STUDIU 2008 ............................... 81 B.1 DEPLOYMENT WEBOVÉ ČÁSTI.................................................................................................................... 81 B.2 DEBUGGING WEBOVÉ ČÁSTI ....................................................................................................................... 81 B.2.1 Nastavení web.configu ........................................................................................................................ 81 B.2.2 Nastavení webového serveru............................................................................................................82 B.2.3 Nastavení ve Visual Studiu ................................................................................................................ 82
C.
OBSAH PŘILOŽENÉHO CD ......................................................................................................... 83
xi
xii
Seznam obrázků OBRÁZEK 1: PŘÍKLAD ÚVODNÍ STRÁNKY WIKIWEBU PORTÁLU WSS ...........................................................................5 OBRÁZEK 2: ARCHITEKTURA HELIOS GREEN ....................................................................................................................8 OBRÁZEK 3: WINFORMS KLIENT .........................................................................................................................................9 OBRÁZEK 4: ZJEDNODUŠENÉ DATABÁZOVÉ SCHÉMA HELIOSU.................................................................................... 10 OBRÁZEK 5: ULOŽENÍ DOKLADOVÉ TŘÍDY ...................................................................................................................... 11 OBRÁZEK 6: SERVICEGATEMESSAGE A ODVOZENÉ TŘÍDY ........................................................................................... 15 OBRÁZEK 7: USE CASE DIAGRAM ..................................................................................................................................... 17 OBRÁZEK 8: ARCHITEKTURA WINDOWS SHAREPOINT SERVICES .............................................................................. 21 OBRÁZEK 9: WSS VIRTUAL PATH PROVIDER .................................................................................................................. 23 OBRÁZEK 10: WEBOVÁ ČÁST MSPAGEVIEWER ............................................................................................................ 26 OBRÁZEK 11: ZOBRAZENÍ POLOŽEK SEZNAMU ÚKOLY ................................................................................................. 28 OBRÁZEK 12: FORMULÁŘOVÉ ZOBRAZENÍ POLOŽKY SEZNAMU ÚKOLY ..................................................................... 28 OBRÁZEK 13: ÚPRAVA POLOŽKY SEZNAMU ÚKOLY ....................................................................................................... 29 OBRÁZEK 14: WEBOVÁ ČÁST WEBPARTHELIOSGRID.................................................................................................. 31 OBRÁZEK 15: WEBOVÁ ČÁST WEBPARTHELIOSGRID V REŽIMU ÚPRAV................................................................... 32 OBRÁZEK 16: WEBOVÁ ČÁST WEBPARTHELIOSITEM ................................................................................................. 33 OBRÁZEK 17: STAVOVÝ DIAGRAM WEBPARTHELIOSITEM ......................................................................................... 35 OBRÁZEK 18: HIERARCHIE TŘÍD REPREZENTUJÍCÍCH STAVY WEBPARTHELIOSITEM ............................................ 36 OBRÁZEK 19: DIAGRAM TŘÍD PŘIPOJENÍ K SERVICEGATE ........................................................................................... 38 OBRÁZEK 20: PROCES ZÍSKÁNÍ DAT ................................................................................................................................. 39 OBRÁZEK 21: TŘÍDA RETRIEVEHELPER A AGREGOVANÉ TŘÍDY ................................................................................. 40 OBRÁZEK 22: TŘÍDA BROWSEHELPER A AGREGOVANÉ TŘÍDY ................................................................................... 41 OBRÁZEK 23: SCÉNÁŘ SYNCHRONIZACE SOUBĚŽNÝCH POŽADAVKŮ .......................................................................... 42 OBRÁZEK 24: HIERARCHIE CACHOVACÍCH TŘÍD ............................................................................................................ 43 OBRÁZEK 25: KOMPONENTY APLIKACE .......................................................................................................................... 47 OBRÁZEK 26: VLÁKNA V ASP.NET ................................................................................................................................. 50 OBRÁZEK 27: ŽIVOTNÍ CYKLUS STRÁNKY V ASP.NET ................................................................................................. 51 OBRÁZEK 28: SÍŤOVÉ SCHÉMA TESTU ............................................................................................................................. 68 OBRÁZEK 29: GRAF ZÁTĚŽOVÉHO TESTU BEZ POUŽITÍ CACHE .................................................................................... 70 OBRÁZEK 30: GRAF ZÁTĚŽOVÉHO TEST S POUŽITÍM CACHE ........................................................................................ 71 OBRÁZEK 31: TÝMOVÝ WEB .............................................................................................................................................. 78 OBRÁZEK 32: CENTRÁLNÍ SPRÁVA SERVERU SHAREPOINT 3.0 .................................................................................. 79
xiii
xiv
Seznam tabulek TABULKA 1: XML ZPRÁVY SERVICEGATE ....................................................................................................................... 14 TABULKA 2: POPIS URL STRÁNKY S WEBPARTHELIOSITEM ČÁSTÍ ........................................................................... 34 TABULKA 3: SLOUPCE SEZNAMU SGCONNECTIONS ....................................................................................................... 37 TABULKA 4: TŘÍDY ZABEZPEČUJÍCÍ KOMUNIKACI SE SERVICEGATE POMOCÍ XML ZPRÁV ..................................... 38 TABULKA 5: ZÁKLADNÍ METODY WEBOVÝCH ČÁSTÍ ...................................................................................................... 58 TABULKA 6: EDITORPARTS WEBOVÝCH ČÁSTÍ ............................................................................................................... 60 TABULKA 7: KONFIGURACE TESTOVACÍHO POČÍTAČE A WEBOVÉHO SERVERU ......................................................... 69
xv
xvi
Seznam příkladů PŘÍKLAD 1: VYTVOŘENÍ SEZNAMU SGCONNECTIONS ................................................................................................... 48 PŘÍKLAD 2: ZÍSKÁNÍ AKTUÁLNÍHO MANAŽERU PŘIPOJENÍ ........................................................................................... 53 PŘÍKLAD 3: INICIALIZACE CACHOVANÝCH DAT............................................................................................................... 54 PŘÍKLAD 4: POUŽITÍ LINQ ................................................................................................................................................ 55 PŘÍKLAD 5: VLASTNOST WEBOVÉ ČÁSTI .......................................................................................................................... 59 PŘÍKLAD 6: VYTVOŘENÍ NÁSTROJOVÉ LIŠTY S TLAČÍTKEM .......................................................................................... 62 PŘÍKLAD 7: REGISTRACE SOUBORU SKRIPTŮ .................................................................................................................. 63 PŘÍKLAD 8: STRÁNKA PRO ZOBRAZENÍ OBRÁZKU .......................................................................................................... 64 PŘÍKLAD 9: XML DOKUMENTACE KÓDU .......................................................................................................................... 66
xvii
1
Úvod Podnikové informační systémy typu ERP (Enterprise Resource Planning) se v dnešní
době stávají klíčovou součástí převážně velkých a středních firem. Na rozdíl od čistě ekonomických systémů řídí pokud možno všechny procesy ve firmě od agendy zaměstnanců přes správu výroby a skladu až po velmi specializované procesy konkrétních firem. Často jsou totiž šity přímo na míru konkrétní firmy či odvětví. Vedle těchto systémů, které většinou představují samostatnou aplikaci, se u firem často setkáváme s webovými intranetovými a internetovými portály sloužícími pro prezentaci a sdílení dat a často také pro komunikaci mezi uživateli. Výhoda těchto webových portálů spočívá především v dostupnosti odkudkoli přes webový prohlížeč. Tato práce se zabývá právě propojením ERP systému Helios Green a Microsoft Windows SharePoint Services portálu s akceptováním rozdílných požadavků na ERP systém a webový portál.
1
2
Popis problému, specifikace cíle Základním předpokladem pro vytvoření webového přístupu k ERP systému Helios Green
je prostudování tohoto systému, analýza jeho funkcionality a datového modelu. Dále bude potřeba seznámit se s knihovnou, která umožňuje napojit externí systém k systému Helios. Na základě získaných znalostí o funkční stránce systému proběhne analýza a návrh, jaké funkce bude obsahovat webové rozhraní. Je potřeba si uvědomit, že není možné a hlavně žádoucí implementovat zcela shodné rozhraní v prostředí webu, protože jsou zde jiné požadavky a také způsoby použití. Ostatně firma LCS International, a.s., která Helios vyvíjí, takové prostředí vlastní; jedná se o imitaci klasického rozhraní v prostředí webu, ovšem toto řešení je velmi pomalé, neohrabané, je zde problém s kompatibilitou mezi prohlížeči a hlavně nepřináší žádnou výhodu nad klasickým rozhraním. Poté je potřeba seznámit se s Windows SharePoint Services portálem (WSS) a způsobem, jakým k němu přistupovat v roli vývojáře za účelem implementace webového přístupu. Použití WSS byl požadavek zadavatele, dále bude zdůvodněna motivace tohoto rozhodnutí. Při návrhu a implementaci vlastního webového rozhraní budou klíčové výkonnostní požadavky na webové rozhraní. Na rozdíl od klasického rozhraní zde může docházet k výrazně vyšší špičkové zátěži, zatímco klasické rozhraní vždy běží maximálně na určitém předem známém počtu klientů. Zároveň by webové rozhraní mělo být dostatečně obecné pro zobrazení libovolných dat ze systému Helios
2.1 Exitující implementace Jak již bylo zmíněno, existuje řešení webového přístupu, které napodobuje vzhled a funkcionalita klasického klienta, ovšem v prostředí webu. To je cesta, která je nežádoucí. Kromě této implementace pro Helios jiná implementace není známa.
2.2 Poznámky k terminologii v textu Pro většinu pojmů existuje nejen anglický název, ale i jeho český ekvivalent. Při absenci českého ekvivalentu je převzat anglický termín a v případě potřeby skloňován. V opačném případě jsou nejprve uvedeny oba termíny a dále používán český ekvivalent, případně zkratka vycházející z anglického názvu.
2
3
Použité technologie
3.1 Operační systém 3.1.1
Microsoft Windows Server 2008
Jedná se o nejnovější (začátek roku 2009) verzi serverového operačního systému firmy Microsoft. Volba této platformy vychází ze zvolení Microsoft Windows SharePoint Services jakožto platformy pro tvorbu webového portálu.
3.2 Aplikační vrstva Aplikační vrstva se týká zvolených webových technologií pro tvorbu webového přístupu a samotného ERP systému Helios. 3.2.1
Microsoft Internet Information Services 7.0 (IIS 7.0)
Jedná se o webový server dodávaný jako součást Windows Serveru. Ve starších verzích byl označen jako Internet Information Server. 3.2.2
Microsoft .NET Framework 3.5
Microsoft .NET Framework 3.5 (dále jen .NET Framework) je platforma pro běh aplikací na operačních systémech od firmy Microsoft. Podobně jako Java je založena na virtuálním stroji, který kompiluje bytekód za běhu aplikace do nativního kódu daného fyzické stroje. Bytekód se nazývá .NET Microsoft Intermediate Language (MSIL) a běhové prostředí virtuálního stroje, ve kterém aplikace běží a které se stará například o automatickou správu paměti a Just In Time (JIT) kompilaci je The Common Language Runtime (CLR). .NET Framework obsahuje rozsáhlou knihovnu tříd Base Class Library (BCL), která usnadňuje tvorbu rozličného spektra aplikací od klasických desktop aplikací, webových aplikací přes aplikace pro mobilní zařízení až po aplikace pro herní konzole. Třídy jsou logicky uspořádány do tzv. namespaces (jmenných prostorů). .NET Framework 3.5 je postaven na stejném CLR jako verze 2.0, liší se pouze v překladači a nových třídách v knihovně tříd. .NET Framework podporuje velké množství jazyků, v této práci je použit jazyk C#. Existuje i open source implementace .NET Frameworku, Mono. Její výhodou je především širší podpora softwarových platforem, tedy i Linux, Unix, OS X.
3
3.2.3
ASP.NET 3.5
ASP.NET je součástí .NET Frameworku a umožňuje vytvářet webové aplikace na straně serveru. Instaluje se jako rozšíření IIS. Používá model, který se snaží vývoj webových aplikací sblížit s vývojem desktop aplikací, existují zde ovládací prvky, které vyvolávají události, které jsou dále zpracovávány. Zároveň je možno velmi striktně oddělit aplikační kód od samotného XHTML (Extensible Hypertext Markup Language) definující zobrazení dat. Na straně klienta – webového prohlížeče se pak generuje XHTML a JavaScript kód, není tedy potřeba podpora .NET Frameworku ani jiné proprietární technologie v prohlížeči. Kromě
zmíněných
funkcí
ASP.NET
umožňuje
přístup
k databázím,
tvorbu
distribuovaných aplikací na bázi webových služeb, poskytuje zabezpečení webových aplikací a autorizaci uživatelů, webovou Cache pro ukládání dat do paměti serveru a Session, ukládání dat pro jednotlivé uživatele. 3.2.4
Microsoft Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services 3.0 je nástroj pro tvorbu webových portálů umožňující sdílení informací a spolupráci na dokumentech. Mnoho funkcí je provázáno přímo s Microsoft Office. WSS je postaven na technologii ASP.NET. Vedle WSS, který je součástí Windows Serveru, existuje ještě Microsoft Office Sharepoint Server 2007 postavený na WSS a přidávající další funkcionalitu, ovšem je potřeba ho dokoupit a jeho cena značně převyšuje cenu samotného Windows Serveru. Dále v textu bude používán převážně obecnější výraz SharePoint místo WSS, protože vše, co platí pro WSS, platí i pro Sharepoint Server 2007. SharePoint může být použit i pro tvorbu webů, není potřeba sdílet dokumenty. Přímo v prostředí portálu lze vytvářet jednoduché stránky a stránky, do kterých lze vkládat takzvané webové části, což jsou programovatelné modulární webové elementy, které mohou obsahovat téměř libovolnou funkcionalitu a mohou být konfigurovatelné z prostředí webu. Dále je možné naprogramovat vlastní stránky s aplikační logikou a pomocí WSS Software Development Kit (SDK) umožňujícího přístup k objektům SharePointu lze např. provádět úpravy stránek, používat datový model SharePointu portálu nebo využít přeprogramované funkcionality zabezpečení a správy dokumentů. Jádrem datového modelu SharePointu jsou takzvané seznamy, které jsou obdobou relačních dat, ovšem je možno s nimi provádět mnoho operací.
4
Obrázek 1: Příklad úvodní stránky Wikiwebu portálu WSS
Obrázek 1: Příklad úvodní stránky Wikiwebu portálu WSS zobrazuje úvodní stránku Wikiwebu. Je zde použita šablona Wikiweb. Šablona obecně generuje množinu stránek. Existuje několik předdefinovaných šablon, další je možno vytvořit, stáhnout již hotové nebo koupit. Weby v SharePointu jsou také skinovatelné pomocí motivů. Zde je použit výchozí motiv. 3.2.5
ERP systém Helios Green
Helios Green je ERP systém pro velké firmy vyvíjený firmou LCS International, a.s. [1]. Vedle Helios Green existují ještě varianty Helios Orange pro střední a menší firmy a Helios Red pro podnikatele a menší firmy. To jsou ovšem jiné produkty s jinými vývojovými týmy. Dokumentaci Helios Green je možno nalézt na [2].
3.3 Databáze 3.3.1
Microsoft SQL Server 2005
Databázový server Microsoft SQL Server 2005 slouží jako datové úložiště pro SharePoint. Databázový server je buď možné nainstalovat nezávisle a pak pomocí 5
konfiguračního průvodce WSS vytvořit potřebné databáze a tabulky, nebo se při instalaci nainstaluje a zinicializuje tzv. Windows Internal Database, což je speciální verze Microsoft SQL Server 2005. Nevýhoda Windows Internal Database spočívá v tom, že ji není možné použít k uložení vlastních databází pro jiné aplikace a také má omezené možnosti škálování. K databázovému serveru se v rámci SharePointu ale nikdy nepřistupuje přímo a není to žádoucí. Postup instalace WSS popisuje Příloha A.1. ERP systém Helios také používá databázový server Microsoft SQL Server, podporovány jsou verze 2000, zmíněná 2005 a v současné době se přechází na verzi 2008.
3.4 Vývojové nástroje 3.4.1
Microsoft Visual Studio 2008 Professional
Microsoft Visual Studio 2008 umožňuje vývoj v mnoha jazycích nad platformou .NET ať již se jedná o webové, desktop či mobilní aplikace. Mimoto podporuje jazyk C++. Pro programování pro WSS je potřeba doinstalovat Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2, se kterými se současně nainstaluje WSS 3.0 SDK. Pro usnadnění dokumentování prvků v kódu lze doporučit zdarma dostupný doplněk pro Visual Studio GhostDoc. 3.4.2
MSDN Library
MSDN Library je dokumentační knihovna produktů Microsoftu primárně určená pro vývojáře. Vedle online verze [3] je součástí instalace Visual Studia jako místní program. 3.4.3
Microsoft SharePoint Designer 2007
Umožňuje upravovat, vytvářet a mazat jednotlivé webové stránky, webové části a seznamy SharePointu bez nutnosti programování. 3.4.4
Red Gate’s .NET Reflector
Jedná se disassembler a analyzátor MSIL kódu. Využívá tzv. reflexe v .NET Frameworku. Je to zcela nenahraditelný produkt, pokud je potřeba nahlédnout, jak nějaký kód funguje uvnitř. Je nepřímo podporován samotným Microsoftem, takže se nejedná o žádný nástroj na pomezí legality a ilegality.
6
3.4.5
Sandcastle
Program Sandcastle umožňuje ze speciálního XML (Extensible Markup Language) souboru obsahující dokumentaci projektu a samotného zkompilovaného souboru vygenerovat nápovědu ve stylu MSDN knihovny. XML soubor s dokumentací vytvoří Visual Studio při překladu z komentářů ve zdrojovém kódu. Navíc byl použit nástroj Sandcastle Help File Builder, který ke zmíněnému Sandcastlu poskytuje grafické uživatelské rozhraní (GUI). 3.4.6
Nástroje pro vývojáře webového prohlížeče Microsoft Internet Explorer 8
Nový Microsoft Internet Explorer 8 obsahuje velmi užitečné Nástroje pro vývojáře. Je možný detailní průchod a runtime editace (editace za běhu) DOM (Document Object Model) modelu webové stránky, nástroj dále obsahuje JavaScript debugger a profiler.
3.5 Zdůvodnění volby technologií Výběr technologií vychází z volby SharePointu jako základu, na kterém je postaveno webové rozhraní. To platí pro operační systém, vývojové prostředí, použitý programovací jazyk. Požadavek použití SharePointu vychází ze zadání. Firma LCS International, a.s. je Microsoft Gold Certified Partner a všechny své produkty staví na produktech firmy Microsoft. Pro firmu je výhodnější implementace na jedné stabilní platformě, kde je většina technologií provázána a tyto technologie mají také velmi podobnou filozofii. SharePoint je potom zcela logickou volbou pro webové rozhraní, protože klienti používající Helios používají Windows Servery a často budují své intranety právě na SharePointu. Pokud ne, mohou WSS instalovat zcela zdarma. SharePoint má tedy zcela jistě přidanou hodnotu oproti čistým ASP.NET aplikacím a není důvod portálové řešení nepostavit právě na SharePointu.
7
4
Analýza a návrh řešení
4.1 Helios Green Celá implementace webového přístupu závisí na systému, ke kterému zprostředkovává přístup, pro začnu jeho popisem. 4.1.1
Architektura systému Helios Green
Helios Green využívá třívrstvé architektury, jak ilustruje Obrázek 2: Architektura Helios Green. Na levé straně obrázku je klientská část. Na pravé straně je serverová část skládající se ze dvou částí, databázového serveru a samotného aplikačního serveru Helios Green postaveného na platformě .NET Framework. Jeden aplikační server může umožňovat
HTTP
Klient
Webové služby
Aplikační server Helios
přístup k více databázím, které takto definují více aplikací.
Databáze MS-SQL 2005 L SQ > TA DA <
.NET Framework
Obrázek 2: Architektura Helios Green
Klient je obecně tenký klient komunikující pomocí webových služeb s aplikačním serverem, může jich být více (běžně řádově desítky). Existují dvě základní rozhraní webových služeb: 1) Interaktivní webová služba Jedná se o nejpoužívanější rozhraní a používá ho WinForms klient. WinForms je název technologie .NET Frameworku pro tvorbu uživatelského rozhraní, klient je tedy implementován v .NET Frameworku stejně jako aplikační server. Zajímavostí je fakt, že vizuální prostředí se v abstraktní formě vytváří na aplikačním serveru a na
8
klientu se pouze renderuje. Toto rozhraní ovšem není veřejně zdokumentované a je zamýšlené pouze k použití WinForms klientem. Ukázku WinForms klienta zobrazuje Obrázek 3: WinForms klient. Nahoře jsou ikony menu, v levé části navigační strom, který umožňuje otevřít okna v pravé části. Obvykle se nejprve otevřou přehledová (tabulková) data a po výběru položky se tato položka zobrazí jako formulář. WinForms klient je důležitý pro funkční analýzu a dále bude zmiňován jako klasický klient.
Obrázek 3: WinForms klient
2) Dávková webová služba – ServiceGate ServiceGate je komunikační rozhraní vytvořené speciálně za účelem připojení k Heliosu z externích systémů. Je použito v této práci a jeho popis bude následovat. Rozhraní je zdokumentované.
9
4.1.2
Datový model Helios Green
Místo celkového datového modelu Heliosu zde uvádím pro ilustraci pouze menší část databázového schématu převzatého z [2], s jehož pomocí lze popsat datový model na úrovni aplikační vrstvy, protože ten je na databázi závislý.
Obrázek 4: Zjednodušené databázové schéma Heliosu
V databázi jsou uloženy dva typy informací: 1) Data 2) Metadata Data neboli také provozní informace jsou samotná uložená data. Na schématu jsou zobrazeny vlevo. Metadata jsou informace o provozních informacích, které definují, jak jsou data uložena, kteří uživatelé je smějí prohlížet a měnit záznamy, jaké mají atributy, vztahy, jaké jsou nad nimi definovány funkce atd. Na schématu jsou zobrazeny vpravo. Základní komponentu na aplikační úrovni tvoří třída, která představuje úložiště dat určitého typu. V databázi jsou třídy uloženy v nis_tridy, na obrázku zcela vpravo. Každá třída má definované datové sloupce neboli atributy (nis_columns), pro které je definován datový typ, název a další vlastnosti. Instancí třídy je záznam. Záznam je typicky uložen ve více tabulkách databáze. Vedle atributů třídy jsou definovány vztahy, které umožňují navázání záznamu jedné třídy k záznamu jiné třídy. V ilustračním obrázku napravo je vidět propojení tabulek organizace a zeme. Rozlišují se vztahy zleva a zprava. Pojmenujme vztah z hlediska databáze v zemi jsou organizace, pak se jedná o vztah s aritou 1:N a zeme v tomto vztahu stojí vlevo. Tedy pro zem jsou navázané organizace tzv. vztah zprava a pro organizaci je země tzv. vztah 10
zleva. Vztahy se dále dělí na statické a dynamické. Statický vztah je de-facto atributem a musí být vždy typu zleva. Dynamické vztahy se implementují přes propojovací tabulku a mohou mít aritu M:N. V uvedeném příkladu se jedná o statický vztah. Pro každou třídu je definován jen nebo více tzv. pořadačů, tabulka poradace na obrázku nahoře v pravé části. Každý záznam patří právě do jednoho pořadače. Příkladem různých pořadačů jedné třídy mohou být faktury došlé domácí a faktury došlé zahraniční. Poslední nepopsanou tabulkou je tabulka subjekty. Tato tabulka spojuje tzv. subjektové třídy. Každá subjektová třída má atributy jako název, datum vzniku atd., což bylo také hlavní motivací spojení záznamů do jedné tabulky. Navíc každý záznam ze subjektové třídy má jednoznačný identifikátor cislo_subjektu v celé databázi. Vedle subjektových tříd existují ještě nonsubjektové třídy, které nevyužívají tabulku subjekty. Dále existuje ještě speciální typ subjektových tříd a to subjektové třídy s položkami, také označované jako dokladové třídy. Dokladová třída je rozdělena na dvě části: hlavičku a položky třídy. K jednomu záznamu pak připadá pole položek, což ilustruje Obrázek 5: Uložení dokladové třídy.
Obrázek 5: Uložení dokladové třídy
Závěrem je vhodné upozornit, že pro práci v klientském programu není potřeba rozlišovat mezi daty a metadaty, to je záležitost databáze, od které aplikační vrstva odstiňuje. V aplikační vrstvě je základ třída, pořadač a záznam. Existují zde pořadače Organizace, Země, atd., ale i pořadače Třídy, Vztahy, atd., které umožňují přístup k metadatům. 4.1.3
Funkcionalita Heliosu
Analýza funkcionality vychází z funkcionality poskytované klasickým klientem, která zahrnuje kompletní množinu uživatelských funkcí. Níže jsou uvedeny základní funkce klasického klienta podle umístění v programu. Jedná se o funkce týkající se hlavní stránky programu, funkce zobrazení tabulkových dat resp. zobrazení přehledu, tedy záznamů 11
v pořadači nebo navázaných záznamů přes nějaký vztah a konečně o funkce spojené s formulářovým zobrazením jednoho záznamu. Hlavní stránka programu: Výběr pořadače o Z navigačního stromu
Vše, oblíbené položky, nedávné položky
o Pomocí rychlého výběru
Zobrazí tabulku pořadačů, jejich čísel a tříd, kterou lze procházet, filtrovat a následně vybrat pořadač.
Správa otevřených oken o Výběr, uspořádání, minimalizace, zavření Nápověda Odhlášení Zobrazení přehledu: Funkce stránkování – nezobrazují se všechny záznamy, informace o celkovém počtu záznamů Filtrování záznamů Řazení záznamů podle sloupce Zobrazení konkrétního záznamu Vytvoření nového záznamu Mazání záznamů Výběr či vytvoření filtru, šablony, pohledu Spuštění funkce nad vybranými záznamy Tisk přehledu Formulářové zobrazení záznamu: Editace atributů – datových položek Editace vztahů o Přidávání, odebírání Správa kategorií Spuštění funkce nad záznamem Tisk
12
V analýze funkcionality se objevily některé nové pojmy. Funkce jsou operace nejrůznějšího charakteru. Mohou být implementovány uloženou procedurou
nebo
přímo
v aplikačním
serveru.
Mohou
být
parametrické
nebo
bezparametrické a mohou vracet výsledek. Může se tedy jednat o velmi jednoduché funkce jako např. zvýšení ceny produktu o 10% až po velmi komplexní operace. Mohou být spuštěny nad různým počtem záznamů a mohou být spouštěny nad položkami záznamů dokladových tříd. Filtr umožňuje zobrazit jen určité řádky v přehledu. Šablona naopak v přehledu zobrazuje jen určité sloupce a nastavuje, jak jsou zobrazeny, tedy například jejich šířku a popisek. Pohled je definice šablony a filtru zároveň. Třída může mít definovány různé kategorie podle různých kritérií a záznam pak spadá právě do jedné kategorie podle kritéria. Příkladem je Organizace podle obratu.
4.2 ServiceGate a ServiceGateAdapter ServiceGate je již zmíněná webová služba umožňující přístup k aplikačnímu serveru Heliosu. ServiceGateAdapter je DLL (Dynamic Link Library tedy dynamicky připojená knihovna) implementovaná na .NET Framework platformě, která zprostředkovává přístup k ServiceGate webové službě. Webová služba představuje komunikaci pomocí výměny zpráv v jazyku XML (Extensible Markup Language). Definované zprávy jsou zdokumentovány v [2]. ServiceGateAdapter pak zapouzdřuje logiku nad těmito zprávami, aniž by bylo nutné zpracovávat samotné XML zprávy.
13
4.2.1
XML zprávy ServiceGate
Tabulka 1: XML zprávy ServiceGate popisuje definované zprávy. Každá zpráva se skládá z požadavku a odpovědi na požadavek. Požadavek
Odpověď
Popis
BROWSE
BROWSERESULT
Slouží k získání tabulky záznamů (přehledu) pro určitý pořadač.
NEW
NEWRESULT
Vrátí nový záznam s předvyplněnými hodnotami.
INSERTUPDATE
INSERTUPDATERESULT
Vloží či aktualizuje záznam a vrátí výsledek uložení.
RETRIEVE
RETRIEVERESULT
Vrátí celé záznamy ve formě RECORD elementu načtené z databáze.
DELETE
DELETERESULT
Smaže záznam a vrátí výsledek smazání.
RUN
RUNRESULT
Spustí funkci na záznamy a vrátí výsledek spuštění.
MERGE
MERGERESULT
Slouží ke slučování záznamů.
QUERYSELECTRESULT
Umožňuje provést SELECT SQL dotaz nebo spustit uloženou proceduru na databázovém serveru.
QUERYSELECT
Tabulka 1: XML zprávy ServiceGate
Za povšimnutí stojí zmíněný RECORD element u zprávy RETRIEVE. Tento element obsahuje definici záznamu včetně atributů, záznamů navázaných přes vztahy, kategorií záznamu a u záznamů z dokladových tříd také položky definované v elementu SLAVES, zde označované jako podřízené záznamy. V požadavku je možné vyloučit zahrnutí některých informací do odpovědi, takže je možné v požadavku např. nevracet všechny navázané záznamy, kterých může být velmi mnoho. Rozdíl mezi zprávou RETRIEVE a BROWSE je ve vrácených datech, která se transformují odlišným způsobem. RETRIEVE tedy odpovídá formulářovému zobrazení dat a BROWSE přehledu záznamů v klasickém klientu. Rozdíl je ovšem v tom, že RETRIEVE vrací pouze data a nikoli způsob, jak je zobrazit, tedy slovní popis atributu, jeho datový typ atd. Zpráva QUERYSELECT se od ostatních zpráv odlišuje tím, že umožňuje přístup až přímo k databázi, zatímco ostatní zprávy komunikují na aplikační úrovni.
14
4.2.2
Základní třídy ServiceGateAdapteru
Základní
třídou
zprostředkovávající
komunikaci
je
třída
ServiceGateConnector
poskytující funkce připojení k ServiceGate. Komunikaci je doporučeno provádět přes rozhraní ICommunicationConnector, které zmíněná třída implementuje. Připojení k serveru obsahuje jako parametry adresu serveru, uživatelské jméno, heslo, databázi na serveru a jazyk. Volba jazyka ovlivňuje názvy pořadačů, tříd, atributů, tedy obecně metadat; samozřejmě pouze v případě, že jsou jazyky v databázi definované, standardně je výchozím jazykem čeština. Dalšími důležitými třídami jsou třídy reprezentující XML zprávy: ServiceGateMessage
ServiceGateRequest
BrowseRequest
RetrieveRequest
ServiceGateResponse
...
BrowseResponse
RetrieveResponse
...
Obrázek 6: ServiceGateMessage a odvozené třídy
Základem je ServiceGateMessage, od které jsou odvozeny zprávy požadavků a odpovědí. Z těchto tříd jsou odvozeny konkrétní typy tříd požadavků a odpovědí. Obrázek 6: ServiceGateMessage a odvozené třídy není sice zcela korektní UML (Unified Modelling Language) diagram, ale nebylo možné umístit do něj všechny třídy. Tři tečky v obrázku vyjadřují místo, kde jsou další třídy reprezentující další zprávy, které byly popsány v kapitole 4.2.1. Jejich jména vždy začínají názvem zprávy a mají příponu request a response Jedinou výjimku tvoří třídy ResetRequest a ResetResponse implementující XML zprávu NEW.
15
4.3 Požadavky na webový přístup Rozlišujeme požadavky funkční, tedy požadavky na zahrnutou funkcionalitu a požadavky nefunkční, což jsou ostatní požadavky netýkající se přímo funkcí, ale například výkonu aplikace. 4.3.1
Funkční požadavky
Funkční požadavky vycházejí z analýzy funkcionality klienta Heliosu a principů práce ve webovém
rozhraní.
Také
je
potřeba
zohlednit
funkcionalitu
pokrytou
ServiceGateAdapterem. Některé funkce jako např. Správa otevřených oken nejsou ve webovém rozhraní relevantní. Jiné funkce byly vypuštěny jako málo podstatné, např. Tiskové funkce a funkce týkající se kategorií záznamů. Filtrování přehledových dat a řazení je relativně náročnou úlohou, tudíž tyto funkce byly z důvodu výkonnostních požadavků také vypuštěny. Webové rozhraní má sloužit k poněkud odlišným účelům než klasický klient, není záměrem, aby uživatel mohl provádět přesně to, co může dělat v klasickém klientu, naopak se předpokládá, že správce webu určí, která data může uživatel na které stránce zobrazovat a případně upravovat. Uživatel pak již jen využívá vytvořených stránek. Webové rozhraní tedy poskytuje přístup pouze k omezenému množství dat a to přesně k těm datům, která jsou potřeba a u kterých lze předpokládat, že webový přístup k nim je důležitý. Například operace týkající se účetnictví se budou s největší pravděpodobností vždy provádět v klasickém klientovi. Zároveň se klade důraz hlavně na zobrazení dat, jejich úpravy jsou až sekundární činnost a lze předpokládat pouze jednoduché úpravy, na složitější a specifické operace je určený klasický klient. Naopak webové rozhraní má být co nejobecnější.
16
Případy užití ilustruje Obrázek 7: Use Case Diagram:
Webový portál Výběr zobrazených dat
Správa stránek «include»
«include»
«include»
Nastavení způsobu zobrazení
Nastavení zobrazených dat «include» Správce
Nastavení povolených operací Správa uživatelů
«include»
Výběr funkcí
Přidávání záznamů
Zobrazení dat «extend»
«extend» Úpravy záznamů
Úpravy dat «extend»
Mazání záznamů
Uživatel
Spouštění funkcí
Obrázek 7: Use Case Diagram
17
4.3.1.1 Shrnutí funkčních požadavků Příklady užití podrobně shrnuje následující výčet: Správce: Správa stránek na webovém portálu – týká se obecně všech stránek o Nastavení zobrazených dat – týká se stránek zobrazujících data z Heliosu
Snadné nastavení, co se bude na stránce zobrazovat – tedy výběr dat Číslo pořadače, výběr šablony nebo pohledu, případně výběr záznamu Nastavení parametrů přístupu k serveru o Možnost uložit nastavené parametry pro použití na dalších stránkách
Nastavení způsobu zobrazení Zobrazení přehledu - nastavení počtu záznamů na stránku
Nastavení povolených operací se záznamem Zobrazení záznamu ve formulářovém zobrazení Přidávání nových záznamů Úpravy záznamů Mazání záznamů Definice funkcí, které je možno nad záznamy spouštět
Správa uživatelů o Nastavení oprávnění pro jednotlivé stránky Uživatel: Přístup ke stránkám o Zobrazování dat
Data přehledů (pořadače, případně šablony nebo pohledy)
Formulářová data jednotlivých záznamů Atributy Navázané záznamy – vztahy o Statické vztahy o Dynamické vztahy U záznamů dokladových tříd jejich položky
o Úpravy dat 18
Přidávání nových záznamů
Úpravy záznamů
Mazání záznamů
o Spouštění funkcí nad záznamy Uživatel samozřejmě může teoreticky přistupovat k různým stránkám. Z hlediska řešení webového portálu nás primárně zajímají stránky zobrazující data z Heliosu a stránky umožňující úpravy dat. Funkční požadavky je třeba porovnat s funkcionalitou pokrytou ServiceGateAdapterem, který podporuje získávání přehledů i formulářových dat a také úpravy dat. Drobným problémem je fakt, že formulářová data jsou získávána jako holá data bez popisků atributů a názvů vztahů, tyto údaje bude potřeba zjistit zvlášť z pořadačů poskytujícím přístup k metadatům systému. Úpravy, přidávání a odebírání záznamů navázaných přes dynamické vztahy je příkladem relativně složité funkcionality a je třeba si uvědomit, že klíčovou vlastností webového portálu. 4.3.2
Nefunkční požadavky Výkonnost Bezpečnost Důraz na snadné a intuitivní ovládání o Správu musí být možné provádět bez programování Lokalizace – podpora více jazyků
Základním nefunkčním požadavkem je výkonnost aplikace. Důvodem je fakt, že samotný aplikační server není v současné době dostatečně škálovatelný, neexistuje možnost distribuce na více strojů. Současně je schopen obsloužit řádově desítky až stovky klientů. Ve webovém prostředí lze očekávat výrazně vyšší špičkové zatížení. Protože úzkým hrdlem je samotný Helios resp. databázový server, kde složitější dotazy potřebné pro zobrazení některých pohledů mohou trvat jednotky sekund, je potřeba omezit tahání všech dat přímo s Heliosu a vyvinout efektivní způsob uchování (cachování) dat na webovém portálu. Druhým požadavkem je bezpečnost, což je obecně velmi kritický požadavek libovolné webové aplikace. Důvodem je dostupnost takové aplikace širšímu okruhu lidí a tím pádem vystavení většímu bezpečnostnímu riziku a také bezestavový charakter samotné webové aplikace, díky kterému je například možno podvržením webové adresy získat citlivá data patřící jinému uživateli. Tomu se dá samozřejmě zabránit optimálním bezpečnostním
19
návrhem, který bývá zpravidla úzce svázaných s mechanismy bezpečnosti poskytovanými použitou technologií. Snadné a intuitivní ovládání (označované termínem usability) je důležitou součástí tvorby každé vizuální aplikace. Zde je navíc kladen požadavek na uživatelské rozhraní správce takovým způsobem, aby úpravy stránek mohl jednoduše a rychle provádět i člověk bez znalostí programování či webových technologií na jiné než uživatelské úrovni. Posledním zmíněným požadavkem je lokalizace aplikace tedy podpora více jazyků a možnost přidávat podporu dalších jazyků. Mezi základní jazyky patří čeština a angličtina, které jsou také podporované v Heliosu.
4.4 Windows SharePoint Services Windows SharePoint Services je platforma, jejíž pochopení i při znalostech ASP.NET vyžaduje určité úsilí. Pokusím se zde zjednodušeně vysvětlit architekturu a základní pojmy systému. Pro přehled o technologiích .NET Framework a zejména ASP.NET, na kterých je SharePoint postaven, doporučuji volně přístupnou MSDN Library [3], či případně knihu Programming Microsoft.NET [4], existuje však velké množství novějších knih i volně dostupných zdrojů na internetu. Pro samotné WSS doporučuji Inside Microsoft Windows SharePoint Services 3.0 [5]. Instalaci WSS popisuje příloha A.1.
20
4.4.1
Architektura Windows SharePoint Services
Obrázek 8: Architektura Windows SharePoint Services zachycuje architekturu WSS z hlediska hierarchické struktury a objektového modelu. Ke každému číslovanému elementu lze totiž přistupovat z objektového modelu.:
Obrázek 8: Architektura Windows SharePoint Services
21
Popis obrázku: 1) WSS používá jako datové úložiště databázový server s tím, že databáze je vždy rozdělena na tzv. Configuration Database (konfigurační databáze) a Content Database (databáze obsahu). Verze databáze značí, že podporované jsou databáze SQL Server 2000 a novější. 2) Jeden nebo více webových serverů (Web Servers) společně s databázovými servery tvoří tzv. farmu. Každá farma obsahuje právě jednu konfigurační databázi. 3) Virtuální server (Virtual Server) je webová aplikace IIS rozšířená o WSS. S touto aplikací je svázaná databáze obsahu. Z uvedené architektury 1-3 je zřejmé, že WSS nabízí velmi dobrou škálovatelnost. 5) Kolekce webů (Site Collection) je kontejner pro jednotlivé weby (Subsites), které mohou mít hierarchickou strukturu. Vždy zde je obsažen právě jeden top-level web, tedy web nejvyšší úrovně. Objekty reprezentující kolekci webů a web jsou často používané, bohužel ve verzi 3.0 došlo ke změně terminologie, avšak názvy objektů (tříd) zůstaly stejné. Kolekci webů (Site Collection) tedy zastupuje objekt SPSite a web (Site) objekt SPWeb. Vedle dalších podřízených webů web obsahuje kolekce stránek (Pages), seznamů (Lists), knihoven dokumentů (Document Libraries) a funkcí (Features). 6) Seznam (List) je základní datové úložiště SharePointu. Seznam má nejblíže k tabulce v relační databázi, tam je ostatně uložen. Vedle předdefinovaných seznamů je možné definovat seznamy vlastní. Knihovna dokumentů je speciální typ seznamu. 7) Fields jsou sloupce v seznamu. Vedle nich jsou definovány ještě tzv. Content Types (typy obsahu webu), které definují jakousi šablony pro celý seznam, samy se skládají ze sloupců. 8) Item je datová položka seznamu, z pohledu relační databáze by se jednalo o řádek. V bodu 5 byly zmíněny tzv. funkce, které se jinak přímo v hierarchickém modelu nevyskytují. Funkce poskytují mechanismus instalace a aktivace součástí na úrovni webových aplikací, kolekcí webů nebo samotných webů. Například v případě instalace tzv. site page (více kapitola 4.4.2.2), tedy zjednodušeně přidání webové stránky funkce definuje adresu vytvořené stránky a případné odkazy na stránku v menu. Detailněji funkce popisuje [5 stránky 19 - 28].
22
4.4.2
Webové stránky ve Windows SharePoint Services
WSS je postaveno na ASP.NET, programátor webových stránek portálu může tedy používat vše, co mu nabízí ASP.NET. Web je vždy vytvořen ze šablony, kde i ta nejjednodušší šablona (Empty Site) obsahuje několik předdefinovaných stránek. Úvodní stránkou je standardně default.aspx (zobrazuje např. Obrázek 1: Příklad úvodní stránky Wikiwebu portálu WSS). Všechny vytvořené stránky jsou postaveny na tzv. Master Page default.master. Master Page je koncept ASP.NET 2.0 umožňující definovat šablonu stránky nejčastěji s levým a horním menu a jednotlivé stránky (tzv. Content Pages) pak již vkládají pouze obsah do k tomu určené části stránky (Content Placeholder). Jednoduše s obrázky je koncept popsán v bakalářské práci Marka Dohnala [6 str. 32] na přiloženém CD nebo v [5 str. 36]. 4.4.2.1 Uložení webových stránek Odlišný je ovšem koncept přístupu ke stránkám. Při příchodu požadavku není stránka načtena
přímo z disku jako je tomu běžně u ASP.NET, ale získána
pomocí
SPVirtualPathProvider. Pomocí virtual path provider je možné stránku získat teoreticky odkudkoli. V případě WSS je získána z databáze obsahu nebo z disku v závislosti na typu stránky. Příklad získání default.aspx uvádí Obrázek 9: WSS virtual path provider.
Obrázek 9: WSS virtual path provider
Použití konceptu virtual path provider přináší dvě zásadní výhody: 1) Stránky jsou snadno upravitelné pomocí nástrojů jako Microsoft SharePoint Designer, případně lze vytvářet jednoduché stránky přímo z webového prostředí. 2) Koncept přináší značné zjednodušení v případě webů o řádově stovkách až tisících stránek. Jak již bylo zmíněno, weby a jednotlivé stránky jsou vytvářeny ze šablon. 23
Reálně se tedy vyskytuje jedna stránka třeba v 500 kopiích. Mnohem praktičtější než kopie je pouze uložení informací o použité stránce v databázi. Pouze upravené stránky je potřeba uložit extra a to se také provádí do databáze. 4.4.2.2 Site Pages Stránky, které je možno upravovat se nazývají site pages. Snadná upravitelnost má však i svá úskalí související s výkonností aplikace, protože v případě získávání všech stránek z databáze se databáze stává úzkým hrdlem a toto je potřeba zohlednit. Upravené (customized) stránky, které jsou uložené v databázi, se také nazývají unghosted. Naproti tomu stránky, které existují ve stejné podobě jako šablona na disku, se nazývají ghosted. Kromě toho se customized stránky parsují ve speciálním bezpečném módu tzv. Safe Mode. Důvod je zabránit uživateli psát serverové skripty, které by mohl využít k útoku na server. Výjimkou jsou bezpečné ovládací prvky (Safe Controls) registrované ve web.config konfiguračním souboru webové aplikace. 4.4.2.3 Application Pages Speciálním typem stránek jsou tzv. application pages. Jedná se o stránky, které nepodporují upravitelnost, jsou tedy vždy tzv. ghosted. Primárně slouží k naprogramování aplikační logiky. Tyto stránky se standardně nahrávají do adresáře LAYOUTS obvykle v C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE. Webová adresa k nim potom v rámci webu začíná na ‚_layouts‘. Do stejného adresáře se často také nahrávají soubory s klientskými skripty (JavaScript skripty) a definice stylů CSS (Cascading Style Sheets). Adresář IMAGES (také v TEMLATE adresáři) slouží k nahrání obrázků. Samozřejmostí až nutností je vytváření podadresářů při kopírování souborů. 4.4.2.4 Web Part Pages Web part pages neboli stránky webových částí jsou speciální site pages, do kterých lze nahrávat tzv. webové části (web parts). Existuje několik předdefinovaných stránek rozložení webových stránek, případně je možné do vlastní site page vložit tzv. oblast webových částí (web part zone), což je místo na stránce, do kterého lze umístit webovou část. Vkládání probíhá za běhu aplikace, čili se podobá úpravě stránky s tím rozdílem, že stránka webových částí zůstává unghosted stavu.
24
4.4.3
Webové ovládací prvky SharePointu
SharePoint obsahuje a používá velké množství webových ovládacích prvků. Převážnou část je uložena ve jmenném prostoru Microsoft.SharePoint.WebControls a jejich název začíná ‚SP‘. Většina ovládacích prvků umožňuje práci se seznamy, ale některé mají velmi obecnou funkcionalitu. Nevýhodou je pouze fakt, že ačkoli ovládací prvky může použít každý, jejich použití je značně ztíženo téměř naprostou absencí dokumentace a jen minimem příkladů, jak prvky použít, což je velmi neobvyklé. Pro použití prvků je tedy často zapotřebí buď hledat na internetu, nebo použít nástroj .NET Reflector pro nahlédnutí dovnitř prvků. 4.4.3.1 Webové části Webová část je speciální ovládací prvek. Existují dvě implementace webových částí, SharePoint implementace a ASP.NET 2.0 implementace, rozdíl není technologický, ale implementace jsou obsažené v odlišných knihovnách. Jsou velmi obdobné, SharePoint implementace existuje z důvodu kompatibility s webovou částí z předchozí verze SharePointu, v době její implementace ještě neexistovala ASP.NET verze. ASP.NET verze je novější a její použití doporučované. Dle mého názoru je také lépe dokumentovaná. Webová část může obsahovat další prvky a poskytovat rozličnou zpravidla netriviální funkcionalitu. Tvoří tak modulární komponentu webového uživatelského rozhraní. Na internetu lze najít velké množství webových částí. Několik jednoduchých webových částí je také standardní součástí WSS. Jednu z nich zachycuje Obrázek 10: Webová část MSPageViewer. Důležitou vlastností webové části je její upravitelnost. Webová část obsahuje speciální menu, s jehož pomocí lze nastavit, co například webová část zobrazuje a jakým způsobem. Nastavení provádí buď administrátor a je poté shodné pro všechny uživatele (tzv. Customization), nebo existují webové části, které si přizpůsobují sami uživatelé (tzv. Personalization). Informace o nastavení se ukládají do databáze obsahu. Webové části mezi sebou mohou komunikovat pomocí tzv. connections (spojení).
25
Obrázek 10: Webová část MSPageViewer
Jedinou drobnou nevýhodou webových částí je jejich charakter webových ovládacích prvků. Na rozdíl od ASP.NET webových stránek není standardně možné kód rozdělit do kódu definujícího prezentační strukturu v podobě aspx souboru a samotnou aplikační logiku. Vše se tedy kóduje přímo v jazyku C# nebo jiném jazyku podporovaném .NET Frameworkem, navíc v současné době neexistuje designer usnadňující rozložení webových prvků uvnitř webové části. 4.4.4
Zabezpečení a uživatelé v SharePointu
SharePoint používá model zabezpečení ASP.NET 2.0, více informací lze nalézt v bakalářské práci Marka Dohnala [6 str. 27]. V běžném nastavení se spoléhá na ověřování Windows, využívá tedy uživatelská jména a hesla domény. Uživatelé jsou v SharePointu rozděleni na vlastníky, členy a uživatele webu. Každý web má svého administrátora, který má právo úplného řízení. Navíc lze umožnit anonymní přístup. Oprávnění lze nastavovat pro celé weby, jednotlivé seznamy i konkrétní položky seznamů. 26
4.5 Návrh uživatelského rozhraní Návrhem uživatelského rozhraní začínám z důvodu, že umožňuje výstižnou ilustraci funkcionality systému a hlavně na uživatelském rozhraní závisí i datový model a samotná architektura aplikace. Uživatelské rozhraní by mělo vycházet z rozhraní používaného v SharePointu. Myšlenkou je, že uživatel by téměř ani neměl poznat, jestli zrovna upravuje SharePoint seznam, nebo jestli zobrazuje položky získané z Heliosu. SharePoint seznam uvádím proto, že jako základní datový element SharePointu je z pohledu struktury velmi podobný pořadači v Heliosu. Také lze zobrazit data jako přehled v tabulce (gridu) nebo zobrazovat a upravovat jednotlivé položky seznamu. Všechny operace by se měly provádět stejným způsobem jako v SharePointu, uživatelské prvky by měly být stejně rozmístěny a neodlišovat se od prvků SharePointu. 4.5.1
Zobrazení přehledu
Zobrazení přehledu položek zachycuje obrázek Obrázek 11: Zobrazení položek seznamu Úkoly. Zajímavá je pravá část obsahující samotný obsah. Nahoře je nadpis odpovídající názvu seznamu, tedy Úkoly. Níže se nachází lišta s vysouvacím menu položek, v její pravé části filtr. Menu obsahuje především akce spojené s úpravou seznamu a jeho zobrazení, tedy akce, které může provádět pouze administrátor. Běžný uživatel vidí pouze menu Akce, s jehož pomocí lze například vyexportovat data do aplikace Microsoft Access, a také pokud může vytvářet nové položky, pokud mu to jeho práva umožňují. Pod lištou je samotný obsah, tedy tabulka, jejíž řádky reprezentují položky a sloupce jednotlivé položky resp. atributy položek. Navíc sloupec nadpis umožňuje kliknutí a přechod na zobrazení detailů o položce, tedy přechod na formulářové zobrazení. Kromě kliknutí je možné použít kontextové menu a rovnou například vymazat položku.
27
Obrázek 11: Zobrazení položek seznamu Úkoly
4.5.2
Formulářové zobrazení položky
Po kliknutí na položku v přehledu nebo výběru volby Zobrazit položku se zobrazí detaily položky, jak zachycuje Obrázek 12: Formulářové zobrazení položky seznamu Úkoly:
Obrázek 12: Formulářové zobrazení položky seznamu Úkoly
28
V pravé horní části je opět nadpis obsahující název seznamu a vybrané položky. Za povšimnutí stojí absence levého menu (panel Snadné spuštění). Důvodem je zřejmě odstranění nepodstatných údajů z uživatelova zorného pole. K navigaci zpět na zobrazení přehledu slouží tlačítko zavřít. Přejděme k samotnému formuláři položky na pravé straně. Formulář v horní části obsahuje lištu akcí spojených s přidáváním, odstraňováním a úpravou položek a níže tabulku, na jejíž levé straně je název atributu položky a vpravo jeho hodnota. 4.5.3
Úprava položky
Formulář pro úpravu položky se podobá zobrazení položky, pouze obsahuje editovatelná pole. Velmi obdobný je také formulář pro přidání položky. Formulář pro úpravu výše zobrazené položky ukazuje Obrázek 13: Úprava položky seznamu Úkoly:
Obrázek 13: Úprava položky seznamu Úkoly
Za povšimnutí stojí tlačítka OK a storno sloužící k uložení změn nebo zrušení změn a k následnému přechodu zpět na zobrazení přehledu. Hodnoty atributů (položky) odpovídají datovému typu, například stav je reprezentován tlačítkem výběr. Navíc formulář obsahuje 29
některé pomocné prvky jako například ikonu pro výběr data nebo HTML editor pro editaci Popisu. 4.5.4
Vytvoření uživatelského rozhraní pomocí webových částí
Výše uvedené uživatelské rozhraní bude simulované pro zobrazení a úpravy záznamů z Heliosu pomocí dvou webových částí: 1) WebPartHeliosGrid 2) WebPartHeliosItem WebPartHeliosGrid slouží k zobrazení přehledu záznamů. Je vždy svázaná s konkrétním pořadačem, pohledem či šablonou. WebPartHeliosItem umožňuje zobrazovat, přidávat, upravovat a mazat jednotlivé položky. V databázovém světě se tyto operace často nazývají CRUD (Create, Read, Update, Delete). Použití webových částí je vhodné, protože: Webová část je modulární element. Webovou část lze snadno přidat do webové stránky (tzv. stránky webových částí), zbytek webové stránky zůstává beze změny. o Stejným způsobem jsou koncipované i výše uvedené příklady uživatelského rozhraní, jsou v nich použity webové části ListViewWebPart a ListFormWebPart, o čemž se lze přesvědčit pomocí SharePoint Designeru. o Uživatel tedy nemusí ani poznat, že se jedná o webovou část. Jedná se o upravitelný element přímo ve webovém prostředí. Webové části jsou snadno znovupoužitelné a snadno mohou být nainstalovány do SharePoint webu.
30
4.5.4.1 Webová část WebPartHeliosGrid Webová část pro zobrazení přehledu dat z Heliosu na základě funkčních požadavků musí obsahovat ještě několik pomocných položek, jak ukazuje Obrázek 14: Webová část WebPartHeliosGrid:
Obrázek 14: Webová část WebPartHeliosGrid
Především se jedná o levý sloupec zaškrtávacích tlačítek, který umožňuje vybrat záznamy, nad kterými budou spuštěny funkce. Funkce umožňuje spouštět menu Spustit funkci v pravé části horní lišty. Navíc z důvodů cachování dat bylo přidáno tlačítko pro načtení aktuálních dat z Heliosu. Obě uvedená tlačítka se před provedením akce ještě dotážou uživatele na potvrzení. Napravo od sloupce zaškrtávacích tlačítek je sloupec zobrazit, který umožňuje zobrazit položku. Důvodem je fakt, že v případě, že hodnota položky ve sloupci umožňujícím přechod na formulářové zobrazení položky je prázdný řetězec, není možné na položku přejít. Konečně ve spodní části si můžeme povšimnout prvků umožňujících stránkování. Obrázek 15: Webová část WebPartHeliosGrid v režimu úprav zobrazuje Webovou část WebPartHeliosGrid znovu v režimu úprav, tedy ve stavu, kdy administrátor může spravovat vzhled a obsah webové části. Webová část je v tomto případě vložena do jiné stránky a to do předdefinované stránky webových částí, která neobsahuje panel snadného spuštění, mírně
31
se liší v nadpisu a je uložena v knihovně Sdílené dokumenty (viz navigační pruh nad nadpisem).
Obrázek 15: Webová část WebPartHeliosGrid v režimu úprav
Do levé části lze teoreticky přidat další webové části a pravá část obsahuje panel umožňující provádět nastavení webové části. Skupiny Zobrazení dat, Funkce a Připojení obsahují vlastní nastavení týkající se Heliosu, zbylé skupiny zahrnují standardní nastavení webových částí. Vlastní naprogramované skupiny mají z nějakého důvodu odlišný formát. Pro ilustraci je skupina Funkce rozbalena. Tato skupina slouží k jednoduchému nastavení funkcí, které bude možné spouštět nad záznamy. Zobrazení dat umožňuje nastavit například číslo zobrazeného pořadače a počet záznamů na stránce. Ve skupině Připojení lze definovat parametry připojení k ServiceGate. 4.5.4.2 Webová část WebPartHeliosItem Příklad webové části WebPartHeliosItem zachycuje Obrázek 16: Webová část WebPartHeliosItem. Z horního menu oproti zobrazení položky seznamu byly odstraněny volby pro správu oprávnění a upozornění. Naopak zde přibyla možnost načíst aktuální data. Také došlo k úpravě zobrazení položek, protože záznam Heliosu obecně může obsahovat atributy, poté záznamy navázané přes vztahy a u dokladových tříd položky zobrazené v tabulce obdobně jako přehled. Protože například atributů mohou být desítky, jako je tomu 32
v uvedeném příkladu se zobrazenou organizací LCS, je vhodné uživateli umožnit zobrazit jen tu část, která je pro něj podstatná. Lze tedy celou skupinu atributů minimalizovat, jak zachycuje obrázek. Navázané záznamy jsou zobrazeny jako odkazy vedoucí na zobrazení záznamu.
Obrázek 16: Webová část WebPartHeliosItem
4.5.4.3 Propojení webových částí Ačkoli webové části na jedné stránce mezi sebou mohou komunikovat prostřednictvím tzv. spojení, zde je situace poněkud odlišná, protože každá webová část se nachází na jiné stránce. Obecně se nedoporučuje dávat na jednu stránku více webových částí nebo obecně více prvků s různou funkcionalitou kvůli rostoucímu zatížení serveru, ačkoli uživatel zpravidla využije jen malou skupinu prvků nebo pouze jednu webovou část. Zatímco
WebPartHeliosGrid
je
vždy
svázaná
s konkrétním
pořadačem,
WebPartHeliosItem umožňuje zobrazit záznam libovolné třídy a tedy i libovolného pořadače.
N
WebPartHeliosGrid
částí
může
být
svázáno
s jednou
jedinou
WebPartHeliosItem částí. Adresa propojené WebPartHeliosItem části je součástí nastavení WebPartHeliosGrid části podobně jako například parametry připojení. Poněvadž se nacházíme ve webovém prostředí, nejsnazší forma komunikace spočívá ve webových požadavcích typu GET, tedy pomocí URL (Uniform Resource Locator) adresy a tzv. query stringu, kterým je možno předat stránce dodatečné parametry. Uvedenou metodu 33
používá i zobrazování položek seznamů v SharePointu. Příkladem adresy pro zobrazení záznamu hodiny z ceníku může být: http://f/WebPartPages/ItemPage01.aspx?action=view&class=317&item=88426&source=ht tp%3A%2F%2Ff%2FWebPartPages%2FGridPage01.aspx%3Fpage%3D1. Význam jednotlivých části zobrazuje Tabulka 2: Popis URL stránky s WebPartHeliosItem částí: Část adresy
Význam
http://f
Adresa webového serveru.
/WebPartPages/ItemPage01.aspx
Adresa stránky, kde je vložena WebPartHeliosItem webová část.
?...
Začátek query stringu, obsahem jsou parametry ve formátu název=hodnota odděleny znakem ‘&‘.
action=view
Specifikuje akci, která se se záznamem provádí, tedy v tomto případě zobrazení záznamu.
class=317
Třída záznamu.
item=88426
Číslo záznamu, který bude zobrazen.
source=…
Adresa stránky, na které byl umístěn odkaz kvůli návratu zpět. Adresa je speciálně zakódována, protože query string nemůže obsahovat některé znaky, které adresa obsahovat může. Tabulka 2: Popis URL stránky s WebPartHeliosItem částí
34
4.5.4.4 Režimy zobrazení webové části WebPartHeliosItem Protože webová část WebPartHeliosItem obstarává mnoho akcí, se kterými by v případě implementace klasickými ASP.NET webovými stránkami bylo spojeno několik stránek, je potřeba zachytit různé stavy webové části, tak jak je popisuje Obrázek 17: Stavový diagram WebPartHeliosItem:
Odstranit položku / Datové operace Upravit položku / Zobrazit formulář
Nová položka / Zobrazit formulář
Zobrazit položku / Zobrazit formulář Úprava záznamu
Nový záznam Upravit položku / Zobrazit formulář
Nová položka / Zobrazit formulář
OK / Datová operace Zobrazení záznamu Odstranit položku / Datová operace
Odstranit položku / Datová operace
OK / Datová operace
Storno / Přesměrování Storno / Přesměrování
Datová operace mazání
Zavřít / Přesměrování
Datová operace úprava
/ Přesměrování
/ Přesměrování
Datová operace nový
/ Přesměrování
Obrázek 17: Stavový diagram WebPartHeliosItem
Počáteční stav odpovídá první inicializaci Webové části resp. stránky s webovou částí. Pravděpodobně předcházela volba operace na přehledové webové části. Na základě volby operace dojde k zobrazení patřičného formuláře, jak zachycují stavy Zobrazení záznamu uprostřed, Úprava záznamu vlevo a Nový záznam na pravé straně. Po zmáčknutí tlačítka Zavřít nebo Storno cyklus WebPartHeliosItem končí a přesměrovává se zpět na stránku, odkud se přišlo, tedy nejspíše na přehled záznamů. Naproti tomu při potvrzení změny údajů nebo výběru smazání položky (mohlo být zvolené hned na začátku) dojde nejprve 35
k inicializaci datové operace, a jakmile datová operace proběhne, dochází k přesměrování na přehled záznamů. To, že datové operace mazání, úpravy a přidání jsou zobrazeny jako stavy, vystihuje fakt, že stránka je běžným způsobem zpracována, ovšem nemá HTML výstup a po ukončení datové operace provádí přesměrování. Výjimkou jsou oznámení o chybách, ale ty z důvodu limitovaného prostoru na stránce stejně jako načtení aktuálních dat schéma nezahrnuje. Jednotlivé stavy stránky je možno reprezentovat hierarchií tříd poskytujících rozdílnou funkcionalitu na základě svých typů, čímž se lze elegantně vyhnout větvení programu podmínkami.
Inicializaci
rozdílných
typů
provádí
statická
metoda
CreateConcreteItemPartHelper třídy ItemPartAbstractHelper na základě action parametru query stringu. Diagram tříd uvádí Obrázek 18: Hierarchie tříd reprezentujících stavy WebPartHeliosItem: ItemPartAbstractHelper +CreateConcreteItemPartHelper() +CreateChildControls() +OnPreRender() +DataTaskFinished()
ItemPartEmptyHelper
ItemPartDeleteHelper
ItemPartViewHelper
ItemPartEditHelper
ItemPartViewRelationHelper
ItemPartCreateNewHelper
Obrázek 18: Hierarchie tříd reprezentujících stavy WebPartHeliosItem
ItemPartAbstractHelper je abstrakní rodičovská třída, ItemPartEmptyHelper slouží k výpisu několika řádek textu, například chyb. ItemPartDeleteHelper provádí mazání záznamů. ItemPartViewHelper obstarává zobrazení záznamu a ItemPartViewRelationHelper zobrazuje propojený záznam. ItemPartEditHelper a ItemPartCreateNewHelper slouží k úpravě a přidávání nových záznamů. Základní virtuální metody ItemPartAbstractHelper vycházejí z cyklu webové stránky v ASP.NET, tedy CreateChildControls 36
pro vytvoření ovládacích prvků, OnPreRender pro
spuštění datové úlohy a DataTaskFinished zahrnující operace po dokončení datové operace. Podrobněji tuto problematiku popisuje kapitola 5.3.1.
4.6 Návrh datové vrstvy a přístupu k datům Základem systému je přístup k datům systému Helios a jejich následné zpracování zahrnující cachování pro rychlý přístup k datům. Druhou částí je již zmíněné uživatelské rozhraní, které data zobrazuje, umožňuje jejich úpravy a obecně zajišťuje interakci s uživatelem. 4.6.1
Přístup k ServiceGate
Přístup k systému Helios srze ServiceGate zprostředkovává ServiceGateAdapter. Webové rozhraní musí umožnit správu připojení k ServiceGate s různými parametry a následně efektivní komunikaci pomocí vytvořených připojení. Správa připojení k ServiceGate a výběr konkrétního připojení se provádí v nastavení webové části ve skupině Připojení. Protože ovšem webové části mezi sebou mohou sdílet připojení, je potřeba manažer připojení a datové úložiště nastavení připojení, které mohou sdílet webové části mezi sebou v rámci konkrétního webu. SharePoint nabízí jako úložiště seznam. Parametry připojení budou tedy uloženy v seznamu SGConnections. Strukturu seznamu zachycuje Tabulka 3: Sloupce seznamu SGConnections: Název sloupce
Význam
SGConnectionName
Název připojení. Slouží jako identifikátor a název pro administrátora.
SGConnectionUrl
URL aplikačního serveru Helios.
SGConnectionDbProfile
Název databáze Heliosu.
SGConnectionLogin
Uživatelské jméno připojení.
SGConnectionPassword
Heslo. Připojení nemusí vyžadovat heslo.
SGConnectionLanguage
Kód jazyka připojení (zpravidla ‘CZ’ nebo ‘EN’). Tabulka 3: Sloupce seznamu SGConnections
K přístupu k seznamu a také jeho vytvoření slouží třída SGConnectionsList. Na aplikační úrovni se parametry uložení do objektu třídy SGConnectionParameters, tento objekt také obsahuje odkaz na položku v seznamu, kterou reprezentuje. Pomocí parametrů je vytvořeno připojení SGConnection a připojení spravuje manažer připojení SGConnMan. Každý web obsahuje právě jeden SGConnMan. Je zde využit návrhový vzor Singleton společně s tzv. lazy 37
instantiation (více o vzorech např. v [7]). Vztahy mezi třídami zachycuje Obrázek 19: Diagram tříd připojení k ServiceGate: SGConnMan
SGConnection 1
*
SGConnectionParameters 1
1
SGConnectionsList 1
1
Obrázek 19: Diagram tříd připojení k ServiceGate
Po vytvoření připojení k ServiceGate je toto připojení udržováno otevřené a jakmile další klient potřebuje komunikovat se ServiceGate, zažádá si o připojení SGConnection podle jména od manažera SGConnMan a získá připojení, které může ihned použít. Pokud by se vždy inicializovalo nové připojení k ServiceGate, došlo by k rapidnímu poklesu výkonnosti, inicializace připojení trvá jednotky až desítky sekund, jednoduchý dotaz při rychlé odezvě sítě desetiny sekundy. 4.6.2
Komunikace se ServiceGate pomocí XML zpráv
V kapitole 4.2.1 jsou popsány zprávy umožňující komunikaci se ServiceGate. Tabulka 4: Třídy zabezpečující komunikaci se ServiceGate pomocí XML zpráv uvádí a popisuje třídy umožňující komunikaci se ServiceGate: Název třídy
XML zpráva
Popis
BrowseHelper
BROWSE
Získání přehledu záznamů.
RetrieveHelper
RETRIEVE
Získání informací o jednom záznamu.
InsertUpdateHelper
INSERTUPDATE
Vložení nového záznamu nebo úprava stávajícího.
DeleteHelper
DELETE
Smazání záznamu.
ResetHelper
NEW
Získání šablony nového záznamu.
FunctionHelper
RUN
Spuštění funkce.
BROWSE
Umožňuje vytvoření a zpracování speciálního BROWSE dotazu pro získání informací o atributech určité třídy.
BROWSE
Umožňuje vytvoření a zpracování speciálního BROWSE dotazu pro získání informací o vztazích určité třídy.
AttributesHelper
RelationsHelper
Tabulka 4: Třídy zabezpečující komunikaci se ServiceGate pomocí XML zpráv
38
Všechny výše uvedené třídy slouží k vygenerování požadavku, jeho zpracování a následnému vrácení odpovědi. Třída vždy provádí požadavek odpovídající jejímu jménu. Výjimku představují pouze třídy AttributesHelper a RelationsHelper, které využívají třídu BrowseHelper, pouze navíc specifikují specifické vlastnosti požadavku. Informace o atributech a vztazích získávají z pořadačů Atributy a Vztahy. 4.6.3
Cachování dat
Cachování dat představuje základní výkonnostní optimalizaci aplikace. Především umožňuje zvýšit počet uživatelů, kteří mohou najednou aplikaci používat, aniž by výrazným způsobem vzrůstal čas odpovědi serveru. Obecný princip získání dat uvádí Obrázek 20: Proces získání dat:
Požadavek na získání dat
[Data nejsou v Cachi]
Získání dat ze ServiceGate [Data jsou v Cachi]
Uložení dat do Cache
Vrácení dat
Obrázek 20: Proces získání dat
Cache reprezentuje datovou komponentu umožňující uložení dat v paměti serveru. ASP.NET přímo nabízí požadovaný objekt. Ten představuje datovou strukturu se slovníkovým přístupem k položkám podle jejich jednoznačného řetězcového klíče (rozptylovací – hashovací tabulku). Data jsou standardně cachovaná po určitou dobu v závislosti na typu dat, obvykle pět minut. Po této době dochází k odstranění z cache a data je nutné v případě potřeby načíst znovu.
39
Metodu cachování lze samozřejmě použít pouze pro získávání dat, tedy v součinnosti s třídami BrowseHelper, RetrieveHelper, ResetHelper, AttributesHelper a RelationsHelper. Uvedené třídy agregují třídu zprostředkovávající cachování dat a ta agreguje vlastní cachovaná data. (V obou případech se jedná o kompozici). Uvedenou skutečnost zachycuje Obrázek 21: Třída RetrieveHelper a agregované třídy. Obrázek kromě třídy RetrieveHelper a agregovaného RetrieveDataCacher zprostředkovávajícího cachování obsahuje i třídy AttributesHelper a RelationsHelper, jimi použitý BrowseHelper a cachovací třídy. RetrieveHelper 1
RetrieveDataCacher
1 1 RetrieveData
1
1 1
1
AttributeHelper
1 1 BrowseHelper
1
RelationsHelper
1
1
1
1 AttributesDataCacher
1
BrowseHelper
1 1 AttributesData
Obrázek 21: Třída RetrieveHelper a agregované třídy
40
1 RelationsDataCacher
1 1 RelationsData
BrowseHelper cachuje zvlášť samotná data a sloupce, tedy jinými slovy strukturu dat. Důvodem je fakt, že sloupce nemusejí být aktualizovány stejně často jako samotná data. Požadavek jestli získat i definice sloupců nebo jen data je součástí BROWSE zprávy. BrowseHelper
1 1 BrowseColumnsCacher
1 1 BrowseColumnsData
1 1 BrowseDataCacher
1 1 BrowseData
Obrázek 22: Třída BrowseHelper a agregované třídy
ResetHelper je velmi podobný jako RetrieveHelper, proto ho zde neuvádím. 4.6.3.1 Synchronizace souběžných požadavků U cachování dat je potřeba třeba zohlednit fakt, že k aplikaci přistupuje velké množství uživatelů, každý je obsluhován jiným vláknem aplikace. Problém tedy může nastat v situaci, kdy několik uživatelů současně zažádá o data, která nejsou uložena v cachi. Dojde přirozeně k tomu, že každé vlákno získá data ze ServiceGate a poté uloží do cache. Protože cyklus požadavku a odpovědi ze ServiceGate může trvat několik sekund, k dané situaci tedy může docházet zcela běžně. Požadované je, aby v okamžiku, kdy jedno vlákno získává data, ostatní vlákna čekala a následně data načetla z Cache. Možné řešení zachycuje Obrázek 23: Scénář synchronizace souběžných požadavků.
41
Uživatel1
bh1: BrowseHelper
CachedData : BrowseData
bh2 : BrowseHelper
GetData()
Uživatel2
GetData() IsCachedData()
IsCachedData()
false
false
Lock(CachedData) Lock(CachedData) GetDataFromSG()
CacheData() Unlock(CachedData) Data IsCachedData() true, Data Unlock(CachedData) Data
Obrázek 23: Scénář synchronizace souběžných požadavků
Na protilehlých stranách se nacházejí dva uživatelé, kteří požadují data. Připomeňme, že uživatel odpovídá vláknu a že uživatelů může být řádově mnohem více než dva. Každý uživatel použije svou instanci BrowseHelperu pro přístup k datům, která jsou obecně sdílená. DataCacher je pro jednoduchost vynechán. Datový objekt CachedData obsahuje část, která je do cache automaticky vložena v okamžiku inicializace DataCacheru (v případě, že se v cachi nenachází) a část, která obsahuje přímo data. BrowseHelpery se dotážou, jestli jsou data dostupná v cachi, tedy přímo na datovou část. Tento požadavek může přijít v naprosto stejný okamžik, a protože obsahuje pouze čtení proměnných, nenastává zde žádný problém. Odpověď je false. Jednomu z BrowseHelperů (zde bh1) se podaří objekt CachedData uzamknout jako prvnímu, k tomu právě slouží automaticky zinicializovaná část. Následuje získání dat (GetDataFromSG(), tedy příjem dat ze ServiceGate), uložení do CachedData a opětovné odemknutí objektu. Až po jeho odemknutí se podaří uzamknout i bh2, následuje dotaz, jestli již data nejsou v cachi a po odpovědi společně s daty je objekt opět odemčen. Data tedy již není potřeba získávat ze ServiceGate. Nakonec získávají oba uživatelé požadovaná data.
42
V souvislosti se zmíněným v cachi automaticky inicializovaným objektem, který se uzamyká při získávání dat, uvádím Obrázek 24: Hierarchie cachovacích tříd: T BaseCacher +DataObject : T +GetFromCache() +InsertIntoCache() +RemoveFromCache()
T BrowseColumnsCacher
RetrieveDataCacher
BaseCacherWithLockingObject
ResetDataCacher
AttributesDataCacher
BrowseDataCacher
RelationsDataCacher
Obrázek 24: Hierarchie cachovacích tříd
Všechny cachovací třídy vycházejí ze třídy BaseCacher. T značí generický typ odpovídající konkrétnímu typu dat (např. RetrieveData). Samotná data jsou přístupná přes DataObject. BaseCacher také definuje základní operace získání, přidání a vymazání dat z cache. BrowseColumnsCacher a BrowseDataCacher jsou používány společně a protože BrowseDataCacher cachuje jednotlivé stránky přehledu, obsahuje vždy pole, které slouží jako uzamykací objekt. BaseCacherWithLockingObject pak definuje speciální objekt pro zamykání, odtud i jeho jméno.
43
4.7 Bezpečnost aplikace Na bezpečnost aplikace je potřeba nahlížet ze čtyř pohledů: 1) Bezpečnost v rámci SharePoint serveru 2) Bezpečnost připojení k ServiceGate 3) Bezpečnost dat uložených v seznamech SharePointu 4) Bezpečnost z pohledu vlastních webových částí 4.7.1
Bezpečnost v rámci SharePoint serveru
Bezpečnost v rámci SharePoint serveru je postavena na ASP.NET zabezpečení a je otázkou správného nastavení uživatelů, uživatelských skupin a práv jednotlivých skupin a uživatelů. Taktéž volba požadavků na hesla (např. minimální délka) ovlivňuje bezpečnost. Z hlediska technického předpokládejme, že se zde nenacházejí žádné známé snadno využitelné bezpečnostní chyby a lze tedy použít standardně poskytované funkce zabezpečení beze změn jako černou skříňku, tedy bez nahlížení dovnitř. 4.7.2
Bezpečnost připojení k ServiceGate
Na ServiceGate i ServiceGateAdapter lze nahlížet jako na černé skříňky, ovšem důležitá je komunikace mezi nimi. Standardně lze k ServiceGate přistupovat přes HTTP (Hypertext Transfer Protocol) a HTTPS (Hypertext Transfer Protocol Secure) protokoly. Jak naznačuje slovo ‚Secure’ v HTTPS, jedná se o zabezpečený protokol, kde je komunikace šifrována. Pokud tedy dochází k připojení k ServiceGate přes veřejnou síť, např. Internet, je velmi žádoucí přistupovat k serveru pomocí HTTPS, protože v opačném případě se data po síti pohybují v otevřené podobě. Naopak v případě, kdy je webový server se SharePointem a ServiceGateAdapterem nasazený na lokální síti a na té samé síti se nachází server se ServiceGate a Heliosem, pak je nutné porovnat bezpečnostní riziko s poklesem výkonnosti díky použití šifrované komunikace. To samé platí v případě VPN (Virtual Private Network) sítí, které se chovají jako lokální a komunikace je v nich již šifrována. Vedle samotné komunikace je zde opět ještě hledisko volby uživatelského jména a hesla pro přístup k Heliosu podobně jako u uživatelských účtů v SharePointu. Podobně uživatelé mohou mít nastavená práva na prováděné operace v jednotlivých pořadačích či třídách.
44
4.7.3
Bezpečnost dat uložených v seznamech SharePointu
Řešení webového přístupu k ERP Helios ukládá parametry připojení používaných webovými částmi do seznamu SGConnections. Zde se nachází potenciálně nebezpečné místo, protože je potřeba zajistit, aby webová část zobrazená uživatelem měla přístup k potřebným údajům, ale samotný uživatel nikoli. Připomeňme, že pořadače a záznamy, které může uživatel zobrazit, určuje správce. Ten také zadává parametry připojení. Uvedené požadavky jsou však protichůdné, protože SharePoint standardně generuje stránky, které uživateli umožní zobrazit seznam, k jehož zobrazení má uživatel práva. Lze ovšem udělat několik kroků, která uživateli zamezí zjistit parametry připojení: 1) Umožnit uživateli pouze zobrazení seznamu Jedná se o zřejmý požadavek, ale je skutečně důležité, aby uživatel neměl na seznam jiná práva, než která potřebuje, tedy zobrazení. 2) Vymazat všechny pohledy Nad seznamem je možné definovat pohledy. Pohled je přehledové zobrazení položek seznamu. Při vytvoření seznamu se vytvoří i výchozí pohled, který zobrazuje všechny položky seznamu. 3) Skrytí všech polí seznamu I pokud není definovaný pohled nad seznamem, stále jsou standardně vytvořeny stránky umožňující zobrazení jednotlivých položek seznamu. Toho by případný útočník při znalosti jména seznamu mohl snadno využít. Pole seznamu lze skrýt a skrytá pole se pak nezobrazují. Při skrytí všech polí je tedy zobrazena pouze prázdná stránka místo celé položky. Vedle skrytí polí lze pomocí SharePoint Designeru smazat stránky umožňující zobrazení položek. 4) Šifrování ukládaných údajů Hesla ukládaná do databáze se doporučuje šifrovat, aby potenciální útočník při získání dat z databáze nemohl data použít. Heslo samozřejmě musí být uloženo v aplikaci, ale k té se útočník nemusí vždy dostat. Stejnou zásadu lze použít v případě seznamu SGConnections pro uložení všech položek. Protože k seznamu se přistupuje pouze při načtení připojení do paměti a úpravách připojení správcem, nejedná se o výkonnostní problém. Všechna výše uvedená opatření využívá třída SGConnectionList zajišťující přístup k seznamu, jeho vytvoření, přidávání, odstraňování a úpravu položek.
45
4.7.4
Bezpečnost z pohledu vlastních webových částí
Jak bylo uvedeno v kapitole 4.5.4.3, komunikace mezi webovými částmi probíhá pomocí query stringu. Webová část WebPartHeliosGrid pomocí query stringu a jeho parametrů definujících číslo záznamu a třídy určí, jaký záznam bude ve webové části WebPartHeliosItem zobrazen. Je nereálné snažit se zajistit, aby uživatelská práva připojení k ServiceGate přesně odpovídala nastavenému zobrazení ve webové části, navíc lze předpokládat, že správce použije sdílené připojení pro více webových částí a nebude řešit, na jaké pořadače má použitý uživatelský účet připojení práva. Možným řešením je uložení informací o právech na jednotlivé záznamy při zobrazení přehledu záznamů ve webové části. Podobně je třeba nastavit právo na prohlížení všem vztaženým záznamům (záznamům navázaným vztahy) při formulářovém zobrazení jednoho záznamu. Informace o právech mohou být uloženy do cache. Před zobrazením záznamu ve webové části WebParhHeliosItem dojde nejprve k ověření požadovaných práv, až následně je provedena požadovaná operace. V případě, že práva pro daný záznam nejsou nastavena, je zobrazena výjimka s upozorněním, že výjimečně může k situaci dojít například při restartu serveru a uživatel je požádán, aby se nejprve vrátil na stránku přehledu a zkusil operaci provést znovu. Typy povolených operací se záznamem definuje třída ItemPermissions. Klasicky se jedná o CRUD operace, tedy zobrazit, upravit, přidat nový, odstranit záznam a navíc povolení spouštět funkce nad záznamem. ItemPermissions pro jednotlivé záznamy je uložena v kolekci se slovníkovým přístupem k položkám podle jednoznačného klíče vytvořeného z čísla záznamu a jeho třídy. Tato kolekce je uložena v cachi na dobu neurčitou a pro každou webovou část WebPartHeliosItem existuje právě jedna tato kolekce. přidávání
položek
do
kolekce
a
kontroly
povolených
operací
Funkcionalitu obsahuje
třída
ItemPermissionManager. Uvedené řešení nepředstavuje výrazné výkonnostní zatížení, jedna položka sice v paměti zabírá průměrně přibližně 80 B (otestováno, délka je dána především klíčem a hashovací strukturou, samotná data jsou přesně 4 B), ovšem lze předpokládat, že na webu se nebudou zobrazovat stovky více jak řádově miliónů záznamů a tudíž ani paměťová náročnost není příliš vysoká. Navíc cache serveru je v případě potřeby vyprázdněna.
46
5
Realizace
5.1 Struktura aplikace Struktura aplikace je dána strukturou WSS a způsobem komunikace s ERP systémem Helios (více kapitola 4.1.1). Jednotlivé komponenty aplikace zachycuje Obrázek 25: «library» ServiceGateAdapter
«library» WebPartHelios
Funkce, stránky, seznamy WebPartHelios
Windows SharePoint Services
ASP.NET 3.5
WSS Configuration Database
WSS Content Database
Obrázek 25: Komponenty aplikace
Komponenty s šedou výplní jsou komponenty implementované v rámci této práce. WebPartHelios je DLL knihovna obsahující funkcionalitu webových částí a přístupu k datům. Nebyl důvod dělit ji na menší komponenty. Druhá implementovaná komponenta představuje množinu dodatečných funkcí, stránek a seznamů. Pod pojmem stránky se rozumí site pages a application pages, které zahrnují i externí soubory jako obrázky a klientské skripty. V rámci projektu Visual Studia jsou všechny tyto dodatečné části uloženy v adresáři TEMPLATES. Seznamy jsou zastoupeny seznamem SGConnections spravovaným knihovnou WebPartHelios. Komponenta WebPartHelios využívá knihovny ServiceGateAdapter ke komunikaci s Heliosem. Dále závisí na Windows SharePoint Services a ASP.NET 3.5, stejně jako dodatečné funkce a stránky řešení. Obrázek také zahrnuje použití databází Windows SharePoint Services. Důležité je, že schéma neobsahuje žádné cyklické závislosti.
47
5.2 Implementace datové vrstvy a přístupu k datům 5.2.1
Přístup k seznamu SGConnections
Přístup k seznamu SGConnections obstarává třída SGConnectionsList. Důležitou součástí funkcionality této třídy je vytvoření samotného seznamu. Při implementaci se vyskytlo několik drobných problémů. Pro samotné testování vytvoření seznamu není vhodné používat řešení webové části, ale konzolovou aplikaci. Existuje zde bezpečnostní omezení, že konzolová aplikace používající API (Application Programming Interface) SharePointu musí být spuštěna na tom samém počítači
s administrátorskými
právy.
Základní
metodu
pro
vytvoření
seznamu
SGConnections ukazuje Příklad 1: /// <summary> /// Vytvoří seznam, pokud neexistuje. /// private static void EnsureSGConnectionsList() { using(SPSite siteCollection = new SPSite("http://localhost")) { using(SPWeb site = siteCollection.OpenWeb()) { SPList list; // Pokud seznam neexistuje, bude vytvořen. if(!site.Lists.TryGetValue(LIST_NAME, out list)) { // Vytvoření seznamu. CreateList(site, ref list); // Nastavení stávajících polí seznamu jako nepovinných. MakeAllFieldsNonRequired(list); // Vytvoření sloupců. CreateListFields(list); // Vymazání pohledů. DeleteAllViews(list); // Skrytí všech sloupců. HideAllFields(list); } } } } Příklad 1: Vytvoření seznamu SGConnections
Za povšimnutí stojí objekty umožňující přístup ke kolekci webů, webu a seznamu a také jejich
poněkud
matoucí
pojmenování.
Metoda
TryGetValue
je
v rámci
řešení
implementovaná rozšiřující metoda (extension method; více MSDN Library [3]). Operace vytvoření seznamu jsou popsané přímo v kódu, poslední dvě operace souvisí se zabezpečením zmíněným v kapitole 4.7.3. Nově vytvořený seznam má standardně definovány některé sloupce a například hodnota sloupce Název je vyžadovaná, metoda MakeAllFieldsNonRequired slouží právě k zamezení požadování neprázdných hodnot. 48
Pro použití zmíněné metody z webové části je třeba provést několik změn. Pro přístup k webu je potřeba přidat následující řádky: SPWeb site = SPContext.Current.Web; site.AllowUnsafeUpdates = true;
První řádek získá web, na kterém se nachází webová část a druhý řádek je důležitý pro povolení operací upravujících seznam z prostředí webu. Závěrem bych rád upozornil na několik úskalí v přístupu k seznamu pomocí SPList: Reference na seznam se mění v průběhu požadavků Nelze tedy referenci na seznam mít uloženou v SGConnectionsList jako statickou metodu, ale je potřeba vždy seznam získávat přes SPWeb objekt. Příčina není zřejmá, dokumentace o tomto naprosto mlčí, ovšem znalost tohoto problému ušetří velké množství času při hledání chyby. K seznamům a položkám se přistupuje podle lokalizovaných názvů Tuto záležitost nebylo potřeba řešit, ovšem narazil jsem na ni při krokování aplikace. Problém je v tom, že názvy předdefinovaných seznamů a sloupců jednotlivých položek seznamů mají lokalizované názvy a podle těchto názvů je k nim třeba přistupovat i v objektovém modelu, aplikace používající tyto seznamy s tím ve vícejazyčném prostředí musí počítat. Po úpravě vlastnosti seznamu nebo sloupce je třeba volat metody Update Tento požadavek je zřejmý, protože samotným nastavením vlastnosti nedochází k uložení vlastnosti do databáze, naopak například při vytvoření nového seznamu je součástí metody vytvoření seznamu i uložení do databáze. Bohužel dokumentace tyto detaily nezmiňuje. 5.2.2
Správa připojení k ServiceGate
Funkcionalitu týkající se správy připojení k ServiceGate obstarává třída SGConnMan, manažer připojení. Pro každý web je vytvořena jedna instance SGConnMan, instance jsou uloženy ve sdílené kolekci (kolekce je static), což k ní zajišťuje přístup z libovolného místa aplikace. Přístup k této sdílené kolekci je potřeba synchronizovat, více o tom pojednává kapitola 5.2.4. Jedna manažeru připojení instance pak obsahuje definovaná připojení SGConnection v rámci webu. Protože SGConnMan je sdílený objekt existující po celou dobu běhu aplikace, je potřeba v případě ukončení aplikace uzavřít všechna otevřená připojení. ServiceGate z licenčních důvodů umožňuje omezený počet připojení a v případě neukončení připojení mohou být 49
dostupná připojení rychle vyčerpána. K ukončení aplikace dochází například při restartu serveru. K zajištění ukončení všech připojení slouží destruktor manažeru připojení, který zavolá na všech svých připojeních metodu Dispose(), která jednotlivá připojení ukončí. 5.2.3
Asynchronní zpracování dat
Vedle cachování dat představuje asynchronní zpracování datových úloh druhou významnou výkonnostní optimalizací. Tato optimalizace je úzce spojena s platformou webového serveru a ASP.NET. 5.2.3.1 ASP.NET model zpracovávání požadavků ASP.NET používá dva typy vláken, pracovní vlákna (Worker Threads), která zpracovávají příchozí požadavky a
vlákna určená pro zpracování vstupně-výstupních operací (I/O
Threads). Pro každý typ vláken je vytvořena fronta, do níž jsou vlákna řazena a postupně zpracovávána. Vlákna, která nejsou aktivní, jsou uložena v tzv. poolu, aby byla připravena na okamžité použití. Situaci přehledně ilustruje Obrázek 26: Vlákna v ASP.NET:
Obrázek 26: Vlákna v ASP.NET
Potíž spočívá v tom, že vláken je obecně omezené množství a žádoucí je, aby pracovní vlákna co nejrychleji zpracovala požadavek a následně byla opět připravena ke zpracování dalšího požadavku. Nedoporučuje se tedy pracovní vlákna používat pro zpracování datových operací, protože to jsou operace, které mohou řádově trvat i desítky sekund a v případě použití všech pracovních vláken by se mohla neúnosně prodloužit odezva serveru.
50
Řešením je použití druhého typu vláken pro datové operace. Cenou je ovšem složitější programátorský model, protože je potřeba stránku zpracovávat asynchronně. Porovnání normálního a asynchronního cyklu stránky v ASP.NET zachycuje Obrázek 27: Životní cyklus stránky v ASP.NET:
Obrázek 27: Životní cyklus stránky v ASP.NET
Obrázek zobrazuje sekvence stupňů, kterými stránka prochází, než je nakonec zobrazena. Jednotlivé stupně jsou vlastně vyvolávané události. Stupně jsou detailně popsány v MSDN Library [3]. Důležité je, že v případě klasického životního cyklu stránky celou sekvenci provádí jedno vlákno, pracovní vlákno. Naopak v případě asynchronního požadavku po ukončení stavu PreRender je pracovní vlákno uvolněno a datová operace je vykonávána vláknem pro zpracování vstupně-výstupních operací. Po dokončení datové operace je zpracování opět předáno pracovnímu vláknu pro dokončení požadavku. 5.2.3.2 Implementace asynchronních operací ve webovém přístupu Spuštění asynchronní datové operace v programovém kódu se provádí pomocí Page.RegisterAsyncTask(asyncTask) metody. Parametrem je objekt typu PageAsyncTask představující asynchronní úlohu. Registraci asynchronní úlohy je doporučeno provést ve stavu PreRender. Uvedené asynchronní zpracování je použito u všech tříd zprostředkovávajících komunikaci se ServiceGate, tedy BrowseHelper, RetrieveHelper, InsertUpdateHelper, ResetHelper, DeleteHelper a FunctionHelper. Samotnou funkci asynchronní úlohy zapouzdřuje pomocná třída ReqRespAsyncTask
, kde generickým parametr je typu 51
ServiceGateResponse. Uvedená třída používá principu skládání místo dědičnosti, agreguje v sobě tedy PageAsyncTask. Definuje delegáty a zpětná volání (Callbacks) zahájení asynchronní úlohy, zpracování odpovědi a také operaci, která se provede po dokončení asynchronní úlohy. Delegát je definice typově bezpečného ukazatele na metodu. Typová bezpečnost je označení pro odlišení od typů v jazyku C nebo C++, značí vyšší úroveň zabezpečení na platformě .NET. Zpětné volání je proměnná typu delegát. 5.2.3.3 Důsledky použití asynchronního zpracování Při použití asynchronního zpracování je třeba si uvědomit, že pokud je po ukončení datové operace potřeba přidat nějaké ovládací prvky například zobrazující získaná data, jsou uživatelské ovládací prvky vytvořeny dynamicky až po vytvoření všech ostatních prvků na stránce a kupříkladu použití událostí u těchto ovládacích prvků je komplikovanější než v případě klasického synchronního modelu. Jak příklad uvádím stránku editace záznamů, kde pole zobrazující hodnoty a umožňující jejich modifikace jsou vytvořeny dynamicky až po skončení datových operací. Za normálních okolností ASP.NET umožňuje po odeslání formuláře zpět na web přistupovat k ovládacím prvkům stejným způsobem jako v desktop aplikaci. Zde ovšem ovládací prvky nejsou k dispozici, pro získání odeslaných dat je tedy třeba při zpracování následujícího požadavku, který odeslaná data obsahuje, použít přímo kolekci Form objektu HttpRequest dostupného jako Page.Request. Kolekce Form obsahuje odeslaná formulářová data. Tento způsob zpracování je naprosto běžný například v programovacím jazyku PHP. Pro jednoznačné identifikování dat je pouze nutné definovat jednoznačné názvy, pro atributy ve formátu ‘at__‘ a název atributu, relace mají prefix ‘rel__’ následovaný číslem vztahu. 5.2.4
Synchronizace přístupu vláken ke sdíleným datům
Aplikace obsahuje množství sdílených dat především z důvodu výkonnosti a zabezpečení. Je tedy potřeba synchronizovat přístup k nim pro zajištění atomičnosti některých operací, integrity kolekcí či pro případné zamezení několikanásobného současného vytváření instancí. Dále jsou uvedeny konkrétní případy použití v rámci aplikace webového přístupu. 5.2.4.1 Synchronizace přístupu ke kolekcím Většina sdílených dat jsou kolekce dat. Jmenujme kupříkladu kolekci manažerů připojení SGConnMan nebo kolekci povolených operací se záznamem pro jednotlivé záznamy.
52
Rozdíl mezi nimi spočívá v místě uložení. Kolekce manažerů připojení je sdílená proměnná, zatímco kolekce povolených operací je uložena v cachi. V prvém případě dojde k vytvoření kolekce pomocí tzv. statického konstruktoru, kde jsou operace z hlediska přístupu vláken bezpečné. Dále je nutné zamykat kolekci především pro zajištění integrity, aby nedošlo k současnému čtení a zápisu do kolekce. K tomu navíc je třeba mít jistotu vzhledem k lazy instantiation, že nedojde k vícenásobnému vložení do kolekce. Kód ukazuje Příklad 2: Získání aktuálního manažeru připojení. Webová cache je bezpečná z hlediska přístupu vláken, přístup je synchronizován interně, nehrozí tedy porušení integrity dat. Ovšem stále je potřeba zajistit, aby se dvě vlákna současně nepokoušela vložit do cache položku se stejným klíčem. Kolekce povolených operací tedy používá jeden zámek pro zajištění vložení právě jedné kolekce do cache a další zámek pro přidávání a odebírání položek, kde je potřeba především zajistit integritu této kolekce. /// <summary> /// Vrátí connection manager pro aktuální web (odkud přichází požadavek). /// public static SGConnMan Current { get { Guid webGuid = SPContext.Current.Web.ID; SGConnMan connMan; lock(connMans) { if(connMans.TryGetValue(webGuid, out connMan)) { // Již existuje, vrátíme. return connMan; } else { // Vytvoření a vložení nového SGConnMan. connMan = new SGConnMan(); connMans.Add(webGuid, connMan); return connMan; } } } } Příklad 2: Získání aktuálního manažeru připojení
5.2.4.2 Synchronizace přístupu ke cachovaným datům V případě cachovaných dat je hlavním důvodem synchronizace přístupu k datům výkonnost. Je potřeba vyhnout se případu, kdy několik současně přistupujících vláken nenalezne položku v cachi a všechna vlákna pak současně zahájí získávání dat ze 53
ServiceGate. Tento případ byl již probírán v kapitole 4.6.3.1. Uvedená kapitola také popisovala v cachi automaticky inicializovaný objekt sloužící jako sdílený uzamykací objekt. Metodu provádějící inicializaci tohoto objektu ve třídě BaseCacherWithLockingObject zachycuje Příklad 3: Inicializace cachovaných dat: protected void InitializeDataObject(object lockingObject) { lock(lockingObject) { // Pokus získat data z cache. dataObject = (LockingDataObject)Cache[cacheKey]; // Pokud není v cachi, vytvořit nový dataObjekt a vložit. if(dataObject == null) { dataObject = new LockingDataObject(); InsertIntoCache(); } } } Příklad 3: Inicializace cachovaných dat
LockingObject z příkladu je statická privátní proměnná konkrétní třídy DataCacher (např. RetrieveDataCacher), uvedená inicializační metoda je volaná z konstruktoru této konkrétní třídy. Metoda zajistí jedinečné vložení DataObjectu do cache, takže může být dále použit pro synchronizaci. Zámek v metodě slouží právě k zajištění jedinečnosti DataObjectu. 5.2.4.3 Synchronizace přístupu k připojení k ServiceGate Třída SGConnection zajišťující připojení k ServiceGate obsahuje metody LogOn() a LogOff() zajišťující připojení a odpojení. Je důležité, aby nedocházelo k několikanásobnému pokusu o připojení nebo odpojení. Protože proces připojování (nebo odpojování) trvá obvykle několik sekund a až po této době je znám výsledek, může operaci provádět opět pouze jedno vlákno. 5.2.4.4 Implementace synchronizace v .NET Frameworku V aplikaci byl použit výhradně nejobvyklejší typ synchronizace pomocí monitorů. Monitory jsou součástí operačního systému, .NET Framework k nim pouze zajišťuje přístup. Klíčové slovo lock zjednodušuje zápis. Monitor jako parametr vyžaduje objekt odkazového typu, tedy ne kupříkladu Integer. Tento objekt musí být přístupný všem vláknům, jejichž přístup má být synchronizován. Obecně se doporučuje použít privátní statický objekt nebo případně samotná sdílená data. Je ovšem důležité vyhnout se situaci, kdy se stejný objekt používá pro zamykání v disjunktních úlohách. To zbytečně snižuje výkonnost. Nedoporučuje se tedy používat například lock(“myLock”) nebo lock(this), protože řetězce jsou sdílené 54
v celé aplikační doméně a podobná situace může nastat pro objekt reprezentovaný this zvláště v případě, že se jedná o veřejný (public) objekt. Vedle monitorů existuje třída ReaderWriterLockSlim, která má tu výhodu, že umožňuje souběžné čtení ze sdíleného prostředku, ale exklusivní zápis. Tato třída je implementována v .NET Frameworku a vyznačuje se nižším výkonem než monitory. Doporučuje se ji používat, pokud jsou operace čtení řádově častější než operace zápisů. Zároveň bych ovšem doplnil, že nemá smysl používat ReaderWriterLockSlim pro jednoduché operace čtení z důvodu zajištění integrity dat v případě současného zápisu, protože režie vytvoření zámku ReaderWriterLockSlim je časově náročnější než zamknutí pomocí monitoru a následné načtení hodnoty z kolekce. ReaderWriterLockSlim jsem původně zvažoval pro zjištění povolených operací se záznamem, tedy přístup do kolekce slovníkového typu přes klíč, ale ze zmíněného důvodu je lepší použít obyčejný monitor. Výborným zdrojem o vícevláknových aplikacích v .NET Frameworku je [8]. 5.2.5
LINQ
LINQ (Language Integrated Query) je velmi zajímavá technologie přicházející s .NET Frameworkem 3.5. Umožňuje zpracování dat pomocí neprocedurální konstrukce podobné dotazovacímu jazyku SQL (Structured Query Language). V aplikaci byl LINQ použit pro zpracování některých dat získaných ze ServiceGate. Příklad použití LINQ pro získání pole statických relací z tabulky typu DataTable získané pomocí BrowseHelperu uvádí Příklad 4: // Statické vztahy seřazené podle sloupce pořadí. var query = from row in table.AsEnumerable() where row[COLUMN_TYPE].ToString().StartsWith(TYPE_STATIC) orderby Utils.ConvertToShort(row[COLUMN_ORDER]) select new RelationDefinition( (int)row[COLUMN_ID], row[COLUMN_NAME].ToString() ); // Převést na pole. StaticRelations = query.ToArray(); Příklad 4: Použití LINQ
Uvedený kód se nachází ve třídě RelationsData, metodě InitializeStaticRelations. Za povšimnutí stojí proměnná query, která je tzv. anonymního typu. Anonymní typy jsou však pouze
záležitostí
překladače,
ve
skutečnost
je
proměnná
query
typu
EnumerableRowCollection, což lze zjistit například s pomocí .NET Reflectoru. Uvedený příklad seřadí vybrané řádky tabulky podle sloupce definujícího pořadí a vytvoří z nich nový objekt RelationDefinition. Kolekci těchto objektů převede na pole.
55
Jak je vidět, uvedený kód velmi elegantně a přehledně provádí operaci, která by vyžadovala několik cyklů a podmínek nehledě na způsob implementace řazení. LINQ dotazy však často trvají déle než klasická implementace pomocí imperativních konstruktů, ve většině případů to nehraje vážnou roli, ale je potřeba brát to na vědomí. Hlavní síla LINQ souvisí s použitím proti databázi (LINQ to SQL) nebo XML (LINQ to XML). 5.2.6
Výkonnost
V několika předchozích kapitolách byly probrány otázky týkající se výkonnosti aplikace, především cachování, asynchronní zpracování požadavků a také implementace zámků. Vedle těchto faktorů důležitých pro zvýšení výkonnosti aplikace existuje celá řada doporučení týkajících se programátorského stylu. Výborným zdrojem je [9]. Rád bych zde upozornil na několik příkladů, na které jsem v průběhu implementace narazil. Spojování řetězců Řetězce lze spojovat dvěma způsoby, pomocí metody String.Concat, která odpovídá operátoru ‘+’, nebo pomocí třídy StringBuilder. První metoda je výhodná pro spojení předem známého počtu řetězců nebo maximálně omezeného počtu (uváděno 7 řetězců). Důvodem je fakt, že řetězec je imutabilní typ, takže při použití cyklu a prodlužování řetězce jsou stále vytvářeny nové instance. Naopak StringBuilder používá jeden objekt a znaky přidává nakonec. Opakované výpočty v iteracích Obvyklou chybou bývá opakování stejného výpočtu uvnitř cyklu. Příkladem může být použití indexované položky pole nebo kolekce. Správné je uložit potřebnou hodnotu do proměnné před tělem cyklu. Důležité je neplést si uvedenou praktiku s voláním metod. Volání metod jsou dobře optimalizovaná, takže rozdělení těla cyklu do metod nepřináší žádné zhoršení výkonu. Výjimkou je volání virtuálních metod. Sekvenční indexery Při zpracování záznamů ze ServiceGate v rámci RETRIEVE zprávy se přistupuje k jednotlivým atributům a vztahům záznamů nikoli podle číselného indexu, ale podle jejich názvu, tedy asociativního klíče. Atributy a vztahy jsou totiž párovány s uloženými definicemi v sekvenčně procházeném poli. Seznam atributů (vztahů) obsahuje indexer, tedy speciální metodu umožňující přístup k položkám na základě názvu atributu (vztahu), ovšem zde definovaný indexer vždy prochází kolekci sekvenčně, dokud nenalezne odpovídající název.
56
Protože nakonec se postupně párují všechny položky kolekce, celková asymptotická složitost uvedeného způsobu je O(n2), kde n je počet položek. Snížení této složitosti je možno vytvořením kolekce typu Dictionary (obdoba hashovací tabulky), kde přístup k položce má konstantní časovou složitost. Párování všech položek pak proběhne v asymptotickém čase O(n). Měřeními jsem zjistil, že do přibližně 25 položek lze použít i první způsob a ten je dokonce o něco rychlejší, zatímco od 25 položek výše je výhodnější druhý způsob. V Heliosu existují třídy s desítkami atributů i vztahů, využití druhé metody se tedy jeví jako odůvodněné. Používání výjimek Výjimky by měly být používány pouze ve výjimečných případech. Zpracování výjimky je z hlediska času velmi drahou operací. Pro indikace běžných stavů aplikace lépe poslouží běžné parametry a návratové hodnoty. Vlastní definované výjimky lze nalézt ve jmenném prostoru WebPartHelios.Exceptions. 5.2.7
Neimplementovaná funkcionalita
Rád bych zde upozornil na neimplementovanou funkcionalitu, která by v budoucnu mohla být dodělána. Týká se především formulářového zobrazení položek. V současné době je možné upravovat pouze atributy, vztahy a položky u záznamů dokladových tříd nemohou být upravovány. Je otázkou, jestli tato funkcionalita bude vůbec požadována, protože se nedá předpokládat, že web bude sloužit ke správě účetnictví. Implementace úpravy navázaných záznamů byla původně zamýšlena, ovšem pomocí XML zpráv se mi nepodařilo zjistit přesně třídu tedy typ navázaných vztahů v případě, že žádné vztahy nebyly navázány. Navíc v současné době aplikační server obsahuje omezení, díky kterému dokáže vrátit pouze prvních 2000 položek pořadače a klasicky pořadače definující vztahy mezi třídami obsahují mnohem více záznamů, je tedy obtížné k nim efektivně přistupovat, nelze načíst celý pořadač, ten zpracovat a cachovat, což je efektivnější řešení než se dotazovat na každý vztah. Obdobný problém nastal v případě editačních stylů, které definují, jak se datová pole záznamů zobrazují. Nejčastějším případem je definice výčtového typu. V případě úpravy záznamu obsahujícího dvacet polí výčtových typů by se muselo jednat o dvacet dotazů k ServiceGate na jednotlivé editační typy, což by značně degradovalo výkonnost aplikace. Informace o editačních stylech by v budoucnu mohly být přímo součástí odpovědi RETRIEVE zprávy, proto nebyly řešeny způsobem, který by byl zbytečně pracný.
57
5.3 Tvorba uživatelského rozhraní Uživatelské rozhraní je implementováno pomocí ASP.NET, které je založeno na používání webových ovládacích prvků. Mnoho jich je předdefinováno, prvky lze skládat do sebe a případně dědit. Většina vlastních definovaných ovládacích prvků je uložena ve jmenném prostoru WebPartHelios.Controls. 5.3.1
Webové části
Webové části WebPartHeliosGrid a WebPartHeliosItem jsou implementované jako ASP.NET webové části, tedy obě dědí z System.Web.UI.WebControls.WebParts.WebPart. Webová část je ovládací prvek, předkem o několik úrovní zpět je System.Web.UI.Control. Tento fakt je důležitý, protože jsou tak definované základní virtuální metody webové části umožňující její zobrazení. Základní použité metody webových částí uvádí Tabulka 5: Metoda
Popis
CreateChildControls()
Vytvoření ovládacích prvků webové části.
OnPreRender(EventArgs e)
Slouží ke spuštění asynchronních operací.
CreateEditorParts()
Slouží k vytvoření částí umožňujících nastavení webové části. Tabulka 5: Základní metody webových částí
První dvě metody jsou zděděné právě z třídy Control a poslední z WebPart. S OnPreRender(EventArgs e) metodou souvisí metoda, která je vyvolána po zpracování dat. Ve WebPartHeliosGrid se jedná o GetDataTaskFinished() metodu, pro WebPartHeliosItem definuje ItemPartAbstractHelper virtuální metody DataTaskFinished(), která je následně implementovaná děděnými třídami. CreateEditorParts() vrací kolekci objektů EditorPart. EditorPart definuje skupinu voleb v panelu nastavení webové části (viz Obrázek 15: Webová část WebPartHeliosGrid v režimu úprav, vpravo). Vedle metod webová část obsahuje vlastnosti (Properties), které mohou být pomocí atributů nastaveny tak, aby se jejich hodnoty ukládaly do databáze. Takové vlastnosti pak reprezentují uložená nastavení webové části. Definice funkcí ilustruje Příklad 5:
58
/// <summary> /// Definice funkcí. /// [Personalizable(PersonalizationScope.Shared), WebBrowsable(false)] public FunctionDefinition[] Functions { get { if(functions == null) functions = new FunctionDefinition[0]; return functions; } set { functions = value; } } Příklad 5: Vlastnost webové části
Uvedená vlastnost slouží k uložení funkcí, které jsou definovány nad daným pořadačem. Funkce definuje správce. Personalizable atribut značí, že se jedná o sdílené nastavení pro všechny uživatele. Pokud je WebBrowsable nastaveno na hodnotu true, bude vlastnost standardně zobrazena v panelu nastavení webové části. Pokud jsou vytvořeny vlastní EditorParts, je nežádoucí, aby se vlastnosti zobrazovaly navíc ještě výchozím způsobem. U vlastnosti také stojí za povšimnutí výchozí inicializace pole funkcí jako pole nulové délky, což je výborný trik, který umožňuje předejít chybám, kdy proměnná není nastavena na referenci objektu. Důležité je také upozornit, že ačkoli dokumentace neuvádí žádnou limitaci na typ vlastnosti kromě toho, že musí být serializovatelný pro možnost uložení do databáze, když byl místo pole použit typ SortedDictionary vlastnosti webové části buď nebyly uloženy korektně do databáze, nebo při dalším načtení webové části nebyly korektně nastaveny, zkrátka veškerá nastavení se ztratila. Je tedy potřeba použít obyčejné pole místo složitějších kolekcí.
59
5.3.1.1 EditorParts webových částí Důležitou součástí webových částí jsou EditorParts zmíněné v předchozí kapitole 5.3.1. EditorParts jsou definovány ve jmenném prostoru WebPartHelios.EditorParts, uvádí je Tabulka 6: EditorParts webových částí: Název třídy
Popis
ConnectionEditorPart
Slouží k nastavení připojení k ServiceGate.
GridSettingsEditorPart
Slouží k nastavení zobrazených prvků a povolených operací s položkou ve WebPartHeliosGrid.
ItemSettingsEditorPart
Slouží k nastavení ve WebPartHeliosItem.
FunctionsEditorPart
Slouží ke definování funkcí nad přehledem ve WebPartHeliosGrid. Tabulka 6: EditorParts webových částí
Základními částmi EditorPart je metoda CreateChildControls() pro vytvoření ovládacích prvků a pak metoda ApplyChanges() pro uložení změn do webové části z webových a naopak metoda SyncChanges() pro nastavení ovládacích prvků tak, aby odpovídaly nastaveným hodnotám ve webové části. EditorPart samozřejmě obsahuje odkaz na webovou část, kterou upravuje. Návrh panelu nastavení a EditorParts dle mého názoru obsahuje jednu chybu z uživatelského pohledu, celý panel obsahuje tlačítko Storno, ovšem po stisku probíhá validace ovládacích prvků, stejně jako při stisku tlačítka OK nebo Použít. To znamená, že pokud uživatel vyplní nějaké nevalidní údaje, nemůže je ve výchozím nastavení zrušit tlačítkem Storno, naštěstí toto lze nastavit zakázáním spouštění validace tlačítkem Storno. O to se stará funkce CancelCancelValidation() vytvořená ve všech EditorParts v řešení. Druhým drobným problémem je fakt, že po potvrzení údajů v panelu nastavení se nejprve volá metoda CreateChildControls() a až poté ApplySettings(). Důsledkem je nutnost zmáčknout tlačítko Použít dvakrát nebo obnovit stránku. Lze to také vyřešit zakázáním takzvaného ViewState ve webové části pomocí EnableViewState = false. ViewState slouží jako pomocné datové úložiště ovládacích prvků. Protože ViewState není ve webové části potřeba a jeho zakázání navíc jemně zvyšuje výkon, byl ViewState zakázán. 5.3.2
Stránky webových částí
Adresář projektu Visual Studia TEMPLATE\FEATURES\WebPartHeliosWebPartPages obsahuje dvě šablony stránek webových součástí, jednu určenou pro vložení 60
WebPartHeliosGrid, tedy zobrazení přehledu a druhou pro WebPartHeliosItem, čili formulářové zobrazení záznamu. V souboru elements.xml lze konkrétně nastavit, jaké stránky budou ze šablon vytvořeny. Důvodem je, že stránka webové části pomocí standardní předdefinované šablony neobsahuje panel rychlé spuštění, zatímco vlastní šablona pro zobrazení přehledu tento panel obsahuje. Panel je na stránce důležitý. Naopak stránka pro formulářové zobrazení položky je vytvořena tak, aby se co nejvíce podobala stránkám zobrazení položek seznamů. 5.3.3
Prvek SPGridView
Třída SPGridView definuje ovládací prvek sloužící k zobrazení přehledu, neboli gridu. Tvoří základní prvek přehledu webové části WebPartHeliosGrid. SPGridView používá vlastnost DataSource k uložení datového zdroje. Navíc musejí být definovány sloupce datového zdroje, které jsou přidány do kolekce GridViewCollumns objektu SPGridView. Celkově byly použity tři typy sloupců, které se liší způsobem zobrazení jednotlivých polí: 1) BoundField – klasické textové pole 2) TemplateField – pro vytvoření polí se zaškrtávacím tlačítkem v prvním sloupci gridu 3) SPMenuField – vytvoření vysouvacího menu pro spuštění operací s položkou Po definování sloupců a nastavení DataSource je volána metoda DataBind(), která způsobí naplnění gridu daty. V uvedeném postupu je však jeden velký problém. Standardně je požadováno naplnění kompletní množinou dat, aby správně fungovalo například stránkování. To je v tomto případě naprosto nemožné, protože přehled v Heliosu (pořadač, šablona nebo pohled) může mít desetitisíce položek, ale je zpravidla potřeba zobrazit pouze poslední stránku s nejčerstvějšími položkami. Pro obejití tohoto omezení byl vytvořen adaptér TableAdapterWithVic, který kromě samotných dat v podobě DataTable obsahuje virtuální počet položek, což je celkový počet položek gridu. Jako DataSource gridu je použit ObjectDataSource, který umožňuje napojení na TableAdapterWithVic. Výsledkem je, že je vždy načteno jen tolik položek, kolik se zobrazuje na stránce gridu a zároveň je poskytována indikace o celkovém počet položek v přehledu Heliosu. Funguje tak základní stránkování poskytované třídou SPGridView a dále je pomocí vlastního prvku BrowsePagerInfo zobrazeno, které položky z kolika celkových jsou momentálně zobrazeny. Toto řešení bylo převzato z [10].
61
5.3.4
Nástrojová lišta
Obě implementované webové části obsahují v horní části nástrojovou lištu, která je standardní součástí WSS, ovšem pro absenci jakékoli dokumentace není její použití jednoduchou záležitostí. Naštěstí lze na internetu nalézt ukázky kódů, několik zajímavých ukázek na svém blogu uvádí Paul Robinson [11].
Funkcionalitu týkající se lišty
zprostředkovává třída ToolBarHelper. Jednoduchý příklad vytvoření lišty s tlačítkem pro úpravu položky zobrazuje Příklad 6: toolBar = (ToolBar)page.LoadControl("/_controltemplates/ToolBar.ascx"); ToolBarButton toolBarButton = (ToolBarButton)page.LoadControl("/_controltemplates/ToolBarButton.ascx"); toolBarButton.Text = WebPartHeliosStrings.EditItem; toolBarButton.ImageUrl = ActionHelper.IMAGE_URL_EDIT; toolBarButton.NavigateUrl = ActionHelper.GetEditActionUrl(...); toolBar.Buttons.Controls.Add(toolBarButton); Příklad 6: Vytvoření nástrojové lišty s tlačítkem
Text tlačítka je získán z resource (viz kapitola 5.4 Lokalizace) a třída ActionHelper definuje pomocné metody právě pro vytvoření odkazů a ikon tlačítek. Za povšimnutí stojí způsob, jakým jsou ovládací prvky vytvořeny, je totiž použit soubor z disku definující tento ovládací prvek v XHTML formátu (s přidanými značkami). Oba zmíněné soubory jsou standardní soubory instalace WSS, ostatně WSS na mnoha stránkách přesně tuto lištu také využívá. Není tedy zcela pravda, že při tvorbě webových částí nelze oddělit HTML kód a aplikační logiku, ale na druhou stranu tento způsob není nikde popisován a běžně používán, proto byly všechny webové části a ovládací prvky webového přístupu programovány přímo na aplikační úrovni v jazyku C#.
62
5.3.5
Klientské skripty
Pro doplnění funkcionality bylo potřeba vytvořit několik klientských skriptů v jazyce JavaScript. Všechny skripty jsou umístěny v projektu Visual Studia WebPartHelios v souboru TEMPLATE\LAYOUTS\WebPartHelios\scripts.js. Vložení skriptů do stránky se provádí pomocí objektu typu ClientScriptManager dostupném jako Page.ClientScript. Registraci výše uvedeného souboru provádí statická metoda RegisterHeliosScriptsInclude třídy Scripts, kterou uvádí Příklad 7. Skripty jsou registrovány na základě jména a typu třídy, která je registrovala. Důvodem je jejich jednoznačná identifikace a zamezení vícenásobného vložení. /// <summary> /// Zaregistruje externí soubor skriptů pro WebPartHelios. /// /// <param name="page">Stránka, kde budou skripty registrovány. public static void RegisterHeliosScriptsInclude(Page page) { Type scriptsType = typeof(Scripts); if(!page.ClientScript.IsClientScriptIncludeRegistered(scriptsType, HELIOS_SCRIPTS_NAME)) { page.ClientScript.RegisterClientScriptInclude( typeof(Scripts), HELIOS_SCRIPTS_NAME, page.ResolveClientUrl(HELIOS_SCRIPTS_URL) ); } } Příklad 7: Registrace souboru skriptů
63
5.3.6
Application Page pro zobrazení obrázku
Některé pořadače mohou obsahovat binární data, kupříkladu obrázky ale i jiné typy souborů. Jejich zobrazení není možné implementovat jednou stránkou nebo webovou částí. Z tohoto důvodu byla vytvořena application page TEMPLATE\LAYOUTS\WebPartHelios\ file.aspx, která místo HTML kódu jako požadavek vrací soubor. Aplikační logika tohoto souboru je uložena ve třídě FilePage ve jmenném prostoru WebPartHelios.ApplicationPages. Její obsah zobrazuje Příklad 8: Stránka pro zobrazení obrázku. public class FilePage : LayoutsPageBase { protected override void OnLoad(EventArgs e) { // Získání klíče v cachi - z query stringu. string cacheKey = Request.QueryString[ActionHelper.KEY]; // Získání souboru z cache. byte[] file = (byte[])Cache[cacheKey]; // Nastavení typu souboru, pokud je známý. if(Utils.IsFileImage(file)) { Response.ContentType = "image/png"; } else if(Utils.IsFilePdf(file)) { Response.ContentType = "application/pdf"; } // Zapsání souboru do odpovědi. Response.OutputStream.Write(file, 0, file.Length); } } Příklad 8: Stránka pro zobrazení obrázku
Stránka dědí z LayoutsPageBase, to je požadavek na libovolnou application page. Soubor, který bude zobrazen, je uložen v cachi, klíč této položky v cachi je stránce předán jako parametr query stringu. Po získání souboru z cache je zapsán do výstupního proudu odpovědi. Protože data získaná ze ServiceGate nemají žádné označení typu, v současné době stránka umožňuje detekci typu obrázku ve formátu png, ve kterém jsou standardně obrázky ukládány v Heliosu, a pdf souboru. Detekce je provedena pomocí načtení začátku souboru, kde je typ definovaný, to ovšem neplatí obecně u všech formátů.
64
5.4 Lokalizace Jazyk prostředí aplikace ve WSS je dán jazykovou verzí webu, tedy nejčastěji šablonou, ze které byl web vytvořen. WSS existuje v mnoha jazykových variantách a navíc je možno stáhnout jazykové balíčky obsahující základní šablony. Na jednom serveru lze tedy provozovat weby v různých jazycích. SharePoint Server 2007 na rozdíl od WSS obsahuje pokročilejší podporu pomocí tzv. Variations (více [12 stránky 249 - 252]). Samotná lokalizace webových částí probíhá stejným způsobem jako lokalizace jakékoli aplikace vytvořené na platformě .NET, alespoň v případě použití standardního způsobu lokalizace pomocí tzv. Resources. Princip spočívá právě ve vytvoření těchto Resources souborů, v případě této aplikace WebPartHeliosStrings.resx a WebPartHeliosStrings.en.resx. Prvně uvedený soubor definuje neutrální jazykovou variantu, obvykle v anglickém jazyce, zde ovšem vzhledem k faktu, že Helios je český ERP systém a čeština je primární jazyk, byla zvolena čeština jako neutrální jazyk. Druhý soubor definuje anglickou jazykovou variantu. Lze vytvořit další jazykové varianty, kde název souboru místo ‘en’ obsahuje definované kódy jazyků. Resource soubor uvnitř definuje jednoduchou třísloupcovou tabulku se sloupci Name (název), Value (hodnota) a Comment (komentář). Název je řetězec indexující položku. Hodnota je v případě lokalizace také řetězec, ovšem obecně se může jednat téměř o libovolný obsah včetně obrázku nebo zvukového záznamu. Visual Studio automaticky generuje přístupové metody k položkám resource souboru. V našem případě jsou tedy ve jmenném prostoru WebPartHelios.Resources definovány statické vlastnosti odpovídající názvům řádků. Vedle této možnosti lze obecně k textovému obsahu přistupovat pomocí ResourceManageru (taktéž staticky vygenerovaného k danému resource) a jeho metody GetString. Při požadování obsahu resource je použita lokalizovaná hodnota na základě nastavené hodnoty Thread.CurrentThread.CurrentUICulture. Tato hodnota je nastavena automaticky na základě jazyka webu. Jediný drobný problém nastane v situaci, kdy se načítá resource z asynchronního kontextu. Vlákna application poolu totiž mohou mít nastavený zcela odlišný jazyk. Pro zajištění načtení správného jazyka je potřeba uložit jazykové nastavení webové části a v asynchronním kontextu explicitně nastavit na základě uložené hodnoty.
65
5.5 Dokumentace Nezbytnou součástí každé rozsáhlejší aplikace je dokumentace tříd, metod, delegátů a dalších částí programového kódu, v opačném případě bude téměř nemožné aplikaci v budoucnu rozšířit nebo nalézt chybu. Pro jazyk C# (i pro jiné jazyky .NET Frameworku) je definovaný formát dokumentace pomocí XML přímo v kódu. Visual Studio obsahuje podporu této dokumentace, při psaní kódu zobrazuje kontextovou nápovědu prvků kódu. Navíc lze při překladu nechat vygenerovat jeden XML soubor obsahující dokumentaci všech prvků kódu, ze kterého lze externími nástroji vygenerovat dokumentaci například v HTML formátu. V současné době lze doporučit především Microsoftem podporovaný zdarma dostupný program Sandcastle. Ukázku použití XML dokumentace kódu ilustruje Příklad 9. Obsahuje hlavičku statické metody sloužící k zašifrování pole bytů pomocí algoritmu Rijndael (neboli také AES – Advanced Encryption Standard). Vedle XML dokumentace lze samozřejmě psát klasické komentáře uvnitř kódu. Pro usnadnění generování XML hlaviček doporučuji zdarma dostupný doplněk pro Visual Studio GhostDoc, kromě vygenerování XML kódu doplní také návrhy textů v anglickém jazyce, případně u virtuálních metod vkládá dokumentaci z původní metody. /// <summary> /// Zašifruje pole bytů do pole bytů pomocí klíče a iniciačního vektoru. /// /// <param name="clearData">Data k zašifrování. /// <param name="key">Klíč. /// <param name="iv">Iniciační vektor. /// Zašifrovaná data. public static byte[] Encrypt(byte[] clearData, byte[] key, byte[] iv) { // Inicializace algoritmu. Rijndael alg = Rijndael.Create(); alg.Key = key; alg.IV = iv; ... } Příklad 9: XML dokumentace kódu
66
6
Testování
6.1 Testování implementace V průběhu implementace webového přístupu byly jednotlivé naprogramované části neustále podrobovány testům. Vzhledem k charakteru aplikace, nelze bohužel napsat unit testy stejně snadno jako v případě implementace knihovny. Testování tedy probíhalo ve dvou krocích, nejprve black-box větších celků a v případě nalezení chyby se provádělo krokování menších částí, dokud nebyla nalezena chyba. Visual Studio poskytuje sofistikované nástroje značně usnadňující tuto úlohu. Samotnou komunikaci se ServiceGate prostřednictvím XML zpráv bylo možné testovat zcela nezávisle pomocí vytvořené aplikace ConnectorTest. Jedná se o desktop aplikaci, která umožní generovat základní typy zpráv (RETRIEVE, BROWSE) a získávat odpovědi ze serveru. Je také možno zadat zprávu přímo v XML formátu. Verifikace správné funkčnosti datové vrstvy probíhala skrze webové rozhraní. Účelem byla správná funkčnost zobrazení a editace různých validních dat. Častými chybami je opomenutí ošetření prázdného vstupu, tedy například předpoklad, že získaný záznam má definovaný alespoň jeden vztah. Chyby tohoto typu byly ošetřeny inicializací polí nulové délky místo testování proměnných, jestli nemají hodnotu null. Důležitou součástí bylo taky správné odchycení výjimek a srozumitelné vypsání chybového stavu, typicky v předpokládatelných situacích jako například výpadku síťového spojení.
67
6.2 Výkonnostní testování Výkonnost aplikace je základním požadavkem, protože lze předpokládat, že uživatelé od webové aplikace očekávají okamžitou odezvu a ne prodlevu desítky sekund. 6.2.1
Síťové schéma testování
Testována byla výkonnost webového rozhraní pomocí Visual Studia 2005 Team Tester, což je verze umožňující definovat a spouštět různé testy. Obrázek 28 zachycuje síťové
Internet
VPN
schéma testu.
Klientský počítač s testovacím programem
Webový server s WSS 3.0 w2008sql.lcs.cz
Aplikační server Helios open.lcs.cz
Databáze Heliosu Demo42
Obrázek 28: Síťové schéma testu
V horní části obrázku je počítač používaný ke vzdálenému připojení k serverům ve firmě LCS skrze internet a VPN. V dolní části jsou počítače umístěné v LCS, které jsou klasicky připojeny k místní gigabitové ethernetové síti. Nalevo je počítač s nainstalovaným testovacím prostředím, který testuje webový server s WSS. Webový server se připojuje k aplikačnímu serveru Helios open.lcs.cz, který umožňuje přístup k Demo42 databázi. Samotné propojení mezi aplikačním serverem a databázovým není důležité, databáze může běžet i na tom samém počítači, obrázek je pouze ilustrativní. Důležitá volba je typ komunikace mezi webovým a aplikačním serverem, zde bylo zvolen protokol http, protože se jedná o místní síť.
68
Tabulka 7 uvádí hardwarovou a softwarovou konfiguraci testovacího počítače a webového serveru. Znalost konfigurace aplikačního a databázového serveru Heliosu není potřebná, ty se netestují. Klientský počítač s testovacím programem
Webový server
Procesor
Intel Pentium 4 3 GHz
Intel Xeon X5450 3 GHz
Operační paměť
1,5 GB
1 GB
Pevný disk
Western Digital 80GB, 7200 RPM
16 GB Virtual ATA disk
Operační systém
Windows Server 2003 SP2 32 bit
Windows Server 2008 Enterprise 32 bit
Další software
Visual Studio 2005 Team Tester
IIS7, WSS 3.0
Tabulka 7: Konfigurace testovacího počítače a webového serveru
6.2.2
Průběh testování
Pro testování zatížení serveru je potřeba vytvořit dva testy: 1) Webový test 2) Zátěžový test Webový test definuje sled požadavků na webový server. V případě testování webového přístupu k Heliosu bylo definováno několik stránek každá zobrazující jiný přehled pomocí WebPartHeliosGrid, jedna stránka pro zobrazení položky s WebPartHeliosItem nad nimi byl definován sled operací zobrazujících různé stránky přehledů a jednotlivé položky. Test uvažoval pouze operace zobrazení, protože se předpokládá, že ve webovém prostředí budou výrazně převažovat nad úpravami položek a také, protože implementace uložení položky pomocí automatizovaného testu je komplikovaná, nestačí pouhý GET požadavek. Kroků testu, tedy požadavků bylo celkově definováno 33. Zátěžový test používá webový test pro definice akcí prováděné jedním uživatelem. Navíc je třeba definovat počet uživatelů. Počet uživatelů se postupně zvyšoval počítaje pěti uživateli a v každém kroku bylo přidáno dalších deset uživatelů. Měřeny byly tyto základní parametry: 1) User Load (počet uživatelů) 2) Requests/sec (požadavků za 1 s) 3) Avg. Response Time (průměrná doba odpovědi) 4) Requests Queued (počet požadavků uložených do fronty)
69
Počet uživatelů je vlastně zadaný parametr, na kterém ostatní parametry závisí. Závislosti mezi parametry a jejich analýzou se zabývá např. [13], obdobný byl postup v rámci tohoto testování. Počet požadavků běžně roste s počtem uživatelů, až do určité míry, kdy je dosaženo limitu propustnosti. Průměrná doba odpovědi je naopak konstantní a při určitém počtu uživatelů začíná prudce růst. Konečně poslední parametr je vlastně zrcadlem k prvnímu parametru, při určitém počtu uživatelů je stále více požadavků ukládáno do fronty, a proto se snižuje počet průchozích požadavků. To platí samozřejmě za předpokladu, že úzkým hrdlem je webový server a nikoli samotné síťové rozhraní, což předpokládáme. 6.2.3
Výsledky testování
Test byl celkově spuštěn třikrát bez použití cache a třikrát s použitím cache. Výsledky těchto trojic testů byly velmi obdobné. Jako první uvádím výsledky zátěžového testu bez použití cache, jak ilustruje Obrázek 29:
Obrázek 29: Graf zátěžového testu bez použití cache
Z grafu je patrné, že okolo času testu 01:15, což odpovídá zátěži 75 uživatelů, přestává růst počet požadavků za sekundu a požadavky se začínají ukládat do fronty. Čas odpovědi začíná růst. Zvláštní je, že čas odpovědi neroste stále, což si vysvětluji tím, že v případě 70
přetížení nejsou další připojení představující uživatele ve skutečnosti vytvořeny. Ostatně pokud je test spuštěn pro 20 000 uživatelů, časy odpovědi stále zůstávají v řádech sekund, přitom v praxi by se uživatel nejspíš odpovědi vůbec nedočkal. Obrázek 30 zobrazuje výsledky téhož testu při použití cache:
Obrázek 30: Graf zátěžového test s použitím cache
Při použití cache se limit na počet uživatelů webového serveru nachází někde v rozmezí časů 02:00 a 02:30, což odpovídá 115 až 145 uživatelům. Je tedy patrné zlepšení oproti případu bez použití cache, ovšem není příliš výrazné. Na druhou stranu lze předpokládat, že limit 75 uživatelů v případě bez použití cache je ve skutečnosti limitem aplikačního a potažmo databázového serveru Heliosu. Naopak zde se jedná čistě o limit webového serveru. Parametry webového serveru se zdají být více než dostatečné, ovšem server běží virtualizovaně, což zřejmě nepříznivě ovlivňuje jeho výkon. Například instalace celého pomocí souboru setup.bat na mém počítači (Pentium M 1,6 GHz, 1,5 GB RAM, 160 GB 2,5’’ disk s 5400 otáčkami) trvala 22 sekund, zatímco na webovém serveru 3 minuty. Na tyto údaje lze nahlížet jako na výsledky aplikačního testu. Nasazení výkonnějšího serveru tedy zcela jistě umožní přístup více než zjištěných 115 – 145 uživatelů, bylo dokázáno, že aplikační server díky cachování již není úzkým hrdlem systému.
71
7
Porovnání webového přístupu s klasickým klientem Porovnání se zaměřuje na rozdíly ve funkcionalitě obou klientů a následuje shrnutí
předností a nevýhod webového přístupu.
7.1 Výběr dat pro zobrazení Zásadním rozdílem je způsob použití webového přístupu oproti klasickému klientu. V klasickém klientu si uživatel může zvolit jaká data zobrazit, zatímco u webového přístupu správce sestaví množinu stránek, kde každá stránka zobrazuje správcem definovaný přehled či záznamy z určeného seznamu.
7.2 Operace s daty Podobně jako u specifikace dat, která klient může zobrazit, správce webu určuje, jaké operace budou s kterými daty povoleny, tedy kde lze přidávat, upravovat nebo mazat záznamy. Obdobným způsobem jsou definovány jen konkrétní funkce, které uživatel může spouštět a nikoli všechny funkce definované pro záznamy. Ostatně některé funkce by ani neměly ve webovém rozhraní význam. 7.2.1
Vynechané funkce a zjednodušené funkce
Filtrování přehledu, řazení přehledu podle sloupce Tyto funkce byly vynechány z důvodu výkonnosti aplikace, protože se jedná o náročné operace, které obecně potřebují data získat z aplikačního respektive databázového serveru a výkonnost webové aplikace je důležitější kritérium. Úprava záznamu U záznamů je podporována pouze úprava jejich atributů, podpora úpravy položek u dokladových tříd a záznamů navázaných pomocí vztahů není obsažena. Důvody jsou dva: 1) Jedná se o funkcionalitu, kterou ve webovém prostředí použije málo uživatelů, základem je zobrazení dat. 2) Omezení ServiceGate rozhraní vytváří několik překážek v jednoduché implementaci, rozebrána byla v kapitole 5.2.7.
72
Styly polí při úpravě záznamů Pole záznamů mohou mít různý formát. V současné době jsou podporovány pouze některé základní formáty. Editační styly umožňují definovat výčtové typy, které nebyly implementovány z technických důvodů popsaných v kapitole 5.2.7. Zobrazení kategorií Záznamy mohou mít definované kategorie. Jako nepříliš podstatná funkce nebyly kategorie implementovány. Tiskové funkce Tiskové funkce byly vynechány, protože webové rozhraní používá zcela jiný styl zobrazení a tisk je možné provádět přímo z prohlížeče. Výběr či vytvoření filtru, šablony, pohledu Obdobně jako samotný výběr dat, která budou zobrazena, nemají uživatelé přístup k výběr filtrů, šablon a pohledů.
73
7.3 Přednosti webového přístupu Webový přístup umožňuje propojení s jinou aplikací Webový portál může obsahovat další funkcionalitu kromě přístupu k datům z Heliosu. Naopak klasický klient nelze snadno přizpůsobit. Webový přístup poskytuje vyšší výkonnost Vyšší výkonnost je dána cachováním dat ve webovém přístupu. Webový přístup je škálovatelná aplikace Aplikace je škálovatelná na rozdíl od aplikačního serveru (alespoň v současné době). Lze vytvářet farmu webových serverů, což umožní připojit více uživatelů. Webové stránky mohou být vzhledově přizpůsobeny Na rozdíl od klasického klienta je možné na webový portál aplikovat motivy či případně editovat přímo konkrétní webovou stránku. Klasický klient vypadá vždy stejně. Webový přístup umožňuje přesně specifikovat, co uživatelé mohou dělat Díky webovému přístupu je možné umožnit přístup k datům Heliosu i uživatelům, kterým by jinak nebylo dovoleno používat klasického klienta nebo spíše by ani neměli zájem klasického klienta instalovat a používat. Webový přístup umožňuje snadné a rychlé nasazení Pomineme-li samotnou instalaci a konfiguraci SharePointu a aplikace, vytvoření stránky, vložení a nakonfigurování webové části za účelem a poskytnutí zobrazení pořadače je velmi rychlá operace. Webový přístup je dostupný odkudkoli Klasický klient může být použit pouze na počítači, kde je instalován, naopak webový přístupu lze teoreticky přistupovat odkudkoli.
7.4 Nevýhody webového přístupu Webový přístup neobsahuje kompletní funkcionalitu klasického klienta Otázkou je, jestli bude neobsažená funkcionalita postrádána. Je potřeba webový správce, který nastaví webové stránky Opět se jedná o vlastnost systému, která se může jevit jako výhoda, či nevýhoda. Vzhledem ke způsobu použití na webových stránkách se jedná spíše o výhodu.
74
8
Závěr Cílem této práce byl návrh a implementace webového přístupu k ERP systému Helios. Po podrobném seznámení se se systémem Helios, který popisují kapitoly 4.1 a 4.2 byly
analyzovány funkční i nefunkční požadavky na webový přístup a shrnuty v kapitole 4.3. Následovně proběhlo seznámení se s technologií Windows SharePoint Services (WSS), která byla zvoleny jako platforma pro implementaci webového přístupu. Následovně bylo navrženo uživatelské rozhraní ve WSS (kapitola 4.5), které vychází ze standardně používaného rozhraní WSS a sestává z webových částí umožňujících zobrazovat a upravovat data ze systému Helios. Zároveň byl v kapitole 4.6 navržen způsob komunikace mezi webovým rozhraním a systémem Helios na základě definované webové služby a dále způsob jakým dosáhnout maximálního výkonu webové aplikace používající cachování dat na webovém serveru. Jako důležitá součást webové aplikace byla v kapitole 4.7 rozebrána bezpečnost z několika úhlů pohled a navržen způsob, jakým uživateli zabránit v pokusu o neautorizovaný přístup k datům využívající podvržení webové adresy. Poté proběhla implementace aplikace, jejíž důležité, problematické nebo jinak zajímavé části jsou popsány v kapitole 5. Důležitou součástí této kapitoly je diskutování způsobů zvýšení výkonnosti aplikace využívající implementačních záležitostí zvolené platformy webového serveru a WSS. Důležitou součástí bylo otestování výkonnosti webového přístupu, které prokázalo, že aplikace díky výkonnostním optimalizacím umožňuje přístup vyššího počtu uživatelů a stává se lépe škálovatelnou, protože aplikační server Helios již není úzkým hrdlem systému. Zmiňované testování popisuje kapitola 6. V kapitole 7 byla na závěr porovnána funkcionalita původního klasického rozhraní s nově implementovaným webovým. Co se týče nasazení v praxi, jsem si jist, že aplikace nalezne uplatnění, protože doposud žádné podobné řešení pro systém Helios neexistovalo a propojení webových systémů s rozsáhlými ERP systémy je v dnešní době velmi žádané. Aplikace webového přístupu umožňuje snadné a rychlé nasazení, jednoduchou upravitelnost díky implementaci pomocí modulárních
webových
částí.
Zároveň
dostatečně
pokrývá
základní
potřebnou
funkcionalitu. Aplikaci včetně zdrojových kódů a demonstračního videa lze nalézt na přiloženém CD (Příloha C).
75
9
Bibliografie
[1] LCS International, a.s. Helios. [Online] 2009. http://www.helios.eu. [2] —. Helios Green - Wiki fórum. [Online] 2009. [3] Microsoft Corporation. MSDN library. [Online] 2009. http://msdn.microsoft.com/enus/library/default.aspx. [4] Prosise, Jeff. Programming Microsoft.NET. Redmond : Microsoft Press, 2002. [5] Pattison, Ted a Larson, Daniel. Inside Microsoft Windows SharePoint Services 3.0. Redmond : Microsoft Press, 2007. [6] Dohnal, Marek. Hotelový systém – uživatelské rozhraní, bakalářská práce. Praha : ČVUT FEL, 2006. [7] Dvořák, Miloš. Návrhové vzory (design paterns), diplomová práce. [Online] 2003. http://objekty.vse.cz/Objekty/Vzory. [8] Albahari, Joseph. Threading in C#. Joseph Albahari. [Online] 1. 12 2007. http://www.albahari.com/threading. [9] Meier, J.D., a další. Improving .NET Application Performance and Scalability. [Online] 2004. http://msdn.microsoft.com/en-us/library/ms998530.aspx. [10] Erwin-ODS. Custom Paging and the GridView ASP.NET 2.0. The Code Project. [Online] 2007. http://www.codeproject.com/KB/aspnet/Custom_Paging_GridView.aspx. [11] Robinson, Paul. Powlo's SharePoint Treats. [Online] 2009. http://blogs.msdn.com/powlo/default.aspx. [12] Tisseghem, Patrick. Inside Microsoft Office SharePoint Server 2007. Redmond : Microsoft Press, 2007. [13] Microsoft Corporation. Chapter 16 — Testing .NET Application Performance. MSDN Library. [Online] 2009. http://msdn.microsoft.com/enus/library/ms998581.aspx#scalenetchapt16_topic15. [14] Gerow, Mark E. SharePoint 2007 Development Recipes. Berkeley : Apress, 2008. [15] Williams, Rob. Multi-Threading in ASP.NET. The Async Assassin. [Online] 2009. http://www.asyncassassin.com/asyncassassin/post/Multi-Threading-in-ASPNET.aspx. [16] Microsoft Corporation. Design and Implementation Guidelines for Web Clients. [Online] 2003. http://msdn.microsoft.com/en-us/library/ms978631.aspx.
76
A. Instalační příručka A.1 Instalace Windows SharePoint Services 3.0 A.1.1 Instalační balíčky Pro instalaci WSS 3.0 je nezbytné stáhnout a nainstalovat Službu Windows SharePoint Services
3.0
s
aktualizací
Service
Pack
2.
Lze
ji
získat
na
adrese
http://www.microsoft.com/downloads/details.aspx?displaylang=cs&FamilyID=ef93e453-75f145df-8c6f-4565e8549c2a. Alternativou může být jiná jazyková verze, či případně x64 verze pro 64bitové procesory. Jiný jazyk lze nainstalovat i dodatečně pomocí tzv. Windows SharePoint
Services
3.0
Language
Pack
(anglická
verze
je
dostupná
na
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=36ee1bf0-652c4e38-b247-f29b3eefa048). Tento balíček nainstaluje základní šablony ve zvoleném jazyce, lze tedy vytvořit například anglický týmový web. A.1.2 Průběh instalace Během instalace je potřeba zvolit, zdali instalovat tzv. Windows Internal Database nebo jestli použít stávající instanci Microsoft SQL Serveru. Po ukončení instalace je spuštěn Průvodce konfigurací SharePoint, který provede konfigurace databáze. Je potřeba rozumět pojmům jako farma webů, ale jinak je konfigurační průvodce jednoduchý a intuitivní.
77
A.1.3 Dokončení instalace Po ukončení instalace a konfigurace je automaticky vytvořen top-level týmový web, který zachycuje Obrázek 31: Týmový web:
Obrázek 31: Týmový web
Po přihlášení se k webu jako Administrátor se v pravé horní části základní stránky (označené číslem 1) objeví menu Akce webu s položkami Vytvořit, Upravit stránku a Nastavení webu. Pomocí nabídky Vytvořit lze přidávat seznamy, typy obsahu, webové stránky, stránky webových částí a také vytvářet nové weby a pracovní prostory, tedy podřízené weby v hierarchii webů. Nabídka Upravit stránku se týká vždy konkrétní stránky (4) a Nastavení webu obsahuje širokou paletu možností nastavení daného webu i kolekce webů. Lze například nastavit motiv webu a upravovat obsah horního (Horní panel odkazů, 2). a levého (panel Snadné spuštění, 3) navigačního menu.
78
Obrázek 32: Centrální správa serveru SharePoint 3.0
Kromě top-level webu je automaticky vytvořena ještě tzv. Centrální správa serveru SharePoint 3.0, kde je možno vytvářet databáze obsahu, webové aplikace, kolekce webů, spravovat webovou farmu a provádět další nastavení například týkající se zabezpečení. Centrální správu zobrazuje Obrázek 32. A.1.4 Povolení anonymního přístupu Jednou z možných úloh spojených se zobrazením stránek je povolení anonymního přístupu. Ten lze nastavit pro konkrétní web v Nastavení webu ve skupině Uživatelé a oprávnění a položce Rozšířená oprávnění. Zde se v menu Nastavení nachází položka Anonymní přístup. Pokud se zde tato položka nenachází, je potřeba Centrální správě ve Správě aplikací pod Zprostředkovateli ověřování (viz Obrázek 32: Centrální správa serveru SharePoint 3.0) pro požadovanou aplikaci a zónu zaškrtnout tlačítko Povolit anonymní přístup. Anonymní ověřování musí být navíc nastaveno na samotném webovém serveru pro daný web (v IIS 7.0 Daný web > Ověřování > Anonymní ověření > Povolit). 79
A.2 Instalace webových částí Vytvořený balíček pro instalaci webových částí je součástí projektu Visual Studia 2008 WebPartHelios. V adresáři bin\Debug resp. bin\Release se nachází soubor setup, který je klíčový pro celou instalaci. Spouštěním setup.bat s přepínačem /i dojde k nainstalování webových částí do základní kolekce webů na serveru, tedy do http://localhost. K nainstalování do jiné nebo kolekce webů nebo webu použijte přepínače /siteurl resp. /weburl. K odinstalování slouží přepínač /u. Soubor setup.bat je třeba spouštět s administrátorskými oprávněními. Pro korektní funkčnost webových částí je navíc třeba do web.config konfiguračního souboru webové aplikace do sekce system.web/compilation/assemblies přidat:
Webové části používají navíc některé obrázky a skripty, které je třeba zkopírovat do C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE (standardní umístění). Ve stejném adresáři, kde se nachází adresář bin, z něhož jsme instalovali webové části, je také adresář TEMPLATE, jehož obsah je potřeba zkopírovat do výše zmíněného TEMPLATE adresáře. Druhou možností je spuštění Dll+TemplateDeploy.bat ve stejném adresáři jako TEMPLATE a bin adresář. Opět budou vyžadována administrátorská práva a také je potřeba se podívat, jestli není třeba upravit cesty v tomto dávkovém souboru.
A.3 Přidání webových částí na stránku Pro přidání webových částí na stránku je potřeba zvolit stránku webových částí. Následně po kliknutí na ‚Přidat webovou část‘ vyberte WebPartHeliosGrid nebo WebPartHeliosItem. Panel nastavení webové části v levé straně kromě standardních skupin obsahuje speciální skupiny, jejichž popis se zobrazí v bublinové nápovědě po najetí myší na prvek. Pro propojení webových částí je třeba nastavit ve webové části WebPartHeliosGrid v položce ‚URL práce se záznamem‘ adresu propojené webové části a níže zaškrtnout operace, které bude možné se záznamem provádět.
80
B. Příručka vývoje webových částí ve Visual Studiu 2008 Pro usnadnění vývoje webových částí i dalších prvků SharePointu ve Visual Studiu je vhodné nainstalovat Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version
1.2.
(http://www.microsoft.com/downloads/details.aspx?FamilyID=7bf65b28-
06e2-4e87-9bad-086e32185e68&displaylang=en). Tento instalační balíček také nainstaluje WSS 3.0 SDK včetně dokumentace. Nástroje pro Visual Studio obsahují různé šablony pro vývoj SharePoint komponent, nejzajímavější je šablona pro webovou část. Po kompilaci řešení je vytvořen balíček a také soubor setup.bat sloužící pro instalaci balíčku, která sestává z mnoha kroků, které je běžně třeba provádět ručně. Přes všechna usnadnění, která WSS Tools přinášejí, je zde několik drobných úskalí týkajících se především deploymentu a krokování (debugging).
B.1 Deployment webové části Deployment webové části resp. celého řešení kromě ručního spuštění souboru setup.bat lze provést rychleji volbou Deploy Solution v menu Build. Obě uvedená řešení však celé řešení nejprve odinstalují a pak znovu nainstalují. Vše končí restartem application poolu (fond aplikací) dané aplikace. Při vývoji často potřebujeme pouze znovu publikovat dll knihovnu obsahující řešení do GAC (Global Assembly Cache) a restartovat application pool. Ve vytvořeném projektu WebPartHelios lze nalézt soubor Dll+TemplateDeploy.bat, který se stará právě o toto. Navíc kopíruje obsah TEMPLATE adresáře do TEMPLATE adresáře serveru kvůli deployment application pages, obrázků a skriptů.
B.2 Debugging webové části Debugging webové části se skládá ze tří částí: 1) Potřebná nastavení ve web.configu. 2) Potřebná nastavení přímo webového serveru. 3) Nastavení ve Visual Studiu B.2.1
Nastavení web.configu
Základní potřebná nastavení jsou uvedena v [5 str. 54]. Zde je výčet: Do sekce SharePoint v elementu SafeMode nastavit parametr CallStack="true" 81
Do sekce systém.web přidat nebo upravit: o o <customErrors mode="Off" /> o B.2.2
Nastavení webového serveru
Ve nastavení webového serveru je potřeba zakázat příkaz ping nebo alespoň nastavit delší prodlevu příkazu ping, jinak po výchozí době 30 s bude krokování na webovém serveru ukončeno. Provádí se v: Daný webový server > Fondy aplikací (Application Pool) > SharePoint – 80 > Upřesnit nastavení > Model procesu > Povolený příkaz ping > False. B.2.3
Nastavení ve Visual Studiu
Ve Visual Studiu pro podporu krokování není potřeba nic speciálně nastavovat. Existují dvě cesty, jak spustit krokování: 1) Pomocí klávesy Debug > Start Debugging (klávesa F5) Tato metoda má nevýhodu, protože dlouho trvá. Provede se totiž nejprve kompletní deployment řešení tedy včetně odebrání, znovupřidání a restartu application poolu. Poté se otevře webový prohlížeč. Je vhodné nastavit požadovanou adresu, aby se prohlížeč otevíral na stránce obsahující webovou část, kterou chceme krokovat. Musím upozornit, že pokud je již otevřená jiná instance Internet Exploreru, stává se, že krokování spadne. 2) Pomocí Debug > Attach to Process Uvedenou metodu lze použít univerzálně. Například pokud webová část nebyla upravena a webový server běží, je značně rychlejší, protože restartovat application pool není třeba. Při použití této volby se vybere proces w3wp.exe, zpravidla se jedná o poslední v seznamu. V případě potřeby krokovat například event handler (event receiver) je obvykle nutné využít druhé metody a také do GAC k dll knihovně zkopírovat pdb soubor z bin\debug. Zkopírování souboru je možné speciální cesty [MachineName]\C$\WINDOWS\assembly nebo pomocí jiného správce souborů než Průzkumníka jako například Total Commanderu.
82
C. Obsah přiloženého CD Kořenový adresář obsahuje soubor index.html, který odkazuje na jednotlivé části CD a popisuje jejich obsah. \demo \doc \WebPartHelios – html \WebPartHelios.chm \install \sources \src+bin \ConnectorTest \Lcs.ServiceGateAdapter \ WebPartHelios \text
– demonstrační video – dokumentace – dokumentace ve formátu html – dokumentace jako zkompilovaná html nápověda – instalační soubory některých nástrojů – volně dostupné odkazované elektronické zdroje – zdrojové kódy a kompilovaná řešení – aplikace testující přístup k ServiceGate – ServiceGateAdapter – hlavní řešení webového přístupu – text diplomové práce (pdf, docx, doc)
83
