Hankelepingu 1.9-8/23-419-1
eritingimused
29.06.2023
Majandus- ja Kommunikatsiooniministeerium, registrikood 70003158, asukoht Suur-
Ameerika 1, Tallinn 10122, mida esindab Majandus- ja Kommunikatsiooniministeeriumi
hankekorra alusel kantsler Ahti Kuningas (edaspidi Tellija),
ja
Tietoevry Estonia AS, registrikood 10137025, asukoht A. H. Tammsaare tee 47, Tallinn
11316, mida esindab volikirja alusel Neil Koiksaar (edaspidi Täitja),
keda edaspidi nimetatakse üheskoos ka pooled ja eraldi pool,
sõlmivad käesoleva teenuse osutamise lepingu (edaspidi leping) alljärgnevas:
1. Üldsätted
1.1. Lepingu moodustavad eri- ja üldtingimused koos lisadega kui konkreetsest lepingu
sättest ei tulene teisiti.
1.2. Lepingu dokumentide prioriteetsus on järgmine: eritingimused (I), lepingu lisad (II) ja
üldtingimused (III). Vastuolude korral lepingu dokumentide vahel prevaleerib
prioriteetsem dokument.
2. Lepingu ese, alus ja tähtaeg
2.1. Lepingu esemeks on ehitusregistri tarkvara majutuse teenus (edaspidi teenus), mida
Täitja kohustub osutama vastavalt lepingus ja lepingu Lisades 2 ja 3 sätestatud
tingimustele.
2.2. Leping sõlmitakse Tellija korraldatud riigihanke „Ehitisregistri majutus 2“ (viitenumber
265190) tulemusena ning vastavalt riigihanke alusdokumentidele ning Täitja edukaks
tunnistatud pakkumusele.
2.3. Leping kehtib alates lepingu allkirjastamisest kuni 31.03.2024. Täitja asub teenust
osutama alates 11.07.2023.
2.4. Lepingu ennetähtaegsel lõpetamisel peavad pooled vähemalt 30 kalendripäeva jooksul
teavitama teist poolt.
3. Tasu suurus, väljamaksmise tähtaeg ja kord
3.1. Lepingu kogumaksumus on kuni 45000 eurot ilma käibemaksuta.
3.2. Tellija tasub Täitjale ehitisregistri majutusteenuse eest igakuiste perioodiliste maksetena
summas 5167 eurot (käibemaksuga 6200,20 eurot) pärast Täitja poolt arve esitamist
kusjuures üleandmise-vastuvõtmise akti ei koostata.
3.3. Kõik majutusteenuse osutamiseks vajaliku majutuskeskkonna esmase ülesseadmise
kulud kannab Täitja.
4. Poolte volitatud esindajad
4.1. Tellija volitatud esindaja lepingu tingimuste täitmisel, täitmise kontrollimisel on Verner
Eiber, telefon +372 625 6496, e-post
[email protected].
4.2. Täitja volitatud esindaja lepingu tingimuste täitmisel ja täitmise kontrollimisel on Eero
Tammelaan, telefon +372 504 2935 , e-post
[email protected].
5. Lepingu lisad
5.1. Lepingu allakirjutamisel on lepingule lisatud:
5.1.1. Lisa 1. Riigihanke alusdokumendid (leitavad riigihangete registris);
5.1.2. Lisa 2. Majutuseteenuse osutamise tingimused;
5.1.3. Lisa 3. Tehniline lahendus ja arhitektuur;
5.1.4. Lisa 4. Täitja pakkumus (leitav riigihangete registris).
6. Muud sätted
6.1. Täitja kinnitab, et on üldtingimustega tutvunud elektroonselt Majandus- ja
Kommunikatsiooniministeeriumi veebis aadressil:
https://mkm.ee/ministeerium-uudised-ja-kontakt/ministeerium-ja-ministrid/hanketeated
6.2. Pooltel on võimalik leping ennetähtaegselt lõpetada ühekuulise etteteatamise tähtajaga.
6.3. Kumbki Pool võib Lepingu rikkumise tõttu nõuda teiselt Poolelt otsese dokumenteeritud
kahju hüvitamist. Poolte koguvastutus ei tohi ületada summat, mis vastab viiekümnele
protsendile (50%) lepingu mahust. Koguvastutus hõlmab kõiki leppetrahve,
teenusekrediiti, hinnaalandusi või samalaadseid kindlaksmääratud hüvitisi. Lepingust
tulenevad leppetrahvid on piiratud maksimaalselt 25% lepingu mahust.
6.4. Vastutuse piirangud ei kehti kahjutasule, mis on põhjustatud lepinguosalise tahtlikust
üleastumisest või raskest hooletusest, intellektuaalomandi õiguste rikkumisega seotud
nõuete suhtes ja kahjule, mis on põhjustatud konfidentsiaalsuskohustuse rikkumisest.
Lepingupooled ei vastuta teise lepingupoole ees kaudsete kulude või kahjude eest,
sealhulgas, kuid mitte ainult: saamata jäänud kasum, saamata jäänud tulu, kolmanda
osapoole kahju (sealhulgas Tellija kliendid) või mis tahes muu põhjuslik kahjum või
kahju.
6.5. Tellijal on kohustus minimeerida oma kulusid ja kahjusid. Täitja ei vastuta kulude või
kahjude eest, mida Tellija oleks mõistlikult saanud vältida, välja arvatud juhul, kui see
on hõlmatud kohaldatava õigusega.
6.6. Täitja on teadlik, et leping on avalik.
6.7. Leping allkirjastatakse digitaalselt.
Tellija Täitja
/allkirjastatakse digitaalselt/ /allkirjastatakse digitaalselt/
Hankelepingu lisa 2
Ehitusregistri majutusteenuse osutamise tingimused.
1. Ehitisregister (edaspidi EHR) koosneb järgnevatest komponentidest:
1.1. EHRi toodangu keskkond;
1.2. kolm testkeskkonda (test, test2 ja test3)
EHRi majutuskeskkonnas kasutusel oleva tehnilise lahenduse ja arhitektuuri kirjeldus on
toodud Lisas 1. Igasse keskkonda on installeeritud EHR tarkvara koos võrgurajatiste
mooduliga (VRM)
2. Andmesideühendus
Majutuskeskkonda peab olema tagatud internetiühendus kiirusega kuni 100 Mbps.
Andmesideühendus peab olema kaitstud tulemüüriga paketifiltrite tasandil. Tulemüüri
pääsureeglid määratakse koos Tellijaga ning need fikseeritakse eraldi aktiga.
Tuleb tagada infosüsteemi andmekaitse ning EHRi andmetele sanktsioneerimata ligipääsu
tõkestamine ja süsteemi informatsiooni lekke ärahoidmine kolmandatele isikutele.
2.1. Andmeedastustunnelid
2.1.1. Tuleb luua turvatud andmeedastuskanal EHRi majutuskeskkonna ja MKMi sisevõrgu
vahel.
2.1.2. Tuleb luua turvatud andmeedastuskanal juurdepääsuks EHR testkeskkondadele, mille
abil EHR arendajad pääsevad ligi EHR testikeskkonna serveritele ja rakendustele.
3. Käideldavus
Tuleb tagada EHR käideldavus järgmiste koormusnäitajate juures:
3.1. samaaegsete kasutajate arv kuni 7000;
3.2. rakenduse päringute arv päevas on kuni 300 000 päringut;
3.4. tööajal keskmiselt 2 päringut sekundis;
3.5. tipptundidel (8:00-17:00 tööpäevadel) kuni 10 päringut sekundis.
4. Andmete varundamine
Varukoopiate tegemisel tehakse 1 kord nädalas koopia kõikidest andmetest (full backup)
ning 6 korda nädala varukoopia andmete muudatustest (incremental backup). Varukoopiad
teostatakse ilma EHR rakendusi ja andmebaase seiskamata. Varundatud andmeid tuleb
hoida alates varundamishetkest 2 kuu jooksul.
5. Arenduste sisseviimine
EHR arendajate poolt teostatud arenduste sisseviimine testkeskkondadesse teostatakse
automaattarne liiniga. Toodangu keskkonda tuleb üle antud rakendus paigaldada mitte
hiljem kui ühe kahe tööpäeva jooksul alates tarnepaketi üleandmisest. Toodangu keskkonda
tuleb teha paigaldusi väljaspool tööaega. Peale paigaldamist tuleb läbi viia paigaldatud
rakenduste suitsutest, millega kontrollitakse, et kõik rakendused, x-tee päringud ja
andmebaas töötavad ning EHR esileht avaneb.
Teenuseosutaja võimaldab EHR testikeskkondadesse rakenduste ja andmebaasi
automaattarnete teostamist. Tellija keskkonnas on kasutusel tarkvaralised vahendid
(GitLab, Maven, Liquibase). Automaattarne juhul teostab suitsutesti tarne läbiviija ehk
Tellija poolt volitused saanud arendaja.
6. Teenuse seisakud, häired ja profülaktilised tööd.
Teenuse seisakuks loetakse olukorda, kus EHRi tarkvara ei ole käideldav. Teenuse häireks
loetakse olukorda, kus EHRi tarkvara on küll käideldav, kuid EHRi tarkvara kasutamisel
esineb veateateid, EHRi tarkvara kasutamine on normaalsest aeglasem või muul moel
häiritud.
Teenuste maksimaalne taasteaeg teenuse seisaku puhul on kuni 24 tundi.
Teenuste taasteaeg teenuse häire puhul on normaaltööajal 2 tundi ning töövälisel ajal 4
tundi.
EHRi tarkvara seisakute puhul profülaktiliste tööde teostamiseks informeeritakse sellest
Tellijat ette vähemalt 48 (nelikümmend kaheksa) tundi. Profülaktilisi töid teostatakse
väljaspool normaaltööaega. Profülaktilisi töid läbi viies võib teenuse seisaku kestvus olla
maksimaalselt kuni 2 tundi. Teenuste seisakute maksimaalne kogukestvus aastas võib olla
kuni 48 tundi.
7. Majutusteenuse osutamisel peab teenuseosutaja lisaks ülalmainitule täitma järgnevad
ülesanded:
7.1. EHRi tarkvara terviklikkuse ja kasutajaõiguste kontroll ning logifailide kontrollimine;
7.2. kasutatud andmeruumi muutuse ja serverite koormustrendide analüüs ning igakuine
statistiline aruandluse esitamine;
7.3. andmebaaside ja rakenduste regulaarne koormuse logide jälgimine ning vajadusel
reageerimine sündmustele, mille tõttu võiks teenuse osutamine seiskuda;
7.4. kasutajate lisamine, õiguste muutmine, kontode kinnipanek (testikeskkondadele ja
andmebaasidele ning andmeühenduse lahendustele juurdepääsuks, x-tee päringute
kasutamiseks);
7.5. üksikute failide või kogu süsteemi taastamine varukoopiast;
7.6. kasutusel oleva majutuskeskkonna ja selle muudatuste dokumenteerimine. Hiljemalt ühe
nädala jooksul alates muudatusest, tuleb tellijale esitada värskendatud dokumentatsioon,
milles on kajastatud kõik majutuskeskkonnas kasutatavad riistvara ja tarkvara
komponendid;
7.7. kolmandate osapoolte nõustamine ja tehnilise info andmine tarkvara arenduse küsimustes;
7.8. kord kuus Tellijale statistiliste aruannet koostamine EHRi andmebaaside mahust,
salvestatud dokumentide ja teostatud päringute arvust, kasutajate arvust jms, mis
kajastavad EHR käitlemist ja kasutatavust;
7.9. Tellija nõudmisel tegema EHR andmebaasidest täiskoopiaid (dumpe) ja laadima need
Tellija poolt näidatud asukohta. Max dumpide arv aastas võib olla 12;
7.10. Tellija nõudmisel või vajaduse ilmnemisel teostama alustarkvarade versiooniuuendusi.
8. Andmebaasitarkvara Oracle Database litsentsid hangib Tellija. EHRi ISKE auditite
läbiviimine ja rahastamine ning EHRi lähtekoodi hoidmine ja versioonihaldus ei ole antud
lepingu osa.
9. EHR-i majutusteenuse osutamisel kasutatakse Tellija veebipõhist probleemide halduse
keskkonda JIRA.
Majandus- ja Kommunikatsiooniministeerium AS Webmedia / AS Datel
Riikliku ehitisregistri e-teenuste mooduli
loomine
Tehniline lahendus ja arhitektuur
2011
Andmed dokumendi muutmise kohta
Kuupäev Versioon Muudatuse kirjeldus Autor
20.05.2011 1.0 Esialgne versioon AS Webmedia / AS Datel
09.06.2011 2.0 Esialgne versioon AS Webmedia / AS Datel
23.03.2018 3.0 Täiendused Ülo Puskar
Dokumendi kinnitused
Kuupäev Kinnitaja Allkiri
2
1. Sissejuhatus (Ü.Puskar 20.04.2023)
Käesolev dokument koostati enne arendusprojekti algust ja kirjeldab mõtteid, mis olid arendajal
enne, kui EHR uue rakenduse arendus algas. Dokumendis kirjeldatud arhitektuur on tänaseks suures
osas realiseeritud ja kasutusel. Dokumendis kirjeldatud komponente ja raamistikke uuendati 2017 ja
uuendatud versioonide viited on lisatud käesolevasse dokumenti. Dokumendis kirjeldatud
„Olemasolev“ rakendus viitab EHR „vanale“ rakendusele, mis oli kasutusel 2003 – 2014. Tänaseks on
„vana“ rakendus kasutusel arhiivina ja EHR töötab nn „uue“ rakendusega (dokumendis „e-teenuste
moodul“), mille arhitektuuri käesolev dokument kirjeldab. Arendusprojekti käigus otsustati teha „e-
teenuste moodulist“ uus EHR ja seetõttu loodi andmebaasi uus skeemi, kuhu kanti andmed „vana“
EHR andmeskeemist. Ülekandmisel andmeid konverteeriti ja seetõttu erineb uue ja vana
andmeskeemi andmetes erisusi ning e-teenuste skeemi viidi üle ka kõik uue EHR tööks vajalikud baasi
protseduurid. EHR „uue“ rakenduse alustarkvara täpsed nimetused ja kasutusel versioonid on
toodud eraldi seisvas dokumendis „EHR tarkvara kirjeldus“.
Olulised muudatused majutuskeskkonnas olevates objektides:
Lõppenud on EHR Java rakenduse (x-tee alamsüsteem ehr) poolt osutatavate x-tee teenuste
osutamine. Säilinud on x-tee teenuste kasutamine läbi ehr alamsüsteemi.
Suletud on Geoteenuste rakendus
Autentimine ja autoriseerimine toimub läbi Riigipilves asuva EHR Keycloak teenuse
Majutatav Java rakendus on integreeritud Riigipilves asuva EHR UI teenusega
2. Tehniline lahendus ja arhitektuur
2.1. Olemasolev rakendus
Toodud on majutatava rakenduse kirjeldus.
3
class e-teenus
EHR register e-teenused
Andmebaas
EHR skeem e-teenused skeem
Baasipaketid
Tabelid
Tabelid
class Välised süsteemid
E-Notar Eesti.ee
«Autentimine»
«execution environ...
E-Teenused rakendus
«teenused»
AAR
X-tee teenuseid «Ametniku tuvastamine»
kasutav ad
«teenused»
rakendused
«teenused»
ADS/Maa-ameti
teenused
«dokument»
«päring» «päring» «päring»
KOVMEN
X-Tee Registrid
Kinnistusregister Rahv astikuregister Äriregister
...
4
E-Teenused rakendus ja seosed erinevate väliste süsteemidega. Liideste kohta täpsemalt on kirjutatud
üldanalüüsis.
2.1.1. Tehnoloogiline arhitektuur
Rakendus on planeeritud käivitada vabavaralisel Apache Tomcat (http://tomcat.apache.org/)
rakendus-serveril ning implementeerimiseks kasutatakse Java versiooni Sun JDK 6.
Rakendus realiseeritakse standardse kihilise J2EE rakendusena:
Ressursikiht
Integratsioonikiht
Teenuste kiht
Esitluskiht
Rakendus
Veebikonteiner
SPRING Framework
Presentatsiooni kiht
Apache Wicket/Spring MVC
Teenuste kiht
Äriteenuste liideste ning realisatsiooni kiht
DAO liideste kiht
DAO realisatsiooni kiht
Integratsiooni kiht
Hibernate ORM
Ressursikiht
Andmebaas
X-Tee registrid
Realisatsioon baseerub raamistikul Spring Framework (http://www.springsource.org/).
1.1.1.1 Ressursikiht
Arhitektuuri seisukohalt moodustavad ressursikihi andmebaas (Oracle) ja erinevad kasutatav välised
süsteemid (näiteks erinevad x-tee registrid). Andmebaasi valikul mängis rolli mitu erinevat põhjust. Üks
oluliseimaid põhjuseid on asjaolu, et käesoleva projekti lõppedes peavad tööle jääma kaks rakendust
– loodud e-teenuste moodul ning olemasolev EHR rakendus (ilma e-teenuste raames realiseeritud
funktsionaalsuseta). Olemasolev EHR rakendus toetub olulisel määral andmebaasile – suur osa
5
äriloogika kontrollidest tehakse Oracle PL/SQL protseduurides. Antud protseduuride ümber-tõstmine
PostgreSQL andmebaasi on keeruline. Pakkumises oli välja toodud kaks faasi – praeguse projekti
skoobis olev järk-järguline üleminek ja lõplik arhitektuur, mis otseselt antud projekti skoopi ei kuulu
ning mis nägi kogu rakenduse üleminekut PostgreSQL peale. Kuna olemasolev rakendus peab jääma
tööle kuniks seal olev funktsionaalsus on realiseeritud e-teenustes, siis on käesoleva projekti skoobis
mõistlik kasutada Oracle andmebaasi. Tööde käigus on üheks eesmärgiks äriloogika väljatõstmine
andmebaasist selleks ettenähtud teenuste kihti e-teenused rakenduses, vastavalt sellele, millised
menetlused realiseeritakse.
Teiseks põhjuseks PostgreSQLi kasutusele võtuks oli pakkumuse plaan Projektipank realiseerida
kasutades Alfrescot, mis vajab tööks PostgreSQLi. Kuna üldanalüüsi käigus selgus, et Projektipanga
realiseerimiseks ei ole otseselt vaja Alfrescot kasutusele võtta, siis langes ära ka kohene vajadus üle-
mineku faasis PostgreSQLi kasutuselevõtuks.
Kolmandaks põhjuseks on see, et Maa-amet on peatanud XGISi PostgreSQL suuna edasiarenduse, mis
võib kaugemas tulevikus tekitada tagasilööke XGIS rakenduse (nii kliendi kui serveri poolse)
kasutamisel.
1.1.1.2 Integratsioonikiht
Integratsioon relatsioonilise andmebaasi ja teenuskihi vahel realiseeritakse Hibernate ORM (Object
Relational Mapping) teegi abil. Hibernate realiseerib relatsioonilise andmebaasi olemite
objektorienteeritud esitamise (POJO objektidena) ning pakub olemitega manipuleerimiseks vajalikud
teenused teenuste- ja ressursikihi vahel.
Integratsioonikiht loob tulevaste projektide tarbeks võimekuse paindlikult võimalike välis-tarbijate
jaoks luua x-tee teenuseid, veebiteenuseid (SOAP) või RMI liideseid, mis baseeruvad teenuste kihil.
Ehk siis sama teenust on võimalik tulevikus kasutada erineval viisil.
1.1.1.3 Teenuste kiht
Äriteenuste baasraamistikuna kasutatakse Spring raamistikku.
Teenuste kihi realiseerimisel jälgitakse maksimaalselt SOA (Service Oriented Architecture) printsiipe.
SOA põhise arhitektuuriga süsteemi korral keskendutakse võimalikult hästi defineeritud liideste ning
maksimaalselt sõltumatute teenuste loomisele. Selline lähenemine võimaldab sama teenust kasutada
näiteks nii E-teenuste esitluskihi tarbeks kui ka luua ka süsteemne liides, mida saavad tarbida teised
rakendused. Viisid, kuidas teenuskihti põhimõtteliselt arendada saab, on kirjeldatud
integratsioonikihis (RMI, SOAP, x-tee jne.)
Pakkumises ühe olulise punktina välja toodud ärireeglite mootorist OpenRules on loobutud põhiliselt
tingituna valikutest kasutajaliideses. Üldanalüüsi käigus selgus, et käesoleva projekti üheks
prioriteediks on luua võimalikult lihtne, atraktiivne ja intuitiivselt käsitletav kasutajaliides. See
tähendab aga, et kasutajaliides tuleb koostada n-ö käsitsi võttes arvesse iga erineva vormi omapärasid.
OpenRules ärireegli mootori kõige võimsam omadus on ilma rakenduse koodi muutmata muuta
rakenduse sisemist äriloogikat ja erinevaid andmetele kehtestatavaid kontrolle, millest aga järeldub
kohe, et kasutajaliides tuleb suuremal või vähemal määral dünaamiliselt genereerida, et kajastada
muutusi äriloogikas. Dünaamiliselt genereeritav kasutajaliides ei ole aga kindlasti väga lihtne või
intuitiivne.
6
Teenuste kihis saab eristada järgmisi alamkihte:
DAO (Data Access Object) teenused
Äriteenused
DAO teenuskihi eesmärk on teenustekihis selgepiiriliselt eristada andmemanipulatsiooni otstarbeks
kasutatavad teenused. Need on teenused, mis suhtlevad läbi integratsioonikihis defineeritud ORM
vahendi poolt pakutavate teenuste persistentsete andmekogudega. DAO teenuskihi teenused ei
sisalda reeglina otsest ärifunktsionaalsust ning tüüpilised teenused on päringud ja CRUD-
operatsioonid.
Äriteenuste eesmärk on pakkuda kompleksset teenust. Näiteks menetluse salvestamine, mis võib
sisaldada endas erinevad äriloogilisi kontrolle andmetele, suhtlust väliste andmekogudega ja
väljakutseid erinevatele DAO teenuskihi teenustele.
1.1.1.4 Esitluskiht
Esitluskihi tehnoloogia valikul tuleb arvestada E-teenused mooduli kahe erineva kasutusvõimalusega.
Avalik liides, mille kasutamiseks ei ole vaja rakendusse sisse logida (registripäringud) ning kus kasutaja
peab saama lehekülgi bookmark’ida (näiteks otselink päringutulemustele), ja menetluse liides, mille
kasutamiseks peab kasutaja ennast autentima ja mis peab toetama protsessi-põhist (wizard-stiilis)
andmesisestust. Peamisteks valikuteks on hetkel Apache Wicket (http://wicket.apache.org/) või Spring
MVC. Valik täpsustub pärast kasutajaliidese prototüübi ja menetlus-protsesside täpsustumist.
Lisatud 23.03.2018
Kasutusel on:
1. Java 1.8.121
2. Spring 4.3.7, Spring Security 4.2.2
3. Apache Wicket 6.26.0
1.1.1.5 Toetavad tehnoloogiad
Regulaarselt käivitatavate protsesside juhtimiseks kasutatakse Quartz Scheduler teeki
(http://www.quartz-scheduler.org/).
Erinevate tihti kasutatavate andmete jaoks kasutatakse puhverdamist, mis realiseeritakse EhCache
teegi abil (http://ehcache.org/).
Logimisraamistikuna on kasutusel laialt levinud log4j raamistik (http://logging.apache.org/log4j/).
ID-kaardiga autentimiseks ning dokumentide digiallkirjastamiseks on kasutusel DigiDoc Service.
Lisatud 23.03.2018
7
Kasutusel on DigiDoc4j
2.1.2. Äriloogiline arhitektuur
Läbiv mõtteviis uute arenduste juures on see, et olemasolevat rakendust muudetakse võimalikult
vähe. Olemasoleva registri funktsionaalsus jääb tööle senikaua, kuni võrdväärne funktsionaalsus ei ole
realiseeritud e-teenused rakenduses. Kuidas ja milliste funktsionaalsete gruppide kaupa olemasoleva
funktsionaalsuse „välja lülitamine“ toimub kirjeldatakse detailanalüüsis.
1.1.1.5.1 Andmebaas
Eelpool toodud pildil on näha, et E-Teenused rakendus töötab uue andmebaasi skeemi peal. Sisuliselt
on tegemist aga olemasoleva skeemi laiendusega, mis sisaldab uut funktsionaalsust toetavaid tabeleid
ning muutunud olemasolevaid tabeleid. Kas tegemist on ka reaalselt iseseisva andmebaasi skeemiga
selgub detailanalüüsis ning sõltub sellest, kui suurel määral peab olemasolev andmeskeem muutuma.
Kui tekib uus skeem, siis olemasoleva skeemi objekte tarbitakse läbi sünonüümide.
Andmebaasi muudatusi võivad tingida ka andmekvaliteedi parandamisega tehtavad tegevused, mis
teostatakse sõltumata sellest kas andmebaasi skeem mutub olulisel määral või mitte.
1.1.1.5.2 Rakendus
Äriloogiliselt saab E-Teenused rakenduse mõttes eristada järgmisi mooduleid:
Menetlusmoodul
Päringumoodul
Ruumiandmete menetlusmoodul
Kaardiliides
Statistika moodul
X-tee teenused
Administreerimise moodul
Projektipank
Osa mooduleid on olemas ka juba praeguses rakenduses. Arenduse üldine põhimõte on järgmine:
olemasolevaid mooduleid täiendatakse ainult nii palju kui on vaja muutunud andememudeliga
arvestamiseks. Muudatused ja täiendused realiseeritakse E-Teenused rakenduses (heaks näiteks X-Tee
teenuste moodul – olemasolevate teenuste muutmise asemel tuleb luua uus andmekogu, mis sisaldab
siis nii uusi kui ka muutunud „vanu“ teenuseid).
Järgnev pilt toob välja üldpildi, kus miski moodul uue lahendus mõttes paikneb. Moodul, mis on
täielikult EHR registrirakenduses jääb muutmata, moodul mis ulatub mõlemasse rakendusse tähistab
muudetavat/täiendavat moodulit, kus kogu uus arendus realiseeritakse E-Teenused rakenduses ja
olemasolev funktsionaalsus jääb EHR rakendusse. Ning täielikult E-Teenused rakenduses paiknev
moodul tähistab täiesti uut funktsionaalsust.
8
Täiesti eraldiseisvana on välja toodud Projektipank, mis tehnilises mõttes võiks olla struktureeritud
failide kogum välisel ketta-massiivil või andmebaasis. Failidega seotud tegevusi (upload, töötlus jms.)
kontrollitakse läbi vastava mooduli E-Teenused rakenduses. Projektipanga tegeliku sisu ning täpsem
tehniline lahendus pannakse paika detailanalüüsi käigus.
class EHR
«execution environment» «execution environment»
EHR registrirakendus E-Teenused rakendus
Statistika moodul Päringumoodul Menetlusmoodul
Kaardiliides
Administreerimise
moodul
X-tee teenused
Ruumiandmete
menetlusmoodul
Proj ektipank
1.1.1.6 Menetlusmoodul
E-Teenused rakendusse loodav moodul, mis võimaldab kasutajatel EHRi edastada elektroonselt
taotlusi ja projektidokumente, neid taotlusi elektroonselt menetleda ja anda taotlejatele tagasisidet
menetluse käigu kohta. Realiseeritakse täies mahus E-Teenused rakenduses.
1.1.1.7 Päringumoodul
Moodul, mis sisaldab endas erinevaid registripäringuid. Olemasolevad päringud jäävad EHR
registrirakendusse, paralleelselt luuakse päringute tegemise võimalused ka E-Teenused rakendusse.
1.1.1.8 Ruumiandmete menetlusmoodul
Menetlusmooduli alamosa, mille sisuks on ruumiandmetega tegelemine. Tihedalt seotud GIS
mooduliga. Täpsemalt on ruumiandmete menetlus mooduli kohta kirjutatud dokumendis
„EHRGIS_visioon_2011_22“.
1.1.1.9 Kaardiliides
Kaardiliidesega seotud muudatused on kirjeldatud dokumendis „EHRGIS_visioon_2011_22“.
9
1.1.1.10 Statistika moodul
Moodul sisaldab erinevaid Statistikaameti jaoks tehtud päringud/raporteid. Jääb praegusel kujul EHR
registrirakendusse, vajadusel kohendatakse võtmaks arvesse võimalikke muutusi andmebaasis.
1.1.1.11 X-tee teenused
X-tee teenused saab jaotada kahte gruppi: olemasolevad ja loodavad. Eesmärk on jätta olemasolevad
teenused võimaluse korral täiesti muutmata. Loodavad x-tee teenused lähevad uue andmekogu
koosseisu. Samuti kui tekib vajadus olemasolevat teenust täiendada, siis luuakse vana teenuse
täiendamise asemel vastav teenus uude andmekokku. Uus andmekogu realiseeritakse vastavuses X-
Tee uute standarditega ja ta kasutab document/literal SOAP sõnumi kodeeringut. Mingil hetkel
tulevikus, kui kõik teenused on uude andmekogusse üle viidud kaob vajadus praeguste vanale
standardile tuginevate x-tee teenuste järgi – ja ühtlasi ka praegu kasutusel oleva andmekogu järgi
1.1.1.12 Administreerimise moodul
Moodul, mille abil saab hallata rakenduse kasutajaid, klassifikaatoreid, süsteemseid parameetreid jm.
rakenduse igapäeva tööks vajalikke parameetreid.
10
2 Sõnastik
DAO – Data Access Object. Abstraktne liides kapseldamaks rakenduse ja persistentse
andmekogu (andmebaas) detailset suhtlust.
ORM – Object-Relational Mapping. Programmeerimistehnika andmete konverteerimiseks
kahe erinevate tüüpi süsteemi vahel (nt. Andmebaas ja rakendus)
POJO – Plain Old Java Object. Termin tähistamaks lihtsat Javas kasutatavat objekti
RMI – Java Remote Method Invocation. Javas kasutatav protokoll, millega Java teenused
omavahel suhtlevad.
SOA – Service Oriented Architecture. Teenuste-põhine arhitektuur.
SOAP – protokoll, millega veebiteenused vahetavad omavahel struktuurseid andmeid.
11