ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická
BAKALÁŘSKÁ PRÁCE 2013
Martin Adámek
České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářská práce
Administrační sekce aukčního portálu Nume.cz Martin Adámek
Vedoucí práce: Ing. Martin Klíma, Ph.D. Studijní program: Otevřená informatika, strukturovaný Obor: Softwarové systémy 23. května 2013
Poděkování Děkuji všem, kteří mě podporovali při vytváření této práce, především pak vedoucímu práce, panu Ing. Martinu Klímovi, Ph.D. za poskytnuté rady a pomoc a mým rodičům za podporu po celou dobu mého studia.
Čestné prohlášení Prohlašuji, že jsem 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 23. 5. 2013 ………………..……………………
Abstract This bachelor thesis deals with the analyses and improvement of administration section of web-based auction portal Nume.cz focused on numismatics. This portal is programmed in PHP using Nette Framework and MySQL database. Thesis is also focused on selection of tool for reporting and data analysis for portal Nume.cz and its deployment in existing application.
Abstrakt Tato bakalářská práce se zabývá analýzou a zdokonalováním administrační sekce webového aukčního portálu Nume.cz zaměřeného na numismatiku. Tento portál je naprogramován v jazyce PHP za pomoci frameworku Nette a využívá databázi MySQL. Práce se dále zabývá výběrem nástroje pro reporting a analýzu dat na portálu Nume.cz a jeho nasazením do stávající aplikace.
Obsah KAPITOLA 1 ÚVOD ....................................................................................................................................... 1 1.1 MOTIVACE ................................................................................................................................................................ 1 1.1.1 Scénáře použití ................................................................................................................................................. 2 KAPITOLA 2 ANALÝZA STÁVAJÍCÍHO STAVU ...................................................................................... 3 2.1 AUKČNÍ PORTÁL NUME.CZ ..................................................................................................................................... 3 2.1.1 Funkce portálu ................................................................................................................................................. 3 2.1.2 PHP ........................................................................................................................................................................ 4 2.1.3 Framework Nette ............................................................................................................................................ 4 2.1.4 Databáze ............................................................................................................................................................. 7 2.1.5 Překladač ............................................................................................................................................................ 8 2.1.6 Stavový automat .............................................................................................................................................. 8 2.1.7 Udržování stavu aukcí pomocí CRONu .................................................................................................. 9 2.2 NÁSTROJE PRO ANALÝZU DAT A REPORTING ...................................................................................................... 9 2.2.1 Požadavky .......................................................................................................................................................... 9 2.2.2 Zkoumané nástroje ...................................................................................................................................... 10 2.3 ANALÝZA UŽIVATELSKÝCH ROLÍ ........................................................................................................................ 17 2.4 POŽADAVKY NA ŘEŠENÍ ....................................................................................................................................... 18 2.4.1 Funkční ............................................................................................................................................................. 18 2.4.2 Nefunkční ......................................................................................................................................................... 18 KAPITOLA 3 NÁVRH ŘEŠENÍ .................................................................................................................. 19 3.1 VÝBĚR NÁSTROJE PRO REPORTING A ANALÝZU DAT ...................................................................................... 19 3.2 AUKČNÍ PORTÁL NUME.CZ .................................................................................................................................. 20 3.2.1 Nasazení serverové komponenty pro tvorbu reportů .................................................................. 20 3.2.2 Report Manager ............................................................................................................................................ 20 3.2.3 Historie ............................................................................................................................................................. 22 3.2.4 Logování ........................................................................................................................................................... 22 KAPITOLA 4 IMPLEMENTACE ............................................................................................................... 23 4.1 AUKČNÍ PORTÁL NUME.CZ .................................................................................................................................. 23 4.1.1 CRON komponenta ...................................................................................................................................... 24 4.2 INSTALACE SERVEROVÉ KOMPONENTY ............................................................................................................ 25 4.3 REPORT VYÚČTOVÁNÍ SLUŽEB ........................................................................................................................... 26 KAPITOLA 5 TESTOVÁNÍ ........................................................................................................................ 27 5.1 NETTE TESTER ..................................................................................................................................................... 28 5.1.1 Test jako skript .............................................................................................................................................. 28 5.1.2 Testování presenterů .................................................................................................................................. 28 5.1.3 Hromadné spouštění testů a pokrytí kódu ........................................................................................ 29 KAPITOLA 6 ZÁVĚR .................................................................................................................................. 31 REFERENCE .................................................................................................................................................... 33 SEZNAM OBRÁZKŮ ...................................................................................................................................... 37 PŘÍLOHA A. OBSAH PŘILOŽENÉHO CD ............................................................................................... 39 PŘÍLOHA B. TVORBA REPORTU V BIRT REPORT DESIGNERU ................................................... 41
Kapitola 1
Úvod
Nume.cz je český internetový aukční portál zaměřený na numismatiku. Do ostrého provozu byl spuštěn na konci roku 2012. Jeho prostřednictvím mohou sběratelé kupovat a prodávat mince a další platidla. Portál podporuje řadu prémiových funkcí jako je upřednostnění aukce před ostatními, zvýraznění titulku aukce nebo jeho obarvení, nastavení ceny Kup teď pro okamžité zakoupení dražené položky a další. V současné době jsou všechny tyto funkce poskytovány zdarma, ale do budoucna je v plánu je zpoplatnit. Tato práce rozšiřuje softwarový produkt, který nemá otevřenou licenci. Z tohoto důvodu nemohly být v této práci zveřejněny kompletní zdrojové kódy. Proto jsou na přiloženém CD uvedeny pouze zdrojové kódy, jejichž jsem výhradním autorem.
1.1 Motivace Součástí portálu je i administrační sekce, která ale v době spuštění nebyla dokončena a chybí v ní několik důležitých součástí, které musí být před zavedením placených funkcí zprovozněny. Jedná se zejména o nasazení nástroje pro reporting, pomocí kterého by se dalo generovat například vyúčtování nebo různé statistiky. Cílem této práce je provést analýzu současného stavu aukčního portálu, zejména jeho administrační sekce, vybrat vhodný nástroj pro reporting, nasadit ho do provozu a do administrační sekce doprogramovat správu jednotlivých reportů.
1
1.1.1 Scénáře použití V této části jsou popsány jednotlivé scénáře použití nástroje pro reporting z pohledu administrátora i běžného uživatele. Závěrečný scénář demonstruje využití konkrétního reportu (Vyúčtování služeb) mimo administraci běžným uživatelem s registrací. Tvorba nového reportu 1. Administrátor na svém počítači prostřednictvím návrháře vyrobí šablonu reportu. 2. Administrátor nahraje šablonu reportu na server prostřednictvím administrační sekce. a. Administrátor nastaví parametry šablony, na základě kterých se bude pravidelně posílat určeným uživatelům na email. b. Administrátor si přímo v administrační sekci portálu vygeneruje aktuální report na základě zadaných parametrů (například identifikačního čísla uživatele nebo zúčtovacího období).
Aktualizace existujícího reportu 1. Administrátor si na svůj počítači stáhne existující report a upraví ho prostřednictvím návrháře. 2. Administrátor nahraje upravenou šablonu na server prostřednictvím administrační sekce.
Úprava existujícího reportu 1. Administrátor si stáhne v administraci portálu report. 2. Administrátor si otevře report v návrháři a upraví ho. 3. Administrátor nahraje upravený report do administrační sekce.
Zobrazení reportu Vyúčtování služeb registrovaným uživatelem 1. Administrátor vytvoří report a nahraje ho na server. 2. Administrátor zakomponuje report přímo do aplikace. 3. Registrovaný uživatel se přihlásí do aplikace a přejde do části Vyúčtování služeb. 4. Registrovaný uživatel zadá parametry (počáteční a konečné datum vyúčtování). 5. Registrovaný uživatel si na webu prohlíží report vygenerovaný na základě zadaných parametrů.
2
Kapitola 2
Analýza stávajícího stavu
2.1 Aukční portál Nume.cz Portál Nume.cz je komplexní webovou aplikací napsanou v PHP [1] pomocí frameworku Nette [2]. Nabízí uživatelům možnost kupovat a inzerovat ve vlastních aukcích a internetových obchodech. Jako databázi portál využívá MySQL [3] verze 5 s tabulkami ve formátu InnoDB [4]. Pro internacionalizaci využívá služby GNU gettext [5]. Následuje stručný popis těchto technologií spolu s několika implementačními zajímavostmi a souhrnem funkcí portálu.
2.1.1 Funkce portálu Primární účel portálu Nume.cz je prodej a nákup mincí (a případně dalších předmětů z oboru numismatiky). Veškerá funkcionalita je zpřístupněna pouze registrovaným uživatelům a z velké části se podobá známému aukčnímu portálu Aukro.cz. I zde se dají vybírat různé doplňkové služby (například zvýraznění titulku aukce, cena Kup teď, prodloužené vystavení, přidání více obrázků než je základní limit). Na rozdíl od Aukro.cz není na Nume.cz zatím nic zpoplatněno, je ale připraven dynamický ceník podle kterého se budou v budoucnosti jednotlivé poplatky počítat. Prodávat lze jak v klasických aukcích (které končí až v určený čas a vyhrává nejvíce přihazující subjekt), tak ve virtuálních obchodech (kde mají položky pevně danou cenu). 3
2.1.2 PHP PHP je skriptovací jazyk určený pro programování dynamických internetových stránek. Je šířen pod open source licencí. Jedná se o interpretovaný jazyk, program se tedy nekompiluje (nepřekládá), ale vykonává se přímo ze zdrojového kódu. Při používání PHP pro dynamické webové stránky jsou skripty prováděny na straně serveru a k uživateli je přenášen pouze jejich výsledek. V dřívějších verzích (do verze 5) bylo PHP striktně procedurálním jazykem, verze 5 ale přinesla základní podporu pro objektové programování (OOP). Od verze 5.3 je pak podpora OOP doplněna i o jmenné prostory (Namespace).
2.1.3 Framework Nette Nette je český open source framework pro tvorbu webových aplikací v PHP 5. Jeho autorem je David Grudl. Zaměřuje se na eliminaci bezpečnostních rizik [6], má vestavěný kvalitní šablonovací systém a propracovaný komponentový model. Skládá se z několika provázaných a navzájem na sobě závislých knihoven. Některé jeho části (ladící nástroj, komponenta pro tvorbu formulářů) se dají používat i samostatně. Architektura MVP Aplikace v Nette se tvoří dle architektury MVP [7] – Model – View – Presenter (viz obrázek 1). Jedná se o modifikaci architektury MVC (Model – View – Controller), kde místo Controlleru figuruje Presenter. Ten na sebe přebírá více povinností, než má klasický Controller – jak jeho název napovídá, stará se o prezentaci dat z modelu do šablony. Dále udržuje stav persistentních proměnných (tedy proměnných udržujících stav) a především zpracovává reakce uživatele. Ty se dají rozdělit na tři typy: •
změna pohledu (přechod na jinou stránku)
•
změna stavu (změna hodnoty persistentní proměnné)
•
příkaz modelu (aktualizace databáze)
4
Obrázek 1.
Architektura Model – View – Presenter v Nette Framework. Zdroj: [7]
Ladící nástroj Nette obsahuje vestavěný ladící nástroj Nette\Diagnostics\Debugger [8] (mezi komunitou přezdívaný jako „Laděnka“, nedávno uvolněný i jako samostatná ladící aplikace pod jménem Tracy). Ten mimo zvýraznění chyby dokáže i vypisovat proměnné v dobře čitelném formátu (funkce Debugger::dump) a hlavně se stará o logování chyb v produkčním režimu do souborů, které pak volitelně umí zaslat na vybraný email. Vývojář se tak může dozvědět o všech chybách ihned při jejich vzniku. Uživateli se přitom (pokud je aplikace v produkčním režimu) zobrazí jednoduchá stránka bez ladicích informací. Zvýraznění chyby je znázorněno na obrázku 2. Laděnka zobrazí zdroj chyby včetně zásobníku volaných procesů vedoucích k chybě, úsek zdrojového kódu ve kterém došlo k chybě, dále obsah systémových proměnných POST, GET, COOKIE, SESSION a SERVER a několik dalších užitečných informací. Na obrázku je vidět upozornění na neexistující funkci – došlo totiž k překlepu – místo funkce isLogged in byla mylně zavolána isLogedIn (s jedním g).
5
Obrázek 2.
Laděnka (Nette\Diagnostics\Debugger). Zdroj: [8]
Šablonovací systém Nette využívá vlastní šablonovací systém Latte [9] s pokročilou ochranou proti útokům XSS (Cross Site Scripting). Obrana proti tomuto útoku je důsledné escapování, tedy převod znaků majících v daném kontextu speciální význam na jiné odpovídající sekvence. V Latte se obsah proměnné escapuje automaticky, a to dle kontextu, ve kterém je vypsána. Této technice se říká Context-Aware Escaping [10]. To znamená, že se obsah proměnné jinak ošetří při vypsání do HTML a jinak při vypsání do Javascriptu. Formuláře Další důležitou součástí Nette je komponenta pro tvorbu formulářů [11], pomocí které lze snadno a rychle tvořit složité formuláře, definovat pro jednotlivé položky různá pravidla a to vše pak v šabloně vypsat pomocí jednoduchého makra. Na základě daných pravidel se při odeslání provádí validace celého formuláře a k jeho zpracování výslednou funkcí dojde pouze v případě splnění všech pravidel. Volitelně lze nalinkováním Javascriptového souboru dostupného jako doplněk pro Nette docílit i automatické validace na straně klienta. 6
AJAX AJAX [12] (Asynchronous Javascript And XML) je skupina technologií, které se společně využívají pro tvorbu aplikací, které mění svůj stav bez nutnosti jejich znovunačtení. Nette Framework má v sobě zabudovanou podporu AJAXu prostřednictvím tzv. snippetů [13], tedy ústřižků jednotlivých šablon. Tyto snippety lze jednoduše definovat v šablonách pomocí makra a v případě, že potřebujeme obnovit danou oblast, stačí ji pomocí presenteru invalidovat (tedy nastavit její obsah na neplatný), framework se už o vše postará a odešle obsah všech takto invalidovaných snippetů prostřednictvím AJAXového požadavku ve formátu JSON [14] (JavaScript Object Notation). O aktualizaci snippetů na straně klienta se ale musíme postarat sami. K tomuto účelu existuje několik hotových javascriptových knihoven dostupných z portálu Nette Addons [15]. Routování Odkazy chápe Nette framework stejně jako funkce. Díky tomu lze řešit výslednou podobu URL až na konci vývoje aplikace. Routování [16] je tedy obousměrné překládání mezi URL a akcí presenteru. Obousměrné znamená, že lze z URL dostat výslednou akci presenteru, a naopak z dané akce presenteru lze odvodit výsledné URL. Routování v Nette podporuje tzv. kanonizaci. Ta se stará o zamezení existence duplicitních adres vedoucích na stejný obsah. Pokud tedy na jednu stránku vede více odkazů, framework první z nich určí jako kanonickou a ostatní adresy na ni přesměruje (pomocí HTTP kódu 301). K tomuto přesměrování dojde pouze u požadavků typu GET. Při AJAXovém nebo POST požadavku by došlo ke ztrátě dat, a proto se v tomto případě kanonizace nepoužívá. Distribuce Nette je distribuováno jak ve verzi pro PHP 5.2, tak ve verzi pro PHP 5.3 a vyšší. Portál Nume.cz je naprogramován ve verzi pro PHP 5.3 využívající jmenné prostory.
2.1.4 Databáze Součástí Nette je od verze 2 i vlastní databázová abstrakční vrstva Nette\Database [17], která vychází z jiného open source nástroje – NotORM [18]. Na rozdíl od původní implementace používá Nette\Database jiné API (ovládá se pomocí jinak pojmenovaných příkazů). Využívá cizích klíčů a na základě dodržovaní jmenné konvence v názvech tabulek a cizích klíčů nabízí API pro základní práci nad všemi databázovými tabulkami. Z tohoto důvodu musí být 7
všechny tabulky uloženy ve formátu InnoDB, který na rozdíl od defaultního MyISAM podporuje transakce a cizí klíče. Knihovna implementuje i cachování výsledků, díky kterému dokáže přenášet pouze sloupce, které se skutečně využívají. Při prvním vykonání dotazu se přenášejí všechny sloupce, poté se do cache uloží informace o tom, které se skutečně využili. Portál Nume.cz používá pro práci s databází právě knihovnu Nette\Database. Databáze je poměrně rozsáhlá a složitá, proto obsahuje pro některé složitější dotazy předpřipravené pohledy (views). Dále pak využívá uložených procedur [19] pro výpočet některých souhrnných údajů (např. hodnocení uživatelů).
2.1.5 Překladač Celý portál Nume.cz je psán v angličtině. O překlad do češtiny se stará vlastní překladač, který využívá nativní funkce GNU gettextu. GNU gettext je internacionalizační a lokalizační nástroj. Obsahuje několik funkcí, pomocí kterých lze překládat text v aplikaci. Podporuje překlady textů včetně parametrů a různých plurálních forem (v češtině máme tři, v angličtině jen dvě). Řetězce určené k překladu se obalí funkcí gettext() nebo jejím aliasem „_()“ (podtržítko). Na základě toho se pak pomocí programu xgettext z aplikace vyextrahují všechny takto označené řetězce. Ty se přeloží (buď ručně nebo pomocí nástroje třetí strany, například POEdit [20] nebo Lokalize [21]). Výsledkem je soubor s koncovkou *.po (Portable Object) s přeloženými řetězci. Ten se musí před použitím ještě zkompilovat do binárního souboru s koncovkou *.mo (Machine Object). Při volání funkce gettext se pak v daném slovníku vyhledá jeho ekvivalent v aktuálním jazyce, pokud není řetězec přeložen, vrátí se jeho originál.
2.1.6 Stavový automat Každá prodejní položka (aukce nebo položka v obchodě) se nachází v jednom ze stavů definovaných na obrázku 3. Modelová třída reprezentující každou takovou položku ve svém kódu implementuje stavový automat [23], který hlídá, aby se aukce nedali přesouvat mezi stavy jinak než podle definice znázorněné na obrázku 3. Zároveň se na základě této definice generuje právě tento obrázek, který se zobrazuje v administraci a dává tak zákazníkovi možnost rychlé kontroly aktuálně používané implementace. 8
Obrázek 3.
Stavový automat. Zdroj: [22]
2.1.7 Udržování stavu aukcí pomocí CRONu Každá prodejní položka má danou platnost. Vystavení připravené aukce nebo ukončení prodeje se provádí pomocí CRON skriptu. Tento skript se spouští každou minutu (nejkratší možný čas) a mimo jiné se také stará o zasílání některých e-mailových zpráv.
2.2 Nástroje pro analýzu dat a reporting Pro generování statistických a finančních reportů je nutné vybrat vhodný nástroj.
2.2.1 Požadavky •
Nástroj musí být zdarma.
•
Nástroj musí obsahovat rozhraní pro vytváření pohledů do databáze.
•
Nástroj musí být kompatibilní s databází MySQL, na které portál Nume.cz běží.
•
Nástroj by měl podporovat exporty dat do Excelu a PDF.
9
2.2.2 Zkoumané nástroje Na základě požadavků a internetové diskuze [24] byly vybrány čtyři nástroje: •
BIRT -‐ [25]
•
JasperReports -‐ [26]
•
OpenReports -‐ [27]
•
Pentaho -‐ [28]
2.2.2.1 BIRT BIRT neboli Business Intelligence and Reporting Tools je open source reportovací systém pro webové aplikace. Jedná se o součást projektu Eclipse [29]. Skládá se ze dvou hlavních částí – návrháře reportů BIRT Report Designer (postaveného nad Eclipse) a serverové komponenty BIRT Runtime. Součástí BIRT jsou i tři open source komponenty, které mohou být použity separátně: •
BIRT Chart Engine – nástroj pro tvorbu grafů pomocí serverové API (CE API).
•
BIRT Chart Designer – návrhář grafů.
•
BIRT Viewer [30]– jednoduchý prohlížeč reportů, postavený jako Eclipse plugin. Může být na serveru použit jako samostatná Java EE aplikace.
Reporting Designer Report Designer je nástroj pro tvorbu jednotlivých reportů pomocí grafického rozhraní. Tyto reporty mohou být nasazeny na server v podobě webové aplikace s živými daty (BIRT Report Viewer), nebo vyexportovány v podobě statických reportů do formátů HTML (stránkovaný / nestránkovaný), DOC, PDF, PostScript, PPT, XLS. Report Designy (tedy šablony vytvářené pomocí tohoto programu) se vnitřně ukládají ve formátu XML, tudíž je možné je upravovat přímo v textovém editoru, nebo je vygenerovat např. v PHP. Pro práci s nimi jsou ale také přístupná různá serverová API: Design Engine API (DE API), Report Engine API (RE API) a Chart Engine API (CE API), pomocí kterých se dají reporty procházet, měnit a generovat. Do reportů je možné naimportovat kaskádové styly. Jejich další výhodou je možnost efektivního verzování [31]. Rozložení komponent v BIRT funguje podobně jako u webových stránek. Na rozdíl od ostatních testovaných nástrojů tedy nepracuje s pevně daným layoutem, ale nechává výsledné 10
reporty přizpůsobit velikosti webového prohlížeče, ve kterém jsou zobrazeny. Toto řešení je tedy vhodnější pro zobrazování výsledných reportů spíš na webu, než pro tisk (kde se lépe pracuje s JasperReports a Pentaho). Každý report sestává z jednotlivých komponent. Samotná data se pak do reportu vkládají jako tzv. Data Sety, které představují jednotlivé MySQL dotazy. Ty je možné vytvářet pomocí vestavěného editoru, nebo jednoduše napsat ručně. Do reportu se pak dají vložit buď jako tabulkový výpis, nebo klasický listový výpis, nebo např. jako graf, viz příklady reportů dále. Report Designer podporuje seskupování dat (GROUP BY), křížové tabulky a dokáže pracovat i s vícero datovými zdroji v rámci jednoho reportu. Hlavní okno, ve kterém se upravuje report, má několik záložek, pomocí kterých lze rychle přepínat mezi úpravami layoutu, úpravou hlavní stránky, rychlým náhledem a přímou editací zdroje v XML. Do samotné aplikace je zakomponována celá dokumentace. U většiny kontextových dialogů je přítomné i tlačítko Help (otazník), které zobrazí rychlou nápovědu spojenou s daným dialogem. Dokumentace, stejně jako samotná aplikace je ale pouze v angličtině. Pro tvorbu grafů obsahuje Report Designer zabudovaného průvodce, pomocí kterého lze celkem jednoduše sestavit i komplexní grafy. Součástí průvodce je i živý náhled, díky kterému se dá snadno experimentovat s jednotlivými možnostmi nastavení. Kromě vizuální podoby grafu lze nastavit i interakce jednotlivých grafových elementů – tzn. například změna viditelnosti některých dat po kliku na osu, nebo otevření webové stránky v prohlížeči. Grafy lze také generovat na základě parametrů reportu. BIRT také podporuje tzv. kontingenční tabulky (cross tabs), čili tabulky maticového typu zobrazující souhrny (počet, součet…) na základě dvou parametrů. Pro jejich tvorbu je zde zabudovaný nástroj Cross Tab Cube Builder, pomocí kterého lze v několika krocích tabulku sestavit. Využívá k tomu stejných datových zdrojů (Data Sets), jako u klasických tabulkových reportů. Vedle hlavního reportu (master report) lze v BIRT tvořit také vedlejší reporty (sub-reports). Tyto vedlejší reporty jsou pak zařazeny pod nějaký jiný, hlavní report. Jejich výhodou je znovu použitelnost, práce s nimi ale není úplně jednoduchá. Závislosti mezi hlavním a vedlejšími reporty si musí hlídat sám vývojář, který report sestavuje. Navíc každý vedlejší 11
report si při prohlížení otevírá své vlastní spojení s databází, což může u komplexních reportů způsobit potíže s výkonem. Dalším problémem je, že se z hlediska editace jedná o dva samostatné reporty, a jejich editace není nijak provázaná. Proto při úpravě hlavního reportu nelze jednoduše přejít k úpravě vedlejšího. Integrace pomocí BIRT Runtime Druhou částí BIRTu je serverová komponenta, kterou nalezneme pod názvem BIRT runtime. Jedná se o JAVA aplikaci, kterou je z různých důvodů (především pro generování nadměrné zátěže) vhodné provozovat na odděleném serveru, který bude s produkčním serverem propojený (viz Obrázek 4). Jako most mezi servery lze použít např. open source projekt PHP / Java bridge [32]. Jedná se o JEE webovou aplikaci, skrze kterou se dá z PHP komunikovat (za pomoci přiložené PHP třídy) s Java serverem, na kterém je nainstalován BIRT Runtime. Druhou možností je ovládat BIRT pomocí BIRT Viewer URL [30] odkazů. Zde ale existuje reálný limit cca 2000 znaků pro délku URL řetězce [33]. Navíc je to nástroj pouze pro generování reportů, a přicházíme tak o možnost úpravy a další práce s reporty pomocí serverového API.
Obrázek 4.
Schéma komunikace s odděleným reportingovým serverem. Zdroj: [32]
Licence BIRT je šířen zdarma pod licencí Eclipse Public License [34]. Dle této licence je možné tento nástroj používat, upravovat, kopírovat a šířit zdarma. 12
2.2.2.2 JasperReports JasperReports je dalším nástrojem pro reportování napsaný v Javě a šířený jako open source. Podporuje výstup v řadě formátů: PDF, HTML, Excel, XML a další. Skládá se ze dvou částí – JasperReports Library (open source knihovny) a JasperReports Server (samostatná aplikace postavená na JasperReports Librabry). Navíc k nim existuje několik dalších nástrojů tvořených společnou komunitou. Příkladem může být návrhář reportů iReport Designer (postavený nad JasperReports Library) nebo PHP wrapper k JasperReports Serveru – PHP Client [35]. JasperReports Server JasperReports Server je samostatná aplikace umožňující generování reportů do HTML, k tisku, nebo do dalších formátů. Jeho klíčové vlastnosti: •
Podporuje řadu datových zdrojů včetně MySQL (skrze ovladač JDBC).
•
Obsahuje webové služby založené na REST a SOAP a HTTP API pro jednoduchou integraci do klientských aplikací.
•
Nabízí centralizovanou správu reportů a jejich plánování skrze webové rozhraní.
•
Umožňuje reporty formátovat pomocí kaskádových stylů.
•
Umožňuje napojení na existující autentizační a autorizační systémy (LDAP, CAS, JAAS, …).
iReport Designer iReport Designer je nástroj pro tvorbu reportů napsaný v Javě a postavený nad Netbeans [36]. Je dostupný jak ve formě samostatné aplikace, tak jako Netbeans plugin. Reporty se ukládají ve formátu XML s koncovkou *.jrxml, poté se kompilují, zkompilovanému *.jasper souboru se dodají data a vygeneruje se report do příslušného formátu. Tento proces je znázorněn na obrázku 5.
13
Obrázek 5.
Životní cyklus reportu v iReportDesigneru. Zdroj [37]
iReport Designer se na první pohled moc neliší od svého kolegy z projektu BIRT. Opět zde pracujeme s jednotlivými komponentami, které představují například tabulky nebo grafy. Základní rozdíl je ale v přístupu k rozložení reportu – na rozdíl od BIRT se zde pracuje s absolutním pozicováním – každá komponenta má přesně danou šířku, výšku a vzdálenost od levého horního rohu. Tento přístup je vhodnější pro generování tištěných reportů (vzhledem k absolutní kontrole nad rozložením jednotlivých komponent). Stejně jako BIRT i iReport Designer podporuje vedlejší reporty. Problémy při jejich používání jsou v podstatě stejné jako u BIRT – nemožnost vidět výsledek dříve než po spuštění reportu, nutnost starat se manuálně o závislosti, otevírání nového spojení s databází pro každý vedlejší report, atd. Na rozdíl od BIRT se v iReportu nedá některých věcí docílit jinak, než za pomoci vedlejších reportů. Jedná se například o využití vícero datových zdrojů, které je v BIRT podporováno nativně. Použitím vedlejších reportů toho sice lze docílit, je to ale mnohem složitější a náročnější záležitost. Součástí aplikace je také jednoduchý průvodce tvorbou grafů, ve kterém ve dvou krocích vybereme typ grafu a napojíme ho na datový zdroj. Vše ostatní (formátování, velikost, popisky os) se pak už musí nastavit přes vlastnosti vygenerované komponenty. Existuje i několik alternativ založených na Eclipse, konkrétně například Jasper Studio [38] – produkt ze stejné dílny, který je přepis původního iReport Designeru do Eclipse platformy.
14
Alternativou reportů utvářených designery může být nástroj DynamicReports [39], který umožňuje vytvořit dynamický report design bez vizuálního nástroje, pouze za pomoci Java kódu. Reporty lze rozšiřovat pomocí dědičnosti. Kód podporuje Fluent Interface [40] (řetězení příkazů za sebe), hodně se podobá například javascriptovému frameworku jQuery [41]. Licence JasperReports je šířen pod licencí GNU Lesser General Public License. Dle této licence je možné ho používat zdarma.
2.2.2.3 OpenReports OpenReports je open source webový reportingový nástroj, který pracuje s několika serverovými nástroji. Jeho klíčové vlastnosti: •
Poskytuje dynamický webový přístup k datům včetně parametrizace.
•
Obsahuje webovou administraci uživatelů, uživatelských skupin, reportů, grafů, parametrů a datových zdrojů.
•
Podporuje mnoho exportů (PDF, HTML, Excel, obrázek, …).
Report Auditing – historie jednotlivých reportů včetně počátku, trvání a autora.
•
Podporuje serverové nástroje JasperReports, JFreeReport, JXLS, Eclipse BIRT.
•
ReportService – SOAP webová služba poskytující možnosti ke správě reportů.
Tento projekt už ale není od roku 2009 aktivně vyvíjen. Licence OpenReports je šířen pod licencí GNU General Public License. Dle této licence je možné ho používat zdarma. Odvozená díla by ale měla zůstat pod stejnou licencí.
15
2.2.2.4 Pentaho Pentaho Busines Analytics (dříve Pentaho BI Platform) je skupina open source nástrojů pro business intelligence. Obsahuje několik komponent: •
Pentaho Report Designer (dříve JFreeReport).
•
Mondrian a JPivot pro analýzu dat (OLAP).
•
Weku pro data mining.
•
Kettle pro ETL (Extract, Tranfsform and Load).
Těmto komponentám poskytuje běhové prostředí pro spouštění, zobrazování výsledků a práci s nimi. Neumožňuje však definici jednotlivých objektů (reportů, OLAP kostek, dotazů nad nimi, atd.), která se provádí mimo vlastní webovou aplikaci buď přímou úpravou XML souborů, nebo skrze samostatné nástroje. Pentaho Report Designer Jedním z těchto nástrojů je dříve zmíněný designer. Jedná se opět o vizuálního pomocníka pro generování reportů (opět ukládaných vnitřně jako XML) napsaného v Javě. Jeho distribuce je společná pro všechny podporované systémy. Obsahuje soubor launcher.jar, který lze pod Windows spustit připraveným dávkovým souborem report-designer.bat (pod Linuxem report-designer.sh).
Pro použití MySQL databáze bylo potřeba nejprve doplnit aktuální
ovladač do složky s aplikací (./libs/JDBC). Reporty se opět skládají z jednotlivých komponent. Stejně jako u JasperReports je rozložení těchto komponent založeno na absolutním pozicování, což z nich opět dělá kandidáty spíše pro tisk. Stejně jako JasperReports a BIRT jsou podporovány vedlejší reporty, pomocí kterých lze (stejně jako u JasperReports) docílit například využití vícero datových zdrojů, které není nativně podporováno. Stejně jako u BIRT a JasperReports, i zde se potýkáme se stejnými problémy při jejich použití. Stejně jako u iReport Designeru je i zde součástí aplikace pomocník pro tvorbu reportů – Report Wizard. Je zpracován velmi povedeně, generování základních reportů je v něm otázkou pár minut. Využití najde jak u začátečníků, tak u zkušených. Součástí je několik předpřipravených moderně vypadajících skinů. S pomocí Report Wizardu je možné tvořit základní stránkované reporty s až čtyřmi úrovněmi seskupení (GROUP BY).
16
Na rozdíl od JasperReports a BIRT postrádá Pentaho průvodce pro tvorbu grafu. Všechny vlastnosti grafu (včetně napojení na datové zdroje) se nastavují v komplexním a ne moc přehledném dialogu. Stejně jako iReport Designer a BIRT je i zde možnost tvorby parametrizovaných reportů. Neliší se ani možnosti exportu do základních formátů (PDF, HTML, Excel, RTF, CSV nebo plain text). Nechybí ani návrhář SQL dotazů (totožný s tím v iReport Designeru), ve kterém se velmi intuitivně a rychle dají tvořit i složitější dotazy slučující několik tabulek. Licence Jednotlivé nástroje Pentaho nejsou šířeny pod jednotnou licencí [42]. Nástroje jsou nabízeny buď ve volně šiřitelné komunitní edici (CE) nebo placené enterprise edici (EE). V placené enterprise edici je několik dalších samostatných součástí (pluginů) jako například nástroj pro interaktivní tvorbu přehledu (Dashboard Designer) nebo Mobilní aplikaci. Report desiger je šířen pod licencí GNU Lesser GPLv2.1, Business Analytics pod GNU GPLv2, Mondrian pod Eclipse Public License. Dle těchto licencí je tento software možné používat zdarma.
2.3 Analýza uživatelských rolí Na portálu Nume.cz existují tři základní role: 1. Neregistrovaný uživatel Uživatel bez registrace nebo nepřihlášený uživatel může procházet portál a prohlížet si nabídku aukcí a obchodů. Nemá ale žádný přístup k reportovacím nástrojům. 2. Registrovaný uživatel Registrovaný uživatel – po přihlášení může kupovat a prodávat v aukcích a obchodech. V detailu svého profilu bude mít zpřístupněno své vyúčtování vygenerované nástrojem pro reporting.
17
3. Administrátor Administrátor má přístup do administrační sekce. V administrační sekci může prohlížet a spravovat uživatele, obchody, aukce, ceníky a prohlížet reporty. V současné implementaci není možné reporty nijak rozšiřovat, dají se pouze prohlížet a exportovat do XLS a PDF.
2.4 Požadavky na řešení 2.4.1 Funkční 1. Registrovaný uživatel bude mít po přihlášení přístup k poslednímu svému vyúčtování prostřednictvím odkazu ve svém pro5ilu. 2. Administrátor bude moct přidávat nové a upravovat stávající reporty prostřednictvím aplikace v administrační sekci. 3. Administrátor bude moct zařadit report do automatického odesílání pomocí CRONu [43]. 4. Administrátor si bude moct prohlížet reporty s živými daty prostřednictvím aplikace v administračním rozhraní.
2.4.2 Nefunkční 1. Přístup ke správě reportů bude pouze pro uživatele s rolí Administrátor. 2. Reportingový nástroj nesmí běžet na produkčním serveru. 3. Všechny změny provedené v reportech musí být zaznamenány do historie a musí být možné se k nim vrátit. 4. Všechny odeslané reporty se musí zaznamenávat do logu. 5. Report musí podporovat možnost exportu do PDF a XLS. 6. Nástroj pro reporting musí podporovat práci s databází MySQL. 7. Správa reportů v administraci portálu musí být naprogramována v jazyce PHP.
18
Kapitola 3
Návrh řešení
První část se zabývá výběrem vhodného nástroje pro reporting, druhá část pak jeho zakomponováním do samotné aplikace.
3.1 Výběr nástroje pro reporting a analýzu dat Všechny zkoumané nástroje jsou ve většině aspektů velmi podobné (viz tabulkové srovnání [44]). Malou výjimkou je již delší dobu nevyvíjený OpenReports, který pracuje se zdroji třetích stran. BIRT neobsahuje vlastní server, ale pouze serverový engine (BIRT Runtime). Nelze v něm tedy na webu spravovat uživatelské přístupy k reportům a další vlastnosti, jako tomu je u JasperReports nebo Pentaho. Pro využití na portálu nume.cz toto neberu jako kritérium, protože pro případnou správu reportů lze relativně jednoduše doprogramovat do stávající administrace modul v PHP, který obstará základní nastavení. Naopak vzhledem k existenci stávající administrace je vhodnější správu reportů zakomponovat do ní. Základním rozdílem, kterým se liší BIRT od JasperReports a Pentaho je jeho přístup k rozložení komponent na stránce. BIRT je vhodnější pro reporty určené primárně k prohlížení na obrazovce, zatímco JasperReports a Pentaho (které pozicují komponenty absolutně) je vhodnější pro tisk.
19
Při používání jednotlivých designerů se jako nejintuitivnější jevil právě BIRT, šikovné je u něj například upravování výsledných hodnot za pomoci JavaScriptového výrazu nebo jeho kvalitně zpracovaný průvodce tvorbou grafů. Ve prospěch BIRT také mluví kvalitní dokumentace, dodávaná jako součást aplikace, a začleněná v podobě kontextové nápovědy skoro do všech dialogů. Na internetu je navíc velké množství tutoriálů, videí a screencastů. Zajímavé je i Pentaho, které má velmi pěkně zpracovaného průvodce tvorbou reportu (který v BIRT úplně chybí), pomocí kterého lze rychle vygenerovat i pokročilejší report s několika úrovňovým seskupením. Naopak tvorba grafů je v Pentaho poměrně složitá a chybí zde alespoň jednoduchý průvodce (jako je například v JasperReports). Všechny nástroje jsou napsány v Javě, a proto je lze bez větších obtíží provozovat na všech hlavních platformách (Windows, Linux, OS X). S ohledem na dobře zpracovanou dokumentaci a velkou komunitu jsem zvolil nástroj BIRT.
3.2 Aukční portál Nume.cz 3.2.1 Nasazení serverové komponenty pro tvorbu reportů Zvolený reportingový nástroj BIRT je napsán v jazyce Java. Pro generování reportů je potřeba na server nahrát serverové rozšíření BIRT Runtime (také v jazyce Java). S ohledem na možné snížení stability a výkonnosti produkčního serveru, na kterém portál běží, musí být serverová komponenta BIRT Runtime nainstalována na odděleném serveru, tak jak je to znázorněno na obrázku 4. Na tomto serveru bude nainstalován aplikační server Apache Tomcat [45], který je dostupný jako open source. Na aplikačním serveru bude nainstalováno rozšíření BIRT Runtime. Vedle serverové komponenty pro tvorbu reportů bude na serveru nainstalována i knihovna PHP/Java Bridge. Pomocí této knihovny bude volána serverová komponenta BIRT Runtime přímo z PHP kódu naší aplikace.
3.2.2 Report Manager Do administrační sekce portálu Nume.cz přibyde nová záložka do části Reporting, jménem Report Manager (viz obrázek 6). Celá tato logika se bude nacházet ve stejném modulu (jmenném prostoru), jako jsou stávající reporty (AdminModule\ReportsModule) a bude zapouzdřena do jednoho presenteru (ReportManagerPresenter). 20
Obrázek 6.
Výsledná podoba Report Manageru. Zdroj: [22]
Základem bude tabulkový výpis stávajících reportů. Ten bude realizován (stejně jako většina tabulkových výpisů na celém portálu) pomocí komponenty pro datagrid jménem NiftyGrid [46]. Díky této komponentě bude možné ve výpisu rychle filtrovat dle všech sloupců a provádět některé hromadné akce (aktivace, deaktivace a smazání reportu) a podporuje také stránkovaný výpis. Každý report se může nacházet ve dvou stavech: aktivní a neaktivní. Neaktivní report se dá prohlížet pouze prostřednictvím administrace. Pokud je report zařazen do automatického odesílání pomocí CRONu, bude se odesílat pouze pokud je aktivní. Při přidávání nového reportu nebo při aktualizaci již existujícího reportu proběhne automatická kontrola koncovky (musí být *.rptdesign) a zároveň kontrola validity obsahu report designu (report design je vnitřně uložen ve formátu XML). V editaci každého reportu bude možnost nastavit automatické odesílání výsledných reportů vybrané skupině uživatelů. Bude se jednat zejména o zasílání souhrnných vyúčtování. Tyto reporty se budou odesílat pomocí CRON modulu, který je pro tyto potřeby v aplikaci připraven.
21
3.2.3 Historie Jakákoliv změna v reportech se bude zaznamenávat do historie. Při každé aktualizaci daného reportu se jeho aktuální stav uloží do databáze. Spolu s údaji o reportu se uloží i obsah souboru s report designem. Volitelně se poté půjde vrátit k libovolné verzi z historie. Při tomto procesu se opět aktuální verze uloží jako poslední položka do historie aby se k ní dalo opět vrátit.
3.2.4 Logování Každý report, který se odešle uživateli na email pomocí CRON modulu se bude ukládat do logu. Logování bude probíhat do databáze, kde se bude uchovávat text emailu, čas odeslání a odkaz na report. V administrační sekci portálu bude v detailu reportu zpřístupněn výpis tohoto logu.
22
Kapitola 4
Implementace
4.1 Aukční portál Nume.cz Do stávající aplikace přibyly tři nové modelové třídy reprezentující databázové tabulky (viz schéma na obrázku 7) : •
Report – základní report, který lze vygenerovat do HTML, PDF nebo XLS. Stará se o
komunikaci s BIRT Runtime prostřednictvím PHP/Java Bridge. Implementuje také pomocné funkce, které ze zdrojového kódu zjistí například parametry reportu. •
ReportHistory – dřívější verze reportu, ke které se lze vrátit. Obsahuje pouze
informace o samotném report designu (název a obsah souboru), ostatní informace (nastavení CRON komponenty) se do historie neukládají. •
ReportLog – záznam o odeslaném reportu na email. Uchovává se celý text zprávy a
přesný čas odeslání.
Pro správu reportů byl vytvořen nový presenter ReportManager, ve kterém je ukryta celá manipulace s reporty, jejich nahrávání, mazání, správa historie a log emailů odeslaných CRONem. Výsledná podoba této části administrační sekce je vidět na obrázku 7. O výpis reportů se stará dříve zmíněný NiftyGrid. Jedná se o komponentu, která se napojí na databázovou tabulku a na základě konfigurace pak vykreslí stránkovanou tabulku podporující filtrování. Další částí aplikace je implementace CRON komponenty, která se stará o odesílání reportů určeným uživatelům. 23
Obrázek 7.
ER diagram nových tabulek. Zdroj: [22]
4.1.1 CRON komponenta Každý report lze zařadit do automatického odesílání na e-mail pomocí služby CRON. Toto nastavení se nachází v editaci reportu (viz obrázek 8). Lze nastavit tyto parametry: •
•
•
Skupina uživatelů, kterým se bude report odesílat: o
Administrátoři.
o
Ověření uživatelé.
o
Vybrané emaily (více emailů lze oddělit středníkem).
Periodicita odesílání: o
Denně – vždy v 6:00.
o
Týdně – vždy o půlnoci z neděle na pondělí.
o
Měsíčně – vždy o půlnoci na přelomu měsíce.
Odesílání prázdných reportů – pokud chceme povolit zasílání i reportů s parametry, pro která nebyla nalezena žádná data.
Každý report může obsahovat parametry, které je před vygenerování do výsledného formátu potřeba dosadit. Pro odesílání takových reportů je nutné do CRON komponenty implementovat následující metodu: protected function processParams<Jméno Reportu>($email, $report);
24
Tato funkce musí vracet pole parametrů na základě kterých se report vygeneruje. Pokud takové pole nevrátí, CRON komponenta tento email přeskočí a pokračuje dalším.
Obrázek 8.
Editace parametrů reportu. Zdroj: [22]
4.2 Instalace serverové komponenty Generování reportu do výsledného formátu (HTML, PDF nebo XLS) probíhá v Javě pomocí prostředí BIRT Runtime nainstalovaném na odděleném serveru Apache Tomcat 7. Komunikace s tímto serverem probíhá pomocí knihovny PHP/Java Bridge (viz obrázek 9). Knihovna PHP/Java Bridge je dostupná ke stažení na webových stránkách [32]. Zajímá nás první soubor ke stažení – Documentation. Jeho název je trochu matoucí, ale obsahuje kompletní verzi se všemi rozšířeními. Tato knihovna má v aktuálně poslední dostupné verzi již v sobě zahrnuty zdrojové soubory pro prostředí BIRT Runtime ve verzi 2.6.0. Verze 2.6.0 ale nepodporuje reporty vytvořené v poslední verzi BIRT Report Designeru (4.2.2). Proto je nutné BIRT Runtime uvnitř PHP/Java Bridge aktualizovat. Postup aktualizace je popsán ve článku [47]. Aktualizovat je potřeba minimálně na verzi 3.7.0.
25
Obrázek 9.
Schéma komunikace PHP serveru s Java serverem. Zdroj: [48]
4.3 Report Vyúčtování služeb V rámci této práce byly v programu BIRT Report Designer 4.2.2 vytvořeny tři reporty. Jedním z těchto reportů je Vyúčtování služeb. Tento report pro daného uživatele a časové období zobrazuje podrobné vyúčtování poplatků za všechny položky, které na portálu Nume.cz prodával. Vedle pravidelného rozesílání CRONem (které lze nastavit stejně jako pro všechny ostatní reporty prostřednictvím Report Manageru) si tento report mohou zobrazit i registrovaní uživatelé portálu. Návod na tvorbu jednoduchého reportu je popsán v příloze B.
26
Kapitola 5
Testování
Pro testování Report Manageru byla zvolena metoda integračních testů. Testuje se tedy chování samotné aplikace a součinnost jednotlivých objektů dohromady. Zdrojové kódy aplikace jsou pokryty z 94% (viz obrázek 10). To znamená, že při spuštění všech testů proběhne úspěšně 94% ze všech řádků zdrojových kódu. Pro testování kódu byl použit nový open source nástroj Nette Tester [49].
5.1 Nette Tester Nette Tester je jednoduchý testovací framework, pomocí kterého jsou napsány například testy Nette frameworku. Jeho výhodou oproti standardnímu nástroji PHPUnit [50] je především jednoduchost instalace. Stačí pouze stáhnout zdrojové soubory ze stránek [49] a umístit je do adresáře s aplikací. Jedná se o aplikaci napsanou v PHP, není proto potřeba žádná další konfigurace.
5.1.1 Test jako skript Každý test je z pohledu Nette Testeru samostatný PHP skript, lze ho tedy spustit i samostatně, bez nutnosti spouštět všechny testy dohromady. Díky tomuto faktu lze otestovat i věci jako jsou kritické chyby, HTTP hlavičky nebo práci s Cookies. Spouštění testů probíhá paralelně, každý ve vlastním vlákně. Tím je docíleno maximální izolace testů. Nette Tester také podporuje serializaci testů pomocí zámků, což se hodí hlavně při testování databáze. Několik testů totiž může pracovat se stejnou tabulkou a mohli by se tak navzájem ovlivnit. Testy lze psát jako třídy, pak každá vychází ze společného předka Tester\TestCase. Ten implementuje metody setUp a tearDown, které jsou spuštěny před (setUp) a po (tearDown) každé testované metodě. Názvy jednotlivých testovacích metod pak končí klíčovým slovem Test.
Každá třída ale musí být samostatně spustitelný skript, a proto je při testování pomocí
tříd potřeba na konec každého souboru přidat kód, který vytvoří instanci třídy a zavolání na ní metodu run. Pro testovaní lze využít aserce, stejně jako se to dělá například v PHPUnit. Ani aserce, ani objektový přístup ale není povinný. Za test lze považovat jakýkoliv spustitelný soubor, který při selhání testu skončí chybovou návratovou hodnotou exit(1).
5.1.2 Testování presenterů Při testování aplikace byla snaha otestovat její funkčnost hlavně jako celku. Proto byl testován i vlastní presenter, všechny jeho akce, signály i formuláře, a to přímo prostřednictvím simulace HTTP požadavku [51]. Při testování presenterů se často testuje kód metod, které pouze generují šablonu a jinak nic nevrací. Pro testování těchto metod byla využita třída Tester\DomQuery. Pomocí této třídy lze v HTML kódu vyhledávat elementy prostřednictvím CSS2 selektorů. Jednoduchý test,
28
který by zkontroloval, jestli kód v proměnné obsahuje element ,
5.1.3 Hromadné spouštění testů a pokrytí kódu Pro hromadné spouštění testů je připraven skript tester.php. Jedná se opět o samostatný spustitelný skript. Spouští se z příkazové řádky a přebírá několik parametrů, na základě kterých lze určit konfigurační soubor php.ini, počet vláken, ve kterých se testy budou spouštět a hlavně složku, ve které se testy mají hledat. Pro spouštění testů Report Manageru byl připraven shell skript tests/run. Ten vždy před spouštěním testů promaže adresář s dočasnými soubory, poté je spustí se správně nastavenými parametry a na konci opět promaže dočasné soubory. Má jeden volitelný parametr cov, pomocí kterého lze zapnout generování pokrytí kódu.
Obrázek 11. Detail pokrytí kódu. Zdroj: [22]
Pro sběr informací o pokrytí kódu testy se využívá rozšíření PHP Xdebug [52]. Na začátek každého testu se musí umístit krátký kód, který nastaví soubor, do kterého se informace mají zapsat. Na základě tohoto souboru se pak (pomocí jiného připraveného skriptu) vygeneruje report o pokrytí kódu. Výsledek je vidět na obrázku 10. Jednotlivé testovací třídy lze rozkliknout a v detailu (viz obrázek 11) je pak vidět jednotlivé řádky, které byly otestovány, a naopak řádky, které vůbec neproběhly. V praxi se pro úkony, které se v každém testu opakují (zapnutí sběru informací o pokrytí kódu, vytvoření systémového kontejneru, nastavení routování), vyčleňují do vlastního souboru tests/bootstrap.php, který se na začátku každého souboru vkládá.
29
30
Kapitola 6
Závěr
V této práci jsem se zaměřil na český internetová aukční portál Nume.cz, zejména na jeho administrační sekci a reporting a analýzu dat, která při jeho chodu vznikají. V první části jsem rozebral stávající stav aplikace a některé implementační zajímavosti. Dále jsem se zaměřil na analýzu reportingových nástrojů dostupných pod licencí open source. Na základě této analýzy jsem zvolil nejvhodnější nástroj pro reportování a popsal důvody této volby. Výsledkem volby byl program BIRT napsaný v jazyce Java. V další části jsem se věnoval integraci tohoto programu do stávající aplikace a návrhu nových funkcí administrační sekce portálu, které s reportováním souvisí. Následně jsem pak nastínil některé postupy při jejich implementaci. Poslední část práce popisuje způsob testování nové části aplikace, která byla v rámci této práce vytvořena. Pro testování jsem zvolil nový nástroj Nette Tester, který je v práci také stručně charakterizován. Testování bylo prováděno metodou integračních testů, při které se ověřuje bezchybná komunikace mezi jednotlivými komponentami uvnitř aplikace. Výsledkem této práce je vytvoření funkční a testováním prověřené nové komponenty, kterou lze integrovat do stávajícího aplikace Nume.cz. Tato komponenta rozšiřuje možnosti administrační sekce portálu, zejména o možnosti generování statistických reportů a jejich automatické odesílání pomocí služby CRON. 31
Seznam obrázků Obrázek 1. Architektura Model – View – Presenter v Nette Framework. Zdroj: [7] ................................ 5 Obrázek 2. Laděnka (Nette\Diagnostics\Debugger). Zdroj: [8] ...................................................................... 6 Obrázek 3. Stavový automat. Zdroj: [22] .................................................................................................................... 9 Obrázek 4. Schéma komunikace s odděleným reportingovým serverem. Zdroj: [33] .......................... 12 Obrázek 5. Životní cyklus reportu v iReportDesigneru. Zdroj [55] ............................................................... 14 Obrázek 6. Výsledná podoba Report Manageru. Zdroj: [22] ........................................................................... 21 Obrázek 7. ER diagram nových tabulek. Zdroj: [22] ........................................................................................... 24 Obrázek 8. Editace parametrů reportu. Zdroj: [22] ............................................................................................ 25 Obrázek 9. Schéma komunikace PHP serveru s Java serverem. Zdroj: [51] ............................................. 26 Obrázek 10. Pokrytí zdrojových kódů testy. Zdroj: [22] .................................................................................... 27 Obrázek 11. Detail pokrytí kódu. Zdroj: [22] ......................................................................................................... 29 Obrázek 12. Výběr typu projektu ................................................................................................................................ 41 Obrázek 13. Výběr názvu projektu ............................................................................................................................. 42 Obrázek 14. Výběr typu souboru ................................................................................................................................. 42 Obrázek 15. Zařazení do projektu .............................................................................................................................. 43 Obrázek 16. Nový report ................................................................................................................................................. 43 Obrázek 17. Vytvoření nového datového zdroje ................................................................................................... 44 Obrázek 18. Datový zdroj JDBC .................................................................................................................................... 44 Obrázek 19. Připojení ovladače Connector/J ......................................................................................................... 45 Obrázek 20. Nový datový zdroj .................................................................................................................................... 45 Obrázek 21. Typ SQL Select Query .............................................................................................................................. 45 Obrázek 22. Zadání SQL dotazu ................................................................................................................................... 46 Obrázek 23. Výsledná tabulka reprezentující datovou skupinu .................................................................... 46 Obrázek 24. JavaScriptový výraz místo vlastní hodnoty ................................................................................... 47
37
38
Příloha A.
Obsah přiloženého CD Tato práce rozšiřuje softwarový produkt, který nemá otevřenou licenci. Proto nemohly být v této práci zveřejněny kompletní zdrojové kódy. Uvádím nicméně zdrojové kódy jejichž jsem výhradním autorem. •
BP.pdf – tisknutelná podoba této práce.
•
BP.docx – zdrojový dokument této práce.
•
Reporty – složka obsahující vypracované reporty v programu BIRT Report Designer.
•
Reporting – složka obsahující část portálu Nume.cz, kterou jsem v rámci této práce vypracoval.
•
JavaBridge – složka obsahující aplikaci PHP/Java Bridge s aktualizovaným prostředím BIRT Runtime 3.7.0 a doplněným ovladačem pro databázi MySQL.
39
40
Příloha B.
Tvorba reportu v BIRT Report Designeru V této příloze je popsán návod na konfiguraci BIRT Report Designeru a tvorbu jednoduchého reportu, který vypisuje data na základě SQL dotazu do tabulky. Vychází především mých vlastních zkušeností, které jsem při používání tohoto programu získal. Všechny obrázky jsem vytvořil sám a proto u nich neuvádím zdroj.
1. Instalace Poslední verzi programu stáhneme ze stránek [25]. Budeme využívat data z databáze MySQL, a proto budeme potřebovat doplnit ovladač Connector/J [52]. Ten si zatím pouze stáhneme ze stránek [52], používat se bude až později.
2. Vytvoření nového projektu Vytvoříme nový projekt pomocí hlavní nabídky: File – New – Project – Business Intelligence and Reporting Tools – Report Project (obrázek 12). Dále vybereme jméno projektu (obrázek 13).
Obrázek 12. Výběr typu projektu
41
Obrázek 13. Výběr názvu projektu
3. Vytvoření nového reportu Vytvoříme nový report pomocí hlavní nabídky: File – New – Other... – Business Intelligence and Reporting Tools – Report (obrázek 14). Ve druhém kroku zvolíme název reportu a vybereme projekt, který jsem vytvořili v kroku předchozím (obrázek 15).
Obrázek 14. Výběr typu souboru
42
Obrázek 15. Zařazení do projektu
Po vytvoření nového reportu se Eclipse přepne do zobrazení Report Design (obrázek 16).
Obrázek 16. Nový report
43
4. Vytvoření datového zdroje Dalším krokem je vytvoření tzv. Data Source, neboli datového zdroje (obrázek 17). Datový zdroj bude v našem případě představovat připojení k databázi, ke které se budeme připojovat právě pomocí dříve staženého ovladače MySQL Connector/J. V následující nabídce zvolíme typ JDBC Data Source (obrázek 18) a vybereme jméno. Poté vyskočí okno s parametry datového zdroje. Pomocí tlačítka Manage Drivers vyvoláme dialogové okno zobrazené na obrázku 19. V tom přidáme dříve stažený ovladač a potvrdíme. V předchozím okně vybereme ovladač com.mysql.jdbc.Driver (v5.1) a vyplníme Database URL. Jeho formát je následující: jdbc:mysql//localhost/<Jméno databáze>
Obrázek 17. Vytvoření nového datového zdroje
Obrázek 18. Datový zdroj JDBC
44
Obrázek 19. Připojení ovladače Connector/J
5. Vytvoření datové skupiny V tomto kroku vytvoříme tzv. datovou skupinu (viz obrázek 20). Ta v našem případě představuje dotaz do databáze. Zvolíme tedy typ SQL Select Query (obrázek 21) a v dalším kroku zadáme dotaz do databáze (obrázek 22).
Obrázek 20. Nový datový zdroj
Obrázek 21. Typ SQL Select Query
45
Obrázek 22. Zadání SQL dotazu
6. Vytvoření tabulkového výpisu Nyní máme připravený datový zdroj, představující určitý pohled do databáze. Přetáhneme ho z levého panelu přímo do hlavní části obrazovky. Tím se nám vygeneruje tabulkový výpis tohoto datového zdroje (viz obrázek 23). Dvojitým poklepáním na jednotlivé hlavičky lze změnit jejich popisek. Dvojitým poklepáním na jednotlivé datové položky lze vyvolat dialog s jejich parametry (obrázek 24). Tam lze například výslednou hodnotu upravit pomocí výrazu v jazyce Java Script. Při takové úpravě si musíme dát pozor na datový typ položky – pokud chceme vypsat například textové „Ano“ a „Ne“ místo jedničky a nuly, musíme změnit datový typ z celého čísla (Integer) na řetězec (String).
Obrázek 23. Výsledná tabulka reprezentující datovou skupinu
46
Obrázek 24. JavaScriptový výraz místo vlastní hodnoty
