ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ
Bakalářská práce
Nabídkový a rezervační systém cestovní agentury Jiří Bruchanov
Vedoucí práce: Ing. Josef Semrád Studijní program: Obor:
Elektrotechnika a informatika strukturovaný bakalářský Informatika a výpočetní technika
Praha 2009
Poděkování Tímto bych chtěl poděkovat Ing. Josefu Semrádovi, vedoucímu bakalářské práce, za všechny podněty, vstřícnost a ochotu při vypracování této bakalářské práce.
Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Praze dne 10. ledna 2009
………………………………
Abstract The bachelor thesis analyses and implements offering and reservation system of travel agency. Requirements are already set. This work is split into several categories. The first part is about public part implementation. The next part is about implementation of private part. The final part is about 3D Secure system implementation.
Abstrakt Bakalářská práce analyzuje a implementuje nabídkový a rezervační systém určený pro cestovní kancelář, dle předem domluvených požadavků. Práce je rozdělena do několika kategorií, které postupně rozebírají danou část implementace. První část je zaměřena na implementaci veřejné části aplikace, další se zabývá implementací privátní části aplikace a na konec problém implementace 3D Secure systému.
NABÍDKOVÝ A REZERVAČNÍ SYSTÉM CESTOVNÍ AGENTURY NÁZEV DOKUMENTU:
Nabídkový a rezervační systém cestovní agentury OBSAH:
Návrh a implementace systému
strana
1
49
VYPRACOVAL:
DATUM:
Jiří Bruchanov
1. 12. 2008
Obsah
1
Úvod
7
2
Specifikace požadavků
7
2.1
Vzhled a rozvržení formulářů
7
2.1.1
Formulář založení rezervace
7
2.1.2
Formulář kontrola údajů
7
2.1.3
Formulář výběr způsobu úhrady
7
2.1.4
Formulář finální notifikace
7
2.2
Položky v objednávce
7
2.2.1
Klíčové položky
7
2.2.2
Doplňující položky
8
2.3
Kontrola a bezpečnost vstupních údajů
8
2.4
Notifikace
8
2.4.1
Mail
8
2.4.2
Smlouva
8
2.4.3
Složenka
8
2.5
3DSecure
8
2.6
Konfigurace
8
2.7
Provozní prostředí
9
2.7.1
Webhosting
9
2.7.2
Kancelář
9
2.8
Minimalizace komunikace
9
3
Analýza
10
3.1
Uživatelské role
10
3.2
Systémové role
10
3.2.1
Klient
10
3.2.2
Český hosting
10
3.2.3
Kancelář
10
3.2.4
Banka
10
3.3
Komunikace
10
3.3.1
Zákazník – Český hosting
11
3.3.2
Český hosting – kancelář
11
strana
2
49
3.3.3
Český hosting – banka
11
3.3.4
Banka – kancelář
11
3.4
Zabezpečení systému
11
3.4.1
Vstupní údaje
11
3.5
Notifikace
11
3.6
Konfigurace
12
3.7
Minimalizace komunikace
12
4
Implementace
13
4.1
Implementační elementy
13
4.1.1
Rezervace
13
4.1.2
Objednávka
13
4.1.3
Privátní notifikační mail
13
4.2
Český hosting
14
4.2.2
Použité technologie
15
4.2.3
Prezentační vrstva
15
4.2.4
Informační vrstva
16
4.2.5
Kontrolní vrstva
16
4.2.6
Datová vrstva
17
4.2.7
Komunikační vrstva
19
4.2.8
Objektová vrstva
20
4.2.9
Vývojový digram vytvoření objednávky
24
4.2.10
Implementační problémy
25
4.3
Kancelář
26
4.3.2
Použité technologie
27
4.3.3
Implementační elementy
27
4.3.4
Publikační vrstva
27
4.3.5
Komunikační vrstva
27
4.3.6
Reportovací vrstva
28
4.3.7
Datová vrstva
28
4.3.8
Objektová vrstva
30
4.3.9
Vývojový diagram zpracování objednávky
40
4.4
3D Secure systém
41
4.4.1
Použité technologie
41
4.4.2
Vytvoření požadavku o transakci
41
4.4.3
Ověření dat
41
4.4.4
Potvrzení dat
41
strana
3
49
4.4.5
Vývojový diagram platby přes internet
43
5
Komunikační model
44
5.1
Kompletní vývojový diagram zpracování objednávky
45
5.2
Kompletní scénař úspěšného vytvoření objednávky vč. platby pomocí 3D Secure
46
6
Závěr
47
7
Přílohy
48
7.1
DVD
48
8
Použitá literatura
49
strana
4
49
Seznam obrázků Obr. 3.2:
Český hosting – model
Obr. 3.2.6.1: Český hosting – datový model Obr. 3.2.8.1: Český hosting – objektový model Osoby Obr. 3.2.8.2: Český hosting – objektový model Rezervace Obr. 3.2.8.3: Český hosting – objektový model Komunikace Obr. 3.2.8.4: Český hosting – objektový model Databáze Obr. 3.2.8.5: Český hosting – objektový model Konfigurace Obr. 3.2.8.6: Vývojový diagram vytvoření objednávky Obr. 3.3:
Kancelář – model
Obr. 3.2.7.1: Kancelář – datový model Obr. 3.2.8.1: Kancelář – objektový model Osoby Obr. 3.2.8.2: Kancelář – objektový model Rezervace Obr. 3.2.8.3: Kancelář – objektový model Komunikace Obr. 3.2.8.4: Kancelář – objektový model Databáze Obr. 3.2.8.5: Kancelář – objektový model Složenky Obr. 3.3.9:
Vývojový diagram zpracování objednávky
Obr. 3.4.5:
Vývojový diagram platby přes internet
Obr. 4:
Komunikační model
Obr. 4.1.:
Kompletní vývojový diagram zpracování objednávky
strana
5
49
Seznam použitých zkratek AJAX
Asynchronous JavaScript and XML
Cache
Skrýta paměť
CSS
Kaskádové styly
FQDN
Fully Qualified domain name
HTML
HyperText Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol over SSL/TSL
IP
Internet Protocol
JPEG
Joint Photographic Experts Group
MSSQL Microsoft SQL Server MySQL MySQL Server OOP
Objektově orientované programování
PDF
Portable Document Format
PHP
PHP Hypertext Processor, (Personal Home Page)
SMTP
Simple Mail Transfer Protocol
SSL
Secure Sockets Layer
TIFF
Tagged Image File Format
WSDL
Web Services Description Language
WWW
World Wide Web
XHTML Extensible HyperText Markup Language
strana
6
49
1
ÚVOD Tato práce byla vytvořena na základě požadavků cestovní kanceláře tak, aby mohla nabízet svojí nabídku v rámci internetových stránek a byl tak umožněn automatický objednávkový systém. Práce se zabývá analýzou a samotnou implementací do již funkčního systému, který je přístupný pouze v kancelářském prostředí.
2
SPECIFIKACE POŽADAVKŮ Specifika k této práci jsou jednoduché, vytvořit webovou aplikaci spolupracující se současným systémem tak, aby bylo možné jednoduše a pohodlně vytvářet objednávky zájezdů, které budou automaticky založeny do kancelářského systému. Cílový zákazník bude notifikován o úspěšné registraci jeho objednávky a bude mu doručena smlouva pomocí mailu.
2.1
Vzhled a rozvržení formulářů
Celá část „viditelné“ aplikace bude tvořena 4 formuláři, ve kterých zákazník vyplňuje potřebné údaje k úspěšnému dokončení celé objednávky. Zákazník se nebude nijak registrovat. Vzhled je upraven tak, aby byl shodný s původním designem webových stránek a nelišil se v barevném konceptu.
2.1.1 Formulář založení rezervace Zákazníkovi bude nabídnuta destinace a termíny odjezdů na základě zvoleného zájezdu a jím vybraným poštovním směrovacím číslem.
2.1.2 Formulář kontrola údajů Zde má zákazník možnost ověřit své vstupní informace, příp. doplnit poznámku.
2.1.3 Formulář výběr způsobu úhrady Zákazník vybírá, jakým způsobem bude platit.
2.1.4 Formulář finální notifikace Finální notifikace zákazníka o vytvoření rezervace. V případě platby přes internet, pomocí služby 3Dsecure, se zobrazí odkaz na přesměrování na platební terminál, kde dojde k platbě.
2.2
Položky v objednávce
2.2.1 Klíčové položky Klíčovými položkami pro dokončení objednávky jsou destinace, PSČ, informace o zákazníkovi.
strana
7
49
2.2.1.1 Destinace Destinace zájezdu je reprezentována názvem a cenou za jednotlivce. 2.2.1.2 PSČ Odjezdová stanice vyskytující se v nějaké oblasti je reprezentována poštovním směrovacím číslem. 2.2.1.3 Zákazník Zákazník je definován jménem, bydlištěm, datem narození a kontaktními údaji, jako je mobil, email. Systém musí být připraven na použití rodného čísla v případě pojištění.
2.2.2 Doplňující položky Spolucestující, telefon zákazníka, rodné číslo, pojištění zákazníka.
2.3
Kontrola a bezpečnost vstupních údajů
Vstupní kontrola údajů je jeden z hlavních požadavků této aplikace, aby zabránila vložení chybných, resp. neúplných údajů. Tento požadavek je hlavně z důvodu použití těchto informací pro generování smlouvy tak, aby byla platná z právního hlediska.
2.4
Notifikace
2.4.1 Mail O úspěchu vytvoření objednávky bude zákazník informován mailem na adresu, kterou uvedl. Mail bude automaticky generován dle zadané šablony tak, aby bylo jasné, kam a kdy odjíždí a doplňující informace o způsobu úhrady, jenž si zvolil.
2.4.2 Smlouva Smlouva bude přikládána jako příloha k notifikačnímu mailu ve formátu PDF.
2.4.3 Složenka V případě, že si zákazník zvolí způsob úhrady složenkou, bude mu zaslán v příloze vzor, jak vyplnit složenku. Formát složenky bude JPEG.
2.5
3DSecure
V systému bude implementován 3DSecure systém České spořitelny, pomocí kterého budou zprostředkovány platby přes webové prostředí.
2.6
Konfigurace
Systém musí být částečně konfigurovatelný, umístění databáze, formátu složenky, notifikačních maily, formát přílohy.
strana
8
49
2.7
Provozní prostředí
2.7.1 Webhosting Webové stránky jsou vytvořeny pomocí PHP skriptovacího jazyka jsou hostovány u společnosti Český hosting na operačním systému GNU/Linux. Aplikace bude navržena tak, aby byla nezávislá na hostujícím operačním systému.
2.7.2 Kancelář Kancelářský systém běží na operačním systému Windows 2003 (Small Bussines Server 2003 R2), jako databáze je použitý Microsoft SQL server.
2.8
Minimalizace komunikace
Systém musí optimalizován tak, aby nedocházelo ke zbytečné komunikaci se serverem v kanceláři.
strana
9
49
3
ANALÝZA V této kapitole jsou uvedeny základní body věnující se analýze výše uvedeného zadání.
3.1
Uživatelské role
Z výše uvedeného zadání vyplývá jediná role, kterou je zákazník. Zákazníkovi bude umožněno vytvářet registrace na základě zveřejněných zájezdů.
3.2
Systémové role
Díky složitějšímu uspořádání dané aplikace, tj. presentace je umístěna jinde než úložiště dat a spojení mezi nimi je úzkým hrdlem dané aplikace, proto jsou zavedeny tyto systémové role.
3.2.1 Klient Role určená pro zákazníka.
3.2.2 Český hosting Tato role je určena pro server, kde jsou umístěny webové stránky. Zde jsou umístěny veškeré presentační materiály. Tento bod je hlavním komunikačním prostředkem pro zákazníka, resp. klienta.
3.2.3 Kancelář Jedná se o roli, do které spadá hlavní datové úložiště, zde se nacházejí veškerá produkční data, jako jsou názvy zájezdů, jejich ceny, termínu odjezdů apod. Zde dochází k vytvoření samotné objednávky, notifikačních mailů a ověřování dat pro banku.
3.2.4 Banka Role určená pro bankovní systém zprostředkovávající platbu přes internet. Jedná se v podstatě o nezávislý vnější element, který nezasahuje do procesu vytvoření objednávky. Banka si pouze ověřuje data v případě platby pomocí platební karty, zdali jsou data skutečné a správné, aby nedošlo k neoprávněné finanční transakci.
3.3
Komunikace
Vzhledem k dané konfiguraci a to, že jsou webové stránky mimo kancelář, tj. hostované na serveru Českého hostingu jsou webové stránky úplně odděleny od kancelářského prostředí, kde se nacházejí veškerá potřebná data pro fungování aplikace. Proto jsou zavedeny 4 typy komunikačních kanálů a to Zákazník – Český hosting a Český hosting – kancelář. Další 2 komunikační kanály jsou Český hosting – banka a Banka – kancelář, tyto kanály jsou využity pouze v případě, že zákazník platí pomocí platební karty.
strana
10
49
3.3.1 Zákazník – Český hosting V tomto komunikačním kanále probíhá kompletní sběr informací od zákazníka. V současné implementaci zde není zavedeno šifrování pomocí SSL, protože rodné číslo, které se považuje za soukromí údaj, není vyžadováno a zákazníkovi není nabízeno k vyplnění. Dalším důvodem je, že Český hosting službu šifrované komunikace (tj. zveřejnění stránek pomocí https) zpoplatňuje měsíčním paušálem.
3.3.2 Český hosting – kancelář Tento kanál v současné implementaci není šifrován (Pro zvýšení bezpečnosti lze využít https komunikaci). Tento kanál je určený pro vlastní vytvoření objednávky do kancelářského systému.
3.3.3 Český hosting – banka V tomto komunikačním kanále dochází k přesměrování zákazníka vč. potřebných dat na stránky české spořitelny, kde dochází k vyplnění údajů k dokončení procesu platby.
3.3.4 Banka – kancelář Kanál je šifrován pomocí SSL, resp. využívá https komunikace. V tomto kanále se ověřují data, aby nedošlo k neoprávněné platbě. Na základě přesměrování uživatele s daty na stránky systému 3DSecure si banka 2x ověří vstupní data s kanceláří. Poprvé při přesměrování, podruhé při vyplnění zákazních dat ohledně platební karty. Pokud se neshoduje některý z určených parametrů, platba se zamítá a označuje jako neoprávněná.
3.4
Zabezpečení systému
Způsob zabezpečení je poněkud odlišný od běžných internetových obchodů. Vzhledem k tomu, že objednávky jsou jednorázové, není zde nutné uchovávat registrační údaje pro pozdější zpracování. Odpadá nám tímto tedy nutnost zavádět registrační, resp. zákaznické uživatelské jméno a heslo a rozlišovat tak různé role v systému.
3.4.1 Vstupní údaje Vstupní údaje jako informace o zákazníkovi nelze nijak efektivně kontrolovat na smysluplnost, proto zde existuje pouze ověření na vyplnění. V případě telefonních čísel, mailu, rodného čísla apod. lze efektivně ověřit alespoň formát vstupních dat.
3.5
Notifikace
Veškerá notifikace zmíněná v zadání je vytvořena a odeslána až po úspěšném vytvoření objednávky. Mail může obsahovat 2 formáty. Prostý text a html stránku. Vzhledem k šablonám je zvolena pouze varianta s html stránkou. V případě, že má uživatel zobrazen mail pouze ve formě prostého textu, zobrazí se mu zpráva o tom, aby upravil náhled do html. V případě příloh je již v zadání vhodně zvolený formát PDF pro smlouvu, který je nezávislý na platformě a jednoduše brání úpravě smlouvy. Pro každý
strana
11
49
způsob úhrady je zavedena šablona, protože některé veřejné mailovací služby ignorují CSS styly v html stránce. Čímž brání k jednoduchému formátování pomocí stylů a dochází tak k zobrazování informací, které mohou být uživateli skryty pouze pomocí stylu.
3.6
Konfigurace
Konfigurace je možné řešit různými způsoby. Vhodným řešením pro jednoduchost je ukládání parametrů do textového souboru, který je snadno, přenositelný, upravitelný a pochopitelný i pro obyčejného uživatele. Proto je zvolen tento způsob konfigurace parametrů na straně kanceláře i českého hostingu.
3.7
Minimalizace komunikace
Komunikace Český hosting – kancelář je poněkud úzkým hrdlem celého procesu objednání. Vzhledem k tomu, že je kancelář připojená na internet několika řádově nižším připojením než se používá pro standardní webhosting (tj. v současné konfiguraci 2MBit/2MBit). Toto připojení používá cca 100 počítačů, což by v extrémních případech mohl vést k dosti pomalým odezvám při komunikaci Zákazník – Český hosting, které je závislé na komunikačním kanále Český hosting – kancelář, kvůli zjištění potřebných údajů jako jsou zájezdy, odjezdová místa atp. Z tohoto důvodů je zavedena cache těchto dat. Tím se zajistí, že v ideálním případě dojde k vytvoření komunikačního kanálu Český hosting – kancelář pouze jednou a to v případě odeslání rezervace za účelem vytvoření objednávky. Nevýhodou je však určitý (konfigurovatelný) časový interval, po který se nebudou promítat změny z kancelářského prostředí na internet.
strana
12
49
4
IMPLEMENTACE 4.1
Implementační elementy
4.1.1 Rezervace Rezervace je pseudoobjednávka figurující pouze na straně českého hostingu, která v ideálním případě končí jako objednávka odesláním požadavku do kancelářského prostředí, kde dojde k jejímu vytvoření. Rezervace se zapisuje do MySQL databáze umístěné u českého hostingu. Využití relační databáze je z několika důvodů. Je to snadně dostupné, kvalitní a rychlé datové úložiště, které Český hosting poskytuje již v základním balíku služeb webhostingu. Nepřímo také zajišťuje zabezpečení zpracovávaných dat, oproti např. skrytým objektům webového formuláře, kde lze jednoduše změnit obsah. U těchto dat nelze nijak stoprocentně říci, zdali jsou tatáž, které jsme odeslali ke klientovi, pokud nedržíme tyto data i na straně serveru. Toto je způsobeno samotným principem WWW komunikace, v podstatě to znamená, že klient naváže spojení, vyžádá si data, server je odešle a komunikace se ukončí. Rezervace jako taková se vytváří při každém pokusu o založení objednávky. K rezervaci se ukládají i další systémové informace o klientovi tj. použitý webový browser, IP adresa klienta, čas vytvoření, FQDN uživatele. Rezervace jako taková funguje pouze na straně českého hostingu a kancelář o těchto rezervacích neví.
4.1.2 Objednávka Objednávka je finální produkt daného procesu rezervace. Vzniká z rezervace až ve finálním kroku, tj. kdy zákazník klikne na posledním formuláři na tlačítko Objednat. Tím dojde k odeslání rezervace a následnému vytvoření objednávky na straně kanceláře. Výsledkem je vytvoření záznamů do databáze MSSQL, vytvoření a odeslání notifikačního mailu zákazníkovi dle šablony.
4.1.3 Privátní notifikační mail Email, který je zaslán zákazníkovi po úspěšném vytvoření objednávky. Na tento email jsou vytvořeny šablony, každý typ platby má svojí šablonu. Do tohoto emailu se vždy vkládá smlouva a v případě platby složenkou se vkládá i soubor, který je vzorem, jak složenku vyplnit.
strana
13
49
4.2
Český hosting
strana
14
49
4.2.1.1 Databáze Přístup k databázi je implementován pomocí třídy DatabaseConnector, která byla navržena pro jednodušší přístup k datům. Tato třída obsahuje základní metody pro čtení, resp. zápis, změnu dat v databázi. 4.2.1.2 Konfigurace Konfigurace aplikace na straně Českého hostingu je řešena pomocí konfiguračních souborů, kde jsou potřebné data k funkčnosti aplikace. O přístup ke konfiguračním datům je implementován pomocí třídy Configuration.
4.2.2 Použité technologie • • • • • •
PHP MySQL AJAX Javascript XHTML 1.0 Strict CSS 2.0
4.2.3 Prezentační vrstva Prezentační vrstva je tvořena 4 formuláři, které obstarávají kompletní komunikaci se zákazníkem, která je potřeba pro úspěšné dokončení procesu rezervace. Stavební kámen je skriptovací jazyk PHP, který zajišťuje kontrolu dat, komunikaci s databází a generování finálních HTML stránek, které jsou odeslány klientovi. Vzhledem k tomu, že je využito HTML formátu XHTML 1.0 Strict je zde nutnost, aby formátování formulářů bylo pomocí kaskádových stylů, pokud vyžadujeme HTML validní kód. 4.2.3.1 Formulář 1 – Vytvoření rezervace Tento formulář zajišťuje, aby zákazník vyplnil požadovaná data o sobě, spolucestujících a vybral si destinaci a místo odjezdu. 4.2.3.2 Formulář 2 – Kontrola vstupních dat a dodatek Tento formulář slouží ke kontrole vstupních dat, aby si zákazník ověřil volbu destinace, odjezdové místo a svá vstupní data, tj. jméno a příjmení, bydliště, kontakt atp. Na tomto formuláři má zákazník možnost připsat dodatek ve formě poznámky, která se pak v kancelářské aplikaci zobrazí. 4.2.3.3 Formulář 3 – Výběr způsobu úhrady Zde zákazník vybírá typ platby a je obeznámen o daném rozpočtu jeho zájezdu. Česká spořitelna poskytuje 4 měny a to CZK, SKK, EUR, GBP. Návrh formuláře je uzpůsoben, aby zákazník mohl vybírat typ měny. Samotná implementace kancelářské aplikace, však není navržena v současnosti na to, aby existovalo víc typů měny, proto je podpora více měn vypnuta a nelze jí změnou konfigurace zapnout, protože nebylo možné tuto podporu otestovat v produkčním prostředí, a proto je v současné době možno platit pouze v českých korunách. Základní typy plateb jsou hotově, bankovním
strana
15
49
příkazem, složenkou, platbou přes internet. Platba přes internet je rozdělena nadále na typy platebních karet, které jsou Visa, Visa Electron, MasterCard, Maestro. 4.2.3.4 Formulář 4 – Vytvoření objednávky Tento formulář je již pouze notifikační a informuje o průběhu vytvoření objednávky, kde je zákazník obeznámen o čísle jeho rezervace. V případě platby přes internet se zobrazuje tlačítko Zaplatit, kterým zákazník pokračuje na platební terminál České spořitelny, aby mohl zaplatit. V případě, že zákazník z nějakého důvodu nezaplatí, nebo transakce neproběhne. Je zde v kancelářském prostředí kontrola vůči příchozím platbám za daný zájezd. V případě, že zákazník nezaplatí, je telefonicky kontaktován, příp. se objednávka stornuje.
4.2.4 Informační vrstva Tato vrstva je součástí prezentační vrstvy, vzhledem k tomu, že je závislá na Javascriptu, nemusí být funkční u klientů, kteří mají vypnutou podporu Javascriptu. Tato vrstva není nutná pro funkčnost, slouží zde pouze pro lepší orientaci a pro zpříjemnění ovládacích prvků daného formuláře. 4.2.4.1 Tooltip Část informační vrstvy je tvořená pomocí tzv. tooltipů. Jedná se o formulářový doplněk, který se zobrazuje při najetí kursoru myši nad daný objekt. Tím se zobrazí tooltip pro daný objekt. A uživatel je informován o tom, že např. datum narození je povinný údaj, jednoduchý popisek a také formát, kterým se dané pole vyplňuje. V tomto případě např. dd.mm.rrrr (den, měsíc, rok). Tento doplněk je vytvořen pomocí AJAXové knihovny DomTT, která je volně šiřitelná. 4.2.4.2 Autocomplete Druhá část informační vrstvy je postavena na AJAXu. Jedná se o formulářový doplněk tzv. Autocomplete. Jedná se o práci zpříjemňující doplněk, který automaticky doplňuje hodnoty vyplňované do TextBoxu. Implementace je pomocí knihovny Ajax Agent for PHP, která je opět volně šiřitelná. Implementace je taková, že při vyplňování PSČ (reprezentuje oblast odjezdového místa) se zobrazí ovládácí prvek Select, ve kterém si zákazník může jednoduše vybrat PSČ s názvem města. Při výběru se toto PSČ a město doplní automaticky do informačních údajů k objednávce.
4.2.5 Kontrolní vrstva Kontrola vstupních dat probíhá ve 2 úrovních. Jednak na straně klienta pomocí Javascriptu a také na straně serveru, resp. Českého hostingu pomocí PHP. Tento problém je obecný na poli internetu a to z toho důvodu, že Javascript lze ve standardních prohlížečích vypnout, na druhou stranu má výhodu v komfortnějším využití a není zde nutnost obnovovat stránku (odeslat na server a zase jí načíst). Kontrola pomocí PHP na straně serveru je tedy nutná podmínka pro případ, že klient nemá zapnutou podporu Javascriptu. 4.2.5.1 PHP Kontrola vstupních dat je realizována pomocí PHP metody mainControl() umístěnou v DataController.php. V této metodě je kontrola veškerých vstupních dat. Ve většině se kontroluje pouze existence těchto dat (jméno, ulice…), zde není možno strana
16
49
reálně kontrolovat hodnotu těchto vstupních dat, zdali jsou smysluplná. U telefonních čísel, PSČ lze kontrolovat formát tak, aby splňoval podmínky. K tomuto jsou využity regulární výrazy. Bohužel zde není možnost kontrolovat smysluplná data, to znamená, že například rodné číslo (implementováno, ale nepoužívá se) je zde kontrolováno na počet 9 nebo 10 číselných znaků. Dělitelnost 11 není stoprocentní (http://cs.wikipedia.org/wiki/Rodn%C3%A9_%C4%8D%C3%ADslo). Proto zde může zákazník vyplnit hodnotu např. 1234567890, která splňuje formát 10 číselných hodnot, ale jedná se o nesmyslnou hodnotu. Stejný problém je i u telefonních čísel. 4.2.5.2 Javascript Jak jsem již zmínil výše, Javascript je pouze postačující podmínkou na kontrolu dat, výhodou je však možnost okamžité reakce na danou událost a tím příjemnější chování a ovladatelnost formulářů. Kontrola je v tomto případě shodná jako u PHP kontroly. V případě chybného údaje je o tom klient obeznámen ihned po opuštění objektu tím, že danému objektu je změněno pozadí na červené. V ostatních případech pomocí tzv. MessageBoxu a zároveň na dobu, dokud se nestiskne OK, se opět mění barva pozadí daného objektu na červenou, aby bylo lépe vidět, kde chyba vznikla. 4.2.5.3 Kontrola
Datový objekt
Typ Kontroly
Jméno, příjmení, ulice, město
Kontrola existence
PSČ
5 číselných znaků Převod na datový typ Date
Datum narození
Datum narození na smlouvu musí být větší 18ti let. Datum narození u spolucestujícího je menší 14ti let, v případě, že má volbu přistýlky. Rodné číslo (pokud je povoleno)
9 nebo 10 číselných znaků a to pouze v případě, že je vybráno cestovní pojištění.
Telefon, mobilní telefon, email
Regulární výraz
Rezervace
Kombinace počtu cestujících a přistýlek musí být vždy tak, aby vznikalo obsazení pokoje 2osoby+1přistýlka na 1 pokoj.
Slabší kontrola smysluplnosti vstupních dat není možná ideální, ale v tomto případě se předpokládá, že zákazník sám ve své vůli vyplňuje vhodná data. Protože např. při špatném telefonním kontaktu ho není možné kontaktovat v případě problému s platbou apod. Nehledě na to, že by kód takovéto kontroly nebyl nikdy stoprocentně funkční a rentabilita takového kódu by byla velmi špatná.
4.2.6 Datová vrstva Jako datové úložiště byla zvolena databáze MySQL. Hlavním důvodem je fakt, že Český hosting tuto databázi poskytuje v základním balíčku služeb webhostingu. Zároveň je MySQL kvalitním a dobře pracujícím nástrojem pro ukládání dat a PHP jazyk má komponenty pro spolupráci s MySQL. Návrh databáze je jednoduchý a záměrně zvolen obdobný návrh jako je v kancelářské aplikaci, aby se SQL dotazy podobaly a tím
strana
17
49
se v budoucnu případně ušetřilo pro opravu nebo rozšíření funkčnosti této aplikace. Návrh, jak jsem zmínil výše, je odvozen od existující databáze. Není zde kladen důraz na efektivitu ukládání dat, tj. minimalizace redundance, ani na normální formu, ale na jednoduchost a podobnost s již existující databází v kancelářském prostředí. Tabulka
Účel
Objednavky
Hlavní tabulka, kde jsou veškeré informace o dané rezervaci. Dle mého názoru takovýto návrh není ideální, ale v tomto případě, jak jsem již zmínil, na podobnost k databázi v kancelářském prostředí.
Ne
Spolucestujici
Tabulka, kde se ukládají spolucestující
Ne
Ceny
Do této tabulky se ukládá cenová varianta zákaznické volby.
Ano
Stats
Místo pro statistiky. Zde se ukládají informace o klientovi jako jeho IP adresa, FQDN, typ webbrowseru.
Ne
Posta
Tabulka poštovních údajů. Potřebná pro autocomplete (viz. 4.2.3.2)
Ne
Tempdata
Tabulka získaných dat z kancelářského protředí.
Ano
strana
18
49
Cache
4.2.6.1 Datový model
4.2.7 Komunikační vrstva 4.2.7.1 Český hosting - kancelář Komunikační kanál Český hosting – kancelář je zprostředkován pomocí webové služby. Komunikační vrstva probíhá pomocí WSDL protokolu zapouzdřeného v HTTP resp. HTTPs komunikaci, což poskytuje jednoduchý, ale silný nástroj pro komunikaci. Na straně Českého hostingu se nachází klient k této službě, který se na základě zákaznických kroků dotazuje na požadovaná data, jako jsou destinace, místa odjezdu, ceny, resp. odesílá finální podobu rezervace za účelem vytvoření objednávky. Komunikace je zprostředkována objektem WebServiceProvider pro přímou komunikaci resp. WebServiceDataFaker, který počítá s existencí cache a na základě konfiguračního parametru vrací data buď z cache, a nebo se dotazuje pro aktuální data pomocí WebServiceProvideru.
strana
19
49
4.2.7.2 Český hosting - banka Implementace 3D Secure systému na stranu českého hostingu je poměrně jednoduchá. Zákazník se přesměrovává na stránky platebního terminálu a to pomocí HTTP metody POST a poté již probíhá komunikace mezi bankou a zákazníkem.
4.2.8 Objektová vrstva Objektové programování, jakožto moderní přístup pro vývoj aplikací je známý již několik desítek let a dobře se osvědčuje v praxi. Skriptovací jazyk PHP objektový model zavedl až ve verzi 5, avšak jeho použitelnost je omezená oproti jiným programovacím jazykům.
strana
20
49
4.2.8.1 Osoby
strana
21
49
4.2.8.2 Rezervace
4.2.8.3 Komunikace
strana
22
49
4.2.8.4 Databáze
4.2.8.5 Konfigurace
strana
23
49
4.2.9 Vývojový digram vytvoření objednávky
1. Formulář
Výběr destinace a odjezdového místa
Vyplnění požadovaných údajů
Nekorektní nebo neúplná data Kontrola vstupních dat systémem
2. Formulář
Data jsou korektní a úplná
Kontrola vstupních dat zákazníkem
Vyplnění poznámky
Data jsou správná
3. Formulář
Zjištění ceny zákazníkovi konfigurace
Výběr způsobu úhrady
Platba pomocí 3DSecure
Ne
Ano
4. Formulář
Odeslání požadavku na vytvoření objednávky a notifikace o jejím průběhu a přesměrování
Odeslání požadavku na vytvoření objednávky a notifikace o jejím průběhu
strana
24
49
Notifikace o průběhu platby
Zaplacení na platebním terminálu 3D Secure
4.2.10 Implementační problémy Hlavní problém, který nastal při implementaci, byl při odesílání dat v objektové podobě do kancelářského prostředí, kde nastávaly výjimky, a program se stal nefunkčním. Problematika byla řešena se support oddělením Českého hostingu, kde bylo doporučení, vyhnout se plně objektovém přístupu, kde vznikají určité problémy ve verzi PHP, která je nasazena v produkčním prostředí firmy Český hosting. Proto tedy objektový návrh není ideální resp. úplný a kód byl upraven tak, aby datovým výsledkem rezervace bylo pole stringů, které při testování splňovalo podmínky použitelnosti a nevykazovalo chyby. Generování příslušného textového řetězce daného objektu je implementováno pomocí metody toString() dané třídy.
strana
25
49
4.3
Kancelář
strana
26
49
4.3.1.1 Databáze Přístup k databázi je implementován pomocí tříd DatabaseConnector, DataReader, DataWriter, které byly navrženy pro jednodušší přístup k datům. Tato třída obsahuje základní metody pro čtení, resp. zápis, změnu dat v databázi. 4.3.1.2 Konfigurace Konfigurace aplikace na straně kanceláře je řešena obdobně jako na straně Českého hostingu a to pomocí konfiguračního souboru, kde jsou potřebné data k funkčnosti aplikace. O přístup ke konfiguračním datům je implementován pomocí třídy Configuration.
4.3.2 Použité technologie • • • • •
C# 3.0 ASP.NET 2.0 PHP Microsoft Reporting technology Microsoft Small Bussiness Server R2 o Internet Information Server 6.0 (IIS) o Microsoft SQL Server 2005 (MSSQL)
4.3.3 Implementační elementy 4.3.3.1 Smlouva Dokument určený pro zákazníka a kancelář. 4.3.3.2 Složenka Poštovní poukázka ve formě obrázku určená pro finanční transakci pomocí české pošty.
4.3.4 Publikační vrstva Tato vrstva umožňuje vytvoření komunikačního kanálu Český hosting – kancelář a poskytuje 4 metody pro publikace kancelářských dat (getDestinations, getZastavky, getPrices, createNewRegistration), které jsou potřeba pro prezentační vrstvu na straně českého hostingu. Komunikace je pomocí WSDL protokolu zapouzdřená do HTTP protokolu.
4.3.5 Komunikační vrstva 4.3.5.1 Kancelář – Český hosting Komunikační kanál určený pro publikaci kancelářských dat pro prezentační vrstvu na straně české hostingu. (viz 4.2.7.1) 4.3.5.2 Kancelář – Banka Tento komunikační kanál slouží pro ověřování a potvrzovaní bankovních transakcí. Probíhá pomocí HTTPs protokolu tak, aby nemohlo dojít k nežádoucímu odposlechu privátních dat zákazníka na internetu. Tento kanál se používá pouze při platbě pomocí 3DSecure systém české spořitelny. Implementace je realizována pomocí PHP skriptů Validation.php a Confirmation.php.
strana
27
49
4.3.5.3 Kancelář – zákazník Tento kanál slouží k privátní notifikaci zákazníka o vytvoření objednávky. Probíhá pomocí mailové komunikace přes SMTP protokol. V této vrstvě dojde k vytvoření mailu pomocí upravení HTML šablony a jako příloha je přiložena smlouva, příp. vzor pro vyplnění složenky při platbě složenkou. Takto vytvořený mail je odeslán na email uvedený zákazníkem.
4.3.6 Reportovací vrstva Tato vrstva je určená pro generování smluv dle zákazníkových údajů, příp. pro vygenerování vzoru složenky pro zaplacení. 4.3.6.1 Smlouva Smlouva je vytvořená pomocí technologie Microsoft Reporting technology, která je plně dostačující pro generování jednoduchých dokumentů, kterým je i námi generovaná smlouva, kde většina dat je statických. Za opravdu dynamická data lze považovat pouze tabulku spolucestujících, která může smlouvu zvětšit až na jednotky stránek. Ostatní data jsou vyplněna na předem určená místa a ovlivnit formátování můžou pouze v extrémních případech. Výstupním formátem je ve výchozím nastavení PDF formát. Pomocí konfiguračních souborů lze využít další formáty TIFF, Excel. 4.3.6.2 Složenka Tato část reportovací vrstvy je určená pro generování obrázků, které slouží jako předlohy, jak vyplnit poštovní poukázku pro úhradu finanční částky. Tato komponenta je navržena tak, aby dle zadání umožňovala poměrně jednoduchou úpravu současných nastavení pro složenky. Vytvoření nového typu složenky si však vyžádá programátorskou úpravu, tj. vytvoření třídy pro danou složenku, protože nebyl vytvořen user-friendly nástroj pro vytváření těchto datových objektů. Úpravu složenky (přemístění objektu) lze provést pomocí konfiguračních souborů. Výsledkem této komponenty je obrázek ve formátu JPG, ve kterém je vyplněná složenka tak, jak by jí měl vyplnit zákazník a je přikládána do privátního notifikačního mailu. V současné implementaci je realizována varianta pro českou republiku a je vytvořena šablona pro slovenskou republiku, která není nasazena do produkčního prostředí z důvodu nedokončené úpravy aplikačního prostředí na straně kanceláře.
4.3.7 Datová vrstva Datové úložiště kancelářské aplikace je Microsoft SQL Server, proto je i kancelářská část této aplikace vytvořena pro tento databázový systém. Databáze byla upravena pouze minimálně a to o pole, která určují, zdali má být naplánovaný zájezd publikován na internetu. Rozšíření bylo vytvořeno spíše z hlediska logování. To znamená tabulky, do kterých se zaznamenávají statistické údaje o ceně a komunikaci s bankou.
strana
28
49
Tabulka
Účel
T_CenyWS
Jedná se o identickou tabulku jako je ceny na straně české hostingu. Záznam cen pro danou smlouvu pro případ, že dojde ke změně ceny zájezdu.
T_PlatbyECConf
Tabulka určená pro logování komunikace s bankou ověřující data transakce a potvrzují její dokončení.
T_PlatbyECValid
Tabulka určená pro logování komunikace s bankou ověřující data transakce.
4.3.7.1 Datový model Datový model vyjadřuje pouze tabulky, které byly upraveny nebo přidány pro naší aplikaci.
strana
29
49
4.3.8 Objektová vrstva Celá aplikace je postavena na technologii C#, která jakožto moderní jazyk plně využívá síly objektového programování oproti PHP. Proto je i aplikace navržena objektově. 4.3.8.1 Osoby
strana
30
49
4.3.8.2 Rezervace
strana
31
49
4.3.8.3 Komunikace
strana
32
49
4.3.8.4
strana
Databáze
33
49
4.3.8.5 Složenky 4.3.8.5.1 Interface
4.3.8.5.2
Struktury a výčtové typy
4.3.8.5.3
Výčtové typy
strana
34
49
4.3.8.5.4
strana
Objekty
35
49
strana
36
49
strana
37
49
strana
38
49
4.3.8.6 Konfigurace
strana
39
49
4.3.9 Vývojový diagram zpracování objednávky Příjem požadavku o vytvoření objednávky ze strany Český hosting
Vytvoření záznamu objednávky
Existují spolucestující
Ano
Vytvoření záznamu spolucestujícího Ano
Existuje další spolucestující Ne Ne
Vytvoření smlouvy
Typ platby složenkou? Vytvoření složenky
Vytvoření notifikačního mailu
Odeslání notifikačního mailu zákazníkovi
Odeslání čísla smlouvy na stranu Českého hostingu
strana
40
49
4.4
3D Secure systém
3D Secure je služba poskytovaná Českou spořitelnou, která umožňuje realizovat bankovní transakce pomocí internetu. Z hlediska složitosti je velmi dobře navržená pro snadnou zákazníkovu implementaci. Celý proces začíná přesměrováním zákazníka na stránky české spořitelny s potřebnými údaji o dané transakci. Během doby, kdy zákazník vyplňuje potřebná data k realizaci transakce, se přeposlaná data 2x ověřují tak, aby v případě neoprávněné transakce nedošlo k jejímu provedení. Při ukončení je zákazník přesměrován zpět, kde je notifikován o úspěchu, resp. neúspěchu jeho požadované transakce. Vzhledem k tomu, že není způsob, jak donutit zákazníka dokončit požadovanou transakci, je každá objednávka placená pomocí 3D Secure systému náležitě označena. V současné implementaci je to pouze pomocí poznámky k dané objednávce, kde se vyplňuje typ platby a v případě dokončení transakce i její výsledek. Je tak poměrně jednoduše zjistitelné, zda-li zákazník zaplatil, ať už úspěšně nebo neúspěšně a nebo se ani zaplatit nepokusil. V jakémkoliv jiném případě, než je úspěšná platba, je zákazník telefonicky kontaktován pro další jednání ohledně platby.
4.4.1 Použité technologie • •
PHP Microsoft Small Bussiness Server 2003 R2 o Internet Information Server 6.0 (IIS) o Microsoft SQL Server 2005 (MSSQL)
4.4.2 Vytvoření požadavku o transakci V případě, že si zákazník vybere platbu kreditní kartou přes internet, se objeví na 4. formuláři tlačítko „Zaplatit“, které zákazníka přesměruje. Přesměrování dat probíhá pomocí HTTP metody POST. Data, která se odesílají, jsou uložena pomocí skrytých textboxů ve finálním 4. formuláři. Tím dojde k přesměrování a odeslání dat o požadované transakci na stranu české spořitelny.
4.4.3 Ověření dat Jakmile je zákazník přesměrován na platební terminál umístěný u české spořitelny se data ověřují, zda-li nedošlo k neoprávněnému požadavku. Tento komunikační kanál probíhá pomocí HTTPs. Povinně se ověřují parametry jako cena, měna, heslo (předem zvolené, které si strany české spořitelny a kanceláře domlouvají při podpisu smlouvy), id klienta (zákazník české spořitelny, tj. kanceláře). Data se kontrolují tedy na straně kanceláře a banka čeká návratovou hodnotu daného ověření. Výsledkem ověření je html stránka [OK] v případě úspěšného ověření, a nebo [nOK] v případě neúspěchu. Při neúspěšném ověření, příp. při jakémkoliv jiném návratovém stringu dané html stránky je transakce označená jako neplatná a dojde k jejímu zamítnutí. Zákazník je přesměrován zpět na 4. formulář spolu s informacemi, proč nedošlo k úspěšnému dokončení transakce, kde mu jsou zobrazeny.
4.4.4 Potvrzení dat V případě, že ověření dat bylo úspěšné, zákazník vyplňuje své informace o platební kartě pomocí, které chce danou platbu realizovat. Zadá-li zákazník platné
strana
41
49
údaje o platební kartě a danou transakci je možno realizovat, dojde ke spuštění shodného procesu jako v bodě 4.4.3, čímž dochází k potvrzení dat o dané transakci. Dojde-li ke kladnému potvrzení, transakce se označuje za úspěšnou a dochází k samotnému peněžnímu transferu, naopak při záporném potvrzení se transakce označuje za neoprávněnou a dojde k jejímu zamítnutí. Zákazník je přesměrován zpět na 4. formulář, kde je notifikován o průběhu.
strana
42
49
4.4.5 Vývojový diagram platby přes internet
strana
43
49
5
KOMUNIKAČNÍ MODEL
strana
44
49
5.1
Kompletní vývojový diagram zpracování objednávky
strana
45
49
5.2
Kompletní scénař úspěšného vytvoření objednávky vč. platby pomocí 3D Secure
Následující tabulka zobrazuje scénář ideálního průběhu při vytvoření objednávky a následném placení přes internet. Není zde zobrazeno využití cache. Zobrazuje tedy scénář, kdy dojde k využití všech komunikačních kanálů. Lokalita zákazníka
1.Formulář
2. Formulář 3. Formulář
4. Formulář
3D Secure terminal 4. Formulář
strana
Proces
Komunikační kanál
Protokol
Zákazník zobrazuje 1. formulář Zjištění publikovaných destinací Zákazník vybírá destinace a zjišťuje místa odjezdu Zjištění naplánovaných odjezdových míst Zákazník vybírá místa odjezdu a vyplňuje kontaktní údaje, příp. spolucestující a tato data odesílá ke zpracování Zákazník vyplňuje poznámku a data odesílá ke zpracování Výpočet ceny dané konfigurace Výběr typu platby a odeslání dat Vytvoření objednávky Notifikace zákazníka privátním notifikačním mailem Notifikace zákazníka o čísle jeho objednávky Přesměrování zákazníka k platebnímu terminálu Ověření platnosti dat Vyplnění zákazníkových údaju o platební kartě Potvrzení platnosti dat Přesměrování zpět
Zákazník – Český hosting Kancelář – Český hosting Zákazník – Český hosting Kancelář – Český hosting
HTTP HTTP HTTP HTTP
Zákazník – Český hosting
HTTP
Zákazník – Český hosting
HTTP
Kancelář – Český hosting Zákazník – Český hosting Kancelář – Český hosting Zákazník – kancelář Zákazník – Český hosting Český hosting – Banka Kancelář – Banka Zákazník – Banka Kancelář – Banka Český hosting – Banka
HTTP HTTP HTTP SMTP HTTP HTTPS HTTPS HTTPS HTTPS HTTP
Finální notifikace zákazníka o průběhu platby
Zákazník – Český hosting
HTTP
46
49
6
ZÁVĚR V současné době je aplikace nasazena do produkčního prostředí a plně funkční od spuštění, které proběhlo v půlce února. Pomocí této aplikace bylo vytvořeno již téměř 3000 objednávek, z čehož asi 2% byly zaplaceny pomocí 3D Secure systému, což napovídá o silné nedůvěře k placení pomocí internetu.
strana
47
49
7
PŘÍLOHY 7.1
DVD • •
strana
Virtuální operační systém s celým systémem VMWare Player
48
49
8
POUŽITÁ LITERATURA [1] ASP.NET 3.5 Unleashed, Copyright © 2008 by Sams Publishing [2] Pro C# 2008 and the .NET 3.5 Platform, Fourth Edition, Copyright © 2007 by Andrew Troelsen [3] Pro T-SQL 2005 Programmer’s Guide, Copyright © 2007 by Michael Coles [4] Client-Side Reporting with Visual Studio in C#, Copyright © 2007 by Asif Sayed [5] Practical Web 2.0 Applications with PHP, Copyright © 2008 by Quentin Zervaas [6] The Best-Practice Guide to XHTML&CSS, Copyright © 2007 by Patrick Griffiths
strana
49
49
