Middleware pro propojení ekonomického systému Pohoda a elektronického obchodu PrestaShop

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Diplomová práce

Middleware pro propojení ekonomického systému Pohoda a elektronického obchodu PrestaShop Bc. Vojtěch Kozák

Vedoucí práce: Ing. Jan Kopecký, Ph.D

9. května 2013

Poděkování Děkuji Ing. Janu Kopeckému, Ph.D. za jeho rady a připomínky. Rovněž děkuji svým rodičům, že se mnou měli trpělivost a po celou dobu studia mě podporovali.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 9. května 2013

.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Vojtěch Kozák. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Kozák, Vojtěch. Middleware pro propojení ekonomického systému Pohoda a elektronického obchodu PrestaShop. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract This research deals with the analysis of transfering large and heterogeneous XML doucuments between two web services with the use of a middleware system. On this basis the connection is implemented for the e-commerce system PrestaShop and the acountant system Pohoda. Keywords middleware, Pohoda, PrestaShop, web service, XML, XSLT

Abstrakt Práce se zabývá analýzou výměny velkých a nesourodých XML dokumentů mezi dvěma webovými službami s využitím middlewaru. Na tomto základě je provedena implementace propojení mezi e-commerce systémem PrestaShop a účetním systémem Pohoda. Klíčová slova middleware, Pohoda, PrestaShop, webová služba, XML, XSLT

ix

Obsah Úvod

1

1 Webové služby a XML 1.1 SOAP . . . . . . . . . . . . . . . 1.2 REST . . . . . . . . . . . . . . . 1.3 XML, XSLT . . . . . . . . . . . . 1.4 XSLT procesor . . . . . . . . . . 1.5 Anatomie procesoru Saxon . . . 1.6 Saxon a zpracování velkých XML 1.7 Parsování XML dokumentů . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dokumentů . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3 4 7 15 16 19 19 21

2 Analýza 2.1 Volba metodiky . . . 2.2 Analýza požadavků . 2.3 Případy užití . . . . 2.4 Analýza a předběžný

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

25 25 28 35 37

. . . . . . . . . . . . návrh

. . . .

. . . .

. . . .

. . . .

3 Detailní návrh 3.1 Obecný export . . . . . . . . . . . . 3.2 Export internetových kategorií . . . 3.3 Export skladových zásob . . . . . . . 3.4 Import skladových zásob . . . . . . . 3.5 Wrapper pro lokální běh middlewaru

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

41 41 43 45 47 49

4 Implementace 4.1 Zabezpečení RESTových služeb . . . . . 4.2 Middleware . . . . . . . . . . . . . . . . 4.3 Webová služba na kontrolu licencí . . . 4.4 GUI aplikace pro spuštění lokální služby

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

53 53 53 55 61

xi

. . . . .

xii

OBSAH

5 Funkční testování 65 5.1 Prostředí testování . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2 Kontrola vložení nového produktu . . . . . . . . . . . . . . . . 66 5.3 Kontrola tvorby kategorií . . . . . . . . . . . . . . . . . . . . . 68 6 Měření nároků na výkon 71 6.1 Měření vlastní aplikace . . . . . . . . . . . . . . . . . . . . . . . 71 6.2 Měření souvisejících aplikací . . . . . . . . . . . . . . . . . . . . 76 Závěr

81

Literatura

83

A Seznam použitých zkratek

87

B Komunikace PrestaShopu B.1 Zdroje webové služby PrestaShopu . . . B.2 Možnosti renderování . . . . . . . . . . . B.3 XML šablona pro vytvoření produktu . B.4 XML šablona pro vytvoření kategorie . B.5 XML šablona pro vytvoření objednávky B.6 XML šablona pro vytvoření zákazníka .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

91 91 93 94 96 97 98

C Komunikace Pohody C.1 Chybové kódy komunikace . . . . . C.2 XML šablona produktu . . . . . . C.3 XML šablona internetové kategorie C.4 XML šablona adresáře . . . . . . . C.5 XML šablona objednávky . . . . . C.6 Seznam XSD schémat . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

101 101 102 104 105 106 107

. . . . . .

. . . . . .

. . . . . .

D Dokumentace 111 D.1 Nastavení Pohody . . . . . . . . . . . . . . . . . . . . . . . . . 111 D.2 Nastavení middlewaru . . . . . . . . . . . . . . . . . . . . . . . 115 D.3 Nastavení PrestaShopu . . . . . . . . . . . . . . . . . . . . . . . 115 E Obsah přiloženého CD

117

Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Izolace klientů od logiky použité k vyřízení jejich žádosti Elementy mapující parametry vzdálené procedury . . . Document/literal styl . . . . . . . . . . . . . . . . . . . Využití XSLT pro transformaci do různých formátů . . XSLT procesor – základní schéma . . . . . . . . . . . . XSLT procesor – průchod stromem . . . . . . . . . . . . Anatomie procesoru Saxon . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 6 7 16 17 17 20

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21

ICONIX Process . . . . . . . . . . . . . . . . . . . . Testování řízené návrhem – V-model . . . . . . . . . Internetové obchodování Pohoda – úvodní okno . . . Internetové obchodování Pohoda – export dat . . . . Funkční požadavky – export dat . . . . . . . . . . . Internetové obchodování Pohoda – import dat . . . . Internetové obchodování Pohoda – filtrování importu Funkční požadavky – import dat . . . . . . . . . . . Nefunkční požadavky – přenos . . . . . . . . . . . . Nefunkční požadavky – perzistence . . . . . . . . . . Nefunkční požadavky – bezpečnost . . . . . . . . . . Nefunkční požadavky – výkon . . . . . . . . . . . . . Nefunkční požadavky – rozhraní . . . . . . . . . . . Nefunkční požadavky – dokumentace . . . . . . . . . Případ užití – základní diagram . . . . . . . . . . . . Import/export – diagram případu úžití . . . . . . . . Architektura systému – lokální služba . . . . . . . . Architektura systému – síťová služba . . . . . . . . . Importování/exportování – diagram robustnosti . . . PPL – problémová doména . . . . . . . . . . . . . . PPL – problémová doména . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

27 27 29 30 31 31 32 32 33 33 34 34 35 35 35 36 38 38 39 40 40

xiii

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

xiv

Seznam obrázků

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Kontrola exportu – diagram aktivit . . . . . . . . . . . . . . . Obecný export – sekvenční diagram . . . . . . . . . . . . . . Zpracování internetových kategorií – sekvenční diagram . . . Zpracování produktů – sekvenční diagram . . . . . . . . . . . Postupné zpracování XML dokumentu při importu produktů Sekvenční diagram spouštění wrapperu 1 . . . . . . . . . . . Sekvenční diagram spouštění wrapperu 2 . . . . . . . . . . . GUI okno pro běh lokálního middlewaru . . . . . . . . . . . .

. . . . . . . .

41 42 44 46 49 50 51 51

4.1 4.2 4.3

Vytvoření realmu v administraci GlassFishe . . . . . . . . . . . . . GUI aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GUI aplikace – debug mód . . . . . . . . . . . . . . . . . . . . . .

54 62 63

5.1

Úspěšný průběh testu v programu SoapUI . . . . . . . . . . . . . .

68

6.1 6.2 6.3 6.4 6.5

PPL – závislost počtu požadavků na době odezvy . . . . . PPL – závislost počtu požadavků na době odezvy . . . . . Nároky na paměť pro malý XML dokument . . . . . . . . . Nároky na paměť pro velký XML dokument . . . . . . . . . Vytížení procesoru při zpracování malého XML dokumentu

. . . . .

. . . . .

. . . . .

. . . . .

72 75 76 76 77

D.1 D.2 D.3 D.4 D.5 D.6 D.7 D.8

Agenda Obecný internetový obchod . . . Nastavení exportu v Pohodě . . . . . . . . Nastavení importu v Pohodě . . . . . . . Nastavení XML komunikace . . . . . . . . Vytvoření internetových kateogrií . . . . . Vložení produktu do kategorie . . . . . . Webové služby PrestaShopu . . . . . . . . Vytvoření nového účtu pro webové služby

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

111 112 113 114 114 115 116 116

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Seznam tabulek 1.1 1.2

Operace v CRUD v architektonickém stylu REST . . . . . . . . . Porovnání vlastností XML parserů . . . . . . . . . . . . . . . . . .

8 22

3.1 3.2

Seznam HTTP požadavků pro export kategorií . . . . . . . . . . . Seznam HTTP požadavků pro export produktů . . . . . . . . . . .

45 47

6.1 6.2 6.3

Jednosměrné symetrické algoritmy . . . . . . . . . . . . . . . . . . Asymetrický algoritmus RSA . . . . . . . . . . . . . . . . . . . . . Asymetrický algoritmus DSA . . . . . . . . . . . . . . . . . . . . .

79 79 79

B.1 Možnosti rendrování . . . . . . . . . . . . . . . . . . . . . . . . . .

93

C.1 Chybové kódy komunikace . . . . . . . . . . . . . . . . . . . . . . . 101 C.2 Seznam XSD schémat . . . . . . . . . . . . . . . . . . . . . . . . . 108

xv

Seznam výpisů 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

Struktura WSDL dokumentu . . . . . . . . . . . . . . . . . SOAP typu RPC/literal . . . . . . . . . . . . . . . . . . . . SOAP typu document/literal . . . . . . . . . . . . . . . . . Ukázka WADL dokumentu . . . . . . . . . . . . . . . . . . Příklad XML dokumentu . . . . . . . . . . . . . . . . . . . Příklad XSLT dokumentu . . . . . . . . . . . . . . . . . . . Výsledek aplikace XSLT na XML . . . . . . . . . . . . . . . XML dokument a výpis ze SAX parseru . . . . . . . . . . . XML dokument, kde není nutná celá reprezentace najednou

. . . . . . . . .

. . . . . . . . .

5 5 6 12 16 18 18 22 24

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Odpověď od middlewaru při exportu . . . . . . . . . . Základní kostra XML dokumentu pro export kategorií Detail kategorie pro export . . . . . . . . . . . . . . . XML dokument kategorií ve formátu PrestaShopu . . Požadavek na stažení všech zásob . . . . . . . . . . . . Vytvoření produktu v Pohodě . . . . . . . . . . . . . . Aktualizace produktu v Pohodě . . . . . . . . . . . . . XSLT dotaz pro vzdálené použití XPath dotazu . . . . XML dokument s datem (date.xml) . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

42 43 43 44 47 48 48 49 49

xvii

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

Úvod Když jsem před třemi lety začal obchodovat s kávou, jedním prodejním kanálem se stal vlastní internetový obchod. Tehdy jsem se musel vypořádat s několika technickými aspekty. Prvním z nich byl výběr open-source e-commerce systému. Volba v tomto případě byla poměrně jednoduchá, protože již delší dobu je jedničkou v této oblasti obchod PrestaShop. Druhým aspektem byla volba aplikace pro správu skladů a především faktur. Přestože PrestaShop umožňuje základní správu skladů i faktur, při větším objemu prodeje je neefektivní. Výhodnější by bylo použít účetní program, který by tuto správu převzal. Takový program by ale musel být dobře propojený s elektronickým obchodem. Nabídka společnosti Zserver s.r.o. vytvořit propojení účetního programu Pohoda a elektronického obchodu PrestaShop pro mě byla blízká nejenom z pohledu uživatele, ale i vývojáře. K vytvoření vlastního fakturačního systému jsem se dostal v rámci bakalářské práce a PrestaShop jsem měl možnost poznat i při vývoji šablon a modulů. Samotné propojení však skýtá nejednu výzvu. Aplikace musí dokázat propojit dva nesourodé systémy tak, aby zákazník mohl z obou používat maximum funkcí. Export padesáti produktů není tak náročný, export padesáti tisíc již vyžaduje pečlivou analýzu, aby bylo propojení rychlé a příliš nezatěžovalo systém, na kterém bude fungovat. V neposlední řadě je nutné se vypořádat s bezpečností přenosu dat a se zabezpečením aplikace proti nelegálnímu užití. První kapitola je jemným úvodem do webových služeb a podrobněji se zabývá zpracováním XML dokumentů. Tyto technologie jsou základním kamenem této práce. Kapitoly 2–7 popisují tvorbu samotné aplikace, včetně výsledků měření výkonnosti vytvořené aplikace.

1

Kapitola

Webové služby a XML Webovou službu je možné definovat jako libovolnou službu dostupnou přes internet, která využívá standardizovaný systém výměny zpráv a není vázána na operační systém nebo programovací jazyk. [5] Webová služba poskytuje prostředky ke komunikaci heterogenních systémů za využití zpráv a nabízí opětovně použitelné funkce dostupné přes protokol HTTP. Webové služby umožňují relativně jednoduše využívat a sdílet společnou logiku i u tak různorodých klientů, jako jsou mobilní telefony, desktopové nebo webové aplikace. Velký rozsah využití je možný díky implementaci otevřených standardů, které jsou všeobecně známé, široce podporované a jsou schopné vzájemné komunikace mezi různými výpočetními platformami. Všechny webové služby využívají protokol HTTP a standardy pro výměnu dat jako je XML nebo JSON. [18] Webové služby vytvářejí vrstvu dereferencí, která přirozeně odděluje klienta od logiky použité k vyřízení jejich žádosti. To umožňuje klientovi a službě nezávislý vývoj za předpokladu, že se změny nedotknou veřejného rozhraní. Majitel služby tak může například upravit službu, aby využívala open-source knihovnu místo uzavřeného kódu bez nutnosti změny klienta (Obrázek 1.1). [6] Tradiční porozumění termínu webová služba je spojováno s protokolem SOAP (rovněž známým pod názvem WS-* Stack) založeným na vzdáleném volání procedur. [20] SOAP však není jedinou technologií, pomocí které lze vytvořit webovou službu. V posledních letech navíc čelí velké kritice související s komplexitou a mohutností zpráv. Kvůli jednoduchosti a malým nárokům na klienta se stává populárnější architektonický styl REST (Representational State Transfer), navržený a popsaný v roce 2000 Royem Fieldingem v jeho disertační práci.1 REST je na rozdíl od známějšího SOAPu (či jeho předchůdce XML-RPC) orientován datově, nikoli procedurálně. Přístup REST využívá metod protokolu HTTP (GET, POST, PUT, DELETE). 1 Fielding, Roy. Architectural Styles and the Design of Network-based Software Architectures [online] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

3

1

1. Webové služby a XML

Obrázek 1.1: Izolace klientů od logiky použité k vyřízení jejich žádosti [6]

Z hlediska „webových autorit“ je SOAP odsouván do pozadí. Yahoo využívá REST pro všechny své služby, včetně Flickeru a del.ici.ous. Amazon a Ebay poskytují obě rozhraní, ale více než 85 % služeb Amazonu je realizováno ve prospěch RESTu. [23] Google využíval SOAP pro všechny své služby až do roku 2006, kdy přešel na REST. [3]

1.1

SOAP

SOAP neboli Simple Object Access Protocol je komunikační protokol založený na odesílání zpráv ve formátu XML přes HTTP. Vznikl jako náhrada vzdáleného volání procedur (RPC). Aplikace pošle serveru požadavek (pomocí XML zprávy), ten požadavek zpracuje a výsledek odešle zpět jako XML odpověď. Zpráva SOAP obsahuje kořenový element Envelope (obálka). V tomto elementu jsou elementy Header (hlavička) a Body (tělo). Hlavička není povinná, používá se pro přenos pomocných informací (např. autentizačních údajů). [17]

1.1.1

WSDL

Jazyk WSDL (Web Services Description Language) hraje důležitou roli v architektuře webových služeb, protože kompletně popisuje způsoby komunikace s aplikací. WSDL je určen pro strojové zpracování, nepředpokládá se tedy, že by jej četl člověk. Pro samotné zpracování je zapotřebí dalšího nástroje, což ale není velký problém, protože se v podstatě jedná o XML dokument. [28] Díky WSDL je možné vygenerovat zdrojový kód, který přesně ví, jak s webovou službou komunikovat. Existují nástroje, které díky WSDL dokáží vytvořit mock webovou službu, a výrazně tak usnadní funkční a integrační testování. Využití tohoto jazyka ještě umocňuje skutečnost, že jej vývojář nemusí 4

1.1. SOAP sám psát, ale nástroje jako Apache Axis nebo JAX-WS jej vytvoří automaticky. [7] Konceptuální model WSDL 2.0 je rozdělen na dvě části. Na část abstraktní a část konkrétní (viz Výpis 1.1). V abstraktní části je webová služba popsána z hlediska odesílaných/přijímaných zpráv a poskytovaných operací. Tyto operace následně sdružuje pomocí rozhraní. Konkrétní část definuje systémové aspekty pro samotný běh služby, jako je formát zprávy, webová adresa, kde je služba dostupná, a také konkrétní rozhraní z abstraktní části, které služba implementuje. [5] Výpis 1.1: Struktura WSDL dokumentu 1 2 3 4 5 6 7 8

< description xmlns:tns = ’ http: // www . tmsws . com / wsdl20sample ’ targetNamespace = ’ http: // www . tmsws . com / wsdl20sample ’ > > < messages > ... < operation > ... < interface > ...

9 10 11 12 13 14

< binding > ... < service > ... < endpoint > ...

1.1.2

Komunikační model SOAP

RPC/literal Tělo zprávy ve stylu RPC je zkonstruováno specifickým způsobem definovaným standardem SOAP. Je vytvořeno s předpokladem, že se volá webová služba podobným způsobem, jako by se volala metoda, která je součástí aplikačního kódu. Tělo zprávy obsahuje XML s jednotlivými elementy, jež specifikují parametry. Tyto parametry jsou obaleny v elementu obsahující jméno procedury, která se má volat (viz Výpis 1.2 a Obrázek 1.2). Výpis 1.2: SOAP typu RPC/literal 1 2 3 4 5 6 7 8

< soap:envelope > < soap:body > < multiply > 8 3.6



5

1. Webové služby a XML

Obrázek 1.2: Elementy mapující parametry vzdálené procedury [6]

Nevýhoda stylu RPC je v pevném svázání s aplikačním kódem (high coupling). Případná změna parametrů by ovlivnila definici webové služby podobně, jako by ovlivnila definici normální funkce nebo metody. [4]

Document/literal (Message) Styl document/literal neobsahuje žádné restrikce XML formátu pro tělo zprávy a na rozdíl od stylu RPC umožňuje připojit XML Schema. Libovolný formát XML vede k tomu, že klientská a serverová aplikace musí provádět logické uspořádání dat (viz Výpis 1.3 a Obrázek 1.3). [4] Výpis 1.3: SOAP typu document/literal 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

6

< soap:envelope > < soap:body > < movies xmlns = ’ http: // www . myfavoritemovies . com ’ > < movie > < title > 2001 : A Space Odyssey < released > 1968 < movie > < title > Donnie Darko < released > 2001

1.2. REST

Obrázek 1.3: Document/literal styl [6]

1.2

REST

REST neboli REpresentation State Transfer není sám o sobě architekturou, ale spíše sadou omezení, které když jsou aplikovány na systém, vytvářejí architektonický styl. Pokud bychom implementovali všechna pravidla zmíněná v Roy Fieldingově disertační práci, vytvoříme systém, který specifikuje úlohu dat, komponent, hypertextových odkazů, komunikačních protokolů a uživatelů systému. REST má šest základních omezení na systém. Ten je pak označen jako RESTful. Tato omezení jsou: 1. musí být typu klient-server, 2. musí být bezstavový – neměl by existovat důvod udržovat session uživatele, každý dotaz by měl být nezávislý na ostatních dotazech, 3. musí podporovat kešování – infrastruktura sítě by měla podporovat kešování na různých úrovních, 4. musí být přístupný jednotným způsobem – každý zdroj musí mít unikátní adresu přístupu, 5. musí podporovat škálování (vrstvený systém), 6. měl by poskytovat kód na požádání (code on demand) – při některých požadavcích se smí přenést nejen data, ale i celé části programu (např. JavaScript), tento požadavek je jako jediný nepovinný. REST je na rozdíl od SOAPu orientován datově, nikoliv procedurálně. Všechny zdroje mají své identifikátory URI, přičemž REST definuje čtyři základní metody, jak k nim přistupovat. Tyto metody odpovídají klasickému 7

1. Webové služby a XML CRUD (Create – vytvořit, Retrieve – získat, Update – upravit, Delete – smazat). Mapování metod CRUD na metody HTTP je znázorněno v Tabulce 1.1. [27] Tabulka 1.1: Operace v CRUD v architektonickém stylu REST

1.2.1

Akce s daty

HTTP metoda

Create

POST

Retrieve

GET

Update

PUT

Delete

DELETE

HTTP metody

REST využívá několik různých HTTP metod definujících typ požadavku. Mezi čtyři nejdůležitější patří již zmíněný GET, POST, PUT a DELETE. Metody GET, HEAD a OPTIONS jsou označovány jako bezpečné (safe methods), protože jejich použití neovlivní stav serveru. Metody GET, HEAD, PUT a DELETE jsou označovány jako idempotentní (indepotent methods), protože jejich opakované zavolání vyvolá stejnou odpověď. [2] OPTIONS Metoda OPTIONS slouží k vyhledání podporovaných metod daného zdroje nebo jako ping na server. Požadavek Hlavička bez těla požadavku. Odpověď Hlavička, zpravidla bez těla. Server může v těle odpovědi odeslat popis metod. Příklad # Požadavek k získání všech dostupných metod daného zdroje OPTIONS /produkty/kava HTTP/1.1 Host: www.espirito.cz # Odpověď se seznamem podporovaných metod daného zdroje HTTP/1.1 204 No Content Allow: HEAD, GET, OPTIONS, PUT, DELETE GET Metoda GET slouží k získání reprezentace zdroje. 8

1.2. REST Požadavek Hlavička bez těla požadavku. Odpověď Reprezentace zdroje, obvykle s tělem odpovědi. Hlavičky, jako je Content-Type, Content-Length, Content-Language, Last-Modified a ETag korespondují s reprezentací zdroje v odpovědi. Příklad # Požadavek k získání reprezentace zdroje GET /produkty/kava/1 HTTP/1.1 Host: www.espirito.cz # Odpověď HTTP/1.1 200 OK Content-Type: application/xml;charset=UTF-8 Content-Length: xxx ... HEAD Metoda HEAD slouží k získání stejných hlaviček jako při metodě GET, ale bez těla odpovědi. Klient může využít tuto metodu, aby zjistil, jestli daný zdroj existuje, a ověřil metadata zdroje. Požadavek Hlavička bez těla požadavku. Odpověď Hlavička bez těla. Server musí odeslat prázdné tělo odpovědi. Příklad # Požadavek k získání reprezentace zdroje (pouze hlavičky) HEAD /produkty/kava/1 HTTP/1.1 Host: www.espirito.cz # Odpověď HTTP/1.1 200 OK Content-Type: application/xml;charset=UTF-8 Content-Length: xxx POST Metoda POST slouží k vytváření nových a aktualizování existujících zdrojů. Klient může provádět operace nad jedním nebo několika zdroji. Požadavek Reprezentace zdroje. 9

1. Webové služby a XML Odpověď Reprezentace zdroje nebo instrukce pro přesměrování. Pokud je v těle vrácena reprezentace zdroje, která nekoresponduje s URI zadaným v požadavku, je URI tohoto zdroje vráceno v hlavičce Content-Location. Příklad # Požadavek na vytvoření nového zdroje POST /produkty HTTP/1.1 Host: www.espirito.cz Content-Type: application/xml;charset=UTF-8 <product> Espirito Cafe Tanzania # Odpověď HTTP/1.1 201 Created Location: http://www.espirito.cz/produkty/1 Content-Location: http://www.espirito.cz/produkty/1 Content-Type: application/xml;charset=UTF-8 <product> urn:espirito:produkty:1 Espirito Cafe Tanzania

PUT Metoda PUT slouží k aktualizování existujících zdrojů nebo k vytváření nových v případě, že klient zná URI nově vytvořeného zdroje. Od metody POST se liší právě nutností znalosti nově vytvořeného URI. Požadavek může obsahovat pouze tu část XML dokumentu, která se má aktualizovat. DELETE Metoda DELETE slouží k vymazání zdroje. Požadavek Hlavička bez těla požadavku. V případě, že k vymazání zdroje je nutné přiložit informace v těle požadavku, používá se metoda POST a URI se zdrojem řadiče. Odpověď Informace o úspěchu, či neúspěchu. Tělo odpovědi může obsahovat status operace. 10

1.2. REST Příklad # Požadavek na vymazání zdroje DELETE /produkty/espirito-tanzanie HTTP/1.1 Host: www.espirito.cz # Odpověď HTTP/1.1 204 No Content

TRACE Při použití metody TRACE vrátí server hlavičky, které obdržel. Hlavičky jsou odeslány v těle odpovědi. Servery, které podporují tuto metodu, mohou být vystaveny útoku typu cross-site tracing (XST). Požadavek Hlavička a tělo požadavku. Odpověď Tělo obsahující všechny hlavičky z požadavku. Příklad # Požadavek TRACE /produkty/espirito-tanzanie HTTP/1.1 Host: www.espirito.cz Accept: text/html # Odpověď HTTP/1.1 200 OK Content-Type: message/http TRACE /produkty/espirito-tanzanie HTTP/1.1 Host: www.espirito.cz Accept: text/html [1]

1.2.2

WADL

WADL (Web Application Description Language) je jazyk, který kompletně popisuje RESTovou webovou službu podobně, jako WSDL popisuje službu SOAPovou. Samotná existence tohoto jazyka vzbudila mnoho debat a kontroverzí a to z toho důvodu, že jej mnoho lidí považuje za zbytečný. Vzhledem k tomu, že technologie, jako je Jersey, dokáží tento dokument vygenerovat automaticky, je možné najít mnoho oblastí jeho využití. V principu je WADL podobný jazyku WSDL, ovšem struktura obou dokumentů je velmi odlišná. WSDL definuje nestrukturovaný seznam konzumujících nebo poskytovaných zpráv a operací, WADL dává důraz na hierarchickou 11

1. Webové služby a XML povahu RESTové služby. Výpis 1.4 zobrazuje jednoduchý WADL dokument, který popisuje dva zdroje. Je to zdroj /books, který obsahuje metodu GET a zdroj /books/{bookID}, který rovněž obsahuje pouze metodu GET. [8] Výpis 1.4: Ukázka WADL dokumentu 1 2 3 4 5 6 7 8 9 10 11

< application xmlns = ’ http: // wadl . dev . java . net /2009/02 ’ > < resources base = ’ http: // example . com / api ’ > < resource path = ’ books ’ > < method name = ’ GET ’/ > < resource path = ’{ bookId } ’ > < param required = ’ true ’ style = ’ templ ’ name = ’ bookId ’/ > < method name = ’ GET ’/ >

1.2.3

Způsoby autentizace

V této kapitole budou popsány tři běžně využívané autentizační metody: • Basic Authentication • Digest Authentication • API klíč První dvě metody jsou součástí HTTP protokolu a jsou definovány v RFC 2617, HTTP Authentication: Basic and Digest Access Authentication 2 . Poslední metoda není nikde standardizovaná, ale je běžně využívaná u veřejných API. Existuje ale celá řada dalších metod, některé aplikace dokonce používají vlastní, proprietární metody. Basic Authentication Autentizační metody, které jsou vestavěné v protokolu HTTP, využívají hlavičky k odeslání informací souvisejících s autentizací. Pokud se uživatel pokusí přistoupit ke chráněnému zdroji, server ověří autentizační údaje a v případě neúspěchu vrátí stavový kód 401 Unauthorized3 . Spolu se stavovým kódem odešle server hlavičku WWW-Authenticate, která obsahuje autentizační schéma a realm. Realm je case-sensitivní řetězec, který unikátně identifikuje (v rámci 2

http://www.ietf.org/rfc/rfc2617.txt HTTP status kód používá slovo „autorizace“, což je zavádějící. Status kód 401 Unauthorized by měl být vrácen v případě neplatné autentizace, naopak kód 403 Forbidden v případě neplatné autorizace. Tuto informaci zmiňuje dokonce i dokumentace W3C (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). 3

12

1.2. REST dané webové stránky) chráněnou oblast. Příklad požadavku a odpovědi od serveru vypadá např.: GET /user-area/ HTTP/1.0 Host: www.espirito.cz HTTP/1.1 401 Authorization Required WWW-Authenticate: Basic realm="Espirito Cafe User Area" Content-Type: text/html ... Poté, co uživatel zadá správné autentizační údaje, server odpoví s očekávaným stavovým kódem: GET /user-area/ HTTP/1.0 Host: www.espirito.cz Authorization: Basic dm9qdGE6aGVzbG8= HTTP/1.1 200 OK Content-Type: text/html ... V tomto požadavku přibyla navíc hlavička Authorization, která obsahuje přihlašovací údaje. Hodnota první části hlavičky obsahuje autentizační schéma – v tomto případě Basic. Druhá část hlavičky obsahuje kombinaci uživatelského jména a hesla enkódovanou do datového formátu Base64. Řetězec dm9qdGE6aGVzbG8= obsahuje po dekódování vojta:heslo. Metoda Basic Authentication má řadu nevýhod: • ověřovací údaje jsou odeslány jako plain text, • není možné odhlásit uživatele (při požadavku uživatele o odhlášení ani po timeoutu), • HTTP proxy servery dokáží zjistit ověřovací údaje, což je ale problém pouze v případě, kdy těmto proxy serverům není možné důvěřovat. [25] Digest Authentication Hlavním účelem metody Digest Authentication je umožnit odesílání uživatelského jména a hesla na server jiným způsobem než jako plaintext. Místo toho se odesílá hash vypočítaný z těchto autorizačních údajů. Aby nebylo možné použít hash opakovaně, používá se tzv. nonce (Number Once). Nonce je číslo vybrané serverem, který ho odesílá klientovi. Zpravidla je při každém odesílání klientovi jiné, což zaručí bezpečnost proti opakovanému útoku. Digest funkce má následující tvar: 13

1. Webové služby a XML MD5(MD5(<password>)+":"+<nonce>+":"+MD5(<method>+":"+)) Ukázka hlavičky úspěšného dotazu pomocí metody Digest Authentication: GET /user-area/ HTTP/1.1 Host: www.espirito.cz Authorization: Digest username="ivanr", realm="User Area", nonce="OgmPjb/jAwA=7c5a49c2ed9416dba1b04b5307d6d935f74a859d", uri="/user-area/", algorithm=MD5, response="3c430d26043cc306e0282", qop=auth, nc=00000004, cnonce="c3bcee9534c051a0" HTTP/1.1 200 OK Authentication-Info: rspauth="e18e79490b380eb645a3af0ff5abf0e4", cnonce="c3bcee9534c051a0", nc=00000004, qop=auth Content-Type: text/html ... Přestože metoda Digest Authentication splnila svůj účel, její využití v praxi se nikdy nedočkalo velkého rozmachu. Je to způsobeno částečně tím, že znatelně zpomaluje komunikaci mezi serverem a klientem. Přidáním protokolu SSL dojde k odstranění většiny nedostatků metody Basic Authentication. Pokud však tento protokol není k dispozici, je metoda Digest Authentication preferovanou volbou. Existuje mnoho volně dostupných nástrojů, které automaticky sbírají uživatelská jména a hesla z hlaviček metody Basic Authentication odeslaných bez zabezpečeného protokolu SSL. Na druhou stranu, nástroje pro automatické útoky na metodu Digest Authentication nejsou veřejně známé, což zvyšuje úroveň znalostí potřebných pro úspěšné provedení útoku na tuto metodu. [19] API klíč Zabezpečení pomocí tzv. API klíče není nikde formálně definováno. Jedná se o velmi jednoduchou metodu, kterou však aplikovalo mnoho velkých veřejně dostupných API. Uživatel obdrží klíč, kterým se autentizuje serveru. Odesílání klíče často probíhá obohacením URI adresy, např.: http://www.espirito.cz/api/users?key=secureKey Tato metoda není bezpečná, protože je pro útočníka snadné heslo zjistit. Uplatnění nalezne tam, kde je potřeba regulovat počet přístupů k určitému webovému zdroji a kompromitace hesla nezpůsobí závažné problémy. Z hlediska implementace se jedná o nejjednodušší možný způsob. [25] 14

1.3. XML, XSLT

1.3

XML, XSLT

Historie XSLT (eXtensible Stylesheet Language) sahá do dob, kdy se internet začal rychle zvětšovat a vznikly snahy o separaci obsahu od prezentace na webu. Prvotní definice HTML dosáhla určitého stupně separace definováním prezentace (odstavce, kurzíva, seznamy atp.). Brzy však vznikla potřeba publikovat stejná data do různých formátů, jako PDF, HTML nebo mobilní WAP. Na počátku roku 1998 byl konsorciem W3C4 definován obecný značkovací jazyk XML5 , aby oddělil strukturu obsahu od jeho prezentace. Na rozdíl od HTML, které má přesně danou sadu elementů, jsou jednotlivé elementy6 v XML definovány uživatelem a mají popisovat strukturu z hlediska věcného obsahu jednotlivých částí (u skladů např. produkty, ceny, popisy atd.). HTML elementy jsou ve své podstatě typografické, XML elementy mají reprezentovat objekty reálného světa. Díky obecnému zápisu XML je možné vytvořit jednotný dokument, který může být dále zpracován a obsah publikován do různých dalších formátů. Bez nástroje na manipulaci s XML by bylo zpracování velmi obtížné. Potřeba tohoto nástroje byla impulsem pro W3C, aby začala vyvíjet Extensible Stylesheet Language (XSL)7 , což je obecný jazyk pro manipulaci a zobrazení dat v XML dokumentu. Během vývoje XSL vyšlo najevo, že příprava XML dokumentů k zobrazení může být rozdělena do dvou částí. Formátování – XSL Formating Objects (XSL-FO) a transformace – XSL Transformation (známé jako XSLT). Transformace je proces konvertování jednoho XML dokumentu do druhého, formátování je naproti tomu proces konvertování transformované stromové struktury do grafické reprezentace. Separace transformace do jednoho jazyka a formátování do druhého se potvrdila jako velmi dobré rozhodnutí. Postupně se totiž ukázalo, že existuje mnoho aplikací, které vyžadují transformaci, ale se zobrazením dokumentu uživateli nemají nic společného. XML se začalo často používat pro výměnu dat mezi aplikacemi, a vznikla tak ještě větší potřeba konverze jednoho XML slovníku8 do druhého (Obrázek 1.4). [31] 4

World Wide Web Consortium (W3C) je mezinárodní konsorcium, které vyvíjí webové standardy pro World Wide Web. http://www.w3.org/ 5 XML je zjednodušenou podobou jazyka SGML (Standard Generalized Markup Language). SGML je komplexnější než XML, které je postavené více na HTML. Cílem XML byla obecnost SGML a jednoduchost HTML tak, aby bylo snadné tento jazyk použít. Tím, že není XML tak komplexní, je nejenom jednoduší jej pochopit, ale především je pro něj snazší vytvořit parser. To je jeden z aspektů, proč se stalo XML tolik populární. 6 Na rozdíl od HMLT4 definuje HTML5 elementy, které popisují strukturu webu, např. hlavička, patička, článek, sekce apod. 7 Nástin XSL byl již proveden v DSSSL (Document Style Semantics and Specification Language), který slouží pro konverzi různých formátů (mezi ně patří i RTF, HTML, LaTeX).

15

1. Webové služby a XML

Obrázek 1.4: Využití XSLT pro transformaci do různých formátů [31]

1.4

XSLT procesor

Proces transformace XML dokumentu je vykonán procesorem, což je aplikace (nebo softwarová komponenta), která čte XML a XSLT dokument a tento XSLT dokument aplikuje na XML. Existují procesory spustitelné jako samostatné aplikace a procesory fungující jako softwarové komponenty, které mohou být použity v aplikacích. Procesor je postaven na parseru, který umožňuje načíst XML a XSLT za použití DOMu9 a následně aplikovat XSLT na XML. Další možností je procesor založený na SAX10 . Výpis 1.5: Příklad XML dokumentu 1 2 3 4 5

< produkty > < prodkt typ = ’ sluzba ’ > Kodovani < produkt typ = ’ produkt ’ druh = ’ smes ’ > Kava

DSSSL je kompatibilní se SGML. 8 XML slovník (angl. XML vocabulary) je sada XML elementů, které byly definovány k určitému účelu. XHTML je příkladem XML slovníku. 9 DOM (Document Object Model) je objektově orientovaná reprezentace XML nebo HTML dokumentu. Umožňuje přístup nebo modifikaci obsahu, struktury či stylu dokumentu. 10 SAX (Simple API for XML) umožňuje sériový přístup k XML. Jedná se o proudové zpracování, při kterém se dokument rozdělí na jednotlivé části (počáteční a koncové elementy, obsahy elementů atd.). Pří průchodu se volají události, které ohlašují nalezení konkrétní části.

16

1.4. XSLT procesor

Obrázek 1.5: XSLT procesor – základní schéma [10]

Obrázek 1.6: XSLT procesor – průchod stromem [16]

Obrázek 1.6 reprezentuje stromovou strukturu XML příkladu z Výpisu 1.5. Kruhy představují elementy, kosočtverce atributy a obdélníky hodnoty atributů. Kruhům a kosočtvercům se říká uzel. Když je tento strom transformován za pomoci XSLT, začne procesor kořenovým uzlem a prochází strom ve směru znázorněným šipkami. Poté, co procesor narazí na uzel, podívá se na pravidlo XSLT dokumentu odpovídající jménu a lokaci konkrétního uzlu. Jestliže takové pravidlo existuje, pak ho na uzel aplikuje. Průběh XSLT je podobný událostmi řízeném (event-driven) průběhu. U tohoto typu průběhu určuje událost sekvenci spouštění kódu. V XSLT je sek17

1. Webové služby a XML vence určena daty, což znamená, že kód je spuštěn, pokud procesor narazí na určitá data. Výpis kódu 1.6 obsahuje příklad XSLT dokumentu, který může být použit na transformaci XML produktů (Výpis kódu 1.5). Obsahuje čtyři pravidla určující, zda má být kód spuštěn. Výpis 1.6: Příklad XSLT dokumentu 1 2 3 4 5

< xsl:stylesheet version = ’ 1.0 ’ xmlns:xsl = ’ http: // www . w3 . org /1999/ XSL / Transform ’ > < xsl:output method = ’ text ’ encoding = ’UTF -8 ’ omit - xml - decleration = ’ yes ’ / >

6 7 8 9

< xsl:template match = ’/ ’ > < xsl:apply - templates / >

10 11 12 13

< xsl:template match = ’ produkty ’ > < xsl:apply - templates / >

14 15 16 17 18

< xsl:template match = ’ produkt ’ > < xsl:value - of select = ’ @typ ’ / > je < xsl:value - of select = ’. ’ / >. < xsl:apply - temlates select = ’ @druh ’ / >

19 20 21 22

< xsl:template match = ’ produkt ’ > Tato < xsl:value - of select = ’ .. ’ / > je < xsl:value - of select = ’ . ’ / >.

Výsledek XSLT transformace (Výpis kódu 1.6) aplikované na XML dokument s produkty (Výpis kódu 1.5) je znázorněn ve Výpisu kódu 1.7. Výpis 1.7: Výsledek aplikace XSLT na XML 1

kodovani je sluzba .

2 3 4

Kava je produkt . Tato kava je smes .

První pravidlo <xsl:template match=’/’> je aplikováno na začátku transformace, protože odpovídá kořenovému elementu. Uvnitř tohoto pravidla je příkaz <xsl:apply-templates />, který říká procesoru, aby šel na všechny potomky uzlu nebo na všechny uzly podstromu. Procesor jde z uzlu produkty na uzel produkt a spustí příslušnou šablonu, která už produkuje první výstup. Druhý potomek uzlu je zpracován stejným pravidlem a dostane se na atribut druh. Výstup je rozdílný pro každý produkt, protože první produkt kódování nemá atribut druh. Pokud tedy neexistuje element nebo atribut odpovída18

1.5. Anatomie procesoru Saxon jící nějakému pravidlu, nestane se nic. Pokud však existuje, je dané pravidlo spuštěno. To je hlavní podstatou XSLT transformace. [16]

1.5

Anatomie procesoru Saxon

Saxon je XSLT a XQuery procesor. Existuje jak komunitní open-source, tak i komerční closed-source verze. Komunitní verze, označená Saxon-HE podporuje XSLT 2.0, XPath 2.0 a XQuery 1.0. Komerční verze navíc podporují např. XSLT 3.0, XPath 3.0, XQuery 3.0 a XML Schema 1.0 a 1.1. Saxon implementuje interface TrAX. Hlavní komponenty jsou zobrazeny na Obrázku 1.7. Konstruktor vytvoří reprezentaci stromu ze zdrojového XML a XSL dokumentu. Konstruktor obsahuje dvě části. První částí je XML parser, který čte zdrojový dokument a notifikuje události jako je výskyt počátečního či koncového element. Druhou částí je tree builder, který je notifikován parserem a vytváří stromovou reprezentaci uloženou v operační paměti. Komunikaci mezi parserem a tree builderem zprostředkovává Java SAX2 API. Přestože SAX2 nebyl nikdy plně standardizován, mnoho parserů jej implementuje, což umožňuje využití těchto parserů spolu se Saxonem. Navigátor stromu umožňuje aplikacím vybírat uzel ze stromu pomocí navigace po jeho hierarchii. Na rozdíl od mnoha jiných XSLT procesorů, nepoužívá Saxon model DOM pro vnitřní reprezentaci stromu. Namísto toho implementuje svoji vlastní proprietární implementaci. To umožnilo zvýšit rychlost tohoto procesoru z mnoha důvodů. DOM je složité namapovat na reprezentaci XPath a navíc obsahuje velké množství synchronizačního kódu kvůli zabezpečení přístupu více vláken. Vzhledem k tomu, že parsovací model XSLT je „zapiš jednou“ a „čti mnohokrát“, synchronizační logika může být jednodušší a díky tomu i navigace po stromové hierarchii rychlejší. To jsou však jen některé nevýhody modelu DOM oproti proprietární implementaci Saxonu. Stylesheet kompilátor analyzuje XSLT styl před jeho spuštěním. Nevytváří spustitelný kód, ale dekorovaný strom, ve kterém jsou analyzovány a parsovány výrazy XPath. Dále jsou zpracovány všechny křížové reference, sloty zásobníkových rámců jsou předalokovány atd. Stylesheet kompilátor tedy vytváří rozhodovací strom, který je využit v čase běhu pro výběr správného pravidla šablony ke zpracování každého vstupního uzlu. Jádrem procesoru Saxon je Stylesheet interpreter. Tento interpret využívá dekorovaný strom, aby mohl řídit samotné zpracování. Toto zpracování funguje velmi podobně způsobu zpracování popsaném v předchozí kapitole. [11]

1.6

Saxon a zpracování velkých XML dokumentů

V případě, že je vstupní soubor příliš velký na to, aby ho bylo možné udržovat v paměti, poskytuje Saxon streamovcí mód. Tato verze je však dostupná 19

1. Webové služby a XML

Obrázek 1.7: Anatomie procesoru Saxon [11]

pouze v komerční enterprise verzi označené Saxon-EE11 . Během streamování jsou data zpracovávána v průběhu čtení dokumentu XML parserem, aniž by bylo nutné vytvářet kompletní stromovou reprezentaci dokumentu v paměti. Některé funkce jsou implementovány v návrhu XSLT 3.012 , některé jsou specifické pro Saxon a několik z nich je rovněž dostupných v XQuery. Je zřejmé, že ve streamovacím módu jsou operace, které není možné vykonat. Takovou operací je například řazení. Dosažení transformace za využití streamování většinou znamená, že je nutné zcela změnit přístup k problému. Úvahou nad principem stramování můžeme vyvodit závěr, že by mohlo být vhodné transformaci rozdělit do několika fází. Při přechodu na streamovací mód tedy s velkou pravděpodobností nevyužijeme dosavadní kód. 11

Individuální licence Saxon Enterprise Edition činí v době psaní této práce 300 £. Distribuovatelná verze (teoreticky využitelná v této práci) pak 12 000 £. 12 XSLT 3.0 je též známé jako XSLT 2.1.

20

1.7. Parsování XML dokumentů V Saxonu existují dvě možnosti streamování. Burst mód a Streamovací šablony. Při Burst módu je transformace velkého souboru rozdělena na sekvenci transformací malých částí souboru. Z každé části je postupně vytvořen malý strom uložený v paměti, ten je dále transformován a uložen do výstupního souboru. Tento přístup funguje dobře v případě, že nemáme příliš zanořený XML dokument. Příkladem vhodného souboru je log obsahující miliony záznamů za předpokladu, že zpracování každého záznamu je nezávislé na ostatních záznamech. Mód Streamovací šablony funguje jako tradiční zpracování XSLT, které se provádí rekurzivním, sestupným procházením XML hierarchie a aplikováním pravidel šablon na uzly v příslušných úrovních. Provádí se ale pouze sekvenčně jeden element po elementu bez nutnosti vytvářet strom uložený v paměti [15].

1.7

Parsování XML dokumentů

Účelem parsování XML dokumentů je přístup k jejich obsahu. Existuje několik různých přístupů: • Document Object Model (DOM), • Simple API for XML (SAX), • Streaming API for XML (StAX), • Transformation API for XML (TrAX). Je důležité, aby pro konkrétní případ byl zvolen správný přístup. V opačném případě může být parsování příliš složité na implementaci nebo náročné na operační paměť. Tabulka 1.2 shrnuje základní vlastnosti jednotlivých přístupů.

1.7.1

Document Object Model (DOM)

Document Object Model (DOM) je standardní API pro dokumenty XML a HTML definované konsorciem W3C. Definuje logickou strukturu dokumentu a způsob, jak k dokumentu přistupovat a manipulovat s ním. Pomocí DOMu lze programově vytvářet dokumenty, procházet jejich strukturou, přidávat, modifikovat a mazat elementy, atributy, komentáře a obsah. [13] DOM představuje API založené na stromové struktuře (Tree-based API). Tento typ API je využitelný v mnoha různých aplikacích, problematická je však jejich paměťová náročnost v případě, že je dokument velmi rozsáhlý. Stromová struktura, která je několikanásobně větší než samotný dokument, je uložena v paměti. [29] 21

1. Webové služby a XML Tabulka 1.2: Porovnání vlastností XML parserů [22] Vlastnost

StAX

SAX

DOM

TrAX

Pull str.

Push str.

In mem. tree

pravidlo XSLT

vysoká

střední

vysoká

střední

ne

ne

ano

ano

dobrá

dobrá

různá

různá

Pouze dopředné

ano

ano

ne

ne

Čtení XML

ano

ano

ano

ano

Zápis XML

ano

ne

ano

ano

CRUD

ne

ne

ano

ne

Typ API Jednoduchost XPath Výkonnost

1.7.2

Simple API for XML (SAX)

SAX je API založené na událostech (event-based API). Parser prochází dokument od začátku do konce a hlásí výskyty začátků a konců elementů a atributů. Během parsování nevytváří stromovou reprezentaci. Event-based API pracuje na nižší úrovni než tree-based API a je schopné zpracovat výrazně větší dokumenty než je dostupná velikost operační paměti. V případě, že by úkolem bylo vyhledat element obsahující zadané slovo, bylo by neefektivní vytvářet celý XML strom, zvlášť v případě, že by jeho velikost převyšovala třeba 20 MB. Event-based API by bylo pro tento úkol vhodnější. Výpis 1.8 zobrazuje XML dokument a výstup ze SAX parseru. Jednotlivé události jsou ohlašovány podle pořadí výskytu v dokumentu. Obsažen je i začátek a konec dokumentu, elementy a samotný textový obsah. Výpis 1.8: XML dokument a výpis ze SAX parseru 1 2 3 4

< doc > < para > Hello , world !

5 6 7 8 9 10 11 12

[29] 22

start document start element: doc start element: para characters: Hello , world ! end element: para end element: doc end document

1.7. Parsování XML dokumentů

1.7.3

Streaming API for XML (StAX)

Hlavním cílem parseru StAX je poskytnout programovou kontrolu nad parsováním. Toho je dosaženo jednoduchým API založeným na parseru. Programátor se tak může dotázat na další událost (pulling). StAX byl vytvořen proto, aby adresoval některé nedostatky DOM a SAX API. Nejčastější případy užití parseru StAX zahrnují: • Data binding – marshalling XML dokumentů – unmarshalling XML dokumentů – paralelní zpracování dokumentů – bezdrátová komunikace • Zpracování zpráv SOAP – parsování jednoduchých předvídatelných struktur – parsování reprezentací grafu s dopřednými referencemi – parsování WSDL • Virtuální datové zdroje – XML databáze – navigace po DOM stromu jako stream událostí – parsování WSDL • Parsování konkrétních slovníků XML • Proudové zpracování XML [22]

1.7.4

Transformation API For XML (TrAX)

TrAX je Java API pro vykonávání XSLT transformací. Je dostatečně nezávislé na parseru, a proto může být použito s mnoha různými XSLT procesory, jako je Xalan nebo Saxon. Rovněž je dostatečně nezávislé na modelu, a umožňuje tak transformaci z nebo do XML streamů, sekvenčních událostí SAX nebo stromů DOM a JDOM. TrAX je standardní součástí JAXP, v Javě je obsaženo od verze 1.4. Většina současných XSLT procesorů TrAX podporuje. [24] 23

1. Webové služby a XML

1.7.5

Parsování velkých XML souborů

Při zpracování XML dokumentů je obvykle nejvhodnější načíst celý dokument za použití DOM parseru a následně se na dokument odkazovat pomocí XPath dotazů. Při zpracování velkých dokumentů to ale není nejlepší varianta, protože je příliš náročná na operační paměť. Pokud bychom zpracovávali soubor o velikosti 1 GB, jeho reprezentace v DOMu by zabrala více než 3 GB. Náklady na produkční server by byly příliš veliké a při běhu na lokálním počítači by zpracování nemuselo být vůbec reálné. Řešení tohoto problému spočívá ve využití SAX, resp. StAX parseru. Ten vyžaduje malé množství paměti po celou dobu parsování. Při parsování komplexního XML dokumentu je ale implementace velmi nepřehledná a složitá. Pro zachování malého množství paměti a jednoduché implementace je vhodné zkombinovat DOM a SAX. V daný okamžik se obvykle zpracovává pouze jediný produkt. DOM reprezentaci proto stačí vytvořit pouze pro malou část, tu zpracovat a vytvořit další reprezentaci. Ve Výpisu 1.9 je příklad XML dokumentu, kde pro zpracování není nutná celá reprezentace DOMu najednou. Při zpracování produktu obvykle potřebujeme pracovat pouze s jedním produktem najednou. Nalezení nového produktu je dosaženo SAX parserem, který je následně převeden do reprezentace DOMu. Výpis 1.9: XML dokument, kde není nutná celá reprezentace najednou 1 2 3 4 5 6 7 8 9 10 11 12

< prestashop > < product > < reference > espirito - cafe -15 < name > Espirito Cafe Espresso < price > 250 < product > < reference > espirito - cafe -17 < name > Espirito Cafe Tarazzu < price > 320

Tímto způsobem je možné zpracovat XML soubory, které jsou i více než 1 GB velké, bez znatelného navyšování paměti. Pro výměnu dat je vhodné využít kompresi ZIP. Java podporuje přímé otevírání a zpracování komprimovaných souborů. Velikost přenášeného souboru se tím sníží na několik desítek GB. [9]

24

Kapitola

Analýza Cílem práce je vytvořit propojení mezi ekonomickým a informačním systémem Pohoda a elektronickým obchodem PrestaShop. Z důvodu kompatibility a uživatelsky přívětivé integrace by mělo propojení využívat API služeb obou systémů. Pohoda obsahuje komunikačního klienta13 Obecný internetový obchod, který umožňuje komunikaci s libovolným internetovým obchodem integrujícím webovou službu dle specifikace tohoto klienta. Komunikace probíhá přes HTTP protokol výměnou XML zpráv. Díky této komunikaci předává Pohoda webové službě data nebo požadavek na data. Webová služba tento požadavek přijme, zpracuje a vytvoří odpověď, kterou předá zpět programu Pohoda. [30] Propojení s PrestaShopem je možné díky RESTful webové službě, která je součástí od verze 1.5. Díky této webové službě je možné získávat, vytvářet, upravovat i mazat prakticky všechny zdroje PrestaShopu. Stejně jako u Pohody probíhá výměna zpráv pomocí jazyka XML. Agenda Obecný internetový obchod v programu Pohoda a webová služba PrestaShopu se jeví jako vhodné prostředky k propojení obou systémů. Ideální způsob, jak toho dosáhnout, je přímé propojení obou systémů. Tato možnost však není reálná, protože komunikace a reprezentace dat je na obou stranách odlišná.

2.1

Volba metodiky

Prvním krokem při tvorbě softwarové aplikace je volba, jakým způsobem bude probíhat životní cyklus vývoje. Metodik existuje celá řada, standardně se však dělí do dvou skupin – klasické a agilní. Klasické metodiky, někdy též pejorativně nazývané rigorózní, jsou založené na sekvenčním modelu. Tento model je založen na předpokladu, že existuje 13 Komunikační klient Obecný internetový obchod je součástí Pohody od verze Říjen, rel. 9600.

25

2

2. Analýza systematický postup, jak dojít od zadání k řešení pomocí řady na sebe navazujících činností, které lze dopředu naplánovat. Klasické metodiky, do kterých řadíme například vodopádový model, jsou považovány za příliš složité, málo účinné, vyžadující velké množství dokumentace, čímž oddalují výslednou implementaci a navyšují celkovou cenu. Agilní metodiky jsou modernější, vycházejí z ortodoxního softwarového inženýrství, ale zároveň boří mnohá dogmata a zažité postupy. Samotnými autory jsou označovány jako metodiky, které umožňují vytvářet software rychleji, pružněji a efektivněji. Základem agilních metodik je inkrementální vývoj s krátkými iteracemi, opakované automatizované testování, častá komunikace se zákazníkem či vytváření pouze takového zdrojového kódu, který je nezbytný k dosažení cíle. Mezi nejpoužívanější agilní metodiky pravděpodobně patří Extrémní programování (XP), Scrum a Test-Driven Development (TDD). [14] [21]

2.1.1

Metodika ICONIX Process

Pro vývoj vlastní aplikace jsem zvolil agilní metodiku ICONIX Process14 . Tato metodika je bezplatná, minimalistická a řízená případy užití. ICONIX Process je rozdělen do dvou vysoce iterativních částí – dynamické a statické. Dynamická část je založena na modelování případu užití a sekvenčních diagramech vycházejících z diagramů robustnosti (zjednodušený komunikační/kolaborativní diagram). Součástí statické části je postupné aktualizování problémové domény, ze které postupně vznikne diagram tříd (viz Obrázek 2.1). [12]

2.1.2

Metodika ICONIX/DDT

Metodika Design-Driven Testing vznikla jako alternativa k metodě Test-Driven Development, které je poměrně pracná a pro mnoho vývojářů koncepčně příliš složitá. Metodika DDT se ubírá směrem, který lze charakterizovat jako „testuj chytřeji, ne obtížněji“ a na rozdíl od TDD, kde se snažíme pokrýt co největší procento kódu, se zaměřuje především na kritické části aplikace. Testování řízené návrhem lze adoptovat do libovolného procesu OOAD, bylo však původně navrženo pro použití s metodikou ICONIX Process. Testování řízené návrhem nabízí okamžitou odezvu, přičemž se ověřuje každý krok v procesu analýzy a návrhu. DDT do velké míry koresponduje s V-modelem. V tomto modelu jsou analýza, návrh a vývoj (na levé straně) spojeny s činností související s testováním (na pravé straně). Modifikace tohoto modelu do DDT je znázorněna na Obrázku 2.2. [26] 14

26

http://iconixprocess.com

2.1. Volba metodiky

Obrázek 2.1: ICONIX Process [12]

Obrázek 2.2: Testování řízené návrhem – V-model [26]

27

2. Analýza Fáze ICONIX/DDT Metodika ICONIX/DDT probíhá ve čtyřech krocích: 1. ICONIX: Podrobné studium obchodních požadavků (funkční, nefunkční požadavky). Diskuse se zákazníkem, tvorba storyboardů a sad požadavků. DDT: Tvorba testovacích případů z požadavků – kritéria přijatelnosti. 2. ICONIX: Tvorba doménového modelu a případů užití. DDT: Automatizované integrační testy. 3. ICONIX: Studium návrhu na předběžné úrovni pro každý z případu užití. Konceptuální návrh se vytvoří z diagramu robustnosti. DDT: Systematické vytváření řadičů15 z diagramů robustnosti. 4. ICONIX: Pečlivé promyšlení implementačních detailů a tvorba sekvenčního diagramu pro každý z případu užití. DDT: Systematické vytváření jednotkových testů. [26]

2.2

Analýza požadavků

Řízení importů a exportů má plně pod kontrolou program Pohoda. Požadavky na systém proto primárně vycházejí z jeho podporované funkčnosti. Tento způsob propojení předpokládá, že se kategorie, produkty a jejich parametry budou vytvářet v Pohodě. Import dat slouží především k získávání informací, které jsou mimo dosah Pohody. Konkrétně jsou to přijaté objednávky z internetového obchodu, adresář registrovaných zákazníků a stav skladových zásob.

2.2.1

Funkční požadavky vycházející ze systému Pohoda

Datová komunikace s obecným internetovým obchodem se spustí kliknutím na Soubor → Datová komunikace → Internetové obchodování. Zobrazí se okno s výběrem internetového obchodu a nabídkou exportu (Odeslat na internet) a importu (Stáhnout z internetu), viz Obrázek 2.3. Mimo tyto dvě možnosti umožňuje Pohoda odeslání obrázků a souvisejících souborů. Tato komunikace probíhá pomocí protokolu FTP, a nemůže tak být přímo propojena s middlewarem. Hlavní výzvou při vytváření požadavků na podobný typ middlewaru je omezený prostor pro vlastní návrh. Propojení jednotlivých agend lze pouze za využití již daných funkcí obou systémů. V této analýze požadavků proto uvádím obecné požadavky bez ohledu na detailní technické možnosti. Tyto požadavky dále rozvedu a upravím na základě podrobného studia v předběžném návrhu. 15

28

Logická softwarová funkce

2.2. Analýza požadavků

Obrázek 2.3: Internetové obchodování Pohoda – úvodní okno

Export dat Export dat by měl podporovat všechny relevantní funkce vzhledem k PrestaShopu. Pohoda využívá pro členění skladových zásob agendu Členění skladů. Každý produkt musí být umístěn do právě jednoho členění, které může být dále zanořené. Tento způsob katalogizace není kompatibilní s běžným internetovým obchodem, který umožňuje vkládat produkty do libovolného počtu kategorií. Možnost začlenit produkt do libovolných kategorií byla nově doplněna i do Pohody, aplikace tak umožňuje dvě nezávislá členění skladů. Spravovat kategorie internetových obchodů v Pohodě lze kliknutím na Nastavení → Internetové obchody → Kategorie internetových obchodů. Přestože v exportu dat existuje nabídka pro odeslání členění skladů i kategorií, budu v middlewaru přijímat pouze kategorie. Členění skladů není v PrestaShopu využitelné. Export dat dále umožňuje filtrování zásob a přijatých objednávek. Toto filtrování je však interní funkcí Pohody, protože middleware přijme XML dokument, který dále zpracuje, aniž by sám prováděl jakékoliv filtrování. Filtrování v exportu proto nezahrnuji mezi funkční požadavky. Užitečnou funkcí by bylo exportování pouze těch skladových zásob, které od své úpravy zatím nebyly odeslány. Tím by se výrazně snížil počet exportovaných produktů, což by mělo velký vliv na rychlost middlewaru a webovou 29

2. Analýza

Obrázek 2.4: Internetové obchodování Pohoda – export dat

službu PrestaShopu. Tuto funkci ale POHODA nenabízí. Nelze ji ani nijak vyřešit na úrovni middlewaru, protože exportované produkty nemají v XML souboru informaci o datu poslední změny. Uživatel si tak musí vystačit s funkcí uživatelských filtrů, díky které lze počet produktů výrazně omezit. Okno se seznamem agend pro export je zobrazeno na Obrázku 2.4. Diagram požadavků pro export popisuje Obrázek 2.5.

Import dat Možnosti importu dat jsou v porovnání s exportem omezené. To je dáno právě tím, že se předpokládá využití Pohody pro správu internetového obchodu namísto její původní administrace. Importovat lze skladové zásoby, adresář a přijaté objednávky (viz Obrázek 2.6). Skladové zásoby a přijaté objednávky je možné ještě dále filtrovat (viz Obrázek 2.7). U zásob je k dispozici výběr dle skladu a členění skladu. Obě možnosti filtrování nejsou v PrestaShopu použitelné, a proto je nebudu dále uvažovat. Přijaté objednávky lze filtrovat dle data od/do. Omezení počtu stažených skladových zásob je podobný problém jako v případě exportu. V tomto případě by však bylo možné tuto funkci doplnit na úrovni middlewaru. Diagram požadavků pro import popisuje Obrázek 2.8. 30

2.2. Analýza požadavků

Obrázek 2.5: Funkční požadavky – export dat

Obrázek 2.6: Internetové obchodování Pohoda – import dat

31

2. Analýza

Obrázek 2.7: Internetové obchodování Pohoda – filtrování importu

Obrázek 2.8: Funkční požadavky – import dat

32

2.2. Analýza požadavků

2.2.2

Nefunkční požadavky

Přenos Pohoda odesílá data výhradně metodou POST. Samotná data jsou odeslána v těle požadavku jako čisté (neenkódované) XML. Stejný formát je vyžadován rovněž při odpovědi. Content-Type musí být nastaven na text/xml. Webová služba PrestaShopu komunikuje pomocí architektury REST, tudíž využívá metody PUT, POST, GET a DELETE. Při použití metody POST musí být tělo zprávy ve tvaru key-value pair. XML je v tomto případě enkódované a internet media type nastaven na application/x-www-form-urlencoded. Klient tak v podstatě předstírá odeslání vzdáleného formuláře. Ostatní metody, tedy PUT, GET a DELETE jsou odesílány běžným způsobem jako čísté (neenkódované) XML s Content-Type nastaveným na text/xml.

Obrázek 2.9: Nefunkční požadavky – přenos

Perzistence Middleware bude umožňovat ukládat uživatelské nastavení, především klíč pro připojení k PrestaShopu a autentizační údaje k Pohodě. Informace o licencích budou uloženy v systému na správu licencí a budou získávány při každé operaci middlewaru. Middleware si bude dále pamatovat historii jednotlivých operací.

Obrázek 2.10: Nefunkční požadavky – perzistence

Bezpečnost Z hlediska bezpečnosti je obecně doporučeno, aby webová služba využívala protokol HTTPS. Díky tomu lze zabránit útokům typu Man in the middle. Při komunikaci s webovými službami PrestaShopu lze přímo v tomto systému zvolit protokol HTTPS. Middleware musí umožňovat nastavení zabezpečeného 33

2. Analýza přenosu pro komunikaci s Pohodou. Tento požadavek se týká pouze middlewaru, který běží na serveru. Komunikace s PrestaShopem je zabezpečená přihlašovacím klíčem pomocí HTTP metody Basic Authentication. Stejnou metodu zabezpečení podporuje i klient Pohody. Middleware musí s tímto typem zabezpečení počítat a využívat ho.

Obrázek 2.11: Nefunkční požadavky – bezpečnost

Výkon Middleware běžící jako lokální služba musí bez problémů fungovat na běžném kancelářském PC. Při komunikaci s Pohodou systém odpoví maximálně do 30 s. Neznamená to však, že by celá operace musela být provedena v tomto čase. Pokud Pohoda očekává pouze informaci o úspěchu či neúspěchu (export dat), je možné data zpracovat asynchronně s tím, že Pohoda obdrží předběžnou informaci o úspěšném provedení operace. U importu je nutné zpracovat celou operaci synchronně. Dodržení tohoto limitu se týká operací do maximálního počtu 50 000 položek. Zároveň by middleware neměl využít více než 128 MB RAM. Samotný export dat musí proběhnout v řádu desítek minut, jinak by byla aplikace pro uživatele nepoužitelná.

Obrázek 2.12: Nefunkční požadavky – výkon

Rozhraní Middleware bude obsahovat uživatelské rozhraní pro přehled licencí, nastavení přenosu, příp. dalších nastavení, jako je podrobnější filtrování importu dat. Rozhraní bude přístupné z webového prohlížeče nebo může být realizováno jako GUI aplikace (pouze u lokální služby). 34

2.3. Případy užití

Obrázek 2.13: Nefunkční požadavky – rozhraní

Dokumentace K systému musí být vytvořena srozumitelná uživatelská příručka. Měla by obsahovat popis správy e-shopu, import a export v Pohodě. Dokumentace musí rovněž obsahovat nastavení PrestaShopu, aby bylo možné využívat webové služby. Stručný popis by měl existovat i pro administraci middlewaru.

Obrázek 2.14: Nefunkční požadavky – dokumentace

2.3

Případy užití

Základní diagram případu užití lze rozdělit na dva průběhy. Prvním průběhem je obecné importování a exportování, druhým pak samotné zpracování požadavku. Importování je přímo závislé na zpracování požadavku, protože jej musí vykonat ještě dříve, než odpoví klientovi. Exportování pouze předá požadavek a klientovi odpoví bez čekání na jeho zpracování. Základní diagram případu užití je znázorněn na Obrázku 2.15.

Obrázek 2.15: Případ užití – základní diagram

35

2. Analýza

2.3.1

Importování/exportování

Případ užití obecné importování/exportování popisuje komunikaci mezi Pohodou a middlewarem. Zabývá se analýzou požadavku a jeho předáním ke zpracování, resp. jeho zamítnutím. Obrázek 2.16 popisuje závislost případu užití na nefunkčních požadavcích.

Obrázek 2.16: Importování/exportování – diagram případu úžití

Základní průběh 1. Uživatel klikne na datovou komunikaci internetového obchodu a vybere typ exportu. 2. Uživatel nastaví filtry pro export a spustí datovou komunikaci. 3. Systém (Pohoda) upraví XML dokument pomocí XSLT procesoru. 4. Systém (middleware) přijme požadavek od uživatele, provede předběžný odhad úspěchu operace a požadavek uloží. 5. Systém (middleware) vyhledá, zda má uživatel platnou licenci pro vybraný internetový obchod. 6. Systém (middleware) odpoví uživateli informací o úspěšném exportu. 7. Systém (middleware) spustí proces exportu. Alternativní průběh 1. Systém (middleware) provede předběžný odhad úspěchu operace a zjistí, že by byla neúspěšná. 2. Systém (middleware) odpoví uživateli informací o neúspěšném exportu. 36

2.4. Analýza a předběžný návrh

2.3.2

Zpracování požadavku

Základní průběh (export) 1. Systém (middleware) stáhne referenční soubor z PrestaShopu. Referenční soubor je výpis položek PrestaShopu a slouží k namapování položek Pohody. 2. Systém (middleware) vytvoří požadavky na PrestaShop na základě referenčního souboru a požadavku z Pohody. 3. Systém (middleware) odešle všechny připravené požadavky PrestaShopu. 4. Systém (PrestaShop) přijme požadavky a zpracuje je. Základní průběh (import) 1. Systém (middleware) odešle požadavek na stažení dat z PrestaShopu. 2. Systém (PrestaShop) získá data a odešle je middlewaru. 3. Systém (middleware) provede předzpracování dat. 4. Systém (middleware) odešle data Pohodě a informuje uživatele. 5. Systém (Pohoda) provede transformaci dat pomocí XSLT procesoru.

2.4 2.4.1

Analýza a předběžný návrh Architektura systému

Pohoda je aplikace určená pro běh na operačním systému MS Windows. Existuje v několika variantách: Pohoda, Pohoda SQL a Pohoda E1, které se dále dělí na podvarianty. Pohoda je určená pro nesíťový provoz, ostatní varianty SQL a E1 využívají pro ukládání dat databázi, jsou proto vhodné jako síťové varianty. V případě, že zákazník potřebuje pracovat s ekonomickým systémem odkudkoliv nebo vyžaduje práci více uživateli zároveň, musí využít síťovou verzi. Ta vyžaduje budování vlastní infrastruktury, alternativně lze využít hosting. Hostování systému Pohoda znamená, že je systém nainstalován v datovém centru na serveru poskytovatele a uživatel přistupuje k programu pomocí vzdáleného připojení. Architektura middlewaru musí tyto varianty brát v úvahu a stejně jako Pohoda nabídne lokální (viz Obrázek 2.17) a síťovou verzi (viz Obrázek 2.18). Lokální verzi bude uživatel spouštět na svém PC spolu s Pohodou. Komunikace bude probíhat pomocí HTTP přes localhost, což musí zajistit lokální, embedovaný server. 37

2. Analýza Síťová verze bude nasazená na serveru v rámci infrastruktury zákazníka, případně na serveru poskytovatele. Propojení s PrestaShopem bude možné z libovolné aplikace připojené na SQL databázi. Uživatel v tomto případě nemusí spouštět žádnou doplňkovou aplikaci na svém PC. Tuto variantu lze využít i pro uživatele lokální verze Pohody, její provoz je ale z důvodu nutnosti vzdáleného serveru dražší.

Obrázek 2.17: Architektura systému – lokální služba

Obrázek 2.18: Architektura systému – síťová služba 38

2.4. Analýza a předběžný návrh

2.4.2

Middleware

Na Obrázku 2.19 je znázorněn diagram robustnosti, který představuje předběžné rozdělení úloh middlewaru do řadičů a jejich vzájemné komunikace. Ta vychází z případu užití a požadavků na systém. Diagram se skládá z části, kterou vykonává systém Pohoda. Ta má na starosti XSLT transformace, komunikaci s webovou službou (middlewarem) a kontrolou odpovědí z webové služby. Druhá část řeší zpracování požadavku v middlewaru. Popisuje postup kontrol, předání požadavku ke zpracování a odpověď Pohodě. V diagramu nejsou znázorněny operace nutné ke zpracování požadavku. Ty jsou specifické pro každý import, resp. export a budou předmětem analýzy v detailním návrhu systému.

Obrázek 2.19: Importování/exportování – diagram robustnosti

39

2. Analýza

2.4.3

Webová služba na kontrolu licencí

Komunikace s dalšími službami Systém na kontrolu licencí bude umožňovat uživatelský přístup z middlewaru. Ten bude omezen pouze na čtení záznamů aktuálně přihlášeného uživatele. Vkládání, upravování a mazání záznamů může zajistit libovolný klient, který implementuje RESTové služby systému. Příkladem takového klienta je například modul do systému ISPConfig, který je běžně používán pro správu uživatelů a jejich hostingových programů. Architektura propojení je naznačena na Obrázku 2.20.

Obrázek 2.20: PPL – problémová doména

Analýza problémové domény Problémová doména obsahuje uživatele zařazené do skupiny. Struktura zákazníků a skupin je vytvořena tak, aby je bylo možné použít jako autentizační realm aplikačního serveru GlassFish. Každý uživatel může obsahovat libovolné množství licencí, které mu umožní využívat sytém pro více elektronických obchodů. Problémová doména je znázorněna na Obrázku 2.21.

Obrázek 2.21: PPL – problémová doména

40

Kapitola

Detailní návrh 3.1

Obecný export

Součástí každého obecného exportu je část sekvenční a část asynchronní. Samotné zpracování dat se provádí asynchronně, díky čemuž může middleware odpovědět Pohodě velmi rychle. Na druhou stranu není zaručeno, že se Pohodě neodešle zpráva o úspěšném provedení v případě, že skutečně dojde k chybě. Tomu částečně předchází sekvence kontrol, které jsou provedeny před odesláním odpovědi uživateli. Poté, co zákazník provede export, dojde k vygenerování XML dokumentu. Tento XML dokument zpracuje XSLT procesor Pohody a již upravený se odešle metodou POST middlewaru. Ten nejprve zkontroluje autentizaci Pohody. Kontrola autentizace má ale smysl pouze v případě, že systém běží na vzdáleném serveru. Systém dále ověří, zda je cílový PrestaShop dostupný (provede se ping) a zda má uživatel oprávnění využívat webové služby. Nakonec se ověří platnost uživatelské licence pro daný PrestaShop. Architektura je navržená tak, aby bylo jednoduché přidávat nové kontroly nebo měnit jejich pořadí. Diagram aktivit zobrazující průběh zpracování kontrol je uveden na Obrázku 3.1.

Obrázek 3.1: Kontrola exportu – diagram aktivit

41

3

3. Detailní návrh

Obrázek 3.2: Obecný export – sekvenční diagram

Pohoda nemá přesně definovanou datovou strukturu odpovědi z webové služby. Aby vyhodnotila export jako úspěšný, musí webová služba odpovědět XML dokumentem, který obsahuje element s atributem @state nastaveným na hodnotu ok. Ukázka odpovědi viz Výpis 3.1. Oznámení o chybném exportu může být např. realizováno nastavením atributu @state na hodnotu error. Sekvenční diagram popisující obecný export je zobrazen na Obrázku 3.2. Výpis 3.1: Odpověď od middlewaru při exportu 1 2 3 4 5

42

< rsp:responsePack version = ’ 1.0 ’ id = ’ 00000001 ’ state = ’ ok ’ application = ’ Transformace ’ note = ’ odpoved z e - shopu ’ xmlns:rsp = ’ http: // www . stormware . cz / schema / response . xsd ’ >

3.2. Export internetových kategorií

3.2

Export internetových kategorií

Při vytváření nové kategorie v PrestaShopu je nutné znát ID nadřazené kategorie. Vzhledem k tomu, že PrestaShop a Pohoda nedokáží sdílet stejné ID (generují se automaticky), je nutné jej získat pro každou nově vytvářenou kategorii. Nemožnost sdílet ID přináší ještě jeden problém – kategorie Pohody nemohou být přesně namapovány na kategorie PrestaShopu a je nutné vytvořit určité omezení, díky kterému bude možné vždy exaktně určit, o kterou kategorii se jedná. PrestaShop i Pohoda umožňují vytvářet kategorie se stejným názvem a to i v případě, že sdílí stejnou nadřazenou kategorii. Pokud ale kategorie nemohou sdílet stejné ID, je propojení takovýchto kategorií logickým problémem. Řešením tohoto problému je povolení pouze unikátních názvů těch kategorií, které mají stejnou nadřazenou kategorii. Z praktického hlediska by se nemělo jednat o významné omezení, protože dvě kategorie se shodným názvem nedávají příliš smysl. Vytváření nových kategorií probíhá v několika fázích. Není možné vytvářet všechny kategorie najednou, protože v době vytváření nemusí být známy všechny ID nadřazených kategorií. Z tohoto důvodu se vytvoří nejprve kategorie nejvyšší úrovně, následně middleware požádá o stažení seznamu všech kategorií z PrestaShopu. Ty již obsahují ID všech nadřazených kategorií. Tímto způsobem se pokračuje až do nejvíce zanořené kategorie. Aby bylo zpracování co nejrychlejší, je vytvořen XML dokument (pomocí XSLT transformace), obsahující elementy category2–cateogryx (Výpis 3.2). To umožňuje využít SAX parser, který pro každou úroveň prochází celý dokument a v případě, že nalezne požadovaný element (např. category4), dojde k vytvoření struktury DOM pro tuto kategorii (Výpis 3.3). Čísla u elementů kategorií odpovídají zanoření v PrestaShopu. Nejvyšší úroveň v PrestaShopu má název „Home“ a hloubku zanoření 1 (Výpis 3.4). Kategorie z Pohody jsou zanořeny do této kategorie, proto první element začíná názvem category2. Sekvenční diagram pro zpracování internetových kategorií je popsán na Obrázku 3.3. Výpis 3.2: Základní kostra XML dokumentu pro export kategorií 1 2 3 4 5

< categories > < category2 > ... < category3 > ... < category4 > ...

Výpis 3.3: Detail kategorie pro export 1 2 3

< category4 > < parent > Kava < level_depth >4

43

3. Detailní návrh 4 5 6

< name > Arabika < description > arabika popis

Výpis 3.4: XML dokument kategorií ve formátu PrestaShopu 1 2 3 4 5 6 7 8 9 10 11 12

< prestashop xmlns:xlink = ’ http: // www . w3 . org /1999/ xlink ’ > < category > < id >2 < id_parent >1 < level_depth >1 < is_root_category >1 < name > Home ... < category > ...

Obrázek 3.3: Zpracování internetových kategorií – sekvenční diagram

44

3.3. Export skladových zásob

3.2.1

Seznam HTTP požadavků nutných pro export internetových kategorií

Počet požadavků při exportu kategorií závisí na hloubce zanoření. Pro každou úroveň dojde k požadavku na stažení seznamu kategorií z PrestaShopu, k odeslání nových a aktualizování existujících kategorií. Seznam požadavků je popsán v následující Tabulce 3.1. Tabulka 3.1: Seznam HTTP požadavků pro export kategorií

3.3

Požadavek

Zdroj

Cíl

Poznámka

1× POST

PO

MID

Export kategorií z Pohody

hloubka× GET

MID

PS

Seznam kategorií z PrestaShopu

hloubka× POST

MID

PS

Aktualizace kategorií

hloubka× PUT

MID

PS

Vytvoření nových kategorií

Export skladových zásob

Stejně jako u kategorií není možné sdílet ID produktů. Proto je třeba najít alternativní způsob jejich propojení. Jednou z možností je využít kód zboží, u kterého sice není vyžadována unikátní hodnota, ale z hlediska použitelnosti by unikátní hodnota neměla představovat žádný problém. Na základě kódů zboží middleware určí, zda je produkt v PrestaShopu obsažen a na tomto základě vytvoří dva požadavky – na vytvoření a na aktualizování exportovaných produktů. U každého produktu je nutné zjistit ID všech kategorií, do kterých je zařazen. K tomu jsou zapotřebí dva soubory – exportní soubor kategorií z Pohody a seznam všech kategorií z PrestaShopu. Tyto dva soubory jsou vytvořeny během exportu kategorií, a proto je nutné tento export provést před exportem skladových zásob. Získání ID kategorií PrestaShopu probíhá tak, že se z detailu produktu vezmou ID kategorií Pohody a pomocí nich se z exportního souboru Pohody získá: • název (XPath: //categories/*[id=5]/name/text()) a • zanoření kategorie (XPath: //categories/*[id=5]/depth/text()). Pomocí názvu a zanoření kategorie je pak možné získat požadované ID ze seznamu kategorií PrestaShopu (XPath: //prestashop/categories/category [level_depth="3"and name/language="Káva"]/id/text()). Sekvenční diagram zpracování produktů je uveden na Obrázku 3.4. 45

3. Detailní návrh

Obrázek 3.4: Zpracování produktů – sekvenční diagram

46

3.4. Import skladových zásob

3.3.1

Seznam HTTP požadavků nutných pro export produktů

Export produktů je velmi nenáročný na počet HTTP požadavků. PrestaShop umožňuje vytváření, resp. aktualizování produktů pomocí jednoho požadavku. Seznam všech požadavků zobrazuje Tabulka 3.2. Tabulka 3.2: Seznam HTTP požadavků pro export produktů

3.4 3.4.1

Požadavek

Zdroj

Cíl

Poznámka

1× POST

PO

MID

Export produktů z Pohody

1× GET

MID

PS

Seznam produktů z PrestaShopu

0–1× POST

MID

PS

Aktualizace produktů

0–1× PUT

MID

PS

Vytvoření nových produktů

Import skladových zásob Import z hlediska Pohody

Agenda pro import skladových zásob umožňuje vytváření nových a editaci současných položek. Import probíhá tak, že Pohoda odešle middlewaru požadavek o stažení produktů. Tento požadavek může obsahovat definici filtru, díky kterému middleware aktualizuje/vytvoří pouze některé produkty. Požadavek na stažení všech zásob je ve Výpisu 3.5. Výpis 3.5: Požadavek na stažení všech zásob 1 2 3 4 5 6 7 8 9 10 11 12

< dat:dataPack > < dat:dataPackItem id = ’ a55 ’ > < lS tk:l istS tockR eque st > < lStk:requestStock > < ftr:filter >

Navzdory dokumentaci Pohody, která zmiňuje možnosti filtrovat zásoby podle konkrétního kódu zásoby a na stažení nových zásob, umožňuje samotná aplikace filtrovat pouze podle členění a skladů. Rozhodnutí o tom, jestli se má vytvořit nový nebo editovat současný produkt závisí na definici elementu stk:actionType. Pokud se má vytvořit nový 47

3. Detailní návrh produkt, musí element stk:actionType obsahovat prázdný element stk:add (viz Výpis 3.6), v případě aktualizace pak neprázdný element stk:update (viz Výpis 3.7). Při aktualizaci je nutné určit, ke kterému produktu se nové informace váží. Pohoda je v této oblasti velmi flexibilní, umožňuje totiž zvolit libovolnou kombinaci vlastností, které se musí shodovat. Tato definice je uvedena v elementu ftr:filter. Pro tuto aplikaci jsem zvolil propojení na základě kódu zboží. Výpis 3.6: Vytvoření produktu v Pohodě 1 2 3

< stk:actionType > < stk:add / >

Výpis 3.7: Aktualizace produktu v Pohodě 1 2 3

< dat:dataPackItem > < stk:stock >

4

< stk:actionType > < stk:update > < ftr:filter > < ftr:code > B04

5 6 7 8 9 10 11 12 13 14 15 16 17

< stk:stockHeader > ...

3.4.2

Import z hlediska middlewaru

Middleware získá od PrestaShopu produkty (pouze ty, které mají datum aktualizace vyšší, než je datum posledního importu) a v nezměněné podobě by je mohl předat Pohodě, která by je zpracovala pomocí XSLT transformace. Pokud by měl XSLT procesor k dispozici datum posledního importu, mohl by rozhodnout, zda se jedná o vytvoření nového nebo aktualizaci stávajícího produktu a podle toho sestavit XML dokument pro import. Toto datum si pamatuje middleware, XSLT procesor ho ale musí nějakým způsobem získat. Mezi standardní funkce XSLT 2.0 patří XPath dotazování nad vzdálenými dokumenty. Příklad takového volání je ve Výpisu 3.8. Pokud by vzdálený soubor date.xml obsahoval data jako ve Výpisu 3.9, bude proměnná $date obsahovat čas 2014-03-14T23:12:50 (standardizovaný tvar). 48

3.5. Wrapper pro lokální běh middlewaru

Obrázek 3.5: Postupné zpracování XML dokumentu při importu produktů

Výpis 3.8: XSLT dotaz pro vzdálené použití XPath dotazu 1

< xsl:variable name = ’ date ’ select = ’ document ( ’ http: // localhost:8080 / import / date . xml ’) / date / text () ’/ >

Výpis 3.9: XML dokument s datem (date.xml) 1 2

< date > 2014 -03 -14 T23:12:50

Problém tohoto přístupu je v tom, že XSLT procesor Pohody neumožňuje všechny standardní funkce16 . Čtení vzdálených souborů tak skončí prázdným řetězcem. Řešením tohoto problému je obohacení XML souboru o dodatečné informace před odesláním Pohodě. Takovou operaci zvládne nejlépe opět XSLT procesor, např. Saxon, který bude součástí middlewaru. Postup zpracování XML dokumentů procesorem v middlewaru a v Pohodě je ilustrován na Obrázku 3.5. Na počátku jsou vždy potřeba dva dokumenty – zdrojový soubor a XSLT dokument v middlewaru. Takto upravený soubor je odeslán klasickým způsobem Pohodě, která upraví jeho strukturu pomocí dalšího XSLT procesoru.

3.5

Wrapper pro lokální běh middlewaru

Wrapper pro lokální běh middlewaru je GUI aplikace, která spouští embedovaný Tomcat 7 a kontroluje platnost licencí. Wrapper musí zobrazit uživateli základní informace o stavu běhu aplikace. Aplikace využívá několika vláken. Je to vlákno pro běh GUI (Swingu), vlákno pro spouštění/testování serveru a vlákno pro běh Tomcatu. Díky tomu, 16

XSLT procesor Pohody ani podporované funkce nejsou v dokumentaci uvedeny.

49

3. Detailní návrh

Obrázek 3.6: Sekvenční diagram spouštění wrapperu 1

že spouštění serveru běží v samostatném vlákně, může být GUI okno spuštěno okamžitě bez závislosti na další aplikační logice. Na Obrázku 3.6 a 3.7 jsou zobrazeny sekvenční diagramy, které popisují proces spouštění a kontrol aplikace. Po spuštění GUI dojde ke startu kontejneru Tomcat (viz Obrázek 3.6). Ten je následně otestován, zda vrací HTTP status kód 200 OK na úvodní stránku. O úspěchu či neúspěchu je uživatel informován prostřednictvím GUI aplikace (Informační panel, viz Obrázek 3.8). Po úspěšném testu Tomcatu stáhne aplikace aktivní licence pro PrestaShopy, se kterými smí aplikace komunikovat (Obrázek 3.7). Ty jsou následně vypsány v pravém okně GUI aplikace (Aktivní licence). Uživatel je opět informován, zda bylo stažení licencí úspěšné. Ze stažených licencí jsou získány URL adresy PrestaShopů, které jsou otestovány, zda jsou dostupné (vrací HTTP status kód 200 OK) a zda má uživatel oprávnění přistupovat k jejich webovým službám. 50

3.5. Wrapper pro lokální běh middlewaru

Obrázek 3.7: Sekvenční diagram spouštění wrapperu 2

Obrázek 3.8: GUI okno pro běh lokálního middlewaru

51

Kapitola

Implementace 4.1

Zabezpečení RESTových služeb

Při implementaci zabezpečení webových služeb existují v podstatě dvě možnosti realizace. Vytvoření vlastní bezpečnostní aplikace nebo využití zabezpečení, které poskytuje aplikační server. Preferovaná je druhá možnost, protože se u ní dá předpokládat vyšší bezpečnost a vyžaduje pouze velmi málo kódování. Zabezpečení webových služeb je rozděleno na autentizaci a autorizaci. Při autentizaci se ověřuje identita uživatele. Autorizace slouží k ověření, zda má uživatel oprávnění přístupu k určitému zdroji nebo zda smí vykonat požadovanou operaci. GlassFish podporuje pro zabezpečení několik realmů. Mezi ně patří např. zabezpečení pomocí certifikátu, JDBC, souboru nebo LDAP. Pro účely této aplikace se jeví jako nejvhodnější JDBC, tedy zabezpečení pomocí databázové tabulky. Vytvoření nového realmu se provádí ve webové administraci GlassFishe (viz Obrázek 4.1). Je k tomu zapotřebí vytvořit JDBC zdroj a connection pool. Databáze musí obsahovat tabulku pro uživatele a tabulku pro skupiny uživatelů. Nově vytvořený realm má své unikátní jméno a lze s ním pracovat ve vlastní aplikaci.

4.2 4.2.1

Middleware Použité technologie

Aplikační server Aplikace je napsaná v jazyku Java (JDK 7), nasazená na embedovaném kontejneru Tomcat 6. Volba samotného kontejneru namísto celého aplikačního serveru je dána nutností běhu v embedovaném prostředí. Přestože všechny známé aplikační servery (TomEE, GlassFish, JBoss aj.) mají embedovanou verzi, jejich implementace je výrazně slo53

4

4. Implementace

Obrázek 4.1: Vytvoření realmu v administraci GlassFishe

žitější. Tomcat má navíc rychlejší start a je datově podstatně menší. Na rozdíl od běhu na serveru, kde rychlost startu a velikost instalace nehraje takovou roli, jsou v embedovaném prostředí tyto vlastnosti velkou předností. RESTový klient Pro komunikaci s PrestaShopem a serverem na kontrolu licencí jsem použil RESTového klienta Jersey 1.13. XSLT procesor Pro operace, které nelze provést v XSLT procesoru Pohody jsem použil Saxon-HE 9.4 ve verzi pro Javu.

4.2.2

HTTP Servlet

Pro přijetí HTTP požadavku od Pohody využívá middleware Servlet 3.0 API. Třída HttpServlet obsahuje metodu doPost, která přijímá metody POST (žádné jiné HTTP metody middleware nepřijímá). Vstupními parametry do této metody jsou instance tříd HttpServletRequest a HttpServletResponse. Pomocí instance HttpServletRequest je možné přistoupit ke streamu hlaviček a těla požadavku. Middleware umožňuje v jeden okamžik přijmout a zpracovat pouze jeden požadavek. V případě, že je aktivní vlákno, které požadavek zpracovává, bude middleware vracet odpověď s chybovou hlášku v těle: HTTP/1.1 200 OK Content-Type: application/xml 54

4.3. Webová služba na kontrolu licencí

4.2.3

Zdroje pro export

Middleware implementuje následující zdroje pro export: POST /export/products – export skladových zásob, POST /export/categories – export kategorií, POST /export/orders – export objednávek, POST /export/customers – export zákazníků.

4.2.4

Zdroje pro import

Middleware implementuje následující zdroje pro import: POST /import/products – import produktů, POST /import/orders – import objednávek, POST /import/customers – import zákazníků.

4.3 4.3.1

Webová služba na kontrolu licencí Použité technologie

Aplikační server Aplikace je napsaná v jazyku Java (JDK 7), nasazena na aplikačním serveru GlassFish. Perzistence Pro objektově relační mapování (ORM) entit na databázi je využitý framework JPA (Java Persistence API). XML Binding Mapování entit na XML (a opačně)17 je realizováno pomocí frameworku JAXB (Java Architecture for XML Binding). Webové služby Vytvoření webových služeb zajišťuje JAX-RS (Java API for RESTful Web Services). EclipseLink Automatické propojení JPA, JAXB a JAX-RS má na starosti framework EclipseLink. Databáze Aplikace je schopna běžet prakticky na libovolné databázi, která obsahuje JDBC ovladač. Zvolená databáze byla v tomto případě MySQL s JDBC ovladačem Connector/J. 17

Též marshalling/unmarshalling.

55

4. Implementace

4.3.2

Prostředky pro běh aplikace

Hardware Aplikace je nasazena na virtuálním serveru s parametry: • Procesor – AMD E-350 Processor 1,6 GHz, single core • Operační paměť – 256 MB RAM Operační systém Na virtuálním serveru je nainstalován operační systém Debian GNU/Linux 6.0, 64 bit.

4.3.3

Podporované RESTové metody – skupina USER

Skupina USER je určena výhradně pro získání licencí přihlášeného uživatele. URI zdroje s uživatelem není obohaceno o konkrétního uživatele, ten se bere z uživatelského jména zadaného v HTTP hlavičce. Zdroj uživatele (/api/customer) OPTIONS /api/customer – seznam všech podporovaných metod s popisem ve formátu WADL a XSD. GET /api/customer – získá informace o přihlášeném uživateli, včetně všech jeho licencí. Příklad HTTP požadavku: GET http://glassfish.zserver.cz:8080/PPL/api/customer \ HTTP/1.1 Host: glassfish.zserver.cz:8080 Authorization: Basic a296YWsudkBnbWFpbC5jb206dm9qdGE= Příklad HTTP odpovědi: HTTP/1.1 200 OK Content-Type: application/xml <customers> <customer> <customer>[email protected] espirito.cz [email protected] 1 56

4.3. Webová služba na kontrolu licencí

4.3.4

Podporované RESTové metody – skupina ADMIN

Zdroj uživatele (/api/customer) Ve všech požadavcích, kde není uveden příklad HTTP odpovědi, vrací server stavový kód 204 No Content. POST /api/customer – vytvoří nového zákazníka. Při vytváření zákazníka je možné zadat všechny jeho licence. Příklad HTTP požadavku: POST http://glassfish.zserver.cz:8080/PPL/api/customer \ HTTP/1.1 Content-Type: application/xml <customer> [email protected] password espirito.cz PUT /api/customer – aktualizuje existující zdroj. V případě, že v těle XML není zadané ID, je zdroj vytvořen. Příklad HTTP požadavku: PUT http://glassfish.zserver.cz:8080/PPL/api/customer \ HTTP/1.1 Content-Type: application/xml <customer> 1 [email protected] password DELETE /api/customer/{id} – vymaže uživatele s ID zadaným v URI. Příklad HTTP požadavku: DELETE http://glassfish.zserver.cz:8080/PPL/api/customer/3 \ HTTP/1.1 57

4. Implementace Host: glassfish.zserver.cz:8080 Authorization: Basic dm9qdGE6dm9qdGE= GET /api/customer/{id} – zobrazí informace o uživateli. GET /api/customer/all – zobrazí všechny uživatele včetně jejich licencí. Zdroj uživatelských skupin (/api/grouptable) OPTIONS /api/grouptable – seznam všech podporovaných metod s popisem ve formátu WADL a XSD. GET /api/grouptable – seznam všech uživatelů zařazených do skupin. Příklad HTTP požadavku: GET http://glassfish.zserver.cz:8080/PPL/api/grouptable \ HTTP/1.1 Host: glassfish.zserver.cz:8080 Authorization: Basic dm9qdGE6dm9qdGE= Příklad HTTP odpovědi: HTTP/1.1 200 OK Content-Type: application/xml [email protected] 1 USER [email protected] 2 ADMIN GET /api/grouptable/{id} – informace o zařazení uživatele do skupiny. POST /api/grouptable/{id} – nové zařazení uživatele do skupiny. Příklad HTTP požadavku: 58

4.3. Webová služba na kontrolu licencí POST http://glassfish.zserver.cz:8080/PPL/api/grouptable \ HTTP/1.1 Host: glassfish.zserver.cz:8080 Content-Type: application/xml ADMIN [email protected] PUT /api/grouptable/{id} – úprava zařazení uživatele do skupiny. Příklad HTTP požadavku: POST http://glassfish.zserver.cz:8080/PPL/api/grouptable \ HTTP/1.1 Host: glassfish.zserver.cz:8080 Content-Type: application/xml 1 ADMIN [email protected] Zdroj licencí (/api/licence a /api/licence/{id} OPTIONS /api/licence – seznam všech podporovaných metod s popisem ve formátu WADL a XSD. GET /api/licence – získá všechny licence s jejich vlastníky. Příklad HTTP požadavku: GET http://glassfish.zserver.cz:8080/PPL/api/licence HTTP/1.1 Authorization: Basic dm9qdGE6dm9qdGE= Příklad HTTP odpovědi: HTTP/1.1 200 OK Content-Type: application/xml <customer>[email protected] <customer_id>1 59

4. Implementace zserver.cz/prestasshop <customer>[email protected] <customer_id>2 espirito.cz POST /api/licence – vytvoří novou licenci. Příklad HTTP požadavku: POST http://glassfish.zserver.cz:8080/PPL/api/licence \ HTTP/1.1 Content-Type: application/xml <customer_id>2 espirito.cz PUT /api/licence – aktualizuje existující licenci. V případě, že není uvedeno ID, je licence vytvořena. Příklad HTTP požadavku: PUT http://glassfish.zserver.cz:8080/PPL/api/licence HTTP/1.1 Content-Type: application/xml 1 <customer_id>2 espirito.cz DELETE /api/licence/{id} – vymaže licenci s ID zadaným v URI. Příklad HTTP požadavku: DELETE http://glassfish.zserver.cz:8080/PPL/api/licence/1 \ HTTP/1.1 Authorization: Basic dm9qdGE6dm9qdGE= 60

4.4. GUI aplikace pro spuštění lokální služby Chybové stavy 400 Bad Request – XML požadavek není validní. 401 Unauthorized – neúspěšná autorizace uživatele. 403 Forbidden – přihlášený uživatel nemá oprávnění k operaci/přístupu na daném zdroji. 404 Not Found – požadovaný zdroj neexistuje. 405 Method Not Allowed – požadovaná metoda není podporována. Například při pokusu o požadavek POST /api/customer/1. 406 Not Acceptable – hlavička Accept musí být nastavena na application/ xml nebo application/json. 415 Unsupported Media Type – hlavička Content-Type musí být nastavena na application/xml nebo application/json.

4.4 4.4.1

GUI aplikace pro spuštění lokální služby Použité technologie

Kontejner Aplikace je napsaná v jazyku Java (JDK 7), nasazena na embedovaném kontejneru Tomcat. Volba kontejneru, namísto celého aplikačního serveru, je dána nutností běhu v embedovaném prostředí. Přestože aplikační servery jako GlassFish nebo TomEE nabízejí embedovanou variantu, nasazování aplikace je na nich výrazně složitější, spuštění trvá znatelně delší dobu a v neposlední řadě zabírají více místa na disku. Nevýhoda jednoduchého kontejneru, jako je Tomcat, je v tom, že nepodporuje všechny Java EE technologie (např. CDI). GUI Uživatelské rozhraní jsem vytvořil pomocí generátoru v NetBeans IDE. Všechny komponenty jsou z knihovny Swing. Stahování licencí Pro stažení licencí uživatele jsem použil knihovnu Jersey 1.14, parsování dat (XML) jsem realizoval převedením na strom DOM a následně dotazováním pomocí XPath.

4.4.2

Popis okna

V okně aktivní licence (viz Obrázek 4.2) je výpis všech licencí uživatele. Licence jsou uvedeny jako cesta k frontendu bez schématu. Aby bylo možné se k jednotlivým PrestaShopům přihlásit, musí být v konfiguračním souboru uveden klíč. Určení klíče je zadáno ve formátu {název licence}={klíč}, např.: kozakv.sin.cvut.cz/prestashop=UDMPGHE1DHCDT6RDZRUKQ9APOCWR0JLH 61

4. Implementace

Obrázek 4.2: GUI aplikace

Okno informační panel představuje velmi jednoduchý výpis stavu aplikace. Po startu aplikace se nejprve spustí embedovaný Tomcat a ověří se, zda je dostupný. Následně se ze serveru stáhnou licence uživatele. Tyto licence jsou vzápětí vypsány v okně Aktivní licence. Posledním krokem je ověření, zda je možné se připojit k PrestaShop API pro jednotlivé licence PrestaShopů. Pro stažení licencí je nutné v konfiguračním souboru zadat uživatelské jméno a heslo, např.: [email protected] PASSWORD=vojta Z důvodu snadnějšího odhalování chyb u zákazníka jsem vytvořil aplikaci, která obsahuje třetí okno s výpisem logu (screenshot okna viz Obrázek 4.3). V případě, že má zákazník s aplikací problém, spustí tuto aplikaci a zkopíruje obsah technické podpoře. Log obsahuje výpis serveru a middlewaru od stupně INFO. Je tak například možné vidět, že došlo k úspěšnému importu nebo exportu.

4.4.3

Executable wrapper

Vzhledem k tomu, že je aplikace napsaná v jazyku Java, je nutné, aby měl uživatel k dispozici prostředí pro její běh (JRE nebo JDK) a ještě navíc ve verzi 7. Takový předpoklad není pro komerční využití reálný. Dobrým řešením tohoto problému je vytvoření wrapperu, který dokáže do jednoho .EXE souboru zabalit embedované JRE a všechny potřebné JAR knihovny. Wrapper musí splňovat několik základních požadavků. Jako ideální se jeví launch4j. Mezi některé vlastnosti launch4j patří: • Licence programu je BSD/MIT, může tedy sloužit pro vytváření closed source komerčních aplikací, • vytvořená aplikace je spustitelná na všech platformách Windows • využití embedovaného JRE. 62

4.4. GUI aplikace pro spuštění lokální služby

Obrázek 4.3: GUI aplikace – debug mód

4.4.4

Struktura adresáře s programem

Adresář s programem obsahuje následující strukturu: conf/ config.properties ............................ konfigurační soubor jre1.7.0_17/ ....................................... embedované JRE lib/ ................................................... JAR knihovny temp/...........................pomocné XML soubory pro přenos dat tomcat.8080/ .................................... embedovaný Tomcat app.exe...........................................spustitelná aplikace PPM.war ..................................... zkompilovaný middleware

63

Kapitola

Funkční testování Funkční testy slouží pro kontrolu všech obecných funkcí aplikace. Ověřuje se, že fungují správně a že odpovídají požadavkům zákazníka. Dále se ověřuje, zda daný systém obsahuje všechny funkce, které jsou uvedeny v požadavcích zákazníka. Pro účely funkčního testování jsem zvolil aplikaci SoapUI. Jedná se o opensource, multiplatformní aplikaci určenou právě pro funkční testování. V grafickém prostředí umožňuje rychlý vývoj automatických funkčních, regresních a zátěžových testů. Funkční testy je možné spouštět pouze v předem připraveném testovacím prostředí. Při testech nejsou využity žádné mock objekty. Spouštěné testy odesílají XML data, čímž umožňují automatické testování. Simulují tak provoz Pohody. Tato simulace je jediným zjednodušením oproti reálnému provozu.

5.1

Prostředí testování

Pro úspěšný průchod testů je nutné, aby byly spuštěny všechny externí služby. Scénář testů očekává běh těchto služeb na přesně daných adresách. Tyto adresy je možné upravit přímo ve scénářích aplikace SoapUI. Výchozí nastavení služeb ve scénářích: • Lokální middleware base URI: http://localhost:8080/PPM/ • PrestaShop base URI: http://kozakv.sin.cvut.cz/prestashop/ klíč: UDMPGHE1DHCDT6RDZRUKQ9APOCWR0JLH • Kontrola licencí base URI: http://glassfish.zserver.cz:8080/PPL/api/ přihlašovací údaje: jméno – kozakvoj, heslo – vojta 65

5

5. Funkční testování

5.2

Kontrola vložení nového produktu

Kontrola vložení nového produktu je složena z 5 kroků. Nejprve se middlewaru odešle požadavek na vytvoření nového produktu. Tento požadavek má následující strukturu: POST http://localhost:8080/PPM/export/products HTTP/1.1 Content-Type: application/xml ... <prestashop> <product> espirito-cafe-15 Espirito Cafe Espresso esp15 <price>275 <decription>Vynikající káva ... SoapUI přijme od middlewaru odpověď, která musí přesně odpovídat požadavkům. Očekávanou odpověď demonstruje následující výpis: HTTP/1.1 200 OK X-Powered-By: JSP/2.2 Server: GlassFish Server Open Source Edition 3.1.2.2 Content-Type: text/xml;charset=Windows-1250 ... Automatická kontrola odpovědi je realizována pomocí assertů. Kontrolují se hodnoty: • Doba odpovědi nesmí překročit 30 000 ms, • stav odpovědi musí být ok (XPath výraz //response/@state), • kód odpovědi musí být 200, • Content-Type musí být nastaven na text/xml. Tato assertace není v SoapUI obsažena, ale je možné ji použít pomocí Groovy skriptu: 66

5.2. Kontrola vložení nového produktu assert messageExchange .responseHeaders.get("Content-Type") .contains("text/xml;charset=Windows-1250") Druhým a třetím krokem je ověření, že produkt existuje v PrestaShopu. Před dotazem na PrestaShop je nutné počkat nějakou dobu, než se produkt vytvoří. Pokud by test nečekal, skončil by s velkou pravděpodobností chybou. Doba čekání (krok 2) je nastavena na 1 000 ms. Komunikace s PrestaShopem je asynchronně odstíněna middlewarem, proto přímo po vložení produktu není k dispozici ID tohoto produktu. Ověření existence je však možné pomocí filtrování, které podporuje PrestaShop. Zkrácená hlavička dotazu na PrestaShop pak vypadá: GET {apiProductURI}/?filter[reference]=espirito-cafe-15 HTTP/1.1 Authorization: Basic VURNUEdIRTFESENEVDZSRFpSVUtROUUjBKTEg6V= ... PrestaShop pošle odpověď a v případě, že byl produkt úspěšně přidán, bude v XML těle tento produkt obsažen: HTTP/1.1 200 OK Server: Apache/2.2.22 (Win32) PHP/5.3.13 X-Powered-By: PrestaShop Webservice Content-Type: text/xml;charset=utf-8 ... <prestashop xmlns:xlink=’http://www.w3.org/1999/xlink’> <products> <product id=’70’ xlink:’href={apiProductURI}/70’/> Automatická kontrola je složena ze dvou assertů: • Kód odpovědi musí být 200, • ID produktu musí být větší než 0 (XPath výraz //prestashop/products/ product/@id>0) V posledních dvou krocích dojde k vymazání produktu z PrestaShopu. K tomu je nutné uložit ID produktu do uživatelských proměnných. Přístup k této proměnné je pak jednoduše dostupný příkazem ${#TestSuite#productID}. Úspěšný průběh testu v programu SoapUI je znázorněn na Obrázku 5.1. 67

5. Funkční testování

Obrázek 5.1: Úspěšný průběh testu v programu SoapUI

5.3

Kontrola tvorby kategorií

Funkční testy pro ostatní položky fungují podobným způsobem jako kontrola produktů. U kategorií je nutné zkontrolovat jejich správné zanoření. Jako vstupní testovací XML dokument slouží následující výpis: Káva 68

5.3. Kontrola tvorby kategorií Arabika Zrnková Mletá Robusta Předchozí výpis ve formátu Pohody odpovídá struktuře: Káva -- Arabika -- -- Mletá -- -- Zrnková -- Robusta Kontrola správného zanoření se provede pomocí několika XPath dotazy. Nejprve se získá seznam všech kategorií z PrestaShopu: GET {apiCategoriesURI}/\ ?display=[id,level_depth,name,id_parent] HTTP/1.1 Authorization: Basic VURNUEdIRTFESENEVDZSRFpSVUtROUUjBKTEg6V= ... Následující kontroly např. ověří, že kategorie Arabika je zanořena ve třetí úrovni a její rodič je kategorie Káva: //prestashop/categories/category[level_depth=3\ and name/language="Arabika"]/id_parent/text() CDATA 61 V případě, že kategorie Arabika existuje a nachází se na úrovni 3, XPath z předchozího dotazu získá ID rodiče. To je použito v následujícím dotazu. Pokud vrátí název Káva, proběhla kontrola v pořádku. 69

5. Funkční testování //prestashop/categories/category[level_depth=2\ and id=61]/name/language[1]/text() CDATA Káva Následuje vymazání všech testovacích kategorií z PrestaShopu. ID nově vytvořených produktů se získá pomocí filtru PrestaShopu. Získání ID kategorie Káva se tedy provede HTTP požadavkem: {apiCategoriesURI}/\ ?filter[name]=Káva&filter[level_depth]=2&display=[id]

70

Kapitola

Měření nároků na výkon Během testování aplikace jsem prováděl několik dílčích měření nároků na výkon, při kterých jsem sledoval např. spotřebu paměti a procesoru, časové nároky, možnosti škálování apod. Každé měření jsem rozdělil do tří částí. V části Motivace testu jsem zdůvodnil, proč bylo vhodné měření provést, v části Nastavení jsem uvedl všechny proměnné parametry, které měly vliv na výsledek testu a v poslední části Vyhodnocení jsem provedl diskusi výsledků měření.

6.1

Měření vlastní aplikace

V kapitole měření vlastní aplikace jsem se zaměřil na testování dílčích částí, které přímo souvisejí s rychlostí implementace. Těmito testy jsem se pokusil ověřit kvalitu vlastního řešení.

6.1.1

Rychlost odezvy služby na správu licencí

Motivace testu Služba na kontrolu licencí funguje společně pro všechny zákazníky, tedy pro ty, kteří využívají jak lokální verzi middlewaru, tak i tu internetovou. Je důležité, aby služba odpověděla v co nejkratší době, protože z hlediska samotného propojení Pohody a PrestaShopu nezajišťuje žádnou funkcionalitu. V případě, že by však došlo k výpadku, nebude propojení aktivní. Nastavení V programu LoadUI jsem vytvořil test, který během jedné minuty postupně zvyšuje počet požadavků na zobrazení informace o uživateli. Počet požadavků je v rozmezí 0–200. Během testu jsem sledoval, při kolika požadavcích dojde k náhlému zvýšení doby odezvy. Samotná služba má vypnuté cachování odpovědí, musí se tedy při každém požadavku dotazovat na databázi. 71

6

6. Měření nároků na výkon

Obrázek 6.1: PPL – závislost počtu požadavků na době odezvy

Vyhodnocení Během testu vyšlo najevo, že služba dokáže zpracovat výrazně více požadavků, než jaké jsou na ni kladeny nároky. Do 120 požadavků/s služba odpovídala v průměrné době 25 ms. Při hodnotách vyšších než 120 požadavků/s začala služba odpovídat ve výrazně delších intervalech – až 1 000 ms (viz Obrázek 6.1). Zároveň začalo docházet k zařazování požadavků do fronty. Operace, které jsou v aplikaci vykonávány, zatěžují tedy server pouze minimálně. Do budoucna při zvyšujícím se počtu zákazníků nebude nutné řešit pro tuto službu další škálování a může běžet na stávající konfiguraci.

6.1.2

Rychlost vkládání nových obrázků

Motivace testu Již na první pohled je vkládání nových obrázků Achillovou patou systému. Problém je v datovém objemu této operace a v počtu požadavků. Pohoda sice uploaduje všechny obrázky na FTP server, k přiřazení těchto obrázků ke konkrétním produktům však ještě vede dlouhá cesta. Při využití PrestaShop Webservice je nutné pro každý obrázek vytvořit samostatný požadavek a ten 72

6.1. Měření vlastní aplikace odeslat. Výhodou na druhou stranu je fakt, že obrázky jsou v době přípravy dotazů uloženy lokálně a odpadá tak problém s pomalým uploadem. Cílem tohoto testu je ověřit, zda je tato funkce v této podobě použitelná, případně jaká je hranice použitelnosti. Nastavení Pro testování jsem připravil 100 obrázků s průměrnou velikostí 680 kB. Zkoušel jsem pouze jednoduché vložení nového obrázku bez jakýchkoliv dalších kontrol. Všechny obrázky jsem přidával pouze k jednomu produktu. Dodatečné kontroly, které jsem v testu vypustil: • Kontrola, zda je obrázek k produktu již přiřazený. Tato kontrola vyžaduje parsování XML pro každý obrázek. • Kontrola, zda má být obrázek použit pro náhled. Tato kontrola vyžaduje vytvoření a odeslání dvou požadavků na server. • Kontrola nastavení Internet media type u obrázku. Vyhodnocení Průměrná doba odeslání jednoho obrázku je 1,5 s, z toho plyne následující: • Pokud dojde k vytvoření obrázků pro celý e-shop, který má 25 000 produktů a průměrně 2 obrázky u produktu, pak bude celá operace trvat 20,8 h. • Při standardně nastaveném časovém limitu pro běh skriptů (30 s) je možné zpracovat maximálně 20 obrázků. Větší počet by mohl být odeslán dávkovým zpracováním za pomocí BASH skriptu, to by ale celou operaci značně zkomplikovalo a zvedlo požadavky na server. Zpracování obrázků je velmi složité i pro malé množství produktů a to i bez zohlednění všech nutných kontrol. U pravidelného spouštění je nutné brát v úvahu počet zpracovaných souborů, případně programově odložit operaci do nočních hodin, kdy je server méně vytížen. Pro úvodní naplnění všech produktů s obrázky by bylo vhodné vytvořit jednorázový skript, který by nevyužíval webové služby PrestaShopu, ale přistupoval by k němu přímo.

6.1.3

Rychlost importu a exportu

Motivace testu Měření celého procesu exportu a importu poskytuje nejkomplexnější přehled o rychlosti propojení obou systémů. Z důvodu omezené licence Pohody, kterou mám k dispozici pro vývoj, nemohu testovat rychlost importu velkého 73

6. Měření nároků na výkon množství položek. Během exportu mohu při testu nahradit aplikaci Pohoda testovacím nástrojem SoapUI, protože samotné odeslání exportních dat není časově náročnou operací. Všechny druhy exportů mají přibližně stejnou strukturu: • úvodní kontroly, • uložení požadavku do souboru (jednorázově – zanedbatelné), • vytvoření požadavku na export v middlewaru, • odeslání požadavku/požadavků. Díky tomuto testu bude možné odhadnout přibližné časové nároky na exporty rozdílných velikostí. Zároveň umožní identifikovat části, které jsou na přenosu časově nejsložitější. Nastavení Testování jsem prováděl na exportu produktů, export ostatních položek bude dosahovat podobných časů. Pro měření časů jsem vytvořil exportní soubory s 1, 100 a 1 000 produkty. Data jsem odesílal z programu SoapUI na lokálně běžící middleware. Ten běžel na standardním kancelářském PC (procesor 2.0 GHz dual-core, 4 GB RAM). Middleware odesílal požadavky na zpracování na vzdáleně běžící PrestaShop. Ten byl nasazen na samostatném VPS (procesor: 1 vlákno Xeon E52650L 1,80 GHz, 2 GB RAM). Vyhodnocení Úvodní kontroly trvají vždy stejnou dobu bez ohledu na počet zpracovaných položek. Doba kontroly je přibližně 1,5 s. Zpracování jednoho produktu trvalo cca. 5 ms. Časově nejsložitější operací bylo zpracování produktu v PrestaShopu, které vycházelo na cca 230 ms/produkt (operace pro zápis, resp. změnu). Na Obrázku 6.2 je zobrazená časová osa pro soubor s 1 000 produkty. Při importu dojde ke stažení dat z PrestaShopu. Tato operace se provede jedním požadavkem (operace pro čtení), ve kterém je vrácen celý XML dokument. Průměrná doba odpovědi od PrestaShopu byla 170 ms. Doba zpracování v middlewaru je dána především rychlostí middlewaru. Toto měření jsem provedl v Kapitole 6.2.1. Operaci mazání jsem neměřil, protože není z hlediska middlewaru využitelná. Rychlosti operací pro zápis, změnu a čtení jsou velmi podobné pro všechny typy zdrojů (produkty, objednávky, zákazníci, atd.). 74

6.1. Měření vlastní aplikace

Obrázek 6.2: PPL – závislost počtu požadavků na době odezvy

6.1.4

Nároky middlewaru na paměť

Motivace testu Cílem tohoto testu je změřit paměťové nároky na zpracování XML dokumentů v middlewaru. Test by měl poskytnout informace o tom, jaké jsou nároky na běžný a extrémní provoz. Test neobsahuje experimentální operace, jako je běh XSLT procesoru.

Nastavení Middleware jsem testoval na PC s procesorem AMD Phenom II X4 965 3,4 GHz quad-core a operačním systémem MS Windows 8, 64 bit. Pro běh JVM jsem využil embedovanou verzi JRE ve verzi 1.7.0_17. Pro měření náročnosti aplikace jsem vytvořil dva XML dokumenty. Jeden o velikosti 970 kB a druhý o velikosti 45 510 kB.

Vyhodnocení Obrázek 6.3 zobrazuje výsledky měření paměti pro menší XML dokument (970 kB). Každá špička v grafu představuje zpracování jednoho produktu. To odpovídá parsování založeném na SAXu a DOMu. Špička znamená, že systém vytvořil DOM strom pro jeden produkt. Zpracování tak nepřekračuje ani 21 MB. Ve druhém měření (Obrázek 6.4) jsem zkoušel zpracovat dokument o velikosti 45 510 kB. Z výsledků je patrné, že využití paměti je identické, zpracování pouze trvá delší dobu. Na Obrázku 6.5 je zobrazeno vytížení procesoru během měření menšího dokumentu. Časová osa přesně odpovídá Obrázku 6.3. Zatížení procesoru je okolo 25 %, což znamená, že aplikace využívá 100 % jednoho jádra. 75

6. Měření nároků na výkon

Obrázek 6.3: Nároky na paměť pro malý XML dokument

Obrázek 6.4: Nároky na paměť pro velký XML dokument

6.2

Měření souvisejících aplikací

V kapitole měření souvisejících aplikací jsem se zaměřil na testování výkonu aplikací třetích stran. Na těchto aplikacích je vlastní implementace přímo závislá a hrají zásadní roli v rychlosti komunikace.

6.2.1

Paměťové nároky na procesor Saxon

Motivace testu Využití XSLT procesoru v middlewaru může představovat významný problém, protože je celá stromová reprezentace XML dokumentu uložena do operační paměti. Hlavním cílem tohoto testu je ověření paměťových nároků. Saxon 76

6.2. Měření souvisejících aplikací

Obrázek 6.5: Vytížení procesoru při zpracování malého XML dokumentu

vytváří jednodušší model stromu než je DOM, ale v případě velkého množství produktů by zpracování nemuselo být reálné. Dalším cílem testu je ověření doby potřebné pro transformaci. Nastavení Pro testování jsem vygeneroval XML soubor, který odpovídá přibližně 20 500 produktům (každý produkt má cca 150 nodů). Testování jsem provedl v příkazové řádce za využití Saxon verze 9.4 a Java verze 1.7. Pro test jsem využil standardní kancelářské PC (procesor 2.0 GHz dual-core, 4 GB RAM). Vyhodnocení Po dokončení transformace vypsal Saxon následující zprávu: Saxon 9.4.0.7J from Saxonica Java version 1.7.0_13 Stylesheet compilation time: 190 milliseconds Processing file:/C:\temp\pplarge.xml Building tree for file:/C:\temp\pplarge.xml using class Tree built in 1053 milliseconds Tree size: 3075004 nodes, 1800000 characters, 0 attributes Execution time: 1448 milliseconds Memory used: 506661648 NamePool contents: 14 entries in 14 chains. 6 prefixes, 6 URIs Procesor Saxon potřeboval na vykonání operace cca 500 MB operační paměti. Taková zátěž je akceptovatelná, ale není vůbec zanedbatelná. V případě 77

6. Měření nároků na výkon běhu middlewaru na počítači uživatele se nejedná o problém, protože podobné nároky má pravděpodobně i XSLT procesor Pohody. Pokud však middleware běží na serveru, tyto nároky se projeví na ceně za pronajatý server. Transformace proběhla za 1,5 s, což potvrdilo předpoklad, že XSLT procesory pracují velmi rychle.

6.2.2

Rychlost OpenSSL

Motivace testu Komunikace s PrestaShopem by vždy měla probíhat pomocí protokolu HTTPS. V případě velkého počtu produktů může dojít k šifrování několika desítek až stovek MB. Komunikace přes protokol HTTPS by měla probíhat i mezi middlewarem a Pohodou v případě, že middleware běží na serveru. Posledním zabezpečeným přenosem je komunikace mezi middlewarem a serverem na kontrolu licencí. V tomto případě je ale přenášeno pouze malé množství dat. O SSL se často říká, že je pomalé. Tento názor je pozůstatkem z dob, kdy byl výpočetní výkon počítačů malý. Zpomalení by nemělo být znatelné ani u velkých webových služeb. Tento předpoklad je ale možné podpořit měřením. Nastavení OpenSSL obsahuje skript pro benchmarking, který lze spustit příkazem: > openssl speed Testování jsem prováděl na procesoru 2.0 GHz dual-core. OpenSSL využívá ale pouze jedno jádro pro testování, v reálném životě by byla využita všechna jádra a tím by byl celý proces ještě rychlejší. Vyhodnocení Pokud se podíváme na první sloupec Tabulky 6.1 (16 B) algoritmu RC4 (často využívaný algoritmus) uvidíme, že tento algoritmus dokáže zpracovat 438 MB/s, a to pouze za využití jednoho procesoru. Při této rychlosti nebude šifrované připojení komunikačním bottleneckem. Asymetrické šifrování se nepoužívá pro přenos dat, ale pro úvodní handshake sloužící k autentizační validaci. Výsledek zobrazuje, kolik operací je možné provést za sekundu. Pokud bychom použili 2 048b RSA klíč, budeme limitováni 21 903 přihlašovacími operacemi za sekundu (Tabulka 6.2). U stejně dlouhého DSA šifrování pak 1 903 operacemi (Tabulka 6.3). Asymetrické šifrování je využito na začátku každého SSL sezení. Toto omezení může být limitující pro velkou e-commerce aplikaci, pro tento typ aplikace však příliš zajímavé není, protože dochází pouze k jedné operaci v rámci jednoho importu, resp. exportu.

78

6.2. Měření souvisejících aplikací

Tabulka 6.1: Jednosměrné symetrické algoritmy typ

16 B [kB]

64 B [kB]

256 B [kB]

1 kB [kB]

8 kB [kB]

md5

38 401

144 454

356 620

564 363

695 873

hmac

33 049

115 382

306 774

535 424

683 990

sha1

47 973

138 186

312 387

442 295

507 092

438 182

571 108

610 010

624 173

631 861

des cbc

66 988

68 567

69 954

69 875

70 372

des ede3

26 590

27 203

27 517

27 376

27 437

rc2 cbc

35 945

36 977

37 661

37 392

37 557

aes-128

97 774

105 507

108 960

279 606

280 389

aes-192

83 102

87 200

90 066

234 974

237 564

aes-256

70 677

74 383

75 475

195 609

196 672

rc4

Tabulka 6.2: Asymetrický algoritmus RSA b

sign [s]

verify [s]

sign/s

verify/s

512

7, 60 × 10−5

6 × 10−6

13 115,3

167 059,8

1 024

2, 21 × 10−4

1, 4 × 10−5

4 524,7

69 403,9

2 048

1, 46 ×

10−3

10−5

684,7

21 902,9

4 096

1, 03 × 10−2

1, 69 × 10−4

96,7

5 920,6

4, 6 ×

Tabulka 6.3: Asymetrický algoritmus DSA b

sign [s]

verify [s]

sign/s

verify/s

512

7, 6 × 10−5

6, 8 × 10−5

13 141,2

14 673,8

1 024

2, 52 ×

10−4

10−4

6 572,4

6 176,0

2 048

4, 55 × 10−4

5, 25 × 10−4

2 199,6

1 903,3

1, 62 ×

79

Závěr Na základě analýzy a návrhu jsem částečně implementoval funkční propojení mezi systémy Pohoda a PrestaShop. Vytvořil jsem middleware, který lze spustit jako webovou službu na aplikačním serveru GlassFish nebo jako GUI aplikaci za pomoci embedovaného kontejneru Tomcat 7. Velkým problémem při návrhu aplikace bylo určení způsobu mapování položek v Pohodě a v PrestaShopu. Pokud by bylo možné sdílet ID položek, bylo by to snadné. Protože to možné nebylo, musel jsem vymyslet alternativní způsoby, které vedly k několika kompromisům a zkomplikovaly aplikační logiku. V rámci práce jsem provedl několik měření. Ta by měla poskytnout rámcovou představu o náročnosti propojení libovolných systémů, které pro komunikaci využívají HTTP protokol a pro zpracování jejich komunikace je zapotřebí XML parser nebo XSLT procesor. Z výsledků měření vyplývá, že je možné vytvořit nenáročné a velmi rychlé propojení na úrovni middlewaru. Problematické je však zpracování v samotném systému. Webová služba PrestaShopu dokáže zpracovat pouze omezené množství dat, než vyprší časový limit pro běh PHP skriptů. Ke zvládnutí většího importu by bylo zapotřebí dávkového zpracování, což by ale vyžadovalo neustálé odesílání dat z middlewaru po celou dobu importu. Zkušenosti z návrhu a implementace by měly posloužit pro vytvoření middlewaru i pro jiný typ ekonomického softwaru propojeného s PrestaShopem. Případně mohou sloužit pro jiný elektronický obchod, který poskytuje webové služby nutné k přenosu požadovaných dat. Protože je každý systém odlišný, nelze vytvořit univerzální middleware, který by bylo možné pouze mírně upravit pro jiný typ dat. Například při implementaci propojení se systémem FlexiBee by middleware musel sám iniciovat import a export, princip konverze dat a komunikace s elektronickým obchodem by však zůstal podobný.

81

Literatura [1]

Allamaraju, S.: RESTful Web Service Cookbook. O’Reilly Media, 2010, ISBN 978-0-576-80168-7.

[2]

Anand, V.: Using HTTP Methods in REST. [online], říjen 2012, [cit. 5. 4. 2013]. Dostupné z: http://www.prideparrot.com/blog/archive/ 2011/10/using_http_methods_in_rest

[3]

Angstadt, M.: WSDL SOAP bindings confusion - RPC vs document. [online], květen 2011, [cit. 19. 10. 2012]. Dostupné z: http://mangstacular. blogspot.cz/2011/05/wsdl-soap-bindings-confusion-rpc-vs. html

[4]

Angstadt, M.: WSDL SOAP bindings confusion - RPC vs document. Mike’s Software Development Blog. [online], květen 2011, [cit. 19. 9. 2012]. Dostupné z: http://mangstacular.blogspot.cz/2011/05/ wsdl-soap-bindings-confusion-rpc-vs.html

[5]

Cerami, E.: Web Service Essentials: Distributed Applications with XMLRPC, SOAP, UDDI & WSDL. O’Reilly, 2002, ISBN 0-596-00224-6.

[6]

Daigneau, R.: Service Design Patterns: fundamental design solutions for SOAP/WSDL and RESTful Web Services. Addison-Wesley, 2012, ISBN 978-0-321-54420-9.

[7]

Dhesiaseelan, A.: What’s New in WSDL 2.0. [online], [cit. 5. 1. 2013]. Dostupné z: http://www.xml.com/pub/a/ws/2004/05/19/wsdl2.html

[8]

Hadley, M.: Web Application Description Language. [online], srpen 2009, [cit. 5. 4. 2013]. Dostupné z: http://www.w3.org/Submission/wadl/

[9]

Haufler, A.: Conveniently Processing Large XML Files with Java. [online], říjen 2012, [cit. 6. 4. 2013]. Dostupné z: http://java.dzone.com/ articles/conveniently-processing-large 83

Literatura [10] Hock-Chuan, C.: Java Programming – Java & XML. [online], březen 2009, [cit. 5. 3. 2013]. Dostupné z: http://www.ntu.edu.sg/home/ehchua/ programming/java/J6d_xml.html [11] Saxon: Anatomy of an XSLT processor. [online], duben 2005, [cit. 5. 3. 2013]. Dostupné z: http://www.ibm.com/developerworks/library/ x-xslt2/ [12] ICONIX Process Overview. [online], [cit. 5. 1. 2013]. Dostupné z: http: //iconixprocess.com/iconix-process/ [13] Jonathan Robie, T. R.: What is the Document Object Model? [online], [cit. 6. 3. 2013]. Dostupné z: http://www.w3.org/TR/REC-DOM-Level-1/ introduction.html [14] Kadlec, V.: Agilní programování – Metodiky efektivního vývoje software. Computer Press, 2004, ISBN 80-251-0342-0. [15] Kay, M.: Streaming of Large Documents. [online], [cit. 5. 3. 2013]. Dostupné z: http://www.saxonica.com/documentation/sourcedocs/ streaming.xml [16] Kay, M.: XSLT 2.0 and XPath 2.0 Programmer’s Reference. Wrox, 2011, ISBN 978-0470192740. [17] Kosek, J.: Inteligentní podpora navigace na WWW s využitím XML. [online], květen 2002, [cit. 5. 4. 2013]. Dostupné z: http://www.kosek. cz/diplomka/html/websluzby.html [18] Kumar, P.: On the Design of Web Services: SOAP vs. REST: NF Theses and Dissertations. Paper 138. University of North Florida, 2011. [19] Laurie, B.: Digest Authentication. [online], únor 1999, [cit. 6. 4. 2013]. Dostupné z: http://docstore.mik.ua/orelly/linux/apache/ch05_07. htm/ [20] Mendel, L.: Describe REST Web services with WSDL 2.0. IBM developerWorks. [online], květen 2008, [cit. 19. 9. 2012]. Dostupné z: http:// www.ibm.com/developerworks/webservices/library/ws-restwsdl/ [21] Merunka, V.: Metoda tvorby informačních systémů. [online]. Dostupné z: http://etext.czu.cz/img/skripta/64/pef_226-1.pdf [22] Why StAX? [online], [cit. 6. 3. 2013]. Dostupné z: http: //docs.oracle.com/cd/E17802_01/webservices/webservices/ docs/1.6/tutorial/doc/SJSXP2.html [23] O’Reilly, T.: REST vs. SOAP at Amazon. [online], březen 2003, [cit. 19. 9. 2012]. Dostupné z: http://www.oreillynet.com/pub/wlg/3005 84

Literatura [24] Pfeifer, C.: XML Processing with TRaX. [online], červen 2001, [cit. 6. 4. 2013]. Dostupné z: http://www.onjava.com/pub/a/onjava/2001/07/ 02/trax.html [25] Ristic, I.: Apache Security. O’Reilly Media, 2005, ISBN 978-0-596-007249. [26] Rosenberg, D.: Testování softwaru řízené návrhem. Computer Press, 2011, ISBN 9788025136072. [27] Sandoval, J.: RESTful Java Web Services. Packt Publishing, 2009, ISBN 978-1-847196-46-0. [28] Skonnard, A.: Understanding WSDL. [online], říjen 2003, [cit. 5. 1. 2013]. Dostupné z: http://msdn.microsoft.com/en-us/library/ms996486. aspx [29] Events vs. Trees. [online], [cit. 5. 3. 2013]. Dostupné z: http://sax. sourceforge.net/event.html [30] Obecný internetový obchod. [online], květen 2011, [cit. 19. 10. 2012]. Dostupné z: http://www.stormware.cz/podpora/faq/obecny_obchod. aspx [31] Tidwell, D.: XSLT, 2nd Edition. O’Reilly Media, 2008, ISBN 9780596527211.

85

Příloha

Seznam použitých zkratek API Application Programming Interface BASH Bourne Again Shell BSD Berkeley Software Distribution CDI Contexts and Dependency Injection DSSSL Document Style Semantics and Specification Language DDT Design Driven Testing DOM Document Object Model DSA The Digital Signature Algorithm Etag Entity tag FTP File Transfer Protocol GUI Graphical User Interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IDE Integrated development environment JAX-RS Java API for RESTful Web Services JAX-WS Java API for XML WebServices JAXB Java Architecture for XML Binding JDBC Java Database Connectivity JPA Java Persistence API 87

A

A. Seznam použitých zkratek JSON JavaScript Object Notation JSP Java Server Pages LDAP Lightweight Directory Access Protocol JAR Java Archive JDK Java Development Kit JRE Java Runtime Environment JVM Java Virtual Machine MIME Multipurpose Internet Mail Extensions nonce Number Once OOAD Object-Oriented Analysis and Design ORM Object-relational mapping PDF Portable Document Format PHP PHP: Hypertext Preprocessor PPG Pohoda-PrestaShop GUI PPL Pohoda-PrestaShop Licenses PPM Pohoda-PrestaShop Middleware RAM Random-access memory REST Representational State Transfer RFC Request for Comments RPC Remote procedure call RSA Ron Rivest, Adi Shamir and Leonard Adleman (algoritmus) RTF Rich Text Format SGML Standard Generalized Markup Language SAX Simple API for XML SOAP Simple Object Access Protocol SQL Standard Query Language SSL Secure Sockets Layer 88

StAX Streaming API for XML TDD Test-driven development TrAX Transformation API For XML URI Uniform Resource Identifier URL Uniform Resource Locator VPS Virtual Private Server W3C World Wide Web Consortium WAP Wireless Application Protocol WADL Web Application Description Language WSDL Web Services Description Language XML Extensible Markup Language XP Extreme Programming (Extrémní programování) XSD XML Schema Definition XST Cross-site tracing XSL-FO Extensible Stylesheet Language Formatting Objects XSLT eXtensible Stylesheet Language Transformations

89

Příloha

Komunikace PrestaShopu B.1

Zdroje webové služby PrestaShopu

• Adresy zákazníků a výrobců: /api/addresses • Cenová pravidla: /api/pecific_price_rules • CMS: /api/content_management_system • Daně (tagy): /api/taxes • Detail naskladnění produktu: /api/supply_order_details (GET, HEAD) • Detail objednávky: /api/order_details • Dodavatelé produtku: /api/product_suppliers • Dodavatelé: /api/suppliers • Dopravci: /api/carriers • Důvody skladových pohybů: /api/stock_movement_reasons • Faktury: /api/order_invoices • Historie dokladů skladových objednávek: /api/supply_order_receipt_histories (GET, HEAD) • Historie objednávek: /api/order_histories • Historie skladových objednávek: /api/supply_order_histories (GET, HEAD) • Hodnoty produktů: /api/product_options • Hodnoty vlastností produktů: /api/product_feature_values 91

B

B. Komunikace PrestaShopu • Hodnoty volby produktů: /api/option_feature_values • Hosti (nákupy bez registrace): /api/guests • Kategorie produktů: /api/categories • Kombinace produktů: /api/combinations • Měny: /api/currencies • Nákupní košíky zákazníků: /api/carts • Nastavení obchodu: /api/configurations • Obchody: /api/shops • Objednaní dopravci: /api/order_carriers • Objednávky: /api/orders • Obrázky: /api/images • Označení produktů (tagy): /api/tags • Pobočky obchodů: /api/stores • Použité slevy: /api/order_discounts • Pravidla daní (tagy): /api/tax_rules • Pravidla košíku: /api/cart_rules • Produkty: /api/products • Překlady konfigurací obchodu: /api/translated_configurations • Rozsahy cen: /api/price_ranges • Skladové objednávky: /api/supply_orders • Skladové pohyby: /api/stock_movements • Skladové zásoby: /api/stock_availables • Sklady: /api/stocks • Skupiny obchodů: /api/shop_groups • Skupiny pravidel daní (tagy): /api/tax_rule_groups • Skupiny zákazníků: /api/groups • Specifické ceny: /api/specific_prices 92

B.2. Možnosti renderování • Statusy skladových objednávek: /api/supply_order_states • Státy: /api/states • Stavy objednávek: /api/order_states • Typy obrázků: /api/image_types • Uskutečněné platby: /api/order_payments • Váhové rozsahy: /api/weight_ranges • Velkoobchody: /api/warehouses • Vlastnosti produktů: /api/product_features • Vyhledávání: /api/search (GET, HEAD) • Výrobci: /api/manufacturers • Zákazníci: /api/customers • Zaměstnanci: /api/employees • Zařazení produktu do velkoobchodu: /api/warehouse_product_locations • Země: /api/countries • Zóny: /api/zones • Způsoby doručení: /api/deliveries

B.2

Možnosti renderování Tabulka B.1: Možnosti rendrování

Klíč

Hodnota

Popis

display

[field1,field2...]

Zobrazí pouze pole v závorkách

display

[full]

Zobrazí všechna pole

filter[field] [value]

Zobrazí pole s hodnotou value

filter[field] [value1,value2...]

Zobrazí pole mezi hodnotami value1 a value2

filter[field] %[value]%

Zobrazí sloupce, které obsahují „value“

sort

Řazení podle zadaných polí

[field1_ASC/DESC,..]

93

B. Komunikace PrestaShopu Klíč

Hodnota

Popis

sort

full

Zobrazí všechna pole

limit

číslo

Omezí počet výsledků na zadané číslo

limit

počáteční index, číslo

Zobrazí zadaný počet výsledků od zadaného indexu

B.3

XML šablona pro vytvoření produktu

<prestashop xmlns:xlink=’http://www.w3.org/1999/xlink’> <product> <supplier_reference> <width> <depth> <weight> <ean13> <ecotax> <minimal_quantity> <price> <wholesale_price> 94

B.3. XML šablona pro vytvoření produktu <customizable> <show_price> <meta_description>lng tag <meta_keywords>lng tag <meta_title>lng tag lng tag lng tag <description>lng tag <description_short>lng tag lng tag lng tag <product_option_values> <product_options_values> <product_features> <product_feature> 95

B. Komunikace PrestaShopu <stock_availables> <stock_available> <product>

B.4

XML šablona pro vytvoření kategorie

<prestashop xmlns:xlink=’http://www.w3.org/1999/xlink’> <position/> lng tag lng tag <description>lng tag <meta_title>lng tag <meta_description>lng tag <meta_keywords>lng tag <products> <product> 96

B.5. XML šablona pro vytvoření objednávky

B.5

XML šablona pro vytvoření objednávky

<prestashop xmlns:xlink=’http://www.w3.org/1999/xlink’> <current_state> <module> <invoice_number> <invoice_date> <delivery_number> <delivery_date> <secure_key> <payment> 97

B. Komunikace PrestaShopu <shipping_number> <product_id> <product_attribute_id> <product_quantity> <product_name> <product_price>

B.6

XML šablona pro vytvoření zákazníka

<prestashop xmlns:xlink=’http://www.w3.org/1999/xlink’> <customer> <secure_key> <deleted> <passwd> <email> 98

B.6. XML šablona pro vytvoření zákazníka <website> <siret> <show_public_prices> <max_payment_days> <note>

99

Příloha

Komunikace Pohody C.1

Chybové kódy komunikace

Tabulka C.1: Chybové kódy komunikace Chyba

Popis chyby

-1

Chyba parsování URL.

-3

Požadavek XML je prázdný.

-4

Odpověď (response) webové služby obsahuje nepovolený Content-Type. Program Pohoda vyžaduje Content-Type: text/xml.

-12002

Vypršel časový limit na odpověď serveru.

-12045

Nepodařilo se ověřit autoritu certifikátu. Je nutné naimportovat certifikát autority vystavitele do úložiště „Důvěryhodné kořenové certifikační autority“.

-12057

Nepodařilo se ovařit autoritu certifikátu. Je nutné naimportovat certifikát autority vystavitele do úložiště „Důvěryhodné kořenové certifikační autority“.

400 Bad request

Požadavek nemůže být vyřízen, poněvadž byl syntakticky nesprávně zapsán.

401 Unauthorized

Používán tam, kde je vyžadována autentifikace, ale nebyla zatím provedena.

403 Forbidden

Požadavek byl legální, ale server odmítl odpovědět.

404 Not found

Požadovaný dokument nebyl nalezen.

101

C

C. Komunikace Pohody Chyba

Popis chyby

405 Method Not Allowed

Požadavek byl zavolán na zdroj s metodou, kterou nepodporuje. Například se jedná o službu, na kterou se odesílají data metodou POST a někdo se je místo toho pokusí odeslat metodou GET.

408 Request Timeout

Vypršel čas vyhrazený na zpracování požadavku.

500 Internal server error

Při zpracovávání požadavku došlo k blíže nespecifikované chybě.

502 Bad Gateway

Proxy server nebo brána obdržely od serveru neplatnou odpověď.

503 Service unavailable

Služba je dočasně nedostupná.

504 Gateway Timeout

Proxy server nedostal od cílového serveru odpověď v daném čase.

505 HTTP Version Not Supported

Server nepodporuje verzi protokolu HTTP použitou v požadavku.

C.2

XML šablona produktu

<stk:stockHeader> <stk:id> <stk:stockType> <stk:code> <stk:EAN> <stk:isSales> <stk:isSerialNumber> <stk:isInternet> <stk:isBatch> <stk:purchasingRateVAT> <stk:sellingRateVAT> <stk:name> <stk:nameComplement> <stk:unit> 102

C.2. XML šablona produktu <stk:storage> <stk:typePrice> <stk:weightedPurchasePrice> <stk:purchasingPrice> <stk:sellingPrice> <stk:count> <stk:countReceivedOrders> <stk:reservation> <stk:supplier> <stk:orderQuantity> <stk:countIssuedOrders <stk:guaranteeType> <stk:guarantee> <stk:news> <stk:clearanceSale> <stk:sale> <stk:recommended> <stk:discount> <stk:availability/> <stk:handlingInformation/> <stk:categories/> <stk:relatedStocks/> <stk:alternativeStocks/> <stk:intParameters/> <stk:stockSerialNumber> <stk:serialNumberItem> <stk:id> <stk:serialNumber> <stk:count> <stk:stockPriceItem> <stk:stockPrice> 103

C. Komunikace Pohody Výstup z XSLT procesoru (input pro middleware): <prestashop> <product> espirito-cafe-gourmet Espirito Café Gourmet <price>250

C.3

XML šablona internetové kategorie

104

C.4. XML šablona adresáře Výstup z XSLT procesoru (input pro middleware): <parent/> Káva <description>popis kávy true <parent>Káva Arabika <description>arabika popis true <parent>Káva Robusta <description/> true <parent>Arabika Zrnková <description/> true

C.4

XML šablona adresáře

105

C. Komunikace Pohody Vojtěch Kozák programátor Vojtěch Kozák Lysá nad Labem U Branky 1846 28922 Středočeský kraj 777627205 [email protected] www.espirito.cz

C.5

XML šablona objednávky

receivedOrder 20100505A001 2013-04-14 Objednáváme u Vás zboží dle ústní dohody Espirito Café Vojtěch Kozák Lysá nad Labem U Branky 1846 28922 789456 CZ789456 PayPal 106

C.6. Seznam XSD schémat Sleva 1 Sestava PC 1 0 high 200 1 0 high 198

C.6

Seznam XSD schémat

XSD schéma definuje přesnou strukturu XML souboru. Program Pohoda má vytvořené pro každou agendu samostatné schéma, kde jsou definovány jednotlivé hodnoty agendy. XSD Schéma agendy se v programu Pohoda používá pro definici struktury vstupního i výstupního XML souboru. Schémata jsou dostupná na adrese http://www.stormware.cz/xml/schema/version_ 2/schema.xsd.

107

C. Komunikace Pohody

Tabulka C.2: Seznam XSD schémat Schéma

Popis

accountingunit.xsd

Schéma pro agendu Účetní jednotky.

addressbook.xsd

Schéma pro agendu Adresář.

balance.xsd

Schéma pro agendu Saldo.

category.xsd

Schéma pro agendu Kategorie internetového obchodu.

contract.xsd

Schéma pro agendu Zakázky.

data.xsd

Schéma pro validaci importu/požadavku na export. Obsahuje element dataPack, což je XML obálka kolem jednotlivých dokladů importovaných do Pohody nebo požadavků na export z Pohody. Tvoří root element vstupních XML souborů. Jeden dataPack může obsahovat elementy dataPackItem jak s doklady pro import, tak položky s požadavky na export.

data-package.xsd

Obdoba Data.xsd, s tím rozdílem, že při validaci se kontroluje jen obálka a ne samotné doklady.

enquiry.xsd

Schéma pro agendu Poptávky.

filter.xsd

Schéma pro obecné filtry na výběr dat.

individualprice.xsd

Schéma pro Individuální ceny zákazníka.

intDoc.xsd

Schéma pro agendu Interní doklady.

intParam.xsd

Schéma pro agendu Parametry internetového obchodu.

invoice.xsd

Schéma pro agendu Faktury.

list.xsd

Schéma pro sezmamy.

list_addBook.xsd

Schéma pro export Adres.

list_contract.xsd

Schéma pro export Zakázek.

list_stock.xsd

Schéma pro export Zásob.

offer.xsd

Schéma pro agendu Nabídky.

order.xsd

Schéma pro agendu Objednávky.

108

C.6. Seznam XSD schémat

Schéma

Popis

parameter.xsd

Schéma pro agendu Volitelné parametry.

prevodka.xsd

Schéma pro agendu Převod.

prijemka.xsd

Schéma pro agendu Příjemky.

prodejka.xsd

Schéma pro agendu Prodejky.

response.xsd

Schéma pro validaci výsledu importu/exportu. Obsahuje ResponsePack, což je obálka kolem jednotlivých dokladů exportovaných z Pohody nebo kolem výsledků importu jednotlivých dokladů. Každý responsePack odpovídá určitému dataPacku.

stock.xsd

Schéma pro agendu Zásoby.

supplier.xsd

Schéma pro Dodavatele na zásobě (pouze Pohoda E1).

type.xsd

Pomocné schéma pro obecné typy - na tyto typy je odkazováno z jiných schémat.

voucher.xsd

Schéma pro agendu Pokladna.

prodejka.xsd

Schéma pro agendu Výdejky.

vyroba.xsd

Schéma pro agendu Výroba.

data-package.xsd

Obdoba Data.xsd s tím rozdílem, že při validaci se kontroluje jen obálka a ne samotné doklady.

documentresponse.xsd

Odpověď (response) na import dokladů.

109

Příloha

Dokumentace D.1

Nastavení Pohody

Nastavení internetového obchodu v programu Pohoda provedete v agendě Internetové obchody, kterou otevřete kliknutím na menu Nastavení → Internetové obchody → Nastavení internetových obchodů (viz Obrázek D.1). Agenda Internetové obchody obsahuje několik variant internetových obchodů, proto při nastavení nového obchodu vyberte typ Obecný internetový obchod. Formulář pro nastavení se skládá z několika částí. Jedná se o záložky: Obecné, Klient, Export, Import a Nastavení. Agenda umožňuje vytvořit více internetových obchodů. Konkrétní obchod pro komunikace zvolíte až při samotné datové komunikaci.

Obrázek D.1: Agenda Obecný internetový obchod 111

D

D. Dokumentace

Obrázek D.2: Nastavení exportu v Pohodě

Na záložce Export nastavte následující adresy pro export (viz Obrázek D.2): URL pro Zásoby http://localhost:8080/export/products URL pro Objednávky http://localhost:8080/export/orders URL pro Adresář http://localhost:8080/export/customers URL pro Kategorie http://localhost:8080/export/categories V případě, že middleware běží na vzdáleném serveru, bude se základní adresa a port (localhost:8080) lišit. Pokud využíváte více internetových obchodů, můžete je odlišit přidáním proměnné shop k adrese URI, například ?shop=www.espirito.cz. Webová služba vyžaduje výstupní formát v jiném tvaru, než je formát Pohody. Proto je nutné pro každou položku nastavit XSLT transformaci: Zásoby export-zasoby.xslt Objednávky export-objednavky.xslt Adresář export-adresar.xslt Kategorie export-kategorie.xslt Nastavení importu v záložce Import provedete podobným způsobem jako v předchozím případě. Pokud používáte middleware na vzdáleném serveru, opět nastavte správnou základní adresu. Tu můžete obohatit o proměnnou 112

D.1. Nastavení Pohody

Obrázek D.3: Nastavení importu v Pohodě

shop, a zvolit tak obchod, ze kterého se bude importovat. URI pro import nastavte (viz Obrázek D.3): URL pro Zásoby http://localhost:8080/import/products URL pro Objednávky http://localhost:8080/import/orders URL pro Adresář http://localhost:8080/import/customers Před zpracováním dat v Pohodě je nutné importní data transformovat pomocí následujících XSLT souborů: Zásoby import-zasoby.xslt Objednávky import-objednavky.xslt Adresář import-adresar.xslt V záložce nastavení zaškrtněte „Kontrola duplicity importu“ a nastavte „Maximální dobu odpovědi“ na dobu ne kratší než 30 s. Verze XML komunikace musí být ve verzi 2 (viz Obrázek D.4). Internetové kategorie vytvoříte kliknutím na Nastavení → Internetové obchody → Kategorie internetových obchodů (viz Obrázek D.5). Zařazení produktu do kategorie se provádí na kartě produktu (Sklady → Zásoby). V přehledu produktu klikněte na záložku Internet a vyberte Kategorie. Každý produkt můžete zařadit do libovolné kombinace kategorií (viz Obrázek D.6). 113

D. Dokumentace

Obrázek D.4: Nastavení XML komunikace

Obrázek D.5: Vytvoření internetových kateogrií

114

D.2. Nastavení middlewaru

Obrázek D.6: Vložení produktu do kategorie

D.2

Nastavení middlewaru

Nastavení middlewaru se provádí v souboru conf.properties. Konfigurační soubor obsahuje nastavení uživatelského účtu pro kontrolu licencí a nastavení klíčů (vygenerované v nastavení webových služeb PrestaShopu) pro internetové obchody. Konfigurační soubor má strukturu: [email protected] PASSWORD=vojta kozakv.sin.cvut.cz/prestashop=UDMPGHE1DHCDT6RDZRUKQ9APOCWR0JLH www.espirito.cz=GGAF5Z239SLHYXEUSN945U6CKI2HAG0Y

D.3

Nastavení PrestaShopu

Před tím, než začnete využívat webové služby PrestaShopu, musíte tuto službu povolit, vytvořit nový účet a vygenerovat klíč, který použijete v nastavení mi-ddlewaru. Do administrace webových služeb se dostanete kliknutím na Advanced Parameters → Webservice (viz Obrázek D.7). Kliknutím na Add new můžete přidat nový účet. Pro lepší kompatibilitu s novějšími verzemi povolte všechny možnosti komunikace (viz Obrázek D.8).

115

D. Dokumentace

Obrázek D.7: Webové služby PrestaShopu

Obrázek D.8: Vytvoření nového účtu pro webové služby

116

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD exe ....................... adresář se spustitelnou formou implementace src impl...................................zdrojové kódy implementace tests ....................................... zdrojové soubory testů thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce DP_Kozak_Vojtech_2013.pdf ............ text práce ve formátu PDF video............................................videoukázky aplikace 117

E