VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika
Napojení e-shopu na obchodní portál a u k ro . c z bakalářská práce
Autor: Josef Vrbata Vedoucí práce: Ing. Pavel Matějka Jihlava 2013
Anotace Cílem této práce je rozšíření e-shopového řešení firmy Komtesa s.r.o. o možnost vystavovat
produkty na portálu
aukro.cz.
Výsledné rozšíření
je vytvořeno
v programovacím jazyce PHP za pomoci SOAPových služeb. První část práce má za cíl teoreticky seznámit čtenáře s problematikou komunikace s portálem aukro.cz. Druhá část práce je věnována popisu vývoje napojení e-shopu firmy Komtesa s.r.o., které vychází z teoretické části.
Klíčová slova Aukro, PHP, SOAP, e-shop, webová aplikace
Abstract The aim of this thesis is to expand the opportunity to exhibit products at the portal aukro.cz using e-commerce solution owned by the Komtesa s.r.o. company. The final extension is written in the PHP programming language and it is based SOAP services. The first part of this thesis is intended to theoretically explain the communication with the portal aukro.cz. The second part, based on the theoretical part, describes the development of the connection between e-commerce solution by Komtesa s.r.o. and the portal aukro.cz.
Key words Aukro, PHP, SOAP, e-shop, web application
Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval firmě Komtesa s.r.o. za poskytnutí tématu a prostředků ke zpracování této bakalářské práce, především Ing. Pavlu Matějkovi, jakožto vedoucímu práce. Dále bych chtěl poděkovat Janu Prokešovi za poskytnutí rad a připomínek ke zvolenému způsobu řešení, které mi pomohly při tvorbě praktické části práce.
Obsah 1
Úvod a cíl práce ........................................................................................................ 8
2
Portál aukro.cz ........................................................................................................ 10
3
4
2.1
Představení portálu aukro.cz ............................................................................ 10
2.2
Princip prodeje prostřednictvím Aukra ............................................................ 11
Řešení elektronického obchodu firmy Komtesa s. r. o. .......................................... 13 3.1
Redakční systém Joomla! ................................................................................. 13
3.2
redSHOP .......................................................................................................... 14
Princip propojení Aukra a elektronického obchodu ............................................... 15 4.1
5
webAPI............................................................................................................. 15
Analýza ................................................................................................................... 17 5.1
Konektor ........................................................................................................... 17
5.2
Struktura konektoru .......................................................................................... 17
5.2.1
Nastavení propojení .................................................................................. 18
5.2.2
Základní nastavení .................................................................................... 18
5.2.3
Předdefinované volby ............................................................................... 18
5.2.4
Doprava a platba ....................................................................................... 19
5.3
Mapování kategorií .......................................................................................... 19
5.4
Mapování atributů ............................................................................................ 20
5.5
Administrace produktů ..................................................................................... 20
5.6
Automatické vystavování produktů ................................................................. 20
5.6.1
6
5.7
Logování .......................................................................................................... 21
5.8
Objednávky ...................................................................................................... 22
Použité prostředky .................................................................................................. 23 6.1
Joomla! Platform .............................................................................................. 23
6.1.1
Princip vývoje aplikací pro CMS Joomla!................................................ 24
6.1.2
Komponenta .............................................................................................. 24
6.1.3
Modul ........................................................................................................ 24
6.1.4
Plugin ........................................................................................................ 25
6.1.5
Shrnutí ....................................................................................................... 25
6.2
Aukro webAPI ................................................................................................. 26
6.2.1 7
Vystavení .................................................................................................. 21
SOAP ........................................................................................................ 26
Návrh a implementace konektoru ........................................................................... 28 7.1
Požadavky na konektor .................................................................................... 28
7.2
Globální nastavení ............................................................................................ 28
7.3
Mapování kategorií .......................................................................................... 29
7.3.1
Dostupné kategorie Aukra ........................................................................ 31
7.4
Mapování atributů ............................................................................................ 32
7.5
Úprava karty produktu ..................................................................................... 32
7.6
Vystavení produktů .......................................................................................... 34
7.7
Stahování objednávek ...................................................................................... 35
7.8
Logování událostí ............................................................................................. 35
8
Testování ................................................................................................................. 37
9
Srovnání s existujícími řešeními ............................................................................. 38
10
Závěr ....................................................................................................................... 40 10.1
Zhodnocení ................................................................................................... 40
10.2
Budoucnost ................................................................................................... 41
Seznam použité literatury ............................................................................................... 42 Seznam obrázků .............................................................................................................. 43 Seznam použitých zkratek .............................................................................................. 44 Přílohy............................................................................................................................. 45 Obsah přiloženého CD ................................................................................................ 45
1 Úvod a cíl práce Jako každý student Vysoké školy polytechnické Jihlava oboru Aplikovaná informatika, jsem musel absolvovat povinnou školní praxi. V rámci této praxe jsem se dostal do firmy Komtesa s.r.o. sídlící v Havlíčkově Brodě. Tato firma se zabývá vývojem internetových aplikací a elektronických obchodů převážně na platformě Joomla. V rámci mé praxe zazněla otázka, zda nevytvořit propojení mezi Aukrem a řešením internetového obchodu této firmy. Na možnost propojení se již několik zákazníků dotazovalo, popřípadě zda to bude možné v budoucnosti. Propojením internetového obchodu s Aukrem získají zákazníci firmy Komtesa jisté výhody. Budou moci nabízet zboží prostřednictvím svého portálu, ale také budou moci využít možnosti vystavit své produkty na portálu aukro.cz, kde by se mohlo vyskytovat více potencionálních zákazníků. Vystavováním produktů na aukro.cz se pak vystavující dostává do povědomí kupujících, získá jejich důvěru a možná i pravidelné a vracející se zákazníky. Díky propojení získá vystavující nový prodejní kanál, prostřednictvím něhož by mohlo dojít k nárůstu obratu. Výhody plynou i pro firmu Komtesa, která tak implementací napojení e-shopového řešení na portál aukro.cz získá jistou konkurenční výhodu, protože tato funkčnost nepatří mezi standardní funkčnost, kterou konkurenční řešení disponují. Toto téma mě zaujalo, proto jsem si ho vybral jako téma své bakalářské práce. Aby mohlo být propojení realizováno prakticky, je zapotřebí nastudovat teoretickou část problému. Zadaný problém spočívá v komunikaci Aukra s internetovým obchodem dodávaným firmou Komtesa. Aukro poskytuje WebAPI, které umožňuje komunikaci mezi Aukrem a patřičnou druhou stranou. Je tedy nutné nastudovat patřičné programové vybavení, pomocí kterého dojde k realizaci samotného propojení. Dále je potřebné nastudovat strukturu propojení. Propojení společnost Aukro nazývá konektor. Konektor musí splňovat určitá kritéria, aby byl funkční a efektivní. V této práci se proto budu věnovat stručnému popisu obou komunikujících stran a následně největší část teorie bude věnována popisu struktury konektoru, protože se jedná o klíčovou část celého systému. Na základě nabytých teoretických znalostí bude navržen a implementován konektor spojující portál aukro.cz s e-shopovým řešením. Řešení internetového obchodu 8
společnosti Komtesa je naprogramováno v jazyce PHP jako nadstavba redakčního systému Joomla. Při implementaci nové funkčnosti budu tedy vycházet ze stávající struktury, která bude rozšířena o novou funkčnost. Mezi hlavní body, které by měly být implementovány, patří správa a vystavování produktů na portál aukro.cz a následné stahování objednávek zpět do e-shopu.
9
2 Portál aukro.cz 2.1 Představení portálu aukro.cz Aukro.cz je internetový portál. Jedná se o elektronickou aukční síň, která podporuje aukce i prodej a nákup za pevné ceny. V Čechách působí od srpna roku 2003. V současné době se jedná o jeden z největších internetových obchodů a o největší internetovou aukční síň na českém trhu. [1]Chyba! Záložka není definována.
Obrázek 1: Úvodní strana portálu aukro.cz
10
Mateřskou společností je polská společnost Allegro Group, která je zároveň majoritním vlastníkem. Allegro Group je součástí nadnárodní mediální skupiny Naspers, která má původ v Jihoafrické republice. Společnost Aukro převzala model polského portálu allegro.pl. [1] V současné době využívá tento obchodní portál více než 1 milion uživatelů. Každý rok se prostřednictvím Aukra prodá více než 6 milionů předmětů v celkové hodnotě 2,5 miliardy Kč. [1]
2.2 Princip prodeje prostřednictvím Aukra Od většiny ostatních internetových obchodů se portál aukro.cz kromě své velikosti odlišuje nabízenými produkty a způsobem prodeje. Většina internetových obchodů je zaměřena na určitý segment trhu, např. počítačové komponenty, domácí spotřebiče, oblečení určité značky, nábytek atp. Aukro nabízí veškerý sortiment zboží. Této široké škály bylo docíleno systémem, na kterém je portál aukro.cz postaven. Tento portál není vlastníkem nabízených předmětů. Aukro funguje jako prostředník mezi prodávajícím a kupujícím. Prodávajícímu je umožněno na určitou dobu vystavit své zboží. Za vystavení produktu zaplatí určitou peněžní částku v závislosti na druhu zboží, které vystavuje. V tuto chvíli má zákazník dvě možnosti, jak dané zboží nakoupit. První možností je koupit zboží za takzvanou cenu „Kup teď!“. Tento způsob nákupu se neliší od ostatních internetových obchodů. Zákazník si vybere zboží, které chce koupit, vloží ho do košíku, vybere způsob platby a dopravy a zboží objedná za cenu označenou jako „Kup teď!“. Druhou variantou, jak nakoupit zboží prostřednictvím portálu aukro.cz, je možnost využití aukce. Majitel zboží stanoví počáteční cenu a délku aukce. Po zahájení aukce může kupující přihodit ke stávající částce určitý obnos. Tímto způsobem se kupující předbíhají a po ukončení aukce vyhrává kupující s posledním příhozem. Posledním příhozem je také stanovena cena, za kterou byl produkt vydražen a za kterou bude prodán. Po úspěšném prodání předmětu je odvedena Aukru provize za uskutečněný prodej. Tato provize je závislá na konečné ceně prodaného předmětu a druhu prodaného zboží. Obvykle se provize pohybuje v rozmezí 0,5 % až 6 % z ceny prodaného předmětu. [2] 11
Oba přístupy nákupu ovšem všechny vystavené produkty nepodporují. Některé předměty jsou vystaveny za fixní cenu, jiné předměty jsou naopak vystaveny pomocí druhé varianty. Ve druhém případě se tedy přesně nejedná o prodej, ale dražbu. V případě automatizovaného vystavování předmětů pomocí prostředků, které Aukro nabízí, nelze vystavovat předměty jako aukce. Pokud tedy chceme vystavit předměty, musíme využít první varianty spočívající v prodeji předmětu za fixní cenu.
12
3 Řešení elektronického obchodu firmy Komtesa s. r. o. Jak již bylo naznačeno, komunikace se zúčastní dvě strany. Jednou z nich je výše popisovaný portál Aukro, druhou stranou je pak internetový obchod, který využívá nabízených služeb Aukra. V případě firmy Komtesa s.r.o. se jedná o řešení redSHOP, které je založené na redakčním systému Joomla.
3.1 Redakční systém Joomla! Joomla! je redakční systém založený na programovacím jazyku PHP. Využívá vlastního frameworku
nazývaného
Joomla!
Platform.
Je
to
jeden
z nejpoužívanějších
a nejúspěšnějších open source redakčních systémů založený na programovacím jazyku PHP. Aktuálně platformu Joomla! využívá okolo 3 % všech webových aplikací. Mezi nejznámější webové aplikace využívající tento redakční systém patří například web o operačních systémech Linux, který najdeme na adrese http://www.linux.com, webová stránka Harvardské univerzity s adresou http://gsas.harvard.edu nebo portál řecké MTV nacházející se na adrese http://www.mtvgreece.gr. [3] První verze označovaná jako Joomla! 1.0.0 byla vydána 16. září 2005. Tato verze byla stejná, jako předešlý produkt Mambo 4.5.2.3, ze kterého vychází. V Joomle byly opraveny pouze některé bezpečnostní chyby. [4] V současné době se nejvíce využívá verze 2.5.8. Tuto verzi užívá i rozšíření redSHOP. Dále se používá verze 1.5.x, která již není vydavatelem podporována, využívá se stále z důvodu nekompatibility některých starých rozšíření se současnou verzí, nebo proto, že provozovatel dané webové aplikace nechce investovat do migrace na vyšší verzi. Nástupcem verze 2.5.8 je verze 3.0 (aktuálně 3.1.1). Ta není ještě moc rozšířena ze stejného důvodu, z jakého se stále drží verze 1.5 - nekompatibilita starších rozšíření.
13
3.2 redSHOP RedSHOP je nadstavba nad redakčním systémem Joomla. Byl vyvinut společností redCOMPONENT, která sídlí v Dánsku. [5] Toto rozšíření poskytuje vše, co elektronický obchod potřebuje. Jedná se především o správu zákazníků, produktů a jejich kategorií, objednávek, výrobců, skladů a dodavatelů. V současné době je silně upravená verze této komponenty využívána společností Komtesa s.r.o. jako hlavní komponenta pro vývoj internetových obchodů.
14
4 Princip propojení Aukra a elektronického obchodu Aukro i internetový obchod jsou dva samostatné portály. Pokud tedy má obchod využívat služby Aukra pro vystavování produktů a následně k získání informací o kupujících a jeho uskutečněných objednávkách, musí být dohodnuta jistá forma komunikace mezi těmito stranami. Této komunikace je docíleno použitím webAPI, které Aukro poskytuje.
4.1 webAPI Jedná se o prostředek komunikace mezi Aukrem a někým, kdo chce využívat jejich služby. Obecně se může jednat o desktopovou aplikaci, mobilní aplikaci či jiný webový portál. V našem případě je komunikující stranou internetový obchod. WebAPI je síťová služba, která využívá Simple Object Access Protocol (SOAP) a textového formátu XML (Extensible Markup Language). Mezi nejdůležitější akce, které API (Application Programming Interface) nabízí, patří: vystavit nabídku, získat informace o struktuře kategorií, stahovat údaje o kupujících, získávat informace o příchozích platbách, zažádat o vrácení provize, vyhledávat nebo nakupovat. [6] Celý princip komunikace je znázorněn na následujícím diagramu:
Obrázek 2: Princip komunikace portálu aukro.cz s protější stranou. Zdroj [6]
15
Na počátku stojí klient. Jelikož je komunikace zprostředkovaná pomocí zasílání XML dokumentů prostřednictvím protokolu SOAP, je celá komunikace nezávislá na programovacím jazyku, pomocí kterého byl klient vytvořen. Můžeme tak využít pro tvorbu klienta celou řadu programovacích jazyků, například PHP C# či Javu. Klient pošle patřičný SOAP požadavek na WebAPI server, tento server vykoná náležité úkony pro zpracování požadavku a odpoví klientovi opět pomocí protokolu SOAP. Celý proces komunikace se děje v rámci konektoru. Konektor je přítomný na straně klienta a jeho úkolem je zprostředkovat komunikaci obou stran. Tento proces vystihuje následující diagram. [6]
Obrázek 3: Komunikace elektronického obchodu a portálu aukro. Zdroj [6]
16
5 Analýza 5.1 Konektor V předešlé kapitole bylo zmíněno, že webAPI, používané ke zprostředkování komunikace mezi Aukrem a internetovým obchodem, je zabalené do prostředku nazývaného konektor. Smyslem konektoru je umožnit z administrace internetového obchodu vystavování položek, provádění nastavení a stahování objednávek a další operace.
5.2 Struktura konektoru V rámci konektoru je nutné implementovat několik důležitých vlastností, tyto vlastnosti shrnuje uvedený diagram, který bude následně popsán.
Obrázek 4: Struktura konektoru. Zdroj [7]
17
Diagram vystihuje hierarchickou strukturu možné implementace položek konektoru. Prvně je nutné přidat do administrace elektronického obchodu novou položku menu, přes kterou bude možné spravovat propojení s Aukrem. Dále je nutné umožnit nastavení připojení, dopravy a platby. Další důležitou vlastností je mapování kategorií a atributů z hierarchie v e-shopovém řešení na hierarchii Aukra. Následně musí konektor umožnit vystavení produktů na Aukro. Po objednání zboží musí být konektor schopen evidovat objednávky a platby. V neposlední řadě v celé fázi procesu komunikace musí docházet k logování jednotlivých událostí a případných chyb, které mohu nastat. [7]
5.2.1 Nastavení propojení Tato část konektoru umožňuje nastavit připojovací údaje k Aukru. Jedná se především o přihlašovací údaje potřebné k navázání spojení. Dále se jedná o předdefinované volby pro vystavení produktů a nastavení způsobů dopravy a platby. [7]
5.2.2 Základní nastavení Základní nastavení by mělo obsahovat uživatelský účet, pomocí kterého dojde ke spojení s Aukrem. K navázání spojení je nutné uživatelské jméno, heslo a WebAPI klíč. [7]
5.2.3 Předdefinované volby Tato sekce slouží k nastavení obecných parametrů týkající se vystavování produktů. Především se jedná o nastavení délky trvání, po kterou má být zboží vystaveno, nastavení základní měrné jednotky, možnost automatického vystavování zboží, nastavení společného textu pro nabídky a další. Předdefinované volby by tak měly urychlit vystavování zboží. [7]
18
5.2.4 Doprava a platba Zde jsou vydefinovány způsoby dopravy a cena za dopravu. Cena za dopravu je standardně definována pomocí 3 položek: •
První položka – udává cenu za první zakoupený kus
•
Další položka – udává, o kolik bude navýšena cena až do hodnoty množství v balení
•
Množství v balení – indikuje počet kusů v jednom balení. Po překročení této hodnoty bude k ceně připočítána cena za první položku.
5.3 Mapování kategorií Řešení internetového obchodu firmy Komtesa s.r.o. využívá zařazení produktů do kategorií pro snadnější orientaci zákazníka a správu produktů. Stejně tak Aukro obsahuje strom kategorií. Pokud chceme vystavit produkt na Aukro, musíme ho zařadit do určité kategorie, kterou Aukro poskytuje. V ideálním případě by se na Aukru vyskytovala stejná kategorie jako v internetovém obchodě. Pro každou kategorii ale nemusí přesná kategorie na Aukru existovat. Z tohoto důvodu je nutné zavést mapování kategorií. Toto mapování určuje dvojice kategorií, tedy kategorii z e-shopu, a k ní patřičnou kategorii Aukra. Některé kategorie Aukra nemusí být využity, to záleží na sortimentu, který internetový obchod nabízí. Dále jedné kategorii Aukra může odpovídat více kategorií e-shopu, protože internetový obchod může využívat specifičtější kategorie. Nemělo by se ovšem stát, že jedné kategorii z internetového obchodu bude odpovídat více kategorií Aukra, takové chování je nežádoucí. [7] Počet a názvy kategorií se mohou časem na Aukru měnit, proto je nutné pravidelně aktualizovat dostupné kategorie, aby při jejich následném párování byly vždy informace aktuální. [7]
19
5.4 Mapování atributů Atribut je určitá vlastnost produktu a pro každou skupinu produktů mohou být tyto atributy jiné a navíc pro každý produkt mohou nabývat jiných hodnot. Atributem je například úhlopříčka monitoru, velikost bot, barva a další. Každá kategorie na Aukru má přidělenou sadu atributů, atributy jsou povinné a nepovinné. Je doporučeno vyplnit co nejvíce atributů, protože na základě hodnot atributů dochází k vyhledávání zboží na Aukru. Je tedy zcela logické, že čím více atributů je vyplněno, tím je větší šance, že produkt bude nalezen. [7] Mapování atributů podléhá stejným problémům jako mapování kategorií. Atributy si nemusí jednoznačně odpovídat jak významem, tak i hodnotou. Například váha produktu či velikost mohou být v internetovém obchodě udávány v jiných jednotkách, než ve kterých se udávají na Aukru.
5.5 Administrace produktů Globální nastavení, jako doba vystavení produktů na Aukru, způsob dopravy, druh platby, mohou být nastavené pro všechny produkty globálně nebo například pro určité kategorie nebo pro každý produkt samostatně. Proto musí konektor umožňovat změnit tyto informace pro každý produkt. [7] Z tohoto důvodu musí dojít v administrační části internetového obchodu k upravení správy produktů, aby výše upravené chování bylo možné. V konečném důsledku musí být vyplněné globální nastavení, které se využije v případě, že nejsou informace u produktu vyplněné. Pokud je ovšem vyplníme, musí mít informace u produktu vyšší prioritu a budou použity místo globálních údajů. [7]
5.6 Automatické vystavování produktů Automatické vystavování produktů je vlastnost konektoru, která patří k těm nejzásadnějším. Pokud budeme mít v e-shopu několik tisíc produktů a každý budeme chtít vystavit na Aukro, kde bude vystaven po dobu 14 dnů, pak bychom každých 14 dní museli tyto produkty projít a opět je zařadit k vystavení. Z tohoto důvodu je automatizace klíčová vlastnost, která usnadňuje práci.
20
Automatické vystavování se může dít několika způsoby, popřípadě jejich kombinacemi. První možností je vystavovat veškeré produkty, které internetový obchod nabízí. Dále je možné vystavovat pouze určité kategorie. Poslední možností je vystavovat pouze určité produkty. [7] Konektor by měl mít minimálně vlastnost vystavování konkrétních produktů, ovšem kombinace všech tří přístupů je nejvhodnější řešení. [7]
5.6.1 Vystavení Další položka, která se v konektoru nachází, umožňuje vystavení produktů na Aukro a sledování vystavených položek. Pro snadnější orientaci musí být možné tato data filtrovat a řadit podle názvu, ceny a data vystavení. Dále musí být umožněno vyhledávání podle daného klíčového slova. V neposlední řadě musí systém umožnit předčasně ukončit vystavení produktu na Aukru. [7] V administraci produktů dojde k označení produktu, tím se systému dá najevo, že ho budeme chtít vystavit. Tento produkt se následně zobrazí v administraci v položce vystavení, kde bude zobrazen jako produkt k vystavení. Následně může dojít k vystavení tohoto produktu. V případě úspěšného vystavení je produkt zobrazen ve vystavených položkách. Vystavené produkty je možno naopak z Aukra odebrat.
5.7 Logování Konektor obstarává nepřeberné množství funkcí a úkonů a ne všechny akce skončí úspěchem. Nemusí například dojít ke spojení se serverem Aukra, či dojde ke ztrátě informací zahlcením sítě. Proto je nutné veškeré informace zaznamenávat, aby se daly případné chyby identifikovat a mohla být zjednána náprava problému. Kromě chyb by mělo docházet i k zaznamenávání operací, jako jsou vystavení nabídek, ukončení vystavení, dokončení objednávky a příchozí platby. [7]
21
5.8 Objednávky Poslední část konektoru se zabývá objednávkami. V okamžiku, kdy je produkt koupen, je Aukrem vystavena objednávka. Tato objednávka je následně přenesena do internetového obchodu. Na základně objednávek je pak zboží dodáno zákazníkovi. Objednávky z Aukra mohou mít vlastní podobu nezávislou na podobě objednávek, které jsou standardně využívány v rámci internetového obchodu, nebo mohou mít stejnou podobu a budou rozlišovány pouze pomocí příznaku, zda se jedná či nejedná o objednávku uskutečněnou pomocí Aukra. Objednávky musí být možné editovat a dále musí být umožněny standardní hromadné operace nad nimi, jako je hledání filtrování řazení a podobně. [7] Dále musí být objednávky rozděleny podle svého stavu, zda jsou nebo nejsou dokončené. Dokončená objednávka znamená, že v průběhu tvorby objednávky byla vyplněna volba přepravy, kde byl určen způsob platby a přepravy a byla vyplněna doručovací adresa. Díky tomu má systém veškeré potřebné informace a zboží může být odesláno kupujícímu. [7] Naproti tomu nedokončená objednávka nemá vyplněné dodací údaje a způsob platby. K dispozici jsou jen údaje kupujícího. V tento okamžik je tedy nutné kupujícího kontaktovat a dohodnout s ním způsob platby a přepravy. Po doplnění údajů je tak možné nedokončenou objednávku převést na dokončenou. [7] Poslední částí objednávek je stav, zda byla objednávka již zaplacena nebo nebyla. Zaplacené objednávky musí být pro přehlednost v systému odlišné od nezaplacených. Ke změně stavu z nezaplacené objednávky na zaplacenou může dojít automaticky v případě, že byla využita metoda platby přes PayU, v opačném případě musí být platba do systému zanesena ručně. [7]
22
6 Použité prostředky Z předcházejícího textu vyplývá, že pro implementaci požadované funkčnosti musí být použito určité programové vybavení. Celá funkčnost bude naprogramována jako rozšíření redakčního systému Joomla v programovacím jazyku PHP, dále bude použito HTML (Hypertext Markup Language) a CSS (Cascading Style Sheets) pro tvorbu šablon a JavaScript pro programování na straně klienta. V rámci komunikace s portálem aukro.cz bude využita SOAPová komunikace, která sama o sobě využívá pro transport informací mezi komunikujícími stranami dokumenty XML. V této kapitole bych proto chtěl, alespoň ve zkratce, představit tyto prostředky, za jejichž pomoci bude konektor implementován.
6.1 Joomla! Platform Joomla! Platform je PHP framework, který vznik v červenci roku 2011 oddělením frameworku od CMS (Content Management System) Joomla. Do té doby byl framework součástí redakčního systému a nebylo možné framework využít bez použití celého redakčního systému. Nyní je Joomla! platform nezávislá sada knihoven, které lze využít samostatně bez nutnosti využití celého redakčního systému, jak vystihuje následující obrázek. [8]
Obrázek 5: Vztah Joomla! Platform a Joomla! CMS. Zdroj [8]
23
6.1.1 Princip vývoje aplikací pro CMS Joomla! Jelikož e-shopové řešení nevyužívá čistě Joomla! platform, ale celý redakční systém se všemi komponentami, bylo by vhodné se s těmito částmi, alespoň rámcově, seznámit, protože veškerý vzniklý kód bude vytvořen právě podle těchto principů. Pro vývoj dílčích částí jsou klíčové tři pojmy: komponenta, modul a plugin. Pomocí těchto prostředků lze rozšířit standardní funkčnost Joomly.
6.1.2 Komponenta Komponenta je v prostředí Joomly považována za největší samostatný celek. Komponenta dále může úzce spolupracovat s moduly nebo využívat funkčnosti pluginů. Pod pojmem komponenta si můžeme představit kompletní správu uživatelů. Komponenta má zpravidla dvě části, takzvaný frontend a backend. Frontend je většinou volně přístupný všem uživatelům, zatím co backend slouží pro administrativní účely. [9] V našem příkladu s uživateli může tedy frontendová část poskytovat registraci uživatele, přihlášení do systému, změnu hesla nebo úpravu profilu. Oproti tomu backendová
část
poskytuje
administrativní
rozhraní,
například
schvalování
registrovaných uživatelů, seznam časů posledních přihlášení, mazání uživatelů, zařazení do určitých skupin, přidělení práv a další. Komponenta tvoří na stránce největší část obsahu dané stránky. Typicky se jedná tedy o zobrazený článek nebo třeba registrační formulář. Princip tvorby komponent vychází z architektonického vzoru Model-View-Controller (MVC).
6.1.3 Modul Modul je další stavební jednotkou využitelnou v prostředí CMS Joomla! Od komponenty se liší především rozsáhlostí. Moduly jsou zpravidla daleko menší. Zatím co na jedné stránce můžeme mít pouze jednu komponentu, modulů můžeme mít na stránce podstatně více. Mezi standardní moduly patří například přihlašovací formulář, zobrazení titulků nejnovějších článků, či komentářů a podobně. [9] Princip modulu je ve své podstatě velmi jednoduchý, většinou se jedná o dva soubory, jeden má na starost obstarat data k zobrazení a druhým souborem je pak šablona, která 24
daná data zobrazí. V případě modulu pro příhlášení má soubor obsluhující logiku zjistit, zda je uživatel přihlášený. Na základě této logiky je poté zobrazen přihlašovací formulář nebo možnost odhlášení.
6.1.4 Plugin Poslední možností, kterou Joomla nabízí, je plugin. Pluginy jsou v Joomle chápány spíše jako eventy (události). Pro každou událost může být zaregistrováno několik pluginů, které mají za úkol na tuto událost reagovat. Plugin je zpravidla implementován jako jedna třída, která využívá dle potřeby další funkce ze svého okolí. Plugin by měl být teoreticky nejjednodušší ze všech zmíněných typů, které můžeme v Joomle implementovat. Praxe je však jiná. Nikde není stanoveno, co má být považováno jako plugin a co už by si zasloužilo vlastní logiku uvnitř nějaké komponenty, proto se můžeme setkat i s velice komplexními pluginy. [10] Jako příklad standardních pluginů můžeme uvést například plugin rozšiřující možnosti registračního formuláře. Mimo klasické pole, které musí uživatel vyplnit při registraci, budeme například vyžadovat telefonní číslo. Toho lze právě docílit aktivací pluginu. Plugin reaguje na událost „onContentPrepareForm“. Na základě vyvolání této události je spuštěn kód pluginu, plugin zkontroluje jaký formulář, je generován a pokud je generován formulář pro registraci, přidá do formuláře další pole pro telefonní číslo. [10]
6.1.5 Shrnutí Standardní funkčnost Joomly je tedy možné rozšířit třemi způsoby: vytvořením komponenty, modulu nebo pluginu. Rozšíření může mít dvě části – frontend a backend. Při tvorbě napojení na portál aukro.cz bude rozšířena komponenta redSHOP, obsluhující veškerou logiku týkající se e-shopového řešení. Dále bude vytvořen plugin, který bude mít na starost logování událostí. Všechna tato funkčnost bude implementována v administrační části portálu, tedy na backendu.
25
6.2 Aukro webAPI Jak již bylo zmíněno v předešlém textu, komunikaci bude zajišťovat webAPI portálu aukro.cz. Jedná se o SOAPové služby využívající data ve formě XML. Pojďme si tedy tyto technologie ve stručnosti představit.
6.2.1 SOAP SOAP (Simple Object Access Protocol), jak celý název napovídá, je protokol pro výměnu strukturovaných informací. Tento protokol využívají webové služby pro komunikaci. Informace jsou přenášeny prostřednictvím XML a převážně pomocí protokolu HTTP (Hypertext Transfer Protocol) doručeny druhé straně. Kromě protokolu http lze využít i jiné protokoly, například SMTP (Simple Mail Transfer Protocol). Protokol SOAP byl vyvinut v roce 1998 za podpory firmy Microsoft a byl rychle přijat i jinými velkými společnostmi jako prostředek komunikace. V současné době od tohoto způsobu komunikace některé firmy upouštějí a využívají místo SOAPu jiných druhů komunikace, jako například REST. SOAPová zpráva je XML dokument, jehož kořenovým elementem je element s názvem Envelope. Tento element obsahuje dva další elementy Header a Body. Header neboli hlavička je nepovinná část, která slouží pro přesnost pomocných informací. Body (tělo) obsahuje informace o tom, jaká služba se má zavolat a s jakými parametry. Mezi nevýhody této technologie oproti konkurenčním prostředkům patří relativní pomalost komunikace, jelikož komunikace probíhá na základě výměny XML dokumentů. XML dokumenty je relativně pomalé zpracovávat a obecně textový formát není vhodný, protože přenášené zprávy jsou zbytečně dlouhé. Pro urychlení komunikace je možné využít binární formu XML. Paradoxně využívání XML by se dalo chápat i jako výhoda, jelikož se jedná o technologii, která je v IT (Informační technologie) široce rozšířená.
26
Obrázek 6: Ukázka XML souboru zaslaného na aukro.cz.
27
7 Návrh a implementace konektoru V tuto chvíli bychom měli mít k dispozici veškeré informace, které jsou nutné pro vyřešení daného problému. Na tomto místě bych rád zopakoval požadavky na implementovaný systém.
7.1 Požadavky na konektor Dle dohody s firmou Komtesa s.r.o. bude rozšíření o možnost vystavit produkty na portál aurko.cz implementováno v rámci jejich e-shopového řešení na CMS Joomla!. Rozšíření musí být naimplementováno tak, aby bylo možné veškerou funkcionalitu povolit či zakázat v závislosti na konfiguraci. Informace týkající se vystavení daného produktu budou přidány do správy produktu jako nová záložka. Na ostatní funkčnost vznikne nová položka v menu, pod kterou správce e-shopu najde zbytek funkčnosti. Mezi hlavní funkčnost bude patřit nastavení spojení, mapování kategorií a atributů, možnost nastavit cenu za jakou má být produkt vystaven, popisek, obrázky a další informace o daném produktu. Implementované rozšíření dále musí umět hromadné vystavení produktů. V neposlední řadě musí být schopné automaticky zjistit informace o prodaném zboží a kupujícím a založit v e-shopu objednávky. Posledním požadavkem je logování událostí. Budou logovány veškeré informace týkající se spojení s portálem aukro.cz, jako je například synchronizace kategorií, vystavení produktů a vytvoření objednávek. Logovány budou i chyby vzniklé při práci s aukrem.
7.2 Globální nastavení Každá komponenta v Joomle je schopná držet si své nastavení. Toto nastavení je možné změnit pomocí formuláře, formulář může obsahovat libovolné množství polí. Pole lze seskupovat do skupin, které jsou uživateli zobrazeny jako záložky. Po uložení je nastavení uloženo do databáze ve formátu JSON (JavaScript Object Notation). Do nastavení komponenty Redshop byla přidána nová záložka s názvem Aukro, do které byly vloženy následující volby: Umožnit vystavení na aukru – jedná se o checkbox, na základě jeho hodnoty systém rozhoduje, zda umožnit uživateli práci s vytvořeným rozšířením.
28
Dalšími položkami jsou uživatelské jméno, heslo a webAPI klíč. Tyto položky specifikují přístupové údaje, které Aukro vyžaduje téměř při každém spojení a dotazu na webAPI server. Posledními dvěma položkami jsou doba vystavení a kód země. Doba vystavení udává počet dní, po který mají být položky vystaveny na portálu aukro.cz. Kód země je pak číslo indikující zemi. WebAPI je totiž společné pro více portálů, kód země tedy říká, na jaký portál chceme zboží vystavit. Například číslo 56 indikuje zájem vystavit produkty na český portál aukro.cz, zatím co číslo 228 je vyhrazeno pro testovací portál testwebapi.pl.
Obrázek 7: Možnosti nastavení komponenty
Výše uvedeného výsledku bylo docíleno rozšířením XML souboru config.xml. Tento soubor obsahuje popis pro vygenerování formuláře.
7.3 Mapování kategorií Mapování kategorií je naimplementováno jako samostatný číselník. Jedná se vždy o dvojici kategorií doplněnou o titulek.
29
Obrázek 8: Číselník mapování kategorií
O správu mapování kategorií se starají především třídy RedshopViewAukroCategories a RedshopViewAukroCategory. Tyto dvě třídy patří do prezentační vrstvy, jejich cílem je zobrazit seznam namapovaných kategorií (úkol třídy RedshopViewAukroCategories ) a umožnit založení nového mapování nebo upravit stávající mapování zobrazením formuláře (úkol třídy RedshopViewAukroCategory ). Zmíněné třídy obstarávají zobrazení dat uživateli, neobsahují logiku pro získání dat. To je úkol tříd RedshopModelAukroCategories a RedshopModelAukroCategory. Třída RedshopModelAukroCategories obsahuje logiku pro získání uložených mapování na základě filtrů uživatele. Data jsou pak poskytnuta výše zmíněné prezentační třídě. Úkolem třídy RedshopModelAukroCategory je vytvořit formulář a v případě editace určitého mapování naplnit formulář hodnotami z databáze. Formulář je pak opět poskytnut prezentační vrstvě. V rámci ukládání mapování byly implementovány jisté validace. Například titulek nemůže být prázdný, kategorie musí být vyplněné či kategorie e-shopu může být použita pouze pro jedno mapování.
30
Obrázek 9: Úprava mapování kategorie
Do kompletní architektury MVC již chybí jen controllery, tedy třídy reagující na požadavky uživatele, vyvolávající určité akce jako je zobrazení zmíněných view, uložení záznamu či odstranění záznamu. Třída RedshopControllerAukroCategories reaguje na uživatelovy požadavky zobrazit seznam namapovaných kategorií a smazat určité mapování. Na první požadavek reaguje vyvoláním metody display, na druhý požadavek pak metodou delete. Druhým controllerem je třída obstarávající požadavky jako uložení nového záznamu či uložení změn určitého záznamu. Tento controller nese název RedshopControllerAukroCategory. Tato architektura je typická pro programování komponent v prostředí Joomla!, z tohoto důvodu dále nebudu popisovat vždy celou strukturu, ale jen nestandardní části.
7.3.1 Dostupné kategorie Aukra Jelikož kategorie portálu aukro.cz se mění, vznikají nové kategorie, je nutné udržovat aktuální stav. Z tohoto důvodu je žádoucí pravidelně aktualizovat seznam kategorií. O synchronizaci
se
stará
controller
RedshopAddonControllerAukroCron,
tento
controller disponuje metodou updateCategoriesFromAukro. V rámci této metody je zavolána metoda updateCategoriesFromAukro třídy RedshopModelAukroCategories. V těle zmíněné metody je inicializován connector, který má na starosti veškerou komunikaci s webApi serverem. Veškeré požadavky na server jsou centralizovány v této třídě nazvané RedshopModelAukroConnector, jehož funkčnosti využívají ostatní třídy jako například právě zmíněná třída RedshopModelAukroCategories, která 31
connector požádá o vrácení seznamu všech kategorií, které portál aukro.cz nabízí. Vrácený seznam kategorií je porovnán s lokálním seznamem uloženým v databázi. Nové kategorie jsou uloženy do lokálního seznamu kategorií a naopak kategorie, které již portál aukro.cz nepoužívá, jsou z lokálního seznamu odstraněny. Tím je docíleno synchronizace kategorií. Aktualizace kategorií musí být prováděna pravidelně. Toho je docíleno automatickým spouštěním dané události pomocí Cronu.
7.4 Mapování atributů Mapování atributů je dle mého názoru jedna z nejtěžších částí, kterou musí vyvíjené rozšíření řešit. Proto bylo mapování po konzultaci zjednodušeno. Mapování je implementováno následujícím způsobem: po založení nového mapování kategorií, je na základě zvolené kategorie portálu aukro.cz odeslán požadavek na vrácení všech atributů pro danou kategorii, pomocí metody updateCategoryFormFields (přejímající jeden parametr aukroCategory ) třídy RedshopModelAukroCategories. Metoda interně inicializuje connector, který se spojí s webApi serverem a zprostředkuje požadavek. Vrácené atributy jsou uloženy do databáze. Samotné mapování se děje až při použití uložených atributů na kartě produktu. Obecně se nemapují veškeré atributy automaticky, ale byla vybrána jistá podmnožina atributů, které jsou namapovány. Zbylé atributy je nutné vyplnit v případě potřeby na kartě produktu ručně.
7.5 Úprava karty produktu Karta produktu je rozšířena o další záložku, která obsahuje možnosti týkající se vystavení. Zde jsou právě zobrazeny veškeré atributy, které byly zmíněny v předcházející kapitole. O veškerou logiku se stará třída RedshopModelAukroProduct, ta má za úkol zjistit, zda má produkt varianty a podle toho se uživateli zobrazí jednoduchý formulář pro atributy nebo možnost přidávat další skupiny atributů a spojit je s patřičnou variantou. Jelikož některé formulářové pole (atributy) není potřebné zobrazovat, obsahuje zmíněná třída metodu isFieldInBlacklist($field), která zajistí, že formulář bude obsahovat pouze požadované atributy.
32
V konečném důsledku třída RedshopModelAukroProduct obstarává získání formuláře, či formulářů (pokud má produkt varianty). Formuláře naplní výchozími hodnotami nebo hodnotami z databáze, pokud se jedná o úpravu hodnot. Nakonec se postará o uložení hodnot do databáze. Pokud byl zatržený checkbox „Vystavit produkt“, jehož hodnota indikuje, zda chceme produkt vystavovat či nikoliv, je při ukládání produktu zkontrolováno, zda je možné daný produkt vystavit. Toho je docíleno voláním connectoru a jeho metody checkProduct($productId, $variantId). Metoda sestrojí prodejní formulář na základě vyplněných hodnot na kartě produktu. Informace odešle na webApi server, který vrátí odpověď, zda byly vyplněny všechny potřebné informace pro vystavení produktu a jestli jsou ve správném formátu. Pokud jsou některé informace chybné, je uživatel o této skutečnosti informován.
Obrázek 10: Karta produktu obsahující atributy z testovacího serveru
33
7.6 Vystavení produktů Další částí je logika pro vystavení produktů a pro předčasné ukončení nabídek. Tato logika je zajištěna třídami se sufixem AukroExhibitProducts. Klasický controller, který Joomla poskytuje, byl rozšířen o metody exhibit() a withdraw(). Jak názvy napovídají, metoda exhibit má za úkol vybrané předměty vystavit na Aukro, kdežto metoda withdraw umožňuje předčasně ukončit vystavení zvolených produktů. Tyto metody interně volají modelovou vrstvu. V případě vystavení produktů se zkontroluje, zda je možné produkt vystavit pomocí metody
canExhibitProduct
nebo
zda
již
není
produkt
vystaven
(metoda
checkIfExhibited ). Pokud je produkt možné vystavit, model inicializuje connector a vyvoláním metody exhibitProduct se pokusí o vystavení produktu. Obdobný postup je aplikován i v případě, že chceme předčasně ukončit vystavení produktu. Nejprve se zkontroluje, zda je produkt vystaven a v případě, že je vystaven, model invokuje metodu withdrawProduct connectoru, která se postará o stažení produktu z portálu aukro.cz. Celý proces vystavení je doprovázený operacemi nad databází, kam jsou ukládány informace o vystavených nabídkách, jako je cena, datum vystavení či datum ukončení aukce a identifikátor aukce.
Obrázek 11: Náhled správy vystavení produktů
34
7.7 Stahování objednávek Stahování objednávek je řízeno modelem RedshopModelAukroDealEvents, který obsahuje logiku pro získání informací z portálu aukro.cz. Jednotlivé události (eventy), jsou uloženy do databáze pomocí metody insertEvent. Z nevyřízených událostí jsou za pomoci metody createDeal vytvořeny skupiny, které se týkají stejné transakce. Události obsahují informace o prodaném předmětu, o kvantitě, o kupujícím, způsobu platby a dopravy. Lze tedy metodou createOrder z výše zmíněných informací založit objednávku. V případě úspěšného založení objednávky jsou jednotlivé eventy označeny za zpracované metodou markDealAsProcessed. V opačném případě se vyskytla chyba a události musí být zpracovány znovu.
7.8 Logování událostí Celý proces doprovází logování. Logování je zajištěno vytvořeným pluginem, který reaguje na události vyvolané ostatními částmi kódu. Joomla disponuje třídou JDispatcher, která umožňuje zaregistrovat jiné třídy, které mají být notifikovány, pokud nastane daná událost. Událost je vyvolána voláním metody trigger nad instancí třídy JDispatcher. Zmíněná metoda přebírá 2 argumenty, prvním je název události a druhým parametrem je pole obsahující libovolné parametry.
Obrázek 12: Výpis z logu událostí
35
Na tomto principu byl vybudován systém událostí s prefixem onLogAukro (například onLogAukroUpdateCategoriesSuccess ). Po vyvolání události na ní zareaguje AukroLogger vyvoláním stejnojmenné metody, která má za úkol danou událost uložit do databáze. Z uložených událostí je následně vytvořen číselník, který si může uživatel třídit a filtrovat podle různých kritérií.
36
8 Testování Portál aukro.cz není jediný svého druhu, jelikož Aukro patří pod společnost Allegro Group, které provozuje obdobný portál pro polské obyvatele allegro.pl. Existují i další portály, které vycházejí z modelu allegro.pl, jako jsou například aukro.sk, aukro.ua, aukro.bg nebo molotok.ru. Jelikož všechny zmíněné portály fungují na stejném principu a využívají stejné webApi, pro komunikaci stačí odladit funkčnost aplikace na jednom portálu. Díky zmíněné kompatibilitě pak aplikace bude s mírnými odlišnostmi fungovat i pro ostatní portály. Tento mechanismus umožnil vznik dalšího portálu, jímž je testwebapi.pl, který slouží jako testovací portál. Výsledné poznatky lze poté přenést na kterýkoli výše zmíněný skutečný prodejní portál. Tím je možné aplikaci testovat, aniž by byl ovlivněn chod prodejních portálů, na které by jinak bylo vystaveno velké množství testovacích produktů. Další výhoda testovacího portálu je, že za jeho použití nemusíme platit. Pokud chceme vystavit produkt na portál aukro.cz za každou vystavenou položku a za každou prodanou položku se platí. To pro testovací server neplatí, můžeme tedy vystavovat stovky produktů, jako by se jednalo o produkční server a otestovat tak skutečně očekáváné množství vystavovaných produktů. Testování probíhalo v průběhu celého vývoje rozšíření, tak jak funkčnost postupně narůstala. Testování bylo uskutečněno na výše zmíněném polském testovacím portálu testwebapi.pl. Postupně byly otestovány všechny klíčové vlastnosti. Na úplném začátku byla testována synchronizace kategorií, následně stažení prodejního formuláře pro danou kategorii, vystavení produktů a předčasné ukončení nabídek a v neposlední řadě stahování objednávek, informace o kupujícím, zvoleném způsobu platby a dopravy. Ačkoliv je testovací portál z velké části shodný s portálem aukro.cz, v jistých ohledech se liší. Jedná se především o způsob vybrání způsobu platby a přepravy, které na rozdíl od portálu aukro.cz testovací portál nevyužívá. Tato funkčnost bude odladěna a řádně otestována až na produkčním e-shopu jednoho ze zákazníků firmy Komtesa.
37
9 Srovnání s existujícími řešeními Na portále aukro.cz jsou k dispozici dvě aplikace, které disponují funkcemi pro hromadné vystavování produktů na Aukro. Jedná se o FlexLoader a Aloader. Obě zmíněné aplikace pracují jako desktopová aplikace využívající technologii Adobe AIR (Adobe Integrated Runtime). FlexLoader i Aloader lze úspěšně provozovat i na některých mobilních telefonech typu smartphone. Hlavním cílem těchto programů je umožnit uživateli hromadně vytvořit popisy produktů a následně produkty vystavit, mezi další funkce patří importování a exportování do csv souboru. Aplikace FlexLoader oproti programu Aloader podporuje správu vystavených nabídek a jejich předčasné ukončení. Na rozdíl od zmíněných aplikací, byl v rámci této bakalářské práce vyvinut modul integrovaný přímo do administrace e-shopu, umožňující vystavování produktů na Aukro. Tato vlastnost je klíčovou odlišností při porovnávání FlexLoaderu, Aloaderu a implementovaného modulu. Jelikož FlexLoader i Aloader existují jako samostatné aplikace, je nutné do těchto programů zadat produkty pro vystavení ručně nebo je naimportovat pomocí csv souboru. Tento soubor ovšem musíme opět nějakým způsobem vytvořit, pravděpodobně v některém tabulkovém kalkulátoru. Při správě většího množství produktů může vytvoření databáze produktů pro FlexLoader či Aloader spotřebovat velké množství času a úsilí. Jelikož byl naprogramovaný modul od začátku zamýšlen jako rozšíření e-shopového řešení poskytovaného firmou Komtesa s.r.o., není potřeba složitě importovat produkty, protože se využívá databáze produktů, kterou daný e-shop disponuje. Další podstatnou výhodou je správa prodaných produktů. Programy FlexLoader a Aloader nejsou koncipovány tak, aby uživateli poskytovali přehled o prodaných položkách, či mu napomáhali organizovat objednávky. Prodávající není pomocí těchto programů schopný evidovat aktuálně vyřizované objednávky, objednávky čekají na vyřízení, či již vyřízené objednávky. V těchto ohledech má naimplementovaný systém výhodu, protože byl postaven nad kompletním e-shopovým řešením. Z prodaného zboží jsou automaticky vytvořeny objednávky v rámci e-shopu a kupující je informován o vytvoření objednávky e-mailem. Následně může být kupující notifikován při expedici zboží, či pokud prodávající obdrží platbu od kupujícího. Pokud by uživatel chtěl používat pouze program Flexloader nebo Aloader, chtěl by evidovat objednávky včetně 38
jejich stavů a chtěl by informovat kupujícího pomocí e-mailů, musel by využívat další podpůrné nástroje, které by mu tuto funkčnost poskytly. V tomto případě bude mít prodávající informace o prodaném zboží na více místech a sestavování a dohledávání objednávek by mohlo být méně efektivní než řešení v podobě kompletního e-shopu s integrovanou podporou pro Aukro. Naimplementovaný systém pro správu vystavení produktů na portál aukro.cz se nedá použít samostatně jako aplikace FlexLoader či Aloader. Pokud ovšem má zákazník zhotovený e-shop od firmy Komtesa s.r.o. a chce vystavovat produkty na Aukro, pak je naimplementované řešení z výše popsaných důvodů vhodnější, než využití aplikací FlexLoader, Aloader či jiných podobných aplikací.
39
10 Závěr 10.1 Zhodnocení Cílem této bakálářské práce bylo napojení e-shopového řešení firmy Komtesa s.r.o. na aukční portál aukro.cz, aby bylo možné vystavovat produkty na Aukro přímo z administrace e-shopu. Před samotnou implementací bylo nutné nastudovat programové API, které Aukro poskytuje pro komunikaci. Jelikož jsou v dokumentaci zmíněného API, ke každé metodě i příklady, jak danou metodu využít v kódu, nevypadal problém napojení složitě. Během vývoje se ovšem opak ukázal pravdou. V některých ohledech dokumentace není jednoznačná, uvedené příklady neodpovídaly skutečnosti a bylo nutné experimentovat. Tyto pokusy a omyly stály relativně velké množství času. Některé problémy, na které jsem narazil, jsem se snažil dohledat na internetu. Bohužel relevantní odpovědi na mé otázky jsem buď nenašel, protože komunita okolo využívání API služeb pro portály typu aukro.cz není moc široká, nebo byly odpovědi v polštině, protože API, které využívá portál aukro.cz, vychází ze stejného modelu jako portál alegro.pl, který tvoří základ pro všechy ostatní odvozené portály. Dalším problémem bylo samotné testování, které probíhalo na testovacím portále testwebapi.pl, který je ovšem také v polštině. Z tohoto důvodu bylo pro mě poměrně obtížné vystavit první produkt na portál, jelikož některá nastavení v prodejním formuláři jsou podmíněná jinými a celá komunikace je v polštině. Jako poslední překážka se ukázalo zjišťování prodaných produktů a jejich kupujících. V tomto ohledu je dle mého názoru API poměrně těžkopádné a mohlo by fungovat daleko jednodušeji. Po překonání popsaných problémů se již podařilo naprogramovat mechanismus pro vystavování a stahování produktů z portálu, logovat vzniklé události a zakládat objednávky do e-shopu, proto si myslím, že cíl, který si tato bakalářská práce kladla, byl splněn.
40
10.2 Budoucnost Napojení na portál aukro.cz bude komerčně využíváno v e-shopových řešeních dodávaných firmou Komtesa s.r.o. Nejedná se tedy o jednorázovou aplikaci, ale vývoj bude nejspíše i nadále pokračovat, ať už na základě podnětů vývojového týmu či zákazníků. API se občas mění, z tohoto důvodu bude nutné i naprogramovaný modul uzpůsobovat aktuální verzi API, které portál aukro.cz používá. Konektor umožňující spojení Aukra s druhou stranou je poměrně komplexní, a tak není těžké vymyslet další kroky, kterými by se mohl vývoj ubírat. Jako stěžejní funkcionalitu, která by v budoucnu mohla být naiplementována, je více automatizované párování atributů produktů e-shopu na atributy Aukra, aby je administrátor nemusel pro vystavení na Aukro na kartě produktu zadávat ručně.
41
Seznam použité literatury 1. Aukro v roce 2008 [online]. 2008 [cit. 2013-05-04]. Dostupné z: http://media.aukro.cz/file/mediakit/159590/3e/zprava-o-cinnosti-aukro-08-short.pdf 2. Ceník služeb. Aukro - největší obchodní portál [online]. [cit. 2013-05-02]. Dostupné z: http://aukro.cz/help_item.php?item=502 3. 10 Most Popular Websites Using Joomla!. In: The Joomla! ® Community Magazine [online]. 2012 [cit. 2013-05-05]. Dostupné z: http://magazine.joomla.org/issues/issue-july-2012/item/800-10-most-popularwebsites-using-Joomla 4. Joomla. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013 [cit. 2013-05-18]. Dostupné z: http://en.wikipedia.org/wiki/Joomla 5. RedCOMPONENT [online]. [cit. 2013-01-10]. Dostupné z: http://redcomponent.com/ 6. WebApi [online]. 2011 [cit. 2013-05-18]. Dostupné z: http://api.aukro.cz/ 7. Obecná specifikace Aukro konektoru [online]. 2012 [cit. 2013-02-18]. Dostupné z: http://api.aukro.cz/Files/Specifikace_konektoru.pdf 8. Joomla Platform. Joomla! Official Documentation [online]. [cit. 2013-05-18]. Dostupné z: http://docs.joomla.org/Platform 9. DEXTER, Mark a Louis LANDRY. Joomla! programming. Upper Saddle River, NJ: Addison-Wesley, c2012, xxv, 558 p. ISBN 01-327-8081-X. 10. MARRIOTT, Jennifer a Elin J WARING. The official Joomla! book. Second edition. Upper Saddle River, NJ: Addison-Wesley, c2012, xxv, 481 pages. ISBN 03218-2154-8. 11. BURGE, Stephen. Joomla! explained: your step-by-step guide. Upper Saddle River, NJ: Addison-Wesley, c2012, xiv, 428 p. ISBN 03-217-0378-2.
42
Seznam obrázků Obrázek 1: Úvodní strana portálu aukro.cz .................................................................... 10 Obrázek 2: Princip komunikace portálu aukro.cz s protější stranou .............................. 15 Obrázek 3: Komunikace elektronického obchodu a portálu aukro ................................. 16 Obrázek 4: Struktura konektoru. Zdroj ........................................................................... 17 Obrázek 5: Vztah Joomla! Platform a Joomla! CMS ..................................................... 23 Obrázek 6: Ukázka XML souboru zaslaného na aukro.cz.............................................. 27 Obrázek 7: Možnosti nastavení komponenty.................................................................. 29 Obrázek 8: Číselník mapování kategorií ........................................................................ 30 Obrázek 9: Úprava mapování kategorie ......................................................................... 31 Obrázek 10: Karta produktu obsahující atributy z testovacího serveru .......................... 33 Obrázek 11: Náhled správy vystavení produktů ............................................................. 34 Obrázek 12: Výpis z logu událostí .................................................................................. 35
43
Seznam použitých zkratek CMS – Content Management System SOAP – Simple Object Access Protocol XML – Extensible Markup Language API (Application Programming Interface) HTML – Hypertext Markup Language CSS – Cascading Style Sheets MVC – Model-View-Controller HTTP – Hypertext Transfer Protocol SMTP – Simple Mail Transfer Protocol IT – Informační technologie JSON – JavaScript Object Notation AIR – Adobe Integrated Runtime
44
Přílohy Obsah přiloženého CD Na přiloženém CD se nachází zdrojové kódy rozšíření e-shopového řešení, které umožňuje vystavovat produkty na portále aukro.cz.
45
