Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Online systém splátkového prodeje pro internetové obchody Diplomová práce

Autor:

Bc. Peter Kocnár Informační technologie a management

Vedoucí práce:

Ing. Vladimír Beneš

Praha

Červen 2013

1

Poděkování:

Rád bych touto cestou poděkoval panu Ing. Vladimíru Benešovi za cenné rady při zpracování mé diplomové práce.

Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze dne 26. 6. 2013

Peter Kocnár

Anotace Předmětem diplomové práce „Online systém splátkového prodeje pro internetové obchody“ je případová studie tohoto systému. První část práce popisuje obchodní a technologické aspekty jeho vzniku a historického rozvoje, další pak architekturu řešení a jeho aplikační části. V poslední části se práce snaţí o zobecnění vývojových tendencí na základě zkušeností z vývoje systému a zhodnocení jeho přínosů.

Klíčová slova:

splátkový prodej, internetové obchody, webové aplikace, vývoj informačních systémů

Annotation Thesis: "Online Installment System for Internet Retailers" is a case study of this system. The first part describes the business and technology aspects of its origin and historical development, the next part describes solution architecture and its application parts. The last part of the work seeks to generalize trends based on the experience of system development and evaluation of its benefits.

Keywords:

installment loans, online retailing, web applications, systems development

Obsah ÚVOD......................................................................................................................................... 8 1

ZVOLENÉ METODY ZPRACOVÁNÍ ............................................................................. 9

2

HISTORICKÉ OKOLNOSTI, OBCHODNÍ VÝCHODISKA ........................................ 10 2.1

2.1.1

Historie ............................................................................................................... 10

2.1.2

Postup nákupu na splátky v prodejně ................................................................. 10

2.1.3

Typy úvěrů na splátky ........................................................................................ 11

2.2

Internetové obchody .................................................................................................. 11

2.2.1

Historie ............................................................................................................... 11

2.2.2

Platební systémy v internetových obchodech..................................................... 14

2.3

3

Splátkový prodej ........................................................................................................ 10

Obchodní východiska ................................................................................................ 15

2.3.1

Představení společností participujících na vývoji .............................................. 15

2.3.2

Základní poţadavky na řešení ............................................................................ 18

2.3.3

Business proces .................................................................................................. 19

ARCHITEKTURA ŘEŠENÍ ............................................................................................ 22 3.1

Funkční architektura systému .................................................................................... 22

3.2

Charakteristika webové aplikace a webových sluţeb jako architektonických prvků

systému ................................................................................................................................. 23 3.2.1

Webová aplikace................................................................................................. 23

3.2.2

Webové sluţby ................................................................................................... 25

3.3 4

Umístění aplikací v síťové infrastruktuře. ................................................................. 26

POUŢITÉ TECHNOLOGIE ............................................................................................ 27 4.1

Technologie pro běh webových aplikací ................................................................... 28

4.1.1

Operační systém ................................................................................................. 28

4.1.2

Webový server .................................................................................................... 28 5

4.1.3

Aplikační serverová vrstva ................................................................................. 31

4.1.4

Databáze ............................................................................................................. 32

4.2

5

Pouţité programovací jazyky a frameworky ............................................................. 32

4.2.1

Serverové programovací jazyky a frameworky .................................................. 33

4.2.2

Klientské programovací jazyky .......................................................................... 36

APLIKAČNÍ ČÁSTI SYSTÉMU .................................................................................... 39 5.1

Webové sluţby pro internetové obchody................................................................... 39

5.1.1

Základní princip sluţeb ...................................................................................... 39

5.1.2

Popis jednotlivých sluţeb ................................................................................... 40

4.1.3 Vývojové milníky .................................................................................................... 43 5.2

Úvěr online ................................................................................................................ 46

5.2.1

Funkční popis aplikace ....................................................................................... 46

5.2.2

Vývojové milníky ............................................................................................... 47

5.3

Webtelem ................................................................................................................... 52

5.3.1 5.4

Webový Interní server (WebIS) ................................................................................. 55

5.4.1 6

Funkční popis aplikace ....................................................................................... 52

Funkční popis aplikace ....................................................................................... 55

TECHNOLOGICKÉ PROMĚNY SYSTÉMU A POZOROVANÉ TENDENCE VE

VÝVOJI WEBOVÝCH APLIKACÍ ........................................................................................ 56 6.1

Od tlustých klientů k webovým aplikacím ................................................................ 56

6.2

Od procedurálního k objektovému programování ..................................................... 57

6.3

Od „jednovrstvé“ k vícevrstvé architektuře ............................................................... 58

6.3.1

Vrstvy v architektuře IT systémů ....................................................................... 58

6.3.2

Vrstvy u webové aplikace v PHP ....................................................................... 59

6.4

Od přímé implementace v programovacím jazyce k frameworkům .......................... 61

6.5

Standardizace kódu HTML dokumentů ..................................................................... 63

6.6

Důraz na analýzu a návrh ........................................................................................... 65

6.7

7

Zavádění nástrojů průběţné integrace ....................................................................... 65

6.7.1

Verzovací systém................................................................................................ 66

6.7.2

Automatické buildování ..................................................................................... 66

6.7.3

Automatizace testování ...................................................................................... 67

OBCHODNÍ PŘÍNOSY ................................................................................................... 68

ZÁVĚR ..................................................................................................................................... 70 SEZNAM POUŢITÉ LITERATURY ...................................................................................... 71 SEZNAM OBRÁZKŮ ............................................................................................................. 73

ÚVOD Práce se ve své podstatné části zaměřuje na popis systému splátkového prodeje na internetových obchodech a historii jeho vývoje. Tato historie začíná v roce 2003 a v současnosti tak slaví 10 let, coţ se můţe zdát málo, ve světě jednoho z nejrychleji se rozvíjejících trhů se ale jedná o relativně dlouhé období. Ve všeobecnosti se dá říct, ţe předmětem práce je technologické řešení obchodních poţadavků vzešlých z dynamického rozvoje nového trhu, který je na druhé straně stimulován rozvojem technologií. Systém, který zde bude popsán, je heterogenní komplex aplikací, které byly postupně vyvinuté podle obchodních poţadavků a rostoucích technologických moţností. Jednotícím prvkem systému jsou webové technologie, které v období, které se váţe k vývoji popisovaného systému, zaznamenaly obrovský rozvoj a růst významu. Vývoj tohoto typu aplikací byl zpočátku neřízený, neexistovaly pro něj ani vhodné technologie ani metodiky, nebylo výjimkou, ţe celou aplikaci, i většího rozsahu, realizoval jeden člověk. Postupně se ale i v tomto segmentu začaly zavádět vývojové metodiky, návrhové vzory, frameworky. Výsledkem mohou být systémy, které se skládají ze starších a novějších aplikací a tvoří tak technologicky pestrou směs. Případová studie jednoho z takových systémů je příleţitostí, jak pochopit jejich vznik, zmapovat jejich historii a poskytnout podklady pro další moţný vývoj. Cílem mé práce je: -

Popsat obchodní poţadavky na vznik nového informačního systému jako reflexi na vznik nového trhu, který byl umoţněn rozvojem informačních technologií.

-

Popsat tento informační systém v kontextu realizace obchodního procesu a z pohledu technologických řešení.

-

Zmapovat určitý historický úsek rozvoje webových technologií na příkladu vývoje aplikačních částí popisovaného systému. Identifikovat tendence tohoto rozvoje.

-

Vyhodnotit obchodní a technologické přínosy.

1 ZVOLENÉ METODY ZPRACOVÁNÍ Při zpracování mé diplomové práce jsem zvolil metodu případové studie, protoţe se jedná o popis jednoho případu z praxe, tj. vývoje konkrétního informačního systému. Existuje velké mnoţství vymezení termínu případová studie. I kdyţ se většinou se pouţívá pro výzkumnou metodu v oboru medicíny, ekonomie, managementu, psychologie, sociologie, politologie, antropologie, pedagogice, sociální práci, kriminologii či právu, je stále častější jeho pouţití i pro popis technologických řešení, projektů nebo systémů. Pro vymezení této případové studie jsem vybral následující charakteristiku: Případové studie detailně popisují nebo rozebírají jeden nebo několik málo případů z praxe. Jedná se o zkoumání předem zvoleného jevu, v rámci jeho reálného kontextu. Případová studie má primárně deskriptivní cíl: usiluje o zachycení sloţitosti případu, jeho komplexnosti, popisuje vztahy v jejich celistvosti. Můţe však být i explanační: odhalit skryté souvislosti a vysvětlit příčiny konkrétních jevů. Podstatou případové studie je předpoklad, ţe důkladným prozkoumáním jednoho případu lépe porozumíme jiným podobným případům.[3] Případ vývoje informačního systému, tak jak je popsán v této práci, zachycuje tento projekt z pohledu obchodního i technologického a sleduje i jeho historický aspekt. Snaţí se ale rovněţ o identifikaci obecných trendů ve vývoji informačních systémů.

2 HISTORICKÉ OKOLNOSTI, OBCHODNÍ VÝCHODISKA 2.1 Splátkový prodej Začátkem nového tisíciletí jsme mohli v České republice sledovat boom tzv. nákupu na splátky, který začal růst jiţ v polovině 90. let. Jedná se o finanční spotřebitelský úvěrový produkt, který umoţňuje pořízení zboţí na úvěr přímo na prodejnách. Je to úvěr na relativně niţší částky, jejichţ předmětem je spotřební zboţí, např. vybavení domácnosti, hobby, oblečení, atd. Podle tiskové zprávy společnosti Expert Elektro Češi nejčastěji nakupují na splátky, elektroniku. Z celkového objemu takto prodaného zboţí tvoří elektronika více neţ 50 %. Z elektronického segmentu dominuje bílá technika. Nejčastěji je hodnota nákupu na splátky kolem 11 tisíc Kč1.

2.1.1 Historie Od začátku byla lídrem tohoto nového trhu nebankovní finanční společnost Multiservis patřící pod mezinárodní finanční skupinu GE Capital, později GE Money. Záhy se k ní přidali další 2 významné nebankovní subjekty a to v roce 1996 společnost Cetelem a v roce 1997 společnost Homecredit. V průběhu druhé poloviny první dekády nového milénia se na tomto trhu etablovaly také další společnosti, například Essox nebo Cofidis. Trh se spotřebními úvěry na splátky rostl meziročně o desítky procent aţ do roku 2008, kdy jeho růst zastavila finanční krize.

2.1.2 Postup nákupu na splátky v prodejně Klient si vybere zboţí, a rozhodne se, ţe ho koupí na splátky. Kontaktuje pak pracovníka prodejny nebo zástupce úvěrové společnosti, který vytvoří v počítačové aplikaci simulaci úvěru a zájemci o úvěr sdělí parametry úvěru, zejména to, jaká bude měsíční splátka, celková výše splatné částky, roční úroková míra a RPSN2. V případě, ţe se zájemce rozhodne parametry úvěru akceptovat, přistoupí na obchodní podmínky a dá souhlas se zpracováním osobních údajů, vyplní poté s pracovníkem prodejny formulář ţádosti. Součástí formuláře je, 1 2

http://www.feedit.cz/wordpress/2012/12/06/cesi-se-neboji-nakupovat-elektroniku-na-splatky-roste-i-oblibadalsich-forem-financovani/ RPSN (roční průměrná sazba nákladů) je údaj, který musí poskytovatel spotřebitelského úvěru uvádět u nabídky úvěru. Měl by umoţnit lépe posoudit výhodnost úvěru neţ úroková sazba protoţe započítává také náklady spojené s časovým průběhem splácení, správou účtu, atd.

kromě údajů nasimulovaného úvěru, také osobní dotazník, který obsahuje všechny potřebné údaje potřebné pro posouzení ţádosti. Tato data jsou odeslána do informačního systému úvěrové společnosti, který je vyhodnotí a rozhodne, zdali je moţné ţádost o úvěr přímo schválit, nebo je nutné expertní posouzení úvěrovými pracovníky. Ti pak rozhodnou o schválení nebo zamítnutí ţádosti. V případě, ţe je ţádost schválena a ţe zájemce dodal poţadovanou osobní dokumentaci (můţe se lišit v závislosti od společnosti nebo od typu a výšky úvěru), můţe podepsat návrh úvěrové smlouvy, odnést si zboţí domů a začít jej od určené doby splácet. Prodejci je následně zboţí úvěrovou společností profinancováno.

2.1.3 Typy úvěrů na splátky Ze začátku se jednalo hlavně o úvěry typu 1/10 (nebo 10 x 10), kdy klient zaplatil při pořízení zboţí jednu desetinu z ceny zboţí pak 10 stejných měsíčních splátek po 10% ceny zboţí. Postupem času se z obchodních a marketingových důvodů začalo portfolio úvěrových produktů pro splátkový prodej rozrůstat a to například o úvěry bez platby na prodejně, úvěry s odkladem, úvěry s moţností předčasného splacení bez navýšení, úvěry na specifické účely, nebo promoční úvěry úplně zdarma, tj. bez navýšení.

2.2 Internetové obchody Jako internetové obchody označujeme počítačové systémy, jejichţ součástí je webová aplikace umoţňující zákazníkům vybrat si zboţí z online katalogu, vytvořit jeho objednávku a zaplatit jej, resp. zvolit si způsob platby. Jedná se o podmnoţinu odvětví označovaného jako e-commerce nebo e-business, elektronické obchodování. Podle orientace internetového obchodu na obchodní partnery3, nebo koncové klienty, mluvíme o zaměření B2B (business to business) nebo B2C (business to client).

2.2.1 Historie Rozvoj telekomunikačních technologií zpřístupnil internet běţným uţivatelům a nastartoval tak raketový růst významu tohoto nového média. V ČR rostl počet uţivatelů internetu do roku 2007 tempem desítek procent ročně. Tento trend názorně ukazuje obrázek č. 1.

3

Obchodní partner je smluvní prodejce společnosti, který nabízí a prodává její úvěrové produkty.

Obrázek č. 1: Vývoj uţivatelů internetu od roku 2001 (údaje v %)

Zdroj: Factum Invenio, červenec 2007

Brzy začal být zřejmý obrovský komerční potenciál internetu, zvláště jeho nejvíc se rozvíjející technologie – webu. Web začal být ke komerčním účelům pouţíván nejdříve ve formě firemních prezentací, katalogů a reklamy. První internetové obchody se objevily v roce 1994. Jedním z nich byl také Amazon.com, který vznikl ve Spojených státech jako internetové knihkupectví. Rychle se ale rozšířil a začal prodávat spoustu dalších druhů zboţí. Momentálně je největším internetovým obchodem na světě4. Internetové obchodování zaţilo celosvětový boom na přelomu tisíciletí, v České republice o pár let později. V současnosti má jiţ většina obyvatel nějakou zkušenost s nákupem na internetu (viz. následující tabulka).

Obrázek č. 2: Počet obyvatel ČR se zkušeností nákupu na internetu (v tis.)

Zdroj: Asociace pro elektronickou komerci 2012, www.apek.cz

4

http://en.wikipedia.org/wiki/Amazon.com

Prvním skutečně velkým internetovým obchodem na českém trhu se stal server www.bilezbozi.cz, který začal s prodejem tzv. bílého elektra, tj. hlavně velkých kuchyňských spotřebičů. Později svůj sortiment rozšířil a stal se internetovou nákupní galerií Internet Mall. V prvním čtvrtletí roku 2003 činily trţby obchodů společnosti Internet Mall, s.r.o. 49.98 mil. Kč s DPH, coţ znamenalo meziroční nárůst o přibliţně 350 %5. Souběţně začali svojí činnost další

internetové

obchody

s různorodým

sortimentem,

například

www.kasa.cz,

www.123shop.cz, www.obchodni-dum.cz. Jako další významný hráč na trhu se objevil online obchod s počítačovou technikou Alzasoft.cz, který se po rozšíření sortimentu a dramatickém nárůstu mnoţství a kvality poskytovaných sluţeb stal jiţ pod názvem Alza.cz největším českým eshopem. Procento prodeje spotřebního zboţí přes internetové obchody nezadrţitelně stoupalo, a na to zareagovali i některé tradiční kamenné prodejny spuštěním svého internetového obchodu, například v roce 2005 jeden z největších tuzemských maloobchodních prodejců elektroniky Datart. Problematikou internetových obchodů v ČR se zabývá Asociace pro elektronickou komerci (APEK), která se soustřeďuje na tuto činnost: certifikace (APEK Certifikovaný obchod a APEK Certifikát kvality), analýzy a studie zaměřené na e-komerci, workshopy, semináře, vzdělávání pro členy Asociace, reprezentování členů asociace vůči třetím stranám, zejména veřejným institucím, médiím, vytváření a podpora etických principů podnikání, právní sluţby.6 V roce 2012 bylo v České republice kolem 21000 internetových obchodů a jimi vytvořený obrat za předchozí rok představoval 37 miliard Kč7.

5

http://www.mall.cz/tiskova-zprava-03-04-18/ http://www.socr.cz/assets/zpravodajstvi/tiskove-zpravy/platebni-metody-na-ceskem-internetu-2012-final.pdf 7 http://byznys.ihned.cz/c1-54991650-cesko-je-e-shopovou-velmoci-internetove-obchody-vygeneruji-37-miliardobratu 6

Obrázek č. 3: Obrat internetových obchodů (v miliardách Kč)

Zdroj: Asociace pro elektronickou komerci 2012, www.apek.cz

2.2.2 Platební systémy v internetových obchodech Důleţitým prvkem nakupování v internetových obchodech je moţnost výběru způsobu zaplacení zboţí. I prvotní růst internetových obchodů, zejména v Americe, byl do značné míry podpořen moţností platit po internetu kartou či s vyuţitím mikroplatebních kanálů, např. PayPal. Tyto platební metody jsou doteď celosvětově nejoblíbenější. Situace v ČR je však poněkud odlišná. I po více neţ 15 letech je hlavní platební metodou platba na dobírku, po ní následuje převod na účet a aţ na třetím místě je platba platební kartou, i kdyţ v poslední době tato moţnost zaznamenává výrazný nárůst. Podle studie Asociace pro elektronickou komerci (APEK) je sice platební metoda prostřednictvím platební karty vnímána jako jedna z nejkomfortnějších, naproti tomu obava z její zneuţití je stále obrovskou bariérou, která brání její většímu rozšíření. Přehled platebních metod na českém internetu: Na dobírku. Bankovním převodem. Na pobočce při odběru zboţí. Platební kartou přes internet. Platební systémy – tzv. „peněţenky“ – např. PayPal, PaySec. Platební brány bank – mBank, eKonto, Platba24 atd. SMS.

Na splátky.8

2.3 Obchodní východiska V roce 2003 jiţ bylo zřejmé, ţe nový trh internetových obchodů zaznamenává výrazný růst a je v něm obrovský potenciál. Jelikoţ největším internetovým obchodem té doby bylo bilezbozi.cz a v oblasti také pořád rostoucího trhu se spotřebitelskými úvěry na splátky byla jedním z hlavních předmětů financování téţ bílá elektronika, je přirozené, ţe vznikl oboustranný zájem o obchodní spolupráci. Společnosti zabývající se splátkovým prodejem Cetelem i GE Capital Multiservis jiţ v té době měli na trhu platební nástroj pro internetové obchody a to vlastní platební brány pro úvěrovou kartu Aura od Cetelemu, resp. OK kartu od Multiservisu. Nicméně jak vyplývá z předchozí charakteristiky českého spotřebitele, není velký zájem o tuto platební metodu ani v současnosti, natoţ v roce 2003. Českou internetovou platební metodou té doby byla dobírka, tj. zaplacení za zboţí aţ při jeho doručení a pro obchodníky z obou zúčastněných stran bylo toto spotřebitelské chování inspirací pro vytvoření nové platební metody. Bylo nutné vymyslet, jak sjednat pro klienta úvěr na dálku. Do té doby bylo podání ţádosti o úvěr sjednáno vţdy prostřednictvím vyškoleného pracovníka a specializované aplikace. Pro internetové obchody bylo potřebné vyvinout proces a systém, které propojí objednávku na internetovém obchodě s ţádostí o úvěr na splátky včetně simulace úvěru a bude klientům srozumitelná.

2.3.1 Představení společností participujících na vývoji Vývoj platební metody pro splátky na internetových obchodech začala ve spolupráci se společností Internet Mall, a.s. na podzim 2003 realizovat společnost Cetelem ČR, a.s. Vývoj systému na straně splátkové společnosti, který je předmětem této práce, byl realizován částečně interně a částečně oustsourceován společností Lundegaard.

2.3.1.1 Cetelem Společnost Cetelem ČR, a.s. patří mezi největší a nejvýznamnější nebankovní poskytovatele úvěrových produktů a sluţeb v České republice. Prostřednictvím svých poboček a sítě obchodních partnerů nabízí klientům: Klasické spotřebitelské úvěry v prodejnách obchodních partnerů. Účelové a neúčelové osobní půjčky. 8

http://www.socr.cz/assets/zpravodajstvi/tiskove-zpravy/platebni-metody-na-ceskem-internetu-2012-final.pdf

Kreditní karty. Produkty určené k financování motorových vozidel. Různé typy pojištění. Cetelem ČR, a.s. je dceřinou společností francouzské banky BNP Paribas Personal Finance, která poskytuje spotřebitelské úvěry jiţ od roku 1953 a postupně rozšířila pole svého působení do více neţ třech desítek zemí světa na čtyřech kontinentech. Společnost byla zaloţena 26. října 1996. Obchodní činnost zahájila v červnu 1997. Klíčovými partnery se staly společnosti IKEA, EXPERT a DATART. V roce 1998 rozšířila svou produktovou nabídku o revolvingové úvěry a v říjnu vydal první úvěrovou kartu AURA. V Čechách i na Moravě se dále rozrůstala síť obchodních partnerů, k nejvýznamnějším patřily společnosti Carrefour, Baumarkt, Europe technik, Tesco, K+B Expert aj. V roce 1999 začala společnost vydávat první kobrandované karty (karty vydané ve spolupráci s obchodním partnerem a nesoucí jeho logo) a v roce 2000 pak první privativní karty (karty pouţitelné pouze v řetězci obchodního partnera). V roce 2000 začala společnost nabízet další produkt – osobní půjčky, určené k financování náročnějších investic a nákupů. V roce 2001 se společnost jako první nebankovní společnost v České republice stala členem asociace MasterCard International. První karety MasterCard Electronic byly vydány v roce 2003. V roce 2004 vstoupila společnost na automobilový trh. V současnosti patří společnost Cetelem mezi nejstabilnější společnosti na českém trhu, coţ dokládá ratingové ocenění ČEKIA Stability Award „A“ české kapitálové informační agentury, kterou získal v roce 2010. Zároveň je jiţ několik let v pozici leadera na trhu nebankovních spotřebitelských úvěrů co do objemu poskytnutých úvěrů . V roce 2011 získala společnost od České národní banky licenci platební instituce, jako potvrzení toho, ţe splňuje přísné regulatorní nároky obdobné poţadavkům kladeným na banky.

Cetelem ČR a.s. je členem těchto profesních a zájmových sdruţení a asociací: Sdruţení právnických osob SOLUS. Česká leasingová a finanční asociace (ČLFA).

Sdruţení pro bankovní karty (SBK). MasterCard International. Asociace pro elektronickou komerci (APEK)9.

2.3.1.2 Internet Mall Společnost Internet Mall, a.s. (dříve bilezbozi.cz, s.r.o.) byla zaloţena v roce 2000. Ideou bylo změnit model nakupování elektroniky na internetu z tzv. ”katalogového prodeje“ na plnohodnotný nákupní proces, s kompletními informacemi a kompetentním zákaznickým servisem. Svoji činnost jako internetový obchod začala společnost provozovat na doméně www.bilezbozi.cz. V roce 2002 začala společnost realizovat vizi expertní nákupní galerie a kromě prodeje bílého zboţí začala provozovat nové obchody. V letech 2005 aţ 2007 expandovala na zahraniční trhy, tj. na Slovensko, do Maďarska, Polska a Německa. V roce 2008 vznikla holdingová společnost Netretail Holding, B.V., která zastřešuje a řídí všechny národní pobočky. Důvodem vzniku holdingové společnosti v Nizozemí je vstup investorů, mj. americké společnosti Intel. V roce 2010 došlo k úplnému sloučení dosavadních obchodů pod MALL.CZ. V současnosti je společnost druhým největším internetovým obchodem v ČR, její obrat v roce 2011 byl podle průzkumu společnosti Shoptet.cz 4 miliardy korun. MALL.CZ je řádným členem Asociace pro elektronickou komerci (APEK), nejvyšší tuzemské

autority

v oblasti

elektronického

obchodování.

Je

drţitelem

certifikátu

Bezpečný nákup a rovněţ prošel úspěšně testováním pro certifikát II. stupně APEK10.

2.3.1.3 Lundegaard Společnost byla zaloţena v roce 1998. Specializuje se na: Rozsáhlé weby pro střední a větší firmy a instituce. Weby pro developerské projekty. Samoobsluţné portály a klientské zóny. 9

http://www.cetelem.cz http://www.mall.cz

10

Rezervační a dokumentové systémy. Intranety a extranety pro sdílení informací a spolupráci. Postupně si vybudovala široké portfólio klientů mezi které patří např. Praţská energetika, Zentiva, Barrandov Studio, 3M, Pfizer, ALD Automotive, ORCO Property Group. Spolupráci se společností Cetelem navázala v roce 2000. Společnost je členem Asociace pro elektronickou komerci APEK a zakládajícím členem Asociace poskytovatelů internetových řešení – Asociace.BIZ11.

2.3.2 Základní poţadavky na řešení Z obchodní analýzy mezi zástupci splátkové společnosti a internetového obchodu vznikli tyto základní poţadavky: Výpočet úvěru umístěný přímo na stránkách internetového obchodu, protoţe obchodní poţadavek byl, aby si klient jiţ v čase výběru platební metody mohl úvěr nasimulovat a podle toho se dál rozhodnout, kterou platební metodu si vybere. Poskytnout klientovi funkcionalitu výpočtu úvěru, která byla běţná pro pořizování úvěru v kamenném obchodě: o Nabídnout klientovi výběr z více typů úvěru, který je moţné nadefinovat pro kaţdého partnera zvlášť, který se v čase mění a je spravován pracovníky obchodního oddělení splátkové společnosti po domluvě s obchodním partnerem. o Pro jednotlivé typy úvěru poskytnout základní strukturovaný popis, podle kterého se klient můţe zorientovat. o Poskytnout klientovi výběr z více typů pojištění schopnosti splácet, jejichţ definice se rovněţ můţe měnit v čase. o Zobrazit klientovi veškeré zákonem i obchodními poţadavky definované parametry úvěru. o V případě, ţe výpočet neproběhl správně, zobrazit klientovi důvody, které by jej nasměrovali k správnému zadání vstupních parametrů.

11

http://www.lundegaard.cz

Zajištění konzistence objednávky zboţí v internetovém obchodě a následné ţádosti o úvěr. Ţádost o úvěr musela obsahovat všechna data potřebná pro posouzení ţádosti. Nutnost validování údajů ţádosti o úvěr, to znamená, ţe formulář ţádosti musel obsahovat formální a logické kontroly pro odeslání do posuzovacího systému úvěrové společnosti. Srozumitelnost a ergonomičnost formuláře pro klienta, tj. logické seřazení vstupních polí a uspořádání do oddílů, nápověda pro kaţdou poloţku a validace zadaných údajů při přechodu na následující poloţku. Souhlas klienta se zpracováním osobních údajů. Online výsledek rozhodnutí o ţádosti, tj. okamţitě po odeslání formuláře ţádosti. O výsledku posouzení ţádosti musel být okamţitě informován klient i prodejce. Nástroje pro klienta i pro prodejce, pomocí kterého mohli dále sledovat stav ţádosti v případě jejího dalšího posuzovaní, pro získání informací o dalším postupu pro dokončení procesu pořízení úvěru v případě jeho schválení a pro obchodní informace a podmínky pro poskytnutí úvěrového produktu. Podpora procesu podepsání smluvní dokumentace.

2.3.3 Business proces Ze základních poţadavků vyplynul tento business proces: 1. Zákazník zvolí po vyplnění objednávky zboţí na internetovém obchodě jako platební metodu nákup zboţí na úvěr Cetelem (dále úvěrová společnost). Pro pouţití této metody nemusí mít zákazník ţádný předchozí kontakt s úvěrovou společností, nebo vyuţívat některý z jejích produktů. 2. Simulace úvěru na stránkách internetového obchodu.: i.

Zákazníkovi je zobrazen základní formulář pro upřesnění typu úvěru a jeho dalších parametrů.

ii.

Zákazník upraví parametry úvěru dle svého poţadavku a vyplněný formulář odešle k výpočtu splátek do „webové kalkulačky“. Obratem je mu zobrazena výše splátky, cena úvěru a RPSN.

iii.

Pokud nabízený úvěr zákazníkovi vyhovuje, je přesměrován na formulář na serveru úvěrové společnosti, kde jsou mu na jeho první stránce zobrazeny parametry jiţ

vypočítaného úvěru. Podle volby internetového obchodu můţe být klientovi nechána moţnost přepočítat si úvěr ještě na stránkách úvěrové společnosti. 3. Na dalších stránkách formuláře klient vyplní všechny potřebné údaje pro poskytnutí spotřebitelského úvěru a odešle ţádost ke zpracování (internetový obchod při přesměrování předá serveru úvěrové společnosti veškerá data o kalkulaci a zákazníkovi, pro zpětnou identifikaci transakce). 4. Ţádost je v reálném čase posouzena v úvěrové společnosti a zákazník je přesměrován zpět do systému prodejce, kde je informován o výsledku transakce (zákazník můţe být přesměrován na odlišné stránky v případě přijetí či zamítnutí úvěru). 5. Systém prodejce obdrţí veškeré potřebné informace o úvěru a transakci a můţe je dále zpracovat. V případě schválení úvěru můţe okamţitě započít s expedicí zboţí k zákazníkovi. 6. Ţádost o úvěr je zároveň uloţena na serveru úvěrové společnosti a prodejce můţe sledovat její stav, a po schválení ji vytisknout ve webové aplikaci Webtelem. V případě, ţe prodejce nemá k aplikaci Webtelem zatím přístup, bude mu při této příleţitosti zřízen (aplikace Webtelem je nezbytnou součástí pouţití sluţby). 7. Prodejce dopraví zboţí zákazníkovi a spolu s jeho předáním zkontroluje dopravce všechny potřebné údaje, doklady a nechá klienta podepsat vytištěnou ţádost o úvěr. 8. Klientem i prodejcem podepsanou ţádost spolu se všemi potřebnými doklady doručí prodejce do úvěrové společnosti, na základě čehoţ mu bude částka ve výši úvěru převedena na účet.

Obrázek č. 4: Business Process Model

Zdroj: vlastní, Enterprise Architect

3 ARCHITEKTURA ŘEŠENÍ Z pohledu globální architektury IS/IT patří popisovaný systém do vrstvy TPS, tj. Transaction Processing System, protoţe je specifický pro charakter podniku a zabezpečuje část základní operativy předmětu podnikatelské činnosti firmy, tj. pořizování ţádostí o úvěry.

3.1 Funkční architektura systému Obrázek č. 5: Funkční pohled reprezentovaný diagramem případů uţití

Zdroj: vlastní, vytvořeno v EA

Celý systém, který postihuje kompletní proces pořízení ţádosti o úvěr, se skládá z několika aplikací. Systém je vícevrstvý, na jeho základní úrovni stojí aplikace telematika, která má různou funkcionalitu a z hlediska pořízení ţádosti o úvěr se stará o

evidenci vloţených ţádostí, jejich vyhodnocování z hlediska o evidence klienta v externích a interních, pozitivních i negativních registrech, o interních posuzovacích metodik, úpravu ţádostí v reţimu manuálního posuzování, poskytování různých přehledů ţádostí, finální přípravu ţádosti pro její transformaci na úvěrový případ v systému klientského účetnictví, poskytování statistik. Aplikace telematika neposkytuje ţádné grafické uţivatelské rozhraní (GUI), ale pouze sadu rozhraní pro pouţití jinými aplikacemi. Webové aplikace, které jsou předmětem této práce, jsou v jistém smyslu uţivatelskými rozhraními aplikace Telematika Jsou to konkrétně aplikace: Webové sluţby pro kalkulaci úvěru. Webová aplikace pro pořizování ţádostí klientem. Webové sluţby pro poskytování stavu ţádosti a generování tiskových sestav. Webová extranetová aplikace WEBTELEM pro prodejce. Webová intranetová aplikace pro interní operátory WEBIS. Kaţdá z těchto aplikací má vlastní historii, funkcionalitu, umístění a také vlastní aplikační a softwarovou architekturu. Tato práce se podrobně věnuje jednotlivým aplikacím v kapitole Aplikační části systému.

3.2 Charakteristika webové aplikace a webových sluţeb jako architektonických prvků systému K popisu architektury systému, tvořeného vyjmenovanými webovými aplikacemi, je zde vhodné charakterizovat pojmy webová aplikace a webová sluţba.

3.2.1 Webová aplikace Webová aplikace je případem aplikace s architekturou klient-server. Tato architektura znamená, ţe uţivatel pouţívá prostřednictvím uţivatelského rozhraní program, který běţí na jeho počítači (tzv. klient), který dále komunikuje prostřednictvím síťové komunikace s

programem umístěným na jiném počítači (tzv. server12). Klient vydává poţadavky na server a ten je zpracovává a dává odpovědi. Obvykle server obsluhuje poţadavky více klientů. Tato architektura umoţňuje: rozdělení a specializaci úkolů, čím je moţné lépe rozloţit potřebu výkonu (klient nemusí být tak výkonný jako server), snadněji systém udrţovat (úpravu nebo výměnu serveru nemusí klient vůbec poznat) a rozdělit a zefektivnit vývoj, sdílení a centralizaci dat (na serveru běţí centrální databáze, kterou sdílejí všichni klienti), coţ umoţňuje optimalizování výkonu, jednodušší správu dat a řízení přístupu k nim, lepší zabezpečení systému, protoţe je snadnější a levnější zabezpečit jeden počítač (server) a přístupy k němu, neţ všechny počítače v systému. Typickými představiteli architektury klient-server byly v minulosti podnikové aplikace, které pouţívali tzv. tlustého klienta, na straně kterého byla implementovaná hlavní část aplikační logiky a na straně serveru byla často jenom databáze. Webová aplikace je naproti tomu aplikace klient-server poskytovaná z webového serveru klientovi, kterým je webový prohlíţeč. Tento klient patří do kategorie tzv. tenkých klientů, protoţe umoţňuje pouze prohlíţet výsledky generované serverem a neobsahuje téměř ţádnou aplikační logiku13. Aplikace se skládá z dynamických webových stránek generovaných webovým serverem za pouţití webového programovacího jazyka ve standardizovaném formátu HTML, takţe je můţe zobrazit jakýkoliv webový prohlíţeč. Samostatně je sice kaţdá stránka statickým dokumentem, ale propojení série těchto stránek pomocí hyperlinků a různých formulářových prvků současně moţností udrţení kontextu a zachování stavu, umoţňuje ve výsledku chování aplikace. Výhody tohoto přístupu jsou zřejmé: minimální náklady na distribuci, údrţbu a také značná nezávislost na platformě. Mezi nevýhody patří hlavně omezenost prostředků jazyka HTML, ale různé technologie se snaţí tento problém minimalizovat. Standardní součástí webové aplikace je také relační databáze, takţe je moţné mluvit také o třívrstvé architektuře: 12

Pod pojmem server můţe být označen samotný program, nebo také počítač, na kterém program běţí. Je moţné implementovat část aplikační logiky pomocí klientských skriptovacích technologií jako JavaScript, nebo rozšíření jako Adobe Flash i do webového prohlíţeče. 13

Obrázek č. 6: Základní schéma třívrstvé architektury webové aplikace

Zdroj: http://interval.cz/clanky/jak-na-ms-sql-pripojovani-k-serveru/

3.2.2 Webové sluţby Pod pojmem webové sluţby se obecně rozumí způsob komunikace počítačů, nebo obecně elektronických zařízení, po internetu. Je to sdílení funkcionality, která je vystavena na síti a je kdykoliv k dispozici. Komunikace mezi přístroji probíhá ve strojově čitelném jazyce a je přenášena pouţitím HTTP protokolu. Pro webové sluţby se pouţívají hlavně 2 technologie – WSDL/SOAP a REST: WSDL (Web Services Description Language) je jazyk, zaloţený na XML, který popisuje funkcionalitu webové sluţby. Popisuje, jak můţe být webová sluţba volaná, jaké parametry očekává a jaké datové struktury vrací. SOAP (Simple Object Access Protocol) je protokolem pro výměnu zpráv mezi webovou sluţbou a zařízením, které ji pouţívá. Je rovněţ zaloţený na XML. Je dost sloţitý a příliš podrobný, coţ klade vysoké nároky na kapacitu síťového přenosu a na zpracování. REST (Representational State Transfer) – je architektura rozhraní, navrţená pro distribuované prostředí. Jejím autorem je Roy Fielding. REST definuje takové principy síťové architektury, které popisují, definici a adresování zdrojů. V jejím striktním pojetí se označuje jako RESTful. Pojem REST můţe ale také označovat jednoduché XML a HTTP rozhraní, které se plně neřídí principy, které navrhl Roy Fielding.

3.3 Umístění aplikací v síťové infrastruktuře. Pro znázornění architektury systému, tvořeného webovými aplikacemi, jsem se rozhodl pouţít diagram sítě vytvořený pomocí nástroje Microsoft Visio. Znázorňuje umístění fyzických serverů a na nich běţících aplikací. Obrázek č. 7: Síťová architektura systému

Zdroj: vlastní, Microsoft Visio

4 POUŢITÉ TECHNOLOGIE Jak jiţ bylo zmíněno, vývoj nové platební metody probíhal na bázi obchodní spolupráce dvou partnerských stran, tj. Cetelem ČR a Internet Mall, nicméně tato práce se omezuje pouze na vývoj z pohledu úvěrové společnosti. Práce se také soustřeďuje pouze na vývoj specifický pro toto řešení, tj. na pořízení ţádosti o úvěr prostřednictvím webových aplikací. Abstrahuje tak od popisu zpracování ţádostí v posuzovacím systému a od dalších etap ţivotního cyklu úvěrového případu vzniklého z pořízené ţádosti. Tato kapitola se tedy zabývá softwarovými technologiemi potřebnými pro běh webových aplikací, které tvoří popisovaný systém a také technologickými prostředky pouţitými pro vývoj jeho aplikačních částí, tedy programovacími jazyky a na nich postavenými frameworky. Pro lepší představu zvolíme následující kategorizaci: Technologie pro běh webových aplikací: Operační systém. Webový server. Aplikační serverová vrstva. Databáze. Technologie pro programování webových aplikací: Serverové jazyky a frameworky. Klientské jazyky a frameworky. Jednoznačné vymezení, do jaké kategorie pouţitá technologie patří, je v mnoha případech obtíţné, např. často je technologie potřebná pro běh aplikace spojena s konkrétním programovacím jazykem. V takových případech bude na tuto nejednoznačnost v detailním popisu upozorněno. Pouţité technologie se v čase měnily, přibývaly a upgradovaly. I popis tohoto vývoje je součástí této kapitoly.

4.1 Technologie pro běh webových aplikací Popisované technologické kategorie tvoří základní rámec pro existenci webových aplikací, v tomto sloţení je například distribuován populární softwarový balíček LAMP14.

4.1.1 Operační systém Operační systém je základní software, který zpřístupňuje funkcionalitu pro ovládání počítače. Je to základní platforma pro běh jakéhokoliv počítačového programu a proto se práce z hlediska jejího vymezení nezabývá na tomto místě jeho detailním popisem, ale je pouze okrajově zmíněn.

4.1.1.1 Sun Solaris Všechny serverové části systému pro splátkový prodej běţí na OS Solaris, i kdyţ jsou rozmístěné na více serverech. Solaris je operační systém typu Unix. Byl původně vyvinut společností Sun Microsystems, která jím v roce 1993 nahradila dřívější operační systém SunOS. V lednu roku 2010 koupila firmu Sun společnost Oracle a OS Sun Solaris se přejmenoval na Oracle Solaris. Solaris je známý pro jeho škálovatelnost, a to zejména na procesorech SPARC, a pro zavedení nových inovativních funkcí, jako DTrace, ZFS a TimeSlider. Solaris podporuje pracovní stanice a servery od společnosti Sun/Oracle a také dalších výrobců, které jsou postavené na procesorech SPARC a x86. Solaris splňuje jednotnou specifikaci UNIX-ových OS (Single Unix Specification). Solaris byl historicky vyvinut jako proprietární software, v červnu 2005 ale Sun Microsystems vydal většinu zdrojových kódů pod CDDL licenci, a zaloţil OpenSolaris open source projekt15. V čase začátku vývoje systému pro splátkový prodej na internetových obchodech běţely serverové aplikace tohoto systému na OS Sun Solaris ve verzi 8 (SunOS 5.8). V roce 2007 proběhl upgrade na verzi 10.

4.1.2 Webový server Webový server je program, jehoţ účelem je obsluhovat poţadavky klientů, většinou webových prohlíţečů, co znamená odeslat jim poţadovaný obsah, zpravidla webovou stránku.

14

LAMP je sada aplikací distribuovaných pod open source licencí. Její název je zkratka, která je sloţena z prvních písmen aplikací Linux – operační systém, Apache – webový server, MySQL – databázový systém, PHP, Perl nebo Python – programovací jazyky 15 http://cs.wikipedia.org/wiki/Solaris_%28opera%C4%8Dn%C3%AD_syst%C3%A9m%29

Komunikace mezi klientem a webovým serverem probíhá pomocí protokolu HTTP (HyperText Transfer Protocol). Počítač, na kterém webový server běţí, můţe být připojen do Internetu, kde pak slouţí jako součást sítě WWW (World Wide Web). Můţe být ale také jenom součástí lokální sítě (intranet), nebo slouţit specifickým účelům (webové rozhraní pro správu routeru). Samotný webový server slouţí na poskytování pouze statického obsahu, tj. HTML stránek, obrázků a dalších souborů. Většina webových sevrerů ale poskytuje také rozhraní pro připojení dalších technologií, které umoţňují programování a tedy poskytování dynamického obsahu.

4.1.2.1 iPlanet Web Server iPlanet byla značka softwarové produktové řady vzešlé z obchodní spolupráce mezi společnostmi Sun Microsystems a Netscape Communications Corporation, známé jako Sun/Netscape Aliance. Značka iPlanet byla jiţ předtím ve vlastnictví společnosti Sun po akvizici společnosti i-Planet, Inc v roce 1998. Aliance Sun a Netscape skončila v roce 2002 a vývoj převzala firma Sun. Po převzetí společností Oracle jsou některé produkty z produktové řady iPlanet prodávané pod značkou Oracle iPlanet, např. Oracle iPlanet Web Server. Webový server iPlanet byl pouţíván od začátku fungování popisovaného systému.

4.1.2.2 Apache HTTP Server Apache HTTP Server je od roku 1996 nejrozšířenější webový server na světě, aktuálně s více neţ 50 % podílem na trhu16. Jeho historie sahá k projektu NCSA HTTPd, coţ byl web server vyvíjený Robem McCoolem v National Center for Supercomputing Aplications (NCSA) na Illinoiské univerzitě od roku 1993. Po jeho odchodu z NCSA v roce 1994 projekt začal stagnovat. Mnoho webmasterů, kteří server pouţívali si jej upravovali buď kvůli potřebným rozšířením, nebo kv ůli odstranění chyb. Někteří z nich se spojili, aby postupovali společně při vývoji a distribuci těchto svých úprav. Tito lidé vytvořili v roce 1995 Apache Group, která v témţe roce vydala první Apache HTTP Server.

16

http://news.netcraft.com/archives/category/web-server-survey/

V roce 1999 byla členy Apache Group zaloţena Apache Software Foundation, jako nadace na organizační, právní a finanční podporu vývoje Apache HTTP Serveru. Server je šířen pod Open Source licencí17 a má implementaci pro většinu pouţívaných operačních systémů18. Apache HTTP Server podporuje kromě základní funkcionality webserveru, tj. komunikace HTTP protokolem a načtení a poslání HTML souboru, velké mnoţství rozšiřujících funkcí. Všechny tyto funkce jsou k dispozici jako moduly. Některé se přilinkují k webserveru při kompilaci,

jiné

mohou

být

kompilované

samostatně

a

být

volané

dynamicky.

Nejpouţívanějšími rozšiřujícími funkcemi jsou například: Omezení přístupu pomocí různých autentizačních mechanismů, například pomocí jména a hesla, NTLM autentizace, omezení přístupu na IP adresy. Automatické přesměrování poţadavků URL (Alias). Podsouvání obsahu pomocí přepisování URI adres (Rewrite). Podpora některých programovacích jazyků, např. Python, Perl, PHP. Podpora SSL (Secure Sockets Layer)19. Komprese poskytovaných dokumentů. Podpora virtuálních hostů, tj. obsluha více webových sídel jednou instancí webového serveru. Logování přístupů a chyb a nastavení formátu logů. Web server Apache prošel od svého vzniku mnoha updaty, jeho aktuální verze je 2.4.4. Systém, který je předmětem této práce, přešel z iPlanet na Apache 1.3.34 v roce 2005. V roce 2008 byly webové servery upgradované na Apache ve verzi 2. Tato verze znamenala významné změny především v oblasti výkonu a správy, například: Podpora hybridního multiprocesového, multithreadového20 módu, který umoţnil významné zvýšení výkonu. Zavedení nového buildovacího systému.

17

Open source je označení pro software s otevřeným kódem ve smyslu technické a legální dostupnosti. Apache HTTP Server je distribuován pod Apache License (http://www.apache.org/licenses/). 18 http://httpd.apache.org/ABOUT_APACHE.html 19 SSL je protokol slouţící k zabezpečení síťové komunikace pomocí šifrování a autentizace komunikujících stran. Nejčastěji se pouţívá pro zabezpečení HTTP komunikace, která se pak označuje HTTPS. 20 Multithreading je moţný pouze na systémech, které podporují práci s vlákny (threads). Vlákna jsou odlehčené procesy (podprocesy), které na rozdíl od procesů sdílejí paměťový prostor společně s dalšími vlákny, které jsou spuštěné v rámci jednoho procesu. To kromě sníţených nároků na paměť sniţuje náklady na správu přepínání mezi vlákny v rámci multitaskingu.

Podpora IPv6. Nové Apache API, které odstranilo problém s řazením/prioritizací modulů u verze 1.3. Zlepšení konfigurovatelnosti pomocí zjednodušení mnoha matoucích direktiv. V současnosti pouţívají webové aplikace a sluţby systému splátkového prodeje Apache HTTP Server ve verzi 2.2.16.

4.1.3 Aplikační serverová vrstva Aplikace v této vrstvě slouţí k tomu, aby bylo moţné spouštět programy, které mají webovým stránkám umoţnit zobrazovat dynamický obsah generovaný na základě interakce s uţivatelem. To znamená, ţe tato vrstva umoţňuje vznik webové aplikace. Toto je realizované pomocí modulárního rozšíření webového serveru, jak bylo popsané v předchozí kapitole.

4.1.3.1 PHP Webový server při poţadavku na soubor s příponou php zavolá interpret jazyka PHP a předá mu soubor obsahující PHP script ke zpracování. PHP můţeme nainstalovat jako modul, CGI nebo FastCGI, ale většinou se pouţívá první moţnost, tj. instalace PHP jako modul Apache serveru. Při tomto pouţití je interpret součástí webového serveru, coţ přináší vysoký výkon a absenci potřeby konfigurace, na druhé straně to přináší jisté nevýhody v podobě bezpečnosti, stability a nemoţnosti rozloţení zátěţe. PHP se konfiguruje pomocí souboru php.ini. O samotném jazyce pojednává kapitola PHP v sekci Pouţité jazyky a frameworky.

4.1.3.2 Apache Tomcat Apache Tomcat (dříve Jakarta Tomcat) je open source webový kontejner pouţívaný podle oficiální referenční implementace pro Java Servlet a Java Server Page technologie (JSP). Tomcat umí pracovat jako samostatný webový server, ale také jako plug-in do webového serveru Apache. Samotný Apache dokáţe obslouţit poţadavky na statické stránky mnohem rychleji neţ Tomcat. Poţadavky směřující na Java aplikace směruje Apache na Tomcat. Poţadavek na HTML nebo PHP stránku je obslouţen samotným Apachem. Poţadavky na Webové sluţby ale Apache přeposílá na Tomcat. Na to se pouţívá konektor mod_jk a protokol AJP13.

4.1.4 Databáze Databáze slouţí programům, které běţí v aplikační serverové vrstvě jako úloţiště dat. Většinou se v prostředí webových aplikací pouţívají relační databáze, s kterými pracují programy prostřednictvím jazyka SQL. Některé databáze poskytují rovněţ jisté moţnosti programování, coţ můţe být přínosné zvláště pro rychlost a bezpečnost operací s daty.

4.1.4.1 Oracle Databáze Oracle (Oracle RDBMS) je hlavním produktem softwarové společnosti Oracle Corporation a je jednou z nejpouţívanějších relačních databází v podnikové sféře. Jedná se o moderní multiplatformní databázový systém s velice pokročilými moţnostmi zpracování dat, vysokým výkonem a snadnou škálovatelností. Tento systém podporuje nejen standardní relační dotazovací jazyk SQL podle normy SQL92, ale také proprietární firemní rozšíření Oracle (např. pro hierarchické dotazy), imperativní programovací jazyk PL/SQL rozšiřující moţnosti vlastního SQL (v tomto jazyce je moţné tvořit uloţené procedury, uţivatelské funkce, programové balíky a triggery), dále podporuje objektové databáze a databáze uloţené v hierarchickém modelu dat (XML databáze, jazyk XSQL). V čase začátku vývoje byla pouţita databáze Oracle ve verzi 8.1.7, postupně přešla přes verzi 9 aţ na aktuální 11g.

4.2 Pouţité programovací jazyky a frameworky Programování na webu má svoje specifika, která jsou úzce spojena se zaměřením webových aplikací, jejich architekturou a z ní vyplývajících technologických omezení. Těmito specifiky jsou zejména: Bezstavovost – kaţdý poţadavek na server je nezávislý. Aby byl zachovaný stav a kontext aplikace, je nutné, aby si server tento stav ukládal (na filesystém, nebo do paměti) a vţdy jej obnovil na základě identifikátor stavu, který mu při dalším poţadavku pošle prohlíţeč. Nízký výpočetní výkon na jednu aplikaci, který je dán moţností velkého počtu současných poţadavků. Nízká přenosová kapacita sítě, která můţe být u kaţdého uţivatele různá, ale je nutné aplikaci přizpůsobit co největšímu počtu uţivatelů Zaměření webových technologií na prezentaci obsahu, které je dané historicky.

Z toho vyplynul vývoj samostatných jazyků, které jsou určeny přímo pro programování na webu (PHP), nebo technologií, které rozšiřují moţnosti původně newebových jazyků (J2EE).

4.2.1 Serverové programovací jazyky a frameworky 4.2.1.1 PHP PHP (rekurzivní zkratka PHP: Hypertext Preprocesor) je scriptovací jazyk určený primárně pro pouţití s webovým serverem. Od svého vzniku v roce 1997 přešla tato technologie velkým rozvojem a v současnosti je nejpouţívanější serverovou technologií na světě. Obrázek č. 8: Pouţití serverových programovacích jazyků pro webové stránky

Zdroj: http://w3techs.com/technologies/overview/programming_language/all

Jako Open Source projekt má za sebou početnou vývojářskou základnu. Od verze 3 implementovalo PHP podporu pro OOP, která byla ještě více rozšířená ve verzi 4 a hlavně ve verzi 5 (Tento vývoj bude více popsán v kapitole Technologické proměny systému). Je nezávislé na platformě, skripty fungují bez větších úprav na mnoha různých operačních systémech. Podporuje mnoho knihoven pro různé účely - např. zpracování textu, grafiky, práci se soubory, přístup k většině databázových systémů (mj. MySQL, ODBC, Oracle, PostgreSQL, MSSQL), podporu celé řady internetových protokolů (HTTP, SMTP, SNMP, FTP, IMAP, POP3, LDAP…). Díky jednoduchosti pouţití a kombinaci vlastností více programovacích jazyků, čímţ nechává vývojáři částečnou svobodu v syntaxi, se stalo PHP velmi rozšířeným. Kombinace operačního

systému Linux, databázového systému MySQL a webového serveru Apache je pod zkratkou LAMP oblíbeným nástrojem pro tvorbu webových aplikací. Vývoje systému, který je předmětem této práce, začal v PHP 4, které bylo později migrované na verzi 5. Aktuální verze je 5.3.25.

4.2.1.2 Zend Framework Na platformě PHP je postavena spousta frameworků pro tvorbu webových aplikací. Nejznámější jsou Zend Framework, CakePHP, Symphony, CodeIgniter nebo v Čechách domácí Nette Framework. Obrázek č. 9: Nejpopulárnější PHP frameworky v roce 2011

Zdroj: http://www.php-developer.org/most-used-php-framework-the-popular-top-7-list-in-year-2011/

Pro vývoj jedné z aplikací – WebIS - byl pouţitý Zend Framework. Jedná se objektově orientovaný framework pro vývoj webových aplikací, který je licencovaný pod New BSD license21. Framework začal být vyvíjen v roce 2005. Hlavní sponzor projektu je společnost Zend Technologies22, která je úzce spojena s vývojem PHP23. Zend Framework je momentálně k dispozici ve verzi 2, která byla uvedena v roce 2012. Hlavní charakteristiky Zend Framework jsou: plně objektová modulární architektura, která umoţňuje pouţívat jednotlivé komponenty s co nejmenší mírou závislosti na ostatních komponentách, 21

http://framework.zend.com/license/ http://www.zend.com/en/ 23 http://www.zend.com/en/community/php/ 22

komponenty pro implementaci aplikací postavených na MVC architektuře24, podpora mnoţství databázových systémů včetně MySQL, Oracle, IBM DB2, Microsoft SQL server, jednoduše pouţitelná databázová abstrakce, formulářové komponenty s podporou HTML5, moţností filtrování a validací hodnot, autorizační a autentizační komponenty, šablonovací systém.

4.2.1.3 Java + Apache Axis Pro naprogramování webových sluţeb na bázi protokolu SOAP byl pouţitá technologie Java a Apache Axis. Java Java je objektový programovací jazyk od firmy Sun Microsystems (aktuálně jiţ Oracle), která je jedním z nejpouţívanějších jazyků. Výhody jazyka jsou hlavně jeho komplexnost, jednoduchost, robustnost a hlavně přenositelnost. Kód programu v Javě je totiţ nezávislý na platformě, protoţe není kompilovaný do strojového kódu, ale do tzv. bytekódu, který je přímo interpretován pomocí běhového prostředí Java Virutal Machine (JVM), nebo kompilován do strojového jazyku pomocí Just In Time Compilation (JIT). Implementace těchto technologií existují pro většinu známých operačních systémů. Technologie Java obsahuje několik platforem, které mají různá zaměření. Základem je platforma Java SE (Standard Edition), pro mobilní zařízení existuje platforma Java ME (Micro Edition) a pro podnikové systémy, včetně webových aplikací Java EE (Java Platform, Enterprise Edition). Moţnosti Javy dále rozšiřuje mnoţství frameworků. Apache Axis Apache Axis je framework pro vytváření SOAP komponent jako jsou klienti, servery, atd.

24

MVC je softwarová architektura, která rozděluje aplikaci na 3 základní vrstvy: Model (model), který reprezentuje datový model aplikace; View (pohled), který zajišťuje prezentaci dat, Controller (řadič), který reaguje na události a zajišťuje změny v modelu nebo pohledu.

Součásti Axis-u je: jednoduchý stand-alone server, server, který se přípají do servletových kontanerů, jako je Apache Tomcat, široká podpora pro Web Service Description Language (WSDL), nástrojová sada, která umoţňuje vytvářet Javovské třídy z WSDL, nástroj pro monitorování TCP/IP paketů.

Sluţby v Axisu běţí na aplikačním serveru Apache Tomcat.

4.2.1.4 PL/SQL Pro programování části aplikační logiky byl pouţitý jazyk PL/SQL (Procedural Language/Structured Query Language), který je součástí databáze Oracle. Proto je pro úplnost uvedený v sekci serverových programovacích jazyků. Je to procedurální nadstavba jazyka SQL. Syntax se podobá jazykům Ada a Pascal. PL/SQL podporuje proměnné, podmínky, smyčky a výjimky. Pouţívá také pole, i kdyţ poněkud nestandardním způsobem, tj. pouţívá tzv. PL/SQL collections. Implementace od verze 8 obsahují jiţ také prvky objektově orientovaného programování. Programové jednotky v PL/SQL: Anonymní bloky Funkce Procedury Balíčky

4.2.2 Klientské programovací jazyky 4.2.2.1 HTML HyperText Markup Language je značkovací jazyk pro hypertext. Je hlavním z jazyků pro vytváření stránek v systému World Wide Web, který umoţňuje publikaci dokumentů na Internetu. Je charakterizován mnoţinou značek (tzv. tagů) a jejich atributů definovaných pro danou verzi. Mezi značky se uzavírají části textu dokumentu a tím se určuje význam (sémantika) obsaţeného textu. Názvy jednotlivých značek se uzavírají mezi úhlové závorky. Část dokumentu tvořená otevírací značkou, nějakým obsahem a odpovídající ukončovací

značkou tvoří tzv. element (prvek) dokumentu. Součástí obsahu elementu mohou být další vnořené elementy. Atributy jsou doplňující informace, které upřesňují vlastnosti elementu.

4.2.2.2 XML Extensible Markup Language (tj. rozšiřitelný značkovací jazyk) je obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Je zjednodušenou podobou staršího jazyka SGML. Umoţňuje snadné vytváření konkrétních značkovacích jazyků (tzv. aplikací, např. XHTML, SOAP) pro různé účely a různé typy dat. Je zaloţen na jednoduchém textu a je zpracovatelný libovolným textovým editorem. Implicitně pouţívá Unicode, takţe je pouţitelný pro mnoho světových jazyků. XML neobsahuje předdefinované značky (tagy), je třeba definovat vlastní značky, které budeme pouţívat. Tyto značky je moţné (nepovinně) definovat v souboru DTD (Document Type Definition). Potom je moţné automaticky kontrolovat, zda vytvářený XML dokument odpovídá této definici.

4.2.2.3 JavaScript První technologií, která generovala dynamický obsah v prohlíţeči, byl JavaScript od firmy Netscape Communications. Byl pouţitý v roce 1995 prohlíţeči Netscape Navigator 2. Jedná se o scriptovací objektově orientovaný jazyk, zaloţený na standardu ECMAScript. Jeho kód se vkládá přímo do HTML dokumentu. Prohlíţeč tento kód umí rozlišit od HTML a umí ho vykonat. Navzdory názvu nemá tento jazyk téměř nic společného s jazykem Java, a je tak nazvaný z marketingových důvodů. Program v JavaScriptu se obvykle spouští aţ po staţení WWW stránky z Internetu (tzv. na straně klienta), na rozdíl od ostatních jiných interpretovaných programovacích jazyků (např. PHP a ASP), které se spouštějí na straně serveru ještě před staţením z Internetu. Z toho plynou jistá bezpečností omezení, JavaScript např. nemůţe pracovat se soubory, aby tím neohrozil soukromí uţivatele. Tak jako pro PHP nebo další programovací jazyky, vznikli ve snaze o zjednodušení vývoje postupem času i pro JavaScript různé knihovny funkcionalit a frameworky. Nejznámější a nejpouţívanější z nich je jQuery.

Obrázek č. 10: Pouţití JavasScriptových knihoven ve webových stránkách

Zdroj: http://w3techs.com/technologies/overview/javascript_library/all

4.2.2.4 CSS Kaskádové styly (Cascading Style Sheets) jsou označením pro jazyk, který popisuje způsob zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML. Syntax jazyka CSS je zaloţena na definici pravidel. Kaţdé pravidlo obsahuje selektor a blok deklarací. Kaţdý blok deklarací pak obsahuje seznam deklarací oddělených středníky. Kaţdá deklarace pak sestává z identifikátoru vlastnosti a hodnoty vlastnosti. Selektory můţou být vlastní elementy HTML dokumentu (jako například ), nebo jsou aplikované vztaţeny na elementy, které mají definovanou nějakou třídu pomocí HTML atributu class, nebo identifikátor pomocí HTML atributu id. Významnou vlastností CSS je dědičnost, to znamená, ţe elementy dědí většinu vlastnosti z nadřazených elementů, takţe není nutné definovat všechny vlastnosti u kaţdého selektoru a zároveň to pomáhá zachovávat jednotný styl.

5 APLIKAČNÍ ČÁSTI SYSTÉMU 5.1 Webové sluţby pro internetové obchody Pro poţadovanou funkcionalitu výpočtu úvěru na straně internetového obchodu, tj. jako součásti výběru platební metody, bylo od začátku zvaţováno více moţností: 1. Implementovat celou výpočtu logiku na straně internetového obchodu 2. Vytvořit aplikaci typu Java Applet nebo ActiveX, která by byla distribuována partnerovi 3. Vytvořit kalkulátor jako dynamickou HTML stránku, kterou by si partner vkládal do svých stránek 4. Vytvořit webovou sluţbu, která by partnerovi poskytovala aktuální informace pro výpočet přímo z interního systému splátkové společnosti. Zejména z důvodu v čase se měnících se parametrů výpočtu a produktů dostupných prodejci byly zamítnuté první 2 moţnosti. To by znamenalo nutnost měnit aplikace s kaţdou změnou nastavení produktu a prodejce. V druhém případě byl navíc problém se samotnými technologiemi, které nebyly plně kompatibilní a spolehlivé napříč spektrem internetových prohlíţečů. Třetí moţnost byla zamítnuta kvůli nutnosti přizpůsobovat aplikaci designu kaţdého nového partnera. Nakonec vyhrála čtvrtá moţnost, která skloubila nutnost mít aktuální data výpočtu a moţnost jejich reprezentace na stránkách internetového obchodu dle grafických představ jeho tvůrců. Sluţby byly vyvinuty společně se společností Lundegaard a uvedeny do provozu v roce 2003.

5.1.1 Základní princip sluţeb Data jsou na vstupu předávány metodou GET jako parametry poţadovaného URL.Jako výstup daného URL je vrácen XML dokument, obsahující veškeré výstupní a případně upravené vstupní parametry. Formát výstupního XML: Kořenový element <webkalkulator/> obsahuje vţdy elementy <status/> a element , který obsahuje 0 aţ N elementů . Element <status/> obsahuje buď řetězec "ok" (výpočet proběhl) nebo "error" (výpočet nemohl být proveden).

Element obsahuje 0 aţ N elementů , které v závislosti na statusu popisují buď důvod, proč nemohl být výpočet proveden (kdyţ status = error) nebo informace o provedených korekcích vstupních parametrů při výpočtu (kdyţ status = ok). Pokud výpočet proběhl, obsahuje kořenový element ještě element , do kterého jsou vloţeny elementy reprezentující výstupní parametry. Všechny sluţby jsou provozovány na zabezpečeném protokolu HTTPS na portu 443.

5.1.2 Popis jednotlivých sluţeb 5.1.2.1 Webkalkulačka Slouţí pro výpočet parametrů úvěru na základě zvoleného druhu produktu (baremu) a dalších vstupních údajů. Má tyto parametry: kodProdejce - Číslo prodejce v systému úvěrové společnosti kodBaremu - Typ produktu. Nutné doplnit podle webčíselníku (viz. kapitola Webčíselník) kodPojisteni - Typ pojištění úvěru. Nutné doplnit podle webčíselníku. cenaZbozi - Celková cena kupovaného zboţí v Kč. primaPlatba - Přímá platba prodejci v Kč, tzv. akontace. vyseUveru - Celková výše úvěru v Kč. pocetSplatek - Počet měsíčních splátek. odklad - Moţnost odkladu začátku splácení v měsících. Je závislá na typu produktu. vyseSplatky – Výše měsíční splátky v Kč. cenaUveru - Cena úvěru v Kč. RPSN – Roční procentní sazba nákladů. ursaz - Roční úroková sazba v % celkovaCastka – Celková částka v Kč, kterou klient zaplatí ve všech splátkách. Příklad úspěšného výpočtu: a) Vstup (musí být pomocí HTTP metody GET): https://www.cetelem.cz:8654/webkalkulacka.php?kodProdejce=2084911&kodBaremu=224& kodPojisteni=S0&kodMaterialu=320&cenaZbozi=10000&vyseUveru=9000&primaPlatba=10 00&pocetSplatek=24

b) Výstup: <webkalkulator> <status>ok Příma platba je 0 2084911 224 S0 10000 <primaPlatba>0 10000 <pocetSplatek>24 0 500 2000 19,75 18,16 12000

5.1.2.2 Webčíselník Na základě identifikace prodejce a druhu poţadovaného číselníku vrátí prodejci jemu dostupný seznam typů úvěrů (baremů), druhů pojištění úvěru nebo materiálů. Pouţití této sluţby je nutné pro získání aktuálních vstupních parametrů pro sluţbu webkalkulačka. Sluţba má dva vstupní parametry a to kód prodejce(kodProdejce) a typ číselníku(typ), kde typ je jeden z následujících: barem material pojisteni Příklad úspěšného dotazu: a) Vstup (metoda GET): https://www.cetelem.cz:8654/webciselnik.php?kodProdejce=2084911&typ=barem b) Výstup: <webciselnik> <moznost <moznost <moznost <moznost <moznost <moznost

hodnota="022">Barem 022 hodnota="104">10% + 10 x 10% hodnota="201">1% měsíčně hodnota="206">1 % měsíčně (10 - 30 MS) hodnota="221">Zdarma do 6 měsíců, jinak 36 měs. hodnota="224">0% + 24x5

5.1.2.3 Bareminfo Na základě identifikace prodejce/partnera je navrácen seznam typů produktů, tzv.„baremů“ a jejich popisů, které jsou prodejci dostupné pro online aktivity. Ty mohou být pouţity na stránkách internetového obchodu pro nastavení kontroly vstupů nebo pro informování klienta o nabízeném finančním produktu. Sluţba má dva vstupní parametry a to povinný kodProdejce a nepovinný kodMaterialu. Výstupní parametry jsou patrné z následujícího příkladu. Element se opakuje dle počtu dostupných baremů. Moţné elementy info v rámci jednoho elementu barem jsou: 1. moţný rozsah úvěru 2. přímá platba 3. počet splátek 4. moţnost odkladu splátek

Obrázek č. 11: Implementace webového kalkulátoru na Mall.cz

Zdroj: www.mall.cz

Obrázek č. 12: Implementace webového kalkulátoru na Alza.cz

Zdroj: www.alza.cz

4.1.3 Vývojové milníky 5.1.2.4 HTTP/XML rozhraní Prvotní sada sluţeb byla vytvořena na velice jednoduchém principu, kombinujícím HTTP metodu GET a XML. V době svého vzniku sledovala spíš obecný princip webových sluţeb, neţ konkrétní technologii nebo standard. Bylo to zejména z důvodu jednoduchosti implementace jak na straně poskytovatele sluţeb, tak na straně partnerů. S odstupem času by se dalo říct, ţe sluţby částečně pouţívaly princip REST, ovšem nikoli RESTfull. Webové sluţby byly postavené na PHP 4 s podporou DB Oracle.

5.1.2.5 CWS (Cetelem Web Services) Webové sluţby zaloţené na komunikačním protokolu XML/SOAP. Byly vyvinuty firmou Lundegaard v roce 2006 a byly odpovědí na poţadavky některých partnerů. Tyto poţadavky byly jak funkční, tak technologické:

Umoţnit pouţití standardního protokolu pro funkcionalitu původních webových sluţeb (webkalkulator, webciselnik). Moţnost zjišťování stavu ţádosti o úvěr pro interní systémy partnerů zaloţeném na čísle objednávek v systémech internetových obchodů předávaných v poloţce obj při volání aplikace Úvěr online. Sluţby byly postaveny na open source technologii Apache AXIS napsanou v jazyce Java. Pouţití sluţeb je zabezpečené pouţitím klientského certifikátu vydaného certifikační autoritou úvěrové společnosti. Pomocí něj je identifikován prodejce aţ do úrovně aplikace. Funkcionalita CWS Zjištění stavu ţádosti Zjištění stavu ţádosti na základě předání čísla objednávky, které je předáno při přechodu na online ţádost o úvěr. Jméno sluţby: Apply Metoda: getParameters Vstupní parametr: orderNumber – číslo objednávky v systému internetového obchodu Výstupní parametry: -

name - jméno klienta

-

surname - příijmeni klienta

-

vendor - číslo prodejce

-

state - stav ţádosti

-

amount - výše úvěru

-

payout - přímá platba (akontace)

-

text - textová správa

-

error - chyba

Číselníky Sluţba vrátí seznam dostupných baremů, kódů materiálu a pojištění pro prodejce. Jedná se o obdobu sluţby Webčíselník z původních webových sluţeb. Jméno sluţby: Sales Metody:

getProductList – seznam baremů getMaterialList – seznam kódů materiálu getInsuranceList – seznam kódů pojištění Popis sluţby ve WSDL: https://www.cetelem.cz:8654/cws/services/Sales?wsdl Úvěrový kalkulátor Sluţba umoţňuje výpočet úvěru na základě vstupních parametrů. Jedná se o obdobu sluţby Webkalkulačka z původních webových sluţeb. Jméno sluţby: Calculator Metoda: calculate Parametry jsou shodné s parametry sluţby Webkalkulačka.

5.1.2.6 Tiskové sluţby Později byla do CWS přidaná funkcionalita online generování smluvní tiskové dokumentace do PDF. Tato vyuţívá javovskou knihovnu iText. iText umoţňuje dynamicky vytvářet PDF dokumenty a manipulovat s nimi. Základní vlastnosti jsou: poslat PDF prohlíţeči, vytvářet dynamické dokumenty z XML souborů nebo databáze, pouţívat mnoţství interaktivních moţností PDF, pouţívat záloţky, čísla stránek, vodotisk, atd., rozdělovat a spájet stránky PDF, automatické vyplňování PDF formulářů, přidat digitální podpis do PDF.

5.2 Úvěr online 5.2.1 Funkční popis aplikace Úvěr online je webová aplikace běţící na serveru splátkové společnosti, která slouţí pro pořízení samotné ţádosti o úvěr klientem. Společně s dřív popsanými webovými sluţbami se jedná o aplikace, které byly vyvinuty jenom pro systém splátkového prodeje na internetových obchodech. Do aplikace se klient dostává přesměrováním po výběru platební metody „Na splátky“ a po simulaci úvěru na stránkách internetového obchodu. Aplikace můţe být vzhledově přizpůsobena potřebám prodejce, například pro moţnost vloţit si ji jako iframe do vlastních stránek. Aplikaci musí být předány informace pro identifikaci prodejce a informace o nasimulovaném úvěru na stránkách internetového obchodu prostřednictvím webových sluţeb, které byly popsány v předchozí kapitole. Aplikace se skládá ze 3 částí: 1. Rekapitulace simulace úvěru ze stránek prodejce s moţností nového přepočtení úvěru se zachováním parametru cena zboţí. Předané údaje z internetového obchodu musí souhlasit s interním přepočtem v aplikaci. 2. Osobní dotazník, tj. 4-stránkový formulář obsahující všechny potřebné údaje pro automatické vyhodnocení ţádosti. Součástí jsou také elektronické souhlasy klienta se zpracováním osobních údajů a s dotazováním do externích registrů. Před odesláním jsou všechna data, která klient zadal, zrekapitulována na jedné stránce s moţností návratu do formuláře. Formulář obsahuje formální i logickou validaci jednotlivých poloţek. Některé z nich jsou vázané na hodnoty vyplněné v jiných poloţkách. 3. Zpracování ţádosti, tj. odeslání ţádosti do posuzovacího systému a zobrazení rozhodnutí klientovi. Podle nastavení prodejce je klient buď přesměrován zpět na stránky internetového obchodu, kde je mu zobrazen výsledek posouzení ţádosti, nebo je výsledek zobrazen přímo v aplikaci. Pokud je ţádost schválena, je moţné, aby si přímo vytiskl návrh úvěrové smlouvy, kterou pak pošle společně s poţadovanými doklady prodejci. V rámci tohoto kroku se klientovi i prodejci odesílá mail s informací o zpracování ţádosti. Klient má v tomto emailu také odkaz zpět do aplikace, aby si mohl kdykoliv zkontrolovat stav posouzení ţádosti a eventuálně vytisknout návrh smlouvy.

Pokud ţádost není automaticky schválena, tak klientovi přijde email o vyhodnocení aţ po posouzení na úvěrovém oddělení.

5.2.2 Vývojové milníky 5.2.2.1 První verze Aplikace byla vyvinuta na PHP 4 a byla uvedena do provozu v roce 2004. Byla vyvinuta interním vývojem, ale pouţívala modulární objektový PHP systém převzatý z aplikace Webtelem. Podle poţadovaného business procesu umoţňovala po zpracování ţádosti pouze přesměrování na stránky internetového obchodu. Jednotlivé stránky osobního dotazníku byly samostatné formuláře a při přechodu mezi stránkami byl vţdy celý obsah formuláře přenášen na server a ukládán v PHP Session. Toto řešení při tehdejší rychlosti a stabilitě internetového připojení způsobovalo častý rozpad nebo expiraci session a tím ukončení procesu pořizování ţádosti. Pro validaci formulářových poloţek byl pouţitý systém, který je programovatelný pomocí jednoduchého meta jazyka, čímţ umoţňuje vyuţívat předdefinované formální kontroly a logicky je strukturovat pomocí podmínek. Na základě těchto definic jsou pak vygenerované validace vstupů na straně klienta (JavaScript) i serveru (PHP).

5.2.2.2 Nový proces V roce 2005 byla aplikace podle obchodních poţadavků rozšířena o podporu nového procesu, který by umoţnil dokončení ţádosti včetně tisku a podpisu smluvní dokumentace na straně klienta. Původní proces totiţ vyţadoval, aby měl prodejce k dispozici vlastní dopravu. Řidič, který dopravoval zboţí klientům a zajišťoval podepsání úvěrové smlouvy klientem při předání zboţí, musel být z právních důvodů zaměstnancem internetového obchodu. Tyto podmínky ale splňovalo a pořád splňuje jenom nepatrné procento internetových obchodů. Systém splátkového prodeje přes internet nemohl být proto více rozšířen. Proces pořízení ţádosti byl tedy od bodu 4 původního procesu popsaného v kapitole 1.3.3 Business proces upraven takto: 4. Ţádost je v reálném čase posouzena v úvěrové společnosti a zákazníkovi je ve webové aplikaci úvěrové společnosti zobrazena zpráva o výsledku posouzení: a. V případě, ţe je ţádost okamţitě schválena, zákazníkovi je na stránce nabídnuta moţnost tisku návrhu smlouvy. Zároveň odchází email na adresu prodejce s oznámením o schválení ţádosti a kontaktem na klienta. Klientovi

odchází také schvalovací email s linkem na stránku „stav ţádosti“, kde si klient po přihlášení můţe znovu vytisknout návrh smlouvy. b. V případě, ţe ţádost není okamţitě schválena, zůstává v systému a bude posouzena pracovníky úvěrového oddělení. Tato skutečnost je rovněţ oznámená klientovi na webové stránce a emailem, v kterém obdrţí také link na stránku „stav ţádosti“. Po posouzení úvěrovým oddělením je klientovi i prodejci automaticky odeslán email s konečným rozhodnutím. V případě schválení ţádosti si klient můţe vytisknout na stránce „stav ţádosti“ návrh smlouvy, tak jako v případě primárního schválení. 5. Po posouzení ţádosti můţe být klientovi zobrazeno tlačítko pro návrat na stránky internetového obchodu. Tato moţnost je závislá na tom, jestli při přesměrování klienta na stránky ţádosti o úvěr jsou poslány nepovinné poloţky url_back_ok, url_back_ko a obj. 6. Prodejce můţe sledovat stav ţádosti v aplikaci Webtelem. Můţe nad pořízenými ţádostmi vykonávat všechny akce, které jsou popsány v manuálu k Webtelem, stejně jakoby ţádost pořídil přes Webtelem. 7. Klient odešle podepsanou smlouvu a příslušné dokumenty podle pokynů na stránce „stav ţádosti“ prodejci. 8. Prodejce po obdrţení a zkontrolování smlouvy a přiloţených dokumentů, potvrdí ţádost ve Webtelem a dopraví zboţí zákazníkovi. 9. Klientem i prodejcem podepsanou smlovu spolu se všemi potřebnými doklady doručí prodejce do úvěrové společnosti. Na tomto základě mu bude částka ve výši úvěru převedena na účet. Aplikace musela být upravena tak, aby podporovala některé nové funkce, například rozlišení typu procesu, poskytnutí informace o stavu ţádosti a tisk smluvní dokumentace.

5.2.2.3 Druhá verze Byla vytvořena v roce 2006 a reflektovala novou verzi korporátních stránek. Přinesla několik významných vylepšení a změn: Nové verze PHP 5, které implementovalo nový objektový model. Nový design v souladu s aktuálním vzhledem korporátního webu. Přechod hlavního layoutu z tabulkového na CSS.

Změna ve vyplňování ţádosti – formulář se pomocí DHTML dál tváří jako by měl čtyři samostatné stránky, ale technologicky je to jeden formulář na jedné HTML stránce. Data se tak neodesílají na server po přechodu na kaţdou další stránku, ale aţ po vyplnění celé ţádosti. To vedlo k výraznému zvýšení rychlosti a spolehlivosti. Oproti předchozí verzi významně klesl počet nedokončených ţádostí.

5.2.2.4 Kustomizace aplikace V roce 2008 je na poţadavky partnerů umoţněna kustomizace aplikace. Jedná se o moţnost upravit aplikaci do designu webových stránek partnera (internetového obchodu), aby si ji pak mohl začlenit do svých webových stránek jako iframe. Kustomizované verze jsou ve správě obchodního oddělení, která je můţe pomocí intranetové aplikace přiřazovat konkrétním prodejcům.

5.2.2.5 Třetí verze V roce 2009 je aplikace opět designově upravena podle nové verze firemních stránek. Aplikace implementuje další rozšíření procesu podle obchodních poţadavků a to moţnost kalkulace úvěru přímo ve formuláři ţádosti. Tento poţadavek vzešel od menších internetových obchodů, pro které bylo z nejrůznějších důvodů komplikované implementovat webové sluţby pro simulaci úvěru. V rámci tohoto procesu jsou aplikaci předávány ze stránek internetového obchodu jenom základní data nutná pro pořízení ţádosti, tj. kód prodejce a cena zboţí.

5.2.2.6 Našeptávač adres V roce 2010 je vyvinuta funkcionalita našeptávač adres pro rychlejší vyplnění formulářových údajů o adresách a zároveň pro větší čistotu těchto dat pro další vyuţití. Zdrojem adresních dat je UIR-ADR: Územně identifikační registr adres, který poskytuje Ministerstvo práce a sociálních věcí ČR. Našeptávač je realizován pomocí technologie AJAX (Asynchronous JavaScript and XML), která umoţňuje komunikaci stránky se serverem bez nutnosti jejího znovunačtení. Tím dostává interaktivita webové aplikace úplně nový rozměr, protoţe se chová téměř jako klasická desktopová aplikace. Komunikace webového prohlíţeče se serverem je realizovaná pomocí JavaScriptového objektu XMLHttpRequest. I kdyţ je přímo v názvu jako formát přenášených dat definován XML, tak není povinný a často se pouţívá například formát JSON (JavaScript Object Notation) nebo přímo kusy HTML kódu.

5.2.2.7 Kontaktování klientů, kteří nedokončili ţádost o úvěr V roce 2011 byla pomocí AJAX implementovaná funkcionalita, která na začátku ţádosti uloţí kontaktní data klienta a dál sleduje, jestli byla ţádost dokončena. Počet nedokončených ţádostí byl identifikován z pohledu obchodu jako jeden z největších problémů procesu a ani postupná optimalizace formuláře tento problém nedokázala plně vyřešit. V případě, ţe ţádost nebyla dokončena, zobrazí se tato informace prodejci společně s kontaktními údaji klienta v aplikaci Webtelem a ten jej můţe pak kontaktovat a asistovat mu při dokončení ţádosti, nebo se s ním domluvit na jiné platební metodě.

5.2.2.8 Přizpůsobení formuláře pro tablety Vzhledem k nárůstu pouţívání tabletů bylo nutné upravit webový formulář aplikace tak, aby alespoň částečně vyhovovala technologickým poţadavkům, které pouţití tabletů a jim specifických prohlíţečů přineslo. Kromě úpravy layoutů a CSS se jako nejproblematičtější ukázalo pouţití proprietárně vytvořených JavaScriptů pro rozšířenou funkcionalitu formulářových prvků jako je například výše zmíněný našeptávač adres. Tyto v některých prohlíţečích způsobily dokonce nefunkčnost aplikace. Z tohoto důvodu byla v roce 2012 funkcionalita problematických JavaScriptů přepsána za pouţití JavaScriptové knihovny jQuery.

5.2.2.9 Dotahování údajů známých klientů Na základě obchodních poţadavků byla v roce 2013 uvedena do provozu funkcionalita, která umoţní usnadnění vyplnění formuláře klientům, kteří jiţ někdy byly klienty úvěrové společnosti. Aplikace na základě údajů jméno, příjmení a rodné číslo pomocí AJAX zjistí, jestli klient je v systému a nabídne mu moţnost dotaţení údajů do formuláře. Pokud si klient vybere tuto moţnost, tak je mu pomocí SMS zaslán autorizační kód na mobilní číslo, které je uvedené v systému. Ten pak klient vyplní do připraveného pole formuláře a v dalším kroku se do formuláře předvyplní většina jeho údajů. Tato autorizace pomocí SMS je implementovaná, aby se zabránilo zneuţití funkcionality pro dotaţení údajů neoprávněným uţivatelem.

Obrázek č. 13: Aktuální verze aplikace Úvěr online

Zdroj: vlastní, testovací prostředí Cetelem

5.3 Webtelem Je to webová extranetová aplikace, která byla vytvořená pro úvěrovou společnost společností Lundegaard v roce 2002. Aplikace nahradila původní desktopovou aplikaci Officeline. Aplikace slouţí primárně pro pořizování ţádostí v partnerských prodejnách úvěrové společnosti. Pro systém splátkového prodeje na internetových obchodech má však význam hlavně jako rozhraní pro práci se ţádostmi, které byly pořízené prostřednictvím webové aplikace Úvěr online.

5.3.1 Funkční popis aplikace 5.3.1.1 Kalkulačka úvěru Kalkulátor je funkce, která umoţňuje pohodlný výpočet různých variant splátek. Celý výpočet pak lze přenést do formuláře pořízení nové ţádosti nebo vytisknout. Poloţky kalkulátoru jsou shodné s poloţkami sluţby Webkalkulačka.

5.3.1.2 Formulář nové ţádosti Nejdříve je nutné vybrat jeden z úvěrových produktů, a po výpočtu úvěru je vyplněn dvoustránkový osobní dotazník. Všechny poloţky formuláře podléhají formálním kontrolám a v případě, ţe klient je jiţ klientem úvěrové společnosti, je moţné pouze na základě zadání jména, příjmení a rodného čísla dotáhnout data ze systému a předvyplnit jimi formulář. Ţádost je moţné kdykoliv v průběhu vyplňování uloţit do sekce rozpracovaných ţádostí.

5.3.1.3 Přehled rozpracovaných ţádostí Zobrazení přehledu všech rozpracovaných ţádostí prodejny. Jsou to ţádosti, které ještě nebyly odeslány k posouzení. Tyto ţádosti je moţné smazat nebo pokračovat v jejich pořizování.

5.3.1.4 Přehled posuzovaných ţádostí Na této obrazovce se zobrazuje přehled ţádostí, které neprošly automatickým schvalováním a byly postoupeny k podrobnějšímu posouzení do úvěrové společnosti. Kliknutím na tlačítko „Detail“ je moţné zobrazit samotnou ţádost. Obrazovka seznamu posuzovaných ţádostí je na obrázku č. 14.

Obrázek č. 14: Náhled na obrazovku ţádostí k posouzení v aplikaci Webtelem

Zdroj: Testovací prostředí Cetelem

5.3.1.5 Stavy ţádostí Kaţdá ţádost můţe mít jeden z následujících stavů: K dalšímu posouzení - ţádost byla zamítnuta v automatickém posuzování. Posuzována - ţádost se právě posuzuje pracovníky úvěrové společnosti - výsledek bude znám cca do třiceti minut od odeslání ţádosti a bude k vidění zde (červená nebo zelená s vykřičníkem); operátor bude také upozorněn zprávou v chatu. Schváleno - ţádost byla schválena - kliknutím na tuto ikonu je potvrzeno úvěrové společnosti, ţe prodejce bere výsledky posuzování na vědomí, a zároveň se zobrazí stránka s informacemi o jméně zákazníka a číslu autorizace ţádosti (číslo autorizace ţádosti je důleţitý údaj, podle kterého je moţné ţádost později kdykoliv dohledat). Kliknutím na tlačítko "tisk" se zobrazí ţádost ve formě určené k vytištění na

počítačové tiskárně; po vytištění nebo po kliknutí na tlačítko "Storno" bude ţádost z tohoto přehledu přesunuta do "Historie ţádostí". Zamítnuto - ţádost byla posouzena a definitivně zamítnuta. Kliknutím na symbol prodejce potvrzuje, ţe bere výsledek schvalování na vědomí (poté bude ţádost z tohoto přehledu přesunuta do "Historie ţádostí"). Odloţeno - ţádost byla odloţena (schvalovací proces byl pozastaven). Výpis ţádostí je standardně setříděn sestupně podle data a času pořízení ţádosti. Toto třídění však lze kdykoliv změnit kliknutím na záhlaví vybraného sloupečku. Nad tabulkou ţádostí je umístěn formulář. Prostřednictvím tohoto formuláře lze filtrovat výpis zobrazených ţádostí podle následujících kritérií: období od – do, typ ţádosti, příjmení, jméno, barem.

5.3.1.6 Historie ţádostí V této části systému má prodejce přístup ke starším pořízeným ţádostem. Je moţné v ní zobrazit poslední pořízené ţádosti, nebo vyhledávat.

5.3.1.7 Přehled ţádostí a financování Tento přehled obsahuje pořízené ţádosti prodejce podle jednotlivých operátorů, kteří ţádosti pořídili. Přehled je moţné sestavit na základě následujících kritérií: Období - období, ve kterém byla ţádost pořízena. Operátor - uţivatel, který ţádost pořídil (zadává se jeho uţivatelské jméno). Sestava - zda jde o ţádost o nový úvěr / kartu, nebo o financování z karty.

5.3.1.8 Chat Pomocí něj můţe komunikovat prodejce s obchodním zástupcem společnosti Aplikace byla naprogramovaná v PHP 4 a Oracle PL/SQL. Na klientské straně pouţívá technologie HTML, JavaScript a CSS.

Přístup do aplikace je zabezpečen SSL šifrováním a klientským certifikátem vydávaným Certifikační autoritou úvěrové společnosti. Tento se vydává pro kaţdé prodejní místo zvlášť. Dále je zabezpečena přístupovými údaji, kterými se autorizují jednotliví operátoři.

5.4 Webový Interní server (WebIS) Intranetová webová aplikace určená primárně pro interní posouzení ţádostí pořízených přes telematické kanály hlavně Webtelem a Úvěr online. Aplikace byla vyvinuta interním vývojem v průběhu roku 2009 a nasazena začátkem roku 2010. Nahradila tak starší desktopovou aplikaci, která slouţila stejným účelům a byla postavená na platformě Delphi od společnosti Borland. Aplikace byla naprogramovaná v PHP 5, byl zde ale poprvé v rámci firemních aplikací pouţitý Zend Framework25 ve verzi 1.

5.4.1 Funkční popis aplikace Hlavní funkcionalitou aplikace WebIS je sada nástrojů, které umoţňují posoudit ţádost o úvěr. Hlavní stránkou aplikace je tedy seznam ţádostí, které neprošli automatickým schválením a je nutné jejich expertní vyhodnocení. Toto zahrnuje například: pokročilé filtrování seznamu ţádostí s moţností uloţení nastavení filtru podle operátorů, vyhledávání ţádostí podle různých parametrů, zobrazení detailu ţádosti, převzetí ţádosti k posouzení, pomocné stavy pro proces posuzování, finální rozhodnutí, komunikaci s prodejcem, tj. s aplikací Webtelem, nastavení oprávnění schvalování pro několik úrovní kompetencí.

25

Bliţší informace dostupné na http://framework.zend.com

6

TECHNOLOGICKÉ PROMĚNY SYSTÉMU A POZOROVANÉ TENDENCE VE VÝVOJI WEBOVÝCH APLIKACÍ

Relativně dlouhé období, kterým je vymezená časová stránka této práce, přineslo velké mnoţství změn v popisovaném systému. Tyto změny byly kromě vývoje funkcionality na zakázku obchodního oddělení také reflexí rozvoje webových technologií a vývojových postupů. Proto se nabízí pokusit se identifikovat na popisu technologických proměn systému některé obecné tendence ve vývoji IT systémů a speciálně webových aplikací.

6.1 Od tlustých klientů k webovým aplikacím I kdyţ se popis systému pro splátkový prodej zaměřuje na webové aplikace, v rámci jeho dřívějšího ţivota byly jeho součástí aplikace, postavené na tlustém klientovi. Tyto aplikace byly pouţívány pro systém splátkového prodeje v čase před masivním nástupem webových aplikací. Officeline od společnosti ALsoft byla aplikace pro pořizování úvěru v kamenných partnerských prodejnách. Klientská část aplikace, která byla nainstalovaná na počítači na prodejně, odesílala data pořízená v offline formuláři pomocí vytáčeného připojení na serverovou část umístěnou na serveru splátkové společnosti, kde byla zpracována. V rámci připojení si také stahovala data o výsledku posouzení dříve pořízených ţádostí o úvěr. V roce 2002 začal vývoj aplikace Webtelem jako webové alternativy k aplikaci Officeline. Společnost tak reflektovala nastupující trend (v tom čase neměly v ČR webový internet banking ještě ani všechny banky26). Po spuštění webové aplikace společnost dále provozovala souběţně obě aplikace ještě několik let. Pozvolné rozšiřování Webtelematiky záviselo od dostupnosti širokopásmového připojení k internetu. Provoz komplexní webové aplikace na nestabilním vytáčeném nebo ISDN připojení byl totiţ značně problematický. Ve snaze o zvýšení dostupnosti byla vyvinuta také jednodušší verze s graficky odlehčeným designem, který například pouţíval namísto obrázkových formulářových prvků co nejvíc textu, a osekanou funkcionalitou, například byla odstraněna hra a chat. Tato verze pak neměla takové nároky na datový přenos.

26

http://www.penize.cz/bezne-ucty/15483-postovni-sporitelna-ve-vasem-pocitaci

Přes tyto počáteční problémy aplikace Webtelem postupně nahradila aplikaci Officeline , jejíţ provoz byl v roce 2007 ukončen. Desktopová aplikace Interní server, napsaná v Borland Delphi, byla výsledkem interního vývoje. Aplikace slouţila pro interní posuzování ţádosti o úvěry. Byla nahrazena webovou aplikací Webis v roce 2010. Zavedení bylo v tomto případě podstatně jednodušší, neţ v případě aplikace Webtelem, protoţe v tom čase byly jiţ webové technologie na jiné úrovni a prostředí podnikové sítě netvořilo ţádnou překáţku. Aplikace přinesla vylepšení po všech stránkách, funkční, ergonomické i výkonnostní. Pomocí technologií AJAX a jQuery práce s ní víc připomíná práci s desktopovou aplikací, neţ práci s webovými stránkami. Všechny části systému pro splátkový prodej jsou tak jiţ v současnosti webové aplikace. Tento vývoj také dokumentuje trend nahrazování desktopových aplikací v některých oblastech pouţití webovými aplikacemi.

6.2 Od procedurálního k objektovému programování Začátky vývoje webových aplikací jsou spojeny se strukturovaným vývojem, tedy s modulárním návrhem. Strukturované programování je technika, která vyuţívá hierarchii modulů, v které má kaţdý modul (procedura nebo funkce) jeden vstupní a výstupní bod a v kterých je kód postupně vykonáván. V strukturovaném programování jsou data a funkce odděleny, coţ se ukázalo jako nedostatek v rámci procesu návrhu zejména. Princip abstrakce vyuţívaný při tomto procesu lépe pracuje s entitami podobnými předmětům z reálného světa, v kterém neexistuje oddělení dat od funkcí. Snaha odstranit tento nedostatek vedla k objektově orientovanému návrhu, objektově orientovanému programování (OOP) a vzniku objektově orientovaných jazyků, které zaznamenaly obrovský rozvoj v 90. letech. S příchodem čistě objektově orientovaného jazyka Java do webového světa (J2EE27) se začíná objektový vývoj prosazovat i ve vývoje webových aplikací. Jako hlavní vývojová platforma pro webové aplikace, které jsou součástí popisovaného systému je PHP. Tento jazyk je v současnosti ve verzi 5, ale v době, kdy se začal systém vyvíjet, byla k dispozici pouze verze 4. Na této verzi byly vyvinuty aplikace Webtelem, Úvěr online a Webkalkulačka.

27

J2EE – Java 2 Enterprise Edition je součást platformy Java určena pro podnikové aplikace. V roku 2006 byla přejmenována na Java Platform, Enterprise Edition (JEE).

PHP podporovalo práci s objekty jiţ od verze 3, nicméně model, který byl implementován i ve verzi 4, nebyl plnohodnotným objektovým modelem. Objekt z hlediska jazyka nebyl ničím víc, neţ jakákoliv proměnná. To znamená, ţe objekt při jeho volání nebyl předáván přímo (respektive referencí na něj), ale hodnotou, tj. kopírován. To vedlo k určitým problémům, pro které bylo pouţití objektů omezené z pohledu návrhu i výkonu a ty se pouţívaly tedy spíš jako kolekce funkcí. Aţ PHP 5 přineslo předávání objektů odkazem, coţ přineslo rychlejší a srozumitelnější kód. Vývoj aplikací v našem systému je dobrým příkladem výše popsané tendence. Původní aplikace Webkalkulačky byla naprogramovaná pouze strukturálně bez pouţití objektů. Tato implementace se s narůstajícími poţadavky na změny potýkala s problémy údrţby kódu a také kompatibility s dalšíma aplikacemi. Se zavedením objektového modelu v PHP 5 byla přepsána. Aplikace Webtelem a Úvěr online byly jiţ naprogramované s co největší snahou o pouţití objektového modelu, i kdyţ se z důvodu jiţ zmíněných omezení nevyhnuly ani prvkům strukturovaného programování. Aplikace WebIS jiţ plně vyuţívá objektový model PHP5, který je dobře vyuţitý v Zend Frameworku, na kterém je aplikace postavená.

6.3 Od „jednovrstvé“ k vícevrstvé architektuře 6.3.1 Vrstvy v architektuře IT systémů V návrhu IT systémů je vrstvení běţně pouţívanou technikou, která pomáhá zpřehlednit a zjednodušit vývoj sloţitých systémů. Rozdělení systému na vrstvy, tj. logicky a funkčně oddělené celky, umoţňuje implementovat menší celky. To má za následek niţší sloţitost, tím moţnost větší specializace, standardizace, lepší otestovatelnosti a spolehlivosti. Obecně se s vrstvami potkáváme v kaţdém segmentu IT systémů, např. rozvrstvena je architektura samotných počítačů (aplikační vrstva, operační systém, hardware) nebo architektura počítačové sítě (např. komunikační protokol TCP/IP). V oblasti programování aplikací byla dlouhou dobu pouţívána architektura klient-server, tedy dvouvrstvá architektura. Klient obsahoval uţivatelské rozhraní a aplikační logiku a na serveru byla pouze databáze, která někdy mohla obsahovat část aplikační logiky ve formě uloţených procedur. Klient tedy komunikoval s databází přímo pomocí SQL dotazů. Tento typ architektury začal být s rostoucími poţadavky na funkcionalitu, a tím také se znásobením rozsahu, problematický na údrţbu, implementaci změnových poţadavků a také zprávu dat.

Aplikační logika se často dostávala do prvků uţivatelského rozhraní, coţ vedlo k znepřehlednění kódu pro další pouţití nebo rozvoj. Různé pouţívané datové zdroje zas nutily implementovat duplikovanou funkcionalitu pro zprávu dat. Objektově orientovaný návrh přinesl řešení mnoha problémů dvouvrstvé architektury. Architektura aplikace se rozdělila do prezentační, doménové a datové vrstvy: Prezentační vrstva má na starost zobrazit uţivateli uţivatelské rozhraní aplikace. To znamená zobrazit data, připravená doménovou vrstvou a připravit grafické ovládací prvky (např. formulářové poloţky jako vstupní pole, výběrové seznamy nebo tlačítka) pro interakci uţivatele s aplikací. Doménová vrstva obsahuje třídy, které reprezentují logiku a funkcionalitu aplikace, výpočty a zpracování dat. Datová vrstva se zabývá prací s datovými úloţišti. Nejčastěji to jsou relační databáze, ale můţe to být například také souborový systém nebo systém pro zasílání zpráv. Ve světě objektově orientovaného návrhu to můţe být vrstva, která zabezpečuje mapování databázových struktur na objekty, se kterými potom samotná aplikace pracuje28.

6.3.2 Vrstvy u webové aplikace v PHP Na vývoji webových aplikací v našem systému je moţné dobře historicky zdokumentovat trend vrstvení, který byl popsán v předchozí kapitole. Původní aplikace PHP se dají s nadsázkou označit jako jednovrstvé. Nezřídka byla v rámci jednoho scriptu implementovaná vrstva prezentační, doménová i databázová. Jazyk PHP a byl, především nástrojem, který umoţňoval vkládat programové části do HTML kódu, tj. doménovou logiku do prezentační vrstvy. Příklad takového kódu pro zobrazení seznamu z databáze můţe být:

Seznam zboží

Objektově relační mapování je programovací technika, která zajišťuje automatickou konverzi dat mezi relační databází a objektově orientovaným programovacím jazykem. Jejím cílem je odstínění programátora od přímé práce s konkrétní relační databází a zajištění persistence dat.

$conn = oci_connect("username", "pasword"); // Parsování SQL dotazu $stmt = oci_parse($conn,"select kod_zbozi, nazev_zbozi from tabulka_zbozi"); // Vykonání SQL dotazu oci_execute($stmt); // Načtení výsledku databáze do pole $pocet_zaznamu = oci_fetch_all($stmt, $results); // Rozhodnutí, podle toho jestli dotaz vrátil nějaké výsledky if ($pocet_zaznamu>0) { // Vypsaní výsledků do HTML kódu v cyklu foreach ($results as $result) { echo "".$result[nazev_zbozi]."
"; } } else echo "V databázi není žádné zboží."; ?>

V tomto kódu je přítomna datová vrstva, tj. komunikace s databází Oracle, doménová logika, tj. rozhodnutí o tom, jaká data se mají zobrazit podle výsledku dotazu do databáze a také prezentační část, tj. zobrazení HTML dokumentu, jak jeho statické, tak dynamické části. Webová aplikace platební brány pro platbu kreditní kartou Aura na internetových obchodech, která byla do jisté míry předchůdcem aplikace Úvěr online, byla implementována právě tímto způsobem. V aplikacích Webtelem, Webové sluţby a Úvěr online byla jiţ pouţita oddělená prezentační vrstva, která byla vyjmuta do šablonovacího systému. V šablonovacích systémech existují zvlášť soubory pro šablony a zvlášť soubory pro aplikační logiku, které jsou většinou oddělené i v rámci adresářové struktury webové aplikace. Existuje spousta šablonovacích systémů, které se hodně liší hlavně co do komplexnosti. Je moţné pouţít i samotné PHP jako šablonovací systém vyjmutím HTML části do samostatného souboru. Z komplexnějších systémů pro PHP je asi nejznámější Smarty29. Pouţití šablon přináší větší komfort pro HTML kodéry, ale také zpomalení aplikace. V našich aplikacích byl pouţitý jednodušší šablonovací systém, který vytvořila společnost Lundegaard. Tento systém umoţňoval pomocí speciálních značek například vkládat do HTML šablon proměnné nebo zobrazit jenom některé poţadované bloky, jak je vidět na příkladě: Počet měsíčních splátek: {@pocetSplatek} 29

http://www.smarty.net/

Výše měsíční splátky: {@vyseSplatky} Kč

Doménová a datová vrstva byly implementovány do modulárního objektového systému v PHP a částečně také do uloţených procedur napsaných v jazyku PL/SQL. Při vývoj aplikace Webis bylo rozhodnuto, ţe se půjde cestou pouţití PHP frameworku Zend, který implementuje MVC architekturu, co přineslo další posun ve vrstvení architektury webového vývoje. Tato architektura vyţaduje vytvoření tří komponent: Model (model) je doménově specifická reprezentace informací, s nimiţ aplikace pracuje. View (pohled) převádí data reprezentovaná modelem do podoby vhodné k interaktivní prezentaci uţivateli. Controller (řadič) reaguje na události a zajišťuje změny v modelu nebo v pohledu. Komponenty „řadič“ a „pohled“ jsou obvykle klasifikovány jako prezentační vrstva, komponenta „model“ jako doménová vrstva. Datovou vrstvu MVC neřeší. V naší aplikaci je ale řešena pomocí třídy Zend frameworku Zend_DB_Table30, coţ je objektově orientované rozhraní k databázovým tabulkám. Komponenta pohled je v aplikaci Webis implementovaná pomocí šablonovacího systému Smarty.

6.4 Od přímé implementace v programovacím jazyce k frameworkům Frameworky slouţí jako podpora při programování tím, ţe obsahují řešení typických problémů pro konkrétní oblasti. Ve webovém objektovém prostředí tedy mohou obsahovat doporučenou objektovou a adresářovou architekturu a nástroje pro její vytvoření, třídy pro podporu návrhových vzorů, knihovny pro podporu různých funkcionalit, např. navigace mezi stránkami, tvorbu formulářů a jejich validaci, práci s databázemi, nástroje pro testovaní, atd. Framework je vázán na konkrétní programovací jazyk a tvoří nad ním nadstavbu, která můţe

30

http://framework.zend.com/manual/1.12/en/zend.db.table.html

mít vlastní pravidla, které jsou striktnější, neţ u programovacího jazyka, na kterém je postaven. Většinou jsou frameworky výsledkem komunitního vývoje pod nějakou Open Source licencí. V popisovaném prostředí se pouţití frameworků datuje od roku 2009, kdy začala být vyvíjena aplikace WebIS. V určitém smyslu byl frameworkem jiţ modulární PHP systém, ve kterém byla napsaná aplikace Webtelem a který byl recyklován při vývoji aplikace Úvěr online, ale aţ WebIS pouţil skutečně komplexní PHP framework a to Zend Framework. Rozhodnutí ubírat se touto cestou vývoje bylo výsledkem potřeby mít dlouhodobě dobře udrţovatelnou a rozšiřitelnou aplikaci, zjednodušit a zrychlit vývoj pouţitím jiţ hotového řešení. Vzhledem k programátorskému zázemí byl od začátku zvaţován pouze vývoj v PHP. Výběr vhodného frameworku proběhl na základě analýzy, v rámci které byla zvaţována i jiná řešení, zejména český framework Nette. Do analýzy pro výběr mezi PHP frameworky vstupovaly tyto faktory: robustnost, vývojářská podpora, stabilita, moţnosti funkčního rozšíření, dokumentace, výkon. Analýzou těchto faktorů byl nakonec vybrán Zend Framework zejména z důvodů dobré vývojářské podpory, dokumentace, rozšíření, funkcionality a také předpokladu, ţe splnění výše uvedených podmínek bude nejlépe garantovat řešení od firmy, která stojí za vývojem jádra PHP. Výkon, ve kterém byl v porovnání s jinými frameworky Zend Framework horší31, nebyl z hlediska pouţití kritickým faktorem. Pouţití frameworku prokázalo vhodnost řešení pro tento typ aplikace. Přes větší časovou náročnost na začátku implementace, způsobenou hlavně nutností naučit se pracovat s frameworkem, a určitými výkonnostními problémy, které se ale podařilo vyladit na uspokojivou míru, je WebIS stabilní a dobře rozšiřitelnou aplikací. 31

http://www.root.cz/clanky/velky-test-php-frameworku-zend-nette-php-a-ror/

Frameworky jsou ale ve světě webu pouţívány rovněţ v programování na straně klienta. Jedná se hlavně o javascriptové knihovny, z kterých začala být pouţívaná v našem systému knihovna jQuery nejdřív v aplikaci WebIS a posléze i v aplikaci Webtelem.

6.5 Standardizace kódu HTML dokumentů Vývoj samotných webových dokumentů nebo stránek byl v roce 2003, stejně jako dnes, postaven primárně na kombinaci technologií HTML, CSS a JavaScript, která je někdy označovaná zkratkou DHTML. I kdyţ v roce 2003 jiţ tyto technologie uměly většinu z toho, co dnes, způsob práce s nimi byl dost odlišný. Technologické prvky byly totiţ z důvodu nestandardních a rozdílných implementací v různých prohlíţečích rovněţ pouţívány nestandardně, a často jiným způsobem, neţ pro jaký byly určeny. Typickými příklady tohoto pouţití jsou: Formátování celého dokumentu bylo postavené na tzv. tabulkovém layoutu, tj. veškeré grafické uspořádání stránky bylo definováno pomocí elementů , a

. Jednotlivé grafické části, tj. menší obrázky a text byly umísťovány do buněk tabulek, a tím vytvářely jakousi mozaiku, která ve výsledku vytvořila ucelený grafický layout. Toto mělo spoustu nevýhod, např. dokument nemohl být správně strukturován, kód byl nepřehledný, protoţe obsah byl míchán s grafikou, a také tento layout zpomaloval zobrazení stránky, protoţe prohlíţeč čekal, aţ se stáhne celá tabulka. Pouţití tabulky jako grafického prvku dokumentu tak nestandardně získalo význam hlavního prostředku pro vytváření grafického layoutu. CSS byly vyţívány pouze pro jednotné formátování textu a barev a pro to, aby nebylo nutné definovat formátování vţdy u kaţdého elementu dokumentu. V tomto případě zas nebyly plně vyuţity moţnosti a principy, které byly určené právě k vytváření vzhledu celého dokumentu. Vzhledem k rozdílné implementaci JavaScriptu v různých prohlíţečích byla často v jednom kódu vícenásobná implementace jedné funkce. Která implementace byla vykonána, bylo určeno na základě identifikace prohlíţeče. To znásobovalo náklady na implementaci a u rozsáhlejších kódů, také ke zpomalení načtení scriptu a jeho vykonání. S postupným vývojem prohlíţečů byla většina problémů způsobených vzájemnou nekompatibilitou odstraněna. Tabulkový layout tak mohl být nahrazen tzv. CSS layoutem, který plně vyuţívá moţnosti kaskádových stylů. Ve spojení s JavaScriptem, který je jiţ z velké části kompatibilní na všech moderních prohlíţečích, tvoří dobrou podporu pro vytváření webových aplikací. V našem systému si tímto vývojem prošli aplikace Úvěr online a Webtelem. Jako příklad uvádím kód základního rozvrţení layoutu u aplikace Úvěr online v původní a nové verzi: Původní verze (tabulkový layout): {@obsah} Současná verze (CSS layout): {@obsah} {@paticka} {@hlavicka} Pouuţití CSS layoutu umoţnilo jednodušší přizpůsobení vzhledu podle poţadavků partnerů u aplikace Úvěr online a rychlou implementaci „light“ verze aplikace Webtelem. 6.6 Důraz na analýzu a návrh V začátcích vývoje webových aplikací byla analýza a návrh často velice nespecifikovaná a neformalizovaná činnost. Webový vývojář zastával často roli analytika, architekta a programátora v jedné osobě. V takových případech byla analýza v nejlepším případě volně psané strukturované zadání a návrh se realizoval aţ na úrovni implementace. S rostoucí náročností webových projektů začaly i do webového vývoje pronikat sofistikovanější prvky softwarového inţenýrství. Vzhledem ke směřování vývoje webových aplikací k objektovému vývoji, to pochopitelně byla objektově orientovaná analýza a návrh za pouţití jazyka UML. V systému splátkového prodeje se tento přístup začal uplatňovat nejdříve u dodavatelů, kdy byl pouţitý v rámci vývoje aplikace Webtelem. V rámci analýzy poţadavků na aplikaci, jejíţ vývoj byl zadáván splátkovou společností, byl pouţitý model případů uţití. Na základě tohoto modelu mohla být validována analýza ze strany zadavatele a akceptován výsledný produkt. V rámci interního vývoje začal být tento přístup praktikován při vývoji aplikace WebIS v roce 2009. Změnu přístupu umoţnilo mimo jiné také rozšíření vývojového týmu, které umoţnilo specializaci členů týmu do rolí analytika, návrháře, programátorů uţivatelského rozhraní a serverové části. Pro analýzu a návrh byla pouţita aplikace Enterprise Architect od firmy Sparx Systems. 6.7 Zavádění nástrojů průběţné integrace Webový vývoj byl ve svých začátcích většinou záleţitostí vývoje jednotlivců, nebo velice malých teamů. Vývoj probíhal v jediné vývojové verzi, která byla po akceptaci manuálně nakopírovaná, většinou pomocí protokolu FTP, do prostředí produkčního serveru. Zálohování bylo neřízené a testování omezeno na uţivatelské testy. S narůstajícím rozsahem projektů se ale i v tomto segmentu zdomácněly nástroje průběţné integrace. Průběţná integrace je souhrnem různých vývojářských nástrojů a metod k urychlení vývoje softwaru a spolupráce týmů. Tyto nástroje zahrnují většinou práci s verzovacím systémem, automatické buildování a automatické testování. 6.7.1 Verzovací systém Je to systém, který obsahuje funkce na podporu vývoje v teamu a verzovaní vývoje software. Tento nástroj byl vyvinut z důvodu potřeby souběţného vývoje více vývojářů na stejném projektu. V takovém případě si programátoři mohou svoje kódy navzájem přepisovat, vznikají konflikty a problémy při buildování a testování. Verzovací software slouţí k řízení takového vývoje. Kódy jsou při tomto způsobu práce ukládány do centrálního úloţiště (repository). Programátoři k němu přistupují, aby si mohli stáhnout do svého vývojového prostředí kopii nejnovější vývojové verzi souborů zdrojového kódu a zároveň do něj vkládají produkty vlastního vývoje, čímţ je prováděna záloha práce. Systém z těchto změn automaticky vytváří novou verzi. V případě souběţné práce více programátorů nad kódem v jednom souboru systém umí změny sloučit, nebo v případě konfliktu poskytne nástroje na jejich odstranění a neumoţní pracovat se souborem, dokud konflikt není odstraněn. Tím je zaručena konzistence všech souborů v projektu. Verzovací systém rovněţ umoţňuje vrátit se k jakékoliv předchozí verzi a tyto verze porovnávat, čím pomáhá při odstraňování chyb. Další funkcí je moţnost vytváření vývojových větví, které mohou slouţit například pro případ souběţného vývoje různé funkcionality s různým časem nasazení. Tyto větve je pak moţné sloučit. 6.7.2 Automatické buildování Build je proces, při kterém je ze souborů, které obsahují zdrojový kód projektu vytvořena cílová aplikace. Jedná se při něm o posloupnost kroků, v rámci kterých se provádí činnosti jako konfigurace, kopírování souborů, vytváření adresářové struktury, kompilace, stahování aktuálních knihoven nebo komponent, odesílání emailů a podobně. Pro buildování se nejčastěji pouţívají nástroje Make, Apache Ant a Apache Maven. Software pro automatické buildování umoţňuje správu buildů pro více projektů na jednom místě, rozšíření jejich funkcionality, integraci s verzovacím systémem, statistiky výsledků a časů buildování, nastavení automatického provedení buildu v časových intervalech a podobně. 6.7.3 Automatizace testování Je to metoda testování, při které programátor nejdříve píše testy, které jsou pak spouštěny při kaţdém buildu aplikace, čímţ je zajištěna funkčnost aplikace. Tyto testy se obecně nazývají unit testy a kaţdý z nich má za cíl otestovat programovou jednotku kódu, např. funkci, proceduru, třídu nebo její jednotlivé metody. Pro tyto testy se pouţívají specializované nástroje např. JUnit pro Javu. Systém, který je předmětem této práce, začal jako první z nástrojů průběţné integrace pouţívat v roce 2006 verzovací software CVS (Concurent Version System) pro vývoj aplikace Webtelem, kdy bylo potřebné sdílet interní vývoj aplikace s vývojem na straně původního dodavatele. Tento software byl v roce 2008 nahrazen software SVN (Subversion). Postupně byly do tohoto verzovacího systému přidány všechny aplikace tvořící systém pro ţádosti o úvěry na internetových obchodech. V roce 2011 bylo zavedeno buildování aplikací pomocí software Hudson. V případě PHP aplikací, které se nekompilují, se jednalo hlavně o automatizaci konfigurace pro různá prostředí, vytaţení projektu z SVN, přesouvání souborů projektu do cílového prostředí (validačního nebo produkčního) a vytváření adresářové struktury za pouţití buildovacího nástroje Apache Ant. V případě Java projektů se jedná o komplexní build, který obsahuje kromě zmíněného ještě kompilaci, sledování závislostí a stahování aktuálních balíčků komponent pomocí buildovacího nástroje Apache Maven. Unit testování je zatím pouţité pouze u projektu WebIS za pomocí nástroje PHPUnit, který má podporu v Zend Frameworku. Pouţití nástrojů průběţné integrace přineslo velké usnadnění a niţší chybovost jak při vývoji, tak při nasazování aplikací. 7 OBCHODNÍ PŘÍNOSY Zavedení systému v roce 2004 mělo nečekaně rychlý obchodní úspěch a meziměsíční nárůst v desítkách procent. V říjnu 2004 bylo pořízeno přes systém 666 ţádostí o úvěr, v listopadu jiţ 1464 a v prosinci 2232 ţádostí. Další vývoj počtu ţádostí je uveden v grafu. Vývoj je zaloţen na srovnání výsledků za prosinec 2004, 2007, 2011 a 2012. Obrázek č. 15: Vývoj dle počtu ţádostí Počet žádostí 9000 8000 7000 6000 5000 4000 Počet žádostí 3000 2000 1000 0 Zdroj: Vlastní, statistiky Cetelem Dle tiskové zprávy Internet Mall z 4.5.2005 se díky zavedení systému pod marketingovým názvem „splátky na dálku“ velmi výrazně zvýšil podíl splátkového prodeje v Internet Mall na 10 % zákazníků32. I kdyţ byly vývoj a spolupráce zahájeny s partnerem Internet Mall, brzy následovali další partneři, kterých bylo v říjnu 2004 jiţ 17. Zlomovým krokem pro výraznější nárůst partnerů 32 http://www.mall.cz/tiskova-zprava-05-05-04/ bylo zavedení nového procesu pořízení ţádosti, který umoţnil zavést systém i pro partnery bez vlastní dopravy. Obrázek č. 16: Vývoj dle počtu partnerů Počet partnerů 250 200 150 100 Počet partnerů 50 0 Zdroj: Vlastní, statistiky Cetelem Graf ukazuje vývoj podle počtu unikátních partnerů v jednotlivých měsících. Za rok 2012 bylo přes systém pořízeno přes 63000 ţádostí, které byly pořízené přes 450 různých internetových obchodů. Splátkový prodej přes internetové obchody se tak stal významným obchodním kanálem. Úspěch nového obchodního kanálu prokázal ţivotaschopnost internetu jako komerčního média a otevřel tak cestu dalším obchodním aktivitám na internetu. ZÁVĚR Zkušenosti z pouţití webových aplikací umoţnily jejich rozšíření jako náhrady za klasické desktopové aplikace. Zlepšila se tak distribuce těchto aplikací a flexibilita při jejich správě. Vývoj v oblasti analýzy a návrhu umoţnil lépe reflektovat poţadavky uţivatelů a lépe připravit podklady pro samotnou implementaci. Samotnou implementaci, údrţbu a zapracování změnových poţadavků usnadnilo pouţití zmíněných frameworků. Problematika konzistence vývoje, testovaní a nasazování do produkce byla částečně podchycena pouţitím nástrojů průběţné integrace. V souladu s těmito zkušenostmi, obchodními poţadavky, technologickými očekáváními partnerů a tendencemi popsanými v kapitole 5, vyplývají z této práce závěry, které se dají pouţít jako východisko pro další směřování vývoje systému: 1. Redesign všech PHP aplikací v systému na jednotné platformě. V rámci dobrých zkušeností s pouţitím Zend Frameworku při vývoji aplikace WebIS přepsat aplikace na tuto platformu v aktuální verzi Zend Framework 2. Pro analýzu a návrh pouţít nástroj Enterprise Architect. Při vývoji důkladně pouţívat automatické testovaní pomocí nástroje PHPUnit. 2. Redesign uţivatelského rozhraní všech webových aplikací. Změnit layout v souladu s aktuálními uţivatelskými poţadavky a trendy na ergonomii a vzhled. Přeprogramovat klientský kód podle současných technologických moţností a trendů. 3. Redesign vrstvy aplikační logiky uloţené v PL/SQL procedurách v databázi Oracle. Přehodnotit funkcionalitu a zjistit, jestli neexistuje lepší řešení na úrovni jiné vrstvy. Refaktorovat zbývající kód. Přidat PL/SQL procedury do nástrojů průběţné integrace. 4. Rozšíření nabídky webových sluţeb: Umoţnit tak větší integraci se systémy partnerských prodejen. Do budoucna vyvinout alternativní SOA33 architekturu. 33 Service Oriented Architecture – architektura IS orientovaná sluţby. Ty jsou většinou poskytované formou webových sluţeb. SEZNAM POUŢITÉ LITERATURY Monografie: [1] BUCHALCEVOVÁ, A., I. STANOVSKÁ a M. ŠIMÚNEK. Základy softwarového inženýrství - základní témata. Praha:VŠE, 2003, ISBN 80-245-0346-8. [2] ECKEL, Bruce. Myslíme v jazyku Java. Praha: Grada, 2001. ISBN 80-247-9010-11164. [3] HENDL, Jan. Kvalitativní výzkum: základní metody a aplikace. Praha: Portál, 2005. ISBN 8073670402. [4] KANISOVÁ, Hana; MULLER, Miroslav. UML srozumitelně. 2.aktualizované vydání. Brno: Computer Press, 2007. ISBN 80-251-1083-4. [5] KOCNÁR, Peter. Historie a současnost technologií pro vývoj webových aplikací. Praha, 2010. Semestrální práce. BIVŠ. [6] KOSEK, Jiří. PHP a XML .Praha: Grada, 2009. ISBN 978-80-247-1116-4. [7] TRAVIS, Brian. XML a SOAP Programování serverů BizTalk. Praha: Computer Press, 2000. ISBN 80-7226-303-X. Elektronické zdroje: [8] About the Apache HTTP Server Project - The Apache HTTP Server Project [online]. ©2012 [cit. 2013-05-20]. Dostupné z: [9] BRÁZA, Jiří. Objekty v PHP5. Interval.cz [online]. 2003-03-12 [cit. 2013-06-26]. Dostupné z: [10] DRESLER Robert. Vícevrstvé architektury aplikací. [online-blog]. 2011-04-26 [cit. 2013-06-09]. Dostupné z: [11] Přispěvatelé Wikipedie, Continuous integration [online], Wikipedie: Otevřená encyklopedie, Datum poslední revize 2013-06-11, 04:51 UTC, [citováno 2013-06-15] [12] Přispěvatelé Wikipedie, Representional State Transfer [online], Wikipedie: Otevřená encyklopedie, Datum poslední revize 2013-04-04, 04:51 UTC, [citováno 2013-06-17] [13] Přispěvatelé Wikipedie, Oracle [online], Wikipedie: Otevřená encyklopedie, Datum poslední revize 2013-04-06, 04:51 UTC, [citováno 2013-05-10] [14] Přispěvatelé Wikipedie, iPlanet [online], Wikipedie: Otevřená encyklopedie, Datum poslední revize 2013-02-28, 04:51 UTC, [citováno 2013-05-20] SEZNAM OBRÁZKŮ Obrázek č. 1: Vývoj uţivatelů internetu od roku 2001 (údaje v %) Obrázek č. 2: Počet obyvatel ČR se zkušeností nákupu na internetu (v tis.) Obrázek č. 3: Obrat internetových obchodů (v miliardách Kč) Obrázek č. 4: Business Process Model Obrázek č. 5: Funkční pohled reprezentovaný diagramem případů uţití Obrázek č. 6: Základní schéma třívrstvé architektury webové aplikace Obrázek č. 7: Síťová architektura systému Obrázek č. 8: Pouţití serverových programovacích jazyků pro webové stránky Obrázek č. 9: Nejpopulárnější PHP frameworky v roce 2011 Obrázek č. 10: Pouţití JavasScriptových knihoven ve webových stránkách Obrázek č. 11: Implementace webového kalkulátoru na Mall.cz Obrázek č. 12: Implementace webového kalkulátoru na Alza.cz Obrázek č. 13: Aktuální verze aplikace Úvěr online Obrázek č. 14: Náhled na obrazovku ţádostí k posouzení v aplikaci Webtelem Obrázek č. 15: Vývoj dle počtu ţádostí Obrázek č. 16: Vývoj dle počtu partnerů × Report "Online systém splátkového prodeje pro internetové obchody" Your name Email Reason -Select Reason- Pornographic Defamatory Illegal/Unlawful Spam Other Terms Of Service Violation File a copyright complaint Description Close Send × Sign In Email Password Remember me Forgot password? Sign In Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close