TECHNICK ´ A UNIVERZITA V LIBERCI Fakulta mechatroniky, informatiky a mezioborov´ ych studi´ı
DIPLOMOV ´ A PR ´ ACE
kvˇeten 2013 Bc. Jiˇr´ı Sojka
TECHNICK ´ A UNIVERZITA V LIBERCI
Fakulta mechatroniky, informatiky a mezioborov´ ych studi´ı
Studijn´ı program: N2612 Elektrotechnika a informatika Studijn´ı obor: 1802T007 Informaˇcn´ı technologie
Klient server aplikace pro Activiti workflow Client server application for Activiti worflow
Bc. Jiˇr´ı Sojka
Vedouc´ı pr´ace: Mgr. Jiˇr´ı Vran´y, Ph.D.
Pracoviˇstˇe: Ustav nov´´ ych technolog´ı´ı a aplikovan´e informatiky
Zad´an´ı oboustran´e, proto prohl´aˇsen´ı ˇc´ıslo str´anky 5.
Cestn´ ˇ e prohl´ aˇ sen´ı
Byl jsem sezn´amen s t´ım, ˇze na mou diplomovou pr´aci se plnˇe vztahuje z´akon ˇ
c. 121/2000 Sb., o pr´avu autorsk´em, zejm´ena § 60 – ˇskoln´ı d´ılo.
Beru na vˇedom´ı, ˇze Technick´a univerzita v Liberci (TUL) nezasahuje do m´ych autorsk´ych pr´av uˇzit´ım m´e diplomov´e pr´ace pro vnitˇrn´ı potˇrebu TUL.
Uˇziji-li diplomovou pr´aci nebo poskytnu-li licenci k jej´ımu vyuˇzit´ı, jsem si vˇedom povinnosti informovat o t´eto skuteˇcnosti TUL; v tomto pˇr´ıpadˇe m´a TUL pr´avo ode mne poˇzadovat ´uhradu n´aklad˚u, kter´e vynaloˇzila na vytvoˇren´ı d´ıla, aˇz do jejich skuteˇcn´e v´yˇse.
Diplomovou pr´aci jsem vypracoval samostatnˇe s pouˇzit´ım uveden´e literatury a na z´akladˇe konzultac´ı s vedouc´ım diplomov´e pr´ace a konzultantem.
Datum: 16. kvˇetna 2013
. . . . podpis
Podˇ ekov´ an´ı
Na tomto m´ıstˇe bych chtˇel podˇekovat pˇredevˇs´ım sv´e rodinˇe a nejbliˇzˇs´ım pˇr´atel˚um, bez jejichˇz trpˇelivosti a podpory bych se k t´eto pr´aci zˇrejmˇe nedopracoval.
D´ale bych zde chtˇel podˇekovat sv´emu vedouc´ımu Mgr. Jiˇr´ımu Vran´emu, Ph.D.
za ochotu, trpˇelivost a pˇr´ıstup k veden´ı m´e diplomov´e pr´ace. Podˇekovan´ı tak´e patˇr´ı m´emu konzultantovi panu Ing. Martinu Pˇr´adn´emu, technick´emu ˇrediteli spoleˇcnosti Actis s.r.o.
Pouˇzit´y software
Tato pr´ace byla vys´azena programem LATEX pod operaˇcn´ım syst´emem Windows 7 64-bit. N´astroj pro tvorbu zdrojov´ych k´od˚u byl pouˇzit Eclipse Juno ve verzi 4.2.1 s extern´ımi pluginy pro komunikaci s Git reposit´aˇrem, vytvoˇren´ı UML diagram˚u a vy- generov´an´ı dokumentace ke zdrojov´ym k´od˚um. Pro uloˇzen´ı dat byly pouˇzity MySQL a SQLite datab´azov´e servery. Testov´an´ı probˇehlo na aplikaˇcn´ım serveru GlassFish 3.1.2, virtu´aln´ım serveru Microsoft Windows Server 2003 a mobiln´ım zaˇr´ızen´ım Sam- sung Nexus S s Android 4.1.2.
Kontakt
E-mail: jiri.sojka@tul.cz
Anotace
Tato diplomov´a pr´ace se zab´yv´a problematikou spr´avy vybran´ych poˇzadavk˚u z Activiti workflow. Activiti framework je n´astroj pro v´yvoj business aplikac´ı za pomoci proces˚u modelovan´ych podle pravidel BMPN 2.0. C´ılem pr´ace je navrhnout a imple- mentovat klient server aplikaci pro spr´avu ´ukol˚u a proces˚u.
Pr´ace popisuje n´avrh a implementaci serveru a d´ale dvou klientsk´ych aplikac´ı.
Jedna jako desktopov´a aplikace v jazyce Java, druh´a prim´arnˇe pro mobiln´ı platformu Android. Komunikace se serverem je realizov´ana vyuˇzit´ım REST rozhran´ı a datov´eho form´atu JSON. Data jednotliv´ych klientsk´ych aplikac´ı jsou centr´alnˇe synchronizov´ana na serveru poskytuj´ıc´ım webovou sluˇzbu a komunikuj´ıc´ım s Activiti workflow.
Kl´ıˇcov´a slova: Activiti workflow, REST, JSON, webov´a sluˇzba, klient, server, ´ukol, proces
Abstract
This diploma thesis deals with the issue of administration of selected requirements of Activiti workflow. Activiti Framework is a tool used for development of business applications supported by processes which are modelled according to BMPN 2.0 The main aim of this thesis is to design and implement a client server application for administration of tasks and processes.
This thesis describes a design and implementation of a server and two client ap- plications. One of them is Java (programming) language desktop application and the other one is primarily intended for Android mobile platform. Communication with server is realised by using REST interface and JSON data format. Data of individual client applications are centrally synchronised at the server which provides the web service and communication with Activiti workflow.
Keywords: Activiti workflow , REST, JSON, web service, client, server, task, process
Obsah
1 Uvod´ 13
1.1 Jazykov´e konvence . . . 14
2 Activiti framework 15 2.1 Souˇc´asti frameworku . . . 15
2.1.1 BPMN 2.0 . . . 15
2.1.2 J´adro frameworku . . . 16
2.2 Activiti engine API . . . 17
2.3 Activiti REST API . . . 18
2.4 Z´akladn´ı pouˇzit´ı frameworku . . . 19
2.5 Spr´ava task z pohledu uˇzivatele . . . 21
2.6 Webov´a sluˇzba . . . 21
2.6.1 SOAP . . . 21
2.6.2 REST . . . 22
2.6.3 CRUD . . . 22
2.7 Zhodnocen´ı aktu´aln´ıho stavu . . . 22
3 N´avrh aplikace 24 3.1 N´avrh komunikace . . . 25
3.2 N´avrh datab´aze . . . 25
3.2.1 Server datab´aze . . . 26
3.2.2 Klientsk´a datab´aze . . . 26
3.3 Synchronizace dat . . . 27
3.3.1 Prvotn´ı n´avrh synchronizace . . . 28
3.3.2 Koneˇcn´y n´avrh synchronizace . . . 30
3.4 Vyuˇzit´ı modern´ıch programovac´ıch prostˇredk˚u . . . 31
4 Implementace 32 4.1 Server . . . 32
4.1.1 Komunikace . . . 33
4.1.2 Komunikaˇcn´ı model . . . 33
4.1.3 Autentizace klient˚u . . . 35
4.1.4 Synchronizace dat . . . 35
4.2 Klient . . . 39
4.2.1 Bezpeˇcnost intern´ıch dat . . . 39
4.2.2 Komunikace . . . 40
4.2.3 Generovan´ı formul´aˇr˚u . . . 41
4.2.4 Synchronizace klientsk´e ˇc´asti . . . 43
4.2.5 Implementaˇcn´ı rozd´ıly klientsk´ych ˇc´ast´ı . . . 44
4.2.6 Vyuˇzit´ı n´avrhov´eho vzoru Command u desktopov´e aplikace . . . 45
4.2.7 Vyuˇzit´ı n´avrhov´eho vzoru State u mobiln´ı aplikace . . . 46
4.2.8 Mobiln´ı aplikace – back stack . . . 46
4.2.9 Moˇznosti desktopov´e aplikace . . . 48
4.2.10 Moˇznosti mobiln´ı aplikace . . . 49
5 Testov´an´ı aplikace 53
6 Moˇznosti rozˇs´ıˇren´ı 54
7 Z´avˇer 55
Reference 58
Pˇr´ıloha A - Uˇzivatelsk´y manu´al - Activiti mobile v1.0 59 Pˇr´ıloha B - uk´azka synchronizaˇcn´ıho poˇzadavku 62
Pˇr´ıloha C - pˇriloˇzen´e CD 63
Seznam obr´ azk˚ u
1 BPMN proces . . . 16
2 Sch´ema Activiti frameworku . . . 17
3 Z´akladn´ı architektura Process Enginu . . . 18
4 Generov´an´ı formul´aˇre . . . 20
5 N´avrh implementace . . . 24
6 ERD model server datab´aze . . . 26
7 ERD model klientsk´e datab´aze . . . 27
8 Zn´azornˇen´ı mnoˇzin . . . 29
9 Sch´ema koneˇcn´eho n´avrhu synchronizace . . . 30
10 Z´akladn´ı sch´ema server ˇc´asti . . . 32
11 Modelov´a situace probl´emu synchronizace . . . 36
12 UML sch´ema tˇr´ıd pro zpracov´an´ı synchronizaˇcn´ıho poˇzadavku . . . 38
13 Sch´ema vytvoˇren´ı synchronizaˇcn´ıho poˇzadavku . . . 41
14 Diagram vytvoˇren´ı formul´aˇrov´eho pole . . . 42
15 Kroky synchronizace . . . 43
16 UML sch´ema tˇr´ıd pro odesl´an´ı autentizaˇcn´ıho poˇzadavku . . . 44
17 UML vyuˇzit´ı n´avrhov´eho vzoru Command . . . 45
18 UML vyuˇzit´ı n´avrhov´eho vzoru State . . . 46
19 Sch´ema pr´ace s aktivity z´asobn´ıkem [7] . . . 47
20 Pˇrihl´aˇsen´ı uˇzivatele a konfigurace pˇripojen´ı . . . 48
21 Dynamicky vygenerovan´y formul´aˇr . . . 48
22 Hlavn´ı okno pro pr´aci s daty . . . 49
23 Pˇrihl´aˇsen´ı uˇzivatele a konfigurace pˇripojen´ı . . . 51
24 Seznam proces˚u a zobrazen´ı formul´aˇre . . . 51
Seznam zkratek
AES Advanced Encryption Standard API Application Programming Interface BPM Business Process Model
BPMN Business Process and Notation EAS Advanced Encryption Standard EER Extended Relationship Diagram ERD Entity Relationship Diagram ID Identifier
JSON JavaScript Object Notation REST Representational State Transfer SD Secure Digital
SOAP Simple Object Access Protocol SSL Secure Sockets Layer
UML Unified Modeling Language URL Uniform Resource Locator URI Uniform Resource Identifier VPN Virtual Private Network XML Extensible Markup Language
1 Uvod ´
Vyuˇz´ıv´an´ı nov´ych a dostupn´ych technologi´ı je v dneˇsn´ı dobˇe t´emˇeˇr nepostrada- teln´ym aspektem ´uspˇeˇsn´e firmy zab´yvaj´ıc´ı se oblast´ı v´yvoje softwaru. Aktu´alnˇe maj´ı v´yvoj´aˇri moˇznost vyv´ıjet aplikace komunikuj´ıc´ı modern´ım zp˚usobem pomoc´ı webov´e sluˇzby, d´ale mohou vyuˇz´ıvat moˇznost´ı mnoha volnˇe dostupn´ych framework˚u, kter´e v´yrazn´ym zp˚usobem ulehˇcuj´ı a zrychluj´ı tvorbu aplikac´ı komunikuj´ıc´ıch po s´ıti.
C´ılem t´eto pr´ace je ´uspˇeˇsnou implementac´ı n´avrhu aplikace demonstrovat moˇznost pouˇzit´ı d´ale popsan´ych technologi´ı v souvislosti s Activiti frameworkem. Ten je v dneˇsn´ı dobˇe spoleˇcnost´ı Actis s.r.o. vyuˇz´ıv´an v mnoha aplikac´ıch.
Aktu´aln´ı vyuˇzit´ı Activiti frameworku je v´az´ano na extern´ı aplikaci Lotus Notes [12], kde jsou data ukl´ad´ana na tzv. dokumenty. Ovˇsem v pˇr´ıpadˇe p´adu Activiti fra- meworku, kdy je proveden intern´ımi mechanismy pˇresun workflow zpˇet do posledn´ıho konzistetn´ıho stavu, jiˇz zmˇeny dat uloˇzen´ych na dokumentech vr´aceny nejsou. T´ım je poruˇsena datov´a konzistence, jeˇz se mus´ı n´aslednˇe manu´alnˇe a komplikovanˇe z´ısk´avat zpˇet.
Motivac´ı t´eto pr´ace bylo pˇredevˇs´ım vyuˇz´ıt Activiti framework jak pro zpracov´an´ı pr˚ubˇehu vykon´av´an´ı proces˚u, tak i pro uloˇzen´ı vˇsech potˇrebn´ych dat aplikace. T´ım, ˇze jsou vˇsechna data pˇr´ımo v Activiti datab´azi, je zaruˇcena poˇzadovan´a konzistence dat.
Z´akladn´ım c´ılem je moˇznost spravovat poˇzadavky z Activiti workflow pomoc´ı mo- biln´ıho zaˇr´ızen´ı se syst´emem Android. Poˇzadavkem se rozum´ı spr´ava ´ukol˚u a start dostupn´ych proces˚u, kter´e jsou uloˇzeny ve formˇe procesn´ı definice v Activiti datab´azi.
Koneˇcn´ym c´ılem pr´ace je vytvoˇren´ı dvou klientsk´ych aplikac´ı s moˇznost´ı zpra- cov´an´ı dat v off–line reˇzimu. Jedna jako desktopov´a aplikace v jazyce Java a druh´a jako mobiln´ı aplikace pro platformu Android. Komunikace je zprostˇredkov´ana webo- vou sluˇzbou, jeˇz doposud pro komunikaci s Activiti frameworkem vyuˇz´ıv´ana nebyla.
Aktu´aln´ı stav dat mezi Activiti frameworkem a jednotliv´ymi klientsk´ymi datab´azemi je zaruˇcen synchronizaˇcn´ım mechanismem na serveru, kter´y zprostˇredkov´av´a komuni- kaci mezi Activiti frameworkem a jednotliv´ymi klienty.
Aplikace byla navrˇzena pro pˇr´ıpadn´e snadn´e rozˇs´ıˇren´ı o dalˇs´ı datov´e zdroje. D´ale je implementov´ano jednotn´e univerz´aln´ı zobrazen´ı dat a jejich n´asledn´a validace v kli- entsk´e ˇc´asti aplikace. Souˇc´ast´ı klientsk´e aplikace je tak´e kompletn´ı uˇzivatelsk´y manu´al.
Po ´uvodn´ım sezn´amen´ı s Activiti frameworkem a jeho moˇznostmi komunikace s ex- tern´ımi aplikacemi, kter´e jsou pops´any v kapitole 2, je vysvˇetlen postup n´avrhu kom- pletn´ı aplikace, d˚uvody pouˇzit´ı centr´aln´ıho prvku a d´ale postup n´avrhu synchronizace dat, kter´a je nezbytn´a pro udrˇzov´an´ı aktu´aln´ıho stavu dat v klientsk´ych aplikac´ıch (kapitola 3).
Kapitola 4 jiˇz popisuje konkr´etn´ı technologie, postupy a ˇreˇsen´ı probl´em˚u, kter´e se vyskytly pˇri samotn´em v´yvoji v´ysledn´e aplikace.
Souˇc´ast´ı pr´ace je tak´e testov´an´ı a oprava pˇr´ıpadn´ych nedostatk˚u v´ysledn´e aplikace popsan´e v kapitole 5. Aplikaci je moˇzn´e rozˇs´ıˇrit o moˇznosti popsan´e ˇc´ast´ı 6.
V samotn´em z´avˇeru pr´ace (kapitola 7) jsou zhodnoceny vlastnosti n´avrhu a im- plementace aplikace, v´ysledky testov´an´ı a pˇredevˇs´ım pˇr´ınos ´uspˇeˇsn´e implementace pro spoleˇcnost Actis s.r.o., kter´a je zadavatelem pr´ace.
Jedn´a se o diplomovou pr´aci, proto bylo k vytv´aˇren´ı t´eto zpr´avy pˇristupov´ano s pˇredpokladem znalost´ı c´ılov´e problematiky a pr´ace samotn´a jiˇz popisuje ˇreˇsen´ı konkr´etn´ıho n´avrhu aplikace a jej´ı implementace.
1.1 Jazykov´ e konvence
Pr´ace obsahuje pˇreloˇzen´e anglick´e term´ıny, jejichˇz pouh´y pˇreklad do ˇcesk´eho ja- zyka nepostihuje plnohodnotn´y v´yznam slova. Nˇekter´e term´ıny jsou vyuˇz´ıv´any bez pˇrekladu, v ˇcesk´em jazyce pro nˇe zat´ım neexistuje ust´alen´y v´yznam. Proto jsou zde uvedeny jejich konkr´etn´ı v´yznamy:
• workflow – oznaˇcen´ı toku informac´ı v podnikov´em procesu a jejich automa- tizovan´e ˇr´ızen´ı, v t´eto pr´aci je tento v´yznam vˇzdy spojov´an s Activiti work- flow. Vyuˇzit´ı workflow m´a za ´uˇcel v´yrazn´e zjednoduˇsen´ı vz´ajemn´e komuni- kace a transparentnosti mezi klientem, softwarov´ym analytikem a samotn´ym v´yvoj´aˇrem v´ysledn´e aplikace,
• framework – softwarov´a struktura pro podporu v´yvoje aplikac´ı, v pr´aci tento term´ın oznaˇcuje Activiti framework,
• ´ukol (user task) – oznaˇcuje objekt definuj´ıc´ı uˇzivatelsk´y ´ukol z Activiti datab´aze,
• proces (process) – oznaˇcuje objekt procesu urˇcen´y procesn´ı definic´ı v Activiti datab´azi,
• engine – oznaˇcen´ı j´adra vykon´avaj´ıc´ıho z´akladn´ı funkci Activiti frameworku.
Pokud je d´ale v pr´aci nˇekter´y z tˇechto term´ın˚u oznaˇcen kurz´ıvou, nab´yv´a tak v´yˇse uveden´eho v´yznamu.
2 Activiti framework
Hlavn´ım c´ılem t´eto pr´ace je spr´ava ´ukol˚u a proces˚u v Activiti workflow. Tato ka- pitola popisuje z´akladn´ı vlastnosti a funkce Activiti frameworku. Bl´ıˇze jsou pops´any ˇ
c´asti, kter´e nab´ızej´ı pˇr´ıstup pro z´ısk´an´ı ´ukol˚u, proces˚u a moˇznosti jejich zpracov´an´ı.
Activiti framework je oznaˇcen´ı n´astroje nab´ızej´ıc´ıho v´yvoj business aplikac´ı za pomoci vizualizovan´ych proces˚u ve workflow prostˇred´ı.
Projekt Activiti zaloˇzili v roce 2010 v´yvoj´aˇri Tom Baeyens a Joram Barrez. Jejich c´ılem bylo vybudovat robustn´ı open-source BPMN 2.0 process engine. Jiˇz po mˇes´ıci v´yvoje byla k dispozici prvn´ı stabiln´ı verze. Postupem ˇcasu vznikla rozs´ahl´a komunita v´yvoj´aˇr˚u, jej´ıˇz souˇc´ast´ı se staly i spoleˇcnosti jako SpringSource, FuseSource nebo Mu- lesoft, kter´e od t´eto doby vyv´ıjej´ı software na z´akladech Activiti. Nespornou v´yhodou pˇri v´yvoji je moˇznost vyuˇz´ıt flexibiln´ı komunikace se samotn´ymi v´yvoj´aˇri tohoto fra- meworku.
Pˇredevˇs´ım podle poˇzadavk˚u v´yvojaˇr˚u vyuˇz´ıvaj´ıc´ıch tento produkt je Activiti fra- mework st´ale vyv´ıjen a zdokonalov´an. Aktu´aln´ı verze nese oznaˇcen´ı 5.12. Podle zmˇen v samotn´em j´adru frameworku jsou tak´e aktualizov´any funkce a vlastnosti Activiti Modeleru a Activiti Designeru, proto je pro v´yvoj´aˇre vyuˇz´ıvaj´ıc´ı Activiti framework v´yhodou sledovat aktu´aln´ı v´yvoj frameworku a pouˇz´ıvat jeho nejnovˇejˇs´ı nab´ızen´e funkce.
J´adro frameworku je naps´ano v jazyce Java a ˇs´ıˇreno jako open–source pod li- cenc´ı Apache [4]. Activiti je moˇzno vyuˇz´ıvat bud’ jako plnohodnotnou aplikaci, nebo jako souˇc´ast komplexnˇejˇs´ıho projektu jak na serveru, tak napˇr´ıklad na clusteru, nebo v dneˇsn´ı aktu´alnˇe se rozˇsiˇruj´ıc´ı technologii zvan´e cloud.
2.1 Souˇ c´ asti frameworku
Obecn´y pojem workflow obvykle popisuje technologii ˇr´ızen´ı podniku, nebo napˇr´ıklad zpracov´an´ı dokument˚u, a jedn´a se o sch´ema proveden´ı komplexnˇejˇs´ı ˇcinnosti (procesu). Obecnˇe plat´ı, ˇze je workflow tvoˇreno pˇredevˇs´ım pravidly definuj´ıc´ı procesy, metrikami proces˚u a pˇred´avan´ymi daty. Tato data jsou pˇred´av´ana v podobˇe tzv. pro- cesn´ıch promˇenn´ych, kter´e mohou b´yt definov´any jiˇz v samotn´e procesn´ı definici. Pro- cesy jsou navrhov´any a modelov´any podle pravidel BPMN 2.0.
2.1.1 BPMN 2.0
Soubor princip˚u a pravidel BPMN, aktu´alnˇe ve verzi 2.0 [11], slouˇz´ı pro grafick´e zn´azornˇen´ı proces˚u v procesn´ım diagramu. Tento diagram je zaloˇzen na tzv. flowchart technologii a graficky zn´azorˇnuje jednotliv´e kroky algoritmu. Jeho v´ysledn´a prezentace je podobn´a diagramu activit z jazyka UML.
BPMN si klade za c´ıl st´at se jedinou univerz´aln´ı notac´ı pro tvorbu model˚u pˇredevˇs´ım pr´avˇe podnikov´ych proces˚u. Za t´ımto ´uˇcelem je z´akladn´ım stavebn´ım prv- kem jazyk XML. V´ysledkem by mˇel b´yt jednotn´y a konzistentn´ı jazyk.
2.1.2 J´adro frameworku
Obecnou funkcionalitu j´adra frameworku (enginu) je moˇzn´e si pˇredstavit jako syst´em, kter´y zajiˇst’uje zmˇenu stavu v procesu dle jeho definice v Activiti datab´azi.
Definice procesu podle pravidel BPMN 2.0 obsahuje:
• events – ud´alosti, napˇr´ıklad start a ukonˇcen´ı procesu,
• tasks – ´ukoly oznaˇcuj´ıc´ı konkr´etn´ı stavy procesu,
• gateways – br´any, kter´e spojuj´ı jednotliv´e toky,
• sequence flow – toky popisuj´ıc´ı pˇrechody mezi jednotliv´ymi stavy procesu.
N´asleduj´ıc´ı sch´ema zobrazuje uk´azku procesu a jeho ˇc´asteˇcnou definici v jazyce XML.
Obr´azek 1: BPMN proces
Pˇr´ıklad ˇc´asti procesu v jazyce XML:
<process id="create_new_account" name="Create new account">
<startEvent id="start_process" name="Start"></startEvent>
<userTask id="create_account" name="Create account">
<extensionElements>
<taskListener event="create" class="NewAccount"></taskListener>
</extensionElements>
</userTask>
Cel´y framework obsahuje sadu komponent, jej´ıˇz hlavn´ı souˇc´ast´ı je process engine.
Toto j´adro frameworku poskytuje z´akladn´ı funkce pro start procesu, pˇrechod mezi de- finovan´ymi stavy ˇci jeho ukonˇcen´ı. D´ale obstar´av´a deploy (nahr´an´ı) nov´ych procesn´ıch definic a start procesn´ıch instanc´ı.
Activiti komponenty:
• Engine – z´akladn´ı komponenta frameworku, zajˇst’uje spuˇstˇen´ı a pr˚ubˇeh BPMN procesu,
• Modeler – webov´e modelovac´ı prostˇred´ı pro tvorbu BPMN 2.0 proces˚u,
• Designer – plugin pro v´yvojov´e prostˇred´ı Eclipse, kter´y slouˇz´ı k modelov´an´ı a definov´an´ı proces˚u,
• Explorer – webov´a aplikace pro spr´avu Activiti workflow. Umoˇzˇnuje startovat nov´e procesy, spravovat uˇzivatele, vizualizovat samotnou Activiti datab´azi,
• REST – webov´a sluˇzba poskytuj´ıc´ı REST API pro komunikaci s enginem z ex- tern´ıch aplikac´ı.
Obr´azek 2: Sch´ema Activiti frameworku Activiti framework nab´ız´ı dvˇe moˇznosti aplikaˇcn´ıho pouˇzit´ı:
• embedded – aplikace pˇr´ımo obsahuje Activiti JAR a vyuˇz´ıv´a Java API pro pˇr´ıstup k Activiti enginu. Je nutn´e engine inicializovat pˇri kaˇzd´em spuˇstˇen´ı aplikace pomoc´ı konfiguraˇcn´ıho XML souboru,
• standalone – Activiti engine je instanciov´an pouze v aplikaci na serveru. Ostatn´ı aplikace maj´ı moˇznost pˇr´ıstupu k enginu pˇres tzv. REST rozhran´ı.
2.2 Activiti engine API
Activiti API [20] pro ovl´ad´an´ı enginu je rozdˇeleno do sedmi z´akladn´ıch ˇc´ast´ı. Pro v´yvoj´aˇre je v´yhodn´e sezn´amit se nejprve s architekturou Java API. Pot´e je mnohem snaˇzˇs´ı pochopit pˇr´ıpadn´e ovl´ad´an´ı enginu pˇres REST API.
Pˇr´ıstup k jednotliv´ym ˇc´astem enginu je zˇrejm´y z n´asleduj´ıc´ıho diagramu.
Obr´azek 3: Z´akladn´ı architektura Process Enginu
Centr´aln´ı ˇc´ast´ı je tˇr´ıda ProcessEngine. Z t´eto instance lze z´ıskat vˇsech 7 z´akladn´ıch instanc´ı pro kompletn´ı ovl´ad´an´ı Activiti enginu. Z´ısk´an´ı z´akladn´ı instance process en- ginu je implementov´ano:
ProcessEngine engine = ProcessEngines.getDefaultProcessEngine();
Po z´ısk´an´ı t´eto instance m´a v´yvoj´aˇr snadn´y pˇr´ıstup ke vˇsem potˇrebn´ym ˇc´astem enginu:
TaskService taskService = processEngine.getTaskService();
2.3 Activiti REST API
Activiti nab´ız´ı komunikaci s Activiti enginem distribuovan´ym zp˚usobem pˇres REST rozhran´ı. D´ıky podpoˇre technologie REST, ve vˇsech aktu´alnˇe nejpouˇz´ıvanˇejˇs´ıch programovac´ıch jazyc´ıch, je volba implementace vz´ajemn´e komunikace mezi aplikac´ı a Activiti pouze na samotn´em v´yvoj´aˇri.
Pˇri komunikaci s REST rozhran´ım je kv˚uli bezzstavovosti protokolu HTTP potˇreba autentizovat uˇzivatele. Ovˇeˇren´ı je realizov´ano pomoc´ı HTTP hlaviˇcky, ve kter´e je pˇren´aˇseno uˇzivatelsk´e jm´eno a heslo. REST rozhran´ı pˇri kaˇzd´em poˇzadavku ovˇeˇruje uˇzivatele a heslo ve sv´e vlastn´ı datab´azi. Po ´uspˇeˇsn´em ovˇeˇren´ı je odesl´ana odpovˇed’
s poˇzadovan´ymi daty, pˇr´ıpadnˇe chybov´e ohl´aˇsen´ı o ne´uspˇeˇsn´e autentizaci.
URI REST sluˇzby je rozdˇeleno v z´avislosti dle ekvivalent´ıho pouˇzit´ı klasick´eho Java API. Podle defaultn´ıho nastaven´ı REST sluˇzby je z´akladn´ı ˇc´ast URI pro komunikaci s enginem:
http://IP adresa:port/activiti-rest/service/
Za toto URI jsou intuitivnˇe pˇrid´av´any ˇc´asti URI pro z´ısk´an´ı poˇzadovan´ych dat.
Pro z´ısk´an´ı kompletn´ıho seznamu proces˚u z Activiti datab´aze, je vytvoˇren HTTP GET poˇzadavek s autentizaˇcn´ı hlaviˇckou pro:
http://IP adresa:port/activiti-rest/service/process-definitions
Odpovˇed’ na tento poˇzadavek je seznam proces˚u uloˇzen´ych v Activiti datab´azi.
Odpovˇed’ je ve form´atu JSON:
{
"data": [ {
"id": "create_new_account:1",
"key": "new_account",
"version": 1 }
],
"total": 1,
"start": 0,
"sort": "id",
"order": "asc",
"size": 1 }
Pˇrid´an´ım ?size=2&order=desc k p˚uvodn´ı ˇc´asti URI je moˇzno z´ıskat setˇr´ıdˇenou ˇ
c´ast poˇzadovan´ych dat.
Ekvivaletn´ı z´ısk´an´ı dat z enginu za pomoci Java API je n´asleduj´ıc´ı:
repositoryService.createProcessDefinitionQuery().desc().listPage();
2.4 Z´ akladn´ı pouˇ zit´ı frameworku
Samotn´e pouˇzit´ı Activiti frameworku je rozdˇeleno na nˇekolik ˇc´ast´ı. Prvn´ı z nich je n´avrh a vytvoˇren´ı procesu napˇr´ıklad v Actviti Designeru podle pravidel BPMN 2.0.
Hotov´y pˇredpis procesu (procesn´ı definice) je pot´e potˇreba nahr´at do Activiti datab´aze - prov´est tzv. deploy procesn´ı definice bud’ vyuˇzit´ım Java API, nebo pomoc´ı webov´e aplikace pro spr´avu frameworku - Activiti Explorer.
Informace o procesu jsou uloˇzeny v tabulce v Activiti datab´azi pod jedineˇcn´ym identifik´atorem. Ten obsahuje tak´e ˇc´ıslo posledn´ı verze procesu. Z t´eto tabulky je tedy moˇzn´y v´ybˇer procesn´ı definice pro start vykon´av´an´ı procesu tzv. execution. Po startu execution je proces spuˇstˇen a vytvoˇren prvn´ı ´ukol dle konkr´etn´ı definice (tak´e je moˇznost startu v´ıce ´ukol˚u nebo v extr´emn´ım pˇr´ıpadˇe ˇz´adn´eho).
Execution jsou uloˇzena ve vlastn´ı tabulce, kde jsou uchov´ana potˇrebn´a data pro vykon´av´an´ı procesu. T´ım se rozum´ı pˇredevˇs´ım ID procesn´ı definice, podle kter´e je proces vykon´av´an, d´ale aktu´aln´ı ID stavu, ve kter´em se proces nach´az´ı a nˇekolik dalˇs´ıch vlastnost´ı definuj´ıc´ı stav vykon´av´an´ı, jako napˇr´ıklad zda je execution v aktivn´ım stavu.
Pr˚ubˇeh procesu je realizov´an pˇrechodem mezi definovan´ymi stavy (´ukoly). V Acti- viti Designeru je moˇzno definovat ud´alosti pr´avˇe napˇr´ıklad na start nov´eho ´ukolu nebo
na jeho ukonˇcen´ı. Kaˇzd´y objekt ´ukolu m´a v tabulce sv´e jedineˇcn´e ID, ID procesu, execution ID pod kterou je ´ukol vykon´av´an, a d´ale informace o pr´avech (vlastn´ık nebo uˇzivatel, kter´y m´a pr´avo na ukonˇcen´ı konkr´etn´ıho ´ukolu).
Pr˚ubˇeh pˇrechod˚u v procesu mezi stavy je realizov´an na z´akladnˇe hodnot procesn´ıch promˇenn´ych. Workflow podle hodnoty procesn´ıch promˇenn´ych rozhodne, kterou ces- tou bude vykon´av´an´ı procesu d´ale pokraˇcovat (napˇr´ıklad rozhodnut´ı na gateway). API poskytuje nˇekolik operac´ı s ´ukoly, jedn´a se pˇredevˇs´ım o n´asleduj´ıc´ı:
• claim – pˇrevzet´ı ˇreˇsen´ı ´ukolu,
• unclaim – odhl´aˇsen´ı se od ˇreˇsen´ı ´ukolu,
• complete – dokonˇcen´ı ´ukolu.
Pˇri procesu dokonˇcen´ı ´ukolu je moˇzn´e (podle procesn´ı definice pˇr´ıpadnˇe vyˇzadov´ano) pˇredat konkr´etn´ı hodnoty procesn´ıch promˇenn´ych, podle kter´ych se work- flow ˇr´ıd´ı.
Pro komunikaci s uˇzivatelem vyuˇz´ıv´a Activiti tzv. formul´aˇre (forms) a jejich vlast- nosti (properties). Vlastnosti formul´aˇre jsou generov´any podle procesn´ıch promˇenn´ych z definice konkr´etn´ıho ´ukolu a jejich z´ısk´an´ı je moˇzn´e pouˇzit´ım standartn´ıho API.
V´yhody pouˇzit´ı formul´aˇr˚u jsou pˇredevˇs´ım jednotn´a komunikace s uˇzivatelem ˇci moˇznost kontroly form´atu a typu vstupn´ıch dat.
Obr´azek 4: Generov´an´ı formul´aˇre
Mezi vlastnostmi formul´aˇr˚u jsou kromˇe ID a n´azvu tak´e poˇzadovan´y datov´y typ a pˇr´ıznak, zda je vyplnˇen´ı formul´aˇrov´eho pole pro uˇzivatele povinn´e, ˇci ne.
Vykon´av´an´ı procesu je tedy vˇzdy start ´ukolu a pˇriˇrazen´ıˇreˇsitel˚u. Uˇzivatel, kter´y m´a pr´ava na dokonˇcen´ı ´ukolu, ho ukonˇc´ı s pˇr´ıpadn´ymi poˇzadovan´ymi parametry a workflow rozhodne, kter´y ´ukol bude nastartov´an jako n´asleduj´ıc´ı.
Takto prob´ıh´a proces od tzv. startovn´ı ud´alosti (start event ) aˇz po ud´alost koneˇcnou (end event ).
2.5 Spr´ ava task z pohledu uˇ zivatele
Activiti REST rozhran´ı nab´ız´ı pro spr´avu ´ukol˚u z´akladn´ı moˇznosti: complete, claim a unclaim. Kaˇzd´y ´ukol m˚uˇze m´ıt definov´ana pr´ava pro pˇr´ıpadn´e zpracov´an´ı uˇzivatelem.
Uˇzivatel m´a moˇznost ´ukol zpracovat, pokud je jeho uˇzivatelsk´y identifik´ator v:
• assignee – pole oznaˇcuj´ıc´ı uˇzivatele, kter´emu je ´ukol pˇridˇelen,
• candidate – pole oznaˇcuj´ıc´ı pˇr´ıpadn´e kandid´aty na zpracov´an´ı,
• candidate–group – pole urˇcuj´ıc´ı skupiny uˇzivatel˚u, kteˇr´ı maj´ı pr´avo na zpra- cov´an´ı.
2.6 Webov´ a sluˇ zba
Jedna z moˇznost´ı komunikace s Activiti je realizov´ana pomoc´ı webov´e sluˇzby.
Webov´a sluˇzba oznaˇcuje syst´em pro souˇcinnou spolupr´aci stroj˚u na s´ıti. Sluˇzba sa- motn´a je prezentov´ana softwarov´ym nebo hardwarov´ym agentem. Sch´ema komunikace je vˇzdy stejn´e, jeden agent o sluˇzbu ˇz´ad´a a druh´y ji poskytuje. Standardy pouˇz´ıvan´e webov´ymi sluˇzbami zajiˇst’uj´ı totoˇznou s´emantiku obou agent˚u.
Pˇr´ınosem webov´ych sluˇzeb je moˇznost integrace libovoln´ych aplikac´ı provozovan´ych na r˚uzn´ych platform´ach a moˇznost jejich ovl´ad´an´ı prostˇrednictv´ım webov´eho rozhran´ı za pouˇzit´ı vzd´alen´eho vol´an´ı procedur pˇres s´ıt’. V dneˇsn´ı dobˇe jsou vyuˇz´ıv´any dvˇe hlavn´ı architektury pro komunikaci webov´ych sluˇzeb: SOAP a REST.
2.6.1 SOAP
SOAP [24] je oznaˇcen´ı protokolu pro v´ymˇenu zpr´av definovan´ych v jazyce XML, pˇredevˇs´ım pomoc´ı protokolu HTTP. Pr´avˇe d´ıky protokolu HTTP m´a SOAP moˇznost pr˚uchodu pˇres firewall, kde b´yv´a protokol HTTP zpravidla povolen. SOAP tvoˇr´ı z´akladn´ı vrstvu pro komunikaci mezi webov´ymi sluˇzbami a poskytuje prostˇred´ı pro implementaci sloˇzitˇejˇs´ı komunikace.
SOAP definuje strukturu a form´at zpr´avy pomoc´ı XML. Tento form´at je vyuˇz´ıv´an pˇredevˇs´ım z d˚uvodu dostupnosti r˚uzn´ych parsovac´ıch n´astroj˚u v mnoha programo- vac´ıch jazyc´ıch. XML form´at disponuje delˇs´ı syntax´ı, coˇz zvyˇsuje ˇcitelnost zpr´avy pro samotn´eho uˇzivatele a umoˇzˇnuje n´aslednou snadnou validaci obsahu. To umoˇznuje pˇredej´ıt chyb´am pˇri vz´ajemn´e komunikaci, ale tak´e zvyˇsuje pamˇet’ovou n´aroˇcnost, v´ıce procesorov´eho ˇcasu a pˇredevˇs´ım zvyˇsuje reˇzii pˇrenosu. T´ım p´adem je sn´ıˇzena rychlost komunikace.
2.6.2 REST
REST je oznaˇcen´ı architektonick´eho stylu rozhran´ı navrˇzen´eho pro distribuovan´e prostˇred´ı. Rozhran´ı REST je pouˇz´ıvan´e pro jednotn´y pˇr´ıstup ke zdroj˚um (takzvan´ym resources), pˇriˇcemˇz data mohou m´ıt odliˇsnou reprezentaci (ATOM, XML, JSON).
Dneˇsn´ı modern´ı frameworky pro v´yvoj server-side aplikac´ı podporuj´ı tvorbu REST rozhran´ı a dokaˇz´ı definovat procedury pro vˇsechny potˇrebn´e metody, coˇz v´yvoj´aˇr˚um v´yraznˇe ulehˇcuje pouˇz´ıv´an´ı REST rozhran´ı.
Aby mohl b´yt syst´em oznaˇcov´an pojmem REST, je nutn´e, aby splˇnoval ˇsest z´akladn´ıch vlastnost´ı vych´azej´ıc´ıch ze z´akladn´ı myˇslenky jeho pouˇzit´ı [3] - klient - ser- ver architektura, bezstavovost, vyuˇzit´ı cache pamˇeti, k´od na vyˇz´ad´an´ı, vrstven´y syst´em a jednotn´e rozhran´ı.
REST architektura je na rozd´ıl od SOAP orientov´ana datovˇe, nikoliv procedur´alnˇe.
Zdroje (sources) mus´ı vlastnit jedineˇcn´y identifik´ator URI a REST definuje ˇctyˇri z´akladn´ı metody pro pˇr´ıstup k dat˚um.
2.6.3 CRUD
Z´akladn´ı metody pro pˇr´ıstup k dat˚um jsou vytvoˇren´ı dat (CREATE), z´ısk´an´ı konkr´etn´ıch dat (RETRIEVE), zmˇena dat (UPDATE) a koneˇcnˇe smaz´an´ı dat (DE- LETE). Tento pˇr´ıstup je implementov´an dle z´akladn´ıch metod aplikaˇcn´ıho protokolu HTTP.
Implementace CRUD skrze HTTP:
• CREATE – pro vytvoˇren´ı dat slouˇz´ı metoda POST,
• RETRIEVE – metoda pro z´ısk´an´ı zdroje, implementov´ana pomoc´ı metody GET,
• UPDATE – zmˇena jiˇz existuj´ıc´ıch dat implementov´ana metodou PUT,
• DELETE – smaz´an´ı zdroje HTTP metodou DELETE.
Activiti framework a jeho vrstva zajiˇst’uj´ıc´ı REST rozhran´ı jsou st´ale vyv´ıjeny a t´ım jsou rozˇsiˇrov´any moˇznosti vyuˇzit´ı webov´e komunikace s t´ımto frameworkem.
2.7 Zhodnocen´ı aktu´ aln´ıho stavu
Zad´an´ı pr´ace spoˇc´ıv´a ve vytvoˇren´ı klient–server aplikace pro Activiti workflow. Po upˇresnˇen´ı poˇzadavk˚u je c´ılem pr´ace vytvoˇrit vlastn´ı server slouˇz´ıc´ı pro synchronizaci dat a dvˇe klientsk´e ˇc´asti. Tyto klientsk´e ˇc´asti se dˇel´ı na desktopovou, jej´ıˇz ´uˇcel je pˇredevˇs´ım testov´an´ı komunikace, a na naitivn´ı aplikaci pro platformu Android.
Klientsk´a aplikace pro platformu Android komunikuj´ıc´ı s Activiti workflow je do- stupn´a na Google Play [8] pod n´azvem Activiti Explorer Beta. Oznaˇcen´ı beta je vhodn´e,
i kdyˇz popis aplikace slibuje z´akladn´ı funkcionalitu, po zad´an´ı pˇrihlaˇsovac´ıch ´udaj˚u se aplikace, zˇrejmˇe kv˚uli intern´ı chybˇe, ukonˇc´ı. Z tohoto d˚uvodu nebylo moˇzn´e otestovat moˇznosti st´avaj´ıc´ı aplikace. Dle dostupn´eho popisu tak´e aplikace nepodporuje moˇznost pr´ace v tzv. off–line reˇzimu, coˇz bylo jedn´ım z poˇzadavk˚u na v´yslednou aplikaci t´eto pr´ace.
Celkov´e zad´an´ı se ˇr´ıd´ı poˇzadavky zadavatele, tedy spoleˇcnost´ı Actis s.r.o. N´avrh ko- munikace, ve kter´e je centr´aln´ım prvkem server obsluhuj´ıc´ı synchronizaci dat a z´aroveˇn klient pro Activiti workflow, doposud tato spoleˇcnost nevyuˇz´ıv´a. ´Uspˇeˇsn´a implemen- tace je z´aroveˇn d˚ukazem moˇznosti pouˇzit´ı d´ale popsan´ych technologi´ı.
Obˇe klientsk´e ˇc´asti popsan´e v n´asleduj´ıc´ıch kapitol´ach, jsou navrˇzeny a imple- mentov´any dle rozhran´ı vlastn´ıho serveru. Tato vlastnost zaruˇcuje, ˇze jsou klientsk´e aplikace jedineˇcn´ym ˇreˇsen´ım c´ılov´e problematiky.
3 N´ avrh aplikace
C´ılem pr´ace je navrhnout a implementovat aplikaci pro spr´avu vybran´ych poˇzadavk˚u z Activiti workflow. Klientsk´a ˇc´ast aplikace by mˇela b´yt implementov´ana pˇredevˇs´ım jako nativn´ı aplikace pro platformu Android s moˇznost´ı pr´ace s daty i bez internetov´eho pˇripojen´ı (tzv. off–line reˇzim). Vybran´ymi poˇzadavky jsou nastartov´an´ı procesu dle procesn´ı definice uloˇzen´e v Activiti datab´azi a spr´ava ´ukol˚u, na kter´e m´a uˇzivatel pr´avo (task manager). V t´eto kapitole je pops´an zp˚usob komunikace, n´avrh datab´aze a synchronizace dat mezi klientem a serverem.
Prvotn´ım n´avrhem od zadavatele, kter´y mˇel b´yt i zad´an´ım pr´ace, byl n´avrh a im- plementace pouze klientsk´e ˇc´asti pro platformu Android. Komunikace s Activiti fra- meworkem vˇcetnˇe autentizace klient˚u mˇela b´yt implementov´ana pomoc´ı REST roz- hran´ı. Data by byla na stranˇe klienta uchov´ana v SQLite datab´azi. Po konzultaci to- hoto n´avrhu byla zv´aˇzena moˇznost vyuˇzit´ı tzv. centr´aln´ıho prvku, kter´y by umoˇzˇnoval klient˚um komunikaci s v´ıce zdroji informac´ı.
Tento n´avrh byl postupnˇe upravov´an, pˇredevˇs´ım kv˚uli splnˇen´ı nov´ych poˇzadavk˚u na moˇznosti aplikace. Tˇemi byly snadn´a moˇznost zmˇeny autentizace uˇzivatel˚u, pˇr´ıpadn´a snadn´a a rychl´a reakce na zmˇenu Activiti REST rozhran´ı. Pro splnˇen´ı vˇsech poˇzadavk˚u byl vytvoˇren fin´aln´ı n´avrh, ve kter´em je centr´aln´ım prvkem reprezentov´an vlastn´ı server s webovou sluˇzbou.
Obr´azek 5: N´avrh implementace
Server bude umoˇzˇnovat klient˚um spr´avu poˇzadavk˚u ve v´ıce zdroj´ıch (datab´az´ıch) prostˇrednictv´ım jednoho pˇripojen´ı. D´ale bude umoˇznˇena snadn´a zmˇena autentizace na jednom m´ıstˇe. Klientsk´a ˇc´ast aplikace vˇzdy odes´ıl´a autentizaˇcn´ı data v pevnˇe de- finovan´em form´atu, zp˚usob autentizace jiˇz bude zprostˇredkov´avat server. Z´aleˇz´ı na samotn´e konfiguraci serveru, zda ovˇeˇr´ı uˇzivatele oproti Activiti frameworku, nebo pˇr´ıpadnˇe oproti LDAPu. Server slouˇz´ı jako prostˇredn´ık pro komunikaci mezi klienty a Activiti frameworkem, proto se reakce na pˇr´ıpadnou zmˇenu Activiti REST API t´yk´a pouze serverov´e ˇc´asti.
Za ´uˇcelem moˇznosti vyuˇzit´ı klientsk´e aplikace tak´e na poˇc´ıtaˇci (nejen emul´ator plat- formy Android) a pro snadnˇejˇs´ı moˇznost testov´an´ı vz´ajemn´e komunikace mezi klientem a serverem je v poˇzadavc´ıch pr´ace implementace dvou klientsk´ych ˇc´ast´ı. Klientsk´a apli- kace implementov´ana pro platformu Android a druh´a jako desktopov´a aplikace v jazyce Java. Poˇzadavky na aplikaci jsou snadn´a rozˇs´ıˇritelnost pro pˇr´ıpadn´e obecnˇejˇs´ı vyuˇzit´ı a vyuˇzit´ı moˇznost´ı Activiti frameworku bez z´asahu do jeho aktu´aln´ı implementace.
3.1 N´ avrh komunikace
Po kompletn´ım n´avrhu aplikace na nejvyˇsˇs´ı ´urovni abstrakce (obr´azek 5) je potˇreba zv´aˇzit a urˇcit moˇznosti samotn´e implementace. Jedn´ım ze stˇeˇzejn´ıch faktor˚u je volba implementace komunikace.
Komunikac´ı mezi serverem a klientem byla zvolena webov´a sluˇzba vyuˇz´ıvaj´ıc´ı REST rozhran´ı. Webov´a sluˇzba byla vybr´ana pˇredevˇs´ım pro snadnou rozˇsiˇritelnost v pˇr´ıpadˇe potˇreby, podporu v´yvoj´aˇrsk´ych framework˚u a vyuˇzitelnost ve vˇetˇsinˇe dneˇsn´ıch modern´ıch aplikac´ı.
Datov´y komunikaˇcn´ı model ve form´atu JSON [2] poskytuj´ıc´ı Activiti framework mus´ı b´yt zpracov´an na stranˇe serveru. Server mus´ı b´yt schopen data nejen pˇrijmout, ale tak´e odes´ılat (autentizaˇcn´ı informace o uˇzivatel´ıch, hodnoty procesn´ıch promˇenn´ych pro dokonˇcen´ı ´ukol˚u atd.). Proto je vhodn´ym ˇreˇsen´ım vyuˇz´ıt alespoˇn ˇc´ast tohoto datov´eho modelu ve form´atu JSON tak´e pro komunikaci mezi serverem a klientem.
Form´at JSON m´a (podle dostupn´eho porovn´an´ı od v´yvoj´aˇr˚u z MyDevNotes [15]) kratˇs´ı d´elku neˇz form´at XML, coˇz je z hlediska objemu pˇren´aˇsen´ych dat v´yhodn´e. Pokud je tento form´at vyuˇz´ıv´an Activiti webovou sluˇzbou, bylo by zbyteˇcn´e na stranˇe ser- veru pˇrev´adˇet form´at JSON napˇr´ıklad do form´atu XML. Dalˇs´ı a nem´enˇe v´yznamnou v´yhodou je podpora form´atu JSON jak v jazyce Java pro v´yvoj desktopov´ych aplikac´ı, tak i v jazyce Java pro v´yvoj aplikac´ı na platformˇe Android.
3.2 N´ avrh datab´ aze
Z poˇzadavku na moˇznost centr´alnˇe spravovat data z v´ıce Activiti datab´az´ı a n´aslednou synchronizaci s klientem vych´az´ı urˇcit´e n´aroky na uloˇzen´ı dat. Data je nutn´e uchov´avat jak na stranˇe serveru, tak na stranˇe klienta pro moˇznost pr´ace s aplikac´ı v off–line reˇzimu. Jako datab´azov´y syst´em na stranˇe serveru a desktopov´e klientsk´e ˇc´asti v jazyce Java byl pro svoji licenci, multiplatformnost a tak´e vyuˇzit´ı v jin´ych projektech zvolen server MySQL 5.6. [18].
3.2.1 Server datab´aze
Na stranˇe serveru je potˇreba uchov´avat data o URL webov´ych sluˇzb´ach jednot- liv´ych Activiti framework˚u. D´ale data o uˇzivatel´ıch, kteˇr´ı maj´ı pˇr´ıstup a moˇznost spravovat ´ukoly a procesy v tˇechto Activiti datab´az´ıch.
Spr´ava ´ukol˚u a start nov´ych proces˚u definuj´ı potˇrebu ukl´adat a synchronizovat datov´e objekty obsahuj´ıc´ı veˇsker´e informace o ´ukolech a procesn´ıch definic´ıch. D´ale pro moˇznost dokonˇcen´ı ´ukolu a vyplnˇen´ı hodnot pˇr´ıpadn´ych procesn´ıch promˇenn´ych jsou uchov´av´any formul´aˇre a jejich vlastnosti.
Z tˇechto poˇzadavk˚u byl vytvoˇren n´asleduj´ıc´ı ERD model datab´aze na stranˇe serveru zachycuj´ıc´ı jednotliv´e vazby mezi entitami.
Obr´azek 6: ERD model server datab´aze
Atributy entit ´ukol (task), proces (proc def), formul´aˇr (form) a formul´aˇrov´a vlast- nost (form properties), jsou urˇceny jiˇz z Activiti datab´aze. Pro jejich jednoznaˇcnou identifikaci v datab´azi jsou tyto entity rozˇs´ıˇreny o pˇrirozen´y kl´ıˇc. D´ale jsou uloˇzeny informace o klientech a skupin´ach, ve kter´ych je konkr´etn´ı uˇzivatel ˇclenem.
Datab´aze by v pˇr´ıpadn´em rozˇs´ıˇren´ı aplikace mohla slouˇzit tak´e jako centr´aln´ı zdroj informac´ı napˇr´ıklad pro statistick´e pˇrehledy vyuˇz´ıv´an´ı jednotliv´ych Activiti webov´ych sluˇzeb. V´yhodou komunikace klient˚u pˇres server je moˇznost centr´aln´ı modifikace a va- lidace uloˇzen´ych dat, pˇr´ıpadnˇe z´ısk´an´ı dat z jin´eho datov´eho zdroje.
3.2.2 Klientsk´a datab´aze
Poˇzadavkem na klientskou aplikaci bylo tak´e jej´ı vyuˇzit´ı v takzvan´em off–line reˇzimu (bez pˇripojen´ı k internetu). T´ımto poˇzadavkem je nutn´e uchov´avat data nejen na serveru, ale tak´e v samotn´e klientsk´e ˇc´asti aplikace. Uloˇzen´ı dat mus´ı b´yt navrˇzeno
tak, aby klient mohl zpracov´av´at poˇzadavky a tyto zmˇeny zaznamen´avat pro n´aslednou synchronizaci v on–line reˇzimu.
Obr´azek 7: ERD model klientsk´e datab´aze
Pro uloˇzen´ı dat v klientsk´e ˇc´asti pro platformu Android byl vyuˇzit intern´ı da- tab´azov´y syst´em SQLite [21]. MySQL Workbench umoˇznuje snadn´y export EER mo- delu do SQL skriptu. Pro pˇrevod tohoto n´avrhu do SQLite skriptu byl vyuˇzit on- line convertor MySQL to SQLite [14]. V´ysledek konvertoru bylo potˇreba dodateˇcnˇe manu´alnˇe upravit dle SQLite dokumentace. Desktopov´a aplikace v jazyce Java vyuˇz´ıv´a stejnˇe jako server datab´azi MySQL ve verzi 5.6.
V´ysledn´y ERD model klientsk´e datab´aze je, co se t´yˇce samotn´ych dat (proces,
´
ukol, formul´aˇr), t´emˇeˇr totoˇzn´y s modelem datab´aze na serveru. Rozd´ıln´e jsou prim´arn´ı kl´ıˇce jednotliv´ych tabulek. Klientsk´a aplikace je od zaˇc´atku navrhov´ana jako jed- nouˇzivatelsk´a, nen´ı tedy nutn´e uchov´avat data o v´ıce uˇzivatel´ıch ani jejich identifik´ator pouˇz´ıvat jako souˇc´ast kl´ıˇce. D´ale je v klientsk´e datab´azi pˇrid´ana tabulka user, ve kter´e jsou uchov´av´any informace o konkr´etn´ım uˇzivateli. Tato tabulka slouˇz´ı pro off–line pˇrihlaˇsov´an´ı a uchov´an´ı stavu aplikace.
3.3 Synchronizace dat
Pokud jsou klientsk´a data uchov´av´ana na stranˇe serveru a z´aroveˇn m´a kaˇzd´y uˇzivatel sv´a data ve sv´e klientsk´e datab´azi (pro moˇznost pr´ace v off–line reˇzimu), je nutn´e tato data synchronizovat a udrˇzovat tak v aktu´aln´ım stavu jak na serveru, tak v klientsk´e ˇc´asti aplikace.
Synchronizace dat znamen´a z´ısk´an´ı nov´ych ´ukol˚u a proces˚u pro konkr´etn´ıho kli- enta. Samozˇrejmˇe tak´e smaz´an´ı jiˇz vyˇreˇsen´ych ´ukol˚u a proces˚u, kter´e se jiˇz v Activiti datab´azi nevyskytuj´ı. Bˇehem synchronizace je proveden pˇr´ıpadn´y start proces˚u ˇci do- konˇcen´ı ´ukol˚u. Pˇri n´avrhu synchronizace je nutn´e b´yt sezn´amen s postupem vykon´av´an´ı urˇcit´ych krok˚u v Activiti frameworku a urˇcit prioritu jednotliv´ych ˇc´ast´ı synchronizace.
3.3.1 Prvotn´ı n´avrh synchronizace
Definice procesu je uloˇzena v datab´azi a ´ukoly postupnˇe vznikaj´ı pˇri vykon´av´an´ı samotn´eho procesu. Detailnˇejˇs´ı popis z´akladn´ı funkce Activiti frameworku je uveden v kapitole Z´akladn´ı pouˇzit´ı frameworku (2.4). Z´akladn´ı funkcionalita frameworku defi- nuje urˇcit´e vlastnosti:
• proces - je urˇcen definic´ı procesu v Activiti datab´azi,
• ´ukol - vznik´a pˇri startu procesu nebo po dokonˇcen´ı pˇredchoz´ıho ´ukolu, jeho de- finice vych´az´ı z definice procesu.
Tyto vlastnosti urˇcuj´ı seˇrazen´ı vˇsech 4 krok˚u synchronizace mezi serverem a Acti- viti frameworkem. Z klientsk´eho hlediska m´a vyˇsˇs´ı prioritu start nov´ych proces˚u a do- konˇcen´ı poˇzadovan´ych ´ukol˚u. Aˇz pot´e je dle priority jejich synchronizace. Toto poˇrad´ı je tak´e logicky urˇceno vznikem nov´ych ´ukol˚u aˇz po dokonˇcen´ı pˇredchoz´ıho ´ukolu nebo startem nov´eho procesu. V´ysledn´e kroky synchronizace jsou n´asleduj´ıc´ı:
• 1. krok – nastartov´an´ı proces˚u,
• 2. krok – dokonˇcen´ı vˇsech poˇzadovan´ych ´ukol˚u,
• 3. krok – synchronizace proces˚u,
• 4. krok – synchronizace ´ukol˚u.
Samotn´a synchronizace dat m´a b´yt po konzultaci se zadavatelem realizov´ana po- moc´ı z´akladn´ıch operac´ı s mnoˇzinami. Pˇri synchronizaci ´ukol˚u si server vyˇz´ad´a pro konkr´etn´ıho klienta vˇsechny ´ukoly ze vˇsech Activiti datab´az´ı. Tato data tvoˇr´ı jednu mnoˇzinu M1 (viz obr´azek 8). D´ale z´ısk´a z vlastn´ı datab´aze vˇsechny st´avaj´ıc´ı ´ukoly pro konkr´etn´ıho uˇzivatele - druhou mnoˇzinu M2.
Nyn´ı pokud provedeme mnoˇzinov´e odeˇcten´ı M1 - M2, z´ısk´ame podmnoˇzinu, jeˇz tvoˇr´ı ´ukoly, kter´e doposud server ve sv´e datab´azi nem´a, tud´ıˇz se jedn´a o nov´a data (ID 100, 101).
Pokud provedeme opaˇcn´e odeˇcten´ı M2 - M1, z´ısk´ame tak podmnoˇzinu, kterou tvoˇr´ı
´
ukoly, kter´e se nevyskytuj´ı v ˇz´adn´e Activiti datab´azi (ID 103, 104). To znamen´a, ˇze tato data jiˇz byla smaz´ana a m˚uˇzeme je oznaˇcit jako star´a data. Stejn´y postup je moˇzn´e pouˇz´ıt i pˇri synchronizaci proces˚u.
Obr´azek 8: Zn´azornˇen´ı mnoˇzin
Touto ˇc´ast´ı je vyˇreˇsena synchronizace mezi serverem a Activiti datab´azemi. D´ale zb´yv´a navrhnout synchronizaci dat mezi datab´az´ı serveru a klienta. N´avrh na syn- chronizaci se skl´adal z n´asleduj´ıc´ıch krok˚u:
1. dle klientsk´eho ID synchronizovat data mezi serverem a Activiti datab´az´ı, 2. nov´a data uloˇzit na serveru a z´aroveˇn je odeslat klientsk´e aplikaci s oznaˇcen´ım
nov´ych dat,
3. star´a data ze serveru smazat a z´aroveˇn je odeslat klientsk´e aplikaci s oznaˇcen´ım star´ych dat.
Tento postup byl demonstrativnˇe implementov´an a otestov´an. Hlavn´ım nedostat- kem testov´an´ı se ovˇsem prok´azala nemoˇznost sesynchronizovat data s v´ıce klientsk´ymi aplikacemi, kter´e pouˇz´ıv´a jeden uˇzivatel. Server mˇel v tuto chv´ıli ve sv´e datab´azi stejn´a data jako jedna konkr´etn´ı klientsk´a aplikace. Pˇr´ı v´yvoji druh´e klientsk´e ˇc´asti a poˇzadavku na pouˇz´ıv´an´ı obou dvou klientsk´ych aplikac´ı jedn´ım uˇzivatelem z´aroveˇn (mobiln´ı aplikace i desktopov´a aplikace vyuˇz´ıv´ana z´aroveˇn jedn´ım uˇzivatelem) bylo nutn´e navrhnout a implementovat sofistikovanˇejˇs´ı ˇreˇsen´ı, jeˇz by umoˇzˇnovalo nez´avislou synchronizaci s v´ıce klientsk´ymi aplikacemi.
Pˇri synchronizaci ´ukol˚u jsou vˇzdy souˇcasnˇe synchronizov´any i ostatn´ı data s nimi spojen´a – formul´aˇre a jejich vlastnosti. Pˇri ukl´ad´an´ı nov´ych ´ukol˚u do datab´aze jsou vyˇz´ad´ana a uloˇzena tak´e formul´aˇrov´a data. Souˇcasnˇe se smaz´an´ım ´ukol˚u jsou kask´adovˇe smaz´ana i vˇsechna formul´aˇrov´a data, kter´a jsou na ´ukol v datab´azi v´az´ana ciz´ım kl´ıˇcem. Tento mechanismus je pouˇzit jak na serveru, tak i v klientsk´e ˇc´asti apli- kace.
3.3.2 Koneˇcn´y n´avrh synchronizace
V´yˇse uveden´y n´avrh neˇreˇs´ı kompletn´ı problematiku uloˇzen´ı dat na stranˇe serveru a synchronizaci, proto byl n´avrh upraven do n´asleduj´ıc´ı podoby.
Obr´azek 9: Sch´ema koneˇcn´eho n´avrhu synchronizace
Server uchov´av´a aktu´aln´ı data klient˚u v datab´azi. Kaˇzd´a z klientsk´ych aplikac´ı ovˇsem m˚uˇze m´ıt data ve sv´e datab´azi r˚uzn´a. Synchronizaci je tedy nutn´e prov´adˇet s kaˇzd´ym klientsk´ym zaˇr´ızen´ım individu´alnˇe. Proto byla ve v´ysledku navrˇzena syn- chronizace skl´adaj´ıc´ı se ze dvou ˇc´ast´ı. Prvn´ı ˇc´ast slouˇz´ı k synchronizaci mezi serve- rem a Activiti datab´azemi, ve druh´e ˇc´asti jsou sesynchronizov´ana data mezi serverem a konkr´etn´ım klientem. Klient tedy ve sv´em poˇzadavku zas´ıl´a serveru informace o da- tech, kter´e jiˇz vlastn´ı ve sv´e datab´azi.
V prvn´ı f´azi (f´aze 1) na obr´azku 9 odes´ıl´a klient poˇzadavek na synchronizaci (po- drobn´y popis poˇzadavku a odpovˇedi v pˇr´ıloze 1.5). Server podle klientsk´eho ID sesyn- chronizuje vlastn´ı data s Activiti datab´az´ı (s jednou ˇci v´ıce dle konfigurace). Po tomto kroku jsou data na serveru v aktu´aln´ı podobˇe.
Ve druh´e f´azi (f´aze 2) doch´az´ı k synchronizaci dat mezi klientem a aktu´aln´ımi daty na serveru. Klient jiˇz ve sv´em ´uvodn´ım poˇzadavku zas´ıl´a informaci o datech, kter´a m´a ve sv´e vlastn´ı datab´azi. Podle tˇechto ´udaj˚u jsou data v´yˇse popsan´ym zp˚usobem (pr´ace s mnoˇzinami) sesynchronizov´ana a v posledn´ım kroku server odes´ıl´a odpovˇed’
se stavem synchronizace, nov´ymi a star´ymi daty.
3.4 Vyuˇ zit´ı modern´ıch programovac´ıch prostˇ redk˚ u
V souladu s modern´ımi pˇr´ıstupy k n´avrhu aplikace v objektov´em jazyce byly vyuˇzity pˇri implementaci nˇekter´e z n´avrhov´ych vzor˚u nebo jejich ˇc´ast´ı.
N´avrhov´e vzory nab´ız´ı svoj´ı koncepc´ı snadn´e ˇreˇsen´ı typick´ych program´atorsk´ych probl´em˚u a zvyˇsuj´ı efektivitu pr´ace. Nejedn´a se pˇr´ımo o ˇc´asti zdrojov´ych k´od˚u, ale o po- stup, jak ˇreˇsit dan´y probl´em. Objektov´e n´avrhov´e vzory vyuˇz´ıvaj´ı vlastnost´ı objektovˇe orientovan´ych jazyk˚u, jako jsou rozhran´ı (interface) ˇci polymorfismus. Problematika a pˇr´ıklady praktick´eho vyuˇzit´ı n´avrhov´ych vzor˚u jsou obsaˇzeny v knize N´avrhov´e vzory od pana Pecinovsk´eho [19].
Konkr´etn´ı vyuˇzit´ı n´avrhov´ych vzor˚u v t´eto pr´aci je pops´ano v kapitole 4.2.6 a 4.2.7.
4 Implementace
Po kompletn´ım n´avrhu aplikace popsan´e v kapitole 3 se podaˇrilo tento n´avrh imple- mentovat. Tato kapitola popisuje kl´ıˇcov´e postupy, zvolen´e implementaˇcn´ı prostˇredky a metody samotn´e implementace jak serverov´e ˇc´asti aplikace, tak i desktopov´e a mo- biln´ı klientsk´e aplikace.
C´ılem projektu bylo vytvoˇrit aplikaci, kter´a by byla snadno rozˇsiˇriteln´a nejen o REST rozhran´ı, ale tak´e o pˇr´ıpadn´e zpracov´an´ı a synchronizaci dat z jin´eho da- tov´eho ´uloˇziˇstˇe.
4.1 Server
Serverov´a aplikace s webovou sluˇzbou vyuˇz´ıvaj´ıc´ı REST rozhran´ı (2.6.2) byla im- plementov´ana na aplikaˇcn´ım serveru GlassFish 3.1.2 [16] v jazyce Java. V´yvojov´e prostˇred´ı Eclipse Juno nab´ız´ı po instalaci pluginu pˇr´ımou spr´avu tohoto aplikaˇcn´ıho serveru a urychluje t´ım v´yvoj a pˇr´ıpadn´e testov´an´ı aplikace.
Obr´azek 10: Z´akladn´ı sch´ema server ˇc´asti
Samotn´a implementace byla rozdˇelena do nˇekolika krok˚u:
• komunikace – implementace REST rozhran´ı pro komunikaci jak s Activiti fra- meworkem, tak s klientsk´ymi aplikacemi,
• synchronizace – implementace synchronizace dat,
• datov´y model – vytvoˇren´ı konkr´etn´ıch komunikaˇcn´ıch a datov´ych objekt˚u.
4.1.1 Komunikace
Aplikaˇcn´ı server GlassFish nab´ız´ı podporu implementace REST rozhran´ı. Roz- hran´ı je implementov´ano Java tˇr´ıdou s metodami a potˇrebn´ymi anotacemi, intern´ı zpracov´an´ı poˇzadavku jiˇz zˇrizuje aplikaˇcn´ı framework. Tˇr´ıda mus´ı m´ıt pˇred svoj´ı de- klarac´ı definovanou tzv. path. Ta urˇcuje, kter´a tˇr´ıda a metoda m´a b´yt vol´ana po pˇrijet´ı poˇzadavku na konkr´etn´ı URL. N´asleduj´ıc´ı ˇc´ast zn´azorˇnuje deklaraci tˇr´ıdy a jej´ı metody pro zpracov´an´ı poˇzadavku na start proces˚u:
@Path("process-definitions")
public class RSProcessDefinitions {
@POST
@Path("start")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response startProcessDefinitions(StartProcess process){
. . . }
}
Po pˇrijet´ı poˇzadavku na URL:
http:/IP SERVER:PORT/process-definitons/start
je tento poˇzadavek zpracov´an metodou startProcessDefinitions a n´aslednˇe je vr´acena odpovˇed’ ve form´atu JSON.
T´ımto zp˚usobem je implementov´ano cel´e REST rozhran´ı poskytuj´ıc´ı metody pro klientsk´e ˇz´adosti na zpracov´an´ı ˇci synchronizaci dat.
4.1.2 Komunikaˇcn´ı model
Samotn´e komunikaˇcn´ı objekty a jejich atributy pro komunikaci mezi serverem a Activiti webovou sluˇzbou byly urˇceny form´atem JSON, kter´y webov´a sluˇzba vrac´ı (2.3). Podle struktury dat byly implementov´any potˇrebn´e objekty nejprve pro komu- nikaci mezi serverem a Activiti webovou sluˇzbou.
Pˇr´ıklad form´atu JSON popsan´y v kapitole 2.3 urˇcuje, jak webov´a sluˇzba vrac´ı konkr´etn´ı data napˇr´ıklad o objektu proces. Tato data jsou obsaˇzena v poli s n´azvem data. Pro pˇrijet´ı a zpracov´an´ı cel´e odpovˇedi je potˇreba pˇrijmout objekt cel´y, vˇcetnˇe
doplˇnuj´ıc´ıch ´udaj˚u (total, start, sort ). Proto byly navrˇzeny objekty, u kter´ych jsou je- jich atributy shodn´e s atributy form´atu JSON. Postup n´avrhu a implementace objekt˚u jsou pops´any v n´asleduj´ıc´ım pˇr´ıkladu.
Po odesl´an´ı poˇzadavku za ´uˇcelem z´ısk´an´ı seznamu proces˚u z Activiti datab´aze je pˇrijata odpovˇed’ ve form´atu:
{
"total": 1,
"start": 0,
"sort": "id",
"order": "asc",
"size": 1,
"data": [ {
"id": "create_new_account:1",
"key": "new_account",
"version": 1 }
] }
Pro zpracov´an´ı tˇechto dat jsou deklarov´any n´asleduj´ıc´ı tˇr´ıdy popisuj´ıc´ı poˇzadovan´e objekty (uk´azka k´odu je pouze ilustraˇcn´ı):
class ListProcessDefinitions{
private int total;
private int start;
private String id;
private String order;
private int size;
private ArrayList<ProcessDefinition> data;
}
class ProcessDefinition{
private String id;
private String key;
private int id;
}
V´ysledn´a, p˚uvodnˇe poˇzadovan´a data, jsou z´ısk´ana jako seznam objekt˚u ProcessDe- finition z pˇrijat´eho objektu ListProcessDefinitions. T´ımto zp˚usobem je navrˇzena a im- plementov´ana tak´e komunikace mezi serverem a klientem.
4.1.3 Autentizace klient˚u
Aktu´aln´ı zp˚usob autentizace klient˚u zprostˇredkov´av´a server. Klienti jsou dle sv´eho klientsk´eho ID a hesla ovˇeˇrov´ani oproti webov´e sluˇzbˇe Activiti frameworku. Po ´uspˇeˇsn´e autentizaci je zaruˇcena n´asledn´a moˇznost komunikace konkr´etn´ıho uˇzivatele s danou webovou sluˇzbou. Kaˇzd´y dalˇs´ı poˇzadavek pro komunikaci s Activiti webovou sluˇzbou mus´ı obsahovat ve sv´e hlaviˇcce klientsk´e ID a heslo.
Pokud m´a klient nastaven na stranˇe serveru pˇr´ıstup k v´ıce datov´ym zdroj˚um (Activiti webov´ych sluˇzeb), je pˇri procesu pˇrihl´aˇsen´ı ovˇeˇren oproti vˇsem datab´az´ım.
V´ysledek autentizace je nejen pˇreposl´an klientovi, ale tak´e uchov´an na stranˇe serveru.
Pokud autentizace selˇze (uˇzivatel jiˇz nem´a ´uˇcet v datab´azi, chybn´e ID nebo heslo), synchronizace dat se s touto datab´az´ı d´ale neprov´ad´ı.
Kaˇzd´y klient m´a na stranˇe serveru minim´alnˇe jeden z´aznam v tabulce user source.
Pˇri poˇzadavku na autentizaci server z datab´aze z´ısk´a vˇsechny z´aznamy pro konkr´etn´ıho uˇzivatele a provede autentizaci oproti vˇsem webov´ym sluˇzb´am.
V´ysledek autentizace je uloˇzen k odpov´ıdaj´ıc´ımu z´aznamu jako atribut isActive.
T´ım je uchov´an stav posledn´ı autentizace klienta, kter´y je kontrolov´an pˇri pˇr´ıpadn´e synchronizaci.
Po ´uspˇeˇsn´e autentizaci klienta si server vyˇz´ad´a kompletn´ı seznam skupin, ve kter´ych je konkr´etn´ı uˇzivatel ˇclenem. Tyto informace jsou uloˇzeny v datab´azi na stranˇe serveru a jsou d´ale vyuˇzity pˇri datov´e synchronizaci pro z´ısk´an´ı vˇsech dostupn´ych
´ ukol˚u.
4.1.4 Synchronizace dat
Kompletn´ı logika aplikace byla pˇri koneˇcn´em n´avrhu aplikace pˇresunuta na stranu serveru. Klientsk´a ˇc´ast proto nebude muset b´yt ve vˇetˇsinˇe pˇr´ıpad˚u zmˇeny modifi- kov´ana, pˇr´ıpadn´e zmˇeny se budou t´ykat pouze centr´aln´ıho prvku – serveru.
Server m´a za ´ukol nejen autentizaci klient˚u, ale tak´e synchronizaci jejich dat.
V´yhodou centr´aln´ı synchronizace je moˇznost modifikace a kontrola dat, jeˇz jsou n´aslednˇe odesl´any klient˚um.
V t´eto pr´aci byla implementov´ana synchronizace dle koneˇcn´eho n´avrhu (3.3.2).
V prvn´ı f´azi synchronizace jsou dle poˇzadavku odpov´ıdaj´ıc´ı data klienta na stranˇe serveru sesynchronizov´ana s Activiti datab´az´ı, pot´e jsou synchronizov´ana samotn´a data mezi aktu´aln´ımi daty na serveru a koncov´ym klientem.
Klient vˇzdy pouze odes´ıl´a ˇz´adost o synchronizaci (obsahuj´ıc´ı informaci o vlastn´ıch datech) a pˇrijme synchronizaˇcn´ı odpovˇed’ s jiˇz synchronn´ımi daty.
Jazyk Java nab´ız´ı pr´aci s mnoˇzinami pomoc´ı kolekce Set. Pˇri implementaci byla vytvoˇrena tˇr´ıda Synchronization, jeˇz sv´ymi metodami obaluje pr´aci s mnoˇzinamy a im- plementuje metody, jako jsou napˇr´ıklad vz´ajmen´e odeˇcten´ı mnoˇzin nebo jejich pr˚unik.
V´ysledn´y rozd´ıl vrac´ı opˇet jako mnoˇzinu objekt˚u, kter´a je d´ale zpracov´ana. K tomu, aby mohla b´yt mnoˇzina objekt˚u odeˇctena od jin´e, je potˇreba, aby konkr´etn´ı objekt implementoval rozhran´ı Comparable a jeho metodu compareTo, ve kter´e jiˇz v´yvoj´aˇr mus´ı implementovat krit´erium vz´ajemn´eho porovn´an´ı.
V prvotn´ı implementaci byl, jako krit´erium pro porovn´an´ı, zvolen sloˇzen´y iden- tifik´ator, kter´y se skl´adal ze dvou ˇc´ast´ı. Prvn´ı z nich byl identifik´ator dat z´ıskan´y z Activiti datab´aze ( ID ´ukolu), ˇc´ast druhou tvoˇrilo URL Activiti webov´e sluˇzby, ze kter´e data poch´az´ı. T´ımto identifik´atorem byla zaruˇcena jednoznaˇcnost kaˇzd´eho da- tov´eho objektu ve zpracov´avan´e mnoˇzinˇe.
Bˇehem testov´an´ı se ovˇsem tato implementace prok´azala jako nedostaˇcuj´ıc´ı z n´asleduj´ıc´ıho d˚uvodu. Pro zjednoduˇsen´ı si lze pˇredstavit pˇr´ıklad s jedin´ym ´ukolem v Activiti datab´azi a jedn´ım klientem (obr´azek 11). Kaˇzd´y objekt ´ukol obsahuje nˇekolik atribut˚u (napˇr´ıklad description), kter´e se mohou na z´akladˇe uˇzivatelsk´e potˇreby zmˇenit, tuto zmˇenu je nutn´e distribuovat i mezi ostatn´ı klienty.
Modelov´a situace vypad´a n´asledovnˇe:
• Activiti datab´aze – obsahuje ´ukol s ID 100, tento ´ukol m´a zpracovat uˇzivatel user (user ID je v poli assignee viz. 2.4).
• Server – jiˇz ve sv´e datab´azi tento ´ukol uchov´av´a, pˇri jeho pˇrijet´ı pˇridal k tomuto objektu hodnotu atributu URL, pro jeho jedineˇcnou identifikaci.
• Klient – jehoˇz ID je user jiˇz tak´e tento ´ukol uchov´av´a ve sv´e datab´azi.
Obr´azek 11: Modelov´a situace probl´emu synchronizace
Nyn´ı dojde ke zmˇenˇe dat v Activiti datab´azi (napˇr´ıklad description). Zmˇen´ı se pouze description, ID tohoto ´ukolu z˚ustane nezmˇenˇeno. N´aslednˇe klient zaˇz´ad´a o syn- chronizaci. Server si vyˇz´ad´a vˇsechny ´ukoly pro uˇzivatele user. Obdrˇz´ı pouze jedin´y s identifik´atorem 100 a s URL activiti url. Tato data sesynchronizuje s daty z vlastn´ı
datab´aze – opˇet ´ukoly pro uˇzivatele user s ID 100 a URL activiti url. Porovn´avac´ı kl´ıˇc je sloˇzen pr´avˇe z hodnot 100 (ID ´ukolu) a activiti url (URL webov´e sluˇzby), proto je synchronizace vyhodnocena s v´ysledkem data aktu´aln´ı. Klient je tedy informov´an, ˇze vˇsechna jeho data jsou v aktu´aln´ı podobˇe.
Tento v´ysledek je ovˇsem nepravdiv´y, protoˇze p˚uvodnˇe doˇslo ke zmˇenˇe descrip- tion. Tato zmˇena nebyla zohlednˇena bˇehem synchronizace, a proto bylo nutn´e navrh- nout a implementovat sofistikovanˇejˇs´ı ˇreˇsen´ı dan´eho probl´emu, kter´e by zohledˇnovalo pˇr´ıpadnou zmˇenu dat v datab´azi (nejen ID ´ukolu).
V pˇr´ıpadˇe shodn´ych ID ´ukol˚u bylo moˇzn´e postupn´e porovn´av´an´ı vˇsech vz´ajemn´ych atribut˚u objekt˚u (napˇr´ıklad object1.description vs object2.description atd). Tento po- stup by byl ovˇsem velmi neefektivn´ı pˇredevˇs´ım z ˇcasov´e a v´ypoˇcetn´ı n´aroˇcnosti. Proto bylo implementov´ano n´asleduj´ıc´ı ˇreˇsen´ı.
Server pˇri pˇrijet´ı ´ukolu z Activiti datab´aze k tomuto objektu dopln´ı nejen acti- viti url, ale tak´e vypoˇc´ıt´a HASH z poˇzadovan´ych atribut˚u, u kter´ych mohlo doj´ıt ke zmˇenˇe. Pˇri synchronizaci jiˇz nen´ı porovn´an´ı prov´adˇeno na z´akladˇe ID a URL, ale na z´akladˇe vypoˇc´ıtan´e hodnoty HASH. Pˇr´ıpadn´a shoda HASH znaˇc´ı identick´y ´ukol vˇcetnˇe vˇsech atribut˚u, pˇr´ıpadn´a neshoda znaˇc´ı zmˇenu nˇekter´eho atributu.
V jazyce Java bylo tohoto ˇreˇsen´ı doc´ıleno vyuˇzit´ım anotac´ı u poˇzadovan´ych atri- but˚u. Pouˇzit´ı vlastn´ıho anotaˇcn´ı rozhran´ı TaskHash a java.lang.reflect je umoˇznˇeno z´ıskat hodnoty atribut˚u objektu oznaˇcen´e konkr´etn´ı anotac´ı. Z tˇechto hodnot po pˇrijet´ı dat na serveru vypoˇc´ıtat hodnotu HASH a uloˇzit ji jako atribut objektu.
V´ysledn´a tˇr´ıda UserTask je tedy definov´ana s implementac´ı Comparable rozhran´ı a jednotliv´e atributy, u kter´ych m˚uˇze doj´ıt ke zmˇenˇe, jsou oznaˇceny anotac´ı TaskHash:
public class UserTask implements Comparable<UserTask> {
@TaskHash
private int id;
@TaskHash
private String name;
. . }
Z takto oznaˇcen´ych atribut˚u je vypoˇc´ıt´an HASH, kter´y je n´aslednˇe porovn´av´an.
Implementace porovn´an´ı ˇretˇezc˚u v jazyce Java je doporuˇcov´ana pomoc´ı metody equals (dle Java tutorial [22]). Tento zp˚usob se bˇehem n´asledn´eho testu uk´azal jako ne- dostaˇcuj´ıc´ı. Nˇekter´e HASH hodnoty, i pˇresto, ˇze se shodovaly, tato metoda vyhodnotila jako r˚uzn´e a synchronizace nezaruˇcovala korektnost dat.
Tento probl´em je ˇreˇsen vyuˇzit´ım tˇr´ıdy Collator, kter´a slouˇz´ı k lingvisticky spr´avn´emu porovn´an´ı textov´ych ˇretˇezc˚u. Tato implementace se bˇehem testov´an´ı prok´azala jako dostateˇcnˇe rychl´a a ve vˇsech testovan´ych pˇr´ıpadech poskytovala ko- rektn´ı v´ysledek porovn´an´ı.
Na UML diagramu ˇc´ıslo 12 je zn´azornˇen vztah mezi tˇr´ıdami implementuj´ıc´ımi pˇr´ıjem poˇzadavku, zpracov´an´ı a odesl´an´ı odpovˇedi. Sch´ema zobrazuje tˇr´ıdy pro zpra- cov´an´ı poˇzadavku, kter´y m´a sesynchronizovat uˇzivatelsk´e ´ukoly.
Aplikace byla vyvinuta pro snadn´e rozˇs´ıˇren´ı st´avaj´ıc´ı funkcionality. Proto jsou tˇr´ıdy implementuj´ıc´ı zpracov´an´ı konkr´etn´ıch objekt˚u rozˇs´ıˇreny od tˇr´ıd abstraktn´ıch, kter´e jiˇz implementuj´ı spoleˇcn´e metody pro pr´aci s datov´ymi objekty, pˇr´ıstup do datab´aze, vyuˇzit´ı logov´an´ı ˇci napˇr´ıklad komunikaci se samotnou webovou sluˇzbou poskytuj´ıc´ı Activiti framework.
Pˇri pˇr´ıpadn´em roˇs´ıˇren´ı aplikace o REST rozhran´ı a napˇr´ıklad zpracov´an´ı nov´eho poˇzadavku je potˇreba pouze rozˇs´ıˇrit jiˇz pˇripraven´e abstraktn´ı tˇr´ıdy a implementovat konkr´etn´ı metody pro zpracov´an´ı poˇzadavku.
Na stranˇe serveru nebyl vyuˇzit Entity framework, ale vytvoˇrena vlastn´ı vrstva mapuj´ıc´ı data z datab´aze do podoby pˇr´ısluˇsn´ych objekt˚u. Veˇsker´e pr´ace s daty jsou prov´adˇeny pro zaruˇcen´ı konzistentnosti dat pomoc´ı transakc´ı.
Obr´azek 12: UML sch´ema tˇr´ıd pro zpracov´an´ı synchronizaˇcn´ıho poˇzadavku
4.2 Klient
Tato kapitola popisuje implementaci klientsk´e ˇc´asti aplikace a uv´ad´ı hlavn´ı prvky implementaˇcn´ıch rozd´ıl˚u mezi v´yvojem desktopov´e a mobiln´ı klientsk´e aplikace.
C´ılem pr´ace bylo implementovat klientskou ˇc´ast prim´arnˇe pro platformu An- droid [6]. Pro moˇznost efektivnˇejˇs´ıho ladˇen´ı aplikace a pˇr´ıstupu do datab´aze (in- tern´ıho v r´amci firmy), se uk´azalo nejvhodnˇejˇs´ım ˇreˇsen´ım vytvoˇrit nejprve deskto- povou klientskou aplikaci v jazyce Java s vlastn´ı MySQL datab´az´ı. Tato klientsk´a ˇ
c´ast slouˇz´ı pˇredevˇs´ım pro testov´an´ı komunikace a pro demonstraˇcn´ı ´uˇcely v r´amci in- tern´ıho vyuˇz´ıv´an´ı aplikace a byla vytvoˇrena nad r´amec p˚uvodn´ıho zad´an´ı pr´ace. Aˇz po schv´alen´ı poˇzadovan´e implementace a funkˇcnosti desktopov´e aplikace byla vyv´ıjena klientsk´a mobiln´ı aplikace pro platformu Android.
Klientsk´a aplikace byla od poˇc´atku navrˇzena jako jednouˇzivatelsk´a s intuitivn´ım ovl´ad´an´ım. D˚uvodem byl pˇredevˇs´ım pˇredpoklad pr´ace s mobiln´ım zaˇr´ızen´ım, kter´e je vlastnˇeno jednou osobou.
4.2.1 Bezpeˇcnost intern´ıch dat
U platformy Android byl zadavatelem vznesen poˇzadavek na zabezpeˇcen´ı lok´aln´ıch dat v mobiln´ım zaˇr´ızen´ı. Platforma Android nab´ız´ı jako intern´ı ´uloˇziˇstˇe neza- bezpeˇcenou SQLite datab´azi. Pˇr´ı ztr´atˇe mobiln´ıho zaˇr´ızen´ı nebo instalaci ˇskodliv´e aplikace (napˇr´ıklad z internetu) je bezpeˇcnostn´ım probl´emem moˇznost z´ıskat neza- bezpeˇcen´a data z intern´ı SQLite datab´aze. Z tohoto d˚uvodu bylo implementov´ano zabezpeˇcen´ı datab´aze, kterou zprostˇredkov´av´a knihovna SQLCipher [25].
Snahou v´yvoj´aˇr˚u t´eto knihovny bylo zv´yˇsen´ı bezpeˇcnosti a soukrom´ı sv´ych uˇzivatel˚u. SQLCipher je rozˇs´ıˇren´ı klasick´e SQLite knihovny, kter´e poskytuje 256-bitov´e AES ˇsifrov´an´ı. Nespornou v´yhodou t´eto knihovny je shodn´e API, kter´e poskytuje pro pˇr´ıstup k datab´azi jako klasick´e SQLite.
Bˇehem v´yvoje aplikace se nejprve pracovalo s nezabezpeˇcenou datab´az´ı. Po n´avrhu datab´aze (obr´azek 7) a otestov´an´ı korektnosti n´avrhu, kter´e probˇehlo na dˇr´ıve vy- tvoˇren´e desktopov´e aplikaci, bylo nutn´e doimplementovat knihovnu SQLCipher.
Pˇri rozˇs´ıˇren´ı projektu o zabezpeˇcen´ı lok´aln´ıch dat u mobiln´ıho klienta byl vyuˇzit postup spoleˇcnosti Zatetic, kter´y popisuje integraci SQLite knihovny do aplikace pro Android [26]. Prok´azalo se, ˇze v´yvoj´aˇri skuteˇcnˇe vytvoˇrili shodn´e rozhran´ı, kter´e po- skytovala p˚uvodn´ı SQLite knihovna. T´emˇeˇr jedin´ym rozd´ılem je nutnost zadat heslo pˇri pr´aci s datab´az´ı a pˇri startu aplikace nahr´at do pamˇeti potˇrebn´e knihovny rea- lizuj´ıc´ı ˇsifrov´an´ı a deˇsifrov´an´ı dat. Implementace zabezpeˇcen´ı ovˇsem pˇrinesla n´ar˚ust velikosti v´ysledn´eho apk instalaˇcn´ıho souboru z p˚uvodn´ıch 1,1MB na 5,1MB. D´ale jsou pˇri prvn´ım spuˇstˇen´ı aplikace rozbaleny na disk potˇrebn´e knihovny pro ˇsifrov´an´ı.
V´ysledn´a aplikace t´ım zab´ır´a po instalaci a spuˇstˇen´ı aˇz 15MB. Proto je umoˇznˇen jej´ı
pˇresun na SD kartu mobiln´ıho zaˇr´ızen´ı (v pˇr´ıpadˇe podpory verze syst´emu Android).
SD karty v dneˇsn´ı dobˇe disponuj´ı velikost´ı pamˇeti i nˇekolik des´ıtek GB.
4.2.2 Komunikace
Obˇe klientsk´e aplikace implementuj´ı komunikaci pˇres REST rozhran´ı. Komunikaˇcn´ı model z˚ust´av´a u obou aplikac´ı stejn´y, ovˇsem konkr´etn´ı implementace se v nˇekter´ych ˇ
c´astech liˇs´ı. U desktopov´e ˇc´asti je komunikace implementov´ana ve v´ıce tˇr´ıd´ach a me- tod´ach. ´Uˇcelem tohoto postupu je snadn´a moˇznost modifikace zp˚usobu odes´ıl´an´ı dat, pˇr´ıjmu dat a zmˇeny potˇrebn´ych parametr˚u pro potˇreby ladˇen´ı a testov´an´ı. V´yvoj ko- munikaˇcn´ıho rozhran´ı mobiln´ı aplikace byl realizov´an jiˇz oproti otestovan´emu rozhran´ı implementovan´eho serveru. Proto bylo moˇzn´e navrhnout a implementovat obecnˇejˇs´ı rozhran´ı pro vz´ajemnou komunikaci neˇz u desktopov´eho klienta. Nebylo zde nutn´e kontrolovat pˇrijat´a data ze serveru.
Desktopov´a klientsk´a ˇc´ast vyuˇz´ıv´a Jersey framework [17] pro implementaci REST komunikace se serverem. Tento n´astroj v´yvoj´aˇr˚um v´yraznˇe usnadˇnuje implementaci komunikace, odesl´an´ı konkr´etn´ıch objekt˚u a z´aroveˇn zpˇetn´e mapov´an´ı pˇr´ıchoz´ıch dat na pˇr´ısluˇsn´e objekty. Dalˇs´ı v´yhodou je pˇr´ım´a podpora a vyuˇzit´ı Jersey frameworku tak´e na stranˇe serveru. To umoˇznilo pouˇz´ıt shodn´e API na obou komunikaˇcn´ıch stran´ach.
V pr˚ubˇehu v´yvoje se projevil i drobn´y nedostatek Jersey frameworku. Jersey framework pˇri vytv´aˇren´ı komunikaˇcn´ıho objektu ve form´atu JSON chybnˇe mapuje jednoprvkov´e pole, kter´e pˇrev´ad´ı na klasick´y atribut objektu. Pˇrenos dat je prove- den korektnˇe, avˇsak pˇri zpˇetn´em sloˇzen´ı objektu je vr´acena v nˇekter´ych pˇr´ıpadech v´yjimka. Jersey metoda oˇcek´av´a podle pˇredpisu tˇr´ıdy atribut pole (uvozen´y v hra- nat´ych z´avork´ach) a z´ısk´a pod t´ımto jm´enem pouze jednoprvkov´y atribut (uvozen´y v klasick´ych z´avork´ach). Tento probl´em byl vyˇreˇsen vyuˇzit´ım knihovny Jackson Ob- ject Mapper [1]. Jedn´a se o ˇc´ast frameworku pro pr´aci s JSON objekty, kter´y korektnˇe pˇrev´ad´ı Java objekty do form´atu JSON a zpˇet.
Souˇc´ast´ı kouminkace za ´uˇcelem synchronizace nejsou pouze kompletn´ı objekty (´ukol, proces). Pˇri odesl´an´ı poˇzadavku na synchronizaci klient pˇred´av´a tak´e infor- mace o tom, jak´a data vlastn´ı ve sv´e datab´azi. V tuto chv´ıli nen´ı nutn´e pˇren´aˇset kompletn´ı objekt, ale staˇc´ı pouze identifik´ator slouˇz´ıc´ı pro synchronizaˇcn´ı proces na serveru. V kontr´etn´ım pˇr´ıpadˇe pro synchronizaci ´ukol˚u klient odes´ıl´a ve sv´e zpr´avˇe pouze taskID, activitiURL a HASH. Pr˚umˇern´a znakov´a d´elka objektu ´ukol ve form´atu JSON se pohybuje mezi 600–800 znak˚u (z´aleˇz´ı na d´elce popisu, URL atd). Synchro- nizaˇcn´ı REST poˇzadavek (obsahuj´ıc´ı taskID, activitiURL a HASH ) m´a v pr˚umˇern´em pˇr´ıpadˇe d´elku pouze 150 znak˚u, coˇz je maxim´alnˇe 1/4 p˚uvodn´ıho objektu. T´ım je minimalizov´an datov´y pˇrenos a zv´yˇsena rychlost aplikace.
Sch´ema 13 popisuje obecn´e vytvoˇren´ı poˇzadavku na synchronizaci, odesl´an´ı a pˇr´ıjem na stranˇe serveru. Klient nejprve sloˇz´ı poˇzadavek z dat uloˇzen´ych v da-
