Käskkiri

KÄSKKIRI 18.05.2023 nr 47 Riigihanke „Ehitisregistri majutus 2" korraldamine, komisjoni ja vastutava isiku nimetamine Riigihangete seaduse § 14 lõike 1 punkti 1, § 100 ja § 101 alusel ning kooskõlas ettevõtlus- ja infotehnoloogiaministri ning majandus- ja taristuministri 09.10.2017. a käskkirjaga (registreeritud dokumendihaldussüsteemis 03.10.2017. a) nr 1.1-1/17-199 kinnitatud „Majandus- ja Kommunikatsiooniministeeriumi hankekorraga“: 1. Korraldada riigihange „Ehitisregistri majutus 2“ (riigihanke objekti kood 72300000-8 – „Andmeteenused“) lihthankena, kuna hanke eeldatav maksumus ilma käibemaksuta on alla 60000 euro. 2. Moodustan käskkirja punktis 1 nimetatud riigihanke läbiviimiseks komisjoni järgmises koosseisus: 2.1. Komisjoni esimees Kristjan Kaiklem – infotehnoloogia osakonna juhataja. 2.2. Komisjoni liikmed: 2.2.1. Verner Eiber – infosüsteemide arendustalituse juhataja; 2.2.2. Ülo Puskar – infosüsteemide arendustalituse peaspetsialist; 2.2.3. Taavi Jakobson – ehitisregistri talituse juhataja. 3. Määran käskkirja punktis 1 nimetatud riigihanke eest vastutavaks isikuks infotehnoloogia osakonna infosüsteemide arendustalituse juhataja Verner Eiber’i. 4. Kinnitan käskkirja punktis 1 nimetatud riigihanke alusdokumendid (lisatud). 5. Valitud hankemenetluse liigi ja punktis 4 nimetatud riigihanke alusdokumentide peale võib esitada vaidlustuse Rahandusministeeriumi juures asuvale riigihangete vaidlustuskomisjonile riigihangete seaduses sätestatud korras ja tähtajal. (allkirjastatud digitaalselt) Ahti Kuningas kantsler  Käskkirja Lisa 2 Lihthanke alusdokument Hankedokument Lihthange – „Ehitisregistri majutusteenus 2“. 1. Lepingu eseme kirjeldus: Ostetakse ehitisregistri tarkvara majutamise teenust. Eduka pakkumuse esitanud pakkujaga sõlmitakse leping, mis kehtib kuni 31.03.2024. 2. Käesoleva riigihanke tellijaks on Majandus- ja Kommunikatsiooniministeerium (registrikood 70003158), asukoht Suur-Ameerika 1, Tallinn 10122. 3. Hanke raames ostetakse majutusteenust kogumaksumusega kuni 59999 eurot. 4. Hange viiakse läbi riigihangete registris (edaspidi RHR). 5. Hanke eest vastutav isik: Verner Eiber (tel: 6256 496, [email protected]), infotehnoloogia osakonna infosüsteemide arendustalituse juhataja. 6. Osalemise tingimused 7. Hankes saavad osaleda ainult pakkujad, kelle elu- või asukoht on Eestis, mõnes muus Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud riigis. 8. Hanketingimused, nõuded pakkumusele ja pakkumuse esitamine. 8.1. Pakkumus tuleb vormistada eesti keeles ja esitada RHR-is. Pakkumuse esitamise tähtpäev ja kellaaeg on märgitud RHR-s üldandmete lehele. 8.2. Pakkumuse esitamisega kinnitab Pakkuja täielikku nõustumist kõigi hanke alusdokumentide, sh hankelepingu tingimustega. Pakkuja ei saa lisada omapoolseid tingimusi hanke alusdokumentidele. 8.3. Hankepass tuleb esitada koos pakkumusega ja digitaalselt allkirjastatult allkirjaõigusliku isiku poolt. 9. Pakkumus peab olema jõus vähemalt 90 (üheksakümmend) päeva pakkumuste esitamise tähtpäevast arvates. 10. Kõigi pakkumuste tagasilükkamine 10.1. Hankija võib teha põhjendatud kirjaliku otsuse kõigi pakkumuste tagasilükkamise kohta lisaks RHS § 116 lõike 1 punktis 1 sätestatule kui: 10.1.1 hankemenetluse toimumise ajal on Hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad Hankijale ebaotstarbekaks hankemenetluse lõpule viimise hanke alusdokumentides sätestatud tingimustel. 10.2. Hankija ei kanna vastutust Pakkujate ees, kui kõigi pakkumuste tagasilükkamine on toimunud käesolevas dokumendis sätestatud tingimustel. 11. Variantpakkumuste esitamine ei ole lubatud. 12. Hindamiskriteeriumid ja pakkumuse hindamine 12.1. Hankeleping sõlmitakse majanduslikult kõige soodsama pakkumuse esitanud Pakkujaga. Pakkumuse hindamiskriteeriumiks on 100% majutusteenuse kuutasu. 13. Koos pakkumusega esitab pakkuja hankepassi vastavalt hanketeates nõutule. 14. Hankedokumendi lisad: Lisa 1 – Majutuseteenuse osutamise tingimused, Lisa 2 – Hankelepingu eritingimuste projekt.  Käskkirja Lisa 1 Riigihanke „Ehitisregistri majutus“ alusdokument Pakkujate hankemenetluselt kõrvaldamise alused, kvalifitseerimistingimused ja kvalifikatsiooni tõendamise nõuded 1. Hankemenetluselt kõrvaldamise alused ja hankepassiga esitatav informatsioon 1.1. Hankija ei sõlmi hankelepingut ja kõrvaldab hankemenetlusest pakkuja, kellel esineb RHS § 95 lõikes 1 nimetatud kõrvaldamise alus. 2. Pakkuja kvalifitseerimise nõuded 2.1. Majanduslik ja finantsseis 2.1.1. Pakkuja viimase 3 (2020; 2021; 2022) lõppenud majandusaasta (mille kohta on riigihanke algamise ajaks kinnitatud majandusaasta aruanded) netokäive kokku hankelepingu esemele vastavas osas on vähemalt 100 000 EUR (KM- ta). Pakkuja esitab nimetatud tingimuse täitmise kohta kirjaliku kinnituse. 2.1.2. Kui punktis 2.1.1 nõutud andmed ei ole Hankijale äriregistri kaudu kättesaadavad, esitab Pakkuja netokäibe hankelepingu esemele vastava osa kohta andmed hankepassis.. Hankija aktsepteerib ka väljavõtet 2023. majandusaasta aruandest, mis tõendab ps 2.1.1. nimetatud netokäibe olemasolu. 2.2. Tehniline ja kutsealane pädevus Pakkuja peab olema riigihanke algamisele eelneva 36 kuu jooksul nõuetekohaselt täitnud ja lepinguga ettenähtud tähtajal üle andnud ning tellija poolt peab olema vastu võetud vähemalt kaks infosüsteemi majutuse lepingut. Pakkuja esitab hankepassis teabe eelnimetatud lepingu(te) maksumuse, kuupäevade, töö nimetuse või sisu ja teiste lepingupoolte kohta, samuti riigihanke viitenumbri juhul, kui on tegemist täidetud riigihanke lepinguga. Iga lepingu maksumus peab olema vähemalt 50 000 eurot ilma käibemaksuta. 3. Hankepass 3.1. Hankepass peab sisaldama märget selle kohta, milline ametiasutus või kolmas isik väljastab vajaduse korral Pakkuja kinnitustele vastavad andmed või dokumendid, ja Pakkuja kinnitust, et tal on võimalik vajaduse korral viivitamata need dokumendid Hankijale esitada. 3.2. Hankepass peab sisaldama märget selle kohta, kas Pakkuja kinnitustele vastavad andmed või dokumendid on Hankijale elektroonilises andmekogus olevate avalike andmete põhjal tasuta kättesaadavad koos vastava veebilehe aadressi, identifitseerimisandmete ja vajaduse korral Pakkuja kinnitusega, et ta on nõus oma andmete väljastamisega. 3.3. Pakkuja esitab hankepassis kinnituse, et ta ei vasta ühelegi riigihangete seaduse § 95 lõikes 1 sätestatud tingimusele. 3.4. Pakkuja esitab hankepassis kinnituse, et ta vastab kõikidele hanketeates Pakkuja kvalifitseerimiseks esitatud nõuetele.  Hankedokumendi lisa 2 Hankelepingu eritingimuste projekt Majandus- ja Kommunikatsiooniministeerium, registrikood 70003158, asukoht Suur- Ameerika 1, Tallinn 10122, mida esindab Majandus- ja Kommunikatsiooniministeeriumi hankekorra alusel kantsler Ahti Kuningas (edaspidi Tellija), ja XXX, registrikood XXX, asukoht XXX, mida esindab juhatuse liige XXX (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 XXX) tulemusena ning vastavalt riigihanke alusdokumentidele ning Täitja edukaks tunnistatud pakkumusele. 2.3. Leping kehtib alates lepingu allkirjastamisest kuni 31.03. 2024. 2.4. Leping 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 xxx eurot ilma käibemaksuta. 3.2. Tellija tasub Täitjale ehitisregistri majutusteenuse eest igakuiste perioodiliste maksetena summas XXX eurot (käibemaksuga XXX 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 XXX, telefon XXX , e-post XXX . 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. 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. Täitja on teadlik, et leping on avalik. 6.4. Leping allkirjastatakse digitaalselt. Tellija Täitja /allkirjastatakse digitaalselt/ /allkirjastatakse digitaalselt/  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  Hankedokumendi lisa 1 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.