Mendelova univerzita v Brně Provozně ekonomická fakulta
Možnosti automatizovaného přenosu dat o produktech a návrh jednotného řešení Diplomová práce
Vedoucí práce: Bc. Ing. Roman Malo, Ph.D.
Bc. Milan Němec
Brno 2012
Rád bych chtěl touto cestou poděkovat vedoucímu své práce Bc. Ing. Romanu Malovi, Ph.D., který mi během vytváření práce poskytl cenné rady a připomínky. Dále bych chtěl poděkovat kolegům ve firmě Sunlight systems s.r.o., své rodině a přátelům za podporu.
Prohlašuji, že jsem diplomovou práci vyřešil samostatně s použitím literatury, kterou uvádím v sekci Literatura. Při jejím vypracovávání jsem vycházel z připomínek Bc. Ing. Romana Mala, Ph.D. a požadavků společnosti Sunlight systems s.r.o.
Abstract Bc. Milan Němec Options for Automatic products data transfer and proposal for a uniform solution This diploma thesis describes examples of systems that uses products data transfer. Format of transmitted data is analyzed and evaluated in terms of efficiency and possiblity of scalability. Based on this understanding is then compiled the resulting format that is trying to contain the largest amount of data that can be stored about products, so that it can be used in all these systems. Keywords: data transfer, products, automatized data tranfer, XML.
Abstrakt Bc. Milan Němec Možnosti automatizovaného přenosu dat o produktech a návrh jednotného řešení Tato diplomová práce popisuje příklady systémů, které využívají přenosu dat o produktech. Formát přenášených dat je poté analyzován a vyhodnocen z pohledu účinnosti a možné rozšířitelnosti. Z takto získaných poznatků je poté sestaven výsledný formát, který se snaží obsáhnout co největší množství dat, které může o produktech uchovávat, tak, aby se dal použít ve všech zmíněných systémech. Klíčová slova: přenos dat, produkty, automatizovaný přenos, XML.
Většina odvětví lidské činnosti již pocítila více či méně vliv počítačů a internetu. Obchodování je stále více závislé na informacích a komunikaci a proto jakékoliv ulehčení, které je možné pomocí počítačů dosáhnout, je vítáno a sledováno. Za vším tímto obchodováním ovšem stojí značné úsilí mnoha programátorů, analytiků, návrhářů a v případě E-shopu i grafiků. Ti k vytvoření softwaru, který by plnil zákazníkem požadovanou funkčnost, využívají nejrůznějších programovacích jazyků, technologií, systémů a datových uložišť. Všechny aplikace či systémy pracující s podobnými daty o produktech, jež daná firma nějakým způsobem zpracovává a používají různé způsoby ukládání svých dat. Pro přenos mezi dvěma systémy, které by mezi sebou měly komunikovat, či nahrazování jednoho systému druhým, vyžaduje vytvoření nějakého rozhraní. V tomto rozhraní musí být definován formát, ve kterém se budou data předávat. Jelikož každý systém eviduje jiná data a jiné návaznosti daných produktů, formáty těchto přenosů jsou vždy jiné. Záleží hlavně na straně, která má při tvorbě tohoto rozhraní hlavní slovo. Případy jsou různé, ale většinou se jedná o problém, kdy jedna strana má hotové nějaké rozhraní, kde má definovaný svůj vlastní formát a druhá strana jej implementuje do svého systému. Příkladů takovýchto řešení je mnoho druhů. Ideálním příkladem jsou v dnešní době čím dál více využívané vyhledávače zboží. Už z jejich povahy — porovnávání zboží z různých e-shopů vyplývá, že by pro ně nebylo únosné dělat propojení s každým e-shopem zvlášť. Proto si pro sebe vytvořili vlastní formát, ve kterém přijímají informace o produktech, jejich cenách a dostupnosti. Nejznámější pro Českou republiku jsou Zbozi.cz, Heureka, Google nákupy a Monitor.cz. Každý z těchto čtyř jmenovaných má více či méně odlišný formát od druhého a proto je třeba pro úspěšný e-shop minimálně tyto 4 formáty podporovat. Ostatní vyhledávače převzaly některý z těchto formátů a používají jej. Za doby využívání veškerého elektronického zpracovávání informací o produktech nebyl ustálen způsob ani formát, ve kterém by se tato data měla pro rozhraní používat. Oficiálně nebyl uveden ani žádný formát pro komunikaci mezi těmito systémy, který by ulehčil propojování těchto systémů, ať už je účelem propojení jakákoliv funkčnost.
2
CÍLE PRÁCE
2
8
Cíle práce
Žádný doposud používaný formát pro práci s produkty není použitelný ve všech odvětvích E-commerce. Většina formátů je navržena tak, aby zvládala obsáhnout požadovaná data, ovšem již se neřeší možné budoucí rozšiřování funkcí a obsahu výsledného souboru s daty. Rozšiřování pak mohou postihovat problémy se zpětnou kompatibilitou či nevhodnou reprezentovací dat. Cílem práce tedy je analyzovat a porovnat stávající formáty pro práci s daty o produktech. Z takto získaných dat poté odvodit nový formát, který by byl použitelný pro většinu typů zkoumaných systémů. Dále pak prozkoumat možnosti výsledného formátu a navrhnout jeho další možná uplatnění. Dle zadání od firmy Sunlight systems s.r.o., která se zabývá tvorbou e-shopů, by tedy cílem mělo být zhodnocení formátů ze stávajících systémů, které s podobnými daty pracují. Zhodnocení by mělo obsahovat porovnání dat, vyhodnocení problémů, nedostatků či výhod a rozčlenění na důležitá a méně důležitá data. S těmito výsledky poté začít na tvorbě formátu, který by dokázal pojmout co nejvíce dat ze stávajících formátů a umožňoval i reprezentaci dat, která ve formátu uvedena nebudou. E-shopy jsou částí množiny služeb, které se hromadně nazývají E-commerce. E-shopy jsou ovšem specifické tím, že u nich mohou a často bývají požadavky na automatizovanou komunikaci s větším množstvím ostatních systémů v oblasti Ecommerce. Výsledný formát by tedy měl být použitelný a přenositelný pro všechny druhy takovýchto systémů, jež s podobnými daty pracují. Kdyby se formát neujal jako univerzální řešení a ostatní firmy by jej nezačaly využívat a začleňovat do svých řešení, stále by měly být poznatky a možnosti formátu využitelné jinými způsoby. Dále je zde požadavek na možnost exportu i dalších specifických dat, které se u ostatních formátů nevyskytují. Jedná se o možnosti systému Sun-shop, které v určitých případech převyšují potřeby systémů v ostatních odvětvích E-commerce. Data o produktech by tedy měly obsahovat i následující: • Více možných identifikátorů, názvů a popisů produktů, • různé typy produktů pro bazarový prodej či prodej služeb, • různých typů dokumentů, které mají souvislost s daným produktem, • štítků, jež mohou být produktu přiřazeny, • více cenových skupin produktů, • data o dodavatelích, • varianty, příbuzné, doplňkové, alternativní zboží a dárky k danému produktu.
3
ANALÝZA SOUČASNÉHO STAVU
3
9
Analýza současného stavu
3.1
Obecný přehled přenosu produktů
Přenos informací produktů může být požadován mezi dvěma ekonomickými subjekty, nebo v rámci jednoho subjektu. Pro přenos mezi dvěma subjekty patří například přenos dat od dodavatele. Uvnitř jednoho subjektu je požadována například komunikace mezi pobočkami nebo komunikace mezi používanými softwarovými systémy. Při zřizování jakéhokoliv řešení automatické komunikace mezi systémy se obvykle vychází z již existujících řešení, která jsou již k dispozici.
3.2 3.2.1
Metody přenosu HTTP
Hyper Text Transfer Protocol je internetový protokol určený původně pro výměnu hypertextových dokumentů ve formátu HTML (Hyper Text Markup Language). Tento protokol je spolu s elektronickou poštou tím nejvíce používaným a zasloužil se o obrovský rozmach internetu v posledních letech. HTTP používá jako některé další aplikace tzv. jednotný lokátor prostředků URL (Uniform Resource Locator), který specifikuje jednoznačné umístění nějakého zdroje v internetu. K protokolu HTTP existuje také jeho bezpečnější verze označovaná jako HTTPS, která umožňuje přenášená data šifrovat, a tím chránit před odposlechem či jiným narušením. Protokol funguje způsobem dotaz – odpověď. Uživatel (pomocí programu, obvykle internetového prohlížeče) pošle serveru dotaz ve formě čistého textu, obsahujícího označení požadovaného dokumentu, informace o schopnostech prohlížeče apod. Server odpoví pomocí několika řádků textu popisujících výsledek dotazu (zda se dokument podařilo najít, jakého typu dokument je atd.), za kterým následují data samotného požadovaného dokumentu. (David Procházka 2011) Pomocí protokolu HTTP nemusí docházet pouze ke stahování HTML dokumentů. Lze jej použít na libovolný soubor. V tomto případě bývá použit pro přenos XML dokumentů. Tuto možnost využívají všechny vyhledávače zboží. Eshopy umisťují své feedy na určitou URL adresu své domény a vyhledávače si je v pravidelných intervalech stahují pro zpracování a umisťují aktuální informace do svých databází. Dodavatelé tento protokol také využívají, ovšem ne všichni mají tato data volně dostupná. Používají například autentizaci, nebo unikátní URL adresy obsahující přihlašovací údaje či Hash kódy, které náleží danému partnerovi. Schémata dokumentů pro vyhledávače a nápovědy k nim jsou veřejně dostupné na internetu. Zájem vyhledávačů je, aby jejich služby využívalo co nejvíce obchodů a proto se snaží integraci s jejich systémem ulehčit. Naproti tomu dodavatelé svoje feedy a dokumentaci k nim neposkytují vždy tak lehce. U některých je zapotřebí registrace a smluvní ujednání, aby partnerovi umožnili přístup k jejich datům.
3.2
Metody přenosu
3.2.2
10
FTP
File Tranfer Protocol je prakticky nejrozšířenějším protokolem pro kopírování souborů na webový server. Pro práci s tímto protokolem je důležité vlastnit některý z programů spadajících do kategorie FTP klient. FTP klient umožňuje manipulaci se soubory, které tvoří obsah webu. Lze s ním provádět veškeré možné operace se soubory na webu, tj. přenos souborů na server, vytváření adresářů na serveru, mazání souborů a adresářů na serveru. FTP klient poskytuje naprostou kontrolu nad obsahem webu. Doporučení FTP klienti: • Total Commander — Pravděpodobně nejoblíbenější souborový manažer, který vyniká širokým spektrem funkcí, ale stále zachovává přehlednost, jednoduchost a rychlost. • FileZilla — Tento bezplatný FTP klient nabízí funkce, ale není složitý a má velmi jednoduché ovládání. FileZilla patří do kategorie opensource, distribuovaný pod GNU General Public Licencí a je tedy volně šířitelný. • WinSCP — Český volně šířitelný FTP a CSP (Secure Copy) klient pro windows používajcí SSH. Jeho hlavním účelem je bezpečné kopírování souborů mezi lokálním a vzdáleným počítačem. (David Procházka 2011) Tento protokol je také možné použít pro přenos dat o produktech. Dodavatelé obvykle umístí na veřejně dostupný server data o svých skladových zásobách a pomocí tohoto protokolu si je pak jejich partneři stahují. Pro automatizaci je nutné dodržovat pravidla ohledně názvu souborů či jejich umístění. Automatizované napojení se pouze připojí k serveru pomocí tohoto protokolu a stáhne si požadované soubory. Dle nich poté aktualizuje svoji databázi. 3.2.3
SOAP
Webové služby umožňují jednoduchou komunikaci mezi aplikacemi ve velmi heterogenním prostředí, protože komunikace je založena na platformě nezávislých technologií, jako je jazyk XML a protokol HTTP. Aplikace si mezi sebou posílají zprávy XML, které přenášejí dotazy a odpovědi jednotlivých aplikací. Celá infrastruktura webových služeb bývá založena na třech základních technologiích: • SOAP (Simple Object Access Protocol) — obálka a způsob kódování dat používané pro komunikaci. • WSDL (Web Services Description Language) — formát pro podpis rozhraní webové služby. • UDDI (Universal Description, Discovery and Integration) — standardní mechanismus umožňující registraci a vyhledávání webových služeb.
3.3
Formáty souborů používaných pro přenos
11
Pro webovou službu většinou existuje popis jejího rozhraní ve formátu WSDL. Součástí tohoto popisu je i definice schématu vstupní a výstupní zprávy XML a informace o tom, jakým protokolem a na jaké adrese je možné se službou komunikovat. Z těchto informací již jednoznačně plyne, jak má vypadat odpovídající SOAP požadavek. SOAP není protokol, jen jednoduchá obálka kolem samotných přenášených dat. Nabízí však prostor pro vložení různých servisních informací, jako jsou třeba digitální podpisy nebo přihlašovací údaje pro přístup ke službám vyžadujícím autorizaci. (Jiří Kosek 2009) Pomocí webových služeb je také možné přenášet data o produktech. Stejně jako u předchozích možností přenosu, stačí pouze přenést dokument a aktualizovat databázi dle takto získaných dat. Webové služby se ovšem dají použít i pro efektivnější synchronizaci dat. Předešlé způsoby byly založeny na pravidelném kopírovaní zdrojových dat a jejich aktualizaci. Webové služby se mohou využít i opačným způsobem. Je pomocí nich možné využít opačný tok dat a při aktualizaci dat u dodávajícího subjektu je možné zaslat informaci o změnách i s daty, která mají být použity pro aktualizaci. Tento způsob není zrovna obvyklý, ovšem z pohledu objemu dat, výpočetního výkonu a aktuálnosti synchronizovaných dat je tato metoda mnohonásobně výhodnější, než doposud zmíněné.
3.3 3.3.1
Formáty souborů používaných pro přenos XML
Pro zmíněný přenos se v dnešní době používají většinou dva datové formáty. Formát XML byl navržen speciálně pro přenos dat v oblasti počítačových technologií a internetu a těší se stále větší oblibě. Oproti CSV má nespornou výhodu v možnostech reprezentace dat. Jeho stromová struktura umožňuje přehledněji a jednodušeji uchovávat podrobnější data. Nevýhodou reprezentace dat v XML souboru je při konfrontaci s laiky. Bez aplikace, která s daným souborem pracuje a umožňuje jeho editaci, je pro laiky téměř nemožné přímo zasahovat do dat v takovémto souboru. To je oproti formátu CSV, který může uživatel editovat v tabulkových procesorech (Microsoft Excel, OpenOffice Calc, . . .), nevýhodou. Zmíněné tabulkové procesory sice dokáží do jisté míry zpracovávat XML soubory, ovšem pouze do chvíle, než se objeví složitější, víceúrovňová struktura dokumentu. Jak již z funkce zmíněných programů vyplívá, pracují hlavně v dvourozměrném prostoru tabulky a proto je pro ně obtížné vizualizovat uživateli stromovou strukturu XML dokumentu. Při vytváření procesu automatizace přenosu dat jsou ovšem zapojeni hlavně programátoři a návrháři se vzděláním v oblasti IT, kteří určitě o formátu XML minimálně slyšeli a znají základy. Z důvodu syntaxe čitelné člověkem je tedy formát XML lepší pro uchovávání kompletních dat o produktech.
3.3
Formáty souborů používaných pro přenos
12
Záleží samozřejmě na účelu, množství dat a jejich struktuře. V některých případech nemusí být použití formátu XML ideálním řešením. Například pokud bychom chtěli přenášet pouze data o počtech kusů na daném skladě, stačí jednoduchá tabulka, která by obsahovala sloupec s identifikátorem produktu a sloupec určující počet kusů. Pro takovýto přenos postačuje využití formátu CSV nebo jemu podobné.
Obrázek 1: Vzor XML
3.3.2
CSV
Kompaktnější ze zmíněných formátů je CSV soubor. Využívá se nejen na přenosy zmíněných dat, ale pro správu dat jakéhokoliv typu, jež se dají hromadně editovat v tabulkových procesorech a mají být následně strojově zpracovávána. CSV (Comma separated values) je textový typ souboru obvykle uchovávající tabulková data. Jeho obsah lze získat i za pomoci editace obyčejným textovým editorem. Při větších objemech dat je samozřejmě výhodnější použít některý z dostupných tabulkových procesorů. Soubor dokáže zpracovávat Microsoft Excel a s daty, které uchovává, tedy mohou nakládat i méně zkušení uživatelé. Jak již ze zkratky vyplývá, formát byl vytvořen tak, že hodnoty buněk tabulky jsou oddělené čárkami. Nejen v naší zemi se ovšem čárka používá jako oddělovač desetinných míst a proto je možné používat i jiné oddělovače. MS Excel například jako základní oddělovač bere středník. Naproti tomu OpenOffice Calc umožňuje zvolit z mnoha různých variant (mezi nimi i zmiňovaný středník). OpenOffice Calc je pro práci s tímto formátem uzpůsoben více i kvůli jednodušší možnosti uložení textu v jiném kódování. MS Excel (testováno na verzi 2007) má navíc problémy s většími soubory a při dostatečně velkém obsahu buňky nedokáže správně tuto buňku zpracovat. Při zobrazování je buňka rozdělena na více buněk a zbytek, který nezpracuje, se bere jako buňka nová. Jestliže tato situace nastane,
3.4
13
Zen Cart — Easy Populate
kompletně se tím zničí struktura souboru a zbylá data jsou již zobrazena ve špatném tvaru. Po uložení jsou již ve výsledném souboru data za touto extrémně velkou buňkou znehodnocena a pro strojové zpracování nepoužitelná. V následujících kapitolách jsou popsány formáty pro přenos dat o produktech, ovšem žádný z uvedených příkladů není ve formátu CSV. Formát souboru pro import a export dat do systému Zen Cart za pomocí rozšíření Easy Populate je jemu podobný, ovšem jako oddělovač zde slouží místo čárky znak tabulátoru. Použití tabulátoru není zcela standardní a spíše se využívá právě formátu CSV.
Obrázek 2: Vzor CSV 3.3.3
Binární datový formát
Tento formát sice v prostředí internetu nebývá používaný často, ale je to další možnost přesunu takovýchto dat. Pro přenos dat mezi dvěma odlišnými systémy není moc použitelný. Binární datový formát je velice kompaktní a oproti předchozím dvěma jsou data uchovávána velice efektivně. Jelikož struktura souboru je řešena přesně dle specifikací daného programu, komunikace by obvykle probíhala mezi dvěma instancemi jedné aplikace nebo dvěma systémy od stejného výrobce.
3.4
Zen Cart — Easy Populate
Zen Cart je systém pro tvorbu online E-commerce skladu určeného pro prodej zboží a služeb. Je napsán v PHP a potřebuje ke své činnosti MySQL databázi. Zen Cart může být použit pro prodej hmotného zboží jako například boty, piana nebo nehmotného zboží jako například dárkové certifikáty, stahování hudby, atd. Je možný i prodej služeb jako například zákaznické podpory. Vývojáři systému Zen Cart se snaží řídit heslem The Art of E-Commerrce“. ” Toto heslo se snaží udržovat jako cíl při tvorbě tohoto softwaru. Proto je software navržen hlavně pro potřeby majitelů obchodů a jejich nakupujících. Majitelé obchodů nepotřebují vzdělání v oboru IT k nastavení a administraci jejich webových stránek a nakupující se mohou jednoduše navigovat v tomto e-shopu a procházet jeho
3.5
Lauratrade.cz
14
položky. Programátoři také nezapomínají na to, aby byl zdrojový kód Zen Cartu dobře strukturován a navržen pro jednoduchou údržbu a snadnou ovladatelnost. Zen Cart je zcela zadarmo s mnoha rozšířeními pro e-commerce, která jsou k němu dostupná. Proto není třeba velkých investic pro vytvoření online robustní a profesionální e-commerce prezentace. Jediné, co je třeba platit, jsou poplatky za web hostingové služby a možná nějaké grafické úpravy, pokud je zájem o jiný vzhled. Zdrojové kódy Zen Cartu jsou volně k dispozici pod licencí GNU General Public Licence. V podstatě dává tato licence komukoliv právo upravovat zdrojové kódy pro vlastní potřebu. Upravené zdrojové kódy ovšem podléhají určitým omezením, pokud mají být poskytovány dále. (Koon Hoek Goh 2007) Zen Cart — Easy populate je modul pro systém Zen Cart, který má možnost importu i exportu produktů do systému. Easy Populate dokáže aktualizovat i vytvářet nové produkty. Data jsou exportována do formátu textové tabulky, která je oddělena znakem tabulátoru. Takto vytvořený textový soubor je poté možné hromadně editovat v programech MS Excel nebo OpenOffice Calc. Je ovšem nutné dodržet oddělovač buněk tedy tabulátor. (Zen Cart Wiki Media 2011)
3.5
Lauratrade.cz
Na stránkách internetového obchodu www.lauratrade.cz naleznete bohatý výběr spodního prádla jak pro dámy, tak i pro pány. Tento internetový obchod také umožňuje velkoobchodní prodej a svým partnerům umožňuje aktualizaci produktů přímo online pomocí XML feedu, který je volně dostupný na URL http://lauratrade.cz/io/produkty–lauratrade–cz.xml. Exporty obsahují: (Lauratrade.cz 2012) • id a název zboží • kategoriii zboží • popisky a obrázky • barvy a velikosti • dostupnost a počty kusů skladem • tip, novinka, výprodej • přímý link na produkt na e-shopu • prodejní cena s DPH v Kč na Export CZ nebo v EURECH na Export SK • původní cena (pokud je zboží zlevněno).
3.6
Zbozi.cz / Heureka.cz / Google produkty
15
Na začátku tohoto feedu jsou také data o stromové struktuře kategorií produktů. Ty jsou uzavřeny v emelentu “categories”. Z dostupných informací je tedy možné získat kompletní stromovou strukturu i s produkty, které do nich patří. Feed obsahuje vše podstatné, co tento velkoobchod u produktů eviduje.
3.6
Zbozi.cz / Heureka.cz / Google produkty
Zboží.cz, Heureka.cz a Google produkty jsou služby, jejichž pomocí můžete vyhledávat informace o nabízeném zboží a jeho cenách mezi registrovanými internetovými obchody. Jde o zprostředkování prodeje, nikoliv o samotný prodej. Prodej produktů si pak obchody zajišťují samy. Jejich úkolem je poskytnout co nejrychlejší a nejpřehlednější vyhledávání vhodných obchodů. Jako první krok nákupu si vyhledáte zboží. Můžete vyhledávat zadáním názvu produktu nebo kategorie do vyhledávacího políčka. Na úvodní stránce si můžete také vybrat kategorii a procházet celým katalogem produktů. Zboží, které zde můžete najít, není prodáváno přímo těmito portály ale obchody, které na své doméně mají umístěn XML feed s aktuálním stavem zboží v e-shopu a jejich dostupnostmi. Tyto feedy si vyhledávače pravidelně stahují a aktualizují dle nich jejich vyhledávání. Tyto feedy obsahovaly zprvu pouze základní údaje o produktech, ovšem postupem času se feedy rozšiřovaly o další atributy produktů. Důvodem byl nárůst popularity těchto vyhledávačů a s tím spojená snaha zkvalitnit služby těchto vyhledávačů.
3.7
Money S3
Účetní program Money S3 patří mezi nejrozšířenější ekonomické systémy pro malé a střední firmy v České i Slovenské republice. Nabízí všechny potřebné moduly – podvojné účetnictví i daňovou evidenci, adresář, fakturaci, sklady, objednávky, mzdy a řadu dalších funkcí včetně homebankingu, propojení s pokladními systémy internetovými obchody a dalšími aplikacemi. Tento účetní systém je velmi oblíben také pro svou jednoduchou a snadnou obsluhou v prostředí Microsoft Windows. Účetní program Money S3 využívá široké spektrum zákazníků napříč všemi obory, od nákupu a prodeje až po výrobu a služby. Mezi jeho uživateli jsou velkoobchodní řetězce, zemědělská družstva, strojírenské firmy a také drobní živnostníci a podnikatelé. V nabídce jsou rovněž varianty Money S3 pro neziskové organizace a školy. Vše při velmi dobrém poměru cena – výkon, zajištěnou servisní sítí po celém území ČR a pravidelnou aktualizací. Vyspělý účetní software lze rozšířit užitečnými doplňky a moduly. Pro Money S3 je to například Kniha jízd a cestovních náhrad, včetně rekonstrukce jízd. Účetní firmy a profesionálové ocení modul Aktivní saldo pro snadné čištění salda a Účetní centrála pro přenášení dokladů od klientů.
3.8
Pohoda
16
Money S3 v současnosti podporuje nejenom export, ale i import dat v tomto formátu. Díky tomu má ekonomický systém široké možnosti komunikace s dalšími aplikacemi — již nyní jsou k dispozici řešení pro výměnu dat s pokladními systémy, aplikacemi třetích stran a dokonce i můstky typu XML-EDI, které vám otevírají cestu pro komunikaci s obchodními řetězci. Kromě předem připravených řešení máte ovšem prostor vytvářet i svá vlastní. Díky tomu, že komunikační formát je otevřený a zdokumentovaný, mohou již nyní proudit oběma směry mezi vaší vlastní aplikací a Money S3 údaje typu adresa, kmenová karta, skladová zásoba, faktura, zakázka, objednávka, nabídka, poptávka, příjemka, výdejka, dodací list, prodejka, bankovní a pokladní doklad atd. (Cígler SOFTWARE 2012) Schémata tohoto programu nejsou na veřejně dostupném webu, ale zpřístupní se až po instalaci programu. Pro účely této analýzy byla použita zdarma poskytovaná verze programu na neomezenou dobu. Tato schémata jsou k nalezení po instalaci programu v adresáři MoneyS3 \Data \XMLDE \Schemas \__Zasoba.xsd. Money S3 stejně jako Pohoda dovoluje export a import XML souborů buď přímo v daném programu, nebo přes příkazový řádek. K provedení importu či exportu ovšem není nutné mít speciální konfigurační soubor. Všechny podrobnosti o prováděné akci jsou předávány přímo jako parametry spouštění programu. Souboru, jehož název je programu předán, slouží při importu jako zdroj dat a při exportu jako cesta, kam má program uložit vyexportovaná data. Absence vstupního souboru při exportu dat tedy neumožňuje využít filtrování pouze určitých prvků (tak jak je tomu u Pohody) a tak jsou tedy výstupní soubory větší. Ovlivnit výstup těchto exportů je možné pouze přímo v programu pomocí speciálních přídavných modulů pro rozšíření exportu. Při importu je také třeba zadávat název souboru, kam se bude ukládat výstupní zpráva o provedeném importu. Tuto funkci tedy mají s Pohodou společnou.
3.8
Pohoda
Program POHODA je komplexní účetní a ekonomický software pro malé, střední a větší firmy z řad fyzických i právnických osob. Umožňuje vést účetnictví i daňovou evidenci a vyhoví plátcům i neplátcům DPH. Systém je oborově neutrální a je vhodný nejen pro živnostníky, podnikatele a společnosti, které se zabývají obchodem a poskytováním služeb, ale i pro svobodná povolání a účtující příspěvkové a neziskové organizace. Systém je určen výhradně pro operační systémy Windows a proto jsou databáze tohoto programu ukládány dle těchto možností. Na výběr je ze dvou možností. Do souboru mdb (výstupní formát Microsoft Access) nebo verze SQL do databáze Microsoft SQL. Pro verzi SQL je nutné mít na serveru Microsoft SQL Server 2008 R2 Express. Program POHODA využívá komunikační rozhraní XML, díky kterému můžete přijímat i odesílat data z a do různých aplikací, včetně internetových obchodů
3.8
Pohoda
17
a externích softwarových modulů pro zpracování dat souvisejících s databázemi programu POHODA. V současné době je tato komunikace upřednostňována před importy a exporty tabulek i přímým přístupem do databáze. Důvodem je vyšší bezpečnost operací, neboť při XML komunikaci dochází ke kontrole a validaci dat tak, jako by šlo o operace vykonávané přímo v prostředí programu. Např. při importu dokladů ve formátu XML tak dochází ke kontrole vstupních údajů, dopočítání chybějících informací a v případě chybovosti importovaných dat také k upozornění na nutnost doplnění nebo přepracování XML souboru bez jeho importování. Bezpečnost této formy komunikace je srovnatelná s bezpečností a možnostmi ručního zápisu dat v prostředí programu POHODA. XML komunikace se na rozdíl od jiných forem importů a exportů dat i nadále vyvíjí a XML možnosti, výkonnost a použitelnost tak neustále stoupá. Výhodou této formy komunikace je také její otevřenost, nezávislost, dostupnost a v případě použití transformačních XSL souborů plná přenositelnost mezi libovolnými systémy. Zpracování XML komunikace lze provádět pomocí dávkového zpracování, které plně automatizuje výměnu informací a umožňuje tak implementovat XML komunikaci s programy společnosti STORMWARE do externích aplikací vyvíjených např. našimi obchodními partnery, případně jinými společnostmi. Je také možné zpracovávat XML komunikaci přímo z prostředí programu s veškerým uživatelským komfortem. (Stormware Software Development 2012) Import a export dat je možné provádět přímo v samotné aplikaci, ovšem pro uplatnění v automatizaci přenosů dat je jistě vhodnější využít ovládání tohoto rozhraní pomocí příkazové řádky systému Windows. Tento import a export dat z Pohody je řízen pomocí ini souboru, který je programu předán jako parametr při spuštění a vstupním XML souborem, který definuje akci, jež bude prováděna. Všechny možné akce a přehled jejich náležitostí uvádí firma Stormware na svých internetových stránkách a je tedy přístupná k nahlédnutím komukoliv. Definice způsobu ovládání programu Pohoda pomocí příkazové řádky je popsaná v definicích samotných principů importu a export, zatímco možnosti a volby pro vytváření požadavků a odpovědí od Pohody je uváděna jako seznam schémat, jejich popisů a vzorů použití pro různé verze i různé konfigurace. Před samotným importem či exportem do Pohody je nutné oba dva zmíněné soubory připravit: 1. Konfigurační soubor, který bude obsahovat základní nastavení importu. Vzorová konfigurace: input_xml='C:/PohodaXML/in.xml' response_xml='C:/PohodaXML/out.xml' database='12345678_2011.mdb'
3.8
Pohoda
18
check_duplicity=1 format_output=0 • Input_xml Určuje vstupní soubor požadavku. Jedná se o XML soubor, ve kterém je definováno, co požadujeme na výstupu (při exportu dat), nebo vstupní data (při importu dat). • response_xml Definuje, kam bude vyexportován výsledek zpracování vstupního souboru. Výsledek obsahuje vyexportovaná data, či výsledky a stavy provedeného importu zároveň s doplňujícími informacemi o zpracování. • database Určuje databázový soubor účetní jednotky, na kterém se budou požadované operace provádět. • chceck_duplicity Určuje, zda se bude vstupní soubor kontrolovat s již provedenými akcemi, které byly přes toto rozhraní prováděny. Toto nastavení je hlavně kvůli importům dat, aby nedocházelo k duplicitám. • format_output Nastavuje, zda výstupní soubor odsazovat pro čitelnost přímo XML dokumentu. Jsou tedy ve výstupním souboru zahrnuty i znaky pro odsazení elementů a znaky nových řádků. (Stormware Software Development 2012) 2. Vstupní XML soubor, ve kterém je specifikováno, jaká akce se má provést. V tomto XML dokumentu je uvedeno, zdá má být proveden import či export a potřebná data, specifikující prováděnou akci. Při exportu je v tomto souboru možné uvést nastavení filtrů, které budou pro export dat použity. Například při exportu produktů je možné specifikovat pouze určité kategorie, ze kterých se budou brát data o produktech. Při importu reprezentuje tento vstupní XML soubor data, která se mají do systému Pohoda naimportovat. Dle nastavení a v případě správného nastavení identifikátorů je možné provádět i aktualizaci již existujících záznamů.
4
TEORETICKO METODICKÁ VÝCHODISKA
4 4.1
19
Teoreticko metodická východiska Metodika tvorby formátu
Pro vytvoření zadaného formátu je nejprve třeba vybrat vzorek systémů, které budou zkoumány. Jelikož systémů, pracujících s podobnými formáty je velké množství, byly zde vybrány pouze nejzákladnější. Byly vybrány již zmíněné systémy: • Zen Cart, • e-shop Lauratrade.cz, • vyhledávače zboží, • účetní systém Money S3, • účetní systém Pohoda. Požadavek, který musely dané systémy splňovat, byl pouze aby pracovaly s nějakým formátem pro přenos dat o produktech mezi systémy a popisy těchto formátů byly volně dostupné. U většiny zmíněných systémů je popis formátu dostupný přímo na internetu. Výjimkou je Money S3, kde jsou schémata pro import a export dostupná až po nainstalování základní neplacené verze Start“. Jelikož účetní programy ” obvykle uchovávají největší množství dat o produktech oproti ostatním systémům, byl i tak systém Money S3 do analýzy zahrnut, aby byly zřejmé rozdíly mezi těmito účetními systémy. Vyhledávače zboží mají obvykle formát podobný s ekvivalentním množstvím dat, proto byly porovnávány hned 3 systémy. Objem dat je zde menší, než u účetních systémů a proto byly všechny shrnuty v jedněch podkapitolách. Jako dalším vzorkem pro analýzu byl vybrán jeden E-shop, jež umožňuje velkoobchodní prodej a poskytuje feed pro své partnery. Tento feed je ve formátu XML, což není vždy pravidlem u dodavatelů. Mohou se také vyskytovat dodavatelé, jež poskytují aktualizace svého zboží ve formátu CSV. Záleží na organizacích, jakou mají mezi sebou domluvu, a jaké funkce jejich systémy nabízejí. Doposud zmíněné systémy většinou pracují se soubory ve formátu XML kvůli složitější struktuře dat. Proto je zde vybrán i Zen Cart, který nepoužívá zrovna hojně používaný formát. Výstup je ovšem velice podobný struktuře CSV souboru. Analýzou je poté třeba zjistit možnosti, daných formátů z pohledu obsahu dat a jejich možností reprezentace. Zároveň je třeba zjistit případné chyby v reprezentaci dat a ve výsledném formátu se jich vyvarovat. Z těchto výsledků poté tedy vybrat formát souboru, který bude použit pro uchovávání dat. Jakmile bude hotový soupis požadovaných dat, je třeba tato data roztřídit do skupin dle souvislostí a možných hodnot. Takto logicky seskládané požadavky na výsledný formát je třeba reprezentovat ve schématu, které bude popisovat první verzi formátu. K tomuto schématu je poté vhodné vytvořit vzorový dokument, který bude sloužit jako návrh výstupu daných systémů. Pomocí iterativního vylepšování
4.2
XML
20
poté odhalovat nedostatky a při porovnávání se stávajícími řešeními, vylepšovat výsledný formát tak, aby byla zvyšována jeho použitelnost při zachování univerzálnosti. Pro zjednodušení implementace v systémech je vhodné výsledné schémat opatřit komentáři, které by mohli sloužit jako dokumentace daného formátu. Pro strukturu dat, která mají být ve výsledném formátu uchovávána, byl zvolen formát XML. Při použití XML je možné využít nástroje pro tvorbu schémat XML dokumentů XSD. Pomocí XSD je tedy výsledný formát popsán a zdokumentován. Dále se poté ke XML váže možnost transformace těchto dokumentů do odlišných formátů za pomocí XSLT. To umožňuje data ve výsledném formátu transformovat do jiních již existujících formátů. Všechny tyto formáty (XML, XSD, XSLT) a jejich možnosti jsou popsány v následujících kapitolách.
4.2
XML
Formát XML definovalo konsorcium W3C jako formát pro přenos obecných dokumentů a dat. XML je zkratka pro eXtensible Markup Language, tj. rozšiřitelný značkovací jazyk. Návrh XML vychází ze staršího a obecnějšího standardu SGML (Standard Generalized Markup Language — ISO 8879:1986). Poznamenejme, že standardu SGML vycházel i formát dokumentů HTML. Sada značek HTML je pevná a slouží k vyjádření prezentační podoby dokumentu. Naproti tomu v XML sada značek pevná není, ale může být definována pro různé sady dokumentů různě. Definice sady značek může být součástí definice XML dokumentu, může být specifikována odkazem, nebo může být dohodnuta předem. Značky slouží k označení určitých prvků dokumentu. Značky mají otevírací závorku (start-tag), např. <popis>, a zavírací závorku (end-tag), např. . Pokud je text mezi závorkami prázdný, lze dvojici otevírací závorky nahradit prázdným elementem (empty-element), např. <podpis/> Pomocí značek XML vyznačíme syntaktickou strukturu dokumentu. Sémantika značek ani význam jejich obsahu nejsou pomocí XML definovány. Význam XML spočívá v tom, že struktura dokumentu je známa, lze ji kontrolovat a zpracovat obecnými nástroji. Libovolná aplikace si může strukturu dokumentu zjistit a dle této struktury jej zpracovat — např. zjistit, kdo zprávu podepsal. Potřeba nezávislého formátu pro reprezentaci a přenos obecných dokumentů je nesporná. Při návrhu XML se autoři z konsorcia W3C řídili následujícími principy: • formát XML musí být použitelný v rámci internetu, • formát XML by měl podporovat širokou škálu aplikací, • formát XML musí být kompatibilní s formátem SGML, • musí být snadné vytvářet programy, které manipulují s dokumenty v XML,
4.3
XSD
21
• množství variant XML by mělo být minimální — nejlépe žádné a • XML dokumenty by měly být čitelné a pochopitelné i pro člověka. (Mlýnková, Nečaský, Pokorný, Richta, K. Toman, V. Toman 2008) Všechna XML musí být správně strukturovaná (Well-formated). Všechny prvky správně strukturovaného XML musí být syntakticky správně. Navíc XML dokument musí obsahovat právě jeden kořenový element, všechny počáteční značky elementů musí mít odpovídající koncové značky (není-li použit zkrácený zápis prázdné značky) a všechny musí být do sebe správně vnořeny (tj. koncové značky elementů se nekříží). Navíc každý element obsahuje pouze sadu atributů s různými jmény. Jsou-li atributy součástí nějakého jmenného prostoru, pak musí být kombinace názvu jmenného prostoru a jména atributu unikátní. Obdobně všechny deklarace jmenných prostorů v rámci jednoho dokumentu musí definovat jiné prefixy a ke každému použitému prefixu jmenného prostoru musí existovat odpovídající deklarace jmenného prostoru. (Prof. RNDr Jaroslav Pokorný, CSc a kolektiv 2008)
4.3
XSD
XSD je doporučením konsorcia W3C, poskytujícím nástroje pro definování struktury, obsahu a sémantiky dokumentů XML. V porovnání s DTD a XDR má XSD dvě hlavní výhody. • Jedná se o oficiální doporučení W3C pro definice struktur dat XML. • Je to nejnovější technologie a jako taková byla vytvořena tak, aby odstranila chyby a závady jiných typů schémat (z větší části problémy s DTD). XDR je spíše alternativní technologií, jedná se spíše o implementací jedné z prapůvodních verzí schémat XSD. DTD je formát určený pro popis struktury a obsahu dokumentu, nikoli k tomu, aby XML obdařil účinným typovým systémem. Oproti tomu XDR přichází s pojmem atributů určitého typu. XSD je v tomto ohledu ještě o něco dál. Nejenom, že zesiluje důraz na důležitost typovaných atributů, ale rozlišuje také mezi jednoduchými a složitými datovými typy, zjednodušuje dědičnost typů a obsahuje plnokrevný a oficiálně přijatý systém typů XML. Schéma je soubor XML (obvykle s příponou .xsd), který popisuje syntaxi a sémantiku dokumentů XML prostřednictvím standardní syntaxe XML. Schéma XML specifikuje omezení pro obsah dokumentu a slovník, kterému musí dokumenty vyhovět, aby byly podle daného schématu platné. Dokumenty musí splňovat například všechny závislosti mezi uzly, přiřazovat atributy správného typu a dodržet přesnou kardinalitu dětských uzlů. Specifikace XML Schema je rozdělena do dvou odlišných částí. V části 1. je obsažena definice gramatiky komplexních typů (kompozitních elementů XML). Část 2. popisuje sadu primitivních typů — typový systém XML a pravidla pro vytváření
4.4
XSLT
22
nových primitivních typů, které jsou označovány jako jednoduché (simple). Nové typy jsou definovány prostřednictvím existujících typů. Schéma XML podporuje také pokročilejší a spíše objektově orientované pojmy, například dědičnost typů. (Dino Esposito 2004) 4.3.1
Jednoduché a komplexní typy
Jednoduché typy XML jsou tvořeny prostým textem a neobsahují žádné jiné elementy. Příklad jednoduchých typů zahrnující string, date a různé druhy čísel (long, double a integer). Komplexní typy XML zahrnují podřízené elementy a atributy. V praxi je komplexní typ vždy vypsán jako podstrom XML. Komplexní typ lze přidružit jen uzlu elementu, zatímco jednoduchý typ je aplikován na elementy i atributy. Jednoduché i komplexní typy jsou odvozeny z obecného typu anyType. Jednoduché typy mají také svou základní třídu anySimpletType. Nové jednoduché typy lze vyvářet z existujících typů. Kombinaci existujících jednoduchých a komplexních typů vytvoříte nové speciální typy. Pří vytváření nových typů vlastně omezujete, shrnujete nebo inventarizujete prvky a hodnoty základních typů. (Dino Esposito 2004)
4.4
XSLT
Extensible Stylesheet Language Transformation (XSLT) definuje programovací jazyk založený na XML, které slouží k převodu XML dokumentů na jiné textové formáty. V současné době je nejobvyklejším použitím XSLT převod XML dokumentu na jiný XML dokument, což pomáhá zmírnit následky nekompatibility návrhů XML dokumentů. XSLT také často používá k převodu XML dokumentu na HTML dokument nebo jiný formát sloužící k prezentaci dat. Navíc k představeným možnostem lze XSLT použít k převodu XML dokumentu na dokument libovolného jiného textového formátu (např. CSV, zdrojové kódy jazyků C++/Java, záznamy jazyka COBOL atd.). (A. Skonnard, Martin Gudgin 2006) Jako každý programovací jazyk nabízí XSLT samozřejmě možnost podmíněného výstupu a cyklů. Jakoukoliv část šablony můžeme obalit podmínkou, a odpovídající kód se provede pouze v případě, že je podmínka splněná. Jako podmínku lze použít libovolný XPath, jehož výsledek se interpretuje jako logická hodnota. Můžeme tak používat i veškeré operátory a funkce dostupné v XPathu. (Jiří Kosek 2009)
5
NÁVRH ŘEŠENÍ
5
23
Návrh řešení
5.1
Zhodnocení a poznatky ze stávajících řešení
V kapitole 2 Analýza současného stavu byly uvedeny systémy, které poskytují možnost exportu či importu ze svých formátů. Systémů je samozřejmě mnoho, proto byly vybrány pouze některé, jako reprezentativní vzorek. Jsou uvedeny systémy, které mají různý účel, ovšem data, která přenášejí, jsou v určitých ohledech dosti podobná. I přes jejich podobnost není ustaven žádný formát, který by byl navržen pro možnost použití ve všech těchto systémech. Nyní porovnáme jednotlivé formáty z pohledu obsahu a prezentace dat, která mohou být v daných formátech uváděna. 5.1.1
Zen Cart — Easy Populate
Toto rozšíření pro Zen Cart pracuje se soubory ve formátu CSV a obsah je tedy pouze tabulka (na rozdíl od ostatních, které používají XML). Soubor musí obsahovat tyto sloupce: • v_products_model — Identifikátor produktu, • v_products_image — název souboru s obrázkem udávaný relativně k zadanému umístění obrázků na serveru, • v_products_name_1 — jméno produktu, • v_products_description_1 — popis, • v_products_url_1 — externí odkaz na produkt, • v_products_price — cena, • v_products_weight — váha, • v_date_avail — dostupnost, • v_date_added — datum přidání produktu, • v_products_quantity — počet kusů skladem, • v_manufacturers_name — výrobce, • v_categories_name_1 — hlavní kategorie, • v_categories_name_2, v_categories_name_3, (až 7) — podkategorie, • v_tax_class_title — název daně, • v_status — stav produktu. (Zen Cart Wiki Media 2011) Zde jsou pro daný formát použity pouze základní vlastnosti. Zařazení do podkategorií je ovšem velice neprakticky řešeno, jelikož cesta kategorie, ve které se produkt
5.1
Zhodnocení a poznatky ze stávajících řešení
24
nachází, musí být rozdělena do více sloupců dle toho, jak hluboko zanořený produkt ve stromě je. Toto řešení je velice nepraktické pro využití tohoto formátu pro další zpracování či ukládání. 5.1.2
Lauratrade.cz
Tento internetový obchod umožňuje pro velkoobchodní odběratele import produktů z jejich feedu. Tento feed obsahuje kromě zboží i údaje o celém stromu produktů. Tyto kategorie produktů jsou uvedeny na začátku souboru v elementu “categories”. Uvádění celého stromu produktů bývá u takovýchto velkododavatelů obvyklé a je reprezentováno podobnou strukturou XML, jako je tomu zde. Tato data jsou buď jako zde udávána ve stejném souboru, nebo v souboru odděleném, který pak tedy odděluje data o stromu produktů od informací o produktech. Jelikož jsou data od dodavatelů většinou potřebná i s tímto stromem, bylo by nezbytné umožnit i stromovou reprezentaci kategorií při tvorbě univerzálního formátu. Stromová struktura je reprezentována tímto vzorovým XML: 81 <parentid>0 Dámské spodní prádlo <position>0 … (Lauratrade.cz 2012) Tato reprezentace je zcela vyhovující pro export kompletní stromové struktury pro produkty. Při práci s SQL databází je většinou strom reprezentován stejným způsobem — tedy jeden záznam obsahuje název kategorie, její ID a ID jejího případného předka. Struktura XML souboru pro přenos produktů je následující: <product> 7119Dámská halenka Grace – Top <shortname>Grace – Top http://damske-halenky.lauratrade.cz/damska–halenka–grace–top– 7119.htm 0
5.1
Zhodnocení a poznatky ze stávajících řešení
25
0 <novinka>0 <description>Luxusní a elegantní halenka ELDAR Grace vyrobená z viskózy s krajkou a tylem. Zaručuje vysoký komfort při nošení. Složení: 95% Viskoza,5% Elastan. Barva černá. Romantica TOP Collection 2010. 20černáSMLXL <stock> 10 −999 −1111 <pricewithdph>472 0 <producer>ELDAR 175 (Lauratrade.cz 2012) Zde je patrné, že kromě základních atributů produktu je možné již ze základu produkt zařadit do více kategorií a zároveň mít více obrázků k danému produktu.
5.1
Zhodnocení a poznatky ze stávajících řešení
26
Parametry jsou zde ovšem dva a bez rozšíření formátu není možné další parametry přidat. Stejný problém zde nastává se štítky — Tip, Výprodej, Novinka. 5.1.3
Zbozi.cz / Heureka.cz / Google produkty
Zbozi.cz a Heureka.cz začínaly s obyčejnými XML, kde bylo pouze jméno, popis, dostupnost, zařazení v kategorii a několik dalších parametrů, které byly specifické pro každého z jmenovaných. Postupem času začínala popularita takovýchto vyhledávačů růst a tak začínalo přibývat služeb, které poskytují. S přibývajícími službami byly navýšeny i požadavky na vstupní XML, které obchody generují. Na konci roku 2011 byla navíc spuštěna služba Google nákupy, čímž společnost Google rozířila svoji působnost i do produktových vyhledávačů. Feed pro Heureku obsahuje tyto údaje: • ITEM_ID — jednoznačný identifikátor produktu, • PRODUCTNAME — přesný název produktu, • PRODUCT — rozvětvený název produktu včetně přívlastků, • DESCRIPTION — popis, • URL — odkaz na produkt v daném e-shopu, • IMGURL — hlavní obrázek, • IMGURL_ALTERNATIVE — alternativní obrázek, • VIDEO_URL — video k produktu, • PRICE_VAT — cena s daní, • ITEM_TYPE — identifikátor produktu z bazaru, • PARAM — rozšiřující parametry produktu, • MANUFACTURER — výrobce, • CATEGORYTEXT — zařazení ve stromě produktů, kde znak |“ slouží jako oddě” lovač podkategorií, • EAN • ISBN • HEUREKA_CPC — specifický atribut pro Heureku určující maximální nabídku za prokliky, • DELIVERY_DATE — dodací doba produktu zadaná buď jako datum, čas v hodinách nebo 0“ pro skladové položky ”
5.1
Zhodnocení a poznatky ze stávajících řešení
27
• DELIVERY — způsoby a ceny dopravy, které je možné použít pro dodání daného produktu • ITEMGROUP_ID — označení variant, stejné ID v tomto atributu značí varianty stejného produktu • ACCESSORY — příslušenství k danému produktu (Miton Media, a.s., 2000–2012) Feed tedy obsahuje obvyklé položky (název, popis, obrázek, . . .) a také některé atributy specifické přímo pro Heureku. Je zde ovšem patrné, že v počátečním návrhu nebylo počítáno s více obrázky u jednoho produktu. Kvůli zpětné kompatibilitě se starými formáty feedu tedy byl přidán nepovinný element IM” GURL_ALTERNATIVE“. Feed pro zbozi.cz je v podstatě obdobný jako u Heureky. Nemá specifické atributy pro Heureku, ale má své vlastní. Jedná se o: • SHOP_DEPOTS — identifikátor poboček, u kterých je produkt skladem • TOLLFREE — slouží pro identifikaci produktů, které nebudou upřednostňovány na placené službě vyhledávání. • FIRMY_CZ — umožňuje specifikovat 5 položek, které se budou zobrazovat při vyhledávání dané společnosti na www.firmy.cz (Seznam.cz , a.s., 1996–2012) Varianty jsou u feedu pro Zbozi.cz řešeny jako samostatný element u daného produktu. Element v sobě může obsahovat všechny prvky jako základní element pro zápis produktu. Atributy variant, které nejsou u rodiče uvedené, se poté dědí přímo z rodičovského elementu a není je tedy třeba opakovat u každé varianty. Toto dědění zajišťuje snížení velikosti dat tím, že rodičovský produkt vlastně slouží jako šablona a varianty v sobě udávají pouze ta data, která mají od rodičovského produktu odlišná. Feed pro Google nákupy obsahuje většinu atributů jako předcházející feedy. Má ovšem několik podmínek závislých na typu produktu a státu, ve kterém je daný produkt prodáván. Například u produktů z kategorie oblečení je možné navolit jejich velikost, barvu, věkovou skupinu a pohlaví, pro které je oblečení určeno. Tyto parametry jsou ovšem udávány stejně jako u feedu od Lauratrade.cz a jejich rozšiřování by tedy zasahovalo do schémat tohoto XML. Podrobný popis formátu XML souboru, který je třeba pro Google Nákupy využívat je na URL . 5.1.4
Money S3 — popis formátu importu a exportu
Jak již bylo uvedeno, schémata pro automatizaci práce s daty pomocí importu a exportu v tomto systému jsou dostupné v podadresáři daného programu. Tato schémata a možnosti importu a exportu produktu jsou ovšem mnohem obsáhlejší než
5.1
Zhodnocení a poznatky ze stávajících řešení
28
u doposud zmiňovaných formátů. Jelikož je to účetní systém, eviduje o produktech více dat, než s kterými pracovaly předcházející systémy.
Obrázek 3: Ukázka ze schématu Money S3 Uvádění všech možností formátu systému Money S3 pro export produktů není pro tuto práci nezbytné. Většina základních atributů produktů, které se dají exportovat či importovat, byla již uvedena u předcházejících formátů. Ze zmíněného formátu lze ovšem získat několik poznatků, ohledně údajů, které jsou pro podobné systémy důležité. V tomto formátu je jasně vidět, že u každého produktu je možné evidovat více cen pro různé účely. Tento formát je omezen možnostmi Money S3 a limit prodejních cen je tedy 5. Výsledný formát by tedy jistě měl umožňovat minimálně 5 cenových skupin, nejlépe však aby toto množstevní omezení zde vůbec nebylo. Dále je zde u každého produktu v exportu návaznost na sklad, na kterém se nachází. Spolu s kódem produktu poté slouží jako unikátní identifikátor produktu,
5.1
Zhodnocení a poznatky ze stávajících řešení
29
který je používán k rozpoznávání produktů při importu do tohoto systému. Ve vytvářeném formátu by tedy měla být možnost evidovat údaje o více skladech, nejen o jednom. Formát XML dokumentů definovaný pro tento systém má ovšem značné nedostatky, které brání jeho jednoduchému použití v dalších systémech. Názvy elementů v schématech jsou česky, což pro univerzální formát dobré není. Navíc je u některých elementů patrné, že nejsou tvořeny ideálním způsobem. Způsob je volen zejména z důvodu zpětné kompatibility starších verzí. Jelikož původní návrh na takovéto rozšíření nebyl stavěn, vznikají pak problémy a krkolomné reprezentace dat. Příkladem je identifikace pozice v definované stromové struktuře, do které jsou produkty řazeny. Příklad: <Skupina> BINBrusle inlineBOTYSB Zde je patrné, že zanoření kategorie není prezentováno ideálně. Proměnlivý počet elementů může být při tvorbě algoritmu zpracovávajícího toto XML velice problematický a to hlavně z důvodu různých názvů těchto elementů. Kdyby existoval v době vývoje této XML komunikace nějaký univerzální formát, který by byl použit, nemuselo k těmto problémům dojít a reprezentace dat by byla mnohem přehlednější a snadněji implementovatelná. Štítky produktů jsou reprezentovány přímo patřičnými elementy a není je tedy možné přidávat bez úprav schématu. Objevuje se zde pojem Kmenová karta“, která reprezentuje každý produkt ” evidovaný v systému. Element kmKarta“ (kmenová karta) je ovšem pouze jednou ” z mnoha atributů, které systém v importovaném / exportovaném XML přiděluje produktům. Kmenová karta (nebo její identifikátor) totiž neslouží jako jediný unikátní identifikátor produktu v systému. Je k němu třeba i identifikátor skladu, na kterém je položka evidována. 5.1.5
Pohoda — popis formátu importu a exportu
Export z Programu Pohoda obsahuje téměř stejné množství dat jako z programu Money S3. Není tedy možné využít všech daných vlastností, ale schéma pro validaci tohoto XML obsahuje detailnější popisy elementů pomocí komentářů. Díky nim je orientace v daném schématu jednodušší. Schéma pro práci je dostupné na URL
5.1
Zhodnocení a poznatky ze stávajících řešení
30
Obrázek 4: Ukázka ze schématu Pohody Způsob tvorby tohoto XSD je velice podařený, ovšem validované XML je specifické zvláště pro potřeby tohoto programu. Nelze jej tedy jednoduše aplikovat univerzálně. Další z důvodu nemožnosti všeobecné aplikace je návaznost na další XSD. Funkce importu a exportu dat do systému Pohoda jsou mnohem větší a netýkají se pouze produktů. Pro specifikaci jsou tedy využívána sdílená schémata. Mezi takto sdílená schémata patří například schéma pro základní datové typy (jednoduché a komplexní datové typy, které se opakují ve více schématech), filtry nebo obálky, ve kterých systém Pohoda daná data přijímá a do kterých balí odpovědi prováděné akce. Jelikož komentáře, které jsou v tomto XML obsaženy, velice pomáhají při automatizování akcí pomocí tohoto XML, bylo by velice vhodné je používat i ve výstupu této práce. V souborech se schématy je také dobře definována povinnost či nepovinnost elementů.
5.2
Vymezení nezbytných a druhotných dat
31
Samotná data o produktech, která systém Pohoda umožňuje pomocí importu a exportu spravovat, nejsou moc odlišná od již zmíněných. V tomto formátu se vyskytuje většina již zmíněných a několik specifických pro systém Pohoda. Je zde ovšem zcela odlišně řešena možnost správy ostatních parametrů, které volí uživatel. Nejsou předdefinovány, ale je zde možnost vytvoření více elementů parameter“, ke kterým ” je možnost volit i více hodnot. Množství datových typů, které tyto hodnoty parametrů mohou nabývat, je mnoho. Pro naše účely by měly bohatě postačovat základní datové typy. Na rozdíl od systému Money S3 se firma Stormware rozhodla vytvořit nový formát (2.0), který již nemusí být zpětně kompatibilní s předchozím. Tento nový formát má oddělná schémata odstraňuje problémy přechozí verze formátu. Vytvořením nové verze formátu se zabránilo krkolomným interpretacím dat, o jejichž evidenci se systém rozšířil. Systém ovšem stále podporuje práci s oběma formáty a údaj o verzi schématu, kterým jsou data předávána, je systému oznámen v obálce specifikované ve schématu data.xsd. Toto schéma je dostupné na URL .
5.2
Vymezení nezbytných a druhotných dat
Jak je ze vzorových XML, schémat či popisů patrné, části všech zmíněných formátů jsou stejné či velice podobné. Dále se u každého formátu objevují jisté odlišnosti dle potřeb daného systému. Většina těchto odlišností by se ovšem dala reprezentovat pomocí univerzálních atributů. Přehled základních atributů, které dokáží zpracovávat zmíněné systémy, jsou uvedeny v tabulkách 1 a 2 v příloze. Rozšiřující možnosti, které jsou specifické pro každý z formátů, je ve výsledném formátu zbytečné implementovat, jelikož tyto prvky se mohou dále rozšiřovat a měnit. Všechny položky, které jsou uvedené v tabulkách, musí výsledný formát obsahovat, aby byl použitelný. Jelikož ne všechny formáty vyžadují stejná data, bylo by vhodné mít většinu položek nepovinnou. Data, která jsou pouze ve formátu z daného systému, jsou pro universální formát nevhodná. Je ovšem třeba uvažovat i tato data a dovolit ve formátu tato data nějakým způsobem reprezentovat. Atributy produktů, které jsou specifické pro každý z formátů, jsou z velké části převoditelné do rozšiřujících parametrů každého produktu. Je tedy třeba navrhnout možnosti parametrů tak, aby pojmuly nejen předvolené parametry ze zmíněných formátů, ale i z těchto specifických atributů.
5.3
Možné hodnoty pro přenášená data
V rámci univerzálnosti je většinou vhodné nedávat restrikce ohledně datových typů a délek datových elementů. Je ovšem jasné, že některá data ze zřejmých důvodů nebudou moci nabývat jiných hodnot. Názvy a popisy entit se mohou průběhem času prodlužovat a zde tedy restrikce nejsou vhodné.
5.4
Rozčlenění dat
32
Ovšem co se jedná časových údajů, je vhodné pro přenositelnost mezi systémy určit si jednotný formát pro tento druh dat. XML má ve svých specifikacích datové typy přímo k tomuto určené a není důvod je nedodržovat. Dalším příkladem dat, která jistě budou vždy nabývat pouze určitých hodnot, jsou ceny, množství a pořadí. Tyto atributy budou zcela jistě číselného typu, ovšem není jisté, zda celočíselného. Množství může být například udáváno v kilogramech a ty se již nemusí řadit mezi celočíselné hodnoty. Pořadí by sice mělo být celočíselného typu, ovšem tento předpoklad není možné dokázat u všech potenciálních systémů, pro které může být výsledný formát zajímavý. Ostatní data, která nebyla zmíněna, mohou v podstatě nabývat libovolných alfanumerických hodnot. Identifikátor se sice může zdát, že bude čistě numerický. V případě Pohody a Money S3 se ovšem k identifikaci produktů využívá kód, který zadává uživatel. Uživatel tedy může zadat libovolnou alfanumerickou hodnotu.
5.4
Rozčlenění dat
Data, která prozatím byla vybrána jako základní pro výsledný formát (viz příloha tabulka 1 a 2), se řadí do dvou skupin: • Identifikující a popisující produkt — data, která zcela jistě budou neměnná i v případech, že bude třeba z nějakého důvodu produkt uvádět vícekrát. Pokud bychom vzali v potaz i časový vývoj firmy a změny, které v systému provádí, byly by změny v těchto datech prováděny pouze administrátory daných systémů. • Aktuální konfigurace produktu — tedy data, která určují dostupnost, skladové zásoby, ceny, . . . Tato data mohou být obsluhována automaticky systémem v závislosti na událostech, které systémy obsluhují. Tato data se také mění podstatně častěji než předešlý druh a bylo by tedy vhodné je od sebe oddělit. U většiny dat z obou zmíněných skupin by bylo vhodné umožnit více položek od stejného druhu dat z důvodu možného rozšiřování systému. Výjimky: • Adresa — pokud uvažujeme adresu v použití E-commerce jsou obvyklé maximálně 3 druhy adres. Osobní, firemní (fakturační) a dodací. • Výrobce — Je zřejmé, že jeden výrobek má vždy jednoho výrobce.
5.5 5.5.1
Specifikace vlastního formátu Výběr formátu souboru
Jelikož výsledná data nemají mít v mnoha ohledech omezení počtu daných atributů produktů, je formát CSV zcela nedostačující. Potřeby zpracovávaných dat přesahují možnosti tohoto formátu. Vytvoření tabulky, kdy by jeden řádek obsahoval údaje o jednom produktu, by vyžadovalo definování velkého množství názvů sloupců. Navíc
5.5
Specifikace vlastního formátu
33
povolit neomezené množství například štítků by ani nebylo možné bez uvažování prefixů při parsování názvů sloupců. Název sloupce by se tedy ve většině případů skládal z více částí. V některých případech by již tyto části názvu sloupce obsahovaly přímo data, která by se u produktů evidovala. Zmíněný binární formát, který by obsahoval například objekty s daty o produktech, by bylo možné použít. S binárním formátem, který by byl přenosný mezi různými systémy, by se ovšem pojil problém ukládání a parsování takto uchovávaných dat. Vývoj aplikace nebo programového modulu by tedy byl podstatně složitější a časově náročnější. Takto uchovávaná data navíc nemusí být pro člověka čitelná a proto by ladění, či správa těchto souborů byla podstatně složitější. Nejlepší formát pro požadované výstupy této práce je zcela jistě XML. Je podporovaný mnoha systémy, programovacími jazyky a nástroji k těmto programovacím jazykům. Již ze zmíněného vzorku systémů a jejich formátů je zřejmé, že formát XML bývá pro tuto práci nejpoužívanější. Navíc jsou k tomuto formátu definované a uznávané způsoby tvorby schémat (XSD) a dále je k tomuto formátu i definován formát, pro transformaci dat do jiného výstuput (XSLT). 5.5.2
Základní identifikátory entit
Základním požadavkem pro automatizaci přenosů je možnost strojového rozlišení entit a při aktualizaci možnost spárování těchto entit za účelem aktualizace stejných prvků. Jak již bylo napsáno — identifikátor nemusí být vždy pouze numerický a je proto využít datového typu string pro identifikaci stejných prvků. Identifikátor nemusí být udáván pouze jeden. Identifikátory jsou různého druhu z různých systémů a norem. Například EAN či ISBN jsou identifikátory, které také slouží pro rozlišení položek. Je tedy logické mít tyto identifikátory u sebe a to jako vnořené elementy jednoho elementu codes“. ” Každý kód je definován třemi parametry. • system — Název systému, ve kterém je entita vedena pod daným identifikátorem. • type — Typ systému nebo název společnosti užívající daný identifikátor. Příkladem může být kód od dodavatele či ISBN u knížek. • unique — Určuje, zda je identifikátor unikátní a lze jej tedy použít pro strojové rozlišování. Například EAN kód nemusí být pro daný soubor unikátní. Dalším požadavkem je v systémech evidovat jména a popisy pro možnost spravovat dané entity lidmi. Stejně jako u výše uvedených kódů je možné mít více způsobů těchto názvů a popisů a proto jsou všechny tyto popisy hromadně v jednom elementu names“. Rozlišení těchto popisů je možné za pomoci atributů type“ ” ” a system“. Type určuje o jaký druh popisu se jedná a má volby: ” • short — krátký název,
5.5
Specifikace vlastního formátu
34
• pure — vlastní název, • long — dlouhý název, • shortDescription — krátký popis, • description — vlastní popis, • longDescription — podrobný popis, • orderName — název v objednávce, • other — jiný název nebo popis produktu nevyhovující výše zmíněným. Další možností odlišení je využití parametru system“, kterým by bylo možné ” určit systém, pro který daný název platí. Pokud je mezi dvěma subjekty nějaký druh domluvy a výsledný XML by byl využíván pro více účelů, může být tímto odlišeno, pro který ze subjektů je název určen. Z důvodu variability formátu pro různá využití je nutné zavést systém parametrů, do kterých by bylo možné vepsat všechny atributy, které jsou specifické výhradně pro daný existující formát. Rozšiřující parametry jsou tedy všechny zařazeny v elementu parameters“, který je uváděn u různých entit pro doplnění dat, ” která tento nový formát neumožňuje. Každému parametru je možné pomocí atributu type“ definovat datový typ, ” jeho hodnot. Pro parametry jsou povoleny tyto datové typy: • bool — Logická hodnota. • float — Číselný údaj. • list — Číselník. Je tedy možné uvádět více hodnot, který parametr může nabývat. Všechny hodnoty jsou textového typu. • string — Textová hodnota. • userDefined — Jiný druh parametru. Parametr je jedna z entit, které je možné identifikovat pomocí zmíněných elementů codes“ a names“. Dále je možné u parametru evidovat jeho pořadí. Tato ” ” volba je zde pro případ odlišného zobrazení pořadí v systémech. Všechny hodnoty daného parametru jsou společně uváděny v elementu para” meterValues“. U těchto hodnot stačí pouze identifikátor entit codes“ a names“. ” ”
5.5
Specifikace vlastního formátu
35
Obrázek 5: Základní identifikátory entit
5.5.3
Formát XML
Jelikož se ve zkoumaných formátech objevila možnost exportu celého stromu produktů, je na základní úrovni třeba rozlišit, zda daný soubor obsahuje data o produktech či o stromové struktuře kategorií. Dodavatelé pro internetové obchody obvykle tento strom udávají tak, jak bylo u vzorového Lauratrade.cz, nebo jej dávají do odděleného souboru. Jelikož jsou tato data sice navázána na data o produktech, není nelogické je udávat v jednom souboru. Zde byl ovšem zvolen druhý způsob a to evidovat tato data v odlišných souborech. Ne všechny kategorie mají návaznost na produkty a zároveň v případech, že by systém zpracovával pouze určitá data, mohly by data o stromové struktuře kategorií být redundantní a zbytečně zvětšovat velikost přenášených dat. Základní element list“ tedy může obsahovat buď data o produktech, nebo o ka” tegoriích a jejich struktuře. Formát tedy umožňuje mimo reprezentace dat o produktech také možnost reprezentace dat určující stromovou strukturu kategorií, ve kterých se mohou produkty nacházet.
5.5
Specifikace vlastního formátu
36
Obrázek 6: Kompletní formát Dle specifikace formát umožňuje vložení buď stromu produktů za pomocí elementů category“, nebo data o produktech pomocí elementů product“. Kategorie ” ” jsou v podobném formátu jako bylo ukázáno v příkladu u Lauratrade.cz. Každá kategorie tedy může obsahovat následující elementy: • codes — Identifikátory kategorie. • parentCodes — Identifikátory nadřazené kategorie. • names — Názvy dané kategorie. • fullPath — Kompletní cesta k dané kategorii. Tato možnost je zde pro případ udávání kategorie pouze u produktu bez využití kompletního stromu produktů. • parameters — Rozšiřující parametry pro danou kategorii.
5.5
Specifikace vlastního formátu
37
Toto řešení by tedy mělo zajistit možnost exportu celého stromu i s případnými doplňujícími údaji, které by bylo případně vhodné u kategorií uvádět. Ve vzorových formátech sice byly pouze základní údaje o kategoriích, ovšem se současným trendem rozšiřování možností automatické aktualizace dat je vhodné počítat i s případnými rozšířeními. Položky uvedené u produktů jsou děleny tak, jak bylo zmíněno v kapitole 4.4 Rozčlenění dat. Data, která se nemění tak často, jsou uváděna v elementu header a zbylá data mají vlastní element v hlavním elementu produktu product“. Struktura ” elementu product tedy vypadá takto: • codes — Identifikátory produktu. • header — data identifikující a popisující produkt. • prices — Cenové skupiny či možné druhy cen, které je třeba u produktu evidovat. • deliveryInfo — Informace o datech či dobách dodání na sklad. Tento element by měl sloužit hlavně vyhledávačům zboží jako je Heureka.cz, Zbozi.cz, Google nákupy. • storages — Data o skladových zásobách daného produktu. • parameters — Rozšiřující parametry výrobku. • internalNote — Interní poznámka systému k danému produktu. Dále pak jsou zde data udávající identifikující a popisující produkt, která se nemění tak často. Tato data jsou umístěná v elementu header“ a mají následující ” strukturu: • names — Slovní popisy a názvy produktů. • type — Stav produktu. Je zde na výběr ze šesti možností - nový, použitý, poškozený, otevřený, služba, jiný. • categories — Identifikace kategorií, ve kterých je produkt zařazen. Datový typ, který položky tohoto elementu využívají, je shodný s datovým typem používaným pro reprezentaci stromu produktů. • units — Měrné jednotky, ve kterých je uváděno množství produktu. Pokud není zvoleno, produkt se eviduje standardně v kusech. • files — Soubory připojené k danému produktu. Může se jednat o obrázky, videa, texty, nebo jiné. Je zde také možnost zvolit uložení daného souboru. Na výběr je mezi lokální cestou, URL, nebo FTP. • tags — Štítky produktu jako například Novinka“, Tip“, . . . Většina zkouma” ” ných formátů měla štítky pevně dané názvem elementu. Zde je možné uvést více štítků bez tohoto omezení.
5.5
Specifikace vlastního formátu
38
• links — Identifikace produktů, které s daným produktem nějakým způsobem souvisí. Pomocí dat v tomto elementu lze reprezentovat produkty: – varianty, – příbuzné, – alternativní, – doplňkové, – komplementární, – dárkové (jsou jako dárek při koupi daného zboží) – parts (pokud je produkt složen z více částí a jedná se tedy o sadu), – sets (sady, kterých je produkt součástí), – jiné. • suppliers — Interní poznámka systému k danému produktu. • creator — Interní poznámka systému k danému produktu. Kódy, názvy a rozšiřující parametry již byly popsány, v dalších popisech tedy budou přeskočeny. Jak bylo popsáno u Money S3, je možné evidovat v systémech E-commerce více cenových relací u každého produktu. Element prices obsahuje možnosti cenových skupin. Každý potomek uvedený v tomto elementu udává jednu možnost ceny pro daný produkt. Každý takovýto element má parametr type s možností určit, zda se jedná o prodejní či nákupní cenu. Dále pak tento element v sobě obsahuje elementy pro určení daně, ceny, identifikace cenové skupiny a možné rozšiřující parametry. DeliveryInfo je element, který poskytuje možnost využití tohoto feedu pro vyhledávače zboží. Jeho potomci nejsou omezení počtem a každý z elementů reprezentuje dobu dodání. Každý z elementů má parametr type, který určuje hodnotu, jež tento element nese. Možnosti reprezentace jsou textová, relativní nebo absolutní. Většina účetních systému podporuje evidence zboží na více skladech. Zde je proto vytvořen element storages, jež uchovává data o skladech a množství produktů, které jsou na nich uskladněny. Každý z elementů je definován elementy určenými pro evidované množství, kódy, názvy, parametry a adresou daného skladu. V hlavičce produktu je jedním z elementů určující typ produktu. Jelikož zmiňované vyhledávače zboží umožňovaly možnost rozlišení bazarových produktů, je zde tento element, popisující skutečný stav produktu. Oproti vyhledávačům jsou možnosti tohoto elementu rozšířeny o produkty poškozené, otevřené a další možnosti. V e-shopech je možné místo produktů nabízet služby. Je tedy v tomto elementu i možnost reprezentace tohoto daného produktu jako služby. Zařazení do více kategorií je možné pomocí elementů udávaných v elementu categories. Obsah tohoto elementu již byl popisován pro možnost práci s kompletní
5.5
Specifikace vlastního formátu
39
stromovou strukturou produktu. V případě vyhledávačů produktů nebyla prozatím nutnost využívat kompletního stromu produktů, proto každý element reprezentující kategorii má možnost zadat pouze kompletní cestu ve stromu produktů v elementu fullPath. Element units obsahuje údaje o možných jednotkách, ve kterých se produkt může evidovat. Všechny zmíněné formáty měly možnost udávat u produktu obrázek. V některých případech jich bylo i více než jeden. U feedu pro Heureku bylo možné k produktu vložit i video. Tato data mohou být reprezentována elementy v rodičovském elementu files. Každý z těchto elementů by obsahoval data o umístění připojeného souboru. Je možné pomocí atributu category definovat o jaký typ souboru se jedná. Možnosti jsou obrázek, video, text a další. Dále je zde i atribut, který definuje způsob reprezentace cesty. Na výběr je mezi lokálním uložištěm, URL, FTP či jiné uložiště. Zda je produkt novinkou či tipem bylo u zmiňovaných formátů vždy reprezentováno přímo elementem s názvem daného štítku. Ve výsledném formátu je možné definovat libovolné štítky v elementu tags. Každý štítek může být identifikován různými jmény, kódy a rozšiřujícími parametry. Všechny zmíněné atributy produktu jsou ve schématu jako komplexní typ s několika možnostmi jejich úprav. Největší změnou oproti doposud zmiňovaným formátům je způsob vkládání návazností mezi produkty. Feedy pro Zbozi.cz a Heureka.cz podporovaly možnost variant produktů, Heureka.cz a Money S3 podporovaly Příslušenství k produktům a Pohoda podporovala možnosti alternativních a souvisejících produktů. Všechny tyto návaznosti jsou zde ve výsledném formátu řešeny pomocí elementu links“ se zvolením typu návaznosti. ” Toto propojování lze také v případě variant využít jako šablonovací systém, kdy by základní údaje o produktu byly všechny uvedeny v daném produktu a v elementu links byly jeho varianty pouze s daty, které jsou odlišné od rodičovského produktu. Při přenosu mezi interními systémy organizace může být i požadavek na přenos dat o dodavatelích a údaje o nich. K tomuto požadavku je zde element suppliers, jehož obsahem jsou elementy určující data a kontaktní údaje o dodavatelích. U každého dodavatele je možné evidovat údaje o identifikátoru daného dodavatele, názvu, adrese a případných doplňujících datech, která by byla reprezentována v parametrech. Stejná data je možné evidovat u výrobce produktu. Rozdílem od dodavatelů je pouze možnost jediného výrobce pro daný produkt. Element creator je tedy přímým potomkem elementu header s možností uvedení maximálně jedenkrát. Oba dva elementy, které reprezentují dodavatele či výrobce, obsahují stejně jako sklad element address“, ve kterém je udávána adresa daného subjektu. Jak již ” bylo zmíněno, v oblasti E-commerce jsou obvyklé 3 základní druhy adres. Osobní, fakturační či také firemní a dodací. U všech tří elementů, které využívají tohoto elementu address“ není nezbytně nutné v souvislosti s exportem produktů znát ” či uvádět všechny tyto adresy. Do výsledného formátu ovšem byly zahrnuty kvůli možnostem rozšíření do dalších, v této práci neuvažovaných, odvětvích E-commerce.
5.6
Doplňkové nástroje pro nový formát
40
Dle možností, které jsou u tohoto formátu popsané je zřejmé, že dovoluje zadávat všechna potřebná data, která byla vypsána a porovnávaná v tabulkách 1 a 2 příloh. Data jsou tímto formátem uspořádána dle jejich charakteru a ve většině případů je možné zadat libovolný počet atributů. Tyto možnosti byly dále rozšířeny pomocí základních identifikátorů entit a dalších možností, které se k produktům váží.
5.6
Doplňkové nástroje pro nový formát
Při vytváření datových vstupů a výstupů pro export či import je vždy nutné mít dobře navrhnutý a zdokumentovaný formát. Bez dokumentace či absence vzorových použití nemusí být výsledný formát sprváně pochopen, či v horším případě nemusí vůbec splňovat svůj učel a to umožňovat komunikaci s dalšími systémy. Při špatném pochopení účelu jednotlivých elementů u XML či sloupců v případě CSV mohou být jejich hodnoty implementovány nesprávným způsobem a zapříčiňovat tak chyby při zpracovávání dat. Pro účely dokumentace výsledného formátu byly vytvořeny některé nástroje, které mohou programátorům pomoci při implementaci.
5.6
Doplňkové nástroje pro nový formát
5.6.1
41
Schéma
Obrázek 7: http://www.sun–shop.cz/xml–schema/schema Přesné schéma pro validaci dokumentů je zcela jistě velice užitečné. V daném schématu je jasně vidět restrikce, které udržují jednotný formát takovýchto XML dokumentů. Při vývoji exportu slouží jako kontrola, zda výsledek odpovídá specifikaci. Při vývoji importu je nezbytný pro zjištění možných hodnot a struktur elementů, které se mohou v importovaném XML souboru vyskytnout.
5.6
Doplňkové nástroje pro nový formát
5.6.2
42
Schéma transformované do čitelnějšího tvaru
Obrázek 8: http://www.sun–shop.cz/xml–schema/transform Samotná schémata jsou vlastně obsáhlé XML soubory, ve kterých je orientace složitější a při vývoji automatizačních procesů je tak vývoj plný vyhledávání v dokumentu. Za tímto účelem bylo vytvořeno pomocí XSLT jednodušší prostředí, kde je pomocí obsahu a odkazů zajištěna jednodušší orientace v dokumentu. Využitá XSL šablona je volně dostupná šablona pro transformaci XSD dokumentu, která je dostupná z URL http://sourceforge.net/projects/xs3p/. Xs3p je XSL šablona, která umožňuje transformaci XSD schématu do XHTML dokumentu. Výsledný dokument je poté zobrazitelný například ve webovém prohlížeči a ulehčuje tak práci s XSD.
5.6
Doplňkové nástroje pro nový formát
5.6.3
43
Vzorový XML soubor
Obrázek 9: http://www.sun–shop.cz/xml–schema/vzor Orientace ve schématech není nezbytným požadavkem pro práci s XML dokumenty. Proto je vhodné mít nějaký vzor, který pomůže při implementaci daného formátu. I zkušeným programátorům může dobře vytvořený vzorový soubor velice urychlit tvorbu automatizačního procesu. Proto je zde vytvořen validní vzorový XML dokument, který obsahuje většinu možností, které formát povoluje.
5.6
Doplňkové nástroje pro nový formát
5.6.4
44
Online validátor
Obrázek 10: http://www.sun–shop.cz/xml–schema/ Při tvorbě automatizovaného přenosu dat je možné validovat dokument různými nástroji. Záleží na zvyklostech a zkušenostech programátora. Pro jednoduchost takové validace byla vytvořena online aplikace, která tuto validaci provede přímo v prostředí prohlížeče na internetu. Jediné, co je k validaci potřebné, je přenést obsah XML dokumentu, který je určen k validaci na server, a tam poté proběhne validační proces. Na výběr je ze tří variant zadávání dokumentu určeného k validaci. • URI — pokud je dokument dostupný z viditelného webu, je možné zadat jeho URI. Při validaci si tato aplikace daný dokument stáhne a podrobí validačnímu procesu. • Přímé zadání textu — Je zde možnost také přímého vložení zdrojových kódů XML dokumentu určeného k validaci. • Upload souboru — Poslední možností je nahrát soubor na server a poté jej podrobit validaci. Všechny tyto varianty jsou založeny na stejném principu, jediný jejich rozdíl spočívá ve způsobu, který si uživatel zvolí pro vložení validovaného XML dokumentu. Validované XML dokumenty nejsou na serveru uchovávány či nijak logovány. Na zmíněné adrese je také možné se dostat ke všem nástrojům, které mohou ulehčit práci s daným formátem.
5.7
5.7
Náročnost implementace
45
Náročnost implementace
Implementace tohoto nově vytvořeného formátu by neměla být náročnější, než implementace vlastního formátu. Jsou pouze určena pravidla, kde se data mají nacházet a jakým způsobem jsou realizována. Spíše je zde ulehčení v tom, že není třeba vymýšlet a definovat vlastní formát, který nemusí být ideální pro případná rozšíření. Co se týče zpracování dokumentů v tomto formátu, je zde jistá komplikace v možnostech více různých entit. Například více jmen, kódů, štítků, parametrů, . . . K jejich zpracování je tedy potřeba více cyklů, popřípadě přesněji specifikovaný Xpath výraz. Při důkladném vytvoření možností importu je však možné pomocí jediného formátu zpracovávat data z více systémů. Ne všechny systémy by využily vše, co daný formát nabízí. Výsledné XML dokumenty by se tedy mohly lišit v prezentaci dat dle dat, s kterými pracují. Základ by byl ovšem stále stejný a proto duplikováním algoritmů pro zpracování jednoho a provedení několika úprav je stále časově méně náročné, než vytvářet kompletně nové napojení, které má zcela odlišné názvy, strukturu a parametry. Není však vůbec nutné implementovat celé nové schéma. Pomocí XSLT lze vytvořit obousměrné transformace XML dokumentů, které by využívaly stávajících možností daných systémů. Tato varianta by se mohla zdát výhodnější z důvodu správy pouze jedné možnosti napojení. Záleží ovšem na schopnostech programátorů, kteří daný automatizovaný přenos dat vytvářejí a spravují.
5.8
Možné problémy
Jak již bylo řečeno, možnosti formátu mohou přesahovat možnosti systémů, které jej budou využívat. Většina systémů nemá možnosti a ani důvod pro uchovávání všech dat, které se ve formátu mohou vyskytovat. Je zde tedy problém, která data vybírat, jak je využívat a jakým způsobem navázat na data a strukturu v daném systému. Tento problém ovšem nastává při každé tvorbě automatizovaného přenosu dat a ani tento formát není výjimkou. Skutečným problémem se ovšem může zdát využití formátu pro uchovávání dat, která jsou specifická přímo pro daný systém. Například maximální cena prokliku u feedů, nebo způsob účtování skladových zásob u účetních programů Money S3 a Pohoda. V daných feedech je stačí reprezentovat jediným elementem. V tomto univerzálním by to šlo pouze přes parametry, nebo v případě ceny prokliku například speciálně zadávanou cenovou skupinou. Data by tak byla stále možné ve výsledném XML dokumentu ukládat, ovšem elementů potřebných k jejich implementaci by bylo více. Dalším problémem by mohly být různé datové typy a jejich délky pro různé systémy. Samotný formát se snaží umožnit využití co nejvíce možných variant, systémy by si tedy omezení datových typů musely hlídat samy dle svých požadavků.
5.9
Ekonomická stránka jednotného formátu v rámci společností
46
Největším problémem by ovšem byla neochota subjektů, které již funkci takovýchto automatických přenosů dat využívají, měnit jejich stávající zaběhlé řešení. Implementace dalšího formátu je přeci jen časově náročná a jsou to jisté náklady.
5.9
Ekonomická stránka jednotného formátu v rámci společností
Zavedení zmíněného univerzálního formátu by mělo za následek snížení výpočetních nároků u e-shopů, které generují feedy pro vyhledávače. Vygenerováním jediného feedu by byly obslouženy všechny služby, které by pomocí tohoto feedu fungovaly. Ze stejného či libovolně upraveného dokumentu by také mohly běžet velkoobchodní feedy pro jejich odběratele. Jednalo by se o zmíněné vyhledávače zboží Zbozi.cz, Heureka.cz, Google nákupy dále pak jyxo.cz, monitor.cz a další. Problémem by určitě byla neochota měnit zaběhlý formát, který systémy využívají. Mimo využití stejného formátu pro export produktů do více systémů je zde i výhoda při využívání importu z daného formátu. Jedinou aplikací, řešící import z daného formátu, by bylo možné obsluhovat více napojení a náklady na tvorbu nových napojení by se tak podstatně snížily. Samozřejmě prvotní investice do implementace by se nemusela okamžitě vrátit a nemusely by být jasně viditelné výsledky, ovšem výsledkem by bylo snížení nákladů na automatizaci přenosů. Další možností využití daného formátu je pro verzování dat o produktech. Pokud by se systém rozšiřoval o možnost správy revizí dat o produktech, byl by tento formát použitelnější, než správa verzí přímo v databázi. V databázi jsou data o produktech obvykle rozdělena do více tabulek a bylo by tedy třeba vytvářet zálohy každé z nich. Při využití tohoto formátu by se ovšem data uchovávala v textové podobě a všechna data o produktech by byla v jednom souboru. Na tento soubor by se dále mohla navázat aplikace pro správu revizí — tedy nějaký verzovací systém, který ukládá změny. Použitím verzovacího systému by se sice zvýšili nároky na výpočetní výkon, ovšem snížil by se objem uchovávaných dat. Pokud by ovšem byl problém s objemem uchovávaných dat bez použití verzovacího systému, mohly by se uchovávat pouze verze, které nejsou starší než například 20 dní s tím, že alespoň jedna či dvě předchozí revize by musely existovat i v případě, že jsou starší než zmíněných 20 dnů.
5.10
Transformace výsledného XML
Systém obvykle generuje několik druhů feedu. Příkladem jsou feedy pro vyhledávače. Obvykle se jedná o 5 druhů různě strukturovaných feedů: 1. Zbozi.cz 2. Heureka.cz 3. Google nákupy (Google.com/shopping)
5.10
Transformace výsledného XML
47
4. Monitor.cz 5. Jyxo.cz. Pro každý E-shop se tedy generuje těchto 5 feedů, navíc pokud provozovatelé E-shopu umožňují velkoobchodní prodej a nabízejí vlastní feed, pak se k těmto pěti přidává další. Nároky na zátěž serveru jsou tedy zbytečně vysoké a daly by se snížit používáním pouze jediného feedu, který by se poté pomocí XSLT transformoval na feedy pro zmíněné vyhledávače zboží. Navíc další rozšiřování počtu feedů by nutně neznamenalo zvýšení nároků na zátěž serveru pro generování dalšího feedu, ale byla by to pouze záležitost vytvoření XSLT. V závislosti na počtu produktů ve feedech a frekvenci jejich aktualizace by se tak snížily výpočetní nároky na servery a nemuselo by tak docházet ke špičkám, které mohou zpomalovat odpovědi od serveru v době přegenerovávání feedů.
6
6
DISKUZE
48
Diskuze
Ve vybraných vzorových systémech, které podporují možnosti automatizace obsluhy, byly předvedeny a vybrány základní požadavky na obsah dokumentů. Většina uvažovaných dat, které systémy spravují, byla implementována ve výsledném formátu a rozšířena o další možnosti. Všechna uvažovaná data byla roztříděna dle jejich charakteru a zařazena pod odpovídající element, který tato data uchovává. Pro obsluhu produktů v rámci E-commerce by tedy výsledný formát měl splňovat většinu požadavků. Pokud by se vyskytly rozšiřující informace, které formát přímo neobsahuje, je zde možnost využití parametrů jako univerzálního uložiště dat. Reprezentace dat je intuitivní a pro tvorbu a zpracování dokumentů dle výsledného schématu jsou přístupné dostačující nástroje. Tyto nástroj by měly ulehčit implementaci daného formátu do systémů, které se jej rozhodnou používat. Formát dat navíc napovídá mnohé ohledně toho, jaká data se mohou v návaznosti na produkt objevovat a jak mohou být reprezentována. Může tedy i sloužit jako inspirace pro vývoj univerzálních systémů spravující data o produktech či službách.
7
7
ZÁVĚR
49
Závěr
Tato práce se nezaobírá tématy, které by se dostaly do povědomí široké veřejnosti. V rámci specifikace různých norem a společných formátů ovšem může mít vliv na vývoj aplikací v oblasti E-commerce, které se zabývají správou dat o produktech či službách a jejich přenosem mezi různými druhy systémů za účelem automatizace lidských činností. Jak a kam budou v budoucnosti tyto systémy směřovat prozatím není možné přesně říci, ovšem při tvorbě výsledného formátu bylo uvažováno o možnostech rozšíření a případných dodatečných datech, která doposud u produktů není třeba uvádět. Požadavky firmy Sunlight Systems s.r.o. byly splněny a výsledný formát obsahuje vše, co bylo požadováno. Za pomoci XSLT bylo navrhnuto i vylepšení. Po zavedení výsledného formátu by mohl být takto vytvořený výstup za pomoci XSLT převáděn na již existující formáty a nebylo by tedy nutné provádět generování feedů pro každý formát zvlášť. Toto vylepšení nemusí být zajímavé pouze pro danou firmu. Mohlo by být použitelné i u jiných systémů z oblasti E-commerce, které využívají pravidelných aktualizací feedů. I další navrhovaný způsob využití výsledného formátu by mohl být aplikován v dalších systémech. Pro správu revizí dat o produktech také není určen žádný speciální formát. Použitelné jsou samozřejmě zálohy celé databáze, ovšem tato akce je výpočetně náročná stejně jako zpětná obnova databáze. Tyto zálohy navíc mohou zabírat velké množství paměti a udržování velkého množství takovýchto záloh by mohlo zvýšit cenu provozu serveru. Zda se formát ujme ovšem předpovědět nelze. Záleží hlavně na hojnosti jeho využití, dostupnosti schémat a nástrojů, které byly pro tento formát vytvořeny.
8
8
LITERATURA
50
Literatura
David Procházka CSS a XHTML; Tvorba dokonalých WWW stránek krok za krokem — 2 aktualizované vydání. Praha: Grada Publishing a.s., 2011. 175 s. ISBN 978-80-247-3897-0. Jiří Kosek PHP a XML 1. vydání. Praha: Grada Publishing a.s., 2009. 367 s. ISBN 9788024711164. Koon Hoek Goh E-Start Your Web Store with Zen Cart: A Hands-on Guide for Entrepreneurs Businesses 1. vydání. Cucumber Media Web Site, 2007. 390 s. ISBN 9789810565916. Zen Cart Wiki Media Zen Cart [online].Dokument ve formátu HTML. Dostupný z WWW: . Wiki Media Racional Invest s.r.o. — Dámské a pánské spodní prádlo [online].Dokument ve formátu HTML. Dostupný z WWW: . Cígler SOFTWARE Účetní program Money S3 [online].Dokument ve formátu HTML. Dostupný z WWW: . Stormware Software Development Účetní program Pohoda [online].Dokument ve formátu HTML. Dostupný z WWW: . RNDr. Irena Mlýnková Ph.D., Mgr Marin Nečaský, Prof. RNDr. Jaroslav Pokorný CSc., Doc. Ing. Karel Richta CSc, Mgr. Kamil Toman, Mgr. Vojtěch Toman XML technologie ; Principy a aplikace v praxi 1. vyd. Praha: Grada Publisking a.s., 2008. 267 s. ISBN 978-80-247-2725-7.. Miton Media, a.s.Služby obchodům; Heureka.cz [online].Dokument ve formátu HTML. Dostupný z WWW: . Seznam.cz , a.s.Specifikace XML pro internetové obchody; Seznam nápověda [online].Dokument ve formátu HTML. Dostupný z WWW: . Prof. RNDr Jaroslav Pokorný, CSc a kolektiv XML technologie ; Principy a aplikace v praxi 1. vyd. Praha: Grada Publisking a.s., 2008. 267 s. ISBN 978-80247-2725-7..
8
LITERATURA
51
Dino Esposito XML; efektivní programování pro .NET 1. vyd. Grada Publisking a.s., 2004. 594 s. ISBN 9788024707754.. Aaron Skonnard, Martin Gudgin XML — pohotová referenční příručka; Referenční příručka programátora ke XML, XPath, XSLT, XML Schema, SOAP a dalším 1. vyd. Grada Publisking a.s., 2006. 342 s. ISBN 9788024709727..
