Univerzita Karlova v Praze Matematicko-fyzikální fakulta
DIPLOMOVÁ PRÁCE
Michal Hampl Internetové obchody Katedra teoretické informatiky a matematické logiky
Vedoucí diplomové práce: doc. RNDr. Mirko Křivánek, CSc.
Studijní program: Informatika Studijní obor: ISS
Praha 2011
Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů, literatury a dalších odborných zdrojů. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona v platném znění, zejména skutečnost, že Univerzita Karlova v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne
Michal Hampl
Název práce: Internetové obchody Autor: Michal Hampl Katedra (ústav): Katedra teoretické informatiky a matematické logiky Vedoucí bakalářské práce: doc. RNDr. Mirko Křivánek, CSc. Abstrakt: Obsahem diplomové práce je zmapovat a vyhodnotit možnosti napojení existujících produktů internetových obchodů na externí systémy, zjistit, jaká jsou pozitiva a negativa existujících postupů a na základě získaných informací navrhnout model univerzálního propojení obecného internetového obchodu s obecným externím systémem. Hlavním cílem takového propojení je získat co nejobecnější princip tak, aby propojení na konkrétní externí systém bylo možné realizovat s co nejmenší námahou nikoliv však na úkor jeho obecnosti. Obsahem práce je také návrh implementace modelu a ověření jeho použitelnosti při implementaci propojení na několik existujících externích systémů. Na závěr pak bude vyhodnocení vhodnosti zvoleného modelu na základě zkušeností získaných při implementacích konkrétních propojení. Klíčová slova: internetový obchod, propojení
Title: E-commerce Author: Michal Hampl Department: Department of Theoretical Computer Science and Mathematical Logic Supervisor: doc. RNDr. Mirko Křivánek, CSc. Abstract: Aim of this work is to map and evaluate possibilities of interoperability of existing e-commerce systems with external systems, find out positives and negatives of existing solutions and on the basis of these information to propose a model of universal interoperability framework of general e-commerce product with general external system. Main goal of this framework is to get the most general solution such as it is possible to create connection to new external system with as less effort as possible but not against its generality. This work will also contain concept of implementation of designed model and verification of its usability while implementing connection to several existing external systems. At the end it will contain evaluation of proposed model in context of experience acquired while implementing sample connections. Keywords: e-commerce, interoperability
Obsah 1. Motivace a cíl práce ........................................................................................... 1 2. Existující řešení pro napojení externích systémů ............................................. 5 2.1. Propojení v některých existujících systémech ................................................ 5 Ekonomické systémy ...................................................................................... 6 Internetové obchody ....................................................................................... 6 2.2. Alternativní produkty určené k propojování................................................... 7 2.3. Taxonomie propojení systémů....................................................................... 8 Online vs. offline propojení ............................................................................ 8 Podle použité technologie ..............................................................................11 Podle iniciátora komunikace ..........................................................................14 Podle umístění kódu realizujícího propojení...................................................14 Přenos změn vs. kompletní přenos .................................................................15 3. Datový model a procesy internetových obchodů .............................................16 3.1. Objekty internetových obchodů....................................................................16 Katalog zboží.................................................................................................16 Cenotvorba ....................................................................................................17 Skladová dostupnost ......................................................................................17 Uživatelé internetového obchodu ...................................................................17 Doklady .........................................................................................................18 3.2. Procesy na internetových obchodech ............................................................18 4. Model univerzálního napojení na externí systém ............................................20 4.1. Požadavek univerzálnosti, obecnosti a rozšiřitelnosti....................................20 4.2. Základní principy fungování modelu ............................................................21 Základní struktura „Můstku“..........................................................................22 Překlady dat a sběrnice “translatorů”..............................................................23 Rozdělení na procesy .....................................................................................24 Obecná transformace .....................................................................................25 4.3. Fungování modelu konkrétně .......................................................................26 Interní datové struktury přenosového můstku.................................................26 Datový kontext běžícího procesu ...................................................................30
Parametry jednotlivých kroků / operací..........................................................32 Rozšíření XSLT o možnost obecných transformací........................................35 5. Návrh objektového modelu systému.................................................................38 5.1. Proces, krok procesu.....................................................................................38 5.2. Sběrnice a operace........................................................................................41 Read/Write Operation ....................................................................................43 Rozšíření XSLT a Transform Operation.........................................................45 6. Několik příkladů implementace operací ..........................................................47 6.1. Propojení na databázi - SqlReadWriteOperation ...........................................47 Příklad: Načtení zboží aktualizovaného od posledního spuštění procesu ........49 6.2. Propojení pomocí web služby - WSReadWriteOperation..............................50 Příklad: Vložení nových objednávek z internetového obchodu do IS..............52 6.3. Propojení pomocí MSMQ - MSMQReadWriteOperation .............................53 7. Komplexnější příklady propojení....................................................................55 7.1. Struktura DB ukázkového internetového obchodu ........................................56 7.2. Procesy implementované v ukázkovém napojení ..........................................57 7.3. Ukázka propojení – Altus Vario ...................................................................57 7.4. Ukázka propojení – Microsoft Dynamics Navision.......................................63 7.5. Ukázka propojení – HP Tronic .....................................................................66 8. Závěr - zhodnocení dosažených cílů .................................................................68 8.1. Univerzálnost, obecnost a rozšiřitelnost........................................................68 8.2. Praktická využitelnost definovaného modelu ................................................69 8.3. Nevýhody a možné rozšíření systému...........................................................70 Použitá literatura ..................................................................................................72
1. Motivace a cíl práce Nakupování v posledních letech zažívá revoluci a z velké části se přesunuje na Internet. Každým měsícem je víc a víc uskutečněných obchodů realizováno elektronicky a to nejen v oblasti známé všem (tedy při maloobchodním nakupování koncových zákazníků – tzv. B2C), ale hlavně v oblasti mezifiremního obchodování (tzv. B2B). Zatímco pro koncového zákazníka nakupování na Internetu neznamená žádnou zátěž navíc (ale spíše naopak), jinak je tomu z pohledu obchodníků. Mít vlastní internetový obchod je v dnešní době z pohledu obchodníka moderní, možná dokonce spíš nutnost pro to, aby si udržel krok se svou konkurencí. Zřídit si vlastní internetový obchod není ani nikterak složité nebo finančně náročné. Na trhu existuje spousta levných krabicových produktů, pomocí kterých je možné zřídit internetových obchod velmi snadno a zvládne to tak i běžný uživatel počítače. Zřízením internetového obchodu a jeho publikováním na Internetu ale elektronické obchodování pro obchodníka nekončí (jak se spousta z nich mylně domnívá), ale teprve začíná. V opačném případě by internetový obchod velmi rychle upadl v zapomnění, pokud by si jej tedy vůbec někdo všiml. Pokud to obchodník s internetovým obchodováním myslí opravdu vážné, začíná pro něj nikdy nekončící proces udržování internetového obchodu aktuálním, jeho propagace, rozvoj a hlavně starání se o komfort svých zákazníků. Právě udržování aktuálních dat na internetovém obchodu je stěžejní - zákazník potřebuje mít přehled o aktuálních cenách a skladovém množství jednotlivých druhů zboží a rovněž předpokládá, že mu bude nabízeno pouze zboží aktuální. Zajištění aktuálnosti dat je na druhou stranu potenciálně časově náročně – aktualizovat průběžně stovky až tisíce cen u jednotlivých druhů zboží a rovněž jeho skladovou dostupnost je velmi pracné a navíc náchylné k chybám. Každá chyba pak snižuje důvěryhodnost internetového obchodu, kterou musí každý obchodník pracně u potenciálních zákazníků získávat. Faktem je, že v dnešní elektronické době téměř každý obchodník již potřebné data v elektronické podobě má. Ty má uložené v různých ekonomických nebo účetních systémech, kde je eviduje pro výstupy požadované zákonem a státními úřady. Bylo by tedy logické, kdyby obchodník nemusel stejná data pořizovat znovu duplicitně pro potřeby internetového obchodu a kdyby bylo nějakým způsobem zajištěno sdílení těchto dat mezi již existujícím ekonomickým systémem a mezi internetovým obchodem. Vzhledem k tomu, že ekonomický nebo účetní systém již obchodník používá před zřízením internetového obchodu a má pomocí něj pořízeny všechny data o svém obchodování, předpokládejme tedy, že primárním úložištěm dat bude právě tento z hlediska internetového obchodu externí systém a internetový obchod tyto data bude z externího systému přebírat a samozřejmě je bude také doplňovat.
1
Podpora komunikace a sdílení dat mezi internetovým obchodem a externími systémy je jeden z pokročilých aspektů, kterým se odlišuje jednoduchý internetový obchod od toho profesionálního. Tvůrci internetových obchodů, kteří se problematikou obchodování po Internetu zabývají, jsou si vědomi potřeb provozovatele internetového obchodu mít publikovaná aktuální data s co nejmenší námahou pro zajištění této aktuálnosti. Profesionální internetové obchody tak vždy nabízejí nějaký způsob interoperability a propojení internetového obchodu s externími systémy. Externích systémů je ale mnoho a mají navíc velmi rozdílné datové modely a různé možnosti komunikace s jinými systémy. Navíc často obsahují také možnost upravení pro potřebu konkrétního obchodníka tak, aby mohl zachytit pro něj specifická data a procesy, kterými se řídí. Je tedy nemožné vytvořit systém propojení internetového obchodu tak, aby fungoval bez zásahu se všemi existujícími ekonomickými a účetními systémy. Součástí implementace internetového obchodu tedy musí být rovněž i implementace celého propojovacího můstku nebo jeho části s externím systémem nebo upravení existujícího propojovacího můstku pro potřeby konkrétního obchodníka. Kvůli neexistenci nějakého obecného frameworku tohoto propojení je tak často nutné psát velké množství kódu specifického pouze a jen pro daného obchodníka, což ve výsledku zvyšuje celkovou cenu jeho internetového obchodu. Obsahem diplomové práce je zmapovat a vyhodnotit možnosti napojení existujících produktů internetových obchodů na externí systémy, zjistit, jaká jsou pozitiva a negativa existujících postupů a na základě získaných informací navrhnout model univerzálního propojení obecného internetového obchodu s obecným externím systémem. Hlavním cílem takového propojení je získat co nejobecnější princip tak, aby propojení na konkrétní externí systém bylo možné realizovat s co nejmenší námahou nikoliv však na úkor jeho obecnosti. Obsahem práce je také návrh implementace modelu a ověření jeho použitelnosti při implementaci propojení na několik existujících externích systému. Na závěr pak zhodnocení vhodnosti zvoleného modelu na základě zkušeností získaných při implementacích konkrétních propojení. A jaká data vlastně mezi internetovým obchodem a externím systémem standardně proudí, respektive by bylo potřeba, aby proudily? V první řadě je potřeba internetový obchod nějakým způsobem naplnit. K orientaci na eshopu slouží nějaký hierarchický produktový strom (případně několik stromů při různých alternativních členěních – například pro členění dle výrobce). V další fázi je potřeba na internetový obchod přenést samotnou nabídku prodávaného zboží. Na zboží se váže cenotvorba, která může být v různých internetových obchodech značně rozdílná. Konkrétně internetové obchody typu B2B mohou mít velmi rozmanitou cenotvorbu, kdy někteří zákazníci mají dohodnuté speciální cenové tarify pro určité skupiny zboží případně jednotlivé výrobky. S katalogem 2
zboží souvisí také velmi důležitá evidence skladové dostupnosti. Ke konkrétním záznamům o zboží může být ale vázána rozmanitá evidence dalších informací. Další skupinou přenášených objektů úzce svázaných s každým internetovým obchodem je jeho uživatelská základna. U různých implementací různých internetových obchodů může být související evidence opět značně individuální. Mimo jiné se může na evidenci zákazníků vázat například evidence komunikace s daným zákazníkem, seznam doručovacích míst, platební historie a podobně. Poslední významnou skupinou objektů, které je potřeba vyměňovat mezi informačním systémem a internetovým obchodem jsou objekty, které je možné souhrnně nazvat jako doklady. Pod tímto si můžeme představit hlavně objednávku zboží vloženou konkrétním zákazníkem (obsahující hlavičku a seznam řádků). Dále pak například faktury, dodací listy, reklamace. Výčet obsažený v několika předchozích odstavcích samozřejmě není úplný. Jedním z cílů navrhnutého řešení je jeho obecnost. To znamená, že navrhnutý princip by měl být použitelný nejen v definovaných standardních situacích při přenosu standardních objektů, ale mělo by jej být možné aplikovat i v nestandardních případech, kdy je mezi internetovým obchodem a externím systémem potřeba vyměňovat specifické objekty aplikovatelné pouze v daném případě. Na tomto místě by bylo vhodné definovat cíle a požadavky na představený a implementovaný model a postup vedoucí k jejich dosažení. Hlavním cílem diplomové práce je definovat a implementovat framework sloužící k propojení obecného internetového obchodu s obecným externím systémem. Dílčím cílem pak s použitím tohoto frameworku implementovat napojení na několik existujících ekonomických a účetních systémů tak, aby se ověřila použitelnost definovaného frameworku v praxi. Na definovaný framework klademe samozřejmě určité požadavky: Framework by měl být použitelný s libovolným internetovým obchodem Framework by měl být použitelný s libovolným externím systémem Měl by obsahovat co možná nejvíce funkcionality související s propojením tak, aby bylo možné zbývající části specifické pro daný internetový obchod a externí systém vytvořit s co nejmenší námahu Framework by měl být dostatečně strukturovaný tak, aby bylo možné ovlivnit způsob jeho chování Diplomová práce je strukturovaná do několika částí odpovídající postupu při návrhu, implementaci a testování frameworku. V první části bude provedena analýza existujících řešení pro napojení externích systémů a zhodnocení jejich pozitiv a negativ. V následující části bude pak určen obecný datový model a procesy
3
v obecném internetovém obchodě tak, aby bylo možné definovat množinu přenášených objektů. V další části pak bude představen model napojení na externí systém spolu s popisem implementace a detailním popisem hlavních myšlenek tohoto modelu. Následovat bude příklad využití tohoto modelu a frameworku v praxi při napojení na některé existující externí systémy. Na závěr pak bude zhodnocen přínos tohoto modelu a vyhodnoceno, zda splňuje cíle, které byly stanoveny výše.
4
2. Existující řešení pro napojení externích systémů Jak bylo předesláno v předchozí kapitole, propojování internetových obchodů s externími systémy je z důvodu nutnosti automatizace mnoha procesů u profesionálních produktů nutností. Proto již v tuto chvíli samozřejmě existují metody (architektury, protokoly, standardy, formáty, …), pomocí nichž je možné toto realizovat. S ohledem na provedený průzkum a zkušeností z praxe není možné ale říci, že by pro řešení tohoto problému existoval nějaký globální a uznávaný standard. Toto plyne na jedné straně z faktu, že na trhu existuje obrovská řada různých produktů, a to jak na straně internetového obchodu tak pravděpodobně ještě více různých produktů na straně ekonomických a jiných systémů. Dle mého názoru funkce propojení systému s jiným systémem pak u většiny těchto systémů není vnímána jako jedna z core (hlavních) funkcí, ale leží více k okraji architektury systému hrající spíše roli funkce podpůrné. U spousty systémů pak plnohodnotná možnost jejich propojování úplně chybí a tyto systémy pak v tom (o něco) lepším případě obsahují alespoň možnost exportu a importu dat do nějakého rozumného standardního formátu. Toto se týká hlavně menších, levnějších systémů s omezeným lokálním významem na trhu. Tuto skutečnost není možné chápat nutně jako chybu autorů systému, ale v mnoha případech jako záměr. Pokud je produktem malý a levný krabicový systém, nemůžeme očekávat, že bude mít stejné funkce a možnosti jako rozsáhlý a drahý produkt. Na druhou stranu tato skutečnost může znamenat nevhodnost takového systému pro společnosti poptávající nebo provozující internetový obchod. U další skupiny systému pak nebyla funkci propojování od začátku věnována potřebná pozornost, případně byla tato funkce doplňována později. To může ve výsledku znamenat špatnou integraci takové funkce s ostatními částmi systému. Vzhledem k tomu, že dnešní doba je dobou integrace, propojování a komunikace, můžeme tedy autorům nových systémů obou typů (internetových obchodů i ekonomických systémů) dát jako doporučení, věnovat možnosti propojit jejich systém s jiným systémem dostatečnou pozornost. Tato funkce pak bude ve výsledku nemalou výhodou v porovnání s konkurenčními produkty.
2.1. Propojení v některých existujících systémech Tato část obsahuje příklad několika existujících systémů a zachycuje jejich možnosti propojování resp. existující metody propojení těchto systému s externími systémy. V následující části je pak představena komplexní taxonomie propojení.
5
Ekonomické systémy Microsoft Dynamics Navision (http://www.microsoft.com/cze/dynamics/navision/default.mspx) Tento produkt od společnosti Microsoft plnící funkci ekonomického systému používá jako datové úložiště Microsoft SQL server. K datům systému je tedy možné přistupovat přímým přístupem do databáze Navisionu případně prostřednictvím oddělené databáze, která plní funkci střední vrstvy. Nevýhodou takového řešení je obejití aplikačního serveru Navisionu, který mimo jiné automaticky udržuje integritu vstupních dat a aplikuje definovanou business logiku. Z tohoto hlediska je lepším řešením využít funkci aplikačního serveru Navision, který podporuje komunikaci prostřednictvím technologie Microsoft Message Queues. Karat Software (http://www.karatsoftware.cz/) V jádře systém bohužel neobsahuje přímou podporu interoperability s jinými systémy. V rámci dodatečných modulů ale existuje možnost propojení na bázi výměny informací přes databázi. Altus Vario (http://www.vario.cz/) Ani jádro tohoto systému nenabízí možnosti propojení s dalšími systémy. K datům je tedy možné přistupovat přímým přístupem do databáze produktu nebo pomocí speciální databáze plnící funkci střední vrstvy. Existují partnerská řešení, která poskytují možnost komunikovat prostřednictvím webových služeb. Stormware Pohoda (http://www.stormware.cz/) Tento produkt je nabízený v několika variantách dle způsobu uložení dat (souborová či SQL databáze). V případě využití SQL verze systému je možné přistupovat k datům napřímo. Kromě toho umí systém automatizovaně exportovat a importovat data pomocí speciálně strukturovaných XML dokumentů.
Internetové obchody Altos eShop (http://www.altos.cz/) Systém neobsahuje žádný obecný modul pro komunikaci s libovolným ekonomickým systémem. Implementace propojení se řeší individuálně pro jednotlivé ekonomické systémy – systém Altos eShop je variabilní a upravitelný na míru konkrétní potřebě, což v praxi znamená široké možnosti 6
propojení dle potřeb konkrétního zákazníka, maximálně optimalizovaných na míru pro daný ekonomický systém. Pro export dat do jiných systémů nabízí Altos eShop v základní verzi sadu XML feedů dostupných přes definovanou webovou adresu. NetDirect ShopCentrik (http://www.shopcentrik.cz/) Propojení s externími systémy má na starosti blíže nespecifikovaná speciální aplikace instalovaná u zákazníka (provozovatele), která umožňuje řešit pokročilé funkce v rámci propojení (mimo jiné např. změnové přenosy). Dle informací na webu výrobce využívá tato speciální aplikace technologie Microsoft SQL, Microsoft BizTalk a XML. osCommerce (http://www.oscommerce.com/) Tento open sourcový internetový obchod umožňuje tvorbu tzv. add-onů, pomocí kterých je možné rozšiřovat funkčnost samotného produktu. Na internetu je k dispozici nabídka různých hotových řešení pro konkrétní ekonomické systémy
2.2. Alternativní produkty určené k propojování Model definovaný touto prací není první ani jediný existující systém určený k obecnému propojování různých systémů, i když uplatňuje k této problematice trochu jiný přístup. Na rozdíl od produktů zmíněných v této části nefunguje navrhnutý a popsaný model jako server čekající na impuls ve formě příchozí datové zprávy na vstupu, kterou nějakým způsobem transformuje a odešle dál. Naopak model představený v této práci funguje autonomně tak, že v pravidelných intervalech spouští definované procesy, které sami o sobě provedou veškerou nutnou komunikaci od fáze získávání dat z jednoho či více systémů, přes fázi transformace těchto dat až konečně k fázi odeslání a uložení dat do cílového systému nebo systémů. Tento přístup umožňuje implementovat automatizovanou komunikaci mezi různými systémy bez nutnosti tyto systémy upravovat a napojovat na systém zajišťující výměnu dat, což by v praxi znamenalo dodatečné náklady. Praktické použitelnosti níže zmíněných produktů v některých případech brání i jejich značná komplexnost / komplikovanost a licenční podmínky, kdy tyto systémy tím pádem nejsou vhodné v kontextu propojování internetových obchodů různých velikostí (včetně těch menších) s externími systémy (rovněž různé cenové hladiny). -
Microsoft BizTalk Server – velmi komplexní a bohužel i finančně náročný produkt od společnosti Microsoft, který je možné prostřednictvím adapterů napojit na rozličné systémy a umožnit mezi nimi výměnu zpráv včetně transformace, spojování, rozdělování atd..
7
-
Windows Communication Foundation – API rozhraní, které je součástí .NET Frameworku a které umožňuje implementovat propojené, distribuované, servisně orientované aplikace.
-
IBM WebSphere – další z komplexní produktů (resp. rodina produktů) určených k integraci různých business aplikací.
2.3. Taxonomie propojení systémů Způsoby a principy propojení systémů (například internetového obchodu a ekonomického systému) je možné rozdělit primárně podle následujících několika kritérií:
Online vs. offline propojení Podle použité technologie Podle iniciátora komunikace Podle umístění kódu realizujícího propojení Přenos změn vs. kompletní přenos
Online vs. offline propojení Jako online propojení rozumějme takové, kdy jeden ze systémů pracuje přímo nad daty systému druhého. Offline propojení naopak znamená, že oba systémy mají k dispozici kopii sdílených (přenášených) dat s tím, že data navzájem synchronizují na základě určité události – nejčastěji při spuštění nějakého časovače v pravidelných intervalech nebo v určitý definovaný čas. K těmto dvěma hlavním možnostem můžeme ještě přidat pseudo-online propojení. Takové propojení pak bude ve skutečnosti offline, ale synchronizace dat proběhne okamžitě (resp. téměř okamžitě) po vzniku těchto dat nebo jejich aktualizaci. Oba systémy pak budou mít ve skutečnosti lokální kopii dat, ale synchronizace změn na těchto datech bude prováděna téměř okamžitě. Pro uživatele to tedy bude vypadat jako by byly oba systémy propojené online. Jako poslední možnost definujme kombinaci výše zmíněných (Online + offline + pseudo-online), kdy některé datové objekty daného systému jsou propojené online a ty méně důležité nebo s menší frekvencí změn jsou propojené offline. Rozeberme si nyní výhody a nevýhody a náročnost implementace jednotlivých přístupů:
8
Online propojení Z hlediska provozovatele a uživatele internetového obchodu je toto propojení chápáno jako nejvhodnější a to hlavně proto, že provozovatel i uživatel mají vždy k dispozici aktuální data. Taková aktuálnost dat ale v mnoha případech nemusí být ve skutečnosti vůbec potřeba. Pokud přece jen je trváno na tomto způsobu propojení, je potřeba si uvědomit také jeho nevýhody. Pro jednoduchost předpokládejme, že jeden z propojených systémů je vždy primární (tedy vlastní ona sdílená data) a druhý systém je sekundární (tedy vzdáleně s těmito daty pracuje). Jak bylo popsáno v úvodu práce, v oblasti internetového obchodování je ve společnosti produkt internetového obchodu pořizován až následně po implementaci ekonomického systému, navíc internetový obchod není uzpůsoben k tomu, aby evidoval všechna data uvnitř společnosti (všechna data nutná z hlediska nutné legislativy). Z tohoto, ale i dalších organizačních důvody tedy předpokládejme, že data při online propojení internetového obchodu a ekonomického systému drží onen ekonomický systém. Internetový obchod pak tyto data čte a zobrazuje, případně některé objekty v ekonomickém systému také aktualizuje. Prvním problémem, který z online propojení plyne, je fakt, že ekonomický systém a internetový obchod má prakticky naprosto disjunktní skupinu uživatelů. Ekonomický systém v organizaci je používán jen zaměstnanci společnosti, internetový obchod pak pro změnu jejími zákazníky. Vzhledem k tomu, že zaměstnanci společnosti pracují primárně uvnitř nějaké kancelářské budovy a jsou propojeni rychlou lokální sítí, je pro ně z důvodu rychlosti práce vhodné, když je ekonomický systém také provozován uvnitř této rychlé sítě, např. na serveru připojeného do této LAN. Naopak uživatelé internetového obchodu (zákazníci) jsou běžně rozprostřeni na velké ploše (konkrétní stát nebo dokonce celý svět). Nejideálnější místo umístění serveru internetového obchodu tak, aby všichni mohli pracovat bez velkého rychlostního omezení, je pak na rychlé páteřní lince Internetu. Mezi serverem, na kterém běží ekonomický systém a serverem, na kterém běží internetový obchod, je tedy propojení s omezenou rychlostí a omezenou stabilitou - rychlost je ekvivalentní rychlosti internetového připojení společnosti a stabilita takových připojení je o poznání nižší než stabilita páteřních linek. Pokud by tedy internetový obchod pracoval online s daty přímo uvnitř ekonomického systému, znamenalo by to značné zpomalení, protože všechna tato data by proudila po pomalém internetovém připojení. Při výpadku internetového připojení společnosti by pak nefungoval ani internetový obchod. Mezi další nevýhody tohoto způsobu propojení patří náročná implementace tak, aby internetový obchod rozuměl struktuře a formátu dat v ekonomickém systému. Upozorněme i na bezpečnostní riziko – proces generující jednotlivé internetové stránky uživatelům obchodu musí být přímo připojený k ekonomickému systému. V případě chyby (bezpečnostní díry) ve skriptu generujícím stránku pak může útočník teoreticky zneužít nebo dokonce poškodit dat uvnitř ekonomického systému.
9
Na druhou stranu, značnou výhodou tohoto přístupu je, že není potřeba synchronizovat na internetový obchod všechna data včetně těch, které nebude možná nikdy potřeba. To u určitých propojených objektů může znamenat snížení datové náročnosti propojení. Není nutné například přenášet velké množství dokladů zákazníka, který na internetový obchod běžně nepřistupuje nebo se na seznam svých dokladů nedívá. Tento způsob propojení tedy může být vhodný v případě, že mezi internetovým obchodem a ekonomickým systémem existuje velmi rychlé a stabilní datové propojení. Při návrhu je pak potřeba počítat s potenciálně náročnější implementací a bezpečnostním rizikem.
Offline propojení Primární nevýhodou tohoto propojení je, že data uvnitř sekundárního systému (internetového obchodu) mohou být neaktuální. Dále je pak nevýhodou potenciálně zbytečně velká datová náročnost – viz problém s přenosem dokladů zákazníka, který se na ně nedivá, popsaný v předchozích odstavcích. Na druhou stranu, výhodou offline propojení je nezávislost na internetovém připojení společnosti a tedy pravděpodobně řádově vyšší rychlost a dostupnost internetového obchodu. Odpadá také bezpečností riziko popsané v předchozím oddílu, protože procesy generující stránky internetového obchodu a synchronizující data jsou oddělené.
Pseudo-online propojení Tento způsob propojení prakticky vychází z offline propojení popsaného v předchozím oddílu s tím, že řeší problém neaktuálnosti dat. Data jsou totiž synchronizovaná vždy, když je potřeba – tedy když proběhne nějaká událost, o jejímž důsledku by se měla dozvědět i druhá strana přenosu. Bohužel tento způsob propojení předpokládá v obou systémech funkci, která je schopna vyvolat určitou akci při vzniku určité události (například spustit přenos nové objednávky z eshopu do ekonomického systému při jejím vzniku, nebo opačně spustit aktualizaci skladové dostupnosti při její změně v ekonomickém systému). Na straně hotového ekonomického systému nemusí být možné takové chování zajistit.
Online + offline propojení + pseudo-online propojení Tato kombinace předpokládá, že se na propojení nebudeme dívat jako na celek, ale budeme posuzovat vhodnost určitého způsobu propojení zvlášť pro daný objekt. Současně budou brány v patrnost i požadavky na způsob přenosu ze strany 10
provozovatele internetového obchodu případně i jeho uživatele. Tedy například informace o skladové dostupnosti můžeme vždy získávat online (v případě, že propojení obou systému je funkční) a tyto údaje můžeme mít uložené v cache (pro případ výpadku propojení). Nové objednávky bude naopak vhodné přenášet pseudo-online – tedy při vzniku objednávky v eshopu vyvoláme její vysynchronizování do externího systému. Doklady (jako třeba faktury, dodací listy) můžeme bez jakýchkoliv problémů synchronizovat pomocí online propojení. Krátkodobé výpadky dostupnosti dokladů na eshopu žádné problémy nezpůsobí a frekvence zobrazování těchto dokladů na eshopu není velká, tedy jejich získávání z externího systému při každém požadavku uživatele eshopu nebude znamenat velkou datovou náročnost a nezatíží zásadně internetové připojení společnosti. Tento individuální přístup jako kombinace všech dříve popsaných postupů umožňuje maximalizovat výhody a minimalizovat nevýhody správnou volbou vhodného způsobu propojení pro daný přenášený objekt, jeví se tedy jako nejvhodnější. Na druhou stranu může být implementačně náročnější, protože je nutné implementovat více způsobu propojení než při volbě jednoho konkrétního způsobu pro všechny objekty.
Podle použité technologie Jako technologii pro propojení 2 systémů musíme vždy volit takovou, která leží v průniku technologií, které podporují oba systémy. Existují následující 3 obecné technologické principy s tím, že určitý systém může podporovat nějaké nativní způsoby propojení s použitím určitých proprietárních protokolů, pro které nabízí také klientské knihovny. Zmíněné 3 obecné principy jsou: Přímý přístup do databáze API / vzdálené volání procedur – například technologie Webový služeb Automatizovaný export a import Přímý přístup do databáze Jeden z propojených systémů se pomocí nativního nebo obecného protokolu (OLEDB, JDBC, …) přímo připojí nejen ke své databázi, ale i k databázi systému na druhé straně. Pomocí SQL dotazů, volání uložených procedur a funkcí pak čte a provádí změny v datech v konkrétních tabulkách druhého systému. Tyto operace mohou být prováděny jednak na hlavních datových tabulkách používaných přímo cílovým systémem nebo mohou k účelům aktualizace dat existovat pomocné
11
„přenosové“ tabulky a pohledy tak, aby došlo k odstínění a případně transformaci datového modelu mezi zdrojovým a cílovým systémem. Tento způsob propojení je velmi jednoduchý a transparentní z hlediska implementace, ale obsahuje určité technologické a bezpečnostní omezení. Z technologického hlediska může být problém pomocí nativních protokolů pro přístup do databáze překonat všechna zabezpečení například ve formě firewallů. Z bezpečnostního hlediska pak může být problémové omezit přístupová práva na tolik, aby klientský systém mohl přistupovat ke všem potřebný datům, ale naopak se nedostal k datům, které pro práci nepotřebuje. Zároveň může být problém zajistit dostatečnou integritu všech změn prováděných ze strany klientského systému stejně jako zabránit nechtěnému případně záměrnému poškození dat.
API / vzdálené volání procedur Tento princip předpokládá propojení na vyšší úrovni, než je princip přímého přístupu do databáze. Klientský systém (internetový obchod) se pomocí nějaké standardního či méně standardního protokolu připojí k aplikačnímu serveru systému na druhé straně. Tomuto aplikačnímu serveru pak klade příkazy vedoucí k získání či změně dat. Při komunikaci s aplikačním serverem se využívá principu vzdáleného volání procedur (remote procedure call). Aplikační server definuje sadu procedur, funkcí či metod (dle názvosloví použité technologie) a zpřístupní tyto metody tak, aby bylo možné je vyvolat skrz určitý komunikační kanál (lokální síť nebo Internet) – tedy z úplně jiného procesu běžícího často na úplně jiném serveru, který může být potenciální značně daleko od běžícího aplikačního serveru. Na základě názvu vyvolané metody a předaných parametrů pak aplikační server provede určitou akci (získání či změnu dat v lokální databázi) a výslednou informaci opět přes zvolený komunikační kanál předá volajícímu systému. Dnes velmi rozšířenou a hlavně standardizovanou technologií umožňující snadno implementovat vzdálené volání procedur je technologie Webových služeb (Web Services). Tato technologie realizuje komunikaci v nejčastějším případě pomocí HTTP protokolu. Tento fakt omezuje výše popsaný problém s překonáváním firewallů po cestě od klienta k serveru. Protokol HTTP je standardním protokolem a firewally jej dokáží bez problému zpracovat a komunikaci propustit k cíly. Pomocí vhodného návrhu metod zpřístupněných ke vzdálenému volání je možné omezit také bezpečnostní riziko a vyřešit problém se zachováním integrity dat. Metody je totiž možné definovat s různou granularitou. Jednak je možné definovat jednoduché metody spíše nahrazující jednotlivé SQL příkazy nebo dokonce jen obalující SQL příkazy do určité „obálky“ – toto ale řeší jen problém s překonáváním firewallů a nikoliv bezpečnostní riziko.
12
Pokud se přesuneme k vyšší úrovni, pak je možné definovat specifické metody pro manipulaci s jednotlivými objekty. Tyto objekty mohou být jak fyzické – například ekvivalentem k řádkům jednotlivých tabulek v DB. Objekty mohou být ale i logické – tedy takové, co reprezentují určitý objekt tak jak jej vnímá uživatel neznalý technického pozadí. Například tedy můžeme mít metody manipulující s objektem „Objednávka“, který je ale velmi nepravděpodobně uložen jen v jedné jediné tabulce v DB. Naopak se pod tímto pojmem skrývá potenciálně velké množství informací – ať už je to například hlavička objednávky, doručovací informace, informace o dopravě, jednotlivé řádky objednávky, a podobně. Můžeme ale ještě více abstrahovat od jednotlivých objektů a můžeme skupinu metod pro vzdálené volání navrhnout tak, aby odpovídala jednotlivým událostem a akcím tak jak je vnímá internetový obchod – tedy například jednu metodu sloužící k získání všech potřebných dat pro aktualizaci katalogu zboží na eshopu (včetně ceníku a skladové dostupnosti), jinou metodu pro aktualizaci informací o zákazníkovi na straně ekonomického systému a to třeba i se seznamem doručovacích adres zákazníka. Otázkou je, jak moc je vhodné abstrahovat od dat fyzicky uložených v tabulkách cílového systému. Čím větší abstrakce, tím bezpečnější komunikace (volající systém nemůže nic pokazit – nemůže poškodit fyzickou integritu ani logický smysl dat). Na druhou stranu tím větší omezení toho, co je možné z volajícího systému zajistit. V případě využití metod definovaných na té nejvyšší úrovni je pak, při rozšíření propojení na další oblasti dat, nutností doprogramovat i příslušné metody na straně volaného systému, což může navýšit pracnost požadovaného rozšíření propojení.
Automatizovaný export a import Tento princip komunikace chápejme jako proces, kdy zdrojový systém vyexportuje data v obecně podporovaném nebo předem domluveném formátu (vhodné je například XML s určitou definovanou či dohodnutou strukturou). Soubor s exportovanými daty pak nějakým vhodným způsobem zpřístupní cílovému systému (například pomocí FTP nebo HTTP protokolu). Cílový systém si data stáhne a dle definovaných pravidel pak zpracuje. Popsaný princip je značně jednoduchý až primitivní a je tedy používán pravděpodobně jen u systémů, které nenabízejí lepší a modernější možnosti propojení. Nevýhodou také je, že se prakticky jedná jen o jednostrannou komunikace a získání odezvy či výsledku zpracování může být značně složité nebo dokonce nemožné.
13
Podle iniciátora komunikace Určitý typ dat je přenášen z ekonomického systému do internetového obchodu (katalog zboží, ceníky, …), naopak některé informace jsou přenášený v opačném směru (objednávky, reklamace, …). Některé objekty pak mohou být přenášeny dokonce oběma směry – například objednávka je přenesena primárně z internetového obchodu do ekonomického systému, ale aktualizace jejího stavu probíhá opačným směrem. Ačkoliv se data přenáší oběma směry, nemusí vždy iniciátorem komunikace být systém, ze kterého data proudí. Tedy například v případě přenosu katalogu zboží je zdrojem dat sice ekonomický systém, ale není běžné, že by ekonomický systém nějakým způsobem notifikoval eshop o nových nebo aktualizovaných záznamech. Přenos probíhá v tomto případě spíše metodou pull – kdy cílový systém (tedy internetový obchod) se dotazuje ekonomického systému, zda pro něj má nějaké nové informace. Obecně tedy z tohoto hlediska můžeme jako iniciátora určit: Systém, který je zdrojem dat Internetový obchod, a to bez ohledu na zdroj dat Ekonomický systém, a to bez ohledu na zdroj dat Stejně jako v případě taxonomie „Online vs. offline“ není možné stanovit iniciátora globálně platného pro všechny typy objektů, budeme jej spíše určovat pro každý typ objektu zvlášť. Navíc i určení iniciátora přenosu daného objektu není možné řešit globálně a dávat nějaká doporučení. Naopak je potřeba vždy brát v úvahu technické možnosti obou systémů jako limitující faktor.
Podle umístění kódu realizujícího propojení Tento způsob členění je z části provázaný s členěním podle iniciátora komunikace. Na straně iniciátora musí být totiž vždy určitý programový kód, který nastartuje procesy spojené s přenosem. Volitelně je pak možné mít určitý doplňující programový kód i na straně systému, který iniciátorem není. Tento kód může být například ve formě triggerů a uložených procedur při přímém propojení databází nebo exportní a importní kód při propojení pomocí automatických exportů a importů. Snahou implementátorů propojení je centralizovat co nejvíc implementované logiky a kódu pouze na straně jednoho systému. Intervence obou stran propojení prodražuje a znamená i nejasné kompetence a zodpovědnost za vzniklé problémy. Bohužel paradoxem je fakt, že při centralizaci kódu na jedné straně přenosu je možné využít jen ty principy, které nejsou z hlediska návrhu úplně čisté – třeba přímý přístup do 14
databáze druhého systému a zasahování přímo do ostrých tabulek nebo napojení pomocí webové služby na úrovni metod pracujících s fyzickými objekty v databázi.
Přenos změn vs. kompletní přenos Při přenosu dat je možné buď přenášet pouze změněné údaje, nebo při každém přenosu přenášet kompletní data daného typu. Stejně tak i u tohoto typu členění si můžeme všimnout kladů a záporů obou řešení, kdy klad jednoho je prakticky záporem toho druhého a naopak. Negativem změnového přenosu je případné technické omezení jednoho ze systémů v tom ohledu, že systém nemusí být schopen evidovat změny provedené od posledního přenosu. Tedy nemusí vůbec existovat možnost jak získat seznam změn, které je nutné přenést. Problém může také nastat v konzistenci dat. V případě chyby během přenosu nemusí dojít ke korektnímu přenosu určité změny z jednoho systému do druhého, ale tato změna může být i přesto označena jako přenesená. Z podstaty změnového přenosu pak již ke správné aktualizaci dat nedojde. Je tedy nutné dbát zvýšeného úsilí pro korektní ošetření všech chybových stavů tak, aby k žádným nekonzistencím nedocházelo. Naopak značným negativem kompletního přenosu všech dat je samozřejmě velký nárůst datové náročnosti. Pravidelný přenos veškerých dokladů z jednoho systému do druhého může obnášet přenos obrovského množství dat a to i v případě, kdy v datech nebyly provedeny od posledního přenosu žádné nebo jen elementární změny. Důležité je tedy stanovit rozumný kompromis v časování přenosu tak, aby častý přenos velkého množství dat zbytečně nevytěžoval internetové připojení a neubíral prostředky obou systémů.
15
3. Datový model a procesy internetových obchodů Tato kapitola poskytuje přehled datových objektů, které jsou standardně součástí internetového obchodu, a procesů, které se k těmto datům vážou. Vzhledem k tomu, že internetové obchody jsou stejně jako ekonomické systémy často realizované na míru dle požadavků konkrétního zákazníka, resp. hotové produkty jsou na míru zákazníků upravitelné a tedy značně variabilní, neklade si práce za cíl poskytnout na tomto místě kompletní přehled zachycující všemožné speciality určitých produktů. Naopak cílem této kapitoly je na příkladu těch základních objektů a procesů představit čtenáři kontext, ve kterém se práce pohybuje, a ukázat onu variabilitu implementací a tedy zdůvodnit tak požadavek na univerzálnost a obecnost navrhovaného řešení blíže specifikovaný později.
3.1. Objekty internetových obchodů Tato kapitola obsahuje seznam základních objektů běžně evidovaných na internetových obchodech.
Katalog zboží Základem každého internetového obchodu je katalog zboží, tedy seznam toho, co je možné na internetovém obchodě nakupovat. Z důvodu snadnější orientace a vyhledávání zboží je tento seznam členěn ve většině případů hierarchicky. Často pak toto hierarchické členění není jen podle jednoho kritéria, ale podle několika kritérií. Známým příkladem může být jeden hierarchický strom mající na první úrovni různé typy produktů a druhý strom mající na první úrovni seznam výrobců. Každý produkt může být v každém stromu zařazen na jednom nebo na více místech. Z hlediska propojení internetového obchodu a ekonomického systému je třeba upozornit, že hierarchický strom často není v napojeném ekonomickém systému evidován − jednak proto, že systém hierarchické strukturování vůbec nepodporuje nebo je členění do hierarchie nastaveno podle jiného zvyku, než je běžné pro uživatele internetového obchodu. V takovém případě je pak nutné nějakým způsobem v rámci přenosů zabezpečit přiřazení každé položky do určité větve (větví) všech stromů na eshopu (například s použitím mapovací tabulky). Ke každému produktu je evidována spousta různých parametrů. Od několika základních (které jsou v naprosté většině internetových obchodů stejné), mezi které můžeme zařadit hlavně název, dlouhý textový popisek nebo například výrobce až po variabilní seznam parametrů, které se liší podle prodávané komodity. Který parametr
16
je možné považovat za základní a který za rozšířený se samozřejmě liší u různých produktů internetového obchodu. V naprosté většině případů je k produktům přiřazen obrázek (potenciálně několika různých velikostí) a případně ještě další přílohy (manuály, záruční listy, …). Stejně tak jako v případě produktového stromu, nemusí být tyto dodatečné informace součástí ekonomického systému, který je primárně určen pro vedení skladů a účetnictví a nikoliv pro ukládání informací o zboží, které jsou primárně určené zákazníkům.
Cenotvorba Cenotvorba neboli výpočet ceny zboží, za kterou se na internetovém obchodě prodává, leží virtuálně někde mezi katalogem zboží a objektem uživatele internetového obchodu. Výpočet ceny je často kontextový pro určitého zákazníka nebo skupinu zákazníků. Výpočet může být značně komplikovaný s mnoha různými podmínkami, slevami a podobně.
Skladová dostupnost Stav skladové dostupnosti je možné evidovat jednak globálně jeden pro každou položku nebo je možné jej členit na několik stavů, vždy jeden stav pro každý sklad společnosti určený pro prodej zboží na internetu. Stav zboží pak může být jednak výčtový (je skladem / není skladem) nebo intervalový (není skladem, 1-10, 11-100, …) nebo absolutní udávající počet kusů daného zboží skladem.
Uživatelé internetového obchodu Dalším z hlavních elementů každého internetového obchodu je jeho uživatelská základna. Internetové obchody můžeme rozdělit na ty sloužící pro B2C prodej (prodej koncovým zákazníkům) a ty sloužící pro B2B prodej (prodej dalším distributorům a prodejcům). Některé internetové obchody mohou být kombinované a mohou sloužit pro prodej zboží v obou sférách. Stejným způsobem můžeme rozdělit i uživatele na skupinu B2C a B2B uživatelů podle toho, zda představují koncového zákazníka nakupovaného zboží nebo naopak. Pro B2C uživatele evidují internetové obchody většinou méně informací než pro B2B zákazníky. Konkrétní rozdíly a seznam evidovaných informací se opět může značně lišit případ od případu. Jednodušší internetové obchody mohou evidovat pouze fakturační a jednu doručovací adresu. Ty složitější pak mohou evidovat seznam více doručovacích adres, seznam osob spojených s určitým zákazníkem, příslušnou dealerskou skupinu respektive přiřazený ceník.
17
Doklady U jednoduchých obchodů se evidence dokladů omezuje pouze na seznam objednávek. U těch složitějších (většinu B2B) obchodů může být požadováno zpřístupnit k objednávkám i relevantní faktury, dodací listy, případně kompletní agendu týkající se reklamací. Ve všech těchto případech mohou být doklady filtrovány jen na ty vázané nějakým způsobem k procesům realizovaným na Internetovém obchodu. V jiných případech pak může být potřeba synchronizovat na internetový obchod úplně všechny doklady všech uživatelů.
3.2. Procesy na internetových obchodech S ohledem na objekty používané na internetových obchodech popsaných v předchozím oddíle budou nyní představeny základní procesy jako příklad toho, co by měl navrhovaný systém univerzálního propojení (samozřejmě mimo jiné) umožňovat. Přenos katalogu zboží z ekonomického systému Pravděpodobně ve všech případech se jedná o přenos stromů zboží a seznamu jednotlivých produktů se všemi informacemi a to výhradně z ekonomického systému do internetového obchodu. Jednou z hlavních funkcí ekonomický systém je evidence prodávaného zboží se souvisejícími informacemi a není tedy důvod při používání internetového obchodu pro duplicitní evidenci stejné agendy. Navíc, když uživatelský komfort obsluhy internetové aplikace je ve většině případů řádově horší než přívětivost desktopových aplikací. Přenos informací pro cenotvorbu z ekonomického systému Stejně jako v předchozím bodě se jedná výhradně o přenos všech informací nutných pro stanovení ceny zboží náležící jednotlivým uživatelům a to z ekonomického systému jako primárního úložiště těchto informací do internetového obchodu. Aktualizace skladové dostupnosti z ekonomického systému Tento proces může být chápán jako součást procesu aktualizace (přenosu) katalogu nebo jako proces oddělený. Skladová dostupnost má výlučné postavení v tom smyslu, že její aktualizaci je vhodné provádět co možná nejčastěji proto, aby měl uživatel v každé chvíli co nejaktuálnější informaci. Pro to je vhodné provádět tuto aktualizaci častěji než aktualizaci celého katalogu a má smysl tedy o ní uvažovat zvlášť. Přenos informací o uživatelích oběma směry Přenos uživatelů je oproti dříve zmíněným procesům obousměrný. Po registraci nového uživatele prostřednictvím formuláře na internetovém obchodu musí být zadané informace přenesené do ekonomického systému.
18
Naopak může být nutné vkládat nové uživatele i prostřednictvím ekonomického systému a musí být zajištěno, aby se takto založený obchodní partner v ekonomickém systému stal automaticky i uživatelem internetového obchodu (pokud je to na základě business politiky žádoucí). Přenos nových objednávek do ekonomického systému Tento proces je samozřejmostí, informace o objednaném zboží na internetovém obchodu musí být přenesena do ekonomického systému, tak aby se mohly automaticky nastartovat následné obchodní procesy související se standardním zpracováním objednávky. Aktualizace stavu objednávek z ekonomického systému Objednávka z obchodního hlediska v čase prochází různými stavy podle dílčích událostí s objednávkou souvisejícími (vystavení faktury, vyskladnění zboží…). Informace o těchto dílčích událostech jsou běžně součástí ekonomického systému a tedy je možné z něj tyto informace čerpat pro zobrazení stavu objednávky na internetovém obchodu. Přenos dokladů z ekonomického systému (případně i opačně) Pravděpodobně úplně ten nejzákladnější účel ekonomického systému je evidence dokladů tvořících účetnictví společnosti – tedy například faktur. Výstup z evidence faktur je často vyžadován i jako součást internetového obchodu – musí tedy existovat proces přenášející určité doklady z ekonomického systému do internetového obchodu. Příkladem opačného procesu může být například přenos dokladů souvisejících s reklamací. Reklamace je obchodní proces iniciovaný zákazníkem. Je tedy logické, aby prvotní krok pro nastartování tohoto procesu učinil na internetovém obchodu, který slouží pro jeho obchodní komunikaci se společností. Následně jsou zákazníkem zadané informace týkající se reklamace přeneseny do ekonomického systému pro další zpracování.
19
4. Model univerzálního napojení na externí systém Tato kapitola je stěžejní částí celé diplomové práce. Nejdříve na tomto místě bude definován požadavek univerzálnosti, obecnosti a rozšiřitelnosti, který by měl být tím hlavním cílem a přínosem modelu vytvořeného touto prací. Následně bude představen model navržený v mantinelech daných definovanými požadavky. Tento model bude primárně jakýmsi platformově nezávislým předpisem, kdy při jeho implementaci pomocí libovolného moderního programovacího jazyka do libovolného internetového obchodu obohatíme tento internetový obchod o možnost snadné spolupráce s jinými externími systémy.
4.1. Požadavek univerzálnosti, obecnosti a rozšiřitelnosti Jak bylo popsáno v předchozích kapitolách, při napojování internetových obchodů na externí systémy se často staví „na zelené louce“ a propojení na jednotlivé externí systémy je víceméně unikátní. To znamená, že musí být napsáno velké množství kódu, který se navíc často opakuje. Toto zvyšuje cenu a dobu vývoje propojení na externí systém. Aby měl model představený touto prací vůbec nějaký význam, je nutné trvat na tom, aby tento model hrál úlohu jakéhosi opakovatelně využitelného frameworku. Tento framework by měl nabízet komplexní prostředky, s použitím kterých markantně snížíme pracnost implementace nového propojovacího můstku na nový externí systém. Pokud chceme, aby nějaký model (resp. framework) byl opakovatelně využitelný, musí být značně univerzální, obecný a rozšiřitelný a nikoliv ušitý na míru jedné konkrétní situace. Požadavky na univerzálnost, obecnost a rozšiřitelnost se dohromady doplňují. Univerzálnost a obecnost nám říká, že tento model musí nabízet takové prostředky, abychom pomocí nich byli schopni pokrýt a zvládnout všemožné rozmanité situace. Situace, které přece jenom pomocí standardních prostředků nebude možné vyřešit, můžeme zvládnout pomocí rozšiřitelnosti, která nám dovolí zapojit do tohoto systému programový kód implementovaný třetí stranou sloužící pro vyřešení oné specifické situace, se kterou samotný návrh frameworku přímo nepočítal.
20
4.2. Základní principy fungování modelu Hlavním účelem vytvářeného modelu je výměna dat mezi dvěma oddělenými systémy – libovolným internetovým obchodem na straně jedné a libovolným externím systémem na straně druhé. Protože systémy na obou stranách mohou být jakékoliv (a protože po našem modelu požadujeme obecnost), nemůžeme přepokládat nějakou pevnou a známou strukturu těchto vyměňovaných dat. Představme si tedy, že mezi oběma systémy proudí jakési balíčky dat, jejichž vnitřek (strukturu) v době návrhu celého modelu neznáme – a musíme tedy počítat, že struktura jednoho datového balíčku může být značně variabilní co do velikosti tak typu dat uvnitř. Nejjednodušší forma výměny dat je naznačena na obrázku 1.
Obrázek 1: Základní princip výměny dat
Jeden ze systému vždy publikuje nějaký datový balíček, který je odeslán komunikačním kanálem druhému systému. Původce publikovaného balíčku může být bez omezení jedna či druhá strana komunikace. Tento návrh zjevně ale nesplňuje definované požadavky – systémy by se totiž musely navzájem znát, a tedy by musely mít v sobě zabudovaný kód pro komunikace právě s tím konkrétním systémem na druhé straně. Mezi oba systémy tedy musíme vložit nějaký můstek, který bude provádět zpracování datových balíčků ze strany jednoho systému a bude je překládat podle definovaných pravidel tak, aby jim rozuměl systém na druhé straně. Upravený průběh komunikace naznačuje následující obrázek. Z toho je navíc jasné, že onen framework, jehož model navrhujeme je umístěn uvnitř dílku „Můstek“, který jediný můžeme ovlivnit (máme totiž nějaký libovolný internetový obchod na straně jedné a libovolný externí systém na straně druhé).
21
Obrázek 2: Princip výměny dat včetně překladu do interního formátu
Základní struktura „Můstku“ Již bylo zmíněno, že náš model pro propojování musí zajistit výměnu obecných datových balíčků mezi jedním a druhým systémem. Protože data na obou stranách mohou být reprezentována ve zcela různých formátech, musíme zajistit překlad těchto dat do formát tak, aby jim rozuměla druhá strana. Navíc různorodost obou systémů se netýká pouze formátu, v jakém jsou data uložena, ale také jejich struktury (datová věta například pro objednávku na obou stranách komunikace bude pravděpodobně rozdílná). Náš model tedy musí zajistit transformaci dat jednak po stránce formátu, ale také po stránce obsahové (struktury). Abychom byli schopni snadno popsat a následně implementovat celý tento proces, je výhodné si jej rozložit na následující 3 části: 1. Vstupní datový balíček přeložíme do interního formátu našeho „Můstku“ 2. Datovou větu vstupního systému přeloženou do interního formátu transformujeme na datovou větu výstupního systému opět v interním formátu. 3. Výstupní větu přeložíme z interního formátu do formátu datového balíčku výstupního systému. Tento proces znázorňuje následující obrázek:
Obrázek 3: Postupný překlad datového balíčku mezi formáty V tuto chvíli nám vyvstala otázka, jaký bude ideální interní formát, ve kterém budeme transformovat datovou větu vstupního systému do datové věty výstupního systému. Pro tyto účely se nám přímo hodí univerzální a obecný formát XML, 22
pomocí kterého můžeme uchovávat libovolně strukturovaná data. Zároveň máme k dispozici technologii XSLT, pomocí které můžeme jednoduše a přímočaře provést transformaci dat popsanou určitým nadefinovaným předpisem. Data, která do systému vstupují, tedy přeložíme do XML, následně pomocí XSLT přetransformujeme do cílové datové věty a tyto cílová data přeložíme do cílového formátu pro externí systém.
Překlady dat a sběrnice “translatorů” Nyní si vzpomeňme na náš požadavek definovaný na začátku této kapitoly – systém musí být obecný. Systém musí být schopen zpracovat prakticky libovolná vstupní data v libovolných formátech a obdobně tak předat data dále v libovolném formátu externímu systému. Co konkrétně formátem dat rozumíme, si ukažme na několika příkladech (všechny tyto body platí jak pro vstupní tak výstupní systém): -
Data uložená v databázi - v různých formátech nebo na různých databázových serverech Data uložená v TXT nebo například CSV souboru na disku Data uložená v nějaké souborové databázi (XLS, DBF, …) Data předaná jako parametry vstupnímu bodu, který je reprezentovaný například jako webová služba Data zaslaná v určitém formátu do určité e-mailové schránky
Jak je vidět, není možné přímo v rámci modelu nebo jeho konkrétní implementaci postihnout všechny možné vstupní a výstupní formáty dat. Tento problém ale můžeme vyřešit pomocí principu rozšiřitelnosti. Kód (třídu), který provádí překlad mezi různými formáty dat, nazvěme „translator“. Množina „translatorů“ pak nebude fixní (nebude jich určitý omezený počet), ale jejich množinu umožníme rozšiřovat zapojováním dodatečných „translatorů“ vytvořených třeba i třetí stranou. V případě nutnosti zpracovat data ve formátu pro systém neznámém, budeme moci připravit si vlastní „translator“, který zapojíme do systému a který zajistí překlad dat z tohoto „neznámého“ formátu do interního formátu XML. Princip sběrnice „translatorů“ opět zachycuje následující obrázek:
23
Obrázek 4: Sběrnice "translatorů"
Rozdělení na procesy V kapitole 3 byly představeny příklady procesů, které popisují vždy ucelenou a zároveň ohraničenou výměnu dat. Data vyměňovaná v rámci jednoho procesu spolu úzce souvisí – běžně se jedná o data týkající se určitého objektu internetového obchodu respektive externího systému (například přenos katalogu zboží z externího systému do eshopu, přenos objednávek z eshopu do externího systému, a podobně). Každý takový proces mezi internetovým obchodem a externím systémem můžeme popsat sekvencí operací obdobně, jako kdybychom tento proces programovali standardním způsobem „na zelené louce“. Mezi tyto operace, které jsou součástí procesu, patří: a) Načtení dat (datového balíčku) z jednoho nebo druhého systému b) Transformace dat, která jsou obsahem jednoho nebo více již dříve načtených datových balíčku a to do datové věty dle cílové struktury. c) Uložení dat (datového balíčku) do jednoho nebo druhého systému. Princip načítání a ukládání dat, jehož součástí je překlad dat mezi interním formátem a formátem jednoho či druhého systému, byl popsán v předchozí části pomocí sběrnice „translatorů“. Za zmínku ale stojí fakt, že operace uložení dat může mít nějakou návratovou hodnotu, kterou je potřeba z cílového systému získat a uložit pro další zpracování (běžně například ID založeného záznamu pro navázání dalších „pod“ záznamů). Rovněž i operace načtení dat může být v některých případech parametrizovaná již dříve načtenými daty. Fungování operací načtení a uložení se tedy může z určitého hlediska stírat a tyto 2 operace mají mnoho společného.
24
Zbývá definovat podobu prostředního kroku, který má na starosti transformaci dat z hlediska jejich struktury, kdy originální i transformovaná data jsou uložena v interním formátu – tedy XML. Způsob zajištění obecnosti tohoto transformačního kroku bude popsán v následujícím oddíle. Celkový pohled na průběh zpracování jednoho procesu zachycuje následující obrázek.
Obrázek 5: Kompletní cyklus zpracování procesu
Na obrázku je zachycen opakující se cyklus, kdy při každém průchodu cyklem se zpracuje operace jednoho typu (načtení dat, transformace, ukládání dat). Při načtení dat si systém načítá data z některého z propojených systémů pomocí sběrnice „translatorů“. Obdobně při ukládání dat provádí můstek ukládání dat opět do jednoho ze systém§, opět pomocí sběrnice “translatorů”.
Obecná transformace Jak již bylo zmíněno, tak pro obecnou transformaci dat ve formátu XML slouží technologie XSLT. Možnosti XSLT jsou ale značně omezené, co se týká práce se samotnými daty. XSLT řeší primárně transformaci struktury originálního XML dokumentu na XML dokument s jinou strukturou. Možnosti transformovat samotná data nejsou nikterak velká. Transformovat samotná data, ale potřebujeme také, protože stejné věci mohou být v obou propojených systémech uloženy různě, například:
25
Jméno a příjmení může být v jednom systému uloženo zvlášť a v druhém dohromady Ceny v objednávce mohou být v jednom systému uloženy bez DPH a v druhém systému s DPH. Časový interval může být v jednom systému uložený jako datum od + datum do, ve druhém systému jako datum od a v druhém poli může být místo koncového data jen počet dní, jak je interval dlouhý. Tento problém můžeme vyřešit podobným způsobem jako v případě obecných a rozšiřitelných „translatorů“. Součástí modelu tedy bude další sběrnice sloužící k transformačním krokům procesu. Do této sběrnice budou moci být zapojené třídy implementující různorodé funkce pro transformaci jednotlivých hodnot uvnitř XML nebo celých větších celků XML. Takovéto třídy bude moci zajistit také třetí strana. Bude tedy možné provádět obecné transformace včetně takových, se kterými se při návrhu modelu ani jeho implementaci nepočítalo.
4.3. Fungování modelu konkrétně V předchozí části byly popsány základní myšlenky fungování modelu. Aby bylo možné podle informací uvedených v této práci model implementovat, je potřeba objasnit a definovat fungování jednotlivých částí modelu konkrétně. To bude provedeno v této části. Detailně zde budou popsány struktury definující jednotlivé procesy přenosů mezi oběma systémy a také struktury definující jednotlivé kroky těchto procesů. Popsána bude také vazba mezi hlavní smyčkou zpracování a oběma sběrnicemi – sběrnicí „translatorů“ a sběrnicí uživatelských transformačních funkcí. Protože tato práce má popisovat jakýsi model komunikačního frameworku, bude popis v této části myšlen jako platformově nezávislý. Nebude tedy řešit konkrétní datové typy vhodné pro jednotlivé informace uložené ve výše zmíněných strukturách, ani technické prostředky jednotlivých programovacích jazyků, pomocí kterých bude možné popsané principy konkrétně naimplementovat. Určité zajímavé detaily při implementaci tohoto frameworku na konkrétní platformě jsou zachyceny v následující (páté) kapitole.
Interní datové struktury přenosového můstku V předchozí teoretické části bylo zachyceno rozdělení jednotlivých přenosů dat do sdružených skupin – procesů. Každý proces byl definován jako sekvence operací 3 typů fungujících obdobně jako reálná implementace přenosu pomocí standardních prostředků bez použití tohoto frameworku. Tento popis byl značně obecný. Na tomto místě jej nadefinujeme detailně a to hlavně z pohledu struktur, které tyto pojmy reprezentují. 26
Přenosový proces – struktura PROCESSES: Tato struktura popisuje jednotlivé sdružené skupiny přenosů dat jednoho typu – tedy 1 proces je například ekvivalentem operace „Přenos katalogu zboží“ nebo „Přenos nových objednávek“. Informace (pole), které takový pojem zachycují, jsou popsané v následující tabulce: Pole ID
Typ -
Popis Jednoznačný identifikátor procesu / primární klíč (Typ tohoto pole je ponechán volbě na konkrétní implementaci na konkrétní platformě. Standardně bude implementován pravděpodobně jako autoinkrementální číslo.)
Code Description Multiple Timeout
String String Boolean Int
Jednoznačný identifikátor procesu použitelný v kódu, tedy například „ITEMS“, „ORDERS“ Textový popis daného procesu pro uživatele. Příznak, zda tento proces může běžet v jednu chvíli vícekrát Počet sekund, za které je proces pak považován jako zaseknutý nebo skončivší chybou.
Kroky přenosového procesu – struktura PROCESS_STEPS: Každý proces je definován jako sekvence operací. Tyto operace jsou popsány touto strukturou: Pole ID
Typ -
Popis Jednoznačný identifikátor kroku / primární klíč (Typ opět ponechán na konkrétní implementaci)
IDProcess Index Type
Int Int
CustomClass
String
Parameters
XML
Odkaz na identifikátor procesu, do kterého krok patří Číslo kroku, podle kterého se určí pořadí zpracování 1 – načítání dat 2 – transformace dat 3 – uložení dat 0 – speciální typ operace, třída nebo funkce, která se má spustit, je definována polem CustomClass Třída nebo funkce, pokud se jedná o speciální typ operace (tedy jiný typ operace, než načítání, transformace nebo uložení) XML dokument s parametry pro daný krok procesu. Struktura XML je pevně definovaná pro standardní typy operace (1, 2, 3) a volitelná pro speciální typ operace (0).
27
Historie běhu procesů – struktura PROCESS_HISTORY Pro účely monitoringu a funkci systému je potřeba sledovat historii běhu procesů. Tato struktura zachycuje informace o běhu celých procesů, ale i jednotlivých operací uvnitř procesu. Pro rozlišení, zda se konkrétní záznam týká celého procesu nebo konkrétního kroku slouží pole Index. Pole ID IDProcess Index PID
Typ Int -
StartTime EndTime Running Successful ErrorText
DateTime DateTime Boolean Boolean Text
ErrorDetail
XML
Popis Jednoznačný identifikátor záznamu historie Odkaz na identifikátor procesu, kterého se záznam týká Číslo kroku, kterého se záznam v historii týká, pokud se týká celého procesu, pak je Index = 0 Identifikátor běhu procesu – pokud u daného procesu je možný jeho vícenásobný běh, pak by bylo složité přiřadit, které záznamy historie patří k sobě. Tento jednoznačný identifikátor (například GUID) vygeneruje systém při spuštění celého procesu a je použit pro identifikaci historie jeho i všech jeho kroků. Datum a čas spuštění procesu nebo kroku Datum a čas dokončení procesu nebo kroku Příznak, zda proces nebo krok stále běží Příznak, zda byl proces nebo krok dokončen úspěšně V případě Successful = false obsahuje informaci o vzniklé chybě. Pole pro uložení případných detailů o chybě ve strukturované XML podobě.
Při spuštění nového procesu je vložen záznam s následujícími hodnotami: IDProcess Odkaz na spouštěný proces
Index 0
PID Jednoznačný vygenerovaný identifkátor
StartTime Aktuální datum a čas
EndTime NULL
Running 1
Při spuštění každého kroku procesu se vloží stejný záznam, kde rozdíl je pouze v poli Index, které určuje Index kroku procesu (viz PROCESS_STEPS). PID bude obsahovat identickou hodnotu jako záznam o procesu, pod který krok patří: IDProcess Odkaz na proces, pod který krok patří
Index Index procesu (viz PROCESS STEPS)
PID Identický dříve vygenerovaný identifikátor
StartTime Aktuální datum a čas
EndTime NULL
Running 1
Při obou vložení záznamu do historie běhu procesů si systém poznačí jednoznačný identifikátor uložený v poli ID pro pozdější uložení informací o dokončení kroku nebo procesu. Dokončení kroku nebo procesu může být buď úspěšné, nebo skončit chybou. Při této
28
události jsou zaktualizovány následující pole struktury konkrétního záznamu historie (podle uloženého ID): EndTime Aktuální datum a čas
Running 0
Successful Podle toho, zda chyba nebo ne
ErrorText V případě chyby základní informace
ErrorDetail Případné detailní informace o chybě
Pro zajištění korektnosti informací v historii běhu procesů a tudíž i pro zajištění korektního fungování systému je nutné spouštět pravidelný proces, který bude zjišťovat zaseknuté nebo přerušené procesy a kroky a bude doplňovat informaci do historie. Pole Timeout ve struktuře PROCESSES určuje maximální povolenou délku běhu procesu. Je možné, že při běhu dojde k neočekávané chybě, která nebude korektně odchycena a po takto přerušeném nebo zatuhnutém procesu zůstanou běžící procesy a kroky v historii běhu. Je potřeba tedy periodicky porovnat, zda existuje běžící proces překročil jeho maximální povolenou dobu běhu. Pokud ano, je potřeba v historii doplnit pole stejným způsobem jako kdyby proces skončil chybou. Doplnění se týká i záznamu o kroku v historii, který není označen jako dokončený a patří pod tento proces. Doplnění těchto informací (a uzavření nedokončeného procesu) je nutné hlavně pro procesy neumožňující vícenásobný běh. V případě neukončeného procesu v historii běhu by se totiž takový proces již nikdy nespustil, což samozřejmě není žádoucí.
Centrální úložiště datových zdrojů – struktura DATA_SOURCES Je možné očekávat, že s jedním datovým zdrojem, ze kterého systém bude číst data nebo do něj bude data zapisovat, bude pracovat více procesů nebo minimálně více kroků tohoto procesu. Pro napojení na určitý datový zdroj potřebujeme vždy množinu informací (adresa zdroje dat, přihlašovací údaje). Tyto údaje není vhodné evidovat u každého z kroků procesu, protože v případě změny adresy nebo přístupových údajů by bylo nutné tuto změnu provést na mnoha místech. Z tohoto důvod definujme strukturu evidující informace o datových zdrojích. Pole ID Code
Typ String
Parameters
XML
Popis Jednoznačný identifikátor datového zdroje Identifikátor datového zdroje používaný v definici kroků procesu, např „ERP“, „ESHOP“ Dokument obsahující všechny parametry nutné pro komunikaci s datovým zdrojem.
29
Datový kontext běžícího procesu Základní fungování celého návrhu spočívá v načítání dat ze vstupního zdroje nebo zdrojů, v transformaci takto získaných dat a jejich uložení do výstupních zdrojů. Vzhledem k tomu, že po tomto frameworku vyžadujeme obecnost, nemůžeme se spokojit s tím, že transformace a následně uložení dat bude vždy vycházet jen z jednoho ohraničeného datového balíku získaného během jednoho procesu načtení dat. Naopak logickou funkcí celého systému by měla být možnost libovolně kombinovat data získaná postupně z jednoho ale i více zdrojů. Běžící proces, který se skládá z uživatelem definovaných kroků (viz výše), musí zahrnovat úložiště, ve kterém uchovává postupně načítaná dat a zároveň výsledky datových transformací. Pokud totiž budeme ve stejném kontextu ukládat i výsledky transformací, umožní nám to následně kombinovat výsledek transformace určitého datového balíčku s následně načtenými daty ze stejného ale i případně jiného zdroje. Jak by tedy měl vypadat tento datový kontext a podle jakého klíče by se s ním mělo pracovat? V předchozích částech byl jako formát vhodný pro uchovávání dat uvnitř systému určen formát XML. Základ transformací dat ze vstupu na výstup pak logicky zajistí XSLT transformace. Nejjednodušším způsobem jak umožnit transformování dat získaných potenciálně z více různých zdrojů v jednom průchodu a to jednou transformací, je mít uložené tyto data uvnitř jednoho XML dokumentu. V tomto postupu není žádný problém a je to velmi bezprostřední. Před prvním načtením dat a jejich transformací do XML založíme prázdný XML dokument reprezentující datový kontext procesu. Transformací získaný XML dokument odpovídající načteným datům vnoříme dovnitř připraveného prázdného XML dokumentu. Následuje další načtení externích dat. I v tomto případě dostaneme XML reprezentující data a toto XML můžeme buď přidat za předchozí, nebo vnořit do jiného uživatelem vybraného elementu XML datového úložiště. Tento postup je znázorněn a definován následujícími ukázkami.
Nejdříve připravený prázdný XML. Ukázka prázdného XML datového kontextu:
30
Nyní ukázka XML reprezentace načtených dat a jejich vnoření do připraveného XML dokumentu: XML reprezentující načtená data:
XML datového načtených dat:
kontextu
po
C_0001 … … ….
C_0001 … … ….
vnoření
A nakonec ukázka načtení dalšího datového balíčku opět včetně jeho vnoření do XML s datovým kontextem: XML reprezentující načtená data:
XML datového načtených dat:
kontextu
po
O_0001 … … ….
C_0001 … … …. O_0001 … … ….
vnoření
Pro větší variabilitu práce s XML datovými balíčky můžeme umožnit v rámci jejich začleňování do XML datového kontextu jejich vnoření i na jiné než výchozí umístění ukázané na předchozím schématu (tzn. na jiné místo než jako nová větev rovnou pod kořenový uzel). Takové místo – tedy XML element, dovnitř kterého bude vnoření provedeno – můžeme určit XPath dotazem. Samozřejmě bude pak záležet na konkrétní situaci, zda takové chování bude mít rozumné opodstatnění nebo vnese do struktury XML datového kontextu spíše nepořádek.
31
Optimalizace chování datového kontextu Práce s velkými XML dokumenty může být náročná. Při zpracování složitějšího procesu uvnitř přenosového můstku může být zapotřebí načíst postupně velké množství dat z několika různých externích zdrojů. Načítání všech těchto dat dovnitř jednoho velkého XML datového kontextu by nemuselo být z výkonnostního hlediska výhodné. Ve spoustě případů budeme pravděpodobně moci vysledovat možnost dekompozice celého složitého přenosového procesu na několik fází, které mezi sebou sdílí jen ohraničenou množinu dat. Přenesme tedy tuto dekompozici i do vnímání datového kontextu. Místo jednoho velkého XML dokumentu můžeme umožnit definovat pole řádově menších XML dokumentů. Datový kontext pak nebude definován jako jeden XML dokument, ale jako pole několika XML dokumentů. Tímto můžeme omezit potenciální výkonnostní problémy – systém nebude muset udržovat a upravovat velké XML dokumenty. Proto, abychom toto rozdělení na více dokumentů mohli umožnit, musí mít každá operace pracující s datovým kontextem parametr určující, se kterým z XML dokumentů bude pracovat. Identifikace XML dokumentu v poli je nechána na konkrétní implementaci – může být buď číselným indexem v poli, nebo to může být případně pole asociativní a tedy se můžeme na jednotlivé dokumenty odkazovat nějakým více intuitivním názvem.
Parametry jednotlivých kroků / operací Struktura PROCESS_STEPS obsahuje pole Parameters s XML dokumentem pro uložení dodatečných informací definujících běh toho daného kroku procesu. U standardních typů operací (načítání, transformace, ukládání) je potřeba definovat základní schéma tohoto XML dokumentu s parametry tak, aby byl umožněn běh dané operace standardním způsobem a bylo také možné provést napojení na dříve popsané sběrnice umožňující zapojení programového kódu dodaného třetí stranou. U speciálního typu operace, jejíž náplň (programový kód, který se má spustit) je dán polem CustomClass, není nutné strukturu tohoto dokumentu nijak specifikovat. Konkrétní požadavky na data uložená uvnitř struktury pro speciální operace definuje až autor třídy nebo funkce, která tuto operaci reprezentuje.
Struktura Parameters – operace načítání dat Mezi základními parametry operace načítání dat musí nutně být identifikace „translatoru” zapojeného do sběrnice „translatorů”, který provede vlastní získání dat a jejich transformaci do XML. Systém pak při zpracování aktuálního kroku procesu vytvoří instanci tohoto „translatoru“ a předá mu řízení. 32
Translator ale rozhodně nemůže fungovat bez dodatečných informací. Cílem totiž je, aby třída nebo funkce reprezentující translator nebyla určena pouze pro jednorázové použití, ale fungovala co nejvíce obecně. Ukažme si to na příkladu translatoru získávajícího data ze SQL. Takový translator musí „z venku“ dostat v prvé řadě informace, k jakému SQL serveru a pomocí jakých přihlašovacích údajů se má připojit (a to ideálně pomocí odkazu do Centrálního úložiště datových zdrojů). Ihned v zápětí musí vědět jméno tabulky, ze které má data čerpat, nebo přímo SQL dotaz vracející požadovaná data. Mezi parametry načítání dat tedy musí být i nějaké pole dodatečných parametrů, které upravují fungování obecného translatoru. A nakonec další 2 parametry určují místo uložení dat v datovém kontextu. Jak bylo popsáno dříve, datový kontext se skládá z několika XML dokumentů. První parametr tedy musí určovat, do kterého z XML dokumentů kontextu budou načtená data uložena. Bylo také zmíněno, že data mohou být uložena na libovolné místo cílového XML dokumentu kontextu – druhým parametrem ohledně cíle uložení dat tedy bude XPath dotaz definující XML element, do které budou načtená data vloženy. Celé XML s parametry pro operaci načítání dat tedy definujme následovně: <Parameters>
... ... ... ... ...
V ukázce je znázorněno, že obsah elementu ReaderParameters je variabilní tak, aby bylo možné předat „translatoru“ potřebná dodatečná data.
Struktura Parameters – operace ukládání dat Operace ukládání dat je operací opačnou k operaci načítání dat. Pokud budeme brát v potaz již dříve zmíněný fakt o nutnosti u některých operací zpracovávat návratovou hodnotu, můžeme spíše říci, že operace ukládání dat je rozšířením operace načítání dat. Tomu tedy také budou odpovídat částečně identické parametry. Krok procesu ukládající data musí stejně jako v předchozím případě vědět název „translatoru“ (tentokrát takového, který data z kontextu ukládá do nějakého cíle dat). Dále musí být tomuto translatoru poskytnuté dodatečné informace upravující a definující jeho běh. Nakonec pak translator musí vědět, ze kterého XML dokumentu uvnitř datového 33
kontextu a z jaké jeho části má čerpat data a zároveň na jaké místo datového kontextu má uložit návratovou hodnotu.
Celé XML s parametry pro operaci ukládání dat tedy definujme následovně: <Parameters> <WriterClass>... <SourceDataContext>... <SourcePath>...
... ... <WriterParameters> ... ...
Na první pohled je patrné, že toto XML s parametry pro operaci ukládání dat je až na 2 dodatečné elementy prakticky totožné s předchozím XML s parametry pro načítání dat. Stejně jako v předchozím případě obsahuje také blíže nespecifikovanou část WriterParameters, která se odvíjí od požadavků konkrétního „translatoru“.
Struktura Parameters – operace transformace dat Poslední ze základních typů kroků procesu je operace transformace dat. Základem této transformace je technologie XSLT. Abychom mohli požadovanou transformaci provést, musíme parametricky tomuto kroku procesu říct, z jakého XML dokumentu uvnitř datového kontextu má čerpat data, jakou část tohoto dokumentu má zpracovat (toto můžeme opět definovat pomocí dotazu XPath). Následně musíme poskytnout vlastní předpis XSLT transformace. Výsledný XML dokument pak musíme opět někam uložit (tedy na nějaké konkrétní místo vymezené XPath dotazem do určitého XML dokumentu datového kontextu). Užitečnou funkcí transformace dat může být vyčištění cílového elementu pro uložení transformovaných dat před vlastním vložením do datového kontextu. Takto můžeme zabránit narůstání velikosti datového kontextu do velkých rozměrů – pomocí této funkce totiž můžeme nechat nahradit zdrojová data těmi transformovanými, pokud zdroj dat již pro další transformace nebude potřeba. Celé XML s parametry pro operaci transformace dat tedy definujme následovně:
34
<Parameters> <SourceDataContext>... <SourcePath>...
... ... ... <Xslt> ...
Rozšíření XSLT o možnost obecných transformací Již bylo uvedeno (v části Obecná transformace), že XSLT nabízí sice velké možnosti pro transformaci struktury XML dokumentů. Možnosti transformace jednotlivých hodnot ale nejsou velké a pro účely obecného propojení internetového obchodu s ekonomickým systémem nemusí být dostačující. Možnosti XSLT tedy rozšíříme o možnost obecně transformovat XML dokument ať už z hlediska struktury nebo dat uvnitř uložených. K tomuto účelu rozšiřme XML dokument vzniklý po XSL transformaci o dodatečné procesní instrukce realizující naše rozšířené transformace pomocí sběrnice transformačních funkcí nebo tříd. Tyto procesní instrukce se budou týkat vždy určité části XML dokumentu – určitého XML elementu. Takový element bude obsahovat speciální procesní element s potřebnými parametry této rozšířené transformace.
Příklad použití speciální transformace Data načtená z připojeného zdroje dat obsahují Jméno a Příjmení osoby, tyto informace ale obsahují v rámci jednoho pole. V cílovém systému, kam potřebujeme tyto data vložit, jsou ale Jméno a Příjmení jako oddělená pole. Potřebujeme tedy nějakým způsobem rozdělit XML element FullName (obsahující jméno a příjmení dohromady) na elementy FirstName a LastName obsahující vždy jednu část jména. Zdrojová a požadovaná cílová data ukazují následující XML dokumenty: XML znázorňující načtená data:
XML znázorňující požadovaná cílová data:
… Jan Novák …
… Jan Novák …
35
Do našeho XML dokumentu si tedy k elementu nadřazeného elementu FullName doplníme procesní instrukce zajišťující volání speciální transformace s náležitými parametry, která provede rozdělení elementu FullName na požadované 2 části. Toto doplnění procesní instrukce můžeme provést buď poslední předcházející XSL transformací nebo samostatným transformačním krokem. Následující XML ukazuje zdrojová data doplněná o procesní instrukce:
<_CustomTransforms> <_CustomTrasnform> FullNameSplit FullName FirstName LastName … Jan Novák …
Speciální transformace v představeném příkladu se týká obsahu uvnitř elementu DataPackage. To, že na obsah tohoto elementu je nutné provést speciální transformace, systém pozná podle elementu _CustomTrasnforms. Tento procesní element obsahuje informace pro jednotlivé kroky transformace uvnitř jednotlivých elementů _CustomTransform. Těchto speciálních transformací aplikovaných na jednu část našeho XML může být libovolný počet. Každá speciální transformace je určena třídou nebo funkcí připojenou na sběrnici těchto speciálních transformací – viz element TransformClass. V tomto případě má na starosti transformaci transformační třída FullNameSplit. Stejně jako v dříve popsaných sběrnicích a operacích je možné i v tomto případě upravovat chování speciální transformace pomocí sady parametrů – v tomto případě jsou to 3 parametry FullNameElement, FirstNameElement, LastNameElement. V tomto konkrétním případě při rozdělování celého jména na jméno a příjmení určují tyto parametry názvy elementů, kde má transformační třída hledat vstupní data a kam má uložit data výstupní. Postup zpracování speciálních transformací Nyní definujme, jaký je postup provádění speciálních transformací: 1. Provede se standardní XSL transformace definovaná v seznamu kroků procesu 36
2. Pomocí XPath dotazu se výsledek prohledá na existenci elementu _CustomTransforms 3. Pokud takový element existuje, tak se v cyklu prochází jednotlivé podelementy _CustomTransform a volá se třída nebo funkce určená hodnotou elementu TransformClass. 4. Po provedení všech definovaných transformací dojde ke zrušení hlavního procesního elementu _CustomTransforms tak, aby při příštím kroku procesu nebyly prováděny všechny tyto speciální transformace znovu.
37
5. Návrh objektového modelu systému Objektový model univerzálního systému popsaného v základních rysech v předcházejících částech můžeme pomyslně rozdělit na 2 skupiny tříd. V první skupině se bude jednat o podpůrné třídy pro evidenci procesů, jejich kroků, historie a podobně. Obsahem druhé skupiny pak bude hierarchie tříd, které reprezentující jednotlivé prováděné operace procesů.
5.1. Proces, krok procesu V popisu základních struktur systému byly představeny základní pojmy jako Proces, Krok procesu a Historie procesů. Dále pak podpůrné struktury pro evidenci datových zdrojů a pro ukládání aktuálního datového kontextu. Z těchto pojmů a struktur vyjdeme při návrhu potřebného objektového modelu. Základní třídou v centru objektového modelu bude třída Process. Instance této třídy bude reprezentovat konkrétní instanci procesu propojení mezi dvěma a více systémy – tedy v rámci životního cyklu instance této třídy bude provedeno načtení všech potřebných informací o procesu a jeho krocích a tento proces bude spuštěn. Zároveň bude mít tato třída na starosti aktualizaci a značení průběhu do historie procesů. Třída také zajistí vytvoření a přístup k datovému kontextu dostupnému instanci tohoto procesu. Data o jednotlivých krocích procesu nebudou pro snadnější manipulaci načteny a udržovány přímo v polích třídy Process, ale tato třída (resp. její instance) bude obsahovat seznam odkazů na instance třídy ProcessStep. Instance třídy ProcessStep pak již sama zajistí načtení informací o jednotlivých krocích. Mezi těmito dvěma třídami bude probíhat určitá kooperace i během samotného běhu procesu, kdy třída Process zajistí iniciaci procesu, následně bude v cyklu předávat řízení jednotlivým instancím ProcessStep obsažené v seznamu kroků. ProcessStep zajistí vždy spuštění toho konkrétního kroku. Po spuštění všech kroků procesu opět přímo třída Process zajistí dokončení celého procesu. Následující 2 úryvky kódu ukazují popsané vazby v praxi. Pro demonstraci byl použit jazyk C# a to vzhledem k tomu, že je tento jazyk použit také pro ukázky implementace představeného modelu (frameworku), jež jsou umístěny na přiloženém CD. Mimo to je to jeden z aktuálně nejhojněji používaných moderních objektově orientovaných jazyků. Úryvky kódů (ty bezprostředně následující, ale i ty pozdější) nejsou kvůli omezenému místu úplným zkompilovatelným kódem tak, aby je bylo možné přímo bez úprav použít. Jedná se jen o základní kostru jednotlivých tříd a zahrnují jen to zajímavé – to, co demonstruje a upřesňuje právě popsané myšlenky.
38
Základní kostra třídy Process by měla vypadat následovně: class Process { // ... elementy obsahující načtená data o procesu // pole kroků procesů private List
processSteps; public ProcessStep Step(int Index) { get { return processSteps[Index]; } } // přístup k datovému kontextu a skladu datových zdrojů private DataContextStorage dataContext; public DataContextStorage DataContext { get { return dataContext; } } public DataSourcesStorage DataSources { get { return DataSourcesStorage.GetInstance(); } } public Process(int ID) { // ... načtení dat o procesu // instanciace jednotlivých kroků procesu foreach (... in ...) { processSteps.Add(new ProcessStep(StepRow, this)); } // založení datového kontextu dataContext = new DataContextStorage(); } public bool Run() { // ... iniciace běhu procesu // volání jednotlivých kroků foreach (ProcessStep step in processSteps) { ... if (!step.Run(PID)) { break; ... } ... } // ... dokončení a uklizení po běhu procesu } }
39
Základní kostra třídy ProcessStep by měla vypadat následovně: class ProcessStep { private Process parent; // ... elementy obsahující načtená data o kroku procesu // mimo jiné přístup k XML s parametry kroku private XmlDocument parameters; public string Parameter(string XPath) { ... } public DataContextStorage DataContext { get { return Parent.DataContext; } } public DataSourcesStorage DataSources { get { return Parent.DataSources; } } public ProcessStep(DataRow Row, Process Parent) { parent = Parent; // ... načtení dat o procesu } public bool Run(Guid PID) { // ... iniciace běhu kroku // ... instanciace a běh operace, // která krok reprezentuje // ... dokončení a uklizení } }
Vazby mezi jednotlivými třídami rekapituluje následující schéma. Jednotlivé čáry mezi třídami znázorňují v tomto případě odkaz (ukazatel) z jedné třídy na druhou.
Obrázek 6: Vazby mezi objekty procesu
40
5.2. Sběrnice a operace Pro implementaci sběrnice „translatorů“ a tříd pro speciální transformace je užitečné využít výhod objektově orientovaného programování, pokud takovou techniku použitá implementační platforma umožňuje. Vhodné vztahy dědičnosti pro implementací jednotlivých tříd znázorňuje následující obrázek:
Obrázek 7: Vazby dědičnosti v objektovém návrhu
Hlavní myšlenkou je využít 3-úrovňového modelu. V každé takové úrovni jsou zahrnuty veškeré funkcionality pro třídy, které jsou přímo nebo nepřímo zděděné. Na vrcholu objektového modelu je třída označená jako Basic Operation. Ta zastřešuje společnou funkcionalitu využitelnou pro libovolný typ operace – konkrétně se jedná o přístup ke struktuře reprezentující krok procesu, který operaci volá, a prostřednictvím něj pak dále k parametrům tohoto kroku, datovému kontextu a k centrálnímu úložišti datových zdrojů.
41
Třída také definuje metodu Proceed, která u potomků má na starosti provedení požadované operace. U základní třídy je metoda Proceed pouze abstraktní, protože základní třída nepředstavuje žádnou konkrétní akci. Základní kostra třídy Basic Operation by měla vypadat následovně: class BasicOperation { ... protected ProcessStep Caller; protected string Parameter(string XPath) { return Caller.Parameter(XPath); } protected DataContextStorage DataContext; protected DataSourcesStorage DataSource; public abstract bool Proceed(); ... }
Od základní třídy jsou odvozené třídy pro jednotlivé základní typy operací představené a popsané v předchozích částech. Jedná se o operaci pro načítání dat, operaci pro ukládání dat a také operaci pro jejich transformaci. Každá z těchto typů operací pracuje podle popsaného základního modelu a pouze určitá část funkcionality je variabilní. Na zvážení je, zda vzhledem ke značné podobnosti operací načítání a ukládání dat je vhodné pro tyto 2 typy operací mít 2 oddělené třídy či jednu společnou, jejíž chování bude ovlivňováno konkrétními parametry. Z důvodu zamezení zbytečnému opakování programového kódu (ať už v obecných třídách pro tyto operace tak ve třídách implementující napojení určitou technologií) se jeví jako výhodnější mít pouze jednoho předka a na operace načítání a ukládání dat se dívat jako na operaci jednoho typu. Tuto operaci budeme nazývat operace načítání/ukládání (Read/Write operation). Operace Read/Write bude fungovat následujícím způsobem: 1) Pokud je operace nastavena tak, že pracuje s již dříve načtenými daty, pak zpřístupní tato data kódu operace a následující kroky provede vždy pro každý element ze zpřístupněných dat – obdoba for-each cyklu (tato funkce je obecná a tedy implementovaná ve společném předkovi – tedy ve třídě ReadWriteOperation). 2) Konkrétní implementace operace načítání/ukládání se následně připojí k datovému zdroji a zpřístupněná data přeloží do formátu a jazyka, kterému datový zdroj rozumí. Následně s použitím těchto dat provede v datovém zdroji nějakou akci (která buď zapíše do datového zdroje nějaká data nebo třeba jen nějaká data získá) – tato část operace je implementovaná až v rámci
42
implementace „ušité“ na míru konkrétnímu datovému zdroji, např. v SqlReadWriteOperation. 3) Pokud operace vrací nějakou návratovou hodnotu, pak konkrétní implementace (např. SqlReadWriteOperation) provede přeložení těchto vrácených dat do formátu XML. 4) Obecná implementace operace načítání/ukládání provede začlenění získaných a do XML přeložených dat na definované místo datového kontextu. Podobným způsobem lze izolovat v kódu společnou a variabilní část u operace transformace dat. V návrhu je umožněna implementace i úplně specifických akcí nezapadajících ani do jedné ze základních kategorií.
Read/Write Operation U operace načítání/ukládání dat je tedy variabilní částí sestavení požadavku na datový zdroj (je možné i s použitím již dříve načtených dat), provedení tohoto požadavku, načtení návratové hodnoty z externího zdroje a způsob její transformace do XML – toto se liší vždy případ od případu pro různé zdroje dat. Jakmile máme jednou k dispozici XML dokument reprezentující načtená data, následuje jeho začlenění do datového kontextu, které je ale vždy již zcela identické a nezávislé na zdroji dat. Výhodné je také zpřístupnit jednotlivé parametry operace načítání/ukládání dat – konkrétně se jedná o TargetDataContext, TargetPath, SourceDataContext a SourcePath a dále o parametry definované v poduzlu Parameters. Zděděná třída ReadWriteOperation by měla rozšiřovat základní BasicOperation následovně: Základní kostra třídy ReadWrite Operation by měla vypadat následovně: public class ReadWriteOperation : BasicOperation { ... protected string TargetDataContext { get { return Parameter("TargetDataContext"); } } protected string TargetPath { get { return Parameter("TargetPath"); } } protected string SourceDataContext { get { return Parameter("SourceDataContext"); } } protected string SourcePath { get { return Parameter("SourcePath"); } } protected string Parameter(string XPath) ( return Parameter("Parameters/" + XPath); } public bool Proceed() { if (SourceDataContext == "") { // NEPOUZIVA JIZ NACTENA DATA
43
Result = SetGetData(null); if (Result != null) // ... ZACLENENI NAVRATOVE HODNOTY } else // ... POUZIVAME DRIVE NACTENA DATA ... foreach (XmlNode Data in ....) { // PRO KAZDY ELEMENT VYBRANYCH DAT Result = SetGetData(Data) if (Result != null) // ... ZACLENENI NAVRATOVE HODNOTY } } return true; } protected abstract XmlDocument SetGetData(XmlNode Data); }
Metoda Proceed představuje společnou část funkcionality a zároveň tak implementuje abstraktní metodu definovanou u BasicOperation. Pro komunikaci s externím datovým zdrojem slouží nově definovaná abstraktní metoda SetGetData – abstraktní je tato metoda proto, že u ReadWriteOperation nemá svůj vlastní význam, ReadWriteOperation žádná data ve skutečnosti nenačítá. Tato metoda je tedy implementována až u potomků (například SqlReadWriteOperation).
Rozdíl v použití ReadWriteOperation pro načítání a ukládání dat Protože třída ReadWriteOperation zastupuje jak operaci načítání tak ukládání dat, je vhodné si ujasnit, jakým způsobem se bude její základní fungování používat v obou těchto případech: a) načítání dat - v případě načítání dat se ve většině případů bude tato operace používat bez vyplněného zdrojového datového kontextu (SourceDataContext a SourcePath). Konkrétní třída tedy naimplementuje metodu SetGetData tak, aby získala konkrétní data z datového zdroje a provedla jejich přeložení do XML, které je následně obecným fungováním ReadWriteOperation začleněno do datového kontextu aktuálního procesu. Nastavení zdrojového datového kontextu je možné ale použít v případě, kdy proces získávání dat bude potřeba parametrizovat již dřívějšími daty (například v jednom kroku budou ze zdroje dat získány hlavičky nových objednávek, ale v dalším kroku chci k těmto hlavičkám načíst ještě nějaké doplňující informace a toto načtení chci provést pro každou z dříve načtených objednávek). b) ukládání dat - v tomto případě bude naopak v naprosté většině případů informace o zdrojovém datovém kontextu vyplněná - a bude specifikovat data, která chci do datového zdroje uložit. XPath dotaz definovaný v
44
SourcePath může vracet kolekci XML uzlů, čímž mohu v rámci jednoho volání této operace provést uložení několika záznamů v cyklu. Každé uložení může zpět do systému vrátit nějaká návratová data (například ID, který nový záznam dostal přiřazené). Pokud nějaká návratová hodnota existuje, pak je možné ji začlenit do datového kontextu a pracovat s ní v dalších krocích.
Rozšíření XSLT a Transform Operation V případě třetího typu operace – transformace dat – je situace o něco komplikovanější. Tato operace se skládá ze dvou kroků. Nejdříve je provedena XSL transformace podle XSLT předpisu uloženého v parametrech daného kroku. Následně je výsledný XML dokument prohledáván na speciální procesní elementy <_CustomTransforms>. Pro každý takový element se provede doplňující transformace popsaná daty uloženými uvnitř tohoto procesního elementu. V tomto případě se tedy uplatní hned 2 třídy.
XsltTransformOperation Tato třída zastřešuje celou operaci transformace dat. Nejdříve provede vlastní XSLT transformaci. Následně dohledá procesní elementy _CustomTransforms a pro každý procesní element instanciuje požadovaného potomka třídy TransformOperation. Třída je stejně jako ReadOperation a WriteOperation (resp. ReadWriteOperation) odvozená od BasicOpeation. Oproti těmto třídám ale již nemá žádné další potomky, protože funkčnost této operace je vždy stejná. Rozmanitost implementovaných operací je řešena až voláním různých potomků třídy TransformOperation. XsltTransformOperation také stejným způsobem, jako základní třídy pro ostatní typy operací, zpřístupňuje používané parametry, jejichž hodnoty jsou nastavené v definici kroků procesu – v tomto případě jsou to parametry říkající, která data z datového kontextu do transformace vstupují, kam a jakým způsobem se výstup uloží a s použitím jakého předpisu XSLT se data transformují. Základní kostra třídy Xslt Transform Operation by měla vypadat následovně: public class XsltTransformOperation : BasicOperation { ... protected string SourceDataContext ... protected string SourcePath ... protected string TargetDataContext ... protected string TargetPath ... protected string ClearTargetFirst ... protected string Xslt ...
45
public bool Proceed() { // ... ZISKANI DAT Z KONTEXTU ... // ... PROVEDENI XSLT // ... ROZSIRENA TRANSFORMACE while (.........) { // INSTANCIACE PRISLUSNE TRIDY // CustomTrasnform/CustomTrasnform } // ... ZAPSANI/NAHRAZENI DAT V KONTEXTU return true; } }
TransformOperation Tato třída reprezentuje jednu konkrétní rozšířenou transformaci prováděnou nad rámec základní XSLT. Nejedná se o jeden ze základních 3 typů operací (Read, Write, Transform), ale pouze o dílčí operaci spadající pod XsltTransformOperation. Z tohoto důvodu logicky tato třída není odvozena od BasicOperation, ale stojí mimo hlavní hierarchii tříd operací. Některé principy použité u BasicOperation a jeho potomků jsou ale aplikovány i v tomto případě. Konkrétně se jedná o rozdělení kódu na společnou část všech transformačním operací a variabilní část dle fungování konkrétní operace. V té základní společné části se jedná hlavně o zprostředkování reference na parametry speciální operace. Mezi další funkce základní části patří odstranění elementu _CustomTransform po provedení transformace. Pokud se jednalo o poslední element, pak je odebrán i samotný element _CustomTransforms.
Základní kostra třídy Transform Operation by měla vypadat následovně: public class TransformOperation { protected XsltTransformOperation caller; protected XmlNode node; protected string Parameter(string XPath) { ... } public virtual bool Proceed() { // ... Odebrani _CustomTransform // ... Pokud posledni pak odebrani _CustomTransforms } }
46
6. Několik příkladů implementace operací V této kapitole bude s použitím objektového modelu popsaného v předchozí kapitole (hlavně tříd týkajících se jednotlivých operací) představeno několik ukázkových implementací operací realizujících načítání či ukládání dat s použitím různých technologií. Konkrétně se bude jednat o pravděpodobně nejčastěji využívanou komunikaci pomocí přímého propojení na databázi (a to ať už databázi internetového obchodu nebo databázi ekonomického (externího) systému). V další části bude představena ukázková implementace s použitím velmi rozšířené technologie webových služeb. Nakonec kapitoly pak bude ještě předvedena implementace operací s použitím technologie postavené na výměně datových balíčku – Microsoft Message Queues.
6.1. Propojení na databázi - SqlReadWriteOperation Propojení přímo na databázi je velmi jednoduché pro ukázku základních postupů při implementaci operací načítání/ukládání dat. Zároveň je velmi užitečné, protože u některých systémů je přistupování přímo na databázi bohužel jediný možný prostředek, jak s nimi komunikovat. Snad každý ekonomický systém nebo systém internetového obchodu svá data v nějaké databázi uložená má a pokud neexistuje jiný komunikační kanál, většinou nic nebrání tuto databázi přenosovému můstku zpřístupnit. Zároveň v rámci komunikace s databází není nutné řešit nějaká implementační specifika. V dnes existujících programátorských nástrojích již existují různé obecné technologie, pomocí nichž je možné se připojit k různým databázovým strojům bez nutnosti psát pro každý z nich nějaký specifický programový kód (technologie ADO.NET, ODBC, JDBC a další). Vzhledem k ukázkové implementaci frameworku s použitím jazyka C# bude následující ukázka SqlReadWriteOperation předpokládat využít technologie ADO.NET. Pro samotné připojení k datovému zdroji nám tedy bude stačit získat tzv. Connection String, který si můžeme přečíst vždy z centrálního úložiště datových zdrojů (viz součást modelu napojení popsaného v kapitole 4). Nyní si popišme, jakým způsobem by měla SqlReadWriteOperation rozšiřovat třídu ReadWriteOperation popsanou v předchozí kapitole. Třída ReadWriteOperation definuje jednu abstraktní metodu "SetGetData", která volitelně přebírá jeden parametr Data, který v případě nutnosti využít pro komunikaci s externím zdrojem již dříve načtená data ukazuje do datového kontextu na tato požadovaná data. Tato metoda by měla volitelně vracet návratovou hodnotu provedené komunikace s externím datovým zdrojem převedenou do formátu XML tak, aby bylo možné návratovou hodnotu přímo začlenit do datového zdroje.
47
Protože chceme, aby třída SqlReadWriteOperation byla obecná a nikoliv použitelná pro jeden konkrétní dotaz do databáze, budeme chtít její chování parametrizovat. To je možné prostřednictvím definovatelných parametrů každé ReadWriteOperation (viz XML element <Parameters> obsahující libovolně strukturované parametry přístupné pomocí metody Parameter definované ve třdídě ReadWriteOperation). Jaké parametry budeme pro běh této operace potřebovat popisují následující odstavce. Uvnitř metody pravděpodobně budeme provádět postupně 2 SQL dotazy. První dotaz provede zapsání změn do datového zdroje a druhý získá návratovou hodnotu. Pokud dané použití této operace má sloužit jen k načtení dat, pak první dotaz prováděn nebude. Naopak pokud nás nezajímá návratová hodnota, pak nevyužijeme druhý dotaz. SQL dotazy mohou obecně využívat parametry. Používání SQL parametrů v dotazech zajistí správné předávání hodnot ve správném formátu a zároveň chrání proti bezpečnostním rizikům typu SQL Injection. Je tedy vhodné, aby operace SqlReadWriteOperation podporovala i předávání parametrů do SQL dotazů. Hodnoty SQL parametrů můžeme chtít určovat následujícími způsoby: a) libovolná konstanta - výhodou použití tohoto typu parametru je jen případné zjednodušení a zpřehlednění SQL dotazu b) odkaz na libovolnou hodnotu v datovém kontextu aktuálního procesu c) odkaz na hodnotu v datech předaných do metody SetGetData Pro účely SqlReadWriteOperation můžeme tedy element <Parameters> vyžít například takto: Obecné parametry pro účely SqlReadWriteOperation <Parameters> <SetDataSQL>... <SetDataParams> Param1;Param2;Param3
<Param1 SourceType="..." SourceValue="..." DataType="..."/> <Param2 SourceType="..." SourceValue="..." DataType="..."/> <Param3 SourceType="..." SourceValue="..." DataType="..."/> ...
48
Následuje popis jednotlivých elementů: -
-
-
-
-
SetDataSQL obsahuje SQL dotaz, který má za úkol zapsat data do datového zdroje SetDataParams obsahuje parametry pro použití v SetDataSQL SetDataParams\List obsahuje seznam parametrů oddělených středníkem, každý z těchto parametrů má pak vedle elementu List vlastní element (viz Param1 až Param3 v příkladu) atribut SourceType definuje typ zdroje, odkud operace načte hodnotu tohoto SQL parametru (viz výše - konstanta, odkaz do datového kontextu, odkaz do dat předaných do metody SetGetData) atribut SourceValue obsahuje buď přímo konstantu předanou jako parametr nebo XPath dotaz vracející hodnotu, která se má jako parametr předat atribut DataType protože XML obsahuje všechna data v textové reprezentaci, je nutné definovat jakého datového typu hodnotu parametru je (string, int, DateTime, a podobně). GetDataSQL, GetDataParams obdoba elementů SetDataSQL a SetDataParams. Tyto elementy definují druhý dotaz, který slouží pro získání návratové hodnoty
Příklad: Načtení zboží aktualizovaného od posledního spuštění procesu Krok 1) Z databáze internetového obchodu se přečte pomocí SqlReadWriteOperation poznačená časová značka poslední zpracované změny položky: GetDataSQL = SELECT LastUpdatedItemTime FROM Shop_Settings Získaná hodnota se uloží do datového kontextu aktuálního procesu Krok 2) Z databáze ekonomického systému se načte datum nejčerstvější aktualizace položky: GetDataSQL = SELECT MAX(Updated) FROM ERP_Items Získaná hodnota se opět uloží do datového kontextu aktuálního procesu Krok 3) Z databáze ekonomického systému se s použitím obou dříve načtených hodnot zjistí seznam aktualizovaných položek, např:
49
GetDataSQL = SELECT * FROM ERP_Items WHERE Updated > @UpdatedFrom AND Updated <= @UpdatedTo Parametry UpdatedFrom a UpdateTo jsou definované tak, že ukazují do datového kontextu na dříve načtené hodnoty z obou systémů Krok 4) Zapsání aktualizovaných položek do databáze internetového obchodu: SetDataSQL = UPDATE Shop_Items SET Title = @Title, Price = @Price ... WHERE Code = @Code IF @@ROWCOUNT = 0 INSERT INTO Shop_Items (Title, Price, Code, ....) VALUES (@Title, @Price, @Code, ...) Tento krok má definovaný zdrojový datový kontext odkazující na načtené informace o jednotlivých položkách - výše uvedený dotaz se tak v cyklu provádí pro každou načtenou položku. Parametry Title, Price, Code a další odkazují na načtené hodnoty z externího systému - viz možnost "c) odkaz na hodnotu v datech předaných do metody SetGetData" popsaná výše. Krok 5) Uložení nové značky definující poslední aktualizovanou položku do databáze eshopu. SetDataSQL = UPDATE Shop_Settings SET LastUpdatedItemTime = @Value Parametr Value odkazuje na stejný zdroj dat jako v případě parametru UpdatedTo v kroku 3.
6.2. Propojení pomocí web služby - WSReadWriteOperation Technologie webových služeb slouží pro vzdálenou komunikaci mezi různými systémy nejčastěji přes prostředí Internetu. Pomocí této technologie je možné na vzdáleném systému vyvolat určitou funkci či metodu, té předat libovolná data a získat návratovou hodnotu. Jako návratová hodnota metod webových služeb může být dokonce i složitější struktura. Technologii webových služeb je tedy možné snadno využít pro komunikaci internetového obchodu a externího systému. Externí systém může v rámci svého aplikačního serveru zpřístupňovat některé jeho metody právě prostřednictvím technolgoie WS. Jako příklad těchto metod mohou být například metody pro: -
získání seznamu skladových položek zapsání informací o nové objednávce a další
50
Abychom mohli volat webovou službu, potřebujeme její adresu - respektive adresu na její tzv. WSDL dokument, který o webové službě obsahuje veškeré informace její adresu, seznam metod, které WS nabízí, seznam parametrů těchto metod a datových typů těchto parametrů. Způsob předávání dat mezi volajícím a webovou službou může probíhat různým způsobem - data do metody WS mohou být předaná jako oddělené parametry nebo formou struktury nebo v rámci jednoho parametru jako XML dokument. Obdobně může být předávána návratová hodnota - formou struktury či jako XML dokument. Parametry operace WSReadWriteOperation tedy můžeme definovat následovně: Obecné parametry pro účely WSReadWriteOperation <Parameters> ... <Method>... ... Param1;Param2;Param3
<Param1 SourceType="..." SourceValue="..." DataType="..."/> <Param2 SourceType="..." SourceValue="..." DataType="..."/> <Param3 SourceType="..." SourceValue="..." DataType="..."/> ...
Význam jednotlivých parametrů je následující: - URL HTTP adresa k WSDL dokumentu webové služby - Method Název metody WS, která se má zavolat - InputParamsEncoding Způsob kódování vstupních parametrů: a) parametry se předávají klasicky jako parametry běžné metody b) parametry se předávají jako 1 parametr formou složitější struktury c) parametry se předají kódované jako XML dokument - InputParams Seznam vstupních parametrů a jejich navázání na konkrétní data v datovém kontextu aktuálního procesu. Význam jednotlivých podelementů a atributů je totožný jako v případě popisu operace SQLReadWriteOperation Navíc bude umožněno poslat jako parametr celý XML fragment definovaný XPath dotazem (uloženým v atributu SourceValue). - OutputParamsEncoding Způsob kódování návratové hodnoty:
51
a) návratová hodnota se předává jako 1 parametr formou složitější struktury b) návratová hodnota se předá kódovaná jako XML dokument V rámci implementace operace WSReadWriteOperation opět dojde k implementaci jediné abstraktní metody SetGetData. V rámci této metody se nejdříve získá a rozparsuje WSDL dokument webové služby dle zadané URL adresy v parametrech operace. Následně se sestaví sada vstupních parametrů podle popisu parametrů uvnitř elementu InputParams a provede se předání parametrů dle požadovaného kódování metodě WS. Návratová hodnota se opět upraví do požadovaného formátu a takto získaná data se začlení do datového kontextu.
Příklad: Vložení nových objednávek z internetového obchodu do IS Krok 1) Z databáze internetového obchodu se pomocí SqlReadWriteOperation načte do datového kontextu seznam nových objednávek, např: GetDataSQL = SELECT * FROM Shop_Orders WHERE Transfered = 0
Krok 2) Z databáze internetového obchodu se načtou stejným způsobem řádky objednávek: GetDataSQL = SELECT * FROM Shop_OrderLines WHERE IDOrder IN (SELECT IDOrder FROM Shop_Orders WHERE Transfered = 0)
Krok 3) Provede se XSLT transformace uvnitř datového kontextu - spojí se informace o hlavičkách objednávek a řádcích objednávek do jednoho XML dokumentu. Krok 4) Zavolá se operace WSReadWriteOperation. SourceDataContext a SourcePath bude vracet seznam uzlů reprezentující jednotlivé objednávky - metoda SetGetData operace se bude tedy volat pro každou objednávku odděleně. Vstupní parametr může být definován například tak, že se webové službě předá celé XML reprezentující objednávku včetně řádků (tedy výsledek transformace popsané v kroku 3). Krok 5) Návratová hodnota metody WS je ID objednávky dle reprezentace externího systému. Toto ID je začleněno do zpracovávané části datového kontextu (viz data odkazovaná pomocí SourceDataContext a SourcePath v kroku 4). 52
Krok 6) Na stejná data provedeme SqlReadWriteOperation s nastavením: SetDataSQL = UPDATE Shop_Orders SET Transfered = 0, TransferID = @TransferID WHERE IDOrder = @IDOrder Parametr TransferID se nadefinuje jako odkaz v rámci aktuálně zpracovávaného datového balíčku (viz parametr metody SetGetData) na uloženou návratovou hodnotu v kroku 5. Parametr IDOrder bude v datovém balíčku přenesený v rámci transformace popsané v bodě 3.
6.3. Propojení pomocí MSMQ - MSMQReadWriteOperation Technologie Microsoft Message Queues (MSMQ) je přímo určená pro vyměňování datových balíčků mezi různými systémy. Na určitém serveru může být definováno několik různých front, do kterých mohou různé systémy datové balíčky posílat a jiné systémy si naopak mohou z těchto front datové balíčky vybírat. Pro komunikaci obdobného typu jaká byla popsána ve 2 předchozích případech (zaslaní požadavku s možností zpracovat zpětnou odpověď) jsou potřeba 2 fronty zpráv - jedna pro zasílání požadavků na externí systém. Externí systém si příchozí zprávy vybírá, zpracovává a do druhé fronty vrací odpovědi. Tyto odpovědi mohou být svázané s původní zprávou pomocí tzv. Correlation ID - je tedy možné po odeslání zprávy ze systému vždy proces uspat do doby, než se zpátky vrátí zpráva s odpovědí a případnými dodatečnými informacemi (= návratovou hodnotou), které je nutné uložit do datového kontextu systému pro další zpracování. Pro komunikaci s frontami zpráv je nutné vědět jejich adresy. Obsah jednotlivých zpráv je pak čistě na dohodě 2 aplikací, které spolu komunikují. Z toho důvodu tedy není možné tak jako v předchozích případech navrhnout obecnou třídu pro komunikaci prostřednictvím technologie MSMQ, kterou by bylo možné použít při propojování libovolných aplikací. Pro ilustraci, jak by tato třída mohl fungovat si představme případ, kdy se do externího systému bude posílat XML dokument s daty předanými jako parametr metodě SetGetData. Rovněž i návratová zpráva s odpovědí by mohla obsahovat přímo XML dokument, který by bylo možné začlenit do datového kontextu procesu. Pokud bychom chtěli budoucím vývojářům tříd pro komunikaci pomocí MSMQ ještě více usnadnit práci, mohli bychom nadefinovat obecnou třídu pro MSMQ komunikaci, která by prováděla komunikaci s externím systémem z obecného hlediska, ale tvorbu zasílané zprávy a načítání přijaté odpovědi by ponechala na potomkovi, od této obecné třídy odvozeného. Obdobně jako u vztahu ReadWriteOperation a SQLReadWriteOperation by tohoto šlo docílit pomocí 53
abstraktní metody - konkrétně dvojice abstraktních metod, které by byly implementované až v konkrétní třídě s jasným definovaným formátem přenášených zpráv. Jedna z těchto abstraktních metod by měla za úkol z poskytnutých dat vytvořit zprávu pro odeslání technologií MSMQ. Druhá z dvojice abstraktních metod by naopak načetla přijatou odpověď a zrekonstruovala by z ní XML dokument obsahující data z odpovědi, který by bylo možné začlenit do datového kontextu běžícího procesu.
54
7. Komplexnější příklady propojení Úkolem této kapitoly je ukázat komplexnější realizaci propojení internetového obchodu s některými externími systémy s použitím operací načítání/ukládání představených v kapitole předchozí. Postupně bude demonstrován příklad napojení na systémy: 1. Altus Vario (http://www.vario.cz/) Jedná se o komplexní ekonomický systém pro malé a střední firmy vyvíjený českou společnosti Altus Software s.r.o., který nabízí kompletní agendu nutnou pro provozovatele internetových obchodů. Tento ekonomický systém využívá pro uložení dat databázi Microsoft SQL. U dřívějších verzí tohoto systému bylo napojení na databázi jedinou možnou cestou, jak se dostat k jeho datům. Novější verze již nabízí i alternativní a modernější způsob napojení pomocí webových služeb, ale pro demonstraci použití SQLReadWriteOperation bude příklad propojení s tímto systémem řešen přímým napojením na databázi.
2. Microsoft Dynamics Navision (http://www.microsoft.com/cze/dynamics/navision/default.mspx) Komplexní ekonomický systém cílený na střední až větší organizace od společnosti Microsoft. Tento systém nabízí různé možnosti propojení (např. přímým propojením na databázi, ale také s použitím technologie Microsoft Message Queues)
3. HP Tronic (http://www.hptronic.cz/) V tomto případě se nejedná přímo o ekonomický systém, ale B2B internetový obchod, který je často propojován s jinými internetový obchody prodávajícími koncovým zákazníkům. Výhodou takového propojení je automatická aktualizace nabídky B2C internetového obchodu a automatizovaná aktualizace cen a skladových dostupností z databáze společnosti HP Tronic. Systém poskytuje data prostřednictvím HTTP požadavků ve formátu XML. Postupy a metody napojení na zmíněné ekonomické systémy a B2B internetový obchod vychází z konzultací s jednotlivými společnostmi a rovněž i dřívějších zkušenosti autora této práce, který se přímo podílel na implementaci velkého množství propojovacích můstků s těmito a dalšími systémy.
55
Modelová databáze internetového obchodu tak jak je použita při ukázkách propojení vychází také z praktické zkušenosti autora práce s komerčním internetovým obchodem.
7.1. Struktura DB ukázkového internetového obchodu Detailní struktura databáze internetového obchodu tak jak s ní budou počítat následující ukázky propojení je obsažena na CD přiloženém k této diplomové práci. Na tomto místě zmiňuji jen přehled základních tabulek a vazeb mezi nimi pro snazší orientaci a přehled v následujícím textu. Mezi základní tabulky demonstračního internetového obchod tedy patří: -
tabulka Tree Zachycuje hierarchický produktový strom, do kterého jsou následně zařazené na internetovém obchodu prodávané produkty. Pro zjednodušení budeme uvažovat jen 1 produktový strom – rozlišení na několik produktových stromů by v praxi znamenalo jen přidání jednoho sloupečku, kterým by příslušnost k jednomu ze stromů byla určena. Mezi základní pole v této tabulce patří název, kód a odkaz na nadřazený uzel ve stromu.
-
tabulka Items Tato tabulka obsahuje seznam produktových karet prodávaných na internetovém obchodu. Základní informace, které budeme v této zjednodušené demonstrační databázi evidovat jsou: název, kód, popis, základní cena, sazba DPH, skladová dostupnost (ano/ne).
-
tabulka TreeItems Tabulka přiřazuje položky (produktové karty viz tabulka Items) do produktového stromu (viz tabulka Tree). Vzhledem k tomu, že jedna položka může být umístěna na několika místech produktového stromu, jedná se o vazbu N:N, a proto se bez vazební tabulky neobejdeme.
-
tabulka Customers Obsahuje seznam registrovaných zákazníků internetového obchodu. Mezi evidované údaje patří: Přihlašovací jméno a heslo zákazníka, fakturační a dodací adresa zákazníka, propojovací kód s externím systémem a informace, zda zákazník čeká na export do externího systému.
-
tabulka Orders Slouží pro evidenci hlaviček objednávek zaslaných uživateli internetového obchodu. Ke každé objednávce bude evidováno její číslo, datum a čas vložení, stav vyřízení, způsob dopravy a platby, fakturační a dodací údaje (údaje v tabulce Customers nám nepostačují, protože adresa se může pro 56
určitou objednávku lišit a objednávky může vkládat i neregistrovaný uživatel), celková částka objednávky a propojovací kód s externím systémem a informace, zda objednávka čeká na export do externího systému. -
tabulka OrderItems Jedna objednávka obsahuje obvykle několik položek. Pro jejich uložení tedy slouží tato tabulka. Ke každému řádku objednávky bude vložen název a kód položky, jednotková cena, množství, sazba DPH.
Tento výčet tabulek a údajů v těchto tabulkách samozřejmě není kompletní – tak jak bylo popsáno v úvodních částech této práce, tak internetové obchody jsou různorodé a často je možné je upravovat na míru potřebám konkrétních zákazníků. Není tedy možné zachytit a popsat jeden vždy platný model, podle kterého bude libovolný internetový obchod fungovat.
7.2. Procesy implementované v ukázkovém napojení V úvodu práce bylo zmíněno, že různé implementace propojovacího můstku mezi internetovým obchodem a externím systémem řeší různý rozsah propojení. Pro účely ukázkového napojení na zmíněné 3 systémy budeme uvažovat následující propojovací procesy: -
Přenos produktového stromu z externího systému do internetového obchodu – aktualizace tabulky Tree Přenos seznamu produktových karet z externího systému do internetového obchodu – aktualizace tabulky Items Aktualizace skladové dostupnosti v internetovém obchodu daty z externího systému – aktualizace hodnoty skladové dostupnosti v tabulce Items Přenos seznamu registrovaných zákazníků z internetového obchodu do externího systému – aktualizace dat podle tabulky Customers Přenos nových objednávek z internetového obchodu do externího systému – export nových záznamů z tabulky Orders a OrderItems Aktualizace stavu vyřízení objednávek podle externího systému – aktualizace hodnoty v tabulce Order
7.3. Ukázka propojení – Altus Vario Jak bylo předesláno již v úvodu této kapitoly, demonstrace propojení na ekonomický systém Altus Vario bude realizována pomocí přímého propojení na databázi tohoto ekonomického systému. Při přímém napojení na databázi externího systému je možné postupovat dvěma způsoby – přímými zásahy do hlavních tabulek ekonomického systému nebo vytvořením mezivrstvy, která odstíní hlavní databázi
57
externího systému od přímých zásahů do jejího obsahu ze strany internetového obchodu. Tato mezivrstva může být řešena formou tabulek s vytvořenými INSERT triggery (pro směr přenosů z eshopu do ERP systému) a formou pohledů na hlavní tabulky (pro opačný přenos). Toto řešení má ještě další výhodu, kterou je možná korekce drobných změn ve struktuře hlavních tabulek ekonomického systému při přechodu na novější verze ekonomického systému. Řešení jednotlivých přenosových procesů při napojení na Altus Vario by mohlo vypadat následovně:
Přenos produktového stromu z externího systému do internetového obchodu Systém Altus Vario eviduje produktový strom v tabulce Kategorie. V této tabulce jsou obsažené sloupce: - ID_kategorie – kód kategorie - Nadrizena_kategorie – odkaz na kód nadřazené kategorie - Kategorie – název kategorie Tyto sloupce přímo odpovídají dříve popsané reprezentaci produktového stromu v ukázkové databázi internetového obchodu. Stačí tedy nadefinovat pohled view_Kategorie v mezivrstvě vracející 1:1 obsah této tabulky Kategorie. Proces přenosu produktového stromu bude 4 krokový: 1. Načtení aktuální data na serveru internetového obchodu do datového kontextu přenosové procesu: SELECT getDate() 2. Načtení dat z databáze mezivrstvy napojené na DB Altus Varia pomocí SqlReadWriteOperation s dotazem (GetDataSQL): SELECT * FROM view_Kategorie Tento dotaz nepotřebuje k běhu žádné parametry a takto definovaná operace SqlReadWriteOperation naplní datový kontext přenosového procesu daty z tabulky Kategorie Altus Varia ve formátu XML. 3. Využití načtených dat pro aktualizaci tabulky Tree v databázi internetového obchodu – opět využijeme SqlReadWriteOperation s definovaným SourceDataContext a SourcePath tak, aby proces pracoval nad seznamem, XML uzlů reprezentujícím jednotlivé řádky tabulky načtené v bodě 1. SetDataSQL může vypadat v syntaxi MSSQL následovně: IF EXISTS (SELECT * FROM Tree WHERE Code = @Code) UPDATE Tree SET Title = @Title, 58
SuperCode = @SuperCode, Updated = getDate() WHERE Code = @Code ELSE INSERT INTO Tree (Code, Title, SuperCode, Updated) VALUES (@Code, @Title, @SuperCode, getDate()) Parametry @Code, @Title, @SuperCode budou odkazovat XPath dotazem na jednotlivé elementy obsahující postupně hodnoty ID_kategorie, Kategorie, Nadrizena_kategorie z původní databáze Altus Varia. 4. Provedení aktualizačního dotazu v databázi internetového obchodu, který zruší všechny neaktualizované řádky tabulky Tree: DELETE FROM Tree WHERE Updated < @Updated Tento popsaný proces zachycuje obecný postup, jakým docílíme k přenosu určité tabulky z ekonomického systému do internetového obchodu nebo naopak 1:1, což je při propojování internetového obchodu a externího systému velmi častý postup – často se mezi oběma systémy synchronizují různé číselníkové tabulky. Výše popsaný postup se nám může malinko zkomplikovat v případě, kdy databáze internetového obchodu neumožňuje poznačit k danému záznamu datum jeho poslední aktualizace. V takovém případě by bylo nutné založit pro tyto účely pomocnou tabulku, do které by byl poznačen každý aktualizovaný záznam a krok 4 by se lišil akorát tím, že by z tabulky Tree zrušil jen řádky, které nejsou obsažené v pomocné tabulce.
Přenos seznamu produktových karet z externího systému do internetového obchodu Postup přenosu produktových karet bude velmi podobný předchozímu postupu. V Altus Variu jsou produktové karty uložené v tabulce Katalog. Bude nutné provést ale drobné rozšíření vzhledem k tomu, že je nutné aktualizovat nejen tabulku Items v internetovém obchodě, ale také tabulku TreeItems, která obsahuje informaci o zařazení položky do produktového stromu. Postup se bude odlišovat v případě, kdy budeme chtít mít položky zařazené jen v jedné kategorii nebo více kategoriích. V prvním případě můžeme do pohledu v databázi mezivrstvy zahrnout i kód položky stromu kategorií, kam položka patří. Při vložení či aktualizaci záznamu v tabulce Items by pak bylo zároveň provedeno vložení či aktualizace záznamu v tabulce TreeItems. Druhý případ by byl malinko komplikovanější. Nejsnadnějším řešením by pravděpodobně bylo přenášet přiřazení položky do stromu kategorií v odděleném procesu, který by následoval ihned za přenosem aktualizujícím produkty 59
v internetovém obchodě. V případě, kdy by internetový obchod vyžadoval povinné zařazení každé položky do stromu kategorií, pak by mohla být do pohledu v mezivrstvě pro aktualizaci produktu vybrána libovolně jedna z kategorií, do které by položka byla vložena. Do dalších kategorií by byla položka zařazena vzápětí při samotné aktualizaci tabulky TreeItems. Kromě začlenění informace o zařazení položky ve stromu kategorií do pohledu mezivrstvy by bylo v tomto procesu nutné do tohoto pohledu zařadit i informaci o ceně položky a její skladové dostupnosti – v Altus Vario se jedná o vazbu na tabulky Cenik a Sklad. Co se týká skladové dostupnosti, mohl by nastat případ, kdy reprezentace této hodnoty v ekonomickém systému je odlišná od reprezentace na straně internetového obchodu. Tuto situaci je možné řešit několika způsoby: -
Transformací ve vstupním SQL dotazu nebo pohledu na straně Altus Varia Transformací na výstupním SQL dotazu (UPDATE a INSERT) na straně internetového obchodu Případnou složitější transformaci je možné provést pomocí speciálního typu operace přenosového procesu – Transform Operation (viz kapitola 5)
Aktualizace skladové dostupnosti v internetovém obchodu daty z externího systému Aktualizace skladové dostupnosti je zjednodušením předchozího procesu. Nad tabulkou Items v tomto procesu nebude prováděn INSERT ale pouze UPDATE tabulky Items a to konkrétně jen sloupce obsahujícího skladovou dostupnost daného zboží. Proces může čerpat ze stejných dat v Altus Variu, případně může být v rámci optimalizace vytvořen samostatný pohled obsahující pouze sloupečky kód položky a skladovou dostupnost.
Přenos seznamu registrovaných zákazníků z internetového obchodu do externího systému Pokud bychom i v tomto procesu chtěli odstínit data Altus Varia mezivrstvou, mohli bychom vytvořit speciální přenosovou tabulku (např. UpdateCustomers) na straně pomocné databáze Altus Varia. Nad touto tabulku bychom nadefinovali INSERT trigger, který by každou vloženou aktualizaci propagoval dále do hlavní tabulky Altus Varia. Celkový proces by byl velmi podobný těm předchozím, jen by byl otočený „naopak“. Postup by fungoval v následujících krocích: 1. Pomocí SqlReadWriteOperation by byla načtena data o nových a aktualizovaných zákaznících z databáze internetového obchodu: GetDataSQL = SELECT * FROM Customers WHERE NeedUpdate = 1
60
2. Pomocí SqlReadWriteOperation s definovaným zdrojem dat by byla data vložena do pomocné tabulky v mezivrstvě: SetDataSQL = INSERT INTO UpdateCustomers (InteropCode, Login, Password, …) VALUES (@InteropCode, @Login, @Password, ….) Parametr SetDataParams by stejně jako v předchozích procesech ukazoval na načtená data v kroku 1. Významná je hodnota parametru InteropCode, který reprezentuje propojovací kód s externím systémem (tedy identifikátor zákazníka v Altus Vario). Pokud se jedná o nového zákazníka, pak v databázi internetového obchodu propojovací kód ještě vyplněný není. Trigger v mezivrstvě podle tohoto faktu pozná, že se jedná o vložení nového zákazníka do databáze Altus Vario. Pokud byl již zákazník do Altus Varia dříve přenesen, pak je hodnota parametru vyplněná a programový kód triggeru provede aktualizaci existujícího záznamu o zákazníkovi. V tomto případě navíc může být nutné získat návratovou hodnotu s identifikátorem zákazníka v rámci Altus Varia (i když konkrétně v případě Altus Varia je možné volit identifikátor zákazníka libovolně a může je klidně tedy určit rovnou internetový obchod). Pokud by identifikátor zákazníka generoval až trigger na straně mezivrstvy v Altus Variu, pak v tomto triggeru by bylo nutné doplnit tuto vygenerovanou hodnotu do vloženého záznamu v tabulce UpdateCustomers. Načtení zpět do přenosového procesu by bylo řešeno pomocí GetDataSQL = SELECT Code FROM UpdateCustomers WHERE ID = (SELECT @@IDENTITY) (tedy získání hodnoty Code z posledního vloženého záznamu do tabulky UpdateCustomers)
3. Zbývá propagovat získaný identifikátor do databáze internetového obchodu a označit zákazníka jako aktualizovaného v Altus Variu. Tuto operaci je možné provést opět pomocí SqlReadWriteOperation, která bude pracovat na stejném zdrojovém kontextu jako v předchozím kroku. Cílová databáze by ale byla databáze internetového obchodu a příkaz, který by data aktualizoval by byl následující: SetDataSQL = UPDATE Customers SET NeedUpdate = 0, InteropCode = @Code WHERE ID = @ID Parametr @Code směřuje na načtenou a do datového kontextu doplněnou návratovou hodnotu v kroku 2, parametr @ID je v kroku 1 načtený identifikátor zákazníka v internetovém obchodu.
61
Přenos nových objednávek z internetového obchodu do externího systému Přenos nových objednávek z internetového obchodu do externího systému je o něco komplikovanější, protože každá objednávka je reprezentována jednak hlavičkou a jednak několika položkami (řádky objednávky). Přenos ale můžeme realizovat postupně – nejdříve můžeme přenést hlavičku a řádky ihned potom. V databázi programu Altus Vario jsou objednávky uložené v tabulkách Doklady a Polozky_dokladu. Stejně jako v případě přenosu zákazníků vytvoříme v mezivrstvě dvojici tabulek UpdateOrders a UpdateOrderItems, na kterých budou definované triggery mající za úkol propagaci dat do hlavních tabulek Altus Varia. Zjednodušený postup přenosového procesu objednávek bude následující: 1. Z databáze internetového obchodu systém načte seznam hlaviček objednávek čekajících na přenos do externího systému. 2. V dalším kroku systém načte řádky těchto načtených objednávek tak, aby v datové větě každého řádku bylo obsaženo i číslo (případně jiný identifikátor) objednávky. 3. Systém provede uložení hlaviček objednávek do pomocné databáze Altus Varia – do tabulky UpdateOrders. Mezivrstva v rámci triggeru zpropaguje hlavičky objednávek do hlavní databáze Varia. V tomto kroku si systém vyžádá (obdobně jako u přenosu zákazníků) – ve formě návratové hodnoty – identifikátor těchto nově vložených objednávek. 4. Následně je proveden přenos řádků objednávek – tedy jejich zápis do tabulky UpdateOrderItems. Pomoc identifikátoru objednávky načteného v kroku 2 je trigger v přenosové tabulce schopný spárovat řádek objednávky k její hlavičce. 5. Načtené identifikátory objednávek v kroku 3 jsou uloženy zpět do databáze internetového obchodu a zároveň jsou objednávky označeny jako přenesené. Aktualizace stavu vyřízení objednávek podle externího systému Poslední ukázkový proces se týká přenosu stavů objednávek z externího systému. Množina stavů, které daný provozovatel internetového obchodu rozlišuje a které je schopen pokrýt jím používaný ekonomický systém se liší případ od případu. V zásadě musí být ke každému sledovanému stavu definovaný předpis podmínky, která daný stav přestavuje. Podle konkrétní podoby této podmínky se bude lišit způsob implementace tohoto procesu. Pokud podmínka nebude extrémně složitá, bude pravděpodobně její vyhodnocení možné provést v rámci SQL dotazu, který se pak použije jako zdroj dat pro přenos stavů objednávek. V komplikovanějším 62
případě může být nutné nejdříve načíst větší množství dat do datového kontextu přenosového procesu a tyto data následně zpracovat buď pomocí speciální transformace nebo (pokud by ani speciální transformace neposkytovala potřebnou sílu) pomocí custom operace (tedy libovolného programového kódu začleněného do procesu přenosu stavů objednávek.
7.4. Ukázka propojení – Microsoft Dynamics Navision Pro ilustraci propojení se systémem Microsoft Dynamics Navision je vybrána technologie Microsoft Message Queues (MSMQ) jako příklad dalších možností univerzálního propojovacího systému. Pro práci se zprávami MSMQ mějme připravenou knihovnu s metodami: - SendRequestMessage – odešle XML dokument jako zprávu MSMQ do vybrané fronty a vrátí GUID odeslané zprávy - ReadResponseMessage – z definované fronty přečte odpověď na zprávu s určitým GUID. Odpověď je s původní zprávou svázána pomocí Correlation ID, kdy ID původní zprávy je vloženo do pole Correlation ID zprávy s odpovědí. Na straně aplikačního serveru programu Navision pak mějme připravený programový kód, který je schopný načítat požadavky z MSMQ fronty a dle obsahu požadavků odešle požadovaná data ve formátu XML do odpovědní fronty. Tento programový kód musí připravit implementátor programu Navision v dané firmě, se kterou je internetový obchod propojený. S implementátorem musí být nejdříve dohodnut formát a obsah předávaných zpráv. Pokud bychom se chtěli zainteresování další strany do implementace propojení vyhnout, bylo by možné přistupovat do databáze programu Navision napřímo tak jak bylo popsáno v předchozím příkladu. V tomto příkladu bude formát požadavku odeslaného do Navision následující: … V atributu Type bude obsažený identifikátor procesu jehož se požadavek reprezentovaný touto XML zprávou týká. Uvnitř elementu Request pak mohou být v případě potřeby umístěna další data. Formát odpovědi může být také jednoduchý, například:
63
... V parametrech operace MSMQReadWriteOperation bude definováno jednak označení typu požadavku, které se má použít jako hodnota atributu Type a rovněž zdroj dat a cíl dat v rámci datového kontextu procesu, odkud se mají čerpat a kam se mají vkládat data odeslaná/získaná v rámci komunikace MSMQ. Jaká data budeme odesílat a přijímat v rámci jednotlivých ukázkových procesů zachycuje následující přehled. Ve většině případů budou data obdobná jako při načítání dat přímým přístupem do databáze (viz příklad napojení na Altus Vario), navíc operace MSMQReadWriteOperation nebude muset převádět data do formátu XML, protože data v tomto formátu již budou přímo obsahem MSMQ zprávy s odpovědí.
Přenos produktového stromu z externího systému do internetového obchodu V tomto případě se přenáší data pouze směrem z Navisionu do internetového obchodu – operace tedy nebude mít definovaný žádný zdroj dat. Kód na straně Microsoft Navisionu zašle MSMQ zprávu, která bude obsahovat záznamy o jednotlivých položkám stromu produktů. Data mohou být reprezentována různě strukturovaným XML dokumentem (např. jednotlivé položky mohou být v XML za sebou na stejné úrovni nebo může struktura XML kopírovat stromovou strukturu přenášeného stromu produktů). Po načtení dat z MSMQ zprávy do datového kontextu získáme data pro uložení do internetového obchodu buď s pomocí vhodné XSLT transformace nebo v některých případech i jednodušeji vhodným XPath dotazem nad XML dokumentem vráceným v odpovědní zprávě MSMQ.
Přenos seznamu produktových karet z externího systému do internetového obchodu V případě přenosu produktových karet bude situace ještě o něco jednodušší vzhledem k tomu, že seznam produktových karet jsou lineární data. XML s daty bude mít tedy s největší pravděpodobností velmi podobnou strukturu a obsah jako XML s daty o produktových kartách získané operací SQLReadWriteOperation u předchozího příkladu napojení na Altus Vario.
Aktualizace skladové dostupnosti v internetovém obchodu daty z externího systému
64
Stejně jako v předchozím příkladu napojení na Altus Vario je tento příklad zjednodušením přenosu seznamu produktových karet s prostorem pro optimalizaci kvůli co největší rychlosti a co nejmenší náročnosti tohoto přenosu.
Přenos seznamu registrovaných zákazníků z internetového obchodu do externího systému V tomto případě se jedná o opačný přenos – tedy přenos z Internetového obchodu do externího systému Navision. Operaci MSMQReadWriteOperation je tedy potřeba říct zdroj dat, které má zaslat v rámci MSMQ zprávy. Tyto data budou před odesláním načteny pomoci SQLReadWriteOperation z databáze internetového obchodu stejně jako v příkladu napojení na Altus Vario. Dle očekávaného formátu MSMQ zprávy s informacemi o zákazníkovi může být nutné nejdříve provést potřebnou XSLT transformaci tak, aby se struktura XML získaného na začátku procesu při běhu SQLReadWriteOperation upravila dle požadavku programového kódu na straně programu Navision. V návratové zprávě z Navisionu by pak měl být obsažený identifikátor nově založeného zákazníka tak, aby tento identifikátor mohl být na konci tohoto procesu uložený do databáze internetového obchodu.
Přenos nových objednávek z internetového obchodu do externího systému Postup tohoto procesu bude podobný jako v předchozím odstavci popsaný přenos registrovaných zákazníků. Vzhledem k využití formátu XML pro komunikaci je pravděpodobné, že programový kód bude v rámci jedné zprávy očekávat současně jak hlavičku tak řádky objednávky. Docílit takového stavu ale není problém – stačí nejdříve z databáze internetového obchodu načíst nejdříve hlavičky a následně řádky přenášených objednávek. Následně je možné XSLT transformací provést spojení těchto 2 balíčků dat do jednoho více strukturovaného XML tak, aby element reprezentující objednávku obsahoval na první úrovni informace týkající se hlavičky objednávky a v podelementech pak obsahoval rovněž hned řádky objednávky.
Aktualizace stavu vyřízení objednávek podle externího systému Tento zbývající ukázkový proces je již velmi jednoduchý na implementaci. Pokud programový kód na straně Navisionu bude schopný vrátit seznam objednávek s aktualizovaným stavem, pak tak učiní v XML s podobně jednoduchou strukturou jako v případě přenosu produktových karet. Nadefinování operace aktualizující tato data v databází internetového obchodu je již pak triviální.
65
7.5. Ukázka propojení – HP Tronic Jak již bylo zmíněno na začátku kapitoly, XML export od společnosti HP Tronic nereprezentuje přímo obvyklý externí systém, který provozovatel internetového obchodu využívá pro evidenci záležitostí týkajících se prodeje, skladů a podobně. Jedná se o B2B internetový obchod, který je významným dodavatelem zboží pro velké množství internetových obchodů prodávajících koncovým zákazníkům. V rámci tohoto příkladu tedy můžeme ukázat nejen způsob napojení pomocí další technologie (technologie XML exportů prostřednictvím HTTP požadavků) ale zároveň i alternativní možnost napojení na systém úplně jiného typu než může být očekáváno. V tomto případě se jedná pouze o jednosměrný export dat z tohoto systému do internetového obchodu (i když někteří B2B prodejci poskytují svým distributorům i systém, pomocí kterého mohou automatizovaně vkládat objednávky přímo do ERP systému B2B prodejce). V úvahu tedy připadají pouze 3 z procesů popsaných na začátku kapitoly.
Přenos produktového stromu z externího systému do internetového obchodu XML export poskytovaný společností HP tronic obsahující produktový strom má následující strukturu: ... ... ... ... .... Načtená data v tomto formátu je tedy možno rovnou použít jako zdroj pro operaci typu SqlReadWriteOperation a provést tedy aktualizaci informací o produktovém stromu v internetovém obchodu stejným způsobem jako v předešlých příkladech.
Přenos seznamu produktových karet z externího systému do internetového obchodu Přenos produktových karet je v tomto případě o něco komplikovanější vzhledem k tomu, že informace potřebné pro vyplnění produktové karty v ukázkové databázi 66
internetového obchodu jsou rozdělené do 3 samostatných exportů – export jednotlivých karet výrobků, export obsahující ceny a export obsahující skladovou dostupnost. Celý proces aktualizace produktových karet může být řešen dvěma způsoby: a) Zpracování jednotlivých exportů se provede postupně – nejdříve samotné karty následované aktualizací cen a nakonec se zaktualizují skladové dostupnosti b) Data je možné načíst nejdříve všechny do datového kontextu, následně je možné XSLT transformací provést upravení struktury datového kontextu – konkrétně spojení údajů ze všech 3 exportů dohromady vždy pod jeden XML element pro každou položku.
Aktualizace skladové dostupnosti v internetovém obchodu daty z externího systému Vzhledem k tomu, že HP Tronic poskytuje oddělený XML export obsahující informace o skladové dostupnosti, je způsob zpracování tohoto procesu implicitní – ve 2 krocích: 1. Načtení XML exportu do datového kontextu 2. Aktualizace dat v internetovém obchodě vhodně definovanou operací typu SQLReadWriteOperation
67
8. Závěr - zhodnocení dosažených cílů V dosavadním textu diplomové práce byly postupně představeny možné postupy pro napojování internetových obchodů a ekonomických systému (kapitola 2), ukázáno s čím (jakými objekty a procesy) se na internetových obchodech můžeme například setkat (kapitola 3). Následně byly definovány požadavky univerzálnosti, obecnosti a rozšiřitelnosti a navrhnut model, který by měl tyto vytyčené požadavky splňovat (kapitola 4). V další kapitole byl popsán možný princip implementace definovaného modelu s využitím objektového modelu (dědičnosti) a s použitím jazyka C# (kapitola 5). Další 2 kapitoly obsahovaly několik příkladů. První skupina příkladů demonstrovala, jakým způsobem se systém bude používat pro napojení na různé internetové obchody a externí systémy pomocí několika rozdílných technologií (kapitola 6). Zbytek příkladů pak ukázal konkrétní řešení komunikace se třemi reálnými externími systémy (kapitola 8). Na tomto místě tedy zbývá zhodnotit nakolik se podařilo dosáhnout cílů vytyčených na začátku této práce, zamyslet se na negativy navrhnutého řešení případně nad možnostmi jejího rozšíření. Vzhledem k tomu, že téma rozpracované v této práci nemá samo o sobě výraznou hodnotu v teoretické rovině a jeho využitelnost je směřována spíše do praktické komerční sféry, bylo by vhodné zhodnotit i míru použitelnosti a realizovatelnosti navrhnutého řešení v praxi.
8.1. Univerzálnost, obecnost a rozšiřitelnost Požadavky univerzálnosti, obecnosti a rozšiřitelnosti byly definovány na začátku čtvrté kapitoly. Pro připomenutí - tyto 3 požadavky by nám měly umožnit využití popsaného modelu v libovolné situaci a to buď implicitně přímo s funkcemi, které model sám o sobě nabízí (univerzálnost a obecnost) a nebo s použitím kódu vytvořeného ve formě zásuvného modulu, kterým základní funkce modelu rozšíříme (rozšiřitelnost). Představený model tyto požadavky podporuje na několika úrovních tak, aby si implementátor přenosových procesů mohl zvolit způsob rozšiřitelnosti, který vyhovuje aktuální konkrétní potřebě. -
Jednotlivé operace načítání a ukládání dat vychází sice z obecného postupu chování tohoto typu operace, ale jejich konkrétní průběh v rámci jednotlivých procesů může být značně rozdílný. V nastavení operace v jednotlivých procesech se určuje název programové třídy, která vlastní načtení nebo uložení dat zrealizuje.
68
-
Vstupní a výstupní struktura a formátování dat můžou být značně rozdílné. Základní transformace struktury se zajistí pomocí transformací XSLT, což je samo o sobě silný prostředek sloužící k úpravám struktury XML dokumentů. Co se týká obsahové stránky zpracovávaných dat, tak k její úpravě slouží funkce popsaná v kapitole 4 jako „obecné transformace“. Stejně jako v předchozím bodě, i obecná transformace je definovaná programovou třídou, která s daty může provést libovolné transformace dle potřeby konkrétního procesu.
-
Pokud při implementaci přenosového procesu mezi internetových obchodem a externím systémem narazíme na nutnost provést operaci, která nespadá ani do kategorie načítání a ukládání dat ani do kategorie obsahové transformace, nabízí nám navržený model možnost využít speciální operaci, jejíž průběh není definicí modelu nijak předem určen. Funkčnost takové operace může naprogramovat implementátor modelu nebo může být definována třetí stranou. Speciální operace má neomezený přístup k datovému kontextu běžícího procesu, takže může na zpracovávanými daty provádět libovolné úkony – a to ať data libovolně transformovat nebo provést jejich doplnění z externího zdroje nebo naopak jejich export.
8.2. Praktická využitelnost definovaného modelu Aby bylo vhodné využít popsaný model v komerční praxi, pak je nutné, aby jeho nasazení a používání přineslo reálné úspory při implementaci propojení mezi internetovými obchody a externími systémy. Toho lze docílit buď zkrácením času nutného pro vytvoření propojení na určitý externí systém nebo opakovaným využíváním již dříve navrhnutých a realizovaných postupů při implementaci propojení pro několik různých zákazníkům. Model představený v této práci nabízí prostředky, kterými lze docílit obojího. V prvním případě fakt, že model popisuje konkrétní architekturu řazení jednotlivých přenosových operací do procesů jakož i způsob vyvolávání a sledování průběhu těchto procesů, může se implementátor propojení při své práci zaměřit na hlavní podstatu řešeného problému – tedy na to jaké vstupní a výstupní operace je nutné během přenosového procesu provést. Navíc tím, že technická realizace vstupněvýstupních operací je zapouzdřena jako třídy připojené ke sběrnici „translatorů“, které má implementátor k dispozici, může se oprostit i od technické podstaty komunikace pomocí určitého komunikačního protokolu. Ve výsledku pak proces implementace propojení 2 systémů je otázka zvolení určitých předpřipravených „kostiček“, které implementátor vhodně poskládá do řady za sebe a doplní o základní informace upravující jejich náplň. Ve druhém případě pak samotné zapouzdřování implementace vstupně-výstupních operací dovnitř znovupoužitelných a konfigurovatelných „kostiček“ s sebou nese 69
úsporu času, který by bylo potřeba vynaložit při opakované implementaci komunikace s určitými systémy pomocí určitých protokolů. Poslední otázka předurčující použitelnost systému v praxi je jeho složitost (či jednoduchost) a s tím spojené náklady na pochopení (zaškolení) a proniknutí do principů systému. Navrhnutý model i přes svou obecnost staví na několika základních principech a běžných technologiích a čas, který by bylo potřeba vynaložit před tím než by implementátor byl schopný začít systém využívat rozhodně nebude znamenat vysokou investici.
8.3. Nevýhody a možné rozšíření systému Každý systém či model obsahuje vždy prostor pro vylepšení či rozšíření. Cesty, kudy by se mohl další vývoj modelu popsaného v této práci ubírat, zmiňuji následující: 1. Optimalizace Jazyk XML, který byl vybrán jako vhodný prostředek pro reprezentaci dat a jejich zpracování uvnitř modelu, nabízí různé přístupy a varianty. Samotný klasický jazyk XML s sebou nese určité nevýhody a v základu neobsahuje žádné optimalizace pro dotazování se na data uložená uvnitř XML dokumentu. Jednou z velkých nevýhod klasického XML formátu je jeho datová náročnost – konkrétně velká míra režijních informací, které leckdy mohou převyšovat dokonce i samotná uložená data. Velká míra využití XPath dotazování implikuje vhodnost využít nějaký postup indexování a optimalizace v tomto směru. 2. Externí vyvolání procesu V jedné z úvodních kapitol práce při popisování různých způsobu řešení přenosových můstků byla zmíněna možnost vyvolávání přenosových procesů jednou či druhou stranou komunikace. Navržený model předpokládá, že veškerá iniciativa při realizaci přenosů bude pocházet právě z implementované systému. V některých případech může být vhodné mít možnost určitý proces vyvolat včetně předání nějakých parametrů externím systémem. Takové řešení například umožní okamžitě reagovat na události vzniklé na straně některého z externích systémů 3. Rozšíření syntaktických možností Tak jak je model představený touto prací navržený, tak navrhuje řešit jednotlivé přenosové procesy jako lineární (jednotlivé stavební části – operace – se mohou řadit pouze lineárně za sebe) se základní podporou cyklů a jednoduchých podmínek (viz cyklus přes uzly získané na základě XPath dotazu, které reprezentují jednotlivé „řádky“ vstupních dat u operace načítání/ukládání dat - např. tedy u operace typu SqlReadWriteOperation). V rámci dalšího rozšiřování modelu by stálo za zvážení přidat podporu
70
dalších prostředků pro řízení toku běhu procesů (podmíněné provádění operací, větvení, předčasné ukončení procesu a podobně). 4. Rozšíření reportingu a zpracování chybových stavů, monitoring V rámci definice modelu nebyl kladen velký důraz na korektní zpracovávání chybových stavů, které samozřejmě při běhu procesů (zvlášť při napojení na externí zdroje) mohou nastávat. Dalším možným rozšířením modelu v budoucnu by tedy mohlo být pokročilejší zpracovávání těchto chybových stavů (možnost definování jak se při různých chybových stavech proces zachová). Možnost logování a zpětného vyhodnocování procesů a monitoring patří rovněž k důležitým funkcím přenosových procesů v komerčním prostředí.
71
Použitá literatura David S. Linthicum: B2B Application Integration: e-Business-Enable Your Enterprise, Addison-Wesley 2001, ISBN: 978-0-201-70936-0 Beth Gold-Bernstein, William Ruh: Enterprise Integration: The Essential Guide to Integration Solutions, Addison-Wesley 2001, ISBN: 978-0-321-22390-6 Jerry FitzGerald, Alan Dennis: Business Data Communications and Networking, 9th Edition, Wiley 2006, ISBN: 978-0-471-77116-6
72
