EHR peamiste töövoogude automaattestide loomine
Lähteülesanne
Koostaja: Majandus- ja
Kommunikatsiooni- ministeeriumi
Ehitisregistri talitus
Tallinn 2023
Sisukord
1 SISSEJUHATUS ....................................................................................................................... 2
2 HANKE EESMÄRK .................................................................................................................. 2
3 TÖÖDE KIRJELDUS ................................................................................................................. 2
4 TÖÖDE AJAKAVA ................................................................................................................... 3
5 ÜLDISED NÕUDED ................................................................................................................. 3
6 LISAD .................................................................................................................................... 3
LISA 1 E-EHITUSE PLATVORMI TARKVARALINE ARHITEKTUUR .............................................................................. 3
LISA 2 E-EHITUSE PLATVORMI RISTFUNKTSIONAALSED NÕUDED (MITTEFUNKTSIONAALSED NÕUDED) ....................... 3
LISA 3 EHR ARENDUSTÖÖDE LÄBIVIIMISE JA TESTIMISE JUHEND ........................................................................ 3
LISA 4 ÄRITEENUSTE TESTISAMMUD ............................................................................................................. 3
1 SISSEJUHATUS
Ehitisregister (EHR) on Eesti Vabariigi Majandus- ja kommunikatsiooniministeeriumi (MKM) Ehitus- ja
elamuehitusosakonna hallatav keskne riiklik register, kus hallatakse ehitiste infot ja mille kaudu kodanikud
ja ettevõtted esitavad ehituslubade taotlusi, kohalikud omavalitsused viivad läbi lubade väljastamise
menetlusi, saavad korrastada ehitiste andmeid ning energiamärgise väljastajad annavad energiamärgiseid.
Hetkel on käimas mitmed projektid EHR kvaliteeditagamise süsteemide loomiseks. Üheks neist on
automaattestide loomine, et arenduste käigus teostada teste kiiremini ja laiapõhjalisemalt.
2 HANKE EESMÄRK
Hanke eesmärk on luua Lisas 4 kirjeldatud töövoogude automaattestid, juhis nende kasutamiseks ja nende
põhjal loodavate uute automaattestide loomiseks.
3 TÖÖDE KIRJELDUS
Arendajal tuleb luua järgmiste äriteenuste automaattestid:
• Ehitamise alustamise teatis
• Ehitusloa taotlus
• Kasutusloateatis
• Projekteerimistingimuste taotlus
• Ehitusloa kehtetuks tunnistamise otsus
Äriteenuste testi sammud on Lisas 4.
Testid luuakse kasutades Playwright tarkvara.
Töö tulemusel peab valmima testide ülene POM - page object model, mis järgib Eehitus
kasutajaliidese üldist loogilist ülesehitust.
Töö tulemusel valmivad terviktestid peavad olema jaotatud iseseisvalt kasutatavateks
loogilisteks alamtestideks, milledest saab koostada uusi teste. Alamtestid on näiteks
autentimine, kasutaja rolli valimine jne.
Töö tulemusel loodavad testid peavad olema käsitsi käivitatavad ükshaaval ja testide grupina
ning töö tulemusel tuleb koostada testide käivitamise juhend.
Töö tulemusel tuleb koostada testide arendusjuhend, mille abil on võimalik töö käigus loodud
teste parandada ja uusi teste juurde luua.
Peale esimese automaattesti loomist tuleb tutvustada loodud POM struktuuri ja automaattesti
teistele EHR raamlepingu partneritele ja EHR tehnilisele tiimile. Saadud tagasiside põhjal
kohandatakse tehtut, et tulemus oleks kõigile arusaadav ja kasutatav.
Automaatteste peab saama käivitada GitLab CI/CD pipelines.
4 TÖÖDE AJAKAVA
Tööde alguse ja lõpu aeg fikseeritakse hankelepingus.
5 ÜLDISED NÕUDED
Tehtud tööd peavad vastama MKM Infosüsteemide arendustalituse poolt kindlaks määratud nõuetele,
mis on kirjeldatud järgmistes dokumentides:
Lisa 1 - e-ehituse platvormi tarkvaraline arhitektuur;
Lisa 2 - e-ehituse platvormi ristfunktsionaalsed nõuded (mittefunktsionaalsed nõuded);
Lisa 3 - EHR arendustööde läbiviimise ja testimise juhend;
Töövõtja pakub töö teostamiseks välja sobiva metoodika, mis lepitakse kokku Tellijaga töö alguses.
Tööd toimuvad tihedas koostöös Töövõtja ja Tellija vahel. Töövõtja pakub töö käigus jooksvalt välja
omapoolseid lahendusi töö teostamiseks ning arutab need läbi töö Tellijaga.
Töö lõpptulemused dokumenteeritakse Confluences vastavalt tarkvaraarenduse heale tavale.
6 LISAD
LISA 1 E-EHITUSE PLATVORMI TARKVARALINE ARHITEKTUUR
LISA 2 E-EHITUSE PLATVORMI RISTFUNKTSIONAALSED NÕUDED (MITTEFUNKTSIONAALSED NÕUDED)
LISA 3 EHR ARENDUSTÖÖDE LÄBIVIIMISE JA TESTIMISE JUHEND
LISA 4 ÄRITEENUSTE TESTISAMMUD
E-ehituse platvormi arendustööde läbiviimise ja testimise juhend V 5 – 20 . 03 .20 2 3 Käesolev juhend on mõeldud järgimiseks kõigile e-ehituse platvormi ja EHRi arendusega seotud osapooltele. Juhendis on kirjeldatud infovahetuse allikad ja kohustused. E -ehituse platvormi arendustööde dokumentatsiooni hoitakse Sharepoint dokumendihalduses (SP). Keskkonna halduse ja juurdepääsu eest vastutab MKM. Meeskondade projektijuhid edastavad projekti alguses nimekirja (ees- ja perenimi, isikukood, e-kirja aadress) osalistest, kes peavad juurde pääsema e-ehituse platvormi dokumendihoidlale (endise nimega EHRi dokumendihoidla) . Projekti alguses luuakse SP- sse projekti kaust, kuhu kogutakse kõik projektiga seotud dokumendid nagu koosolekute protokollid, lähteülesanded, projektiplaanid jm. dokumendid. Juhul, kui dokument paikneb kuskil teises asukohas siis lisatakse SP projektikausta link sellele dokumendile. E-ehituse platvormi dokumentatsioon antakse Tellijale üle dokumendihalduse keskkonna kaudu. Juhul, kui samast dokumendist edastatakse mitu versiooni, siis kõik erinevad versioonid tuleb nimetada ühe ja sama failinimega. Versioonid eristuvad SP-s „versiooni ajaloo“ kaudu. E-ehituse platvormi dokumentide sisukord (analüüsi, disaini, arhitektuuri, testimise, projektijuhtimise kontekstis) lepitakse kokku enne vastavate projekti tööde algust. Täitja projektijuht, kes hakkab vastavat dokumenti koostama, esitab hiljemalt tööde alguse kuupäeval SP projektikausta dokumendi kavandi, milles on toodud vähemalt dokumendi sisukord ja võimalusel ka vorm. Operatiivse suhtlusvahendina kasutatakse lisaks (mobiil)telefonile ka Skype või Teamsi keskkonda. Projekti osalised lisatakse projekti ühisvestlusse . Skype kasutamise puhul edastab Täitja projektijuht vajalike osaliste Skype kontode nimekirja MKM projektijuhile, kes lisab nimekirja liikmed vestlusele. Projekti kestel on kõigil meeskonnaliikmetele kohustus osaleda vestluses; Projektide vahelisel ajal tööde planeerimiseks või vigade aruteluks, on tehnilistel projektijuhtidel, analüütikutel või arhitektidel kohustus osaleda vestluses; Vestluses on kohustuslik informeerida kõiki osapooli kavandatavatest tarnetest. Vt. EHR koodi haldamise ja tarnimise juhendit Osapooled praktiseerivad proaktiivset kommunikatsiooni ning ei varja võimalike vigu ja probleeme. E -ehituse platvormi tarnete, arendustööde, vigade ja hooldustööde fikseerimiseks kasutatakse JIRA keskkonda. Meeskondade projektijuhid edastavad projekti alguses nimekirja (ees- ja perenimi, isikukood, e-kirja aadress) osalistest, kes peavad juurde pääsema e-ehituse platvormi (end. EHR ) JIRA keskkonnale. Arendusprojektide läbiviimise alguses koostab Täitja Lepingu lähteülesandes toodud funktsionaalsete nõuete kohta JIRA piletid tüübiga “arendus”. Arenduspiletite koondamiseks luuakse JIRA komponent, nii, et kõik ühe lepinguga seotud (või lepingu alapunktiga) seotud piletid on seotud vastava komponendiga. Komponentide abil saab ülevaate kõigist komponendiga seotud arendustöödest ja veapiletitest, mis vastavas komponendis aja jooksul on tehtud. Lepinguliste tööde arendamiseks, testimiseks ja üleandmiseks koostatakse lähteülesandes toodud nõuetest Jira piletid nn. “ backlog ” . “ Backlog ” jagatakse sprint ideks ehk vahetulemusteks , mille kestus on 2 nädalat . Arendustööde vahetulem uste ehk sprindi tulemuse paigaldus ja üleandmine toimub vastavuses EHR koodi haldamise ja tarnimise juhendile . Lepinguliste tööde Tellijale üleandmine algab Täitja poolt üleandmise akti esitamisega (või vastavuses Lepinguga). Üleandmise aktis peavad olema viited kõigile üleantavatele tulemitele sh.: Lingid üleantavatele koodidele Git -s (git.mkm.ee). Link peab olema koodiharule ja -versioonile , milles asu b üleantav kood , Viide API teenuste endpointidele Swaggeris (swagger.ehr.ee) Viide Katalon automaattestidele, millega üleantavat rakendust saab testida Viited projekti tulemdokumentidele ja seal tehtud muudatustele S P -s ( https://365mkm.sharepoint.com/sites/MKM/EHR ) Viit, millelt Tellija saab alustada rakenduse testimist Üle antava rakenduse Helm Chart nimetus ja versioon (juhul, kui üle antav rakendus paigaldatakse Kubernetes klastrisse) JIRAsse loodud arenduspiletid peavad olema sellise detailsusastmega, et nende alusel saavad arendajad teostada arendustööd ning testijad saavad läbi viia vastuvõtu testimise. Kui kasutusloo realiseerimiseks vajaminevad piletid on valmis, siis tuleb läbi viia kasutusloo testimine, milleks arendaja loob eraldi pilet, kus on testi sammude kirjeldused. Arendaja testib kõigepealt ja seejärel suunab pileti tellijale. Live eelne t estimine Kui kõik arendustööd (LÜ kirjeldatud nõuded) on valmis ja testitud, siis peab läbi viima terviktöövoogude testimised, mida tehakse vastuvõtutestimise sprindis. Arendaja koostab piletid tervikvoogude testimiseks. Iga tervikvoo kohta üks pilet. Tervikvoos testimiseks kirjeldab arendaja sammud mida testija peab läbima (tervikvoo testimislood salvestatakse Confluence -sse , et neid saaks korduv kasutada). Kõigepealt testib terviktöövoo üle arendajapoolne testija ja seejärel suunatakse pilet tervikvoo testimiseks tellijale testimiseks. Arendaja lisab vastuvõtutestimise sprinti ka dokumentide lõppversioonide ülevaatamise pileti. Vastuvõtutestimise sprinti lisab tellija omapoolsed testimise ülesandeid nt. endpointide testimine. Live minnakse siis kui: LÜ-s ja töö käigus kokkulepitud muudetud ja uued nõuded on realiseeritud, testitud ja veavabad. Vastuvõtutestimine on läbiviidud ja vead parandatud. Dokumentatsioon esitatud ja tellijapoolt kinnitatud. Arendustöödes tuvastatud vigade lahendamiseks koostab MKM Helpdesk JIRA-sse lisatud veapiletite alusel kord kuus arendajale kriitiliste vigade sprindi, mille arendaja tarnib järgmisel kuul MKM-le testimiseks. JIRA piletite lahendamise protsessi üldine kirjeldus on järgmine: Töid üle andva arenduspartneri testija testib kõik üle antavad piletid esmalt MKM keskkonnas “test”. Testimisel viib testija piletid oma nimele staatusega „TESTIMISEL“. Peale testimist viib arenduspartneri testija piletid staatusesse „OMANIKU TESTI OOTEL“ ja suunab piletid MKM testijale . Üldpõhimõttena antakse piletid üle “OMANIKU TESTI OOTEL” staatusesse esimesel võimalusel, ehk ei neid ei grupeerita ega anta üle portsude kaupa. MKM testijad testivad piletid ning peale testimist suunavad arenduspartneri testijale staatuses „TESTITUD“ või „AVATUD“ vastavalt sellele, kas pilet oli lahendatud või esineb vigu. Kui kõik sprindi piletid on peale MKM testimist staatuses „TESTITUD“, siis võib liikuda järgmisesse toodangusse viimise etappi “ prelive ”. Peale “ prelive ” tarnet testib arenduspartneri testija kõik üle antavad piletid esmalt MKM “ prelive ” keskkonnas. Testimisel viib testija piletid oma nimele staatusega „TESTIMISEL“. Peale testimist viib arenduspartneri testija piletid staatusesse „OMANIKU TESTI OOTEL“ ja suunab piletid MKM testijale . MKM testijad testivad piletid prelive keskkonnas ning peale testimist muudavad pileti staatuseks „LAHENDATUD“, „TARNE OOTEL“ või „AVATUD“ vastavalt sellele, kas pilet oli lahendatud, vajab üle kontrollimist toodangus või esineb vigu. Kui kõik prelives oleva tarne piletid on staatuses „LAHENDATUD“, siis võib alustada toodangusse tarnimisega. Juhul, kui “ prelive ” etapis avastati vigu siis alustatakse peale vigade parandamist uuesti “test” etapist. Kõikide osapoolte projektijuhid lisatakse JIRA tarnepiletite kohta info saajateks. Tööde tähtaegade fikseerimisel tuleb arvestada, et töö tähtaeg tähendab kokkulepitud päeva lõpp 23.59. Kõik MKM projektiga seotud meediaga suhtlus tuleb alati kooskõlastada ennetavalt MKMiga ; ka MKM peab ennetavalt kooskõlastama partneritega meediasse suunatava informatsiooni. Kõik e-ehituse platvormi arenduse projektis läbi viidud koosolekud protokollitakse (fikseeritakse otsused, riskid, probleemid) ja soovi korral helisalvestatakse, selles osas lepitakse rollide täitjad kokku enne koosoleku algust. Üldjuhul koostab protokolli Täitja projektijuht ja salvestab selle koosolekule järgneval tööpäeval SP- sse projekti kausta. Iga sprindi/arendusetapi lõpus viiakse vajadusel läbi üle antava töö ühisläbivaatus , mille käigus Täitja esindajad esitlevad Tellijale üle antava töö tulemit. Täitja projektijuht esitab projekti alguses MS Project formaadis projekti tööde plaani SP- sse projekti kausta (kui MKMiga ei ole eelnevalt kokku lepitud teisiti) . Täitja projektijuht uuendab igal projekti töönädala esmaspäeval või kokkuleppel muul päeval vasta val t projekti nädala koosoleku ajale esialgselt esitatud projektiplaani ning lisab sellesse tööde täitmise informatsiooni. Projekti plaan peab olema sprindi pealkirja täpsusega. Tööde plaan vaadatakse kõigi osapoolte poolt üle igal projekti koosolekul ja vajadusel viiakse sellesse muudatused. Juhul, kui arendusprojekti käigus on vajalik e-ehituse platvormi andmebaasi des muudatuste tegemine siis peab järgima: E-ehituse andmebaasid ja nende uuendamine Juhul, kui arendusprotsessi käigus luuakse uus teenuste API või täiendatakse olemasolevaid teenuseid siis arendaja täiendab API kirjeldust Swaggeris vastavalt EHR API teenuste nimetused ja teenuste kirjeldamine
Ehitisregistri tarkvaraline arhitektuur Ver . 10 17.11.2022 Ülo Puskar , Kristjan Kaiklem Alates 2018 neljandast kvartalist toimuvad E -ehituse platvormi edaspidi platvorm arendused, mis lähtuvad käesolevas dokumendis toodud nõuetest . Käesolev dokument kajastab MKM IT osakonna ja arendajate poolt tehtud e-ehituse keskkonna arhitektuuri kokkuleppeid. Uutes arendustes tuleb järgida käesolevat dokumenti. Juhul, kui tekkib vajadus käesolevas dokumendis toodud nõude id laiendada või muuta tuleb selleks eelnevalt saavutada kokkuleppe MKM IT spetsialistidega ning tehtud kokkulepped käesolevasse dokumen ti sisse viia. Arhitektuuri e esmär gid Tagada lõppkasutajatele kiire töökeskkond ja teenuste lühike vastuseaeg, et võimaldada head kasutajakogemust. Muuta platvormi rakenduse edasiarendamine vähe ressursse nõudvaks , et tagada platvormi ajakohasus ning paindlikkus muudatu ste sisseviimisel . Tagada platvormi turvalisus ning platvormi komponentide pidev uuendamine, et vältida turvariske . Tagada platvormi jätkusuutlikkus võttes arendustes kasutusele järk järgult uusi tehnoloogiaid ja rakenduse käitluskeskkondi nii, et olemasolevaid rakendusi saaks töös hoida, kuni uued need välja vahetavad. Tagada EHR vastavus kõigile ISKE klassiga määratud nõuetele. Platvormi a rhitektuuri põhimõtted Arhitektuur lähtub mikroteenuste kontseptsioonist ( https://en.wikipedia.org/wiki/Microservices ) , ehk p latvorm koosneb kesksest UI rakendusest ning sellega seotud API REST mikroteenuste rakendustest . (Mikroteenuse asemel on edaspidi kasutusel sõna teenus). Vanem EHR Java Spring rakendus t kasutatakse paralleelselt senikaua, kui uued teenused selle järk järgult välja vahetavad. Uute teenuste arendusel lähtume „ Brownfield “ arendusmetoodikast ( https://en.wikipedia.org/wiki/Brownfield_(software_development) ), ehk teenuste loomine lähtub olemas olevast tarkvarast kuni 2023 esimene kvartal . Peale seda võetakse vanem Java rakendus kasutusest maha. Platvormi tarkvarali n e arhitektuur koosneb komponentidest : Kasutajaliides e rakendus ed (pakendatud konteinerrakendus) Pakendatud API konteinerrakendused Konteinerite käitluskeskkond Kubernetes koos Rancher haldustarkvaraga Andmebaas id Virtuaalserverid Riigipilv Joonis SEQ Joonis \* ARABIC 1 EHR - arhitektuur Kasutajaliides e rakendused : Kasutajaliides ( User Interface ) – lähtub mi c rofrontend ( https://micro-frontends.org/ ) põhimõttest ehk kasutajaliides on jaotatud komponentideks ( custom elements ) . Kõik kasutajaliidese komponendid kasutavad keskseid aluskomponente mida kasutatakse npm paketist ehr-components . Kasutajaliidese loomisel kasutame React , HTML, CSS ja Javascripti viimaseid versioone ja Nginx veebiserverit. E-ehituse aluskomponendi loomisel ei tohi muuta esialgseid komponente. Esialgse komponendi alusel tuleb luua uus komponent ning lisada see e-ehituse komponentide projektis “ src / ehr_components ” folderisse . E-ehituse kasutajaliides käivitub juurkomponendist , mis asub projektis: ehr -ui ning kõik uued loodavad komponendid peavad olem a integreeritud juurkomponenti. Juurkomponendis on komponentide infovahetuseks kasutusel Redux pakett Komponen did integreeritakse juurkomponenti npm paketina. Komponendi sisenditeks on “ React props ” ja väljunditeks “ render props event ”- d. Komponentide s isendid ja väljundid dokumenteeritakse React Styleguidist paketiga Kasutajaliidese juurkomponent integreeritakse olemasoleva Java rakendusega linkide kaudu, nii et www.ehr.ee lingi avamisel käivitatakse juurko m ponent ning sellest omakorda uue või vana Java rakenduse lehed vt. joonis Kasutajaliidese navigeerimiseks kasutame juurkomponendis react-router paketti Kasutajaliidese stiilid võetakse juurkomponenti integreeritud e-ehituse CSS stiilifailist . Kasutaliidese stiilide muutmiseks või lisamiseks on e-ehituse stiiliraamat . E-ehituse stiilifail asub siin projektis . E-ehituse stiilifaili täiendamisel peab arendaja tagama, et muudatused ei kahjustaks olemasolevate komponentide töötamist. Peale muudatuste sisseviimist tuleb genereerida uus CSS ja integreeridasee e-ehituse juurkomponenti. Kasutaja õigused kasutajaliidese elementidele leitakse juurkomponendis või vajadusel alamkomponentides kasutades e-ehituse JWT tokenit . Vt. Juurdepääsu piirangud E-EHITUS platvormi teenustes ja kasutajaliideses Kasutajaõiguste süsteemi detailanalüüs Kasutajaliidese andmevahetuseks andmebaasiga kasutame REST teenustel põhinevat API-t . Vormi väljade kohustuslikkuse kontroll ja väljade kuvamise/ täitmise ärireeglid realiseerime võimalusel lehitsejas ja Andmebaasi kirjutamisel vastavas API-s . Kasutajaliidese põhivaated realiseeritakse prototüüpimisel kasut a des e-ehituse aluskomponente . E-ehituse kasutajaliides peab olema testitud enamlevinud lehitsejatega (Chrome, Edge, Firefox , Safari) ja mobiilivaates . Kasutajaliides peab olema koostatud nii , et autoriseeritud kasutaja saa ks muuta html elementide pealkirju , veateated ning abitekste. Kasutajaliides e tekstid peavad asuma juurkomponendis keelefailides (eesti, inglise). Lõppkasutajale kuvatavatel html elementidel peavad olema unikaalsed ID-d, et saaks rakendada kasutajaliidese automaattestimist. Komponentidele luuakse staatiline html , et kuvada komponente ka juhul, kui javascript pole kättesaadav/lubatud. Uute komponentide loomisel kasutame antd ja reacstrap pakette. Kasutajaliidese loomisel kasutame creat e -react-app tööriistu ( webpack , babel , eslint airbnb reeglitega ). Pakendatud API konteinerrakendused : Uu te API -de loomisel kasutatakse kas: Java, NodeJS või Pyt h on tehnoloogiate viimaseid stabiilseid versioone . Uue API rakendusserverid käitatakse Docker https://www.docker.com/ konteinerite s riigipilves Kubernetes klastris. Kubernetes klastrite haldusvahendina kasutatakse Rancher tarkvara https://rp-rancher.opnd.eu/g/clusters . Uue API rakendused peavad sisaldama automaattarne: EHR Git -> Riigipilv es Helm Chart vajalikke Helm konfiguratsiooni faile vt. Näiteks Helm konfiguratsioonifaile : https://git. ehr .ee/ehr/ehr-k8s-pipeline/ehr-geoservices/tree/master/helm ja Juhend Helmi kasutamiseks Automaattarne riigipilve lisatakse MKM Git -s projektidele, mis asu vad https://git. ehr .ee/ehr/ehr-k8s-pipeline grupis. Helm Charti abil peab saama paigaldada rakendused Rancher App kaudu: https://rancher.com/docs/rancher/v2.x/en/catalog/ e-ehituse test - ja toodangu klastris olevatesse : development , test, prelive , live projektides asuvatesse namespacedesse . Luuakse mikroteenuste kontseptsioonil baseeruv E -ehituse REST AP I. API kavandamiseks ja dokumenteerimiseks kasutatakse OpenAPI standardit ( https://github.com/OAI/OpenAPI-Specification/ ) ja Swagger tööriistu: https://swagger.io/ Swagger UI ja Swagger Editor . EHR API k avandamisel tuleb järgida: EHR API kirjeldamise reeglid . E- ehituse REST API kirjeldus asub: https://swaggerui.ehr.ee/ . Uue API loomisel tuleb API kirjeldus lisada projekti: https:// git . mkm .ee/ehr/ehr-k8s-pipeline/swaggerui ning uus versioon tarnida riigipilve. E-ehituse API loomisel tuleb tagada, et teenused ei korduks ja soovitav on olemasolevat teenust edasi arendada, mitte luua uusi teenuseid. Teenused peavad olema vähemalt 2 põ hiversiooni (semver2) tagasiulatuvalt ühilduvad. Andmete ülekandmiseks API-st kasutajaliidesesse kasutatakse võimalusel JSON formaati või eelneval kokkuleppel mõnda muud XML formaati (näiteks CityGML ). E-ehituse Kaardikomponendist ja geo - otsingu teenustest andmete vahetuseks kasutatakse GeoJSON formaati. Juhul, kui API teostab andmebaasis C R UD operatsioone siis a ndmete verifitseerimine toimub kahe l tasemel ehk esmalt UI vormi kasutajaliidese s ja seejärel enne andmebaasi viimist API rakenduses . Teenuste autoriseerimine toimub vastavalt: Kasutajaõiguste süsteemi detailanalüüs ja Juurdepääsu piirangud E-EHITUS platvormi teenustes ja kasutajaliideses Teenused, mis teostavad andmebaasiga C R UD operatsioone tuleb luua nii, et trans aktsioonid ning vajalikud Join operatsioonid toimuvad andmebaasis, kasutades andmebaasi protseduure , mitte API rakenduses. Andmete terviklikkuse tagamiseks andmebaaside üleselt kasutatakse võimalusel (juhul, kui saga pattern realiseerimine pole otstarbekas) kahetasemelist “ c ommit ” lahendust (2PC) lisades transaktsiooni koordineerimist vajavate teenuste üleselt uue “ commit ” teenuse või vajadusel mikroteenustes nn. “ Choreography-based saga pattern ” metoodikat ( https://microservices.io/patterns/data/saga.html ) . Teenuste ja andmebaasi ning teenuste omavaheliseks infovahetusel kasutatakse RabbitMQ ( https://www.rabbitmq.com/ ) message brokerit . Andmebaas: Mikroteenuste vajadusteks l uuakse uued PostgreSQL andmebaasid vt. Ehitisregistri andmebaasid ja nende uuendamise juhend Igal andmeobjektil on üks baas , kuhu andmed kirjutatakse . Juhul kui on vajadus kasutada andmeid mõnes teises baasis päringute teostamise ks siis luuakse teise baasi r pre fiksiga view , mille abil andmeid saab lugeda. Andmete sünkroniseerimiseks andmebaaside vahel kasutatakse pglogical tarkvara. Olemasolev Oracle ja uu ed baas id hoitakse sünkroonis Rabbit MQ ( https://www.rabbitmq.com/ ) sõnumiedastusega, kuni olemasolev Java rakendus on kasutusel. EHR unikaalvõtmete (EHR-kood, dokumendi number jm.) loomiseks kasutatakse teenuseid: Koodide omistamise teenused Andmebaasi siseste operatsioonide teostamiseks luuakse SQL protseduurid, mida API-t realiseerivad komponendid välja kutsuvad. Failisüsteem Konteinerakendustele on klastris kasutusel NFS block storage ja Longhorn block storage . Klastrites on kasutusel S3 Object storage teenus , mis on eelistatud failide hoidmise lahendus Riigipilv Kõiki platvormi komponente käitatakse riigipilves Platvormi jaoks on pilves loodud 2 privaatvõrku test ja toodang. Arendajad saavad kasutada testvõrgus olevaid servereid ning Kubernetese klastrit. Toodangu privaatvõrk, Kubernetese klaster ning virtuaalserverid on piiratud juurdepääsuga ainult administraatoritele. Pilves olevate serveritega suhtlemiseks kasutatakse SSH lahendust gate.ehr.ee. Rakenduste tarne pilve toimub git.ehr.ee vahendusel. Pilve arhitektuuris kasutame nimelahendust (DNS). Vt. Eehitus DNS kirjeldus Muud komponendid Cache vajadustega rakenduste jaoks on kasutusel Redis. Vt. https://git. ehr.ee/ehr/ehr-k8s-pipeline/ehr- redis-proxy . Redist saab rakendada vajadusel konteinerite vahel info jagamiseks või rakenduse andmete ajutiseks säilitamiseks kiires püsimälus. Mikroteenuste rakendustele tuleb lisada Kubernetes liveness probe Uue teenuse loomisel kasutatakse võimalikult palju valmis arendatud komponente ( https://www.npmjs.com/ ) ja olemas olevaid raamistikke või teeke. E-ehituse teenused peavad arenduse käigus olema kaetud unit testidega, mille abil kontrollitakse teenuse komponentide (alamosade) vigadeta tööd. Javascripti kasutamisel ( React , NodeJs ) peab tarnitav kood olema kontrollitud Eslint ( https://eslint.org/ ) Airbnb reelitega ning ei tohi sisaldada linteri veateateid. Koodi kvaliteeti k ontrollitakse CI/CD tarnetel Sonarqube ( https://www.sonarqube.org/ ) tarkvaraga. Koodi Sonarqube raport https://sonarqube.mkm.ee/dashboard?id=<projekti nimi> peab olema : Reliability Bug = 0 Security Vulnerability = 0 Rakenduse arendusel tuleb arvestada, et rakendus peab olema testitav Katalon ( https://www.katalon.com/ ) automaattestidega ehk kasutajaliideses kasutatavad html elemendid peavad sisaldama unikaalset atribuuti näiteks id. Kasutajaliides peab olema testitud automaattestidega mobiilivaates ning toetatavate veebilehitsejate vaadetega . API peab olema testitud Katalon API testimiseks mõeldud testidega. Rakenduste logid kogutakse kesksesse logihalduse teenusesse ja seetõttu peavad rakenduste logid olema Json formaadis. Logiteenuse kirjeldus Üleminek uprotsessi etapid Etapid on toodud ajalises järgnevuses aga samas on võimalik etappe ka paralleelselt käivitada juhul, kui selleks on olemas piisavalt ressursse. Tarkvaralise arhitektuuri dokumenteerimine Olemasoleva EHR komponentideks jaotamine ja teenuste kavandamine (vt. järgmine ptk .) Automaattarnete ja testide käivitamine Teenuste kasutajaliidese arendamine (MTA UI + React ) T urvateenuste arendamine : JWT – ehk teenustele juurdepääsu pass , autoriseerimi se süsteem ehk kasutajad/grupid/rollid/juurdepääsuõigused , andmete turvalisus e ja juurdepääsu muudatused . Teenuste arendusprojektid, mille käigus arendatakse uus teenus ja muudetakse olemasolevat rakendust nii, et uue teenuse saab kasutusele võtta. EHR olemasoleva rakenduse komponentideks jaotamine Olemasoleva rakenduse teenusteks jaotamisel on aluseks EHR tänase rakenduse komponendid. Samuti tuleb komponentidena arvestada tänases EHR infrastruktuuris paiknevad eraldi rakendused: andmeait, EHR infoportaal, VRM, kaardirakendus. Uue teenuse arendusel tuleb järgida mikroteenuste põhimõtteid ehk teenuses peavad olema andmed, rakenduse server ja kasutajaliides nii, et EH R muude teenuste (va. Elutähtsad teenused, mis on aluseks kõigi teiste teenuste toimimisele) katkestused ei mõjutaks ülejäänud teenuste tööd. Kuna uute teenuste loomisel tuleb need integreerida olemasoleva rakendusega siis olemasolevad EHR komponendid tuleb jaotada teenusteks arvestades olemasoleva rakenduse ülesehitust ja võimalusi nii, et uusi teenuseid saaks kasutusele võtta võimalikult vähe olemasolevat rakendust muutes. See võimaldab hoida kokku ressursse ning tagada lõppkasutajatele võimalikult sujuva ja probleemideta ülemineku protsessi. EHR tarneprotsess (tehnoloogia vaade) E-ehituse teenuste tarkvaraline protsess on lahti kirjeldatud allpool olevas joonisel (vt. Joonis 1). Uue tarkvara tarnimisel võetakse kasutusele konteineri põhine lähenemine – selle protsessi realiseerimiseks kasutatakse järgmisi tarkvarasid : GIT / GIT CI ( https://about.gitlab.com/ ) – kooditarnete tegemine (rakenduse kood, sql kood, docker paigaldusfailid, automaattestid). Tarne protsessi automaatne käivitamine . Kasutatakse tellija keskkonda aadressil : https://git. ehr .ee Docker ( https://www.docker.com/ ) – vastavalt GIT- is oleva infole konteinerite loomine ja levitus ( rakendus + andmebaas + rakenduse toimimiseks vajalik infrastruktuur) . Docker -iga integreeritud tarkvarad : Unit testid – arendaja poolt kirjutatud testid kontrollimaks EHR-i ja selle komponentide toimimist vastavalt nõuetele; Apache Maven ( https://maven.apache.org/ ) - Java koodi kompileerimine, SonarQube ( https://www.sonarqube.org/ ) – koodi kvaliteedi kontrolli teostamine, Liquibase ( https://www.liquibase.org/ ) – andmebaasi loomine ja muutmine, Artifactory ( https://jfrog.com/artifactory/ ) – Java artif aktide loomine ja konteinerite registreerimine. Helm kaartide hoidla - ( https://chartmuseum.com/ ) Kubernetes ( https://kubernetes.io/ )– konteinerite haldamine, skaleerimine ja koormuse jaotamine. Katalon ( https://www.katalon.com/ ) – EHR UI ja API testmine . Joonis 1. E-ehituse tarneprotsess (tehnoloogia vaade)
Mittefunktsionaalsed nõuded
V1.2 16.05.2022
Järgnevalt on toodud Ehitisregistri rakenduste arendamise mittefunktsionaalsed nõuded ja nõudega
seotud vajalikud lingid.
Nõude kirjeldus Selgitus Kategooria
https://pilv.mkm.ee/s/lyWdATR1SUmVIfQ/d
Rakenduse arhitektuur peab lähtuma EHR
1. ownload?path=%2F&files=Ehitisregistri%20t Arhitektuur
arhitektuuridokumendist
arkvaraline%20arhitektuur.docx
Rakenduse kasutajaliides peab olema
https://www.w3.org/TR/2018/REC-
2. juurdepääsetav ning vastama vähemalt Kasutajaliides
WCAG21-20180605/
WCAG 2.1 tasemele AA.
Rakenduse kasutajaliides peab olema
kasutatav järgmiste veebibrauseritega:
3. Kasutajaliides
Chrome, Safari, Firefox, Edge, Android
Chrome ja IOS lehitsejad.
Rakenduse kasutajaliides peab ühilduma
täielikult HTML5, CSS3 ja Javascript
4. kehtivate standarditega ning kõikide Kasutajaliides
nõutud veebilehitsejate viimaste
versioonidega.
Rakenduse kasutajaliides peab kohanduma
5. erinevate ekraanivaadetega (arvuti, tahvel Kasutajaliides
ja mobiiltelefon).
Rakenduse kasutajaliidese disainiotsused
6. Kasutajaliides
tuleb tellijaga kooskõlastada.
Rakenduse kasutajaliides peab olema
7. tehtud lähtudes värskeimatest UX Kasutajaliides
trendidest
8.
Rakenduse kasutajaliidese kujunduses E-ehituse stiiliraamat Kasutajaliides
tuleb lähtuda E-ehituse stiiliraamatust veebiversioon
Rakenduse kasutajaliidese
9. aluskomponentideks on MTA EHR-komponendid Kasutajaliides
komponendid
Kasutajaliidese komponendid peavad react-styleguidist
10. Kasutajaliides
olema dokumenteeritud
Kasutajaliidese komponendi Git projekti
readme.md failis peab olema: Vt. näidis
Komponendi eesmärgi tutvustus Ehitise kehtivate andmete teenus
Juhend, kuidas komponenti saab teistes
projektides kasutada ja
Viide dokumentatsiooni asukohale –
11. https://swaggerui.ehr.ee/ehitise_kehti Kasutajaliides
dokumentatsioon peab sisaldama näiteid,
vate_andmete_teenus
kuidas komponenti võõrast koodist välja
kutsuda
Juhend edasiarendamiseks
Juhend versioneerimiseks ja
publitseerimiseks
Rakendus peab töötama
12. veebibrauseritega, mis toetavad ID- eID
kaarditarkvara 2 viimast versiooni
Rakendus peab kasutama kasutaja
13. tuvastamiseks keskset TARA https://e-gov.github.io/TARA-Doku/ eID
autentimisteenust
Arendusprojekti juhtimiseks ja projekti
läbiviimiseks kasutatakse Hankija Arendustööde tellimused ja tarkvaravigade
14. organisatsioon
projektijuhtimistarkvara JIRA haldamine.
(https://jira.mkm.ee)
Arendusprojekti käigus loodav lähtekood
esitatakse dokumenteerituna läbi
15. organisatsioon
koodihalduskeskkonna
https://git.ehr.ee/projektinimi
Arendusprojekti käigus loodavate
rakenduste versioone tähistatakse
vastavalt Semver 2.0 standardile
16. Semver 2.0 organisatsioon
„versioon-x.x.x“. Versiooni numbrid
peavad kajastuma koodihoidla Git Tag-des
Statistilisi parameetreid mõõdetakse Tellija annab omalt poolt vastava Google
17. analüütika
Google Analytics keskkonna kaudu. Analytics konto andmed
Jõudluse parameetrid:
Üldjuhul peavad API päringud tagastama
tulemuse browserisse alla 1s.Mõõdetakse
18. browseri põhiselt. Kvaliteet
API erijuhud lepitakse Tellijaga eraldi kokku
Kasutajaliidese html koos stiilide ja
Javascriptiga laaduma <1s
API rakenduse endpoint-id peavad olema EHR API teenuste nimetused ja teenuste
19. Kvaliteet
vastavuses viidatud juhendile. kirjeldamine
API rakenduse kõik „route“-d peavad
20. olema varustatud Katalon testiga, mis Katalon Kvaliteet
testib sisend/väljundit ja kiirust.
Rakendus peab tagama isikuandmete
töötlemise vastavalt isikuandmete kaitse https://eur-lex.europa.eu/legal-
21. Infoturve
üldmäärusele ja isikuandmete kaitse content/ET/TXT/?uri=CELEX%3A32016R0679
seadusele
Rakenduse ja andmebaasi turvalisuse
https://www.owasp.org/index.php/OWASP_
22. tagamiseks tuleb järgida OWASP-i parimaid Infoturve
Cheat_Sheet_Series
praktikaid.
Rakendus ei tohi lubada ühe kasutajaga
23. Infoturve
mitut samaaegset sessiooni
Rakenduse ja kasutaja vaheline
24. infovahetus tohib käia ainult üle HTTPS Infoturve
protokolli.
ISKE turvaklassi täpsustab Tellija. Täpsem
Rakendus peab olema kirjutatud info RIA lehel :
25. arvestades töödeldavatele andmetele https://www.ria.ee/et/kuberturvalisus/infos Infoturve
määratud ISKE turvaklassi nõudeid. usteemide-turvameetmete-susteem-
iske.html
Krüptograafiliste algoritmide valmisel
https://www.ria.ee/et/ametist/uuringud-
26. lähtuda RIA krüptograafiliste algoritmide Infoturve
analuusid-ulevaated.html
elutsükli uuringutest
API rakendus peab olema turvatud: Denial-
Of-Service (DOS), Cross-Site-Scripting (XSS),
27. Infoturve
Brute Force ja SQL/NoSQL Injection
rünnakute vastu.
API peab sisaldama …/version route-i, mis
tagastab API kehtiva versiooni ja k8s liveness probe
28. liveness probe, mille abil K8s kontrollib Infoturve
API rakenduse „elus“ olekut
Loodavat infosüsteemi majutatakse
29. Riigipilve keskkonda ning sellega tuleb https://riigipilv.ee/ Infra
arvestada arhitektuuri planeerimisel.
Eelistatud on vabavaraliste andmebaaside
30. Infra
platvormide kasutamine. nt PostgreSQL
Rakendusserverite ja andmebaasi teenuste
31. jooksutamise tuleb kasutada Infra
plokksalvestuskeskkonda.
Faililao loomisel eelistatakse
32. objektsalvestuskeskkonna kasutamist S3 Infra
REST API-ga.
Rakenduse logimine peab vastama
https://www.riigiteataja.ee/akt/104012019
33. isikuandmete kaitse seaduses §36 andmekaitse
011
kehtestatule
Automaatseks rakenduse ehitamiseks ja
34. paigaldamiseks kasutame Gitlab CI/CD DevOps
töövooge koos Docker-iga
Rakendused käitatakse Docker
konteinerites Kubernetese klastrites.
35. DevOps
Kubernetes haldamiseks kasutame
Rancher-it.
Kubernetesesse paigalduseks tuleb
rakendusele lisada Helm chart, mis https://helm.sh/ DevOps
36.
arvestab, et rakendust paigaldatakse https://chartmuseum.com/
erinevatesse Rancher projektidesse.
Helm chart peab sialdama paigalduse
juhendit koos rakenduse tööks vajalike
secretite ja configmap muutujate Kvaliteet
37.
kirjeldusega failis: app-readme.md ning
paigalduseks vajalike muutujate kirjeldusi
failis:questions.yml
Rakenduse kasutajaliidese kood peab
olema silutud ning linter „Eslint“ Airbnb
38. https://eslint.org/ Kvaliteet
reeglitele vastav väljund ei tohi sisaldada
vea ning hoiatusteateid.
Rakenduse testimiseks peavad olema
koostatud testilood ning igale testiloole
39. peab olema koostatud sellele vastav https://www.katalon.com/ Kvaliteet
Katalon automaattest. Automaattestid
peavad töötama ilma vigadeta.
Rakendusele html kujul kasutusjuhendit
40. tuleb täiendada ja viia see vastavusse Kvaliteet
rakenduses tehtud muudatustega.
Kasutajajuhendi stiil lähtub e-
41. Kvaliteet
ehituse stiiliraamatust
Kasutusjuhend peab olema kasutusloo
põhine, ehk juhendama kasutajat samm
42. Kvaliteet
sammult iga konkreetse kasutusloo
läbiviimisel
https://unstoppablesoftware.com/5-best-
Kasutusjuhendi kirjutamisel tuleb
43. practices-for-writing-fantastic-software- Kvaliteet
juhinduda:
user-guides/
Kasutajajuhend peab olema
44. kontekstipõhiselt lingitud kasutajaliidese Kvaliteet
elementidega
Rakendusele peab olema koostatud
45. Turve
paigaldusjuhend ja taasteplaan.
Rakenduse loomisel tuleb arvestada
võimalusega muuta see mitmekeelseks (nt
inglise, eesti, vene). Kasutajaliides
46.
Rakendused peavad väljastama logikirjed
Infoturve
47. JSON formaadis.
PAKKUMUS
HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD
Viitenumber: 265770
Hankija: Majandus- ja Kommunikatsiooniministeerium (70003158)
Hange: EHR peamiste töövoogude automaattestide loomine
Pakkumus: 436544
Ettevõtja: Tietoevry Estonia AS (10137025), roll: peapakkuja
Pakkumuse maksumust hinnatakse - Ilma maksudeta
1. Pakkumuse kogumaksumus (ilma käibemaksuta)
Pakkumuse kogumaksumuse väärtuspunktide määramisel saab maksimaalsed väärtuspunktid kõige odavam pakkumus. Teised saavad 70-st võimalikust
punktist sama suhtarvu võrra vähem punkte, mille võrra nende pakkumuse kogumaksumus on kõige odavamast pakkumusest kallim. Väärtuspunktid
arvutatakse: “väärtuspunktid” = “kõige odavam pakkumuse kogumaksumus” / “hinnatava pakkumuse kogumaksumus” ×70
Tüüp ja hindamismeetod: Maksumus, vähim on parim
Osakaal: 70%
Hindamismetoodika kirjeldus: Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt
vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".
Kogus Ühik Ühiku hind Maksumus KM% Maksumus KM-ga Märkused
EUR 10140,000 10140,000 20 12168,000
2. Töö üleandmise tähtaeg kalendripäevades
Töö üleandmise tähtaeg kalendripäevades väärtuspunktide määramisel saab maksimaalsed väärtuspunktid kõige lühema ajalise kestvusega pakkumus. Teised
saavad 30- st võimalikust punktist sama suhtarvu võrra vähem punkte, mille võrra nende pakkumuse töö üleandmise tähtaeg kalendripäevades on kõige
lühemast ajalisest kestvusest pikem.
Väärtuspunktid arvutatakse: “väärtuspunktid” = “kõige lühem töö üleandmise tähtaeg kalendripäevades ”
/ hinnatava pakkumuse töö üleandmise tähtaeg kalendripäevades ” ×30
Tüüp ja hindamismeetod: Kulu, vähim on parim
Osakaal: 30%
Hindamismetoodika kirjeldus: Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt
vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".
Koostatud 14.06.2023 15:20:19 1/2 https://riigihanked.riik.ee/rhr-web/#/procurement/
6007242/general-info
Väärtus Ühik Märkused
35,000 päeva
Pakkumuse maksumus kokku
Maksumus kokku KM-ta: 10140,000
Maksumus kokku KM-ga: 12168,000
Koostatud 14.06.2023 15:20:19 2/2 https://riigihanked.riik.ee/rhr-web/#/procurement/
6007242/general-info
1/1
PAKKUMUS
VASTAVUSTINGIMUSED
Viitenumber: 265770
Hankija: Majandus- ja Kommunikatsiooniministeerium (70003158)
Hange: EHR peamiste töövoogude automaattestide loomine
Pakkumus: 436544
Ettevõtja: Tietoevry Estonia AS (10137025), roll: peapakkuja
HANKEPASSI KINNITUS
Pakkuja kinnitus, et riigihankes ".." koos pakkumusega esitatud hankepassis olevad kinnitused on
jätkuvalt tõesed.
Ettevõtjalt oodatavad vastused:
1. Kas pakkuja kinnitab, et esitatud hankepassis olevad kinnitused on jätkuvalt tõesed?
(Raadionupp valikutega "Jah/Ei")
Vastus: Jah
PAKKUJA JUHTIVISIKUTE LOETELU, KES EI OLE NÄHTAVAD ÄRIREGISTRIST.
Esitada pakkuja poolt volitatud isikute andmed (nimi, isikukood), kellel on volitus seda ettevõtjat
esindada, tema nimel otsuseid teha või teda kontrollida ning kes ei ole hankijale nähtavad
äriregistri B-kaardilt.
Ettevõtjalt oodatavad vastused:
1. Pakkuja esitab volitatud isiku nime(d) ja isikukoodi(d) või kinnituse, et selliseid isikuid
pakkujal ei ole. (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus: Tietoevry Estonia AS määrab volitatud isikuks Vallo Hannus'e, isikukood
37812280264. Volitus on lisatud hankepassi lisadokumentide alla.
Koostatud 14.06.2023 15:20:19
https://riigihanked.riik.ee/rhr-web/#/procurement/6007242/general-info
HANKELEPING nr 4
1.9-21/23-407-1
27.06.2023
Majandus- ja Kommunikatsiooniministeerium, registrikoodiga 70003158, asukohaga Suur-
Ameerika 1, 10122 Tallinn, mida esindab Majandus- ja Kommunikatsiooniministeeriumi
hankekorra alusel kantsler Ahti Kuningas (edaspidi Tellija),
ja
Tietoevry Estonia AS, registrikood 10137025, asukoht Harju maakond, Tallinn, A. H.
Tammsaare tee 47, 11316, mida esindab volituse alusel Vallo Hannus (edaspidi Täitja),
keda edaspidi nimetatakse ka Poolteks, sõlmisid käesoleva hankelepingu (edaspidi Leping)
alljärgnevas:
1. Üldsätted ja Lepingu ese
1.1. Leping sõlmitakse Tellija korraldatud riigihanke „Ehitisregistri arendusteenus 4”,
viitenumber 255236, tulemusena 17.03.2023 sõlmitud raamlepingu nr 1.9-21/23-107-1
ja minikonkursi "EHR peamiste töövoogude automaattestide loomine", viitenumbriga
265770, alusel.
1.2. Lepingu alusel teostatakse töö "EHR peamiste töövoogude automaattestide loomine"
(edaspidi Töö) vastavalt Lepingu Lisale 1 „Lähteülesanne“ ja Lisale 2 „Täitja
pakkumus“.
1.3. Leping on koostatud ühes eksemplaris ja allkirjastatud digitaalselt.
1.4. Käesolev Leping jõustub pärast Lepingu kõigi osapoolte allakirjutamist.
1.5. Käesoleva Lepingu allakirjutamise hetkel on Lepingule lisatud:
1.5.1. Lisa 1 – Lähteülesanne;
1.5.2. Lisa 2 - Täitja pakkumus.
2. Töö teostamise tähtaeg
Täitja kohustub Töö üle andma hiljemalt 35 kalendripäeva jooksul peale Lepingu
allkirjastamist.
3. Töö üleandmine ja tasu suurus
Tellija tasub teostatud ja vastuvõetud tööde eest 10 140 eurot (lisandub käibemaks 20%).
4. Poolte kontaktisikud
4.1.Tellija volitatud esindajaks Lepingu tingimuste täitmisel, kontrollimisel ja vastuvõtmisel
on Liivia Mahlapuu, telefon +3725031675, e-post
[email protected].
4.2.Täitja volitatud esindajaks ja kontaktisikuks on Martin Paukson, telefon +372 5022577,
e-post
[email protected].
2
Tellija: Täitja:
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
Ahti Kuningas Vallo Hannus
kantsler volituse alusel