Systém pro automatizaci srovnávání produktů konkurence

Mendelova univerzita v Brně Provozně ekonomická fakulta Systém pro automatizaci srovnávání produktů konkurence Bakalářská práce Vedoucí práce: Ing. Ondřej Popelka, Ph.D. Pavel Řezníček Brno 2013

List zadání práce

Děkuji vedoucímu práce Ing. Ondřeji Popelkovi, Ph.D. za cenné rady, konstruktivní připomínky a čas, který mi při konzultacích věnoval. Také děkuji své rodině a nejbližším přátelům, kteří mě při tvorbě práce podporovali a dodávali mi inspiraci.

Prohlašuji, že zadanou bakalářskou práci jsem vypracoval samostatně pod vedením Ing. Ondřeje Popelky, Ph.D. a v seznamu literatury uvedl veškeré použité zdroje. V Brně dne 22. května 2013

Abstract Řezníček, P. System for automation of comparison of the competitive products. Bachelor thesis. Brno, 2013. The thesis describes the design and the implementation of the system ADETA. The system is intended for the administrators of the e-shops and it provides them an opportunity to monitor and compare products of the competitors. In the first part, there are the descriptions of actual possibilities of monitoring the competitors and there is also a comparison of the options, usable by the administrator of the e-shop. In the second part, there is an analysis of the new comparative system along with the description of the technologies, usable to solve the problems. The third part is dedicated to the implementation of the system and there are the descriptions of its parts. In the conclusion, there s an assessment of the results and there are outlined some more steps for the expansion of the system. Keywords Monitoring of competitors, web application, products comparison, wget, DOM, XPath. Abstrakt Řezníček, P. Systém pro automatizaci srovnání produktů konkurence. Bakalářská práce. Brno, 2013. Text práce popisuje návrh a implementaci systému ADETA, určeného správcům e-shopů, který umožňuje sledování a porovnávání produktů konkurence. V první části práce je popsán současných stav možností sledování konkurence a jsou zde porovnány jednotlivé správcem e-shopu využitelné varianty. V druhé části je rozebrán návrh nového srovnávacího systému spolu s popisem technologií využitelných k řešení daného problému. Třetí část práce je věnována implementaci systému a popisu jeho jednotlivých částí. V závěru je výsledek práce zhodnocen a jsou zde nastíněny některé další možné kroky pro rozšiřování systému. Klíčová slova Sledování konkurence, webová aplikace, porovnání produktů, wget, DOM, XPath.

Obsah 11 Obsah 1 Úvod a cíl práce 15 1.1 Úvod... 15 1.2 Cíl práce... 15 2 Možnosti sledování konkurence 17 2.1 Srovnávací systémy... 17 2.2 Existující systémy pro hromadné srovnání... 19 2.2.1 Price checking... 19 2.2.2 Karsa Monitor... 20 2.3 Shrnutí... 22 3 Návrh řešení 25 3.1 Uživatel systému... 27 3.2 Relační datový model... 28 3.3 Stažení webu... 32 3.3.1 curl... 33 3.3.2 Wget... 33 3.3.3 HTTrack Website Copier... 34 3.3.4 Výběr nástroje... 34 3.4 Zpracování obsahu webu... 34 3.4.1 XML... 35 3.4.2 HTML DOM... 36 3.4.3 Výběr nejvhodnějšího nástroje... 37 3.4.4 Vyčištění HTML kódu... 37 3.5 Definice atributů produktu... 38 4 Implementace 43 4.1 Použité technologie... 43 4.2 Stažení a zpracování webu... 44 4.2.1 Konfigurační parametry a spuštění Wget... 44

12 Obsah 4.2.2 Konfigurace Tidy... 45 4.2.3 Převod kódování stránek... 46 4.2.4 Získání hodnoty elementu... 47 4.2.5 Zpracování zrcadla webu... 48 4.3 Uživatelské rozhraní... 49 4.3.1 Získání XPath cesty... 51 4.3.2 Dynamický formulář definice atributů produktu... 54 4.3.3 Ukazatel průběhu zpracování... 54 4.3.4 NiftyGrid... 56 4.4 Model pro řízení práv a přístupů... 58 4.5 Instalace systému... 59 5 Závěr 61 6 Literatura 63 A Náhledy vybraných částí aplikace 66

Seznam obrázků 13 Seznam obrázků Obr. 1 Rozdělení trhu porovnávačů zboží v roce 2012 [25] 18 Obr. 2 Ukázka XML zdroje dat pro porovnávač zbozi.cz 19 Obr. 3 Ukázka XLS výstupu systému Price checking 20 Obr. 4 Standardní report z aplikace Karsa Monitor 22 Obr. 5 Sekvenční diagram použití systému 26 Obr. 6 ER diagram systému 29 Obr. 7 Příklad použití SAX rozhraní 36 Obr. 8 Diagram aktivit definice atributu 39 Obr. 9 Prototyp části aplikace k definici atributů produktu 41 Obr. 10 Prototyp rozložení prvků aplikace 50 Obr. 11 Sitemap webové aplikace 51 Obr. 12 Ukázka vybraných produktů stejného webu 53 Obr. 13 Ukázka formuláře pro přidávání atributů produktu 54 Obr. 14 Ukazatel průběhu zpracování 55 Obr. 15 Využití NiftyGrid pro práci s uživateli systému 56 Obr. 16 Využití NiftyGrid pro práci s firmami 57 Obr. 17 Ukázka části aplikace pro srovnávání produktů 66 Obr. 18 Ukázka části aplikace pro zrcadlení webu 67

14

Úvod a cíl práce 15 1 Úvod a cíl práce 1.1 Úvod Internetový obchod je v dnešní době běžným způsobem jak nabízet a prodávat své produkty, ať už v podobě výrobků nebo služeb. Funkce internetového obchodu (e-shopu) jsou závislé na jeho poskytovateli a na implementaci pro zákazníka. Na českém trhu je široké spektrum poskytovatelů, jejichž nabídka se liší zejména v doprovodných službách, jako jsou SEO, webový hosting nebo napojení na účetní systém. Co už ale mnoho poskytovatelů nenabízí, je možnost porovnání zboží majitele e-shopu s konkurencí a to zejména porovnání cen produktů. Právě cena produktu je při rozhodování konečného zákazníka o koupi produktu jedním z hlavních kritérií, a proto by měl provozovatel e-shopu ceny na trhu sledovat a určitým způsobem se jim přizpůsobovat. Pro určité prodejce je důležité srovnání nejen cen, ale také například množství produktů na skladě a dalších položek jednotlivých produktů. Konkurenční boj existuje napříč všemi odvětvími a získat určitou výhodu nad ostatními je čím dál těžší. Majiteli internetového obchodu navíc zabere spoustu času průzkum konkurence a její srovnávání s vlastními produkty. S využitím vhodných nástrojů je možné tento proces srovnávání určitým způsobem zautomatizovat, díky čemuž lze dosáhnout úspory drahocenného času a s vhodnou strategií získat konkurenční výhodu na daném trhu. Prováděný monitoring cen konkurence není pouze o zlevňování svých produktů a dosahování lepšího postavení v cenových srovnávačích jako je například Heureka.cz, ale také o vyhledávání položek, kde si prodejce může dovolit zdražit a zvyšovat tím svůj hospodářský zisk. 1.2 Cíl práce Cílem této práce je vytvořit systém ADETA umožňující správcům e-shopů srovnávat své produkty s konkurencí se zaměřením nejen na srovnávání ceny, ale i dalších parametrů produktů. V práci nejdříve prozkoumám současné možnosti majitelů e-shopů v oblasti sledování produktů svých konkurenčních subjektů. Na základě informací získaných průzkumem zhodnotím dostupné možnosti sledování konkurence a popíši technologie využitelné k řešení této problematiky. Následně navrhnu nový systém, který bude sloužit k získávání libovolných uživatelem definovaných parametrů produktů konkurenčních subjektů pomocí analýzy HTML kódu webů konkurenčních e-shopů. Tento systém umožní snadné srovnání ceny a dalších parametrů vlastních produktů se zvolenou konkurencí. Navržený systém pomocí vhodných technologií implementuji formou webové aplikace a v práci rozeberu její hlavní části. V závěru práce zhodnotím, jaké přínosy vytvořená aplikace uživatelům poskytuje, v jakých ohledech se liší od existujících systémů, a nakonec stručně popíši další možné kroky při jejím rozšiřování.

Možnosti sledování konkurence 17 2 Možnosti sledování konkurence Internetové obchodování se postupem času stalo již běžnou součástí nákupních praktik spotřebitelů. Ze studie E-comerce 2012 [27] od společnosti Gemius vyplývá, že v roce 2012 na českém trhu existovalo přibližně 21 tisíc aktivních internetových obchodů, které jen v roce 2011 vygenerovaly obrat přibližně kolem 37 miliard Kč. Z průzkumu také vyplývá, že pro nákup zboží či služeb použilo internet celkem 64% obyvatelstva ČR (34% z nich nakupovalo více než jednou). Nejčastějšími uvedenými důvody, proč lidé využili obchodování přes internet, bylo ušetření času, možnost porovnávání cen, větší výběr zboží a nižší ceny než v kamenných obchodech. Oproti většině Evropy, kde je běžné platit kartou, používají čeští zákazníci raději platbu dobírkou a to z důvodu obavy ze zneužití své platební karty. Nakupované produkty si zákazníci vybírají v e-shopech, jež jsou zaměřeny vždy na určitou část trhu. V každém odvětví existuje několik e-shopů, které nabízejí stejné produkty a to, co spotřebitele ovlivňuje při rozhodování, kde si nakonec produkt koupí, je mimo jiné cena produktu. Způsobem, jak si udržet stávající zákazníky a pokusit se přilákat zákazníky nové, je poskytování vlastních produktů za nejnižší ceny na trhu. K tomu je potřeba provádět určitým způsobem průzkum stavu konkurence. Ruční průzkum, který by mohl představovat zjišťování cen konkurence, jejich zapisování a porovnávání s vlastními cenami, je zejména časově velice náročná záležitost. Pro ušetření času, ale i finančních prostředků spojených se mzdami pracovníků, kteří by průzkum vykonávali, nastává nutnost využít na řešení tohoto problému nějaký automatizovaný nástroj. 2.1 Srovnávací systémy Srovnávací systém je nástroj určený pro koncového zákazníka, který mu umožní porovnat parametry nakupovaného výrobku v různých konkurenčních e-shopech. Zákazník sleduje nejen cenu výrobku, ale také ostatní parametry jako je například doba dodání, počet výrobků skladem nebo dostupnost v prodejnách. Systémů umožňujících toto srovnání produktu je na internetu veliké množství. Uvádím výčet některých českých srovnávacích systémů, které jsou provozovány jako webové portály. Zboží.cz http://www.zbozi.cz/ Heureka - http://www.heureka.cz/ Srovname.cz - http://www.srovname.cz/ Hyper zboží - http://www.hyperzbozi.cz/ Hledejceny.cz - http://www.hledejceny.cz/ Monitor.cz - http://www.monitor.cz/

18 Možnosti sledování konkurence Nejlepší ceny - http://www.nejlepsiceny.cz/ SrovnaniCen.cz - http://www.srovnanicen.cz/ NejNákup.cz - http://www.nejnakup.cz/ Podle studie spojené s projektem Shoptet.cz si v roce 2012 český trh rozdělili srovnávače zboží zbozi.cz se 44% trhu a heureka.cz se 40% trhu. Zbylých 16% připadlo dalším menším systémům jako například srovnavame.cz nebo hyperzozi.cz. [27] Obr. 1 Rozdělení trhu porovnávačů zboží v roce 2012 [25] Účelem srovnávacích systémů, které o sledovaném produktu přehledně na jednom místě poskytují informace zejména o ceně produktu z různých e-schopů, je především ušetřit čas koncového zákazníka při koupi výrobku. Zákazník nemusí procházet nabídky jednotlivých e-shopů a systém mu umožní jednoduše stanovovat cenové stropy produktů, nebo řadit a filtrovat výsledky hledání, které vidí přehledně na jednom místě. Určitou nevýhodou je, že s využitím srovnávacího systému může zákazník najednou srovnávat vždy pouze jeden produkt. Toto srovnání se navíc provádí pouze pro produkty e-shopů, které jsou do systému registrovány a poskytly XML zdroj (feed) 1 svého zboží, jehož ukázka je uvedena na obrázku 2. XML feed zboží se pomocí e-shopového rozhraní v určitých správcem definovaných intervalech 1 Speciální datový soubor ve formátu XML (extensible Markup Language) s přesně definovanou strukturou, představující seznam všech produktů e-shopu, které jsou určeny ke srovnávání.

Možnosti sledování konkurence 19 nebo ručně aktualizuje. Hodnoty produktů jsou z něj následně systémem pravidelně získávány nejčastěji 1 za 24h. Obr. 2 Ukázka XML zdroje dat pro porovnávač zbozi.cz 2.2 Existující systémy pro hromadné srovnání Na českém trhu se v současné době vyskytují dva nástroje, které umožňují automatizovaně srovnávat větší množství produktů s uživatelem definovanou částí konkurence. Prvním popisovaným nástrojem je Price checking, tím druhým je nástroj Karsa Monitor. 2.2.1 Price checking Price checking je webová aplikace, která umožňuje porovnávání cen výrobků v e-shopech nejen českých, ale i slovenských a maďarských. Zaměřuje se převážně na bílé zboží (pračky, ledničky, myčky nádobí), TV a audiotechniku (televize, mp3/4 přehrávače, DVD technika, reproduktory), počítače (hardware, software), pneu a hračky. Aplikace sleduje přes 250 výrobců ve více než 200 e-shopech a další výrobce a e-shopy je možné za příplatek do aplikace přidat. [24] Pro porovnání cen výrobků musí uživatel nejdříve zadat vstupní údaje. Vstupním údajem může být název porovnávaného výrobku (např. HTC One V) nebo v souboru 2 definovaný seznam výrobků, který se do aplikace importuje. Tento soubor potom aplikace zpracuje a doplní o údaje cen výrobků konkurenčních e-shopů, které si uživatel vybere z nabídky dostupných e-shopů. Ke spárování a porovnání odpovídajících produktů využívá aplikace heuristické algoritmy, které k sobě přiřazují výrobky s nejlepší dostatečnou shodou. 2 Soubory typu XSL nebo XML, které mohou být exportovány přímo z e-shopu.

20 Možnosti sledování konkurence Toto přiřazování může uživatel v aplikaci změnit a výrobky k sobě libovolně přiřazovat sám. V aplikaci pak porovnání např. 2000 výrobků na 20-ti e-shopech trvá měně než 5 minut, uvádí prodejce. Upravený soubor s doplněnými cenami produktů konkurence je po zpracování nabídnut ke stažení. Obr. 3 Ukázka XLS výstupu systému Price checking Data o cenách výrobků jsou v databázi systému aktualizována pravidelně 2x týdně a dochází tak k určité neaktuálnosti údajů, které se například v období svátků mohou měnit ze dne na den a uživatel systému na ně tak nestíhá reagovat. V aplikaci lze kromě porovnání cen výrobků provádět také statistické pohledy na vývoj cen jednotlivých výrobků a pozorovat data z minulosti. Cena licence za užití aplikace se odvíjí zejména od množství sledovaných e-shopů, kde hraje roli, zda se jedná o již sledovaný nebo nový e-shop či nového výrobce. Noví sledovaní výrobci nebo celé e-shopy, které požaduje uživatel zařadit do srovnávání, cenu výrazně zvedají a ze základních 6000 Kč/měsíc 3 se může cena za licenci dostat až k 65000 Kč/měsíc. [24] 2.2.2 Karsa Monitor Karsa Monitor je projektem společnosti KARSA TECHNOLOGIES, s.r.o., která se v minulosti zabývala vývojem e-shopů. Tento projekt je provozován jako webová 3 Částky jsou uvedeny v cenách bez DPH

Možnosti sledování konkurence 21 služba určená pro majitele e-shopů a její hlavní funkcí je pravidelné denní monitorování cen produktů konkurenčních e-shopů. Umožňuje zákazníkovi monitorovat tisíce produktů z širokého spektra kategorií 4 u více než 250 e-shopů. [12] Aktualizace dat probíhá automaticky každý den pomocí webové služby, XML nebo CSV souboru dle preferencí zákazníka. Použití uživatelské části této webové aplikace je rozděleno na čtyři samostatné kroky: 1. Výběr sortimentu Zákazník si nejdříve určí kategorii produktů (např. bílé zboží, foto, parfémy, pneumatiky), u kterých chce monitorování cen provádět. Jednotlivé hlavní kategorie jsou dále děleny do podkategorií. 2. Volba konkurence Po zvolení kategorie, kterou chce zákazník sledovat, musí určit z nabídky dostupných e-shopů ty, které pro něj představují konkurenci. U zvolených e-shopů bude prováděno monitorování cen. Při výběru e-shopů se u každého zobrazuje počet monitorovaných produktů ve zvolené kategorii. 3. Odeslání poptávky Dalším krokem je zaslání formuláře s kontaktními informacemi o zákazníkovi (jméno, příjmení, společnost, email, telefon a adresa zákazníkova obchodu). Po odeslání formuláře zákazníka kontaktuje pověřený pracovník a prodiskutuje s ním podrobnosti projektu. Pokud požadovaný konkurenční e-shop není v nabídce nalezen, je možné jeho název napsat do Poznámky u odesílacího formuláře poptávky. Pracovníci Karsa Monitor pomocí rozhraní odděleného od webové aplikace web nového e-shopu analyzují a definují cesty k potřebným atributům produktu, zejména k názvu a ceně. Tyto cesty jsou při zpracování použity v algoritmech získávajících informace ze všech stránek webu e-shopu. 4. Získání aktuálních cen každý den Zákazníkovi jsou poté každý den poskytovány reporty o stavu konkurence ve formátu XSL, které si může dále libovolně upravovat. Na stránkách projektu je dostupný ceník služeb, pomocí kterého si lze snadno sestavit předběžnou kalkulaci požadovaných služeb. Výsledná částka se skládá z jednorázové ceny za přípravu projektu a dále jednotlivých měsíčních poplatků za provozování monitorovacích služeb. Se zvyšujícím se počtem sledovaných konkurentů měsíční cena za službu lineárně roste. Výhodou při zpracování velkého množství produktů je, že s rostoucím počtem reportovaných produktů se cena za report jednoho produktu snižuje. 4 Přehled hlavních kategorií dostupný z http://www.karsa-monitor.cz/category/4539/hlavni-kategorie

22 Možnosti sledování konkurence Obr. 4 Standardní report z aplikace Karsa Monitor Ve výsledném reportu, jehož příklad je vidět na obrázku 4, označuje barevné zvýraznění nejlevnější a nejdražší cenu. Na stupnici skladovosti jsou zvýrazněny hodnoty produktů, které jsou nejdražší, a zároveň jich má firma mnoho kusů na skladě. Opačná situace nastává, pokud je produkt nejlevnější a naskladněno je málo kusů. 2.3 Shrnutí Srovnávací systémy jako zbozi.cz či heureka.cz jsou určeny pro koncové spotřebitele, kteří ve většině případů srovnávají pouze jeden produkt. Rychlost srovnání jednoho produktu a zobrazení výsledků je závislá na rychlosti internetového připojení uživatele, i tak ale ve většině případů zabere řádově pouze několik sekund (±5s). Pro provozovatele e-shopu, který srovnává někdy i tisíce svých produktů, jsou pro jeho účely tyto srovnávací systémy nedostačujícím nástrojem. Srovnání všech svých produktů je v nich velice časově náročné a nemusejí pokrývat celou požadovanou konkurenční oblast. Price checking je aplikace poskytující majiteli e-shopu přehlednou formou informace o cenách konkurence. Kromě aktuálního stavu cen produktů v konkurenčních e-shopech, který je možné exportovat do souboru a získat z něj důležité

Možnosti sledování konkurence 23 informace pro cenovou tvorbu, poskytuje také různé statistické záznamy o cenách. Nevýhodou této aplikace je zaměření pouze na ceny produktů. Pro majitele e-shopu mohou být při budování cenové strategie důležité i některé další informace o produktech jako například množství zboží skladem. Karsa Monitor umožňuje majiteli e-shopu prohlížet pravidelné denní reporty z výsledků monitorování cen produktů konkurence. Do reportů z aplikace jsou kromě srovnání cen produktů zařazeny i informace o počtu vlastních výrobků na skladě. Na základě těchto údajů se lze rozhodovat při naskladňování nových výrobků. Informace o počtu výrobků skladem u produktů konkurence, použitelné při řízení stavu svých zásob, už však poskytovány nejsou. V případě větší konkurenční rivality v odvětví (5 a více konkurentů) licence za využití Price checking či Karsa Monitor výrazně podraží a s každým dalším novým sledovaným konkurentem její cena roste. Správa většího počtu dat je tak vykoupena vyšší cenou za poskytnuté služby. Majitelé menších nebo rozjíždějících se e-shopů bez většího vstupního kapitálu, kteří nedisponují dostatkem volných peněžních prostředků na využívání služeb těchto srovnávacích nástrojů, zůstávají neinformováni o pohybu cen a dalších položek produktů konkurence, která je na základě svých informací a cenové strategii v očích koncových zákazníků překoná. Na trhu chybí systém, který porovnává nejen ceny, ale i další libovolné uživatelem definované atributy produktů s produkty konkurence a neomezuje uživatele výběrem konkurence pouze z nabídky dostupných sledovaných e-shopů bez dalších příplatků. Proto je v této práci vytvořen systém ADETA, jehož návrh a následná implementace budou podrobněji popsány v následujících kapitolách.

Návrh řešení 25 3 Návrh řešení Systém pro srovnání produktů konkurence ADETA je nástroj určený majitelům internetových obchodů, který umožňuje porovnání parametrů vlastních produktů s produkty konkurence. Uživatel si definuje, jaké e-shopy chce sledovat a na jeho impuls systém stáhne stránky zvolených e-shopů, analyzuje jejich kód a uloží do databáze uživatelem definované informace o produktech (např. cena, počet kusu skladem, dostupnost). Velké množství uložených dat o konkurenčních produktech systém umožní uživateli přehledně porovnat se svými vlastními produkty. Na základě informací získaných z tohoto přehledu může uživatel upravovat svou stávající cenovou strategii k dosažení lepšího postavení na trhu. Schéma zobrazující kroky uživatele, které musí provést pro srovnání produktů konkurenční firmy se svými produkty je zobrazeno na obrázku 5.

26 Návrh řešení Obr. 5 Sekvenční diagram použití systému Systém ADETA je navržen jako webová aplikace přístupná odkudkoliv, kde je k dispozici připojení k Internetu, pouze s využitím webového prohlížeče. Pro majitele e-shopů je práce s webovým prohlížečem přirozená a při používání systému budou navíc některé funkce prohlížeče 5 velice užitečné a usnadní práci se systémem. 5 Získávání XPath výrazů pomocí nástroje Developer Tools v prohlížeči Google Chrome, které bude popsáno v kapitole 4.2.4.

Návrh řešení 27 3.1 Uživatel systému Systém ADETA je navržen pro správce e-shopů, kteří chtějí získat přehled nad svou konkurencí. Člověk, který se důkladněji zajímá o svou konkurenci, se snaží nalézt způsoby jak zvýšit svůj zisk a má přinejmenším zájem na tom vědět, jak jeho e-shop funguje. Předpokládám tedy, že pořizovatelem systému je člověk s určitou počítačovou gramotností, který zná alespoň základy jazyka HTML a dokáže se v něm orientovat a zároveň pro něj nebude práce s webovým rozhraním ničím novým. Ačkoliv by systém měl dokázat využívat a ovládat kdokoliv, jsou v něm prováděny určité operace, které by měl uskutečňovat pouze pověřený a proškolený pracovník. Z toho důvodu je oprávnění k vykonávání operací v systému rozděleno do tří základních uživatelských úrovní. Uživatel Člověk bez potřebných znalostí používaných technologií, který systém využívá převážně ke srovnávání produktů s konkurencí a na základě získaných informací si utváří závěry pro své budoucí jednání. Tento uživatel je oprávněn k činnostem jako: srovnání cen produktů srovnání dalších libovolných atributů produktů zobrazení a úprava atributů vlastních produktů zobrazení konkurenčních firem přidávání dalších konkurenčních firem úprava údajů o firmách odstranění firem, které si nepřeje nadále sledovat sledování stavu konkurence z pohledu jiné firmy Správce Osoba, se znalostmi struktury HTML jazyka, která v systému provádí změny a je zodpovědná za ukládané informace. Správce dědí veškerá oprávnění od uživatele a navíc je oprávněn k: stahování e-shopu konkurenční firmy definování sledovaných atributů produktů při zpracování staženého webu zobrazení náhledu zpracování zpracování staženého webu

28 Návrh řešení Administrátor Osoba s nejvyššími uživatelskými oprávněními v systému, pověřená zejména správou uživatelských účtů aplikace. Dědí oprávnění od role správce a má navíc oprávněním k: přidávání nových uživatelů úprava údajů a mazání stávajících uživatelů změny hesel uživatelů 3.2 Relační datový model K uchování potřebných dat a budoucímu přístupu k nim byla zvolena relační databáze. ER diagram 6 na obrázku 6 zobrazuje navrženou strukturu tabulek a jejich vzájemné vazby. Diagram obsahuje 10 tabulek, jejichž význam a atributy budou popsány v následujícím textu. Při navrhování a následnému vytváření struktury modelu jsem vycházel z několika základních požadavků na funkce systému, které by měl uživateli poskytovat. Těmito požadavky jsou: sledování libovolného počtu firem srovnávání cen produktů libovolných firem srovnání dalších různých volitelných atributů produktů možnost sledování stavu konkurence z pohledu jiné firmy identifikování nových cen a nových produktů firem V rámci této subkapitoly lze název firma ztotožňovat přímo s jejím e-shopem. 6 Entiti-Relationship diagram

Návrh řešení 29 Obr. 6 ER diagram systému 7 Tabulka firmy id_firmy primární klíč nazev unikátní klíč url priorita V tabulce jsou uchovávány informace o e-shopech firem, jejichž produkty jsou sledovány. Ukládány jsou zejména informace o názvu firmy, dále URL adrese jejího e-shopu, odkud jsou získávány informace o produktech příslušné firmy a také 7 Žlutý klíč atribut je primárním klíčem, Prázdný diamant nepovinný atribut, Modrý diamant povinný atribut, Červený diamant atribut je cizím klíčem

30 Návrh řešení je ukládána hodnota priority. Čím je hodnota priority menší, tím významnější firma je a firma s nejnižší hodnotou priority je považována za firmu primární. Veškeré údaje o firmě jsou zadávány ručně při definici nové firmy nebo při modifikaci firmy již existující. Tabulka produkty id_produkty primární klíč identifikator unikátní klíč Tabulka poskytuje přehled o produktech, které jsou předmětem srovnávání. Každý produkt má přiřazen identifikátor, což je jeho jedinečná specifická hodnota. Například identifikátor knihy je její ISBN, u jiných produktů to může být kód EAN nebo pouze název produktu. Identifikátor produktu je povinný atribut, jehož hodnota by měla být vhodně zvolena, protože na základě hodnoty identifikátoru probíhá spárování produktů různých firem při porovnávání jejich cen a dalších atributů. Hodnoty tabulky produkty se plní při hromadném zpracování staženého webu hodnotami získanými syntaktickou analýzou HTML kódu jednotlivých souborů s využitím jazyka XPath. Tabulka produkty_firmy id_produkty_firmy primární klíč id_firmy cizí klíč idenfitikující firmu, ke které produkt patří id_produkty cizí klíč určující produkt, jehož cenu ukládám a spolu s id_firmy tvoří unikátní klíč cena Tabulka je asociační tabulkou mezi tabulkami produkty a firmy. Pro další budoucí využití v aplikaci je zde definován primární klíč id_produkty_firmy. Položky tabulky produkty_firmy reprezentují produkty jednotlivých firem, u kterých je uchováván údaj o ceně. Hodnota ceny se ukládá při zpracování jednotlivých souborů obrazu webu e-shopu. Je to jeden z povinných údajů o produktu, který sleduji vždy a podle kterého produkty porovnávám, a proto je oddělen od ostatních atributů produktu a umístěn již v této tabulce. Tabulka p_atributy id_atributy primární klíč nazev unikátní klíč Tabulka poskytuje přehled o názvech atributů produktů. Závisí na uživateli a konkrétním použití aplikace, které atributy použije. U produktu může například uživatel definovat atributy kusů skladem, dostupnost a další.

Návrh řešení 31 Tabulka pf_data id_pf_data primární klíč id_produkty_firmy cizí klíč představující produkt konkrétní firmy id_p_atributy cizí klíč určující atribut, jehož hodnotu ukládám a spolu s id_produkty_firmy tvoří unikátní klíč hodnota Tabulka poskytuje informace o hodnotách sledovaných atributů jednotlivých produktů, které tento produkt lépe popisují (např. počet kusů na skladě). Tabulka nove_produkty id_nove_produkty primární klíč id_produkty atribut identifikující produkt id_firmy atribut identifikující firmu, ke které se nový produkt vztahuje a spolu s id_produkty tvoří unikátní klíč Tabulka slouží k identifikaci produktů firem, které byly u jednotlivých firem získány nově, tzn., při posledním minulém získávání informací o produktech konkrétní firmy tyto produkty firma v nabídce neměla. Při každém novém zahájení zpracování produktů určité firmy jsou hodnoty pro danou firmu z této tabulky smazány a je prováděno naplňování hodnotami novými. Tabulka nove_ceny id_nove_ceny primární klíč id_produkty atribut identifikující produkt, jehož cena byla změněna id_firmy atribut identifikující firmu, ke které se nový produkt vztahuje a spolu s id_produkty tvoří unikátní klíč Tabulka slouží k identifikaci produktů firmy, jejichž ceny se od posledního minulého získávání informací o produktech této firmy změnily. I zde jsou při každém novém zahájení zpracování produktů určité firmy hodnoty zpracovávané firmy z této tabulky smazány a je prováděno naplňování novými hodnotami. Tabulka uzivatele id_uzivatele primární klíč id_u_opravneni cizí klíč určující roli, pod kterou uživatel v systému vystupuje prihlasovaci_jmeno jméno, pod kterým se uživatel přihlašuje do systému

32 Návrh řešení heslo atribut, který se spolu s atributem prihlasovaci_jmeno kontroluje při přihlašování uživatele do systému jmeno prijmeni email kontaktní údaj o emailu uživatele telefon údaj o telefonním čísle uživatele Tabulka uzivatele uchovává informace o jednotlivých uživatelích systému. Změny údajů o uživatelích provádí vždy pouze uživatel s rolí admin. Kromě přihlašovacího jména a hesla, které slouží k autorizaci uživatele do systému, se o uživateli ukládá také informace o jeho jméně, příjmení a jeho kontaktních údajích. Tabulka u_opravneni id_u_opravneni primární klíč role název role, pod kterou uživatel v systému vystupuje Tabulka slouží jako číselník rolí, které určují oprávnění uživatele k přístupu do jednotlivých částí aplikace. Tabulka progress souboru_celkem počet všech souborů zrcadla webu souboru_zpracovano počet doposud zpracovaných souborů, který se při procesu zpracování v určitých časových intervalech aktualizuje souboru_chybovych počet souborů, kde systém při zpracování nezískal identifikátor produktu nebo jeho cenu Tabulka progress se využívá při zpracování zrcadla webu. Při zpracování jsou do ní systémem ukládány údaje o současném stavu zpracování a tyto informace jsou uživateli zobrazovány pomocí ukazatele průběhu zpracování. 3.3 Stažení webu Informace o produktech konkurenčních firem lze získat z jejich e-shopů, kde firmy svým zákazníkům produkty nabízejí. Tyto informace chci z HTML stránek jednotlivých produktů získat pomocí sémantické analýzy kódu. Všechny stránky e-shopu jsou systémem analyzovány jednotlivě a musejí být nejdříve staženy na disk. Potřebuji využít nástroj, který umožní web e-shopu zrcadlit projde celý web rekurzivně a na lokální disk serveru vytvoří jeho offline verzi.

Návrh řešení 33 3.3.1 curl Jedním ze způsobů jak na disk stáhnout internetovou stránku, popřípadě stránky je využít jeden z produktů projektu curl 8. Prvním produktem je libcurl - knihovna pro TCP/IP protokoly, určená zejména pro HTTP komunikaci, podporovaná na nejrůznějších platformách od Solaris, NetBSD přes Windows až po Android. Druhým produktem je curl, nástroj spouštěný z příkazové řádky. Oba tyto produkty slouží ke stažení dat stránky ze zadaného URL a umožňují i nahrání souboru na server. Verze knihovny jsou k dispozici pro více než 40 jazyků včetně C/C++, Java, PHP a Python. [26] curl umožňuje při definici URL adres, které mají být staženy několik usnadnění. Jedním z nich je možnost zadat URL adresy výčtem za pomoci hranatých závorek. http: //www.cl.cam.ac.uk/ http: //www.cl.cam.ac.uk/ ~ rja14/papers/se - 01.pdf http: //www.cl.cam.ac.uk/ ~ rja14/papers/se - 02.pdf http: //www.cl.cam.ac.uk/ ~ rja14/papers/se - [01-24].pdf odpovídá... ~ rja14/papers/se - 24.pdf Dalším usnadněním je zadávání URL pomocí výčtu s využitím složených závorek. http : //www.something.name/page/{one, two,three}.pdf Tyto usnadnění zjednodušují definici stahovaných souborů. Při stahování celého e-shopu však neznám indexy prvního a posledního souboru, ani přesné názvy souborů. 3.3.2 Wget GNU Wget je program, vydávaný pod licencí GPL 9, pro stahování souborů z internetu pomocí protokolu HTTP a FTP. Původně byl naprogramován pro operační systém Linux, ale během vývoje vzniklo již několik verzí pro další operační systémy, jako jsou Mac OS X nebo Microsoft Windows. Wget pracuje velmi dobře na pomalých či nestabilních spojeních, kde se pokouší soubor získat tak dlouho, dokud není celý načtený. Podporuje využití proxy serverů, které mohou odlehčit síťovou zátěž a zrychlit stahování. [11] Wget umožňuje následovat odkazy z již stažených stránek a rekurzivně opakovat tuto činnost tak dlouho, dokud nejsou staženy všechny stránky ze zadané 8 http://curl.haxx.se/ 9 http://www.gnu.org/software/wget/

34 Návrh řešení domény. Konfiguračními parametry lze ovlivnit hloubku zanoření rekurze. Rekurzivní stahováním se web zrcadlí a vytváří se na serveru či lokálním disku jeho offline verze. Jednou z výhod Wgetu je velké množství konfiguračních parametrů, podrobně popsaných v obsáhlé dokumentaci, které uživateli umožňují detailně specifikovat co přesně a jakým způsobem se má stahovat. 3.3.3 HTTrack Website Copier HTTrack Website Copier je nástroj umožňující rekurzivní stažení webových stránek do lokálního adresáře, rekurzivní sestavení adresářů, získání HTML souborů, obrázků a dalších souborů. HTTrack lez využít jako knihovnu nebo GUI 10 aplikaci pro Windwos nebo Linux/Unix. Funkce HTTracku je konfigurovatelná řadou parametrů popsaných v dokumentaci. [20] 3.3.4 Výběr nástroje Všechny popisované nástroje umožňují získat HTML soubor přes FTP, HTTP nebo HTTPS protokol. Lze je spustit z příkazové řádky a jsou vydávány jako open source. Nástroj curl neumožňuje web stahovat rekurzivně, a pro takto navržený systém by byl uplatnitelný až po vlastním doimplementování potřebné funkcionality. HTTrack i Wget umožňují zrcadlit web, vyloučit ze stahování definované typy souborů (jpg, gif, css) a určit hloubku zanoření při stahování. Některé webové stránky si mohou provádět analýzy přístupů z programů, jako jsou Wget nebo HTTrack a jejich činnost případně přerušit a blokovat. Kontrolují se podobnosti v časech mezi jednotlivými žádostmi při stahování souborů webu. Konfigurační parametr --random-wait umožňuje Wgetu nastavit náhodný čas mezi žádostmi z intervalu 0.5 až 1.5*wait, kde wait je počet sekund nastavený u dalšího parametru --wait. Pomocí přístupu na web v náhodných časových intervalech dokáže obejít algoritmy kontrolující činnost těchto stahovacích robotů. Stažení kompletního zrcadla webu je operace, která může v určitých případech trvat i několik hodin a délka stahování pro mě při rozhodování mezi nástroji pro stahování nehrála roli. HTTrack měl při testování na pomalejším připojení problém s opětovným stažením souboru, který nebyl stažen kompletní. V důsledku toho nebyly ve správné podobě staženy vždy všechny soubory e-shopu. Wget s opětovným stahováním souborů neměl problémy a fungoval bez chyb, proto byl v systému využit. 3.4 Zpracování obsahu webu Ačkoliv podle schématu z obrázku 5 probíhá zpracování obsahu webu až po definici atributů produktu, bude v práci nejdříve popsána problematika zpracování 10 Graphical User Interface Grafické uživatelské rozhraní

Návrh řešení 35 obsahu webu a to z důvodu, že definice atributů produktu závisí na zvolené technologii zpracování. Ze souborů staženého zrcadla webu potřebuji pomocí syntaktické analýzy 11 HTML kódu získat uživatelem definované informace o produktech. Existuje několik možností jak tyto informace získat, ty budou v následujícím textu stručně popsány a následně bude vybrána nejvhodnější technologie. 3.4.1 XML První možností, která se nabízí, je zpracování HTML souboru jako XML souboru. K tomuto zpracování lze využit rozhraní SAX (Simple API for XML). SAX je parser založený na řízení pomocí událostí (event-driven), který soubor prochází vždy od začátku do konce. Pomocí rozhraní se vytváří vazba mezi událostmi, které generuje parser, a kódem. [21] V praxi to znamená, že se definují funkce, které se zavolají v okamžiku, kdy parser narazí na začátek elementu, obsah elementu, konec elementu, komentář apod. Zpracování jediné informace je rozděleno vždy na tři části: událost začátku elementu událost znakových dat událost konce elementu Je potřeba napsat stavový automat, který umožní identifikaci stavů a určí další postup při zpracování jednotlivých elementů. 11 Syntaktická analýza je proces, kterým se transformuje vstupní text do datové struktury, většinou stromu, jenž je vhodný pro pozdější zpracování a který zachovává hierarchii vstupních dat. http://cs.wikipedia.org/wiki/syntaktick%c3%a1_anal%c3%bdza

36 Návrh řešení Obr. 7 Příklad použití SAX rozhraní 3.4.2 HTML DOM HTML DOM je objektový model pro přístup k HTML dokumentům a k manipulaci s nimi. Dokument je reprezentován jako stromová struktura, kde každému elementu odpovídá jeden uzel stromu. [8] HTML DOM vyžaduje před samotným zpracováním souboru nahrání celého stromu dokumentu do paměti a až poté umožňuje z dokumentu získávat určité informace nebo nad ním provádět nějaké změny. U větších souborů (nad 10MB) zabírá DOM poměrně velkou část paměti a rychlost čtení z něj s rostoucí velikostí souborů klesá, což jsou jeho velké nevýhody. [1] Pro správné vytvoření stromu dokumentu musí zpracovávaný soubor splňovat podmínky validity 12. U souboru s nevalidní strukturou nemusí jít strom dokumentu vůbec vytvořit, popřípadě nemusí odpovídat skutečnosti, což znemožní správný pohyb po jeho uzlech. Elementům stromu odpovídají instance třídy DOMElement, atributům instance třídy DOMAttr a textovým uzlům pak instance třídy DOMText. Všechny uzly mají mnoho společných metod a vlastností. Nejdůležitějšími a pro mě podstatnými vlastnostmi jsou ty, které umožňují získat jméno uzlu (nodename) a jeho hodnotu (nodevalue). 12 Validita - sémantická správnost kódu. http://www.seo-konzultace.cz/vyznam-validity-kodu-pro-seo/

Návrh řešení 37 Na rozdíl od SAXu není potřeba dokument procházet od začátku do konce, ale můžu se v něm pohybovat dle vlastní potřeby, například pomocí vlastnosti childnodes, která vrací seznam podřízených uzlů, nebo vlastnosti parentnode, která vrací rodiče uzlu. K jednotlivým elementům dokumentu lze také přistoupit za pomoci metod getelementbyid() nebo getelementsbytagname(), které vracejí seznam uzlů odpovídajících hodnotám zadaným jako parametry těchto metod. V případě první uvedené metody je parametrem id hledaného elementu, u druhé zmíněné je to název elementu. [8] XPath 1.0 XPath (XML Path Language) [29] verze 1.0 definuje organizací W3C schválenou syntaxi popisu adres částí XML nebo HTML dokumentu. Adresuje stromový model dokumentu, k jehož jednotlivým uzlům se lze dostat pomocí výrazu zvaného cesta (location path). XPath cesty podobně jako cesty v systému souborů, navigují v rámci stromového modelu, kde identifikují množinu uzlů (node-set). Spolu s množinami uzlů podporuje XPath ještě další tři datové typy: logické hodnoty (boolean), čísla (number) a textové řetězce (string). Každý XPath výraz vrátí objekt jednoho z možných uvedených datových typů, s kterým lze následně pracovat. [23] 3.4.3 Výběr nejvhodnějšího nástroje S rozhraním SAX, pomocí kterého by bylo možno HTML soubor zpracovávat jako soubor XML, bych musel pro získání hodnot elementů procházet každý soubor od začátku do konce. Na jednotlivých stránkách mě však někdy zajímají pouze jejich malé části, z kterých potřebuji informace získat. HTML DOM, který umožňuje se ve stromu dokumentu pohybovat libovolně, představuje lepší variantu. Nejdůležitějším rozhodovacím kritériem pro mě, i přes tuto výhodu DOM, byl způsob definice cesty atributu produktu. Tuto definici v aplikaci provádí samotný uživatel a měla by tedy být co nejjednodušší. S využitím nástrojů moderních internetových prohlížečů má uživatel možnost získat XPath cestu k elementu pomocí několika kliknutí myši. Z důvodu, že každou staženou stránku zpracovávám samostatně a předpokládám, že její velikost nepřesáhne 10MB, nepředstavuje paměťová náročnost DOM parseru problém. S využitím jazyka XPath poté získám přístup k potřebným elementům stránky a jejich hodnotám, které uložím do databáze. 3.4.4 Vyčištění HTML kódu HTML stránky obrazu webu vždy nesplňují požadavky validity. Při zpracovávání souborů pomocí DOM a XPath, které jsem zvolil jako nejvhodnější nástroje, je však pro jejich správnou práci zapotřebí, aby HTML stránky validní byly. Ponechání struktury souborů v podobě, ve které byly staženy, by mohlo vést k chybám

38 Návrh řešení při vytváření stromu dokumentu a XPath výrazy by tak nevraceli správné výsledky. Zajistit potřebnou úroveň validity zpracovávaných souborů pro správné vytvoření stromu dokumentu a tím dosáhnout i správného fungování jazyka XPath lze využitím nástroje HTML Tidy. Tento nástroj slouží ke kontrole validace a opravovaní chyb HTML, XHTML a XML souborů. Je vydáván pod GNU licencí a tedy volně dostupný. HTML Tidy je kompilován přes příkazový řádek, nebo využíván jako dynamická knihovna. Knihovna je dostupná pro široké využití v aplikacích vyvíjených v jazycích PHP, Java, Python nebo Perl. [9] U souborů Tidy detekuje a opravuje řadu chyb v kódu a snaží se vytvářet strukturu odpovídajících značek, které jsou kompatibilní se standardy W3C a jsou podporovány ve většině webových prohlížečů. Podporuje standard HTML 4.0 a částečně i XML 1.0. Poslední, prozatím experimentální, verze HTML Tidy je rozšířena o podporu HTML5. [18] Nástroje knihovny Tidy jsou schopny opravit širokou škálu chyb nebo pouze upozornit na věci, které by měly být opraveny. Každá nalezená položka je opatřena indexem řádku a sloupce, takže je při konečném výpisu chyb zřetelné, kde problém nastal. Pro konkrétní představu jsem uvedl několik příkladů úprav, které Tidy dokáže v nevalidním souboru provádět: [18] doplnění chybějících koncových značek oprava neodpovídajících koncových značek oprava nesprávného pořadí značek doplnění uvozovek okolo hodnot atributů 3.5 Definice atributů produktu Systém ADETA jsem navrhl tak, aby jeho uživatel mohl u produktu srovnávat libovolný počet jeho atributů, které si sám zvolí. Srovnávané atributy definuje v systému pouze uživatel s příslušným oprávněním například na základě žádosti svého vedoucího pracovníka. Na obrázku 8 je zobrazen postup při definici atributu produktu.

Návrh řešení 39 Obr. 8 Diagram aktivit definice atributu Po zvolení firmy a úspěšném stažení webu jejího e-shopu je definice atributů produktu posledním krokem před zpracováním celého obrazu webu a ukládáním dat do databáze. Tato část systému je navržena tak, aby si uživatel mohl na jednotlivých souborech staženého webu otestovat, zda výsledná hodnota zadané XPath cesty odpovídá skutečné hodnotě na stránce webu, a až poté zahájit zpracování celého obrazu webu e-shopu. Po zvolení testovací stránky, kterou následně systém zobrazí, uživatel zvolí kódování, ve kterém jsou stránky e-shopu napsány. Dalším krokem uživatele je volba filtrovacího elementu. Tato položka slouží k identifikaci sledované katego-

40 Návrh řešení rie produktů na zpracovávaném webu. Na konkurenčním e-shopu mohou být nabízeny různé typy zboží současně (DVD, knihy, parfémy apod.) a je potřeba identifikovat pouze ty kategorie zboží, které chce zákazník sledovat. Pomocí definice XPath cesty elementu, určujícího typ zboží, a zadáním filtrovacího řetězce představujícího sledovanou hodnotu (např. 'DVD'), uživatel definuje kategorii e-shopu, jejíž produkty budou zpracovány. Ostatní kategorie budou při zpracování vynechány. Kromě povinných atributů, kterými jsou identifikátor a cena produktu, lze libovolně přidávat nebo ubírat i další sledované atributy. O atributech produktu jsou do databáze ukládány vždy dva údaje. Prvním údajem je jeho název, který při definici atributu zadává uživatel. Druhým ukládaným údajem o atributu je hodnota. Získání hodnoty atributu pro každý produkt je prováděno při zpracování jednotlivých souborů. Z každého souboru je vytvořen strom dokumentu přes HTML DOM, který pomocí jazyka XPath umožňuje přístup k uzlům stromu. Uživatel do systému zadá XPath výraz identifikující část HTML kódu, kde se zjišťovaný atribut nachází, a jeho hodnota je následně zobrazena. Hodnotu atributu lze před uložením do databáze ještě upravit. Uživatel má možnost oříznout z výsledné hodnoty určitý počet znaků (např. 3 znaky zleva). Může také na hodnotu aplikovat regulární výraz 13, který v aplikaci zadá, nebo použít jednu z funkcí pro transformaci textu (např. funkce pro převod znaků na velká či malá písmena). Tento proces lze provádět pro libovolný počet souborů, které si uživatel jeden po druhém volí z adresáře obsahujícího zrcadlo webu firmy. 13 Regulární výraz je vzorem, který popisuje obsah řetězce. Říká, co se v řetězci smí a nesmí vyskytovat, jaký je možný počet opakování těchto výskytů, na jaké pozici v řetězci má co být apod. https://akela.mendelu.cz/~darena/perl/regexp.html

Návrh řešení 41 Obr. 9 Prototyp části aplikace k definici atributů produktu

Implementace 43 4 Implementace V této kapitole popisuji technologie, které jsem při vývoji systému ADETA využil. Jsou zde také popsány některé konkrétní části aplikace spolu s problémy, které bylo nutné při jejich implementaci řešit. 4.1 Použité technologie HTML5 je specifikace jazyka HTML (HyperText Markup Language), který se využívá k definici obsahu webové stránky. Ačkoliv je verze 5 stále ve vývoji, je již nyní podporována řadou webových prohlížečů a oproti starší verzi HTML4 přináší vývojářům řadu nových elementů a atributů usnadňujících tvorbu webových aplikací. [7] CSS3 je nejnovější a v současné době stále vyvíjená verze jazyka nazývaného kaskádové styly (Cascading Style Sheets), který je určen k definici vzhledu stránek psaných ve značkovacích jazycích. jquery je open-source knihovna pro JavaScript, která poskytuje mnoho metod usnadňujících práci s JavaScriptem a je podporována všemi prohlížeči. Umožňuje průchod a manipulaci s HTML dokumentem, zpracování událostí, animace a zjednodušuje práci s technologií AJAX. [14] AJAX je zkratka pro Asynchronous JavaScript and XML. Tato technologie umožňuje měnit části stránky bez nutnosti celou stránku znovu načítat. Tento proces je nazýván jako částečné obnovení stránky. Všechny moderní prohlížeče poskytují XMLHttpRequest object, který se využívá k zasílání AJAX requestu na webový server a následnému získání dat, které server vrátí. JavaScript je v prohlížeči využit ke zpracování vrácených dat a modifikaci stránky. Při práci s AJAXem lze specifikovat, jaký typ dat má server vracet a lze využít prostý text, XML, HTML nebo JSON. [14] Pro samotnou implementaci aplikace jsem využil programovací jazyk PHP a Nette Framework, který nabízí vlastní šablonovací systém Latte, propracované ladící nástroje, podporu HTML5, AJAX a je v něm kladen velký důraz na bezpečnost. [22] Pro zpřehlednění kódu a oddělení aplikační logiky od kódu zobrazujícího data uživateli jsem využil návrhového vzoru MVP, který aplikaci rozděluje do 3 logických částí: [15] Model datový a zejména funkční základ celé aplikace obsahující aplikační logiku View vrstva zobrazující uživatelské rozhraní aplikace Presenter zpracovává požadavky od uživatele a na jejich základě volá příslušnou aplikační logiku (metody modelu) a předává data k zobrazení do View

44 Implementace Pro práci s databází jsem zvolil databázovou vrstvu dibi, která podporuje řadu databází jako: MySQL, PostgreSQL, SQ Lite, MS SQL, Oracle a obecné PDO. Aplikace je postavena na databázi MySQL, která však může být díky nezávislosti dibi na databázové platformě změněna. [3] 4.2 Stažení a zpracování webu 4.2.1 Konfigurační parametry a spuštění Wget Využití Wgetu jehož funkce byla popsána v kapitole 3.3.2 je velice široké a pomocí konfiguračních parametrů lze přizpůsobit jeho chování tak, aby prováděl potřebné operace k dosažení požadovaného výsledku. Pro stažení zrcadla webu jsem nastavil níže uvedené konfigurační parametry. U jednotlivých parametrů uvádím jejich krátkou i dlouhou podobu zápisu a jejich účel: [28] -np (--no-parent): při rekurzivním stahování nedovolit vstoupit do nadřazeného adresáře -nd (--no-directories): nevytvářet adresářovou hierarchii -o logfile (--output-file=logfile) : ukládat logy do souboru logfile.log -P prefix (--directory-prefix=prefix): nastavit adresář kam se bude zrcadlo ukládat -E (--adjust-extension): pokud se stáhnou soubory, které nekončí podle regulárního výrazu \.[Hh][Tt][Mm][Ll]?, přidat těmto souborům příponu html -w seconds (--wait=seconds): vyčkat zadaný počet sekund mezi pokusy o získání souboru -R rejlist (--reject rejlist): výčet přípon souborů, které nestahovat -r (--recursive): zapnout rekurzivní procházení -l depth (--level=depth): nastavit hloubku zanoření -m (--mirror): nastavit parametry vhodné pro zrcadlení webu Použitím této volby se dá současně nastavit rekurzivní stahování, nastavování timestampů soborů, nekonečná hladina zanoření a zákaz odstraňování dočasných souborů. Je to ekvivalent k použití voleb -r -N -l inf --no-removelistening. -t number (--tries=number): nastavit počet pokusů o stažení souboru

Implementace 45 public function mirrorcompanyeshop($id_firmy) { session_write_close(); if($this->is_exec_available()) { set_time_limit ( 0 ); $url = $this->getcompanyurl($id_firmy); $reject ="jpg,jpeg,png,gif,bmp,js,css,swf,ico,php,xml,txt"; $reject_uc = strtoupper($reject_extensions); $wget_command = "wget -m -E -t 3 -R $reject, $reject_uc -w 5 --random-wait -P../data/$id_firmy -np -nd -o../temp/mirror.log $url"; exec($wget_command); Výše uvedená část kódu v aplikaci obstarává stažení zrcadla webu e-shopu firmy, jejíž id je předáno jako parametr funkci mirrorcompanyeshop($id_firmy). Proces zrcadlení může v určitých případech trvat i několik hodin, proto pomocí funkce set_time_limit parametrem 0 nejdříve nastavuji neomezený čas, po který může skript na serveru běžet. Pomocí php funkce exec(), která spouští externí programy, spustím program Wget s potřebnými nastavenými parametry, který do adresáře data stáhne kompletní zrcadlo webu. Počet pokusů o stažení jednoho souboru jsem na základě testování nastavil na hodnotu 3, která byla pro úspěšné stažení souborů dostačující. Soubory s příponami uvedenými v proměnné $reject, které pro budoucí zpracování nejsou podstatné, budou ze stahování vyloučeny. Tím ušetřím místo na disku a sníží se tím i čas potřebný ke stažení zrcadla webu. Výstup programu Wget přesměrovávám do souboru mirror.log, jehož část je po dokončení zrcadlení webu uživateli zobrazena a poskytuje informaci o průběhu celé operace stahování. Volbami -w 5 --random-wait zajišťuji náhodné časy mezi jednotlivými přístupy programu na web, čímž odstraním riziko přerušení stahování, které může kontrolní program na webu vyvolat. 4.2.2 Konfigurace Tidy Pro správné vytvoření stromu dokumentu z HTML stránky pomocí instance třídy DOMDocument musí být její vstup validní HTML. Nelze spoléhat na to, že všechny weby e-shopů sledovaných firem splňují kritéria validity, a proto každou stránku před samotným zpracováním nejdříve zvaliduji s využitím knihovny Tidy. Uvádím část konfiguračních parametrů, podle kterých probíhá očištění původního HTML kódu.

46 Implementace $config = array( 'show-body-only' => false, 'clean' => true, 'doctype' => 'auto', 'input -encoding' => 4, output-encoding' => 4, 'add-xml-decl' => true, 'add-xml-space' => true, 'output-html' => false, 'output-xml' => false, 'output-xhtml' => true, 'numeric-entities' => false, 'ascii-chars' => false, 'doctype' => 'strict',... ) U položek input-encoding (vstupní kódování) a output-encoding (výstupní kódování) jsem nastavil hodnotu 4, což podle specifikace knihovny Tidy odpovídá kódování UTF-8 14. [9] V tomto kódování vytvářím instanci třídy DOMDocument, a proto stránky napsané v jiném kódování před vytvořením instance nejdříve převádím na UTF-8, které je kompatibilní se všemi ostatními českými kódováními. 4.2.3 Převod kódování stránek U českých webů převládají kódování ISO 8859-2, Windows-1250 a UTF-8. [16] Z těchto údajů jsem vycházel a uživateli jsem dal při definici kódování stránky na výběr z těchto možností: iso-8859-1 iso-8859-2 iso-8859-3 iso-8859-4 iso-8859-5 UTF-8 UTF-16 UTF-32 windows-1250 14 UTF-8 (UCS Transformation Format) je kódování umožňující reprezentovat každý znak ze sady Unicode, které bylo navrženo se zpětnou kompatibilitou s ASCII.

Implementace 47 windows-1251 windows-1252 windows-1253 windows-1254 windows-1255 Samotný převod kódování provádím pomocí funkce iconv() z knihovny iconv, přebírající jako parametry vstupní kódování zadané uživatelem, zdroj dat a výstupní kódování. Funkce převede zadaný řetězec ze zdrojového do cílového kódování. [13] Pro definici výstupního kódování jsem využil způsob zápisu UTF- 8//IGNORE, umožňující vynechat znaky, které nemohou být reprezentovány v množině znaků výstupního kódování. [10] 4.2.4 Získání hodnoty elementu K možnosti využít pro získání hodnoty elementu odkazovaného pomocí jazyka XPath musím při zpracování nejprve každý soubor načíst do paměti. Pomocí třídy DOMDocument 15 a její metody loadhtml() vytvořím objekt reprezentující stromovou strukturu souboru. Instanci této třídy předám jako parametr konstruktoru třídy DOMXpath 16, která podporuje jazyk XPath 1.0 a obsahuje metody pro pohyb po stromu dokumentu pomocí XPath cest. [4] [5] WebKit jako vykreslovací jádro prohlížeče Google Chrome, pro který byla aplikace optimalizována, na stránce webu vytváří uvnitř elementu table další vnoření element s názvem tbody, který se v původním zdrojovém kódu nenachází a obsahuje původní data elementu table. Po zkopírování může získaná XPath cesta obsahovat elementy tbody, které při získávání hodnoty výrazu odstraňuji. public function get_xpath_result($domxpath,$xpath_expression) { } $XPath_expression = str_replace("/tbody/", "/", $XPath_expression); return trim($domxpath->evaluate("string($xpath_expression)")); Získaná hodnota XPath výrazu je podle uživatelem definovaných úprav modifikována na požadovaný tvar. Systém umožňuje z výsledných hodnot oříznout libovolný počet řetězců od začátku i z konce. Tento nástroj je využitelný v situaci, kdy se například před názvy všech produktů na webu objevuje stejná sekvence znaků, které je potřeba odstranit (např. DVD: Název filmu). Zpracovávané řetězce jsou v kódování UTF-8 a mohou mít jeden znak uložen ve více než jednom bajtu. 15 http://php.net/manual/en/class.domdocument.php 16 http://php.net/manual/en/class.domxpath.php

48 Implementace Pro práci s těmito řetězci je v PHP určena knihovna mbstring 17, kterou jsem při implementaci využil. [13] Odříznutím nepotřebných znaků v původním řetězci získám požadovanou hodnotu. Pro náročnější uživatele jsem do systému implementoval i možnost kontroly získané hodnoty pomocí regulárního výrazu. Pomocí následujících uvedených funkcí provádím transformaci získaných hodnot atributů produktu před ukládáním do databáze. public function applyregular($value,$regular_expression) { $regular_expression = preg_quote($regular_expression, '/'); if (!preg_match("/$regular_expression/", trim($value))) { $value = ''; } return $value; } public function applyfunction($value, $function_name) { switch ($function_name) { case 'none': break; case 'strtolower': $value = strtolower($value); break; case 'strtoupper': $value = strtoupper($value); break; default: break; } return $value; } 4.2.5 Zpracování zrcadla webu Proces zpracování zrcadla webu následuje po definování atributů produktu a jejich příslušných XPath cest. Celý proces začíná tím, že smažu údaje o zpracovávané firmě z tabulky nove_produkty a nove_ceny. Poté spočítám počet souborů v adresáři, kde se nachází stažené zrcadlo webu, a tento údaj uložím do tabulky progress, jejíž obsah poslouží k zobrazování průběhu zpracování uživateli. Pro každý soubor zrcadla zvlášť nejdříve kontroluji, zda uživatelem zadaná hodnota kontrolního elementu odpovídá skutečné získané hodnotě jeho XPath výrazu. Pokud hodnota neodpovídá, soubor odstraním a pokračuji ve zpracování dalšího souboru. Odpovídá-li hodnota kontrolního elementu, kontroluji, zda byl podle 17 http://cz1.php.net/manual/en/book.mbstring.php

Implementace 49 uživatelem zadané XPath cesty nalezen identifikátor a cena produktu, které jsou povinnými údaji o produktu. Pokud ne, je tento soubor v adresáři ponechán, navyšuji hodnotu nezpracovaných souborů a pokračuji zpracování dalšího souboru. Pokud je hodnota identifikátoru i ceny na stránce nalezena, jsou uloženy do databáze a provádím zpracování atributů produktu. Při ukládání dat do databáze současně kontroluji, zda se jedná o nové produkty či ceny a popřípadě tyto data ukládám do tabulek nove_produkty nebo nove_ceny. Kontrolu provádím pomocí návratové hodnoty funkce execute(), která je součástí dibi rozhraní. Při ukládání údajů o produktu a jeho ceně do tabulky produkty_firmy využívám konstrukci INSERT ON DUPLICATE KEY UPDATE, kde při jejím použití nastávají v systému 3 možné stavy. $result = $this->dibi->insert("produkty_firmy", $array) ->onduplicatekeyupdate("cena = %i", $cena) ->execute(); if ($result == 0) { /* zachování původního produktu se stejnou cenou */ } else if ($result == 1) { /* proběhlo vložení nového produktu a ceny (INSERT) */ } else if ($result == 2) { /* proběhla aktualizace ceny produktu (DELETE, INSERT) */ } Tyto stavy kontroluji a na jejich základě dále postupuji při zpracovávání souboru. Pro každý uživatelem definovaný atribut naleznu pomocí zadané XPath cesty jeho hodnotu a i zde kontroluji, zda je to hodnota atributu nová nebo již v databázi uložená. Po úspěšném zpracování souboru a uložení všech sledovaných atributů o produktu do databáze soubor odstraním, navýším počítadlo zpracovaných souborů, jehož hodnotu uložím do tabulky progress, a pokračuji zpracováním dalšího souboru. Pro nezpracované soubory je možné po dokončení operace zadat nové XPath cesty a opět zahájit zpracování. 4.3 Uživatelské rozhraní Při tvorbě layoutu stránky jsem vycházel z volně šiřitelného administrátorského skinu Internet Dreams 18, jehož upravené CSS soubory a nepatrně změněné původní rozložení jsem v aplikaci využil. Zvoleným layoutem jsem uživateli poskytl dostatečnou pracovní plochu a zároveň jsem docílil přehledného rozložení všech potřebných prvků aplikace. 18 http://www.netdreams.co.uk/index.php/blog/2010/02/18/free-admin-skin-available-fordownload

50 Implementace Obr. 10 Prototyp rozložení prvků aplikace Oznámení o stavech systému uživateli zobrazuji pomocí flash zpráv 19, které jsou součástí Nette Frameworku. V aplikaci jsem pro různé stavy, které mohou nastat, definoval 3 typy zpráv: message-success zpráva zvýrazněná zeleně, která informuje o úspěšném dokončení nejrůznějších akcí v aplikaci message-info zpráva se žlutým zvýrazněním, která při práci s aplikací uživateli sděluje další doporučené kroky message-error červeně zvýrazněná zpráva, informující o snaze uživatele použít aplikaci nesprávným způsobem Jediným avšak naprosto dostačujícím navigačním prvkem aplikace je dvouúrovňové menu, které jsem umístil do horní části okna aplikace pod logo systému ADETA. V menu je vždy zvýrazněna sekce, ve které se uživatel při práci se systémem nachází. Všechny sekce včetně jejich hierarchie lze vidět na obrázku 11. S využitím modelu AccessControlList popsaného v kapitole 4.4 uživateli zobrazuji pouze ty části menu, k jejichž přístupu má oprávnění (uživateli s rolí správce například není zobrazena sekce Uživatelé). V případě prvního přihlášení je uživatel přesměrován na úvodní stránku, na kterou se dostane z kterékoliv části aplikace 19 Flash zpráva je zpráva informující o výsledku určité operace (např. úspěšné přidání uživatele), která sama zmizí.