Implementace systému pro získávání informací z webových zdrojů

Mendelova univerzita v Brně Provozně ekonomická fakulta

Implementace systému pro získávání informací z webových zdrojů Bakalářská práce

Vedoucí práce: Ing. Ludmila Brestičová

Aleš Procházka

Brno 2012

Tímto bych rád poděkoval paní Ing. Ludmile Brestičové za veškerou pomoc, odborné vedení, cenné rady a připomínky při vedení závěrečné práce.

Prohlašuji, že jsem tuto bakalářskou práci řešil samostatně za použití materiálů, které uvádím v seznamu literatury. V Brně dne 1. května 2012

__________________

Abstract Procházka, A. Implementation of a system for gathering information from web sources. Bachelor thesis. Brno: MUAF, 2012. Current state of information gathering, system requirements for a system for gathering information from internet sources and its model implementation are presented here. An abstract is in (British) English. Keywords Information, gathering information, system, implementation, automation. Here are key words in (British) English.

Abstrakt Procházka, A. Implementace systému pro získávání informací z webových zdrojů. Bakalářská práce. Brno: MZLU v Brně, 2012. V textu je popsán současný stav v oblasti získávání informací, požadavky na systém sloužící pro automatizované vyhledávání a jeho vzorová implementace. Klíčová slova Získávání informací, informace, systém, automatizace, implementace.

Obsah

5

Obsah 1

2

Úvod a cíl práce

8

1.1

Úvod .......................................................................................................... 8

1.2

Cíl práce .................................................................................................... 8

Informace a jejich získávání

9

2.1

Výhody užívání systému namísto lidských zdrojů ................................... 9

2.2

Právní aspekty užívání cizích databází ..................................................... 9

2.3

Způsob získávání informací .....................................................................10

2.3.1

Firmy.cz ............................................................................................ 11

2.3.2 ARES a hledání IČ ekonomického subjektu pomocí regulárních výrazů 11 3

Požadavky 3.1

Požadavky na systém ............................................................................... 14

3.1.1

4

14

Uživatelské rozhraní ........................................................................ 14

3.2

Model systému ......................................................................................... 14

3.3

Požadavky na server ................................................................................ 15

Popis jednotlivých částí systému

16

4.1

CRON a spouštění systému ..................................................................... 16

4.2

Backend – neustále běžící skript ............................................................. 16

4.2.1

Diagram aktivit skriptu collector.php .............................................18

4.2.2

Funkce camp() ................................................................................. 19

4.3

Moduly ..................................................................................................... 21

4.3.1

Třída DOM_Tools ............................................................................ 21

4.3.2

Modul Firmy.cz ............................................................................... 22

4.3.3

Modul Vyhledávač IČ ...................................................................... 23

4.3.4

Modul ARES .................................................................................... 23

4.4

ERD implementovaných modulů ........................................................... 24

4.5

Uživatelské rozhraní ............................................................................... 25

4.5.1

Diagram případů užití ..................................................................... 30

Obsah

6

5

Závěr

31

6

Literatura

32

Seznam obrázků

7

Seznam obrázků Obr. 1 Ukázka regulárního výrazu pro hledání IČ

12

Obr. 2

Schéma prohledávání grafu do šířky

13

Obr. 3

Záznam do démona CRON

16

Obr. 4

Ukázka kódu pro kontrolu běhu a start systému

16

Obr. 5

Hlavní smyčka skriptu collector.php

17

Obr. 6 Diagram aktivit popisující celkovou činnost skriptu collector.php

18

Obr. 7

Diagram aktivit funkce camp()

20

Obr. 8

Spuštění nových instancí, zde pro modul firmy_cz

21

Obr. 9

Funkce new_self()

21

Obr. 10

Ukázka použití třídy DOM_Tools

22

Obr. 11

Získání odpovědi pro dotaz na výpis z OR pro dané IČ

24

Obr. 12

ERD tří implementovaných modulů

24

Obr. 13

Nabídka akcí po přihlášení administrátora

25

Obr. 14

Nabídka akcí po přihlášení běžného uživatele

26

Obr. 15

Zadání nového úkolu

26

Obr. 16

Přehled úkolů a jejich stavů

27

Obr. 17

Náhled výsledků vyhledávání pro výraz „lyže“

28

Obr. 18

Export do XLS

29

Obr. 19

Diagram případů užití

30

Úvod a cíl práce

8

1 Úvod a cíl práce 1.1

Úvod

Samotné získávání informací je dnes s využitím internetu a dostupných vyhledávačů poměrně snadné. Příkladem budiž následující situace, kdy chceme najít například prodejce ledniček v Brně. Většinou nám stačí ve webovém prohlížeči jít například na vyhledávač Firmy.cz a hledat frázi „ledničky Brno“. Vyhledávač vrátí desítky výsledků, a pokud je důvodem našeho hledání koupě nové lednice, pravděpodobně nám tento způsob prezentace výsledků stačí. Pokud ale hledáme tyto prodejce za nějakým marketingovým účelem, například hledáme partnery pro propagaci a distribuci našich produktů, tak jednak tento způsob je velmi nepohodlný pro větší počet výsledků a také nedostačující vzhledem k požadovaným informacím. Při hledání potenciálních partnerů nejen že budeme potřebovat jejich kontaktní informace, ale bude vhodné dohledat doplňující údaje například z rejstříku firem. Již v tomto jednoduchém příkladu výše uvedený portál Firmy.cz nestačí a uživatel by musel doplňující informace hledat sám jinde. Logicky tedy vyvstává potřeba systému, který nejen že převezme od uživatele zdlouhavé a monotónní hledání, ale také tyto výsledky obohatí o informace z dalších serverů a nakonec poskytne veškeré získané údaje ve srozumitelné formě.

1.2 Cíl práce Cílem této práce je zrealizovat vzorovou implementaci systému pro získávání informací z portálu Firmy.cz s napojením na rejstřík firem ARES, provozovaným ministerstvem financí. Systém bude automatizovaný, zadá se mu hledaný výraz a následně bez asistence uživatele systém sám provede množství úkonů, které by jinak musel vykonat uživatel, aby získal systémem nalezené informace ve stejném rozsahu. Dalším požadavkem je modulární koncepce. Je žádoucí, aby systém nebyl psaný s pevně danou funkcionalitou, ale aby se bez zásahů do kódu dal rozšiřovat. Funkční část systému bude implementována v programovacím jazyce PHP. Databáze pro ukládání dat bude typu MySQL a uživatelské rozhraní bude implementováno ve značkovacím jazyce HTML za doplnění skriptovacím jazykem JavaScript.


9

2 Informace a jejich získávání Nejdříve je nutné definovat, co je to informace. Častá definice v oblasti informatiky zní „Informace snižuje nebo odstraňuje neurčitost (entropii)“ (wikipedia.org, 2012), ta je ovšem poněkud složitá a špatně pochopitelná. Lépe ji pochopíme z následujícího příkladu: Pokud bychom měli k dispozici databázi všech firem v ČR s jejich adresami sídel a předměty podnikání, pravděpodobně řekneme, že máme k dispozici velké množství dat, ne informací. Teprve až tato data nějak zpracujeme a interpretujeme, přiřadíme jim tedy určitý význam, hovoříme o informacích. Z toho plyne, že rozsáhlý seznam mnoha údajů je v praxi málo užitečný, pokud z něj nelze vybrat pouze to, co nás zajímá. Výběrem pouze relevantních údajů data zpracováváme, přiřazujeme jim důležitost. Takto se data stávají informacemi a pouze ty nás ve výsledku zajímají. Jakýkoli systém pro získávání informací tedy musí poskytovat jen ty údaje, které jsou žádané. V marketingu toto platí dvojnásob. Motivů pro hledání informací v marketingu je celá řada. Mezi nejčastější zřejmě patří průzkum trhu, hledání konkurence, partnerů nebo dodavatelů. Pro tvorbu správných rozhodnutí je potřeba mít dostatek informací. A pokud tyto informace budou kvalitní, můžeme v jejich dostupnosti vidět konkurenční výhodu.

2.1 Výhody užívání systému namísto lidských zdrojů Jak již vyplývá z úvodu, samotný fakt, že na internetu lze zjistit s nadsázkou cokoli, v praxi mnohdy nestačí. Při vyhledávání informací ve firemním prostředí je totiž nutné brát v úvahu nejen dostupnost informací, ale také časové a personální nároky s tím spojené. Pokud by zpracováním v úvodu popsaného dotazu byl pověřen reálný zaměstnanec v nějaké firmě, tak by k jeho dokončení potřeboval čas v řádech hodin. Naopak, tímto úkolem pověřený systém, by stejnou úlohu dokončil řádově v minutách a krom spotřebované elektrické energie s ním nejsou spojeny žádné další přímé výdaje. Použití počítačového systému pro získávání informací namísto lidských zdrojů tedy přináší značnou úsporu času i nákladů. Nemluvě o možnosti zadat systému celou řadu úkolů ke zpracování přes noc, aby byly výsledky hledání k dispozici hned z rána dalšího dne. Výhody plynoucí z užívání počítačových systémů jsou tedy značné a zřejmé.

2.2 Právní aspekty užívání cizích databází Ačkoli je většina běžně užívaných on-line databází volně dostupná, je třeba zjistit, zda podmínky jejích užívání a obecná právní úprava dovolují automatické procházení robotem. Následuje citace ze 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)


10

§ 91 Omezení zvláštního práva pořizovatele databáze Do práva pořizovatele databáze, která byla zpřístupněna jakýmkoli způsobem veřejnosti, nezasahuje oprávněný uživatel, který vytěžuje nebo zužitkovává kvalitativně nebo kvantitativně nepodstatné části obsahu databáze nebo její části, a to k jakémukoli účelu, za podmínky, že tento uživatel databázi užívá běžně a přiměřeně, nikoli systematicky či opakovaně, a bez újmy oprávněných zájmů pořizovatele databáze, a že nezpůsobuje újmu autorovi ani nositeli práv souvisejících s právem autorským k dílům nebo jiným předmětům ochrany obsaženým v databázi. § 92 Bezúplatné zákonné licence Do práva pořizovatele jím zpřístupněné databáze též nezasahuje oprávněný uživatel, který vytěžuje nebo zužitkovává podstatnou část obsahu databáze a) pro svou osobní potřebu; ustanovení § 30 odst. 3 zůstává nedotčeno, b) pro účely vědecké nebo vyučovací, uvede-li pramen, v rozsahu odůvodněném sledovaným nevýdělečným účelem, a c) pro účely veřejné bezpečnosti nebo správního či soudního řízení.1 Z výše citovaného vyplývá, že na činnost mého programu, v rámci bakalářské práce, se vztahuje bezúplatná zákonná licence podle § 92, písmena b. Pro komerční účely, tedy pro případ nasazení aplikace do reálného provozu s velkým množstvím dotazů do databáze žádná taková zákonná licence neexistuje a v tom případě může být, v závislosti na podmínkách užití dané databáze, nutné si s provozovatelem sjednat licenci opravňující k tomuto použití.

2.3 Způsob získávání informací Nejjednodušší způsobem získávání informací z databáze by samozřejmě byl přímý přístup do takové databáze. To je ovšem u webových aplikací téměř nemyslitelné. Rozhraní k přímému přístupu by se okamžitě stalo cílem mnoha internetových útoků a bezpečnost databáze by byla ohrožena. Další možností je poskytnout API2. U obou možností existuje riziko, že se najdou tací, kteří by chtěli databázi tzv. vydolovat, zneužít pro svůj prospěch na úkor zhotovitele databáze, ať už vytvořením její celé kopie nebo jiným způsobem.

Zákon č. 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) Dostupný také z: http://portal.gov.cz/app/zakony/download?idBiblio=49278&nr=121~2F2000~20Sb.): 1

API (Application Programming Interface) – rozhraní pro programování aplikací, zpravidla zabezpečené proti nadměrnému či neoprávněnému užití.

2


2.3.1

11

Firmy.cz

Protože portál Firmy.cz žádné API nenabízí, veškerá práce s tímto portálem ze strany systému bude napodobovat chování běžného uživatele při hledání výrazů v prohlížeči. I když se může zdát, že webové rozhraní dostupné na adrese http://www.firmy.cz poskytuje přístup v neomezeném rozsahu, není tomu tak. V nápovědě dostupné na stejné adrese, je k dispozici text pojednávající o ochraně proti zneužití ve formě omezení počtu dotazů z jedné IP adresy za blíže nespecifikovanou dobu. Po překročení tohoto počtu portál zamezí dalšímu užívání, dokud uživatel neopíše bezpečnostní kód ze zobrazeného obrázku. Moje zkušenosti jsou mírně odlišné. Přesný způsob práce mého systému je popsaný v následujících kapitolách, v tento okamžik pro vysvětlení plně postačí zjednodušení na fakt, že během své činnosti systém posílá na vzdálený server Firmy.cz až desítky dotazů za minutu. Bohužel pro mě a můj systém, je takové množství dotazů vyhodnoceno serverem buď jako pokus o zneužití nebo pokus o DoS útok3. Výsledkem je zablokování vyhledávacích funkcí na následujících 60 minut. Z provedených testů jsem zjistil, že k zablokování dojde po odeslání přibližně 100 HTTP požadavků během této doby. Rozdíl oproti způsobu blokace popsaném v nápovědě a mých zkušenostech je v tom, že podle nápovědy měl být zobrazen obrázek pro opsání kódu k odstranění blokace. Bohužel, během testů jsem po překročení limitu vždy dostal ze serveru odpověď „HTTP 403 Forbidden“4 bez možnosti opsání kódu. Do systému tedy přidám omezení počtu dotazů za minutu, aby k blokaci během běžného provozu nedocházelo. Samotné získávání dat ze stažených HTML stránek je zde jednoduché, dokonce ani není nutné pro rozlišování jednotlivých údajů použít regulární výrazy, protože údaje jsou ve výstupu označeny podle typu různými CSS třídami. Za předpokladu, že data vkládaná do databáze Firmy.cz prochází nějakou vstupní validací a že jejich následné označení třídami probíhá spolehlivě, stačí pouze vybrat hodnoty některých elementů a uložit je. 2.3.2

ARES a hledání IČ ekonomického subjektu pomocí regulárních výrazů

Ministerstvo financí ČR vyšlo všem zájemcům o údaje z registru ekonomických subjektů maximálně vstříc implementováním veřejného API služby ARES 5 . Podmínky provozu a způsob použití jsou jasně definovány a integrace do vlastní aplikace je tak rychlá a přímočará. V podmínkách provozu se lze dočíst o omezení počtu dotazů za specifikovaná časová období a také kroky, které mohou vést k nechtěnému zablokování seDoS (Denial of Service) útok je typ útoku na webový server, při kterém dochází k jeho přetížení požadavky od útočníků, a tím k následnému pádu či zpomalení poskytovaných služeb. 4 Chybový kód HTTP 403 znamená, že nemáte oprávnění prohlížet požadovaný obsah. 5 Více informací na adrese http://wwwinfo.mfcr.cz/ares/ares_xml.html.cz 3


12

be sama. V tom případě ministerstvo požaduje pro obnovení přístupu písemné záruky. Z hlediska používání nabízeného rozhraní automatizovanými systémy je v podmínkách pouze doporučení na správné vyplňování parametrů, není tedy zakázáno či jinak omezeno. ARES poskytuje jak základní informace o subjektech, tak výpisy z mnoha samostatných rejstříků, jakými jsou například obchodní a živnostenský rejstřík. Pro účely této práce bude implementován pouze výpis z obchodního rejstříku. Doplnění o další výpisy v budoucnu je otázkou pouhé změny URL adresy při volání API. Vstupním parametrem pro ARES může být IČ subjektu, jeho sídlo či název. Ze zkušenosti mohu říct, že vyhledávání podle názvu obchodní firmy v naprosté většině případů nevrací požadované výsledky a doplnění o sídlo situaci nezlepší. Nejspolehlivějším je hledání podle IČ, které je pro každý subjekt unikátní a má definovaný tvar. Z pohledu informatiky se jedná o posloupnost osmi číslic s nezaměnitelným pořadím. Vyhledání takového výrazu je jednoduché, viz následující příklad.

Obr. 1

Ukázka regulárního výrazu pro hledání IČ

Vyhledávání podle regulárního výrazu je nutné, protože nevím o žádném fulltextovém vyhledávači, který by vracel IČ. Firmy.cz bohužel IČ ve svém výstupu neobsahují, nabízí ale URL webové prezentace nalezených subjektů. Většina podnikatelů a firem IČ ve své prezentaci uvede, takže přichází na řadu otázka jeho vyhledání v textu. Pokud je IČ v prezentaci vůbec uvedeno, ne vždy je přímo na úvodní stránce, ale je nutné ho najít přes některý z odkazů v menu. Vhodnou metodou pro procházení odkazů z úvodní stránky je prohledávání grafu do šířky.


Obr. 2

13

Schéma prohledávání grafu do šířky

Do reálné implementace je vhodné dát několik omezujících podmínek. Nejdůležitější je zajistit, aby procházené odkazy vedly pouze na další stránky prezentace a nevedly mimo, na jiný web, jinou prezentaci jiné firmy. A také limitovat množství úrovní zanoření.

Požadavky

14

3 Požadavky 3.1 Požadavky na systém Přestože v této práci popisuji vzorovou implementaci, považuji za vhodné již z počátku cílit uživatelské rozhraní svou skladbou a nabízenými možnostmi na běžné uživatele a usnadnit tak případné nasazení systému do praxe. Zejména systém správy uživatelů s možností jejich třídění do skupin a možnosti těmto skupinám přiřazovat různá oprávnění. Tento požadavek vyplývá z běžné potřeby odlišit oprávnění správce systému od běžných uživatelů. Po nich jednak nemůže být vyžadováno, aby rozuměli způsobu fungování systému a dále by velké množství uživatelů s administrátorskými právy představovalo bezpečnostní riziko. Kterýkoli z uživatelů by ať už z nedbalosti nebo z úmyslu mohl provézt akci, která by systém, či v něm nashromážděná data, mohla ohrozit. Další vlastnosti a funkčnost mohou být předmětem dalšího vývoje systému. Z hlediska nefunkčních požadavků je nutné zajistit schopnost využití dostupných serverových prostředků. V dnešní době více-jádrových procesorů je poněkud nešťastný fakt, že převážná část počítačových programů nedokáže využít více, jak jedno výpočetní jádro procesoru a tím zbytečně běží déle, než by bylo nutné. Dal jsem si tedy za cíl provézt implementaci tak, aby systém z vícejádrových procesorů profitoval. 3.1.1

Uživatelské rozhraní

Standardem ve webových aplikacích se dnes stává podpora více jazykových překladů uživatelského rozhraní. Můj mateřský jazyk je čeština, systém tedy vybavím pouze českými popisky. Současně ale implementuji jednoduchý způsob přidávání dalších překladů a snadnou možnost jejich přepnutí v uživatelském rozhraní. Z pohledu práce uživatele se systémem je nutné mít k dispozici výsledky všech předchozích hledání a informace o průběhu běžících úloh. Žádoucí je také možnost exportu výsledků hledání do souboru. Jako formát exportu jsem zvolil XLS, pro jeho masivní rozšíření mezi uživateli a vestavěné pokročilé možnosti formátování. V souladu se současným trendem „WEB 2.0“, budou použity moderní značkovací jazyky, jakými jsou HTML 5 a CSS 3 a skriptovací jazyk na straně prohlížeče – JavaScript s frameworkem jQuery tam, kde to bude vhodné.

3.2 Model systému Vzhledem k tomu, že v PHP nelze přímo psát více-vláknové skripty, je nutné využití více vláken dosáhnout jinak. Ze seminární práce do předmětu AVT mám zkušenosti s tvorbou PHP skriptů, které běží nepřetržitě a z databáze v pravidelných intervalech získávají úlohy ke zpracování. Tehdejší implementace sice sloužila ke spouštění a sledování běhu programu wget, princip ale zůsta-

Požadavky

15

ne podobný. Celková činnost systému bude probíhat v těchto jednoduchých krocích: 1. 2.

Čekání na úkol Načtení parametru úkolu

3.

Postupné spouštění modulů v úkolu s čekáním na doběhnutí Každý modul čeká na předcházející, aby mohl použít jeho výsledky

4.

Úkol dokončen, čekání na další úkol

5.

Načtení dalšího úkolu

Aby systém mohl čekat na vložení nového úkolu a spouštět moduly dle potřeby, bude potřeba skript, který tuto činnost samostatně obstará a poběží nepřetržitě. Systém se tedy bude skládat ze čtyř částí: 1. 2.

Nepřetržitě běžící skript na serveru („backend“) Dynamicky spouštěné skripty (moduly)

3.

Vhodně strukturovaná databáze Webové uživatelské rozhraní

4.

3.3 Požadavky na server Zvoleným programovacím jazykem je PHP, protože se jedná o nejpoužívanější programovací jazyk na straně serveru k tvorbě webového obsahu (w3techs.com, 2012) a mám s ním mnohaleté zkušenosti. Platformu pro běh serveru jsem zvolil Linux, z důvodu jeho nízké, resp. nulové pořizovací ceny u většiny distribucí a dostupnosti vhodného programového vybavení. Tím myslím démona CRON pro automatizované spouštění úloh, webový server Apache, databázový server MySQL a server PHP. Z důvodů popsaných níže je nutné v konfiguraci PHP povolit užití funkce exec() a shell_exec(), což je na webových serverech obecně považováno za silné bezpečnostní riziko. Funkce exec() a shell_exec(), jak anglické názvy napovídají, slouží ke spouštění příkazů v operačním systému, kde PHP server běží. V této práci popisovaný systém je ale zamýšlen jako vnitropodniková aplikace, tedy že systém nebude k dispozici na síti internet, odkud by mohly přicházet útoky snažící se těchto funkcí zneužít.


16

4 Popis jednotlivých částí systému 4.1 CRON a spouštění systému Ke spouštění a k zajištění nepřetržitého běhu systému slouží plánovač CRON. Ten ve zvolených intervalech (na obrázku každých 15 minut) spustí skript backend_control.php.

Obr. 3

Záznam do démona CRON

Jeho funkcí při volání bez parametru je kontrola vůči databázi, zda má systém běžet. Pokud ano, zkontroluje, zda běží a případně spustí collector.php (backend). Spuštění provádím za pomoci příkazu nohup, který zajistí, aby se skript po ukončení shellu (zde funkce exec) nezastavil signálem SIGHUP. Dále přesměrovávám standardní a chybový výstup do koše /dev/null a poslední znak „&“ pak spouštěnou úlohu přenese na pozadí, čímž se nečeká na její dokončení.

Obr. 4

Ukázka kódu pro kontrolu běhu a start systému

4.2 Backend – neustále běžící skript Backend (collector.php) je stěžejní část systému. Po spuštění se připojí do databáze a s přednastavenou periodou z databáze bere úlohy vložené uživatelem a spouští definovaný počet instancí jednotlivých modulů. Abych dosáhl nepřetržitého běhu skriptu a současně nevytížil zcela server pouhou smyčkou běhu, implementoval jsem jednoduchý postup pro vkládání minimálních prodlev ve smyčce.


Obr. 5

17

Hlavní smyčka skriptu collector.php

V nastavení skriptu je řádek s nastavením hodnoty konstanty TICK pro určení minimální délky běhu jedné smyčky ve vteřinách. Z pohledu na výše zobrazený kód je zřejmý způsob fungování. Dokud není v databázi příkaz na zastavení běhu, ulož aktuální čas, vymaž staré záznamy v logu, spusť funkci camp() (bude vysvětlena později), vypočítej délku čekání a pokud skript běžel kratší dobu, než minimální definovaná, čekej vypočtený čas. Během vývoje systému jsem implementoval funkci msg() pro ukládání stavových hlášení do databáze, díky čemuž jsem snáze odhalil chyby během programování a teď po dokončení lze její výstup použít pro hledání příčin nestandardního chování, pokud by k nějakému docházelo. Množství zaznamenávaných hlášení dosahuje poměrně vysokých hodnot, takže za relativně krátkou dobu vygeneruje funkce stovky záznamů do databáze a pokud by tato činnost byla ponechána bez pravidelného promazávání, databáze by narostla do nepřijatelných hodnot. Každý den běhu skriptu se proto spustí SQL příkaz pro vymazání záznamů starších, jak 1 den. Dále jsem implementoval na výše uvedeném obrázku nezobrazenou funkci log_acces(), která do tabulky „statistika“ zaznamenává čas spuštění jednotlivých modulů. Z těchto záznamů lze později generovat statistické údaje o používání systému, v této práci ovšem takové generování není implementováno. Výše popsanou činnost skriptu názorně zobrazuje následující diagram aktivit.


4.2.1

Diagram aktivit skriptu collector.php

Obr. 6

Diagram aktivit popisující celkovou činnost skriptu collector.php

18


4.2.2

19

Funkce camp()

Tato funkce obstarává veškerou funkční činnost ve skriptu. Vstupním parametrem je z databáze načtené pole s nastavením systému a modulů. Při jejím zavolání se vždy načte seznam úkolů, které čekají ve frontě a následně se jím prochází. Pro každou úlohu dělá tyto kroky: 1. 2.

Nastavit stav na „provádí se“ Z parametrů úkolu načíst seznam modulů a nastavení pro moduly

3.

Pro každý z modulů, které se mají při zpracování úkolu použít: 3.1. Pokud má modul hodinový limit počtu dotazů, čekat, dokud se modul nedostane pod limit

4.

3.2. Spustit modul s jeho parametry 3.3. Čekat, dokud modul neskončí Nastavit stav na „hotovo“

Bod 3.3 je velmi důležitý pro správnou návaznost modulů. Pokud následující modul potřebuje výstup současného pro svůj běh a spustil se předčasně, neprovedl by veškeré zamýšlené úkoly. Lépe tyto kroky vysvětlí následující diagram.


Obr. 7

Diagram aktivit funkce camp()

20


21

4.3 Moduly Modul dostane při spuštění ID úkolu, který má provézt a seznam parametrů. Moduly rozlišují několik fází běhu. V první fázi zkontroluje vstupní parametry, provede počáteční načtení vstupních parametrů pro další fázi a spustí tolik nových instancí sama sebe v další fázi, kolik hodnot vstupních parametrů získal.

Obr. 8

Spuštění nových instancí, zde pro modul firmy_cz

Funkce new_self() zajistí spuštění nových instancí stejným způsobem, jako to dělá backend_control.php. Na tomto místě by případně bylo vhodné implementovat omezovač počtu současně běžících úloh, pokud by se ukázalo, že při vysokých počtech úloh dochází ke zpomalování systému.

Obr. 9

Funkce new_self()

Bez posledního znaku „&“ a tím vyvolaným přesunutím běhu na pozadí, by se nové instance spouštěly v řadě za sebou bez úspory času a využití dostupných prostředků. 4.3.1

Třída DOM_Tools

Protože většina činnosti modulů spočívá ve vyhledávání a procházení HTML dokumentem, implementoval jsem třídu DOM_Tools, která za pomocí selektorů podobným těm z CSS, vybírá pouze žádané elementy a z nich vrací jejich obsah či hodnoty atributů.


Obr. 10

22

Ukázka použití třídy DOM_Tools

Implementované selektory: • ID elementu pomocí #název_třídy • název elementu • CSS třída s výběrem až tří různých tříd pomocí znaku roury ve funkci logického „nebo“, například p.red|green|blue • hodnota libovolných atributů, například: a[target="_blank"] vybere odkazy, které se otevírají v novém okně • pozice s výběrem :first, :last, :eq(n), kde n je číselná pozice elementu Selektory v tomto rozsahu umožnily značné zjednodušení práce s objektovým modelem dokumentu. Na výše uvedeném obrázku bylo pro vybrání všech odkazů s třídou „logo“ z elementu s ID „results“ a z nich pouze hodnoty atributu „href“ zapotřebí pouhých dvou řádků kódu. 4.3.2

Modul Firmy.cz

Vstupním parametrem pro modul Firmy.cz je hledaný řetězec. Ten uživatel ve webovém rozhraní vyplní při zadávání úkolu a modul jej následně použije pro získání výsledků vyhledávání. Protože přístup na Firmy.cz je omezen na přibližný počet 100 požadavků za hodinu, modul si vede záznamy o čase odesílání požadavků a nezahájí svou činnost, pokud byl limit překročen. Pokud z nějakého důvodu server vrátí špatnou odpověď, modul s minutovými rozestupy opakuje požadavek a po překročení definovaného množství opakování svou činnost ukončí. Postup činnosti modulu: 1.

Vyhledání zadaného výrazu. Pro Firmy.cz to znamená stažení webové stránky s adresou http://www.firmy.cz/?q=hledany+vyraz a její uložení k dalšímu zpracování. Takto uložená webová stránka je HTML kód, ve kterém lze pomocí PHP snadno vyhledávat řetězce či struktury objektového modelu DOM, a nachází se na ní zpravidla 25 výsledků vyhledávání s odkazy na podrobnosti o daném výsledku.


23

2.

Získání výsledků hledání V elementu s ID „results“ stačí vyhledat veškeré hyper-textové odkazy s parametrem „class“ rovným hodnotě „logo“. Tyto odkazy vedou na podrobnosti (detail) výsledku hledání a z jedné stránky jich lze získat 25. 3.

V tomto bodě lze využít výkon procesoru a kapacitu přenosové linky tím, že se spustí až 25 samostatných úloh ke zpracování detailů. Slovo „až“ zde píši záměrně, záleží na konkrétním nasazení, do jakého bodu přináší zvyšování počtu současně běžících úloh užitek. U velkého počtu úloh také vstupuje do úvahy přenosová kapacita linky do sítě internet a její další parametry, zejména latence6. Při zaplnění kapacity by spouštění dalších úloh znamenalo paradoxně prodloužení běhu. 4.

Uložení nalezených údajů z detailů do databáze. Jedná se o údaje adresa, telefon, mobil, email a www. Adresu modul ještě před uložením rozdělí na ulici, číslo popisné, obec a psč.

4.3.3

Modul Vyhledávač IČ

Jak již bylo uvedeno dříve, Firmy.cz nenabízí v detailech nalezených subjektů jejich IČ a pro spolehlivé hledání v databázi ARES je nezbytné. Proto jsem implementoval modul, který prochází webovou prezentaci firmy a tam se pomocí regulárních výrazů IČ snaží najít. Postup procházení je jednoduchý. Po načtení úvodní stránky prezentace modul vybere všechny hypertextové odkazy. Obvykle se IČ nachází na stránkách s popisem firmy nebo v obchodních podmínkách, modul tedy ze získaných odkazů vybere jenom ty, které obsahují jeden z následujících řetězců: obchodní, kontakt, podmínky, o nás, řád, nákupní. Porovnávání řetězců se provádí až po převodu na malá písmena funkcí mb_strtolower()7 a nahrazení českých znaků jejich ekvivalenty bez diakritiky, například „nákupní“ se převede na „nakupni“. Dále se zkontroluje, zda odkaz vede na stránku stejné domény a teprve pak se předá do další fáze pro hledání IČ pomocí regulárního výrazu. Takto nalezené výrazy sice odpovídají posloupnosti osmi číslic, ovšem může se stát, že se ve skutečnosti jedná o úryvek telefonního nebo jiného čísla. Pro ověření, že se skutečně jedná o IČ, používám funkci verifyIC() Davida Grudly. Po získání ověřeného IČ je možné jednoduše a spolehlivě vyhledávat v systému ARES. 4.3.4

Modul ARES

ARES nabízí přístup k velkému množství registrů a rejstříků. V této práci jsem implementoval výpis dat pouze z obchodního rejstříku. Latence je doba uplynulá mezi odesláním požadavku na vzdálený server a příjmu odpovědi. Použití funkce mb_strtolower() namísto běžného strtolower() je nutné při práci s textem v UTF-8. 6 7


Obr. 11

24

Získání odpovědi pro dotaz na výpis z OR pro dané IČ

Služba vrací výsledky ve formátu XML podle definovaných šablon. Přidání dalších výpisů je tedy v případě potřeby snadné.

4.4 ERD implementovaných modulů

Obr. 12

ERD tří implementovaných modulů

Společným znakem všech modulů je cizí klíč „id_hledani“, který značí vazbu na záznam v tabulce „hledani“. Každý modul může mít libovolný počet tabulek.


25

Ukládání dat do nich řeší každý modul samostatně a pro následné čtení dat z uživatelského rozhraní je taktéž realizován modulární přístup. Tabulka „hledani“ uchovává datum a čas zadání úkolu, parametry v jednom řetězci pro všechny moduly, seznam modulů a číselnou reprezentaci stavu úkolu. Stav může nabývat následujících hodnot: • 0 – čeká ve frontě • 1 – dokončeno • 2 – právě se zpracovává

4.5 Uživatelské rozhraní

Obr. 13

Nabídka akcí po přihlášení administrátora

Uživatelské rozhraní jsem dle dříve stanovených požadavků implementoval s podporou uživatelských skupin a nastavením oprávnění k činnostem v systému. Na obrázku výše je vidět úvodní strana webového rozhraní po přihlášení uživatele ze skupiny administrátorů, která má plná práva a zobrazují se tak všechny dostupné akce. Běžní uživatelé by mohli být zmateni přítomností tlačítek, která s ohledem na jejich uživatelskou skupinu jsou nefunkční, proto běžní uživatelé mají nejen omezená práva, ale systém také omezí výpis dostupných akcí.


Obr. 14

26

Nabídka akcí po přihlášení běžného uživatele

V pravém horním rohu si lze všimnout české vlaječky. Pokud by systém disponoval soubory s překlady textů i v jiných jazycích, zobrazovaly by se na tomto místě další ikony k přepnutí jazyka. Veškeré texty rozhraní jsou uloženy v textových souborech v adresářové struktuře systému. Tvorba nového překladu je otázkou vytvoření kopie těchto souborů, jejich přejmenování na označení jiného jazyka a překlad textů v nich obsažených. Zadání nového úkolu je velice jednoduché. Každý modul zobrazí, co požaduje ke své činnosti a po uživateli se vyžaduje pouze vyplnění prázdných políček.

Obr. 15

Zadání nového úkolu

V současném stavu jsou v systému tři moduly a pouze modul Firmy.cz potřebuje od uživatele specifikovat hledaný výraz. Limit prohledávání uživatel může nechat na výchozí hodnotě. Ostatní zobrazené moduly vstup od uživatele nevyža-


27

dují, vstupní data si předávají mezi sebou automaticky. Stisknutím tlačítka „uložit“ se úloha vloží do fronty a systém ji začne automaticky zpracovávat.

Obr. 16

Přehled úkolů a jejich stavů

V přehledu úkolů lze sledovat činnost systému a kdykoli v průběhu lze zobrazit náhled nalezených dat.


Obr. 17

28

Náhled výsledků vyhledávání pro výraz „lyže“

Aby náhled zůstal přehledný, nejsou v něm zobrazeny veškeré údaje. Ty se zobrazí až v exportu do XLS, kde každý modul vypíše nalezená data do samostatného listu. Export je realizován pomocí knihovny PHPExcel8, která je k dispozici pod GNU LGPL licencí. Autorem všech obrázkových ikon použitých ve webovém rozhraní je Mark James9.

8 9

Více informací na adrese http://www.codeplex.com/PHPExcel Více informací na adrese http://famfamfam.com/


Obr. 18

Export do XLS

29


4.5.1


Obr. 19


30

Diagram případů užití zachycuje jaké akce jsou dostupné pro různé typy uživatelů. Uvedený diagram platí pro výchozí nastavení systému. Administrátor však přes správu oprávnění může běžnému uživateli přidělit více práv a přes správu skupin vytvářet nové skupiny uživatelů s novými oprávněními.

Závěr

31

5 Závěr V práci jsem popsal současný stav v oblasti hromadného získávání informací a jeho marketingový přínos. Dále jsem vytvořil model systému pro automatizované získávání informací a vzorový systém následně implementoval. Současný stav v získávání informací jsem vyhodnotil jako ne zcela uspokojivý. Přístup k informacím je sice pro běžné uživatele rozsáhlý, nenašel jsem ale systém či službu, která by poskytovala tak ucelený výstup, jako moje vzorová implementace. Během její tvorby jsem narazil na jistá omezení pramenící z povahy internetových služeb. Mnoho služeb používá různé a různě zdokumentované prostředky ochrany vůči zneužití a ne vždy je snadné s těmito omezeními pracovat. Tyto problémy se ale dají vyřešit spoluprácí s poskytovateli těchto služeb. Problém závažnějšího typu je nekonzistence ve webových prezentacích firem či jejich úplná absence. Během tvorby zde popisovaného systému nebyl ani tak problém navrhnout a následně implementovat technické řešení systému, ale spíše navrhnout takové řešení, které spolehlivě projde webové prezentace firem a najde v nich hledané informace. Protože firemní prezentace se nevytváří podle žádného standardu, je zcela na jejich tvůrcích, co a v jaké podobě v nich uvedou. V textu jsem popisoval problém hledání IČ. Kdyby každý tvůrce dodržoval nějaký standardizovaný formát, hledání informací by bylo snazší nejen pro automatizované systémy, ale i pro uživatele. V tomto bodě tedy vidím největší prostor pro zlepšení systému. Mnou implementované procházení webové prezentace nedokáže správně projít různá kreativní řešení webových stránek. Kromě tohoto nedostatku ale věřím, že zde popsaná implementace může sloužit jako základ pro do praxe nasazovaný systém.

Literatura

32

6 Literatura MINISTERSTVO FINANCÍ ČR. ARES – jmenné prostory. [on-line] 14. 5. 2012 [cit. 14. 5. 2012]. Dostupné na: http://wwwinfo.mfcr.cz/ares/xml_doc/ schemas/index.html MINISTERSTVO FINANCÍ ČR. XML služby ARES. [on-line] 1. 1. 2012 [cit. 14. 5. 2012]. Dostupné na: http://wwwinfo.mfcr.cz/ares/ares_xml.html.cz DAVID GRUDL. Jak ověřit platné IČ a rodné číslo? [on-line] 14. 9. 2007 [cit. 30. 3. 2012]. Dostupné na: http://latrine.dgx.cz/jak-overit-platne-ic-arodne-cislo Usage of server-side programming languages for websites. [on-line] 30. 3. 2012 [cit. 30. 3. 2012]. Dostupné na: http://w3techs.com/technologies/overview/programming_language/all WIKIPEDIA FOUNDATION INC. Informace. [on-line] 31. 3. 2012 [cit. 16. 5. 2012]. Dostupné na: http://cs.wikipedia.org/wiki/Informace BUREŠ, M. -- MORÁVEK, A. -- JELÍNEK, I. Nová generace webových technologií : informace v 21. století. 1. vyd. Praha: VOX, 2005. 264 s. Webové technologie. ISBN 80-86324-46-X. ISKRA, J. Google : tipy a návody pro vyhledávač, Gmail, YouTube, Earth a další aplikace. Brno: Computer Press, 2008. 231 s. ISBN 978-80-2511833-7.

Implementace systému pro získávání informací z webových zdrojů

Recommend Documents