Prvn´ı logickou ˇc´ast´ı t´eto komponenty je import dat z extern´ıho syst´emu do plat-formy. Pro tyto ´uˇcely je nad´ale za onen extern´ı syst´em povaˇzov´an syst´em RIS.
V tento moment je vhodn´e rozdˇelit import do dvou pohled˚u.
Prvn´ım pohledem je syst´em, kter´y data bude pˇrij´ımat, tedy platforma. Existuj´ı dva smyslupln´e zp˚usoby, jak pˇrij´ıman´a data zpracov´avat a uchov´avat. Tyto z´avis´ı na modelech platformy, kter´e byly uvedeny v kapitole 3.3. V pˇr´ıpadˇe platformy zaloˇzen´e na centr´aln´ım ´uloˇziˇsti dat (viz obr´azek 3.1) by jej´ım centr´aln´ım prvkem byl datab´azov´y server. Mˇelo by tak smysl prov´adˇet import v˚uˇci platformˇe pˇr´ımo do jej´ı datab´aze. Coˇz samo o sobˇe nelze povaˇzovat za ˇspatnou techniku. A vzhledem k tomu, ˇze ostatn´ı komponenty v tomto modelu s datab´az´ı spolupracuj´ı, je to jeden z praktick´ych zp˚usob˚u, jak zajistit dostupnost importovan´ych dat pro ostatn´ı kom-ponenty a jak import prov´est. Platforma je navrˇzena podle modelu s aplikaˇcn´ım serverem (viz obr´azek 3.2), kter´y obsahuje jako centr´aln´ı prvek aplikaˇcn´ı server.
Ten je prostˇredn´ıkem mezi datab´az´ı, jako datov´ym ´uloˇziˇstˇem, a ostatn´ımi kompo-nentami. Pˇrestoˇze i v tomto pˇr´ıpadˇe by pˇr´ım´emu proveden´ı importu do datab´aze nic nebr´anilo, jedn´a se sp´ıˇse o teoretickou moˇznost. T´ım by totiˇz byla ztracena jist´a m´ıra abstrakce, kterou aplikaˇcn´ı server pro ostatn´ı komponenty nad datab´az´ı vytv´aˇr´ı pomoc´ı sv´eho API.
Druh´ym pohledem je zcela analogicky syst´em, kter´y data pro import poskytuje.
Nebo-li ten, ze kter´eho se data pˇrev´adˇej´ı do platformy. V tomto pˇr´ıpadˇe tedy RIS.
Zde je situace o pozn´an´ı komplikovanˇejˇs´ı. To je ze sv´e podstaty zapˇr´ıˇcinˇeno jeho komerˇcn´ı povahou. Pro zaˇc´atek je moˇzn´e konstatovat, ˇze platforma je vybudov´ana tak, aby ji mohli vyuˇz´ıt i jeho tv˚urci. T´ım je myˇslena moˇznost implementace API aplikaˇcn´ıho serveru platformy v´yvoj´aˇri syst´emu RIS. Samozˇrejmˇe v pˇr´ıpadˇe jejich v˚ule. Z uveden´eho je vˇsak opˇet patrn´a z´avislost na tv˚urci syst´emu RIS. Nicm´enˇe za pomoci konzultac´ı u konzultanta byla zjiˇstˇena jeˇstˇe jin´a moˇznost, jak´ym zp˚usobem je moˇzn´e import prov´est. Konzultant bˇeˇznˇe pracuje i se soubory form´atu CSV, kde jsou specificky uloˇzeny atributy dan´eho schematu. Data tˇechto soubor˚u jsou pˇreb´ır´ana ze syst´emu RIS a obsahuj´ı potˇrebn´e parametry, kter´e jsou poˇzadov´any i platformou.
V tomto okamˇziku je vhodn´e zm´ınit, ˇze tento CSV soubor nereprezentuje intern´ı
´
uloˇziˇstˇe dat v syst´emu RIS, ale jedn´a se o jak´ysi pˇrenosov´y prostˇredek s vybran´ym obsahem. Je tedy patrn´e, ˇze tento zp˚usob je v dobˇe tvorby t´eto komponenty plat-formy t´ım jedin´ym dostupn´ym, a proto je pouˇzit k proveden´ı importu dat. Jedn´a se tak o zp˚usob importu soubor – API.
N´asleduj´ıc´ı obr´azek 7.1 pˇribliˇzuje jak´ym zp˚usobem je program pro import dat
navrˇzen. Pro potˇreby autorizace a z´ısk´an´ı pˇr´ıstupov´eho k´odu komunikuje s posky-tovatelem identit. Data jsou pak pos´ıl´ana na aplikaˇcn´ı server prostˇrednictv´ım jeho API. D´ale je zde patrn´a skuteˇcnost jak´ym zp˚usobem form´atovan´a data dok´aˇze kom-ponenta zpracov´avat. T´ım jsou pˇrenosov´e form´aty CSV a XML, kter´e jsou pops´any n´ıˇze v n´asleduj´ıc´ı kapitole. Tak´e je zde zn´azornˇena moˇznost pˇr´ım´eho napojen´ı API komponenty na extern´ı syst´em. Avˇsak toto je zde pouze demonstrov´ano. Vzhledem k pˇredchoz´ımu odstavci to nen´ı implementov´ano.
Obr´azek 7.1: Import – n´avrh komponenty
7.2.1 Pˇ red´ avac´ı form´ at
Pouˇzit´ı pˇred´avac´ıho form´atu je zvoleno z d˚uvodu uveden´ych v pˇredchoz´ı kapitole.
Principi´alnˇe by nebyl potˇreba v pˇr´ıpadˇe pˇr´ım´e implementace API platformy na stranˇe tv˚urc˚u jednotliv´ych syst´em˚u. Na druhou stranu je to ale vhodn´y prostˇredn´ık pro popis dan´eho schematu.
CSV
Tento form´at je pˇrevzat od konzultanta. Jeho struktura je ovlivnˇena samotn´ym zp˚usobem form´atov´an´ı CSV, coˇz jsou jednotliv´e hodnoty oddˇelen´e stˇredn´ıkem. Prvn´ı
ˇr´adek obsahuje hlaviˇcku schematu. V n´ı jsou uvedeny napˇr. jeho jm´eno ˇci popis.
N´asleduj´ı dvˇe sekce. Prvn´ı z nich popisuje uzlov´e body, kde kaˇzd´y uzlov´y bod je reprezentov´an jedn´ım ˇr´adek. V nˇem jsou uloˇzeny jeho atributy napˇr. popis bodu, jeho identifik´ator v r´amci tohoto souboru, souˇradnice na schematick´e mapˇe a hod-noty potˇrebn´e pro v´ypoˇcty. Druh´a sekce uchov´av´a ´useky. Jej´ı struktura je podobn´a.
Obsahuje napˇr. popis ´useku, jeho identifik´ator v r´amci tohoto souboru a dalˇs´ı hod-noty vztaˇzen´e k v´ypoˇct˚um. Tento form´at je plnˇe pˇrevoditeln´y na n´asleduj´ıc´ı XML form´at.
XML
Tento form´at byl vytvoˇren pro potˇreby platformy jiˇz v r´amci magistersk´eho projektu (viz [1]). Vych´az´ı z jejich potˇreb. Je tak´e plnˇe pˇrevoditeln´y na pˇredchoz´ı pˇred´avac´ı form´at CSV.
7.2.2 Implementace
Na z´akladˇe poˇzadavk˚u na funkˇcnost z kapitoly 3.1 byl pro tvorbu t´eto komponenty zvolen jazyk Java. V r´amci implementace je pouˇzit konektor na aplikaˇcn´ı server, kter´y byl bl´ıˇze pops´an v kapitole 5.7.
Pro autentizaci tato komponenta pouˇz´ıv´a autorizaˇcn´ı proces povˇeˇren´ı uˇzivatele.
To je z toho d˚uvodu, ˇze v tomto pˇr´ıpadˇe nelze vyuˇz´ıt standardn´ı proces autorizaˇcn´ı k´od, protoˇze tato komponenta je navrˇzena pro provoz v pˇr´ıkazov´em ˇr´adku. T´ım p´adem neumoˇzˇnuje prov´est manu´aln´ı autorizaci, kter´a prob´ıh´a ve webov´em prostˇred´ı poskytovatele identit. Pr´avˇe i z tohoto d˚uvodu se zde pro pˇr´ıstup pouˇz´ıvaj´ı ´udaje
´
uˇcelov´eho pˇr´ıstupov´eho ´uˇctu. Ten m˚uˇze b´yt zˇr´ızen pouze pro potˇreby t´eto kompo-nenty, je pˇriˇrazen k identitˇe uˇzivatele, kter´y jej vytvoˇril, ale z´aroveˇn nem˚uˇze doj´ıt k ovlivnˇen´ı ˇci prozrazen´ı ´udaj˚u jeho hlavn´ıho pˇr´ıstupov´eho ´uˇctu.
Tato komponenta je navrˇzena pro spuˇstˇen´ı v termin´alu. Jej´ımi parametry je volba pˇred´avac´ıho form´atu a n´aslednˇe samotn´y soubor pˇripraven´y k importu. Po je-jich zad´an´ı komponenta provede naˇcten´ı souboru, vytvoˇren´ı prvk˚u prostˇrednictv´ım objekt˚u dan´eho schematu. N´asleduje vytvoˇren´ı nov´eho schematu na aplikaˇcn´ım serveru, opr´avnˇen´ı pro aktu´aln´ıho uˇzivatele a d´ale jsou postupnˇe odes´ıl´any do novˇe vytvoˇren´eho schematu pˇripraven´e prvky. Nejprve se odes´ılaj´ı mapov´e body, pot´e uzlov´e body a z´avˇerem ´useky. Toto poˇrad´ı je urˇceno prostˇrednictv´ım vazeb mezi objekty. Nelze totiˇz napˇr. vytvoˇrit ´usek, jehoˇz parametrem jsou uzlov´e body, kter´e jeˇstˇe nejsou na aplikaˇcn´ım serveru vytvoˇreny.
7.2.3 Testov´ an´ı
Testov´an´ı t´eto komponenty prob´ıhalo za pomoc´ı n´asleduj´ıc´ıch technik. Po vytvoˇren´ı dan´eho k´odu byl k´od testov´an program´atorem. Vzhledem k faktu, ˇze se zde vyuˇz´ıval i API Connector z kapitoly 5.7, kter´y byl samostatnˇe testov´an, tak tato ˇc´ast nebyla zvl´aˇstˇe testov´ana. Nad celou komponentou pak probˇehlo syst´emov´e testov´an´ı, jenˇz
mˇelo za ´ukol ovˇeˇrit jej´ı funkˇcnost. To bylo provedeno autorem. T´ımto testov´an´ım komponenta proˇsla.
7.2.4 Re´ aln´ e s´ıtˇ e
Po dohodˇe vydal konzultant souhlas s proveden´ım importu schemat NN s´ıtˇe v obci ˇZelkovice a ˇc´asti VN s´ıtˇe ve mˇestˇe Dobruˇsce za ´uˇcelem ovˇeˇren´ı funkcionality plat-formy. Schema ˇZelkovice bylo importov´ano z pˇred´avac´ıho form´atu CSV. Pro druh´e schema Dobruˇska byl vytvoˇren pˇred´avac´ı form´at XML, kter´y byl importov´an. Tato zmˇena form´at˚u probˇehla za ´uˇcelem ovˇeˇren´ı funkˇcnosti XML form´atu. Oba im-porty probˇehly ´uspˇeˇsnˇe. N´aslednˇe byla prostˇrednictv´ım editoru provedena vizu´aln´ı kontrola ´uplnosti schemat. V pˇr´ıloze E je uvedena uk´azka importovan´e s´ıtˇe obce ˇZelkovice v prostˇred´ı editoru.