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

Transkript

1

2

3 Č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

4

5 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.

6

7 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

8 Č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.

9 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

10

11 Obsah Úvod 1 1 Webové služby a XML SOAP REST XML, XSLT XSLT procesor Anatomie procesoru Saxon Saxon a zpracování velkých XML dokumentů Parsování XML dokumentů Analýza Volba metodiky Analýza požadavků Případy užití Analýza a předběžný návrh Detailní návrh Obecný export Export internetových kategorií Export skladových zásob Import skladových zásob Wrapper pro lokální běh middlewaru Implementace Zabezpečení RESTových služeb Middleware Webová služba na kontrolu licencí GUI aplikace pro spuštění lokální služby xi

12 xii OBSAH 5 Funkční testování Prostředí testování Kontrola vložení nového produktu Kontrola tvorby kategorií Měření nároků na výkon Měření vlastní aplikace Měření souvisejících aplikací Závěr 81 Literatura 83 A Seznam použitých zkratek 87 B Komunikace PrestaShopu 91 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 C Komunikace Pohody 101 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 D Dokumentace 111 D.1 Nastavení Pohody D.2 Nastavení middlewaru D.3 Nastavení PrestaShopu E Obsah přiloženého CD 117

13 Seznam obrázků 1.1 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 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 xiii

14 xiv Seznam obrázků 3.1 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 Sekvenční diagram spouštění wrapperu GUI okno pro běh lokálního middlewaru Vytvoření realmu v administraci GlassFishe GUI aplikace GUI aplikace debug mód Úspěšný průběh testu v programu SoapUI 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 D.1 Agenda Obecný internetový obchod D.2 Nastavení exportu v Pohodě D.3 Nastavení importu v Pohodě D.4 Nastavení XML komunikace D.5 Vytvoření internetových kateogrií D.6 Vložení produktu do kategorie D.7 Webové služby PrestaShopu D.8 Vytvoření nového účtu pro webové služby

15 Seznam tabulek 1.1 Operace v CRUD v architektonickém stylu REST Porovnání vlastností XML parserů Seznam HTTP požadavků pro export kategorií Seznam HTTP požadavků pro export produktů Jednosměrné symetrické algoritmy Asymetrický algoritmus RSA Asymetrický algoritmus DSA B.1 Možnosti rendrování C.1 Chybové kódy komunikace C.2 Seznam XSD schémat xv

16

17 Seznam výpisů 1.1 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 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) xvii

18

19 Ú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

20

21 Kapitola 1 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] 3

22 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] 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

23 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 <! -- struktura WSDL -- > 2 < description 3 xmlns:tns = http: // www. tmsws. com / wsdl20sample 4 targetnamespace = http: // www. tmsws. com / wsdl20sample >> 5 <! -- abstraktni definice -- > 6 < messages >... 7 < operation >... 8 < interface > <! -- konkretni definice -- > 11 < binding > < service > < endpoint > </ description > 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 < soap: envelope > 2 < soap:body > 3 < multiply > <! -- nazev procedury -- > 4 <a>8</a> <! parametr --> 5 <b>3.6 </b> <! parametr --> 6 </ multiply > 7 </ soap:body > 8 </ soap: envelope > 5

24 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 < soap: envelope > 2 < soap:body > 3 <! -- arbitrary XML --> 4 < movies xmlns = http: // www. myfavoritemovies. com > 5 <movie > 6 <title >2001 : A Space Odyssey </ title > 7 < released >1968 </ released > 8 </ movie > 9 <movie > 10 <title > Donnie Darko </ title > 11 < released >2001 </ released > 12 </ movie > 13 </ movies > 14 </ soap:body > 15 </ soap: envelope > 6

25 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

26 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 Akce s daty Create Retrieve Update Delete HTTP metoda POST GET PUT 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: # Odpověď se seznamem podporovaných metod daného zdroje HTTP/ No Content Allow: HEAD, GET, OPTIONS, PUT, DELETE GET Metoda GET slouží k získání reprezentace zdroje. 8

27 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: # Odpověď HTTP/ OK Content-Type: application/xml;charset=utf-8 Content-Length: xxx <coffee>... </coffee> 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: # Odpověď HTTP/ 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

28 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: Content-Type: application/xml;charset=utf-8 <product> <name>espirito Cafe Tanzania</name> </product> # Odpověď HTTP/ Created Location: Content-Location: Content-Type: application/xml;charset=utf-8 <product> <id>urn:espirito:produkty:1</id> <atom:link rel= self href= /> <name>espirito Cafe Tanzania</name> </product> 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

29 1.2. REST Příklad # Požadavek na vymazání zdroje DELETE /produkty/espirito-tanzanie HTTP/1.1 Host: # Odpověď HTTP/ 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: Accept: text/html [1] # Odpověď HTTP/ OK Content-Type: message/http TRACE /produkty/espirito-tanzanie HTTP/1.1 Host: Accept: text/html 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

30 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 < application xmlns = http: // wadl. dev. java. net /2009/02 > 2 < resources base = http: // example. com / api > 3 < resource path = books > 4 < method name = GET /> 5 < resource path = { bookid } > 6 <param required = true style = templ name = bookid /> 7 < method name = GET /> 8 </ resource > 9 </ resource > 10 </ resources > 11 </ application > 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 Unauthorized 3. 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 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 ( 12

31 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: HTTP/ 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: Authorization: Basic dm9qdge6agvzbg8= HTTP/ 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

32 1. Webové služby a XML MD5(MD5(<password>)+":"+<nonce>+":"+MD5(<method>+":"+<uri>)) Ukázka hlavičky úspěšného dotazu pomocí metody Digest Authentication: GET /user-area/ HTTP/1.1 Host: Authorization: Digest username="ivanr", realm="user Area", nonce="ogmpjb/jawa=7c5a49c2ed9416dba1b04b5307d6d935f74a859d", uri="/user-area/", algorithm=md5, response="3c430d26043cc306e0282", qop=auth, nc= , cnonce="c3bcee9534c051a0" HTTP/ OK Authentication-Info: rspauth="e18e79490b380eb645a3af0ff5abf0e4", cnonce="c3bcee9534c051a0", nc= , 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ř.: 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

33 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 W3C 4 definován obecný značkovací jazyk XML 5, aby oddělil strukturu obsahu od jeho prezentace. Na rozdíl od HTML, které má přesně danou sadu elementů, jsou jednotlivé elementy 6 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íku 8 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. 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

34 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í DOMu 9 a následně aplikovat XSLT na XML. Další možností je procesor založený na SAX 10. Výpis 1.5: Příklad XML dokumentu 1 <? xml version = 1.0 encoding = UTF -8?> 2 < produkty > 3 < prodkt typ = sluzba > Kodovani </ produkt > 4 < produkt typ = produkt druh = smes >Kava </ produkt > 5 </ produkty > 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

35 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 sek- 17

36 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 <? xml version = 1.0 encoding = UTF -8?> 2 < xsl:stylesheet version = xmlns:xsl = http: // /1999/ XSL / Transform > 4 < xsl:output method = text encoding = UTF -8 5 omit -xml - decleration = yes /> 6 7 < xsl:template match = / > 8 < xsl:apply - templates / > 9 </ xsl: template > < xsl:template match = produkty > 12 < xsl:apply - templates / > 13 </ xsl: template > < xsl:template match = produkt > 16 <xsl:value -of select /> je <xsl:value -of select =. />. 17 <xsl:apply - temlates select /> 18 </ xsl: template > < xsl:template match = produkt > 21 Tato <xsl:value -of select =.. /> je <xsl:value -of select =. />. 22 </ xsl: template > 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 kodovani je sluzba. 2 3 Kava je produkt. 4 Tato kava je smes. Výpis 1.7: Výsledek aplikace XSLT na XML 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ída- 18

37 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

38 1. Webové služby a XML Obrázek 1.7: Anatomie procesoru Saxon [11] pouze v komerční enterprise verzi označené Saxon-EE 11. 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 , 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 XSLT 3.0 je též známé jako XSLT

39 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ů 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

40 1. Webové služby a XML Tabulka 1.2: Porovnání vlastností XML parserů [22] Vlastnost StAX SAX DOM TrAX Typ API Pull str. Push str. In mem. tree pravidlo XSLT Jednoduchost vysoká střední vysoká střední XPath ne ne ano ano Výkonnost 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 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 <? xml version = 1.0?> 2 <doc > 3 <para >Hello, world!</ para > 4 </ doc > 5 6 start document 7 start element: doc 8 start element: para 9 characters: Hello, world! 10 end element: para 11 end element: doc 12 end document [29] 22

41 1.7. Parsování XML dokumentů 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] 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

42 1. Webové služby a XML 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 < prestashop > 2 < product > 3 < reference >espirito -cafe -15 </ reference > 4 < name > Espirito Cafe Espresso </ name > 5 <price >250 </ price > 6 </ product > 7 < product > 8 < reference >espirito -cafe -17 </ reference > 9 < name > Espirito Cafe Tarazzu </ name > 10 <price >320 </ price > 11 </ product > 12 </ prestashop > 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

43 Kapitola 2 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 klienta 13 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

44 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] Metodika ICONIX Process Pro vývoj vlastní aplikace jsem zvolil agilní metodiku ICONIX Process 14. 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] 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]

45 2.1. Volba metodiky Obrázek 2.1: ICONIX Process [12] Obrázek 2.2: Testování řízené návrhem V-model [26] 27

46 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 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 Logická softwarová funkce 28

47 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 Presta- Shopu. 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

48 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. 30 Diagram požadavků pro import popisuje Obrázek 2.8.

49 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

50 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

51 2.2. Analýza požadavků 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

52 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 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

53 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 Obrázek 2.15: Případ užití základní diagram 35

54 2. Analýza 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

55 2.4. Analýza a předběžný návrh 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 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

56 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

57 2.4. Analýza a předběžný návrh 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

58 2. Analýza 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 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 Obrázek 2.21: PPL problémová doména 40

59 Kapitola 3 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

60 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 <rsp:responsepack> s 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 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 <? xml version = 1.0 encoding = Windows -1250?> 2 < rsp:responsepack version = 1.0 id= state = ok 3 application = Transformace note = odpoved z e- shopu 4 xmlns:rsp = http: // www. stormware.cz/ schema / response. xsd > 5 </ rsp: responsepack > 42

61 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 < categories > 2 < category2 >... </ category2 > <! -- Kat. nejvyssi urovne -- > 3 < category3 >... </ category3 > <! -- Podkat. 1. urovne -- > 4 < category4 >... </ category4 > <! -- Podkat. 2. urovne -- > 5 </ categories > Výpis 3.3: Detail kategorie pro export 1 < category4 > 2 < parent >Kava </ parent > 3 < level_depth >4</ level_depth > 43

62 3. Detailní návrh 4 <name > Arabika </ name > 5 < description > arabika popis </ description > 6 </ category4 > Výpis 3.4: XML dokument kategorií ve formátu PrestaShopu 1 <? xml version = 1.0 encoding = UTF -8?> 2 < prestashop xmlns:xlink = http: // /1999/ xlink > 3 < category > 4 <id >2</id > 5 < id_parent >1</ id_parent > 6 < level_depth >1</ level_depth > 7 < is_root_category >1</ is_root_category > 8 <name >Home </ name > < category > </ prestashop > Obrázek 3.3: Zpracování internetových kategorií sekvenční diagram 44

63 3.3. Export skladových zásob 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í 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í 3.3 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

64 3. Detailní návrh Obrázek 3.4: Zpracování produktů sekvenční diagram 46

65 3.4. Import skladových zásob 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ů 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ů 3.4 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 < dat:datapack > 2 < dat:datapackitem id= a55 > 3 <! -- export zasoby --> 4 < lstk: liststockrequest > 5 < lstk: requeststock > 6 < ftr:filter > 7 <! -- export vsech zasob -- > 8 </ ftr:filter > 9 </ lstk: requeststock > 10 </ lstk: liststockrequest > 11 </ dat: datapackitem > 12 </ dat: datapack > 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

66 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ží. 1 < stk: actiontype > 2 < stk:add /> 3 </ stk: actiontype > Výpis 3.6: Vytvoření produktu v Pohodě 1 </ dat: datapack > 2 < dat: datapackitem > 3 < stk:stock > 4 Výpis 3.7: Aktualizace produktu v Pohodě 5 < stk: actiontype > 6 < stk:update > 7 < ftr:filter > 8 < ftr:code >B04 </ ftr:code > 9 <! -- kod zasoby --> 10 </ ftr:filter > 11 </ stk:update > 12 </ stk: actiontype > < stk:stockheader >... </ stk:stockheader > 15 </ stk:stock > 16 </ dat: datapackitem > 17 </ dat: datapack > 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 T23:12:50 (standardizovaný tvar). 48

67 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 <? xml version = 1.0 encoding = utf -8?> 2 <date > T23:12:50 </ date > Problém tohoto přístupu je v tom, že XSLT procesor Pohody neumožňuje všechny standardní funkce 16. Č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

68 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 Presta- Shopy, 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

69 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

70

71 Kapitola 4 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 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ě slo- 53

72 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 XSLT procesor Pro operace, které nelze provést v XSLT procesoru Pohody jsem použil Saxon-HE 9.4 ve verzi pro Javu 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/ OK Content-Type: application/xml <?xml version= 1.0 encoding= Windows-1250?> <response state= error /> 54

73 4.3. Webová služba na kontrolu licencí 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ů 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 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

74 4. Implementace 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 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/1.1 Host: glassfish.zserver.cz:8080 Authorization: Basic a296ywsudkbnbwfpbc5jb206dm9qdge= Příklad HTTP odpovědi: HTTP/ OK Content-Type: application/xml <customers> <customer> <licences> <licence> <customer>kozak.v@gmail.com</customer> <licencename>espirito.cz</licencename> </licence> </licences> <authusername>kozak.v@gmail.com</authusername> <id>1</id> </customer> </customers> 56

75 4.3. Webová služba na kontrolu licencí 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/1.1 Content-Type: application/xml <customer> <authusername>kozak.v@gmail.com</authusername> <authpassword>password</authpassword> <licences> <licence> <licencename>espirito.cz</licencename> </licence> </licences> </customer> 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/1.1 Content-Type: application/xml <customer> <id>1</id> <authusername>kozak.v@gmail.com</authusername> <authpassword>password</authpassword> </customer> DELETE /api/customer/{id} vymaže uživatele s ID zadaným v URI. Příklad HTTP požadavku: DELETE \ HTTP/1.1 57

76 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/1.1 Host: glassfish.zserver.cz:8080 Authorization: Basic dm9qdge6dm9qdge= Příklad HTTP odpovědi: HTTP/ OK Content-Type: application/xml <grouptables> <grouptable> <authusername>kozak.v@gmail.com</authusername> <groupid>1</groupid> <groupname>user</groupname> </grouptable> <grouptable> <authusername>kopecky@zserver.cz</authusername> <groupid>2</groupid> <groupname>admin</groupname> </grouptable> </grouptables> 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

77 4.3. Webová služba na kontrolu licencí POST \ HTTP/1.1 Host: glassfish.zserver.cz:8080 Content-Type: application/xml <grouptable> <groupname>admin</groupname> <authusername>kozakvoj@fit.cvut.cz</authusername> </grouptable> PUT /api/grouptable/{id} úprava zařazení uživatele do skupiny. Příklad HTTP požadavku: POST \ HTTP/1.1 Host: glassfish.zserver.cz:8080 Content-Type: application/xml <grouptable> <id>1</1> <groupname>admin</groupname> <authusername>kozakvoj@fit.cvut.cz</authusername> </grouptable> 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/1.1 Authorization: Basic dm9qdge6dm9qdge= Příklad HTTP odpovědi: HTTP/ OK Content-Type: application/xml <licences> <licence> <customer>kopecky@zserver.cz</customer> <customer_id>1</customer_id> 59

78 4. Implementace <licencename>zserver.cz/prestasshop</licencename> </licence> <licence> <customer_id>2</customer_id> <licencename>espirito.cz</licencename> </licence> </licences> POST /api/licence vytvoří novou licenci. Příklad HTTP požadavku: POST \ HTTP/1.1 Content-Type: application/xml <licence> <customer_id>2</customer_id> <licencename>espirito.cz</licencename> </licence> 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/1.1 Content-Type: application/xml <licence> <id>1</id> <customer_id>2</customer_id> <licencename>espirito.cz</licencename> </licence> DELETE /api/licence/{id} vymaže licenci s ID zadaným v URI. Příklad HTTP požadavku: 60 DELETE \ HTTP/1.1 Authorization: Basic dm9qdge6dm9qdge=

79 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/ 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 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 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

80 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ř.: USERNAME=kozak.v@gmail.com 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 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ří: 62 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.

81 4.4. GUI aplikace pro spuštění lokální služby Obrázek 4.3: GUI aplikace debug mód 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

82

83 Kapitola 5 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: PrestaShop base URI: klíč: UDMPGHE1DHCDT6RDZRUKQ9APOCWR0JLH Kontrola licencí base URI: přihlašovací údaje: jméno kozakvoj, heslo vojta 65

84 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/1.1 Content-Type: application/xml... <?xml version= 1.0 encoding= Windows-1250?> <prestashop> <product> <reference>espirito-cafe-15</reference> <name>espirito Cafe Espresso</name> <reference>esp15</reference> <price>275</price> <decription>vynikající káva</description>... </product> </prestashop> 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/ OK X-Powered-By: JSP/2.2 Server: GlassFish Server Open Source Edition Content-Type: text/xml;charset=windows <?xml version= 1.0 encoding= Windows-1250?> <response state= ok /> Automatická kontrola odpovědi je realizována pomocí assertů. Kontrolují se hodnoty: 66 Doba odpovědi nesmí překročit 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:

85 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 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/ OK Server: Apache/ (Win32) PHP/ X-Powered-By: PrestaShop Webservice Content-Type: text/xml;charset=utf-8... <?xml version= 1.0 encoding= UTF-8?> <prestashop xmlns:xlink= > <products> <product id= 70 xlink: href={apiproducturi}/70 /> </products> </prestashop> 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

86 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: <lst:listcategory> <lst:categorydetail version= 1.0 > <ctg:category> <ctg:name>káva</ctg:name> <ctg:subcategories> <ctg:category> 68

87 5.3. Kontrola tvorby kategorií <ctg:name>arabika</ctg:name> <ctg:subcategories> <ctg:category> <ctg:name>zrnková</ctg:name> </ctg:category> <ctg:category> <ctg:name>mletá</ctg:name> </ctg:category> </ctg:subcategories> </ctg:category> <ctg:category> <ctg:name>robusta</ctg:name> </ctg:category> </ctg:subcategories> </ctg:category> </lst:categorydetail> </lst:listcategory> 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

88 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

89 Kapitola 6 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í 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í 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

90 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ž 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 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

91 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á 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 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

92 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 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í Presta- Shop. Ten byl nasazen na samostatném VPS (procesor: 1 vlákno Xeon E5-2650L 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 Presta- Shopu, 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 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 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

93 6.1. Měření vlastní aplikace Obrázek 6.2: PPL závislost počtu požadavků na době odezvy 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 X ,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 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 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

94 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 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

95 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ě 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 J 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: nodes, characters, 0 attributes Execution time: 1448 milliseconds Memory used: 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

96 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 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 přihlašovacími operacemi za sekundu (Tabulka 6.2). U stejně dlouhého DSA šifrování pak 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

97 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] md hmac sha rc des cbc des ede rc2 cbc aes aes aes Tabulka 6.2: Asymetrický algoritmus RSA b sign [s] verify [s] sign/s verify/s 512 7, , , , , , , , , , , , , , ,6 Tabulka 6.3: Asymetrický algoritmus DSA b sign [s] verify [s] sign/s verify/s 512 7, , , , , , , , , , , ,3 79

98

99 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

100

101 Literatura [1] Allamaraju, S.: RESTful Web Service Cookbook. O Reilly Media, 2010, ISBN [2] Anand, V.: Using HTTP Methods in REST. [online], říjen 2012, [cit ]. Dostupné z: /10/using_http_methods_in_rest [3] Angstadt, M.: WSDL SOAP bindings confusion - RPC vs document. [online], květen 2011, [cit ]. Dostupné z: 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 ]. Dostupné z: wsdl-soap-bindings-confusion-rpc-vs.html [5] Cerami, E.: Web Service Essentials: Distributed Applications with XML- RPC, SOAP, UDDI & WSDL. O Reilly, 2002, ISBN [6] Daigneau, R.: Service Design Patterns: fundamental design solutions for SOAP/WSDL and RESTful Web Services. Addison-Wesley, 2012, ISBN [7] Dhesiaseelan, A.: What s New in WSDL 2.0. [online], [cit ]. Dostupné z: [8] Hadley, M.: Web Application Description Language. [online], srpen 2009, [cit ]. Dostupné z: [9] Haufler, A.: Conveniently Processing Large XML Files with Java. [online], říjen 2012, [cit ]. Dostupné z: articles/conveniently-processing-large 83

102 Literatura [10] Hock-Chuan, C.: Java Programming Java & XML. [online], březen 2009, [cit ]. Dostupné z: programming/java/j6d_xml.html [11] Saxon: Anatomy of an XSLT processor. [online], duben 2005, [cit ]. Dostupné z: x-xslt2/ [12] ICONIX Process Overview. [online], [cit ]. Dostupné z: http: //iconixprocess.com/iconix-process/ [13] Jonathan Robie, T. R.: What is the Document Object Model? [online], [cit ]. Dostupné z: introduction.html [14] Kadlec, V.: Agilní programování Metodiky efektivního vývoje software. Computer Press, 2004, ISBN [15] Kay, M.: Streaming of Large Documents. [online], [cit ]. Dostupné z: streaming.xml [16] Kay, M.: XSLT 2.0 and XPath 2.0 Programmer s Reference. Wrox, 2011, ISBN [17] Kosek, J.: Inteligentní podpora navigace na WWW s využitím XML. [online], květen 2002, [cit ]. Dostupné z: 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, [19] Laurie, B.: Digest Authentication. [online], únor 1999, [cit ]. Dostupné z: htm/ [20] Mendel, L.: Describe REST Web services with WSDL 2.0. IBM developerworks. [online], květen 2008, [cit ]. Dostupné z: [21] Merunka, V.: Metoda tvorby informačních systémů. [online]. Dostupné z: [22] Why StAX? [online], [cit ]. 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 ]. Dostupné z: 84

103 Literatura [24] Pfeifer, C.: XML Processing with TRaX. [online], červen 2001, [cit ]. Dostupné z: 02/trax.html [25] Ristic, I.: Apache Security. O Reilly Media, 2005, ISBN [26] Rosenberg, D.: Testování softwaru řízené návrhem. Computer Press, 2011, ISBN [27] Sandoval, J.: RESTful Java Web Services. Packt Publishing, 2009, ISBN [28] Skonnard, A.: Understanding WSDL. [online], říjen 2003, [cit ]. Dostupné z: aspx [29] Events vs. Trees. [online], [cit ]. Dostupné z: sourceforge.net/event.html [30] Obecný internetový obchod. [online], květen 2011, [cit ]. Dostupné z: aspx [31] Tidwell, D.: XSLT, 2nd Edition. O Reilly Media, 2008, ISBN

104

105 Příloha A 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

106 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

107 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

108

109 Příloha B 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

110 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

111 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 [field1_asc/desc,..] Řazení podle zadaných polí 93

112 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 <?xml version= 1.0 encoding= UTF-8?> <prestashop xmlns:xlink= > <product> <id></id> <id_manufacturer></id_manufacturer> <id_supplier></id_supplier> <id_category_default></id_category_default> <new></new> <cache_default_attribute></cache_default_attribute> <id_default_image></id_default_image> <id_default_combination></id_default_combination> <id_tax_rules_group></id_tax_rules_group> <id_shop_default></id_shop_default> <reference></reference> <supplier_reference></supplier_reference> <location></location> <width></width> <height></height> <depth></depth> <weight></weight> <quantity_discount></quantity_discount> <ean13></ean13> <upc></upc> <cache_is_pack></cache_is_pack> <cache_has_attachments></cache_has_attachments> <is_virtual></is_virtual> <on_sale></on_sale> <online_only></online_only> <ecotax></ecotax> <minimal_quantity></minimal_quantity> <price></price> <wholesale_price></wholesale_price> <unity></unity> <unit_price_ratio></unit_price_ratio> 94

113 B.3. XML šablona pro vytvoření produktu <additional_shipping_cost></additional_shipping_cost> <customizable></customizable> <text_fields></text_fields> <uploadable_files></uploadable_files> <active></active> <redirect_type></redirect_type> <id_product_redirected></id_product_redirected> <available_for_order></available_for_order> <available_date></available_date> <condition></condition> <show_price></show_price> <indexed></indexed> <visibility></visibility> <advanced_stock_management></advanced_stock_management> <date_add></date_add> <date_upd></date_upd> <meta_description>lng tag</meta_description> <meta_keywords>lng tag</meta_keywords> <meta_title>lng tag</meta_title> <link_rewrite>lng tag</link_rewrite> <name>lng tag</name> <description>lng tag</description> <description_short>lng tag</description_short> <available_now>lng tag</available_now> <available_later>lng tag</available_later> <associations> <categories> <category><id></id></category> </categories> <images> <image><id></id></image> </images> <combinations> <combination><id></id></combination> </combinations> <product_option_values> <product_options_values> <id></id> </product_options_values> </product_option_values> <product_features> <product_feature> <id></id> <id_feature_value></id_feature_value> 95

114 B. Komunikace PrestaShopu </product_feature> </product_features> <tags> <tag><id></id></tag> </tags> <stock_availables> <stock_available> <id></id> <id_product_attribute></id_product_attribute> </stock_available> </stock_availables> <accessories> <product><id></id></product> </accessories> </associations> </product> </prestashop> B.4 XML šablona pro vytvoření kategorie <?xml version= 1.0 encoding= UTF-8?> <prestashop xmlns:xlink= > <category> <id/> <id_parent/> <active/> <id_shop_default/> <is_root_category/> <position/> <date_add/> <date_upd/> <name>lng tag</name> <link_rewrite>lng tag</link_rewrite> <description>lng tag</description> <meta_title>lng tag</meta_title> <meta_description>lng tag</meta_description> <meta_keywords>lng tag</meta_keywords> <associations> <categories> <category><id/></category> </categories> <products> <product><id/></product> 96

115 B.5. XML šablona pro vytvoření objednávky </products> </associations> </category> </prestashop> B.5 XML šablona pro vytvoření objednávky <?xml version= 1.0 encoding= UTF-8?> <prestashop xmlns:xlink= > <order> <id></id> <id_address_delivery></id_address_delivery> <id_address_invoice></id_address_invoice> <id_cart></id_cart> <id_currency></id_currency> <id_lang></id_lang> <id_customer></id_customer> <id_carrier></id_carrier> <current_state></current_state> <module></module> <invoice_number></invoice_number> <invoice_date></invoice_date> <delivery_number></delivery_number> <delivery_date></delivery_date> <valid></valid> <date_add></date_add> <date_upd></date_upd> <id_shop_group></id_shop_group> <id_shop></id_shop> <secure_key></secure_key> <payment></payment> <recyclable></recyclable> <gift></gift> <gift_message></gift_message> <total_discounts></total_discounts> <total_discounts_tax_incl></total_discounts_tax_incl> <total_discounts_tax_excl></total_discounts_tax_excl> <total_paid></total_paid> <total_paid_tax_incl></total_paid_tax_incl> <total_paid_tax_excl></total_paid_tax_excl> <total_paid_real></total_paid_real> <total_products></total_products> <total_products_wt></total_products_wt> 97

116 B. Komunikace PrestaShopu <total_shipping></total_shipping> <total_shipping_tax_incl></total_shipping_tax_incl> <total_shipping_tax_excl></total_shipping_tax_excl> <carrier_tax_rate></carrier_tax_rate> <total_wrapping></total_wrapping> <total_wrapping_tax_incl></total_wrapping_tax_incl> <total_wrapping_tax_excl></total_wrapping_tax_excl> <shipping_number></shipping_number> <conversion_rate></conversion_rate> <reference></reference> <associations> <order_rows> <order_row> <id></id> <product_id></product_id> <product_attribute_id></product_attribute_id> <product_quantity></product_quantity> <product_name></product_name> <product_price></product_price> </order_row> </order_rows> </associations> </order> </prestashop> B.6 XML šablona pro vytvoření zákazníka <?xml version= 1.0 encoding= UTF-8?> <prestashop xmlns:xlink= > <customer> <id></id> <id_default_group></id_default_group> <newsletter_date_add></newsletter_date_add> <ip_registration_newsletter></ip_registration_newsletter> <last_passwd_gen></last_passwd_gen> <secure_key></secure_key> <deleted></deleted> <passwd></passwd> <lastname></lastname> <firstname></firstname> < ></ > <id_gender></id_gender> <birthday></birthday> 98

117 B.6. XML šablona pro vytvoření zákazníka <newsletter></newsletter> <optin></optin> <website></website> <company></company> <siret></siret> <ape></ape> <outstanding_allow_amount></outstanding_allow_amount> <show_public_prices></show_public_prices> <id_risk></id_risk> <max_payment_days></max_payment_days> <active></active> <note></note> <is_guest></is_guest> <id_shop></id_shop> <id_shop_group></id_shop_group> <date_add></date_add> <date_upd></date_upd> <associations> <groups> <group> <id></id> </group> </groups> </associations> </customer> </prestashop> 99

118

119 Příloha C 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 Vypršel časový limit na odpověď serveru Bad request 401 Unauthorized 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. 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. Požadavek nemůže být vyřízen, poněvadž byl syntakticky nesprávně zapsán. 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

120 C. Komunikace Pohody Chyba 405 Method Not Allowed 408 Request Timeout 500 Internal server error 502 Bad Gateway 503 Service unavailable 504 Gateway Timeout 505 HTTP Version Not Supported Popis chyby 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. Vypršel čas vyhrazený na zpracování požadavku. Při zpracovávání požadavku došlo k blíže nespecifikované chybě. Proxy server nebo brána obdržely od serveru neplatnou odpověď. Služba je dočasně nedostupná. Proxy server nedostal od cílového serveru odpověď v daném čase. Server nepodporuje verzi protokolu HTTP použitou v požadavku. C.2 XML šablona produktu <rsp:responsepack xmlns...> <rsp:responsepackitem version= 1.0 id= a55 state= ok > <lstk:liststock version= 2.0 datetimestamp= datevalidfrom= state= ok > <lstk:stock version= 2.0 > <stk:stockheader> <stk:id></stk:id> <stk:stocktype></stk:stocktype> <stk:code></stk:code> <stk:ean></stk:ean> <stk:issales></stk:issales> <stk:isserialnumber></stk:isserialnumber> <stk:isinternet></stk:isinternet> <stk:isbatch></stk:isbatch> <stk:purchasingratevat></stk:purchasingratevat> <stk:sellingratevat></stk:sellingratevat> <stk:name></stk:name> <stk:namecomplement></stk:namecomplement> <stk:unit></stk:unit> 102

121 C.2. XML šablona produktu <stk:storage> <typ:id></typ:id> <typ:ids></typ:ids> </stk:storage> <stk:typeprice> <typ:id></typ:id> <typ:ids></typ:ids> </stk:typeprice> <stk:weightedpurchaseprice></stk:weightedpurchaseprice> <stk:purchasingprice></stk:purchasingprice> <stk:sellingprice></stk:sellingprice> <stk:count></stk:count> <stk:countreceivedorders></stk:countreceivedorders> <stk:reservation></stk:reservation> <stk:supplier><typ:id></typ:id></stk:supplier> <stk:orderquantity></stk:orderquantity> <stk:countissuedorders</stk:countissuedorders> <stk:guaranteetype></stk:guaranteetype> <stk:guarantee></stk:guarantee> <stk:news></stk:news> <stk:clearancesale></stk:clearancesale> <stk:sale></stk:sale> <stk:recommended></stk:recommended> <stk:discount></stk:discount> <stk:availability/> <stk:handlinginformation/> <stk:categories/> <stk:relatedstocks/> <stk:alternativestocks/> <stk:intparameters/> </stk:stockheader> <stk:stockserialnumber> <stk:serialnumberitem> <stk:id></stk:id> <stk:serialnumber></stk:serialnumber> <stk:count></stk:count> </stk:serialnumberitem> </stk:stockserialnumber> <stk:stockpriceitem> <stk:stockprice> <typ:id></typ:id> <typ:ids></typ:ids> <typ:price></typ:price> </stk:stockprice> 103

122 C. Komunikace Pohody </stk:stockpriceitem> </lstk:stock> </lstk:liststock> </rsp:responsepackitem> </rsp:responsepack> Výstup z XSLT procesoru (input pro middleware): <prestashop> <product> <reference>espirito-cafe-gourmet</reference> <name>espirito Café Gourmet</name> <price>250</price> </product> </prestashop> C.3 XML šablona internetové kategorie <rsp:responsepack xmlns...> <rsp:responsepackitem version= 1.0 id= a56 state= ok > <lst:listcategory version= 1.0 datetimestamp= datevalidfrom= state= ok > <lst:categorydetail version= 1.0 > <ctg:category> <ctg:id></ctg:id> <ctg:name></ctg:name> <ctg:description/> <ctg:sequence></ctg:sequence> <ctg:displayed></ctg:displayed> <ctg:picture/> <ctg:note/> <ctg:internetparams> <ctg:idinternetparams/> </ctg:internetparams> <ctg:subcategories> <ctg:category> <ctg:id></ctg:id> <ctg:name></ctg:name> <ctg:description/> <ctg:sequence></ctg:sequence> <ctg:displayed></ctg:displayed> <ctg:picture/> <ctg:note/> <ctg:internetparams> 104

123 C.4. XML šablona adresáře <ctg:idinternetparams/> </ctg:internetparams> </ctg:category> </ctg:subcategories> </ctg:category> </lst:categorydetail> </lst:listcategory> </rsp:responsepackitem> </rsp:responsepack> Výstup z XSLT procesoru (input pro middleware): <categories> <category2> <parent/> <name>káva</name> <description>popis kávy</description> <active>true</active> </category2> <category3> <parent>káva</parent> <name>arabika</name> <description>arabika popis</description> <active>true</active> </category3> <category3> <parent>káva</parent> <name>robusta</name> <description/> <active>true</active> </category3> <category4> <parent>arabika</parent> <name>zrnková</name> <description/> <active>true</active> </category4> </categories> C.4 XML šablona adresáře <dat:datapackitem id= AD002 version= 2.0 > <adb:addressbook version= 2.0 > <!-- import kontaktní osoby --> 105

124 C. Komunikace Pohody <adb:addressbookheader> <adb:identity> <typ:address> <typ:company>vojtěch Kozák</typ:company> <typ:division>programátor</typ:division> <typ:name>vojtěch Kozák</typ:name> <typ:city>lysá nad Labem</typ:city> <typ:street>u Branky 1846</typ:street> <typ:zip>28922</typ:zip> </typ:address> </adb:identity> <adb:region>středočeský kraj</adb:region> <adb:mobil> </adb:mobil> <adb:web> </adb:addressbookheader> </adb:addressbook> </dat:datapackitem> C.5 XML šablona objednávky <dat:datapackitem id= OBJ001 version= 2.0 > <ord:order version= 2.0 > <!-- import prijate objednavky s polozkami z internetového \ obchodu --> <ord:orderheader> <ord:ordertype>receivedorder</ord:ordertype> <ord:numberorder> a001</ord:numberorder> <ord:date> </ord:date> <ord:text>objednáváme u Vás zboží dle ústní dohody</ord:text> <ord:partneridentity> <typ:address> <typ:company>espirito Café</typ:company> <typ:name>vojtěch Kozák</typ:name> <typ:city>lysá nad Labem</typ:city> <typ:street>u Branky 1846</typ:street> <typ:zip>28922</typ:zip> <typ:ico>789456</typ:ico> <typ:dic>cz789456</typ:dic> </typ:address> </ord:partneridentity> <ord:paymenttype> <typ:ids>paypal</typ:ids> 106

125 C.6. Seznam XSD schémat </ord:paymenttype> <ord:pricelevel> <typ:ids>sleva 1</typ:ids> </ord:pricelevel> </ord:orderheader> <ord:orderdetail> <!-- textova polozka --> <ord:orderitem> <ord:text>sestava PC</ord:text> <ord:quantity>1</ord:quantity> <ord:delivered>0</ord:delivered> <ord:ratevat>high</ord:ratevat> <ord:homecurrency> <typ:unitprice>200</typ:unitprice> </ord:homecurrency> </ord:orderitem> <!-- skladova polozka --> <ord:orderitem> <ord:quantity>1</ord:quantity> <ord:delivered>0</ord:delivered> <ord:ratevat>high</ord:ratevat> <ord:homecurrency> <typ:unitprice>198</typ:unitprice> </ord:homecurrency> </ord:orderitem> </ord:orderdetail> </ord:order> </dat:datapackitem> 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 2/schema.xsd. 107

126 C. Komunikace Pohody Tabulka C.2: Seznam XSD schémat Schéma accountingunit.xsd addressbook.xsd balance.xsd category.xsd contract.xsd data.xsd data-package.xsd enquiry.xsd filter.xsd individualprice.xsd intdoc.xsd intparam.xsd invoice.xsd list.xsd list_addbook.xsd list_contract.xsd list_stock.xsd offer.xsd order.xsd Popis Schéma pro agendu Účetní jednotky. Schéma pro agendu Adresář. Schéma pro agendu Saldo. Schéma pro agendu Kategorie internetového obchodu. Schéma pro agendu Zakázky. 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. Obdoba Data.xsd, s tím rozdílem, že při validaci se kontroluje jen obálka a ne samotné doklady. Schéma pro agendu Poptávky. Schéma pro obecné filtry na výběr dat. Schéma pro Individuální ceny zákazníka. Schéma pro agendu Interní doklady. Schéma pro agendu Parametry internetového obchodu. Schéma pro agendu Faktury. Schéma pro sezmamy. Schéma pro export Adres. Schéma pro export Zakázek. Schéma pro export Zásob. Schéma pro agendu Nabídky. Schéma pro agendu Objednávky. 108

127 C.6. Seznam XSD schémat Schéma parameter.xsd prevodka.xsd prijemka.xsd prodejka.xsd response.xsd stock.xsd supplier.xsd type.xsd voucher.xsd prodejka.xsd vyroba.xsd data-package.xsd documentresponse.xsd Popis Schéma pro agendu Volitelné parametry. Schéma pro agendu Převod. Schéma pro agendu Příjemky. Schéma pro agendu Prodejky. 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. Schéma pro agendu Zásoby. Schéma pro Dodavatele na zásobě (pouze Pohoda E1). Pomocné schéma pro obecné typy - na tyto typy je odkazováno z jiných schémat. Schéma pro agendu Pokladna. Schéma pro agendu Výdejky. Schéma pro agendu Výroba. Obdoba Data.xsd s tím rozdílem, že při validaci se kontroluje jen obálka a ne samotné doklady. Odpověď (response) na import dokladů. 109

128

129 Příloha D 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

130 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 URL pro Objednávky URL pro Adresář URL pro Kategorie 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= 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

131 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 URL pro Objednávky URL pro Adresář 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

132 D. Dokumentace Obrázek D.4: Nastavení XML komunikace Obrázek D.5: Vytvoření internetových kateogrií 114

133 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: USERNAME=kozak.v@gmail.com PASSWORD=vojta kozakv.sin.cvut.cz/prestashop=udmpghe1dhcdt6rdzrukq9apocwr0jlh 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

134 D. Dokumentace Obrázek D.7: Webové služby PrestaShopu Obrázek D.8: Vytvoření nového účtu pro webové služby 116