VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ FACULTY OF INFORMATION TECHNOLOGY ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ DEPARTMENT OF COMPUTER SYSTEMS ZPŘÍSTUPNĚNÍ SYSTÉMU PROALPHA EXTERNÍMUKLIENTOVI EXTRENAL ACCESSS TO THE PROALPHA SYSTEM DIPLOMOVÁ PRÁCE MASTER’S THESIS AUTOR PRÁCE Bc. ONDŘEJ SUCHÝ AUTHOR VEDOUCÍ PRÁCE Ing. MARTIN KRČMA SUPERVISOR BRNO 2017 Abstrakt V této práci je rozebírána problematika ERP systémů a jejich hlavních cílů a principů. V návaznosti na tento rozbor je představen ERP systém proALPHA, který je dále ana- lyzován z pohledu možností přístupu k jeho funkcionalitě z externích klientů, což je také hlavním cílem této práce. Jako část tohoto systému, jejíž funkcionalitu se budeme snažit zpřístupnit, byl zvolen modul materiálového hospodářství. Do něj budeme přistupovat přes modul INWB, který je implementován s využitím nástroje Sonic ESB, jehož problematika je rovněž předmětem této práce. Všech vytyčených cílů se podařilo úspěšně dosáhnout. Abstract This work deals with main goals and principles of ERP systems. On the basis of the presen- ted principles it presents the proALPHA ERP system and examines it in order to determine external access possibilities. The external access into the proALPHA system is the main goal of this work. The materials management module has been chosen as the part of the system to be accessed. The access will be realized via proALPHA INWB module based on Sonic ESB which is described as well. All set goals of this work were reached. Klíčová slova ERP systém, Enterprise Resource Planning, proALPHA, podniková sběrnice služeb, Java Messaging Service, Sonic, externí přístup Keywords ERP system, Enterprise Resource Planning, proALPHA, Enterprise Service Bus, Java Messaging Service, Sonic, external accesss Citace SUCHÝ, Ondřej. Zpřístupnění systému proALPHA externímu klientovi. Brno, 2017. Di- plomová práce. Vysoké učení technické v Brně, Fakulta informačních technologií. Vedoucí práce Krčma Martin. Zpřístupnění systému proALPHA externímu kli- entovi Prohlášení Prohlašuji, že jsem tuto diplomovou práci na téma Zpřístupnění systému proALPHA ex- ternímu klientovi vypracoval samostatně pod vedením pana Ing. Martina Krčmy. Další informace mi poskytli zaměstnanci firmy SPC solutions, spol. s r.o. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. . . . . . . . . . . . . . . . . . . . . . . . Ondřej Suchý 9. května 2017 Poděkování Na tomto místě bych chtěl poděkovat Ing. Ivanu Pagáčovi za konzultace praktické části této práce a pomoc při řešení problémů, které se v jejím průběhu objevily, Ing. Martinu Šebestovi za vytvoření zadání práce a Ing. Martinu Hollemu za poskytnutí informací o systému proALPHA z uživatelského pohledu. Obsah 1 Úvod 4 2 ERP systémy 5 2.1 Historický vývoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 60. a 70. léta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2 Zvyšování integrace systémů . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3 Moderní ERP systémy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Principy ERP systémů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Modulární architektura . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2 Přínosy a rizika ERP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 Systém proALPHA 11 3.1 Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Moduly a části systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1 Kmenová data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 Finanční účetnictví . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3 Odbyt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.4 Nákup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.5 Materiálové hospodářství . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.6 Ostatní moduly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Možnosti externího přístupu . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 Enterprise messaging a JMS 17 4.1 Hlavní principy EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.1 Architektura EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1 Pojem zprávy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.2 Modely komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.3 Praktické aspekty JMS API . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 SonicMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.1 Zprávy v SonicMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5 Podniková sběrnice služeb Sonic ESB 24 5.1 SOA implementovaná sběrnicí ESB . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1 Komunikace v ESB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2 Klíčové prvky v Sonic ESB . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1 ESB Endpointy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.2 ESB kontejnery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1 5.2.3 ESB Služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4 ESB procesy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3 Přehled vestavěných služeb . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.1 Směrování a transformace . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.2 Split and Join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.3 Služby pracující nad soubory . . . . . . . . . . . . . . . . . . . . . . 31 6 OpenEdge ABL 32 6.1 Procedury a funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1.1 Externí procedura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1.2 Interní procedura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1.3 Funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2 Přístup k databázi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3 Temporální tabulky a ProDataSety . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.1 Temporální tabulky . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.2 ProDataSety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4 Zpracování XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4.1 SAX API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.5 Sonic adaptéry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5.1 SonicMQ adaptér . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5.2 Sonic ESB adaptér . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7 Návrh systému pro externí přístup 38 7.1 Operace nad vychystávacími návrhy . . . . . . . . . . . . . . . . . . . . . . 39 7.2 Návrh aplikačního rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.1 Architektura REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.2 Definice rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.3 Adaptér a jeho funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.3.1 Získání vychystávacích návrhů . . . . . . . . . . . . . . . . . . . . . 44 7.3.2 Vytváření a mazání záznamů . . . . . . . . . . . . . . . . . . . . . . 45 7.3.3 Editace vychystávacích návrhů . . . . . . . . . . . . . . . . . . . . . 45 7.4 Propojení API s adaptérem . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.4.1 RESTful webová služba jako ESB proces . . . . . . . . . . . . . . . 46 7.4.2 Volání ABL procedury z ESB služby . . . . . . . . . . . . . . . . . . 47 7.4.3 REST procesy a komunikace s adaptérem . . . . . . . . . . . . . . . 48 8 Implementace adaptéru pro externí přístup 50 8.1 Generování seznamu vzniklých chyb . . . . . . . . . . . . . . . . . . . . . . 52 8.1.1 Procedura writeError . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.2 Manipulace se záznamy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.3 Vytváření a získávání záznamů . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.4 Mazání vychystávacích návrhů a jejich položek . . . . . . . . . . . . . . . . 57 8.5 Editace vychystávacího návrhu . . . . . . . . . . . . . . . . . . . . . . . . . 58 8.5.1 Procedura endElement . . . . . . . . . . . . . . . . . . . . . . . . . . 59 8.6 Editace položek vychystávacího návrhu . . . . . . . . . . . . . . . . . . . . . 62 8.6.1 setStatusOfPickLineToWorking . . . . . . . . . . . . . . . . . . . . . 63 8.6.2 updateLinePickStatus . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2 9 Realizace externího přístupu 66 9.1 ESB procesy a jejich interakce s okolím . . . . . . . . . . . . . . . . . . . . 66 9.1.1 Realizace potřebných procesů . . . . . . . . . . . . . . . . . . . . . . 66 9.1.2 Propojení ESB procesu a adaptéru . . . . . . . . . . . . . . . . . . . 68 9.2 Testovací klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 9.2.1 Podoba klienta a jeho funkce . . . . . . . . . . . . . . . . . . . . . . 72 9.2.2 Vnitřní realizace klienta . . . . . . . . . . . . . . . . . . . . . . . . . 73 10 Závěr 76 Literatura 78 A ESB procesy 80 B Procedury pro editaci řádků návrhu 84 C Uživatelské rozhraní testovacího klienta 87 D Obsah CD 88 3 Kapitola 1 Úvod Jako klíčovým prostředkem pro správu celopodnikových zdrojů se v současné době uplatňují Enterprise Resource Planning (ERP) systémy. Základy těchto systémů byly položeny již v 60. letech minulého století, v podobě, v jaké je známe dnes, se však začaly objevovat až na počátku 90. let. [11, 31] Na přelomu tisíciletí pak ERP systémy začaly výrazněji pronikat i do oblasti malých a středních podniků. [16] Jak ukazuje například studie [4], pro malé podniky je velmi důležitým požadavkem možnost přistupovat k informacím a funkcionalitě systému odkudkoliv včetně mobilního a webového rozhraní. Vzdálený přístup do ERP systému je hlavním předmětem této práce. Cílem jejího zadání je nastudovat a představit problematiku ERP systémů a na základě získaných poznatků zanalyzovat ERP systém proALPHA. Konkrétně je třeba zjistit, jaké jsou možnosti externího přístupu do tohoto systému a vybrat vhodnou část, jejíž funkci- onalitu se pokusíme zpřístupnit. Další náplní práce je pak navrhnout implementaci exter- ního přístupu do vybrané části, realizovat ji a demonstrovat její funkčnost jednoduchým testovacím klientem. Iniciátorem tohoto zadání je firma SPC solutions, spol. s r.o., která se dlouhodobě stará o českou a slovenskou lokalizaci systému proALPHA a která vznesla požadavek na jeho analýzu z hlediska možností zpřístupnění jeho funkcionality externím klientům. Přehled vývoje ERP systémů, jejich základních konceptů a klíčových cílů bude rozebrán v kapitole 2, na kterou navazuje kapitola 3 zabývající se podrobněji systémem proALPHA. V té je rovněž identifikována vhodná oblast pro otestování možností externího přístupu do systému a jeho preferovaná cesta. Kapitoly 4 a 5 pak popisují mechanismy a principy, na kterých je vybraná cesta externího přístupu založená. Konkrétně se jedná o problematiku ESB a EMS. O jejich implementaci se v tomto případě stará nástroj Sonic ESB respektive SonicMQ. Rozbor relevantních tech- nologií doplňuje kapitola 6 prezentující hlavní implementační jazyk této práce OpenEdge ABL. Na základě všech těchto poznatků následně v rámci kapitoly 7 navrhneme celkovou podobu systému pro externí přístup a definujeme rozhraní mezi jeho jednotlivými částmi. Implementačními detaily navrženého systému se budeme zabývat v kapitolách 8 a 9. Do- sažené výsledky a směr, kterým by se mohl případný další vývoj této práce ubírat budou shrnuty v její závěrečné části v kapitole 10. 4 Kapitola 2 ERP systémy Aby byl podnik schopný čelit výzvám moderního, rychle se měnícího ekonomického pro- středí a mohl být konkurencí pro ostatní podniky na trhu, je nutné, aby všechny jeho části fungovaly co nejefektivněji, nejspolehlivěji a s minimálními náklady. Jedině tehdy totiž podnik může nabízet v dostatečně krátkém čase kvalitní a levné služby svým zákazníkům. Tohoto stavu docílíme maximálním využitím potenciálu veškerých zdrojů, které má podnik k dispozici, a optimalizací jeho běžných obchodních procesů.1 Právě za tímto úče- lem vznikly komplexní podnikové informační systémy, pro které se používá označení ERP (Enterprise Resource Planning). Pojem ERP definuje [8] následovně: „ERP je charakterizován jako typ aplikačního software, který umožňuje řízení a koordinaci všech disponibilních podnikových zdrojů a aktivit. Mezi hlavní vlastnosti ERP patří schopnost automatizovat a integrovat klíčové podnikové procesy, funkce a data v rámci celé firmy.“ Kvůli výše uvedeným požadavkům během posledních desetiletí firmy upustily od svých starých informačních systémů a začaly místo nich využívat ERP systémy integrující klíčové aktivity podniku. ERP systémy se využívají ke správě všech podnikových dat, díky čemuž mohou poskytovat aktuální informace tehdy, kdy je jich třeba. [5] Cílem této kapitoly je podrobněji představit pojem ERP systému, udělat stručný přehled jeho historického vývoje a prezentovat jeho klíčové prvky, základní úlohy a výhody včetně rizik spojených s jeho nasazením. 2.1 Historický vývoj V této části bude probrán průběh vývoje informačních systémů, které měly za úkol starat se o zdroje podniku. Přehled zachycuje období od 60. let minulého století, kdy dominovaly systémy zajišťující plánování a správu výroby, až po současné ERP a ERP II systémy, pro něž je typická vysoká míra integrace dílčích podnikových systémů. 2.1.1 60. a 70. léta Jak již bylo naznačeno v úvodu této sekce, ERP systémům předcházely systémy orientované spíše na plánování a správu výroby než podnikových zdrojů obecně. [11] Tento software 1Obchodní proces chápeme jako kolekci aktivit s jedním nebo více vstupy, které jsou transformovány na výstupy mající nějakou hodnotu pro zákazníka. Zákazník může být buď osoba platící za cílový produkt, nebo pracovník jiného oddělení, který výstup dále zpracovává. 5 zaznamenal v průběhu 60. a 70. let vývoj od jednoduchých systémů pro sledování zásob až k pokročilejším MRP (Material Requirement Planning) systémům. [16] V období 60. let si mohly společnosti dovolit udržovat poměrně velké množství zásob, aniž by tím klesala jejich konkurenceschopnost. Systémy se tedy zaměřovaly především na kontrolu zásob podniku. [31] Během 70. let se však začalo ukazovat, že tento přístup postupně přestává být přípustný. To vedlo na vznik systémů MRP [31], které umožňovaly vhodně plánovat produkci v dosta- tečném množství a s tím spojené objednávky zdrojů nutných pro realizaci této produkce. Vytvoření plánu probíhalo na základě analýzy predikce budoucích prodejů. [16] 2.1.2 Zvyšování integrace systémů Díky zvýšení možností a dostupnosti nových technologií bylo v 80. letech možné provést propojení pohybů zásob s odpovídajícími finančními aktivitami, což vedlo na vznik systémů MRP II (Manufactoring Resource Planning). Tyto systémy v sobě zahrnovaly finanční účetnictví a správu financí společně s řízením výroby a správou materiálů. [31] Kromě toho do sebe také začlenily oblast plánování kapacit výrobních zdrojů. [8] Pokračující technologické pokroky na počátku 90. let umožnily další rozšiřování systémů MRP II. Postupně se do nich začlenily části pro správu a řízení veškerých zdrojů společ- nosti, jako například lidské zdroje, projektové řízení, materiálové plánování apod. [11, 31] S rostoucím počtem oblastí, které tyto systémy pokrývaly, se pro ně začal zavádět název ERP (Enterprise Resource Planning). První společností, která vyvinula software pro ERP systémy, je společnost SAP. [16] 2.1.3 Moderní ERP systémy Díky velkému počtu oblastí, které ERP pokrývají, se již tyto systémy nemusí orientovat pouze na výrobní podniky, ale i na množství jiných průmyslových odvětví. [11] To znamená, že nemusí být nutně použity jen pro výrobní společnosti, ale může je použít kterákoliv firma, která chce zvýšit svou konkurenceschopnost efektivním řízením svých zdrojů. [31] Od svých předchůdců se odlišují silnější integrací výrobních a finančních modulů, díky čemuž je možné lépe vyhodnocovat ekonomické efekty a případná rizika zakázek. Dále se také projevuje lepší řízení personálních zdrojů, řízení majetku a propojení výrobního a finančního plánování. [8] K velkému nárůstu počtu implementací2 ERP systémů došlo na konci 90. let, a to mimo jiné i kvůli blížícímu se problému Y2K.3 Aby firmy tento problém vyřešily, mohly buď vynaložit nemalé finanční náklady na opravu svých zastaralých systémů, nebo investovat do zavedení moderního ERP systému, který měl navíc potenciál zlepšit správu obchodních procesů společnosti a tím i její konkurenceschopnost. [16, 31] Ve stejné době se také začali dodavatelé ERP systémů více orientovat na systémy pro malé a střední podniky, jelikož oblast velkých podniků se již postupně zaplňovala. [16] V posledních letech se můžeme setkat také s pojmem ERP II. Systémy tohoto typu pokračují dále v trendu integrace a kromě jádra tvořeného systémem ERP v sobě zahrnují i množství dalších prvků jako například Business intelligence, e-Businnes, workflow apod. ERP II jsou typicky určeny pro střední a větší podniky. [8] 2V kontextu ERP systémů rozumíme pod pojmem implementace nasazení systému do provozu v kon- krétním podniku. 3Systémy ze 70. a 80. let z důvodu optimalizace používaly pro reprezentaci roku jen jeho dvě poslední číslice. V roce 2000 by tak došlo k přetečení této hodnoty vedoucí na nekonzistenci v systémech. 6 2.2 Principy ERP systémů V době, kdy ERP systémy nebyli tak rozšířené, jako je tomu v posledních letech, měla většina společností neintegrované informační systémy, které se staraly pouze o činnost kon- krétních oblastí podniku, jako například marketing, produkce atd. Každý z těchto systémů fungoval nezávisle na ostatních s vlastním hardwarem, softwarem a metodami zpracování dat. [16, 11] Nevýhodou tohoto přístupu je absence kvalitního sdílení dat napříč celým podnikem vedoucí na neefektivitu fungování společnosti, přestože všechny systémy pracují kvalitně a spolehlivě ve své individuální oblasti. Aby bylo možné sdílet data mezi jednotlivými odděleními, bylo typicky nutné vyexportovat data z jednoho systému a znovu je zadat do dalšího. [16] Tento proces je jednak časově náročný, navíc také zvyšuje pravděpodobnost vzniku chyby a tudíž nekonzistence v systému. Automatizací převodu dat mezi systémy je sice možné riziko chyby snížit, změny ale obvykle probíhají periodicky a aktuální data tudíž nejsou dostupná v dostatečně krátkém čase. [16] Dále například není možné sledovat prů- chod zákaznického požadavku napříč jednotlivými odděleními, což opět vede na nutnost opakovaného zadávání stejné informace na různých úrovních procesu do často neslučitel- ných databází. Tím se snižuje efektivita podnikových dat a operací a naopak stoupá prav- děpodobnost chyby a nekonzistence v datech. [8] Jak již bylo naznačeno v sekci 2.1, ERP systémy se snaží sjednotit dílčí podnikové funkce na úrovni celého podniku do jedné aplikace se společným zdrojem dat (viz obrázek 2.1). Programy v nich integrované vyhovují potřebám jednotlivých oddělení a pracovníků. Je- jich úkolem je tedy vytvořit jedinou konzistentní aplikaci, která bude efektivně poskytovat podporu běžným podnikovým procesům. [12, 8] Obrázek 2.1: Zjednodušená architektura ERP systému. (Převzato z [2]) ERP pokrývá techniky pro správu podniku jako celku z pohledu efektivního nakládání s podnikovými zdroji za účelem zvýšení efektivity celé organizace. Jsou navrženy tak, aby modelovaly a automatizovaly základní obchodní procesy s cílem integrace informací na- příč podnikem a eliminovaly nákladné propojení mezi jednotlivými systémy, u kterých se 7 vzájemná komunikace nikdy nepředpokládala. [11] Pro ERP systémy je charakteristický vysoký počet uživatelů, typicky jsou transakčně orientované a téměř výhradně pracují nad relační databází. [8] Při nasazování ERP systému je velmi důležitá jeho customizace neboli přizpůsobení. ERP systémy jsou obecné aplikace a je tedy nutné je přizpůsobit potřebám konkrétních ekonomických subjektů. Jako příklady customizace uvádí [8] mimo jiné • úpravy uživatelského rozhraní a funkcí, • nastavení defaultních hodnot pro jazyk, měnu apod., • úpravy a naplnění číselníků, • přizpůsobení standardních výpočtů. Podle [8] v našich podmínkách obvykle rozlišujeme následující typy ERP systémů: • velké systémy – pro podniky s více než 500 zaměstnanci a obratem nad 800 mil. Kč, • střední systémy – pro podniky s 25 – 500 zaměstnanci a obratem 100 – 800 mil. Kč, • malé systémy – pro podniky do 25 zaměstnanců a obratem do 100 mil. Kč. 2.2.1 Modulární architektura Aby byla v ERP systému zachována rovnováha mezi provázaností a nezávislostí jednotlivých částí, je celý systém založen na modulární struktuře. [8] Softwarové moduly jsou individuální programy, které lze zakoupit, instalovat a provozovat samostatně, všechny moduly ale budou k práci využívat data ze sdílených databází. [16] Díky tomu je možné lépe vyhovět potřebám konkrétních podniků a nekupovat nepo- třebné moduly. Je zbytečné, aby například firma, která nevyrábí žádné zboží, měla insta- lovaný výrobní modul apod. [8] Moduly ERP systému si mezi sebou předávají data buď přes sdílené databáze, nebo prostřednictvím datových vstupů a výstupů. Důsledkem této komunikace je, že vykonání operace v jednom modulu přímo vede na automatické generování příslušné operace v jiném modulu. Takovéto operace jsou pak vzájemně konzistentní a jejich důsledky jsou dohleda- telné napříč systémem. [8] Tento přístup je demonstrován na obrázku 2.2. Jako typické příklady modulů ERP systému si uvedeme následující zástupce: [8, 12, 16] • Modul výroby – udržuje informace o produkci, provádí její plánování a zazname- nává produkční aktivity. Obvykle nebývá omezený jen na jednoduché operace jako výroba do zásoby nebo výroba na zakázku, ale umožňuje kombinovat škálu výrobních a plánovacích metod v rámci operace a dosáhnout tak vysoké flexibility. • Modul finančního účetnictví – shromažďuje data z oblasti financí, zaznamenává transakce do hlavní účetní knihy, generuje finanční výkazy pro další použití atd. Fi- nanční data jsou důležitá pro strategické plánování. • Modul řízení zásob – optimalizuje všechny nákupní procesy, umožňuje automati- zovanou evaluaci dodavatelů, snižuje náklady na nákupy a uskladnění, eviduje příjmy, výdaje a stav zásob. 8 Obrázek 2.2: Typický tok dat mezi moduly ERP systému při realizaci styku se zákazní- kem a dodavatelem. Jednotlivé dokumenty reprezentované modrošedým obdélníkem jsou systémem vytvářeny na základě již existujících dokumentů. Operace nad dokumenty jsou znázorněny bílým oválem. Pojmenování modulů, dokumentů a operací uváděných na ob- rázku koresponduje s pojmenováním v systému proALPHA (viz kapitola 3). • Modul lidských zdrojů – usnadňuje nábor nových zaměstnanců s vhodnými schop- nostmi a jejich zaškolení, spravuje zaměstnance podniku a jejich data, kontroluje ces- tovní výdaje, zaměstnanecké výhody a platy, plánování směn a další. • Modul prodeje a distribuce – zpracovává objednávky, stará se o procesy spojené s objednávkami a jejich dodáním, spravuje informace o zákaznících. • Modul správy zařízení – zajišťuje plánování preventivních údržbářských prací za účelem minimalizace poruch zařízení v podniku. ERP architektura navíc kromě výše uvedených modulů, které se taky označují jako aplikační, obvykle nabízí i řadu dalších podpůrných modulů. Mezi tyto moduly mohou patřit například dokumentační moduly obsahující dokumentaci jednotlivých aplikačních modulů, implementační moduly pomáhající při nasazení systému v daném podniku, moduly pro customizaci systému nebo vlastí vývojové prostředí. [8] 2.2.2 Přínosy a rizika ERP ERP systémy pomáhají společnosti centralizováním informací z různých geografických lo- kací lépe kontrolovat její zásoby, nákupy, finance, výrobu a lidské zdroje. [5] Dále nabízejí ucelený pohled na podnik a jeho fungování, který pokrývá všechny jeho funkce a oddě- lení. [31] Díky integraci jednotlivých oblastí podniku získáváme optimalizované obchodní pro- cesy, které jsou méně nákladné než v případě neintegrovaných systémů. [16] Zavedení ERP 9 systémů rovněž vede ke snížení ceny práce a zvýšení kvality zákaznických služeb vedoucí k minimalizaci ztráty zakázek a celkovému zvýšení obratu. [12] ERP systémy jsou také schopné provádět simulaci různých scénářů využití dostupných kapacit a zdrojů, což umožňuje udržovat stav zásob a prostoje při práci výrobních zaří- zení na minimální úrovni. [11] Díky tomu můžeme pozorovat pokles nákladů na skladování a logistiku a snížení pravděpodobnosti zastarávání nebo poškození zásob. [5, 12] Z nehmotných přínosů můžeme zmínit, že díky společné databázi ERP systému není nutné duplikovat soubory a udržovat redundantní záznamy. Finanční výkazy mohou být navíc snadno přizpůsobené pro konkrétní účely a odhady jsou založeny na detailních ERP kalkulacích. Vysoká integrace a schopnost automaticky aktualizovat data mezi souvisejícími činnostmi vedou také na zlepšené rozhodování. [11, 12] Na druhou stranu je ale nutné zmínit, že implementace ERP systému je velmi nákladná, a to jak finančně, tak i časově. Hlavní faktory ovlivňující cenu jsou podle [5, 16] následující: • rozsah ERP softwaru, který je závislý na velikosti společnosti, • pořízení hardwaru, který odpovídá potřebám komplexního ERP systému, • náklady na konzultanty a analýzy, • zaškolení pracovníků a následná podpora. Kromě toho, výběr vhodného systému pro danou organizaci a jeho efektivní implemen- tace jsou náročné procesy s vysokou pravděpodobností neúspěchu. [12] Vždy je nutné mít na paměti, že ne všechny organizace získají od stejného ERP systému stejné výhody a ne každý systém je dostatečně vhodný pro každou firmu. Jako časté příčiny neúspěchu si můžeme uvést tyto faktory: • zvolení nevhodného ERP systému, jehož technologické schopnosti neodpovídají exis- tujícím obchodním procesům a procedurám dané společnosti, • lidský faktor, tj. nekvalitní implementační tým a vedení projektu, zaměstnanci neo- chotní přijmout nový systém, • nedostatečné plánování a řízeni implementace, • nedostatek podpory ze strany řízení podniku vedoucí na nekvalitní analýzu a přepra- cování obchodních procesů, • neochota přizpůsobit stávající obchodní procesy a organizační strukturu podniku zvo- lenému ERP systému. [5, 31] 10 Kapitola 3 Systém proALPHA ProAPLHA je ERP systém vyvíjený německou společností proALPHA Business Solutions GmbH. Hlavní cílová skupina tohoto systému jsou malé a střední podniky v oblastech výroby, obchodu a služeb. [1] Hlavní jádro systému je napsané v jazyce OpenEdge ABL, další externí komponenty jsou psané v jazycích C# a Java. Cílem této kapitoly je seznámit čtenáře s podobou tohoto systému, jeho základními funkcemi a operacemi a představit jeho klíčové moduly. Z těchto modulů také určíme jeden, který v práci dále poslouží jako cílová oblast pro externí přístup do systému. V závěru kapitoly také stručně prodiskutujeme preferovaný způsob přístupu do vybrané části. Jelikož firma SPC solutions nemá přístup k vývojářské dokumentaci systému proALPHA a nebyly nalezeny ani jiné dostupné a dostatečně kvalitní materiály, musely být při psaní této kapitoly využity jiné alternativy. Jako zdroj informací pro tuto kapitolu sloužily kromě oficiálních webových stránek systému [1] převážně osobní konzultace s pracovníky SPC, roz- pracovaná uživatelská dokumentace firmy SPC a nápověda v uživatelském rozhraní systému proALPHA. 3.1 Uživatelské rozhraní Ještě než se budeme podrobněji zabývat jednotlivými částmi a funkcionalitou systému, ukážeme si základní prvky jeho uživatelského rozhraní. Po zadání přihlašovacích údajů a spuštění proALPHA můžeme na levé straně hlavní obrazovky najít navigační panel (obrá- zek 3.1). Jednotlivé části systému jsou v tomto panelu organizovány do stromové struktury, přičemž nejvyšší úroveň reprezentuje jednotlivé moduly, nižší úrovně oblasti, které pod ně spadají, případně data, která jsou relevantní v dané oblasti. Zbylá část obrazovky slouží ke zobrazení aktuálně otevřených oken umožňujících pro- hlížení a úpravu dat. Při práci s dokumenty v systému proALPHA se nejčastěji setkáme se dvěma základními typy oken: • hlavní okno (obrázek 3.2), • závislé okno (obrázek 3.3). Hlavní okno slouží ke zobrazení jednoho záznamu z databáze. Typicky se jedná o do- kument jako je faktura, dodací list, zakázka aj. V horní části okna jsou uvedeny základní údaje o dokumentu. Mezi ně spadá například zákazník, který je s dokumentem spojen, datum vytvoření apod. Doplňující údaje pak nalezneme ve spodní části okna rozdělené do přepínacích panelů. 11 Obrázek 3.1: Panel pro navigaci v systému proALPHA. Pro zobrazení závislých záznamů, jako například jednotlivých položek zakázky, slouží závislé okno. V horní části okna se nachází tabulka s jednotlivými položkami a základními údaji, konkrétně objednané množství, cena nebo termín dodání, ve spodní části pak opět můžeme nalézt detaily vybrané položky. V některých případech se můžeme v tomto okně setkat i se strukturovanými položkami, kde rozlišujeme hlavní a závislé řádky položek. Jako příklad uveďme položky vychystáva- cích návrhů, kde hlavní řádek reprezentuje skladovou položku, která má být vychystána v požadovaném množství. Vychystávání může probíhat postupně, a položky lze odebírat z různých skladů. Každý závislý řádek tedy představuje záznam o jednom dílčím vychys- tání části požadovaného množství. Obě okna sdílejí také společné menu s následujícími položkami: • Soubor – obecné operace se systémem a záznamy, • Funkce – přístup k podřízeným nebo nadřízeným záznamům, • Náhled – přepínání podrobností zobrazovaných ve spodní části okna, • Nástroje – operace, které jsou specifické pro daný typ záznamu, například fakturu, • Kmenová data – přístup do číselníků a k nadřízeným záznamům, • Info – přístup k dalším datům doplňujícím informace zobrazované v okně. Kromě menu máme v záhlaví každého okna k dispozici také toolbar s tlačítky pro navi- gaci mezi záznamy v databázi, zpřístupnění editace záznamu, jeho smazání a další. 12 Obrázek 3.2: Hlavní datové okno systému proALPHA. Obrázek 3.3: Okno se závislými daty systému proALPHA. 13 3.2 Moduly a části systému Díky využití modulární struktury, rozebírané v části 2.2.1, umožňuje proALPHA přizpůso- bení systému pro potřeby konkrétního podniku, zároveň však dodržuje koncept integrace jednotlivých částí, čímž zajišťuje konzistentní tok dat napříč podnikem. V této části pro- bereme jednotlivé moduly systému a stručně vysvětlíme, jakou v něm hrají roli. 3.2.1 Kmenová data Kmenová data představují typ dat, který je naprosto nezbytný pro běh celého systému. Pokud nebudou správně vyplněna, nebude možné provádět požadované operace. Přístup ke kmenovým datům je možný buď přes příslušnou položku v navigaci systému nebo přes jednotlivé moduly, u kterých jsou vždy k dispozici odkazy na data, která se jich týkají. Mezi kmenovými daty obvykle najdeme především číselníky, tj. uspořádané seznamy záznamů, ve kterých je každému záznamu přiřazena identifikace. Konkrétně se jedná o da- tabázové tabulky, ve kterých jsou uloženy • státy, • měny, • číselné řady, • banky a banovní spojení, • daňové klíče, • ceníky • a monoho dalších. Kromě výše uvedených si ještě z kmenových dat zvlášť vyzvedněme seznamy • zákazníků, • dodavatelů, • artiklů (zboží a služby), • pracovníků. 3.2.2 Finanční účetnictví Modul finančního účetnictví má na starosti zaznamenávání obchodních transakcí, správu informací o bankovních spojeních apod. Dále také umožňuje generovat hlášení v podobě rozvahy a výkazu zisků a ztrát. Zároveň poskytuje všechny nutné prostředky pro strategické plánování. Zaúčtování faktury z odbytu nebo nákupu typicky probíhá tak, že nejprve provedeme její tisk a následně uvolnění v příslušném modulu. Uvolněná faktura je připravena k zaúčtování a po provedení denní závěrky pak z faktury vzniká otevřená položka. Ta říká, že nám zákazník dluží peníze za vystavenou fakturu nebo naopak dluží peníze podnik dodavateli za přijaté zboží. Otevřenou položku uspokojíme například zaplacením požadované částky dodavateli. 14 3.2.3 Odbyt Odbytový modul se stará prakticky o všechny operace týkající se styku se zákazníky. Je možné v něm vytvářet zákazníkům nabídky, na základě nabídek zadávat zakázky a dodací listy a pro ně pak vystavovat faktury. V případě vráceného zboží je zde také možné generovat dobropis. Dále je v tomto modulu možné předpovídat budoucí odbyt artiklů. V průběhu celého procesu obsluhy zákazníka jsou data pro dokumenty postupně přebí- rána z existujících dokumentů jak zachycuje obrázek 2.2. Díky tomu tedy lze přes jednotné rozhraní spravovat data z oblasti prodejů od nabídek až po faktury bez nutnosti opakova- ného zadávání stejných údajů, což eliminuje možnost vzniku chyby při přepisu. Tyto údaje navíc mohou být později použity také ve výrobním modulu pro plánování výroby. Další vý- hodou přebírání dokumentů je možnost vysledovat pro každý dokument jeho předchůdce. Tyto údaje lze získat přes položku Info v menu odpovídajícího okna. 3.2.4 Nákup Jestliže se odbytový modul staral o veškerý kontakt se zákazníkem, pak modul nákupu pokrývá pro změnu všechny aspekty vztahů mezi podnikem a jeho dodavateli. Ti mohou dodávat jak zboží, tak služby. Podobně jako v odbytech, i zde se výrazně uplatňuje přebírání jednotlivých dokumentů, tj. poptávek, objednávek, dodacích listů a faktur. Další z funkcí tohoto modulu je kvalitativní hodnocení dodavatelů. Hodnocení probíhá na základě uživatelem definovaných skupin ohodnocení. Tyto skupiny jsou definované volně a jejich definice záleží tedy především na konkrétních potřebách uživatele. Jako příklad hodnotícího kritéria můžeme uvést hodnocení na základě dodržování dodacích termínů re- spektive zpoždění dodávek. Hodnocení probíhá vždy pro období specifikované uživatelem. 3.2.5 Materiálové hospodářství Modul materiálového hospodářství má primárně za úkol řešit logistické záležitosti podniku. Konkrétně se jedná o • plánování poptávek pro dodavatele, • určení množství objednávaných položek, • uskladnění a transport zboží, • optimalizovanou správu skladů, • sledování veškerých pohybů zboží. Důležitými dokumenty v tomto modulu jsou vychystávací návrhy (staging suggestions, picking). Ty nesou mimo jiné informace o tom, jaké skladové položky byly v jakých množ- stvích rezervovány k odebrání ze skladu. Nejčastěji se položky ze skladu odebírají, aby mohly být vyexpedovány k zákazníkovi na základě zakázky, může se ale také jednat o odebrání surovin za účelem výroby nebo přeskladnění na jiný sklad. Práce s těmito dokumenty probíhá stejným způsobem jako s dokumenty zmiňovanými dříve. Na druhou stranu ale vychystávací návrhy nejsou tak silně vázány na ostatní moduly a operace nad nimi mají menší celkové dopady na systém. Díky tomu se jeví tato oblast ma- teriálového hospodářství jako optimální část systému proALPHA pro otestování možností externího přístupu do systému. Další motivací pro využití této oblasti může být i fakt, 15 že právě při práci s těmito dokumenty vzniká nejintenzivnější potřeba využití mobilních zařízení. 3.2.6 Ostatní moduly Přestože ERP systém proALPHA nabízí více modulů než jen výše uvedené, nebudeme se jimi v této práci zabývat podrobně, ale uvedeme si pouze následující přehled: • Investiční účetnictví – stará se o hmotný majetek společnosti a jeho odpisy. • Vnitropodnikové účetnictví – umožňuje dělit náklady na střediska podle potřeb podniku. • Výroba – zahrnuje všechny funkce pro potřeby plánování a řízení výroby produktů. • MIS – nabízí manažerský pohled na data bez možnosti úprav. • Správa systému – spravuje šablony a umožňuje z nich generovat formuláře. • Správa projektů – umožňuje definovat a spravovat projekty, jejich strukturu, čin- nosti, milníky atd. • Vyhodnocení – provádí analýzy odchylek plánovaných činností od skutečnosti. • Výměna dat – viz 3.3 3.3 Možnosti externího přístupu Interakci systému proALPHA s okolním světem zajišťuje modul výměny dat označovaný také jako integration workbench (INWB). Ten v systému plní úlohu podnikové sběrnice služeb (ESB), jejíž koncepty budou podrobně rozebrány v kapitole 5. INWB je realizován s využitím softwaru Sonic ESB. Důvod pro zavedení INWB do systému proALPHA byla optimalizace výrobních plánů, které byly výpočetně náročné a nebylo možné je zpracovávat synchronně. Tento problém byl vyřešen použitím asynchronního enterprise messaging systému (viz kapitola 4) právě v rámci modulu INWB. V následujících verzích proALPHA se funkce tohoto modulu roz- šířily a v současnosti je možné jej použít například pro tyto operace: • replikace dat v systému, • přenos dokumentů jak mezi dvěma instancemi proALPHA, tak mezi externími sys- témy, • ověřování adres obchodních partnerů za účelem udržení činnosti podniku v souladu s korporátní compliancí • a další. Všechny operace se systémem jsou silně závislé na uživatelském kontextu, který nese informace o přihlášeném uživateli a úrovni jeho oprávnění. Kontext je možné získat mimo jiné s využitím standardních komponent, které poskytuje modul INWB. Tento modul tedy plní také funkci primární cesty pro přístup z vnějšího prostředí do systému proALPHA. 16 Kapitola 4 Enterprise messaging a JMS Enterprise messaging systém (EMS) můžeme podle [6] definovat jako asynchronní rozhraní, které umožňuje zasílání zpráv mezi programy. Tyto zprávy jsou uloženy do fronty a následně ve vhodnou dobu zpracovány příjemcem. V prostředí podnikových systémů se setkáváme také s označením Message-Oriented Middleware (MOM) [6, 28]. Smyslem EMS je naplnění následujících cílů: • propojení činnosti existujících systémů, které pracovaly nezávisle na sobě, prostřed- nictvím výměny zpráv, • spolehlivé doručení informací z koncových zařízení, jako například z externích senzorů, výrobních strojů v rámci podniku apod., • garantované doručení dat ze vzdálených oblastí podniku do jeho centra, • podávání hlášení pro vedení podniku o obchodních aktivitách v distribuovaných pod- nikových systémech, • bezpečný a spolehlivý přenos dat od obchodních partnerů a zákazníků do obchodních portálů. [17] V této kapitole nejprve v sekci 4.1 představíme základní myšlenky a koncepty využité v EMS, dále se v sekci 4.2 budeme věnovat popisu specifikace JMS a na závěr (sekce 4.3), probereme SonicMQ, konkrétní implementaci JMS. 4.1 Hlavní principy EMS Enterprise messaging systém je ve své podstatě software, který umožňuje dvěma aplikacím komunikovat prostřednictvím odesílání a přijímaní zpráv bez nutnosti lidského zásahu. Tyto aplikace mohou běžet zcela nezávisle na široké škále hardwarových zařízení. [17] Hlavní myšlenkou v EMS je asynchronní doručování zpráv přes síť od jedné aplikace ke druhé. Odesilatel tak nemusí čekat na příjemce, až zprávu příjme a zpracuje, ale může ihned po odeslání zprávy pokračovat v činnosti. Na druhou stranu existují také případy, kdy je vyžadována synchronní komunikace. Z tohoto důvodu je důležité, aby systém pro zasílání zpráv dokázal podporovat jak asynchronní, tak synchronní komunikaci. [17, 28] Zpráva má v EMS podobu samostatného balíku dat a směrovacích hlaviček. Data ob- sažná ve zprávě mohou být jakéhokoliv charakteru. Tyto zprávy obecně informují systém, že v některém jiném systému došlo k události, na kterou je třeba reagovat. O doručení 17 a správnou distribuci zpráv mezi aplikace se stará MOM. Ten mimo jiné dále zprostředko- vává také odolnost proti chybám, vyvažování zátěže, rozšiřitelnost a podporu transakcí pro systémy, které si potřebují spolehlivě vyměňovat velké počty zpráv. [28] Výměna zpráv v moderních EMS probíhá přes virtuální kanály, pro které se používá označení destinace (viz 4.2.2). Pokud chce jedna aplikace komunikovat s jinou, neadresuje konkrétní zprávu přímo své protistraně, místo toho ji zašle do příslušné destinace. Každá aplikace, která má o příjem zpráv zájem, se registruje jako odběratel dané destinace. Ode- silatel a příjemce tak nejsou pevně svázáni a mohou přijímat i odesílat zprávy podle vlastní potřeby. [28] 4.1.1 Architektura EMS V praxi se můžeme setkat s centralizovanou i distribuovanou architekturou. Centralizovaná architektura je závislá na message serveru (message router, message broker), který je zod- povědný za doručování zpráv mezi klienty. Klient vždy vidí pouze server, kterému předává zprávy k doručení, nikoliv klienta, se kterým komunikuje. [22, 28] Tato architektura je znázorněna na obrázku 4.1. Obrázek 4.1: Centralizovaná architektura EMS, pro kterou se typicky používá topologie hvězda, tj. centrální server, k němuž jsou připojení všichni klienti. (Převzato z [28]) V případě decentralizované architektury jsou úkoly message serveru delegovány na kli- entské stanice. Pro doručení zpráv na síťové vrstvě v současné době všechny decentralizované architektury používají IP multicast. [28] 4.2 Java Message Service Java Message Service (JMS) je API pro EMS vytvořené společností Sun Microsystems. Jedná se spíše o abstrakci rozhraní a tříd nutných pro výměnu zpráv mezi klienty než 18 o samotný messaging systém. Smyslem tohoto API je poskytnout Java aplikacím stan- dardní programovací model, který je nezávislý na messaging systémech. Aplikace mohou tyto systémy využívat k zasílání notifikací o událostech nebo vzájemné výměně dat. [10, 28] Využívání možností JMS není striktně omezeno jen na Javu. Podporu pro práci s tímto API dnes nalezneme pro většinu běžných programovacích jazyků jako například C/C++, C# nebo i OpenEdge ABL. [17] JMS API nabízí dva standardní modely pro komunikaci: publish-and-subscribe a point- to-point. [10, 17, 22, 28] Tyto modely a jejich specifické přínosy budou podrobněji popsány v části 4.2.2. 4.2.1 Pojem zprávy JMS zprávy mohou buď nést důležitá data, nebo sloužit pouze jako notifikace o události v systému. Každá zpráva má tři základní části: 1. tělo zprávy nesoucí její data, 2. hlavičky s důležitými metadaty o zprávě, 3. vlastnosti nastavované programátorem se stejnou strukturou jako hlavičky. Hlavičky jsou v principu realizované jako dvojice klíč-hodnota, přičemž klíč je pevně definován. O jejich nastavení se obvykle stará implementace JMS. Typicky v nich nalezneme informace nutné pro směrování zprávy, jejího autora a ID, typ apod. [10, 17, 28] Na základě hodnot uložených v hlavičkách a vlastnostech zprávy (nikoliv v jejich těle) je také možné zprávy filtrovat s využitím tzv. message selectorů. JMS konzument se tak může rozhodnout, jestli danou zprávu zkonzumuje či nikoliv. [17, 28] Typy JMS zpráv V JMS rozlišujeme podle typu nesených dat celkem šest typů zpráv, které musí být podpo- rovány každým JMS poskytovatelem. Popis těchto typů nalezneme ve zdrojích [10, 17, 28]. V praxi se však můžeme setkat i s různými rozšířeními JMS o nové typy ze strany konkrét- ních implementací JMS (viz 4.3). Standardní typy jsou následující: • Message – nejjednodušší typ zprávy, který slouží jako základní rozhraní a ze kterého jsou odvozeny ostatní typy. Zprávy tohoto typu obsahují pouze hlavičky a vlastnosti a mohou tedy být použity jako JMS zprávy bez těla. Obvykle se používají pouze pro notifikaci. • TextMessage – tento typ se používá pro zprávy nesoucí řetězec textových dat, tj. typ String, který je typicky nestrukturovaný. Je však možné jej použít i pro výměnu komplexnějších dat jako například XML dokumentů. • ObjectMessage – datovým obsahem této zprávy je serializovatelný Java objekt. Díky tomuto typu je možná výměna objektů mezi aplikacemi, avšak jak odesilatel, tak příjemce musí mít přístup k definici třídy, jejíž instancí přenášený objekt je. Aby tedy byla výměna možná, obě komunikující strany musí být programy v Javě. • ByteMessage – pokud potřebujeme zaslat data v nativním formátu aplikace, který není kompatibilní s žádným standardním typem, použijeme zprávu ByteMessage, je- jímž obsahem jsou neinterpretované byty. Obvykle se jedná o situace, kdy JMS vyu- žíváme čistě jako prostředek pro přenos dat mezi dvěma systémy. 19 • StreamMessage – je typ nesoucí sérii primitivních datových typů, jako například int, char, double atd. Tyto typy jsou ze zprávy čteny ve stejném pořadí jako byly zapsány a je prováděna i typová kontrola. • MapMessage – jako svůj obsah nese zpráva tohoto typu množinu dvojic jméno- hodnota. Hodnoty těchto dvojic mohou být primitivní datové typy nebo typ String. 4.2.2 Modely komunikace Jak již bylo zmíněno v úvodu této sekce, při práci s JMS se setkáváme se dvěma modely zasílání zpráv: • publish-and-subscribe (pub/sub), • point-to-point (ptp) U obou modelů platí, že mezi komunikujícími klienty nejsou žádné pevné vazby. Jak odesilatelé, tak příjemci mohou být dynamicky přidáváni a odebírání, díky čemuž se může v průběhu času zvětšovat nebo zmenšovat komplexnost celého systému. Modely a jejich charakteristiky jsou popisovány na základě informací z [10, 17, 28]. Publish-and-subscribe Princip modelu publish-and-subscribe spočívá v tom, že jeden producent může zaslat zprávu více konzumentům s využitím virtuálního kanálu neboli destinace (viz obrázek 4.2). V pří- padě pub/sub modelu se pro destinaci používá označení topic. Významné charakteristiky tohoto modelu jsou následující: 1. Zprávy zaslané do topicu jsou doručeny všem klientům, kteří jsou zaregistrovaní k od- běru. 2. Pro doručení zpráv je použit push model, což znamená, že zprávy jsou automaticky zaslány příjemcům, aniž by si o ně museli zažádat. 3. Každý klient přihlášený k odběru topicu obdrží svou vlastní kopii zprávy, která do něj byla odeslána. Obrázek 4.2: Komunikační model publish-and-subscribe. (Převzato z [28]) 20 Point-to-point Jak je ukázáno na obrázku 4.3, model point-to-point implementuje pro změnu komunikaci jeden s jedním, tj. každá zpráva má maximálně jednoho příjemce. Virtuální kanál využívaný v tomto modelu se nazývá fronta. Hlavní charakteristiky tohoto modelu jsou tedy tyto: 1. Přestože k frontě může být připojeno více klientů, zpráva je doručena vždy právě jednomu z nich. 2. Komunikace může být synchronní nebo asynchronní. 3. Zprávy jsou doručovány buď na žádost klienta s využitím pull modelu, nebo automa- ticky v případě push modelu. 4. Fronta zprávy doručuje ve stejném pořadí, v jakém jsou do ní zasílány. Toto pořadí může být ovlivněno prioritami zpráv. Obrázek 4.3: Komunikační model point-to-point. (Převzato z [28]) 4.2.3 Praktické aspekty JMS API Pokud pro zasílání zpráv používáme JMS, budeme nejprve vytvářet spojení (connection), které identifikuje aplikaci a určuje, jak bude server s klientem nakládat, a v rámci něj následně vytvoříme jedno nebo více sezení (session). Po vytvoření sezení může klientská aplikace produkovat nebo konzumovat zprávy. [17, 22] Jakým způsobem je spojení se ser- verem zapouzdřeno, ukazuje obrázek 4.4. Obrázek 4.4: Spojení aplikace s message serverem. O zapouzdření spojení se stará objekt ConnectionFactory. (Převzato z [22]) 21 Po vytvoření sezení odesilatelé zasílají své zprávy do virtuálních kanálů (destinací ), příjemci je pak z těchto destinací získávají. [17, 22] Pro implementaci synchronní komunikace může klientská aplikace použít mechanismus Request/Reply, což znamená, že po odeslání zprávy čeká producent na odpověď. Aby bylo možné odpověď doručit, vytvoří pro ni producent tzv. dočasnou destinaci a její identifikátor odešle v hlavičce zprávy. [17, 22] Tyto destinace jsou vytvářeny dynamicky a jejich životnost je spojená se spojením, do kterého patří sezení, v rámci něhož byly vytvořeny. Je také zaručena unikátnost destinace napříč všemi spojeními. [28] 4.3 SonicMQ Progress SonicMQ představuje certifikovanou implementaci JMS, která umožňuje využívat komunikační modely ptp a pub/sub. Díky velké škálovatelnosti umožňuje rychlé zvětšování topologie a prudké výkyvy v objemu zasílaných zpráv. Dále také zavádí nové typy zpráv, konkrétně XML message a Multipart message. [17] SonicMQ je založen na topologii hvězda, která chápe všechny entity připojené do topo- logie jako klienty s výjimkou centrálního serveru neboli SonicMQ brokeru, ke kterému se všichni klienti připojují a přes který probíhá výměna zpráv. Pro komunikaci se severem lze využít následující protokoly: • TCP – implicitní typ socketu pro SonicMQ, • SSL – SonicMQ podporuje kódování na úrovní spojení s využitím SSL, • HTTP – kromě navázaní a udržování spojení klienta se serverem může být HTTP využito i pro interakci SonicMQ s čistě webovými aplikacemi, • HTTPS – zabezpečená verze služeb HTTP. [22] Destinace jsou reprezentovány objektem Destination. Jedná se o pojmenované lokace, do kterých mohou klienti zasílat zprávy a které jsou vždy buď typu fronta, nebo topic. Je možné poslat zprávu do dynamicky definovaného topicu i staticky definované fronty se stejným jménem. Server totiž rozlišuje, jakého typu je cílové destinace, tj. buď topic, nebo fronta. [17] 4.3.1 Zprávy v SonicMQ SonicMQ zpráva je balík dat, který zapouzdřuje tělo zprávy a vystavuje navenek metadata, která identifikují cílovou destinaci, prioritu, časové razítko a další. Jak můžeme vidět na obrázku 4.5, kromě pěti typů zpráv odvozených od společného předka Message, které jsou dané JMS specifikací, nabízí SonicMQ také rozšíření v podobě následujících dvou typů: 1. XMLMessage – rozšiřuje typ TextMessage, její tělo obsahuje standardní TextMessage s XML tagy, která je zpracovatelná buď jako validní XML DOM nebo s využitím SAX, 2. MultipartMessage – tělo této zprávy obsahuje jednu nebo více částí. Každá část může představovat například standardní zprávu (objekt Message), primitivní typy jako XML, HTML nebo data v libovolném jiném MIME formátu. Každá část má svoji hlavičku, ve které jsou dvojice jméno/hodnota určující například typ obsahu, a obsah. 22 Obrázek 4.5: Hierarchie typů zpráv v SonicMQ. (Převzato z [22]) Pokud zprávě vyprší její platnost nebo ji SonicMQ označí za nedoručitelnou, nazveme ji mrtvou zprávou. Pro tyto zprávy nabízí SonicMQ tzv. Dead Message Queue (DMQ), která usnadňuje jejich obsluhu. Co se týče struktury samotné zprávy, můžeme zde rozlišit standardní prvky definované v JMS specifikaci, konkrétně hlavičky, uživatelem definované vlastnosti a tělo. Kromě těchto polí využívá SonicMQ ještě poskytovatelem definované vlastnosti, tj. vlastnosti definované SonicMQ, které nesou informace potřebné k využívání rozšířených vlastností nabízených touto implementací. Jako příklad můžeme uvést hlavičku definující typ zprávy včetně nově zavedených typů nebo hlavičky informující jak nakládat s nedoručitelnými zprávami. 23 Kapitola 5 Podniková sběrnice služeb Sonic ESB Abychom se mohli zabývat podnikovou sběrnicí služeb (enterprise service bus, ESB) a je- jím významem, je nutné nejprve stručně vysvětlit pojem servisně orientovaná architektura, který s ní úzce souvisí. Servisně orientovaná architektura (SOA) je model architektury založený na konceptu služeb. [15, 30] Službou v tomto kontextu rozumíme samostatnou bezstavovou funkci, která je dostupná přes standardizované rozhraní nezávislé na imple- mentaci. [7, 15] Primárním cílem SOA je převést různorodé IT zdroje v obchodním prostředí na mno- žinu centrálně spravovaných služeb. Tento přístup vytváří základ pro tvorbu aplikací, které umožňují znovupoužití a kombinaci existujících služeb za účelem tvorby komplexnější lo- giky. S využitím SOA je možné vytvořit distribuované prostředí, ve kterém spolupracuje velké množství aplikací bez ohledu na jejich geografické umístění, platformu, použitý datový model nebo jazyk, ve kterém jsou napsány. [7, 15, 30] V typické SOA aplikaci poskytovatelé registrují své služby u centrální služby Naming Service. Klientské aplikace pak u ní vyhledávají dostupné služby a získávají informace o tom, jak s nimi komunikovat. [15] V následujících částech této kapitoly představíme praktickou realizaci servisně oriento- vané architektury prostřednictvím podnikové sběrnice služeb. Základní principy ESB budou vysvětleny a demonstrovány na produktu Sonic ESB, implementaci ESB od Progress Soft- ware. 5.1 SOA implementovaná sběrnicí ESB ESB nabízí distribuovanou, událostmi řízenou servisně orientovanou architekturu, která v sobě kombinuje zasílání zpráv, webové služby, datové transformace a inteligentní smě- rování za účelem spolehlivého propojení a koordinace interakce mezi různými aplikacemi napříč společností a jejími obchodními partnery. [7, 15, 27] Jak můžeme vidět na obrázku 5.1, ESB na rozdíl od tradiční topologie hvězda vyu- žívá flexibilní topologii založenou na sběrnici. Jakmile jsou jednou aplikace vystaveny na sběrnici, je možné je snadno vzájemně propojovat s ostatními. [7, 15, 30] Zároveň si také můžeme všimnout čtyř základních komponent v architektuře ESB: 1. Komunikační páteř – zajišťuje konektivitu mezi službami. 24 Obrázek 5.1: Architektura ESB. Služby jsou připojeny ke sběrnici (komunikační páteř) přes jednotné rozhraní (kontejner) bez ohledu na jejich implementaci. (Převzato z [30]) 2. Konfigurační repozitář – centralizované úložiště všech metadat potřebných v sy- tému. V Sonic ESB se tento repozitář označuje jako Directory Service. [30] 3. Kontejnery – budou probrány v 5.2.2. 4. Služby – budou probrány v 5.2.3. Komunikační páteř leží na nejnižší, fyzické vrstvě, která bývá obvykle reprezentována messaging systémem. Tato vrstva je pak řízena pravidly definovanými ve vyšších vrst- vách. [7, 15, 27, 34] V případě Sonic ESB je jako komunikační páteř použita implementace JMS SonicMQ [27, 30], která byla probrána v sekci 4.3. Nad fyzickou vrstvou pak leží ESB framework, jehož cílem je vytvářet, distribuovat, spouštět a spravovat služby. Kromě uvedených vrstev je možné se v ESB setkat i s dalšími nadstavbovými vrstvami. [34] Tyto vrstvy však nejsou důležité pro účely této práce, a proto se jimi nebudeme podrobněji zabývat. O celý běh Sonicu, tj. jak SonicMQ, tak Sonic ESB se stará tzv. Domain Manager. [27] Ten má na starost řízení Directory Service a je zodpovědný za veškerou konfigurační komu- nikaci s ním. Prostřednictvím Domain Manageru je možné přes nástroj Sonic Management Console vytvářet kontejnery, řídit jejich životní cyklus, přiřazovat jim služby, spravovat zdroje Sonicu apod. 25 5.1.1 Komunikace v ESB Komunikace mezi jednotlivými službami připojenými k ESB je založena na zasílání zpráv. Tyto zprávy přenášejí požadavky a následné odpovědi od jedné služby k druhé. [3] Každá zpráva v Sonic ESB je typu XQMessage, což je rozhraní v jazyce Java podobné typu Multi- partMessage v SonicMQ. Toto rozhraní umožňuje přístup k hlavičkám a jednotlivým částem zprávy. [27, 30] Obsah zprávy může být soubor XML nebo obecná binární data. [3, 7] Preferovaným formátem v ESB je však XML. Data, která jsou v systému produkována a konzumována mohou existovat ve velkém množství různých formátů. Přestože je možné přenášet přes ESB data v jakékoliv formě, využití jednotného formátu XML s sebou nese spoustu výhod jako například možnost využívat speciální ESB služby pro kombinaci dat z různých zdrojů, jejich transformaci, vložení nových hodnot nebo jejich přesměrování (viz 5.3). [7] Služby v ESB vytvářejí ESB zprávy, které jsou následně zasílány na stanovené ESB adresy. ESB adresa reprezentuje pojmenovanou destinaci, na které příjemce čeká na příchozí zprávu. Pokud odesilatel požaduje odpověď na svoji zprávu, je součástí metadat zprávy i adresa pro zaslání odpovědi. [3] Každá ESB adresa může být jednoho z následujících typů, jak udávají [3, 30]: • ESB endpoint – abstrakce pro destinace transportní vrstvy (viz 5.2.1). • ESB služba – odkazuje přímo na jméno služby, má stejný význam jako odkaz na vstupní endpoint této služby. • ESB proces – posloupnost služeb zakomponovaná do komplexnějšího procesu (viz 5.2.4). 5.2 Klíčové prvky v Sonic ESB V následující části kapitoly si vysvětlíme jednotlivé komponenty, se kterými se setkáme při návrhu a tvorbě ESB aplikací. Informace o nich byly čerpány primárně ze zdrojů [3, 7, 27, 30]. Jako doplňující zdroje byly dále použity [18] pro endpointy a kontejnery, [20] pro služby a [34] pro procesy. 5.2.1 ESB Endpointy ESB endpointy umožňují komunikaci mezi jednotlivými službami. Endpoint představuje pojmenovanou destinaci, přes kterou ESB služba odesílá a přijímá zprávy. Jedná se tedy o její primární komunikační rozhraní. Aplikace přistupují ke službám odesíláním požadavků do jejich vstupních endpointů. Díky využití tohoto mechanismu je možné přesunout část transportní logiky ze služeb do lépe konfigurovatelného ESB. Za každým endpointem leží na nižší vrstvě některá z JMS destinací, tj. topic nebo fronta, ke kterým ESB framework přistupuje přes SonicMQ broker. Rozlišujeme čtyři typy endpointů: • Vstupní endpoint – přijímá zprávy, které jsou následně zpracovány službou. Každá přijatá zpráva způsobí jedno spuštění implementace služby. • Výstupní endpoint – představuje poslední destinaci při vykonávání ESB procesu nebo služby, do které je vygenerována odpověď na příchozí zprávu. Zprávy z tohoto endpointu mohou být zaslány jak další službě, tak odesilateli původního požadavku. 26 • Chybový endpoint – volitelný endpoint služby nebo procesu, jehož úkolem je ob- sluha odstranitelných chyb a přerušení, které je nutné řešit na aplikační úrovni. O za- slání zprávy do chybového endpointu se rozhoduje na úrovni služby. • Rejected endpoint – Zachytává zprávy, které jsou nevalidního typu pro daný proces, způsobily výjimku v průběhu vykonávání služby nebo je z nějakého důvodu není možné doručit. O zaslání zprávy do chybového endpointu se rozhoduje na úrovni ESB frameworku. 5.2.2 ESB kontejnery ESB kontejnery jsou základní stavební prvky architektury v Sonic ESB. Jedná se o samo- statnou komponentu, jejíž primární cíle jsou: • řídit životní cyklus služeb, • poskytovat službám běhové prostředí. Kontejner dále také navazuje spojení s jednotlivými JMS destinacemi, tj. endpointy, čímž izoluje služby od zbytku ESB infrastruktury. Konfigurační informace získává od cent- ralizovaného Directory Service, který v případě změn konfigurace zašle kontejneru notifikaci. ESB kontejner dále poskytuje podporu pro přístup k logovacím souborům služeb, které pod něj spadají. Jednou ze základních komponent každého kontejneru je také logika tzv. dispečera, je- hož úkolem je zajištění příjmu a odesílání ESB zpráv, spuštění služby, na jejíž vstupní endpoint dorazila zpráva, a interpretování itineráře zprávy (viz 5.2.4) při zpracování ESB procesu. Tento přístup umožňuje soustředit se při vytváření služby především na její logiku, aniž by bylo třeba starat se zpracování itineráře a směrování odchozích zpráv nebo jejich transformace, případně zotavení z chyb. 5.2.3 ESB Služby V Sonic ESB je služba chápána jako klient přijímající a odesílající zprávy, který může být použit samostatně nebo jako součást jednoho nebo více procesů. Veškerá aplikační logika zůstává uvnitř služby. Konkrétní běžící služba je instance některého typu služby. Typ služby se skládá z třídy v jazyce Java, která definuje konkrétní operace prováděné službou, a XML soubor, který popisuje inicializační a běhové parametry služby. Konfigurace služby je pak specifické použití jejího typu s nakonfigurovanými endpointy a inicializačními parametry. Každá služba je spravována ESB kontejnerem, který zajišťuje její konektivitu s messa- ging systémem na nižší úrovni a stará se o její životní cyklus. Vstup je službě předán ve formě XQMessage zprávy, její výstup je pak opět ve formě XQMessage. Na obrázku 5.2 je ukázáno, jakým způsobem probíhá příjem a zpracování zprávy služ- bou. Postupně proběhnou následující kroky: 1. Zpráva je přijata vstupním endpointem příslušné služby, kde je převedena do formátu XQMessage. 2. Dispečer kontejneru se postará o její přesunutí do inboxu adresované služby, čímž dojde k její iniciaci. 27 Obrázek 5.2: Cesta zprávy přes ESB kontejner. 3. Služba příjme zprávu a vykoná nad ní požadované operace. 4. Na základě výsledku prováděných operací jsou vygenerovány příslušné odchozí zprávy do outboxu, respektive faultboxu služby. 5. Dispečer umístí odchozí zprávy do příslušných endpointů na základě jejich adres. 6. Zprávy jsou v endpointech převedeny do vhodného formátu a odeslány do svých destinací. Pokud mluvíme o inboxu, outboxu a faultboxu, máme vždy na mysli kolekci zpráv spra- vovanou dispečerem, ze které si služba vyzvedává příchozí zprávy a kam umisťuje odchozí. 5.2.4 ESB procesy Pojmem proces v ESB rozumíme posloupnost služeb, přes které přijatá zpráva postupně projde. Řízení procesu v ESB může představovat jak jednoduchou sekvenci o několika kro- cích, tak sofistikovaný obchodní proces s paralelním vykonáváním několika větví procesů využívající podmíněné větvení a opětovné spojování. Příklad jednoduchého procesu je uká- zán na obrázku 5.3. Nejběžnější případy, co může udělat jeden krok, jsou: • spustit jednu nebo více služeb, • spustit jeden nebo více jiných procesů, • vybrat jednu z více větví procesu, která bude vykonána, • rozdělit proces na více paralelních větví. Celý proces je distribuovaný na sběrnici, avšak jeho definice je centralizovaná v Directory Service a kterákoliv služba nebo endpoint běžící v ESB kontejneru jej může adresovat. Proces může být typicky vystaven navenek jedním z následujících způsobů: • jako adresa na sběrnici, • přes JMS požadavky, • jako webová služba, • přes HTTP požadavky. 28 Obrázek 5.3: Jednoduchý ESB proces v nástroji Sonic Workbench. Zpráva postupně putuje službami Service 1 až 3. Kruhy na začátku a na konci označují vstupní a výstupní endpointy procesu. (Převzato z [27]) Stejně jako služby musí být i procesy umístěny do ESB kontejneru. Zpráva do procesu vstupuje vždy přes vstupní endpoint jeho prvního kroku. Po zpracování zprávy dojde k je- jímu přeposlání na vstupní endpoint následující služby nebo kroku. Pokud zpráva dorazí do poslední destinace, je odeslána do výstupního endpointu celého procesu. Itinerář procesu Jak již bylo zmíněno dříve, proces je definován posloupností kroků. Tato posloupnost se nazývá itinerář. Itinerář je připojen ke zprávě v momentě, kdy dorazí do daného ESB procesu. Zpráva jej pak nese s sebou po dobu celé její cesty k cílové destinaci. Vyhodnocení itineráře provádí příslušný ESB kontejner v každém kroku ESB procesu, na základě čehož je pak spuštěna vhodná další služba nebo vnořený proces. Tento přístup eliminuje nutnost existence centrální jednotky, se kterou by musela každá služba navazo- vat kontakt a zjišťovat, kam má být zpráva přeposlána. Řízení procesu je tak kompletně distribuované. Mapování polí zpráv Mapování zpráv určuje, jak běžící proces čte data například z příchozí XQMessage, podle po- třeby je transformuje a následně výsledná data mapuje na cíl, což může být opět XQMessage. Díky tomu je možné řešit tyto problémy na úrovni ESB procesů místo uvnitř implementace služeb, čímž se zjednodušuje proces jejich vytváření a integrace. Jako možné akce, které lze s daty při mapování provést, si uvedeme následující zástupce: • XPath – transformace zdrojových dat s využitím XPath výrazu, 29 • Přidání částí – zkopírování částí nebo hlaviček ze zdrojové XQMessage do cílové bez jejich modifikace. Tato akce je použitelná jen pokud mapováním vytváříme zcela novou XQMessage. • Odebrání částí – části původní XQMessage jsou odebrány a neobjeví se v cílové. Akci lze použít, pokud jako odpověď přebíráme původní zprávu. 5.3 Přehled vestavěných služeb V poslední části kapitoly o podnikové sběrnici služeb Sonic ESB budou představeny zá- kladní typy vestavěných služeb, které Sonic nabízí. Služba Sonic Connect umožňující volání webových služeb a zpřístupnění ESB procesů jako webové služby bude podrobněji popsána v části 7.4.1. Informace uváděné v této sekci byli čerpány především ze zdrojů [20, 30], jako vedlejší zdroje byli dále použity [7, 27, 34]. 5.3.1 Směrování a transformace Směrování podle obsahu (content based routing, CBR) umožňuje definovat službu, která prochází obsah přijatých zpráv, a následně směruje tyto zprávy k různým procesům, službám nebo endpointům na základě informací získaných z jejich hlaviček a těl. Mezi základní charakteristiky CBR typicky patří následující: • Směruje zprávy na jednu nebo více ESB adres. • Směrování je založené na komplexních pravidlech. • Nemění obsah směrované zprávy. Pravidla, která tato služba využívá ke směrování zpráv, mohou být definována jako jed- noduchý XML dokument využívající XPath výrazy, nebo v případě náročnějšího směrování jako soubor v jazyce JavaScript. Pravidla CBR podporují výrazy a podmínky. Pokud je podmínka vyhodnocena jako splněná, je daná zpráva odeslána odpovídající cestou. Kromě směrování zpráv podporuje Sonic ESB také jejich transformaci. Služba XML transformace slouží k převodu obsahu zprávy na zprávu s jiným formátem na základě XSLT souboru, který je službě předán jako její parametr. Stejným způsobem je možné modifikovat, vytvářet, případně mazat i hlavičky transformované zprávy. XSLT dále umožňuje vytvoření více výstupních XML zpráv z jedné vstupní a jejich odeslání do příslušných destinací. 5.3.2 Split and Join Principem služby Split and Join je udělat z jedné vstupní zprávy více výstupních, nad každou z nich provést potřebné operace a jejich výsledek opět spojit do jedné zprávy. V Sonic ESB jsou k dispozici dva typy této služby: 1. Split and Join Parallel, 2. Split and Join ForEach. Split and Join Parallel vytvoří několik kopií příchozí zprávy a každou z těchto kopií odešle na jednu adresu, přičemž každá adresa reprezentuje jinou ESB službu nebo pro- ces. Po obdržení odpovědí od všech adresátů provede složení výsledků do jedné výsledné 30 zprávy. Tuto službu je vhodné použít v situacích, kdy je třeba nad zprávou provést několik nezávislých operací a jejich výsledek pak spojit do jediné zprávy. Split and Join ForEach na rozdíl od předchozí varianty nekopíruje příchozí zprávu, ale rozděluje ji na několik částí. Jejich počet je možné určit dynamicky. Každá z těchto částí je následně odeslána na jednu stejnou adresu ke zpracování. Výsledky pro jednotlivé části zprávy jsou poté opět shromážděny a spojeny do jedné výsledné zprávy. Tento přístup se používá v situacích, kdy je třeba vykonat stejnou operaci nad různými částmi zprávy. 5.3.3 Služby pracující nad soubory Pro manipulaci se soubory nabízí Sonic ESB dvě jednoduché služby: • File pickup, • File drop. Přestože je možné setkat se i s dalšími službami pracujícími nad soubory, v rámci této práce stručně probereme jen uvedené dvě. Služba File pickup slouží ke zkopírování obsahu zadaného souboru do odchozí zprávy vhodného typu. Kromě samotného obsahu souboru jsou do vlastností zprávy vloženy také jeho metadata. File pickup může zahájit svou činnost buď na základě přijetí zprávy, nebo provádí kontrolu souborů určených ke zpracování periodicky v pravidelných intervalech. Služba File drop pak provádí inverzní činnost ke službě File pickup, tj. kopíruje obsah příchozí zprávy do nového souboru na specifikované místo na lokálním souborovém systému. Službu je možné nakonfigurovat tak, aby nevytvářela nové soubory, ale přidávala data na konec existujícího souboru. 31 Kapitola 6 OpenEdge ABL Programovací jazyk OpenEdge Advanced Business Language (ABL), dříve Progress 4GL nebo jen PROGRESS [32], je vysokoúrovňový procedurální a objektově orientovaný pro- gramovací jazyk, umožňující výstavbu aplikací od uživatelského rozhraní až po přístup k databázi. Jazyk ABL je používán v rámci Progress OpenEdge, což je sada vývojových nástrojů pro vytváření dynamických, jazykově nezávislých aplikací a jejich nasazení na li- bovolné platformě. [19, 25] V mírně pozměněném prostředí OpenEdge je vytvořen i ERP systém proALPHA. Z toho důvodu bude jazyk ABL také hlavním implementačním jazykem této práce. Základní charakteristiky jazyka uváděné v [19, 25] jsou následující: • Procedurální jazyk – program je tvořen množinou příkazů, které mohou být uloženy v samostatných procedurách. Příkazy se skládají z jednoho nebo více klíčových slov jazyka ABL a případně parametrů. • Blokově strukturovaný – příkazy mohou tvořit bloky, tj. sekvence jednoho nebo více příkazů, případně zanořených bloků, které sdílejí určité zdroje. • Interpretovaný – zdrojový kód programu je přeložen do platformově nezávislého runtime kódu (r-code), který je následně interpretován ABL Virtual Machine (AVM). Další důležitou součástí OpenEdge je také AppServer, který se stará o spouštění ABL procedur jako odpověď na žádost klientů přes síť. Díky němu je možné vytvářet komplexní distribuované aplikace tím, že umožníme klientům spouštět ABL procedury a funkce vzdá- leně stejným způsobem, jako kdyby běžely na lokální stanici klienta. Vzdálenou procedurou, respektive funkcí tedy rozumíme proceduru nebo funkci spouštěnou na AppServeru oddě- leně od klienta a typicky na jiné stanici, než na které běží klient. [26] V dalších částech této kapitoly probereme praktické aspekty jazyka OpenEdge ABL, které budou relevantní pro tuto práci. Konkrétně se jedná o vysvětlení pojmu procedur a funkcí a manipulace s daty, které čerpají ze zdrojů [19, 25], dále bude následovat představení datových struktur temporální tabulka a ProDataSet popsaných v [25, 29], možností práce s XML dokumenty, kterou se podrobně zabývá [24] a nakonec zmíníme adaptéry uváděné v [23], které umožňují komunikaci ABL se Sonic ESB a SonicMQ. 6.1 Procedury a funkce Na rozdíl od většiny běžně používaných programovacích jazyků jazyk ABL striktně rozlišuje pojmy procedura a funkce. Zatímco funkce transformuje hodnoty parametrů na návratovou 32 hodnotu nějakého datového typu, procedura pouze vykoná určitý úsek kódu na základě parametrů, které jsou jí předány. O spouštění procedur se stará příkaz RUN, kterému jsou také předávány jejich parametry. Každý parametr má datový a typ a jeden ze tří typů parametru: • INPUT – je předán do procedury hodnotou. • OUTPUT – je proměnná, do níž bude zapsána hodnota při vykonávání procedury. Pů- vodní hodnota parametru se nepředává. • INPUT-OUTPUT – je kombinací předchozích dvou typů. Jedná se o klasické předání parametru odkazem. Přestože hlavní komunikace procedury s jejím okolím probíhá přes parametry, je možné využít také její návratovou hodnotu. V případě ABL procedruy se ale jedná pouze řetěz- covou hodnotu vracenou příkazem RETURN, kterou je ve volající proceduře možné získat příkazem RETURN-VALUE. Typické použití je pro indikaci úspěchu a neúspěchu procedury. Existují dva typy procedur: • externí procedury, • interní procedury. 6.1.1 Externí procedura Blok externí procedury je tvořen textovým souborem s libovolným počtem příkazů, který lze zkompilovat jako samostatnou jednotku spustitelnou příkazem RUN. Jedná se o nejzá- kladnější blok jazyka ABL a lze v něm použít kterýkoliv typ příkazu nebo bloku. Externí proceduře je možné definovat jeden nebo více vstupních bodů v podobě interních procedur a funkcí. Na externí procedury můžeme nahlížet jako na určitý typ knihovny. Typicky je pou- žijeme pro zapouzdření množiny souvisejících funkcí a procedur nebo rozsáhlé komplexní procedury, která funguje jako samostatný celek. Abychom mohli externí proceduru využívat jako knihovnu funkcí, je nutné ji zavolat perzistentně pomocí možnosti PERSISTENT příkazu RUN jak demonstruje následující příkaz: RUN h-FuncProc.p PERSISTENT SET hFuncProc. Při tomto volání proběhne inicializace proměnné hFuncProc datového typu HANDLE. Ten můžeme chápat jako ukazatel, respektive popisovač objektu jazyka ABL, například právě externí procedury. Perzistentně zavolaná procedura a její datový kontext zůstávají uloženy v paměti. 6.1.2 Interní procedura Pro definici bloku interní procedury použijeme příkaz PROCEDURE následovaný jejím jmé- nem. Za ním je pak uveden výčet parametrů procedury, jejich typů (INPUT, OUTPUT, . . .) a datových typů. Interní procedura je vždy kompilována jako část externí procedury a může obsahovat kterýkoliv typ příkazu nebo bloku kromě další interní procedury. Pokud chceme zavolat interní proceduru definovanou externě, uvedeme v příkazu RUN handle externí procedury, ve které se její definice nachází: RUN myProc IN hFuncProc (par1, par2). 33 6.1.3 Funkce Funkce jazyka ABL se ničím neliší od funkcí jiných jazyků, tj. volá se uvedením jejího jména, za kterým následuje seznam parametrů. Ty jsou pak funkcí transformovány na návratovou hodnotu. Díky tomu je možné uvést volání funkce na libovolném místě, kde je očekávána proměnná nebo výraz stejného datového typu. Funkce mohou být definovány lokálně, v externí proceduře nebo vzdáleně. Pokud funkci definujeme jinak než lokálně, je třeba uvést na začátku procedury její deklaraci. Následující příklad deklaruje funkci myFunc, která je definována v objektu (například externí proceduře) jehož handle je uložen v proměnné hFuncProc: FUNCTION myFunc RETURNS DECIMAL (INPUT par1 AS DECIMAL) IN hFuncProc. 6.2 Přístup k databázi Jazyk OpenEdge ABL nabízí sadu příkazů a funkcí pro co nejjednodušší manipulaci se záznamy databáze. Jako nejběžnější příklad se uvádí konstrukce, která má obdobný význam jako SQL příkaz SELECT * FROM Customer, konkrétně FOR EACH Customer: DISPLAY Customer. END. Příkaz FOR EACH otevírá blok kódu, ve kterém proběhne dotaz na databázi a získání všech záznamů zadané tabulky. V každé iteraci tohoto bloku máme k dispozici jeden ze získaných záznamů a pomocí DISPLAY provedeme jeho zobrazení uživateli. FOR EACH je možné doplnit také klauzulí WHERE specifikující podmnožinu záznamů. Jako alternativu ke klíčovému slovu EACH lze použít FIRST a LAST, které z tabulky získají první, respektive poslední odpovídající záznam. Další možnost přístupu k položkám databáze je s využitím příkazu FIND, který vrací jeden záznam tabulky. Tento příkaz lze kombinovat se zmiňovanými klíčovými slovy FIRST a LAST a dále také s NEXT a PREV pro přechod na sousední záznam. Stejně tak je možné aplikovat na výběr omezení v podobě klauzule WHERE. Jestli bylo hledaní úspěšné či nikoliv, můžeme zjistit vestavěnou funkcí AVAILABALE. Kdykoliv se procedura snaží získat záznam z tabulky databáze, vytvoří pro ni AVM tzv. record buffer a záznam zpřístupní skrz něj. Record buffer je tedy datová struktura ne- soucí jeden záznam databázové tabulky, se kterým se aktuálně pracuje. Pro každou odka- zovanou tabulku v proceduře je vytvořen jeden implicitní record buffer se stejným jménem, jako je jméno tabulky. Record buffery je možné také definovat explicitně v případě potřeby práce s více záznamy z jedné tabulky najednou. 6.3 Temporální tabulky a ProDataSety Pro zapouzdření a práci s většími bloky dat poskytuje jazyk ABL dvě datové struktury, které se chovají stejně jako data v databázi. Tyto struktury jsou • temporální tabulka (TEMP-TABLE), • ProDataSet (DATASET). 34 Každá z nich může být vytvořená přímo na základě dat uložených databázi, definovaná programátorem nebo může vzniknout kombinací obou přístupů. Tyto datové struktury také nabízejí několik metod pro usnadnění práce s nimi. Volání metod nad objekty jazyka ABL se realizuje operátorem ":", tj. například myTempTable:WRITE-XML(). 6.3.1 Temporální tabulky Temporální tabulka poskytuje programátorovi téměř všechny vlastnosti databázové tabulky a je možné ji použít na většině míst, kde je vyžadována práce s databázovou tabulkou. Na rozdíl od databázové však temporální tabulka není perzistentní a tudíž se nikde trvale neukládá. Tyto datové struktury se typicky používají v případech, kdy potřebujeme dočasně ulo- žit několik řádků tabulky nebo předávat velké objemy dat mezi procedurami. Tabulky jsou viditelné jen v rámci sezení, které je vytvořilo nebo obdrželo jako parametr. Kromě ope- rací souvisejících s perzistencí dat a víceuživatelským přístupem je možné s nimi pracovat identickým způsobem jako s databázovými tabulkami. Temporální tabulku je možné vytvořit • nezávisle na tabulkách v databázi, • jako kopie databázových tabulek (klíčovým slovem LIKE), • podle databázové tabulky, ale s přidanými nebo přejmenovanými poli apod. Pokud je tabulka založená na databázové tabulce přebírá všechna její pole a indexy. 6.3.2 ProDataSety ProDataSety jsou objekty, které dále rozšiřují funkcionalitu temporálních tabulek. Jedná se databázi uloženou v paměti, která je naplněna množinou souvisejících záznamů potenciálně v několika tabulkách. Ve skutečnosti tedy představují kolekce jedné nebo více temporálních tabulek, které mohou volitelně obsahovat také informace o jejich vzájemných vztazích. Součástí definice ProDataSetu může být i část představující množinu vztahů, označo- vaných jako Data-Relations, z nichž každý definuje vztah mezi nadřízenou a podřízenou tabulkou této struktury. Vztahy mají podobu dvojic, které udávají jména polí v obou ta- bulkách tvořící primární a cizí klíče. Díky definici vztahů mohou být závislé tabulky vyplněny automaticky na základě dat v nadřazené tabulce bez nutnosti vytváření explicitního dotazu na databázi. Ke každému nadřazenému záznamu jsou získány všechny jeho podřízené. Každá temporální tabulka v ProDataSetu může být získána z jiného zdroje dat. V nejjednodušším případě se jedná o OpenEdge databázi případně databázi jiného typu, ke které se přistupuje s využitím prostředí OpenEdge. 6.4 Zpracování XML Standardní instalace OpenEdge zahrnuje prostředky pro čtení a zápis XML. Zároveň je možné provádět validaci dokumentu proti DTD nebo XML Schema. Jazyk ABL nabízí dvě API pro práci s XML dokumenty: • Document Object Model (DOM), 35 • Simple API for XML (SAX). Kromě těchto dvou metod ABL umožňuje i serializaci temporálních tabulek a ProData- Setů do XML a jejich opětovné načtení. K tomu slouží jejich metody READ-XML a WRITE-XML. Dále je možné exportovat i XML Schema tabulky nebo ProDataSetu a následně podle něj vytvořit prázdnou datovou strukturu. 6.4.1 SAX API Zatímco DOM reprezentuje dokument jako množinu uzlů uspořádaných do stromové struk- tury, SAX API jej rozloží do posloupnosti volání procedur. Jedná se tedy o model prou- dového zpracování, který vždy v daném okamžiku pracuje pouze s jediným elementem a umožňuje na něj reagovat pomocí callback procedury. Díky tomu má SAX menší paměťové nároky, na druhou stranu ale není možný náhodný přístup k elementům. Jazyk ABL poskytuje podporu pro SAX API prostřednictvím těchto objektů: • SAX-reader – načítá a analyzuje XML dokument, • SAX-writer – umožňuje generování XML dokumentu jako proudu znaků, • SAX-attributes – obsahuje hodnoty atributů, které se mohou v XML vyskytnout. Než začneme načítat XML dokument s využitím objektu SAX-reader, je nutné vytvořit externí proceduru, která obsahuje jednotlivé callback procedury. Ta se uloží do jeho atributu HANDLER. Po nastavení XML vstupu, je pak možné zahájit zpracování dokumentu metodou SAX-PARSE. V průběhu zpracování aplikace reaguje na události vyskytující se v XML doku- mentu pomocí zadaných callback procedur. Jako příklady nejčastějších událostí si uvedeme následující: • StartDocument – detekován začátek XML dokumentu, • StartElement – detekován začátek XML elementu, • Characters – zpracovávají se řetězcová data, • EndElement – detekován konec XML elementu, • EndDocument – detekován konec XML dokumentu. Případné atributy se předávají proceduře StartElement přes automaticky vytvořenou in- stanci objektu SAX-attributes. Vytváření nového XML dokumentu pomocí SAX-writer probíhá posloupností volání jeho metod, které otevírají, zavírají a plní jednotlivé XML elementy. Může se jednat napří- klad o následující metody: • START-DOCUMENT – vytvoří nový XML dokument • START-ELEMENT – vloží otevírající XML značku, • END-ELEMENT – vloží ukončující XML značku, • END-DOCUMENT – ukončí vytvářený dokument, • WRITE-DATA-ELEMENT – zapíše kompletní element včetně jeho obsahu. Při zpracování XML dokumentů v rámci této práce není nutný náhodný přístup k jejich elementům ani udržování zpracovávaného dokumentu v paměti. Vzhledem k nižší paměťové náročnosti tak bylo pro práci s XML upřednostněno SAX API. 36 6.5 Sonic adaptéry Součástí OpenEdge je také podpora pro připojení k messagingovému systému SonicMQ a pro vystavení ABL kódu jako služby na podnikové sběrnici služeb Sonic ESB, které byly rozebírány v částech 4.3 a 5. 6.5.1 SonicMQ adaptér Adaptér pro SonicMQ je v ABL k dispozici v podobě tří externích procedur: • ptpsession.p – sezení využívající model ptp, • pubsubsession.p – sezení využívající model pub/sub, • jmssession.p – sezení umožňující využít současně ptp i pub/sub. Tyto procedury implementují objekty využívané v JMS API, konkrétně spojení, sezení a zprávy. Nezbytnou součástí JMS komunikace v ABL je také objekt MessageConsumer. Jeho úkolem je přijímat zprávy z JMS destinací, případně asynchronní chybové zprávy. Při práci s tímto objektem aplikace typicky implementuje proceduru, která se stará o ob- sluhu příchozích zpráv, poté vytvoří instanci MessageConsumer a tuto proceduru mu předá. MessageConsumer se následně buď přihlásí k odběru topicu, nebo přijímá zprávy z fronty. 6.5.2 Sonic ESB adaptér Sonic ESB adaptér umožňuje, aby OpenEdge služba (např. program v jazyce ABL) umís- těná na sběrnici Sonic ESB mohla být zavolána třeba jako součást Sonic ESB procesu. Existují dva přístupy jak toho dosáhnout: • Nativní invokace (Native Invocation), • Webové služby – Sonic ESB zavolá aplikaci na AppServeru jako webovou službu. V případě nativní invokace volá Sonic ESB přímo aplikaci na AppServeru prostřednic- tvím služby OpenEdge Native service. Ta bere jako své běhové parametry tzv. invokační soubory s příponou .esboe vytvářené v rámci prostředí OpenEdge. Ve své podstatě se jedná se o XML dokumenty specifikující podrobnosti o tom, jakou ABL proceduru spustit a jaké parametry tato procedura očekává. Úkolem OpenEdge Native service je rovněž postarat se o namapování hodnot na tyto parametry. Tento přístup bude podrobněji probrán v 7.4.2. 37 Kapitola 7 Návrh systému pro externí přístup V předcházejících kapitolách této práce jsme nejprve rozebrali problematiku a základní principy ERP systémů a následně jsme na základě těchto poznatků zanalyzovali systém proALPHA, a to především z hlediska možností zpřístupnění jeho funkcionality pro externí klientské aplikace. V rámci této analýzy jsme rovněž vybrali správu vychystávacích návrhů jako vhodnou oblast, jejíž funkcionalitu budeme zpřístupňovat, a cestu, po které budeme do systému přistupovat, konkrétně modul INWB. Dále práce popisovala technologie, které budou pro řešení problému externího přístupu relevantní, tj. nástroje SonicMQ a Sonic ESB, na kterých je vystavěn modul INWB, a hlavní implementační jazyk systému proALPHA OpenEdge ABL. V této kapitole se budeme zabý- vat tím, jak tyto technologie spojit a využít pro vytvoření systému umožňujícího provádění operací nad daty v proALPHA prostřednictvím vzdálených klientů. Princip, na němž bude celý systém fungovat, je zachycen na obrázku 7.1. Klientské apli- kace zasílají své požadavky na systém prostřednictvím aplikačního rozhraní (API), které bude tyto požadavky transformovat do zpráv typu XQMessage využívané pro komunikaci mezi službami na sběrnici Sonic ESB (viz 5.1.1). Na základě XQMessage ESB proces identi- fikuje operaci, která má být provedena, a její parametry a postará se o spuštění příslušných ABL procedur. Po skončení operace proces rovněž vrátí klientovi vhodnou odpověď. Obrázek 7.1: Schéma navrhovaného systému pro externí přístup do systému proALPHA. Přestože Sonic ESB lze považovat za součást modulu INWB, v tomto schématu na něj nahlížíme jako na externí komponentu. Na straně systému proALPHA se pak nachází adaptér, jehož interní procedury a funkce nabízejí podporu pro manipulaci s daty v systému. Jeho úkolem je rovněž podat vhodným způsobem informace o tom, jak požadovaná operace dopadla, případně k jakým chybám při ní došlo. Část označená jako Databáze pak představuje oblast dat systému vybranou v sekci 3.2, ke kterým budeme externě přistupovat, tj. správa vychystávacích návrhů v mo- dulu materiálového hospodářství. Vychystávací návrhy se nacházejí v databázové tabulce MMT_Picking. 38 7.1 Operace nad vychystávacími návrhy Ještě před tím, než se začneme podrobně zabývat návrhem jednotlivých částí systému pro externí přístup, probereme, jaké operace jsou možné nad vychystávacími návrhy v systému proALPHA a které z nich umožníme klientům provádět přes API. Vychystávací návrhy umožňují rezervovat skladové položky v požadovaném množství a přesunout je do vychystávacího skladu, kde jsou připraveny k převzetí. Typicky se používají v situacích, kdy je třeba vychystat zboží na základě zákazníkovy objednávky, odebrat zdroje nutné pro výrobní činnost nebo při přesunu položek z jednoho skladovacího místa na jiné. Do správy vychystávacích návrhů se dostaneme s využitím navigačního panelu systému proALPHA přes položky Materiálové hospodářství → Vychystávání → Vychystávací návrhy. Zde se zobrazuje hlavní okno, popisované v sekci 3.1 s detaily jednoho vychystávacího návrhu. Na závislé okno s jeho položkami se dostaneme přes Funkce → Položky. Vychystávací návrh může být v jednom z následujících stavů vychystávání: • Nový – stav bezprostředně po vytvoření vychystávacího návrhu, dosud neproběhla žádná manipulace s jeho daty, • Ve zpracování – na návrhu se pracuje (tj. byl změněn některý z jeho údajů), • Částečně vychystaný – některé položky návrhu jsou již vychystány, ostatní na vychystání teprve čekají, • Vychystaný – všechny položky návrhu jsou vychystány. Ze zobrazených údajů o vychystávacím návrhu umožňuje hlavní okno editaci následují- cích polí: • komisionářský sklad – identifikátor vychystávacího skladu, kam budou položky návrhu přesunuty, • vychystávací místo – oblast vychystávacího skladu, do které jsou položky umístěny, • referent – uživatel zodpovědný za vychystávací návrh, • stav vychystávání – viz výše, • rozdělovník – umožňuje uživateli podle potřeby definovat klasifikaci návrhů, • číslo formuláře – identifikace šablony, která je použita pro tisk vychystávacího ná- vrhu, • počet formulářů – počet kopií k vytištění. Editace všech uvedených položek bude umožněna i v rámci demonstrace externího pří- stupu do systému proALPHA. Prostřednictvím položky menu Nástroje je možné přistoupit ještě k dalším operacím nad vychystávacími návrhy jako například zaúčtování návrhu, tj. vygenerování jeho následujícího dokumentu. Podpora pro tyto operace nebude v rámci této práce implementována. V závislém okně pak lze editovat kromě položek komisionářský sklad, vychystávací místo a stav vychystávání, jejichž význam je obdobný jako u hlavního okna, ještě následující pole: • odebrané množství – množství, které již bylo odebráno ze skladu, 39 • PDo – příznak dodávky popisující detaily dodání, např. jestli se jedná o kompletní dodávku nebo jen částečnou. I v tomto případě bude umožněna vzdálená editace všech těchto polí. Je důležité zmínit, že změny těchto hodnot rozhodně nejsou vzájemně nezávislé. Pokud například změníme stav jednoho závislého řádku položky na Vychystáno, bude jeho ode- brané množství automaticky nastaveno na hodnotu rovnu rozdílu požadovaného a dosud odebraného množství. Stav Vychystáno pak bude nastaven také hlavnímu řádku odpoví- dající položky. Obdobným způsobem se projeví i změna některého z polí samotného vy- chystávacího návrhu. Při změně vychystávacího místa tak například bude nastavena stejná hodnota také pro vychystávací místa všech položek návrhu. Kromě operací editujících uvedená datová pole vychystávacích návrhů a jejich polo- žek bude v rámci této práce umožněno také vytvoření vychystávacího návrhu na základě objednávky a mazání vychystávacích návrhů respektive jejich jednotlivých položek. 7.2 Návrh aplikačního rozhraní Při vytváření vhodného aplikačního rozhraní systému pro externí přístup je nutné brát ohled na to, že pokud mluvíme v této práci o externích klientech, máme na mysli primárně mobilní zařízení s omezenými výpočetními zdroji. Aplikace budou k systému přistupovat jako k webové službě a jak uvádějí práce [9, 33], preferovaným přístupem pro komunikaci s mobilními aplikacemi je v tomto případě využití REST arichtektury. Důvod upřednostnění RESTful webových služeb před těmi založenými na protokolu SOAP je právě otázka výkonu. Použití SOAP webových služeb může u mobilních apli- kací vést na nepřijatelně vysokou spotřebu výpočetních zdrojů, která může být způsobena například zpracováváním objemných XML zpráv, přes které SOAP komunikace probíhá. V důsledku toho je pak výkonnost celé klientské aplikace velmi nízká. Dalším důvodem pro využití REST je možnost jeho snadné a intuitivní implementace prostřednictvím ESB procesu v Sonic ESB. [21] 7.2.1 Architektura REST Ještě než se v této sekci budeme věnovat samotnému návrhu podoby aplikačního rozhraní, stručně probereme základní principy a vlastnosti, na kterých jsou RESTful webové služby založeny. Uváděné informace jsou čerpány ze zdrojů [9, 14, 21, 33]. Architektura REST nahlíží na data a funkcionalitu jako na tzv. zdroje, ke kterým je umožněn přístup přes jejich Uniform Resource Identifikátory (URI). Pro komunikaci kli- entů se serverem je použit bezstavový protokol, typicky HTTP. Díky použití standardních protokolů a rozhraní pro výměnu zdrojů jsou aplikace založené na REST jednoduché, od- lehčené a nabízejí vysokou výkonnost. RESTful webové služby jsou založeny na REST architektuře, tj. zdroje jsou vystaveny klientům prostřednictvím URI a pro manipulaci s nimi jsou použity čtyři základní HTTP metody: • GET – slouží pro získání zdroje, a to jak jednoho konkrétního, tak celé množiny zdrojů, • PUT – metoda umožňující editaci zdroje s daným identifikátorem, v těle požadavku je nový obsah zdroje, • POST – vytváří zdroj s obsahem, který je zaslán v těle požadavku, 40 • DELETE – smazání zdroje se zadaným identifikátorem. Každá URI zdroje může mít až čtyři různé typy částí: • neměnná část – část URI která zůstává stejná, např. /books specifikuje seznam všech knih v databázi, • proměnné URI – liší se podle toho, k jakému konkrétnímu zdroji přistupujeme, např. /books/hamlet a /books/othello, • query parametry – umisťují se na konec URI oddělené otazníkem, specifikují detaily vybraných záznamů, např. /books?year=2010 pro všechny knihy vydané v roce 2010, • matrix parametry – se oddělují středníkem, mají podobný význam jako query para- metry, ale vztahují se k aktuální úrovni, na které jsou uvedeny, např. pro vybrání všech knih autorů, jejichž křestní jméno je Jack, můžeme použít /authors;name=jack/books. S RESTful webovými službami se typicky jako formát pro výměnu dat pojí JSON. Jeho výhodou oproti XML je především jeho stručnost, díky čemuž se minimalizuje velikost přenášených dat. I přes výhody formátu JSON je však třeba myslet na to, že preferovaným formátem pro komunikaci v rámci Sonic ESB je značkovací jazyk XML, jak bylo zmíněno v části 5.1.1, a proto bude XML primární formát pro komunikaci s navrhovaným systémem pro externí přístup. Jako výhody XML můžeme zmínit například jeho lepší vyjadřovací schopnosti, kon- krétně možnost vytváření atributů pro jednotlivé elementy dokumentu nebo definování jmenných prostorů. Podrobnosti ohledně jazyka XML je možné nalézt v jeho specifikaci [13]. 7.2.2 Definice rozhraní V sekci 7.1 jsme definovali, jaké operace bude klientům umožněno vykonávat prostřednic- tvím aplikačního rozhraní. V této části se budeme zabývat konkrétní podobou jednotlivých URI, které tyto operace zpřístupňují, HTTP stavovými kódy vracenými jako součást odpo- vědí na klientské požadavky a nastíníme podobu dat, která se budou přes API posílat. V navrhovaném REST API budeme mít celkem tři různé URI, kterými budeme imple- mentovat vybrané operace nad vychystávacími návrhy: • /staging/suggestions – umožňuje pracovat nad množinou vychystávacích návrhů, případně vytvořit nový návrh, • /staging/suggestions/{sid} – zprostředkovává přístup k jednomu vychystávacímu návrhu identifikovanému hodnotou proměnného pole sid, • /staging/suggestions/{sid}/lines/{lid} – dále specifikuje jeden konkrétní řádek daného vychystávacího návrhu prostřednictvím proměnné části lid, Nad jednotlivými URI aplikačního rozhraní jsou definovány různé HTTP metody. Tyto metody a operace, které jsou za nimi skryty, jsou shrnuty v tabulce 7.1. Stavové kódy vracené jako součást odpovědí na požadavky klientů a případy, kdy jsou vráceny, jsou pak uvedeny v tabulce 7.2. Vychystávací návrhy budou vraceny vždy i se všemi svými položkami. Jelikož jsou po- ložky v systému proALPHA vždy chápány jako neodmyslitelná část vychystávacího návrhu, nemá smysl implementovat metodu GET pro získání jediné položky některého z návrhů. 41 URI Metoda Význam /suggestions GET Vrátí seznam všech vychystávacích návrhů v systému proALPHA. POST Vytvoří nový vychystávací návrh na základě zakázky v systému. Identifi- kátor zakázky je zaslán v těle poža- davku. Při úspěšném provedení ope- race bude nově vzniklý návrh vrácen v těle odpovědi. /suggestions/{sid} GET Získá jeden konkrétní vychystávací návrh identifikovaný proměnnou sid včetně všech jeho položk. PUT Upraví vybraný vychystávací návrh. Jeho nová podoba bude součástí těla HTTP požadavku. Při úspěšném pro- vedení operace je aktualizovaný ná- vrh vrácen v těle odpovědi. DELETE Smaže vybraný vychystávací návrh. /suggestions/{sid}/lines/{lid} PUT Upraví vybraný řádek vychystávacího návrhu daný proměnnou lid. Ovliv- něný návrh bude vrácen v těle odpo- vědi. DELETE Smaže vybraný řádek vychystávacího návrhu. Při úspěšném provedení ope- race bude celý ovlivněný návrh vrá- cen v těle odpovědi. Tabulka 7.1: Přehled HTTP metod, které je možné volat nad URI aplikačního rozhraní a jejich význam. URI jsou uvedeny bez společné neměnné části /staging. Stavový kód Navrácen 200 OK • Požadavek GET proběhl v pořádku. • Požadavek PUT proběhl v pořádku. • Řádek vychystávacího návrhu byl úspěšně smazán. 201 Created • Vychystávací návrh byl úspěšně vytvořen. 204 No Content • Vychystávací návrh byl úspěšně smazán. 400 Bad Request • Neznámá HTTP metoda. • Požadavek způsobil chybu v adaptéru. 405 Method Not Allowed • Požadovanou metodu nelze aplikovat na danou URI. 501 Not Implemented • Pokus o provedení neexistující operace. Tabulka 7.2: Přehled HTTP stavových kódů vracených aplikačním rozhraním a situace, ve kterých budou vráceny. 42 V případě, že dotaz na systém pro externí přístup způsobí chybu na straně adaptéru, bude v těle odpovědi vrácen seznam chyb, které byly při zpracování zachyceny. Tato situace obvykle nastává například jako důsledek zadání nepovolené hodnoty do některého z edito- vatelných polí návrhu, pokus o přístup k neexistujícímu návrhu apod. Příslušné odpovědi mají typicky stavový kód 400 Bad Request, případně 501 Not Implemented. Řešení závislostí mezi editovatelnými poli V závěru této části práce ještě zmiňme, že navrhované REST API na rozdíl od systému proALPHA nepodporuje možnost současné editace několika datových polí položek vychys- távacího návrhu. Vzhledem ke vzájemným závislostem jednotlivých polí, které byly na- stíněny v části 7.1, může tento přístup způsobovat komplikace při editaci jako například uvedení systému do nekonzistentního stavu. Z výše uvedeného důvodu je třeba umožnit při editaci položky vychystávacího návrhu přes API změnu pouze jedné hodnoty v daném okamžiku. Tyto změny se ihned uloží do databáze včetně automatických změn ostatních polí, které tato akce může vyvolat. Proto není v tomto případě možné implementovat editace obvyklým přístupem orientovaným na zdroje, při kterém metoda PUT předá serveru novou podobu daného zdroje, nýbrž je nutné ji chápat spíše jako funkci, které vždy předáme pole, jež chceme měnit, a jeho novou hodnotu. Tento problém není nutné řešit u editace dat samotného vychystávacího návrhu, jelikož jeho datová pole nejsou vzájemně závislá. Podobným způsobem je nutné přistupovat i k metodě POST vytvářející nový vychys- távací návrh. Jelikož vychystávací návrhy nejsou generovány uživateli, ale vytvářeny sys- témem na základě existujících dokumentů, je třeba i v tomto případě specifikovat metodě parametry pro vykonání operace místo konkrétního těla zdroje, který se má vytvořit. Předá- vané parametry specifikují operaci, která vychystávací návrh vytváří a data nutné k jejímu správnému provedení. Jelikož v rámci této práce umožňujeme pouze generování návrhu na základě existující objednávky, bude tato operace vždy představovat vychystání objednávky s daným identifikátorem. 7.3 Adaptér a jeho funkce V předchozí sekci jsme definovali podobu REST API, přes které bude klientům umožněna interakce se systémem proALPHA. Nyní se budeme zbývat tím, jak vhodně vytvořit část označenou na schématu 7.1 jako Adaptér, která bude přímo manipulovat s vychystávacími návrhy systému a na jejíž funkce a procedury budeme mapovat jednotlivé zdroje navrženého API. Funkcionalita adaptéru rovněž zahrnuje podání vhodné zprávy o výsledku operace. Adaptér, který představuje stěžejní část celého systému pro externí přístup, bude rea- lizován jako externí procedura jazyka ABL, požadované operace budou v rámci adaptéru implementovány jako jeho interní procedury. Adaptér bude dále nabízet i některé podpůrné procedury a funkce pro usnadnění práce s ním. Po skončení činnosti adaptéru bude možné získat informace o tom, jestli při běhu vola- ných procedur došlo k chybě nebo ne. Jelikož těchto chyb mohlo při zpracování vzniknout více, jsou chyby postupně zaznamenávány do XML zprávy, která pak může být předána zpět klientovi a zobrazena uživateli. Aplikace využívající adaptér by tedy měla vždy po vykonání požadavků od klienta zkon- trolovat zda nedošlo k chybě prostřednictvím funkce lGetAnyError, která vrací hodnotu 43 True v případě alespoň jedné chyby nebo False, pokud vše proběhlo v pořádku.1 Pro získání XML s hlášením o chybách bude v adaptéru k dispozici funkce clGetErrorList. V následujících částech této sekce si postupně rozebereme jednotlivé procedury nabí- zené adaptérem pro implementaci obsluhy požadavků na API, jejich vstupní a výstupní parametry a situace, kdy v nich může vzniknout chyba. Přehled těchto funkcí je uveden v tabulce 7.3. Procedura/funkce Význam getSuggestions Získá všechny dostupné vychystávací návrhy. stageOrder Vychystá zadanou zakázku. getSuggestionById Získá jeden vychystávací návrh. updateSuggestionById Upraví hodnoty zadaného vychystávacího návrhu. deleteSuggestionById Smaže zadaný vychystávací návrh. updateLineAdpotionCode Upraví hodnotu odpovídajícího pole řádku návrhu. updateLinePickStatus updateLinePickedQty updateLinePickingLocation updateLinePickingStorage deleteLine Smaže zadaný řádek vychystávacího návrhu. lGetAnyError Informuje o vzniku chyby při zpracování. clGetErrorList Vrátí seznam chyb. Tabulka 7.3: Přehled procedur a funkcí adaptéru, zajišťujících implementaci vybraných operací nad vychystávacími návrhy a obsluhu možných chyb. 7.3.1 Získání vychystávacích návrhů Abychom mohli pracovat s vychystávacími návrhy přes navržené REST API, je v prvé řadě nutné dát klientovi možnost návrhy získat z databáze. Jak již bylo zmíněno dříve, získání návrhů bude probíhat prostřednictvím metody GET nad příslušnou URI, přičemž mohou nastat dvě situace: • získání všech vychystávacích návrhů, • získání jednoho konkrétního vychystávacího návrhu. Pro získání množiny všech otevřených vychystávacích návrhů, tj. těch, které dosud ne- byly archivovány nebo jinak vyřízeny, bude adaptér poskytovat