DAR 0.9 Systembeskrivelse Version 1.3

Transkript

1 DAR 0.9 Systembeskrivelse Version 1.3 DAR 0.9 Systembeskrivelse Side 1 Version 1.3

2 Versionsoversigt Version Dato Beskrivelse Initialer Version 0.0 oprettet som kopi af arkitekturbeskrivelsen JWT Version 1.0 sendt til KOMBIT JWT Ændret afsnit om integration mellem DAR og AWS. - MBBL/KOMBITs tilbagemeldinger indarbejdet - Nyt felt bemærkning på adresseniveau - Valideringsbeskeder tilføjet - Nye tegninger af logisk og fysisk datamodel Vejkode vises ikke med foranstillede 0 er Automatiske statusændringer beskrevet (DAR 0.9.1) - Fremdatering af ikrafttrædelsesdato beskrevet (DAR 0.9.1) samt tilhørende valideringsbeskeder - Tilretning af indledningen JWT JWT JWT DAR 0.9 Systembeskrivelse Side 2 Version 1.3

3 Indholdsfortegnelse 1 Indledning Systemarkitektur Præsentationslag ADK Klient OIO snitflade Applikationslag Service Interface Lag Batch Lag Forretnings Lag Data Access Lag Datalag Dataudveksling med andre systemer Snitflader, som DAR udstiller Snitflade til BBR (DAR udstiller, BBR kalder) Eksterne ajourføringsservices til 3. part Snitflade til AWS suiten Udtræk som DAR leverer Levering af totaludtræk til AWS Data, som modtages og indlæses i DAR Indlæsning af data fra CPR Snitflader, som DAR kalder Snitflade til GST Snitflade til certificeringscenter Snitflade til BBR (BBR udstiller, DAR kalder) Datamodel Den logiske datamodel Adgangspunkt Husnummer Adresse Sagsreference Den fysiske datamodel Nøgler Entiteter med historik (Adgangspunkt, husnummer, adresse, sagsreference) Transaktioner og timestamps Tegning af databasemodellen Andre systemtabeller i den fysiske datamodel Tabeller til CPR data Bitemporale egenskaber Konvertering fra BBR adresser til DAR Forretningslogik Matrikel-adresse relation Adresseforekomsters liv Krav om vejkode og husnummer, samt CPR vejstykke Tilknytning af adresser til entiteter i BBR Statusværdier Sammenhæng mellem statusværdier DAR 0.9 Systembeskrivelse Side 3 Version 1.3

4 5.7 Adressernes entydighed Diverse valideringsregler på entitetsniveau Adgangspunkt Husnummer Adresse Valideringsbeskeder Sikkerhed og brugeradgang Brugeradministration Adgang til webservices Adgang til ADK klienten Samtidighedsaspekter Eksempel 1: Adresseanvendelse i DAR Eksempel 2: BBRs mulighed for at oprette og slette adresser i DAR Logning Produktions- og demomiljø Produktionsmiljø Demomiljø Dokumentation Brugervejledninger Brugervejledning til ADK klienten Snitfladebeskrivelser Snitfladebeskrivelse til AddressV Installationsvejledning DAR 0.9 Systembeskrivelse Side 4 Version 1.3

5 1 Indledning Dette dokument indeholder systemdokumentation for DAR 0.9, som er det nye officielle register over alle adresser i Danmark. Tidligere har BBR - Bygnings- og Boligregistret - været Danmarks officielle adresseregister. Det er ændret siden maj 2015, hvor adressedelen blev udskilt fra BBR og er blevet lagt over i et nyt selvstændigt register - DAR (Danmarks AdresseRegister). Udviklingen af DAR er et led i Grunddataprogrammets målsætning om, at alle data kun skal registreres et sted og at adgangen til dem skal være sikker, enkel og effektiv. Det nye adresseregister skal på længere sigt ikke kun være autoritativt grunddataregister for adresser, men også for navngivne vejnavne, supplerende bynavne m.m. DAR 0.9 kan benyttes til at vedligeholde følgende adressedata: Adgangspunkter, Husnumre og Adresser. DAR kan tilgås via Adresseklienten ADK samt et sæt OIO snitflader, som 3. parts systemer kan benytte. Systemdokumentation indeholder i alt 7 kapitler, som kort beskrives i det følgende. Kapitel 2: Systemarkitektur Kapitlet giver et overblik over DAR 0.9s overordnede løsningsarkitektur, dvs. løsningens væsentlige komponenter og deres indbyrdes sammenhænge. Kapitlet beskriver således præsentationslaget, applikationslaget og datalaget i systemet. Kapitel 3: Dataudveksling med andre systemer I kapitlet beskrives overordnet de relationer og interaktioner, som findes mellem DAR og dets omgivelser. Kapitel 4: Datamodel I kapitlet beskrives DARs logiske og fysiske datamodel samt implementering af bitemporale egenskaber. Kapitel 5: Forretningslogik I kapitlet beskrives DARs forretningslogik, herunder eksisterende forretningsregler samt valideringer. Kapitel 6: Sikkerhed og brugeradgang I kapitlet beskrives, hvordan sikkerhed og brugeradgang håndteres i DAR 0.9 samt Adresseklienten ADK og OIO snitfladerne. Kapitel 7: Samtidighedsaspekter I kapitlet beskrives samtidighedsaspekter i systemet, specielt i forhold til samspillet mellem BBR og DAR. Kapitel 8: Logning I kapitlet beskrives logning samt fejllogning i systemet. Kapitel 9: Produktions- og demomiljø DAR 0.9 Systembeskrivelse Side 5 Version 1.3

6 Kapitlet giver et overblik over løsningens teknologiarkitektur, dvs. der beskrives hvordan de enkelte komponenter i løsningen er fordelt på fysiske servere, både i løsningens produktions- og demomiljø. Kapitel 10: Dokumentation/vejledning/hjælp I kapitlet beskrives kort, hvilken yderligere dokumentation der er udarbejdet i forbindelse med levering af DAR 0.9. DAR 0.9 Systembeskrivelse Side 6 Version 1.3

7 2 Systemarkitektur I dette afsnit beskrives DARs systemarkitektur. Beskrivelsen er givet ud fra et logisk synspunkt og tager ikke stilling til, hvordan de enkelte komponenter er fordelt på fysiske maskiner og databaser. Denne fordeling er beskrevet i kapitel 9 Produktions- og demomiljø. Systemarkitekturen (et overblik) for DAR fremgår af nedenstående figur. DAR Autentifikation ASP.NET MVC Website ADK 0.9 OIO XML Service Gateway Service Agenter Service Agenter DAR Service Interface Lag Batch Service Contract Service Adapter Windows Services/Scheduled tasks Forretnings Lag Forretnings Logik Forretnings Entiteter Data Access Lag Data Access Logik Service Agenter Enitity framework SQL Server DAR Kald til andre systemer - BBR -GST Figur 1 Systemarkitektur DAR 0.9 DAR 0.9 Systembeskrivelse Side 7 Version 1.3

8 Overordnet består DAR af følgende 3 lag, som er beskrevet nedenfor: Præsentationslag Applikationslag Datalag 2.1 Præsentationslag Præsentationslaget udstiller en browserbaseret brugergrænseflade, ADK klienten, og en webservicebaseret snitflade til 3. parts systemer, baseret på OIOXML ADK Klient ADK er én måde at tilgå DAR 0.9 på. ADK giver mulighed for at oprette og vedligeholde adgangspunkter, husnumre og adresser. En mere detaljeret beskrivelse af ADK findes i brugervejledning for ADK Adresseklient (afsnit Brugervejledning til ADK klienten). ADK Adresseklienten er bygget på Microsofts ASP.NET MVC 4 og følger Microsofts standard skabelon for MVC projekter. Applikationen er opbygget efter SPA princippet (Single Page Application). Model/View/Controller Klient projektets model-lag udgøres af et sæt viewmodels. Hovedparten af disse er bygget på baggrund af de entiteter, der er defineret i forretningslaget og indeholder alle de samme data. Derudover har de enkelte viewmodels egenskaber og metoder der kun bruges til at generere views i klienten. Kommunikation mellem klienten og forretningslaget foregår via WCF webservices og disse benytter sig af forretningslagets entiteter til at strukturere og lagre data til transport. Når der skal indlæses en entitet fra forretningslaget skal denne omformes til klientens viewmodels og når de indberettede data skal lagres skal klientens viewmodels omformes tilbage til noget forretningslaget kan bruge. Til automatisering af denne proces benyttes en open-source komponent kaldet Automapper (ref. automapper.org). Klienten benytter én enkelt master page (/shared/_layout.cshtml) som ramme til alle views. Alle generelle scripts og applikationens stylesheets bliver lagt ind på denne side, mens viewspecifikke scripts bliver koblet til på de underliggende views der bruger dem med erklæring. Hvert område i klienten har sine egne controller, og alle controller er bygget over en base class controller (/Controllers/BaseController.cs), der definerer et minimum af funktionalitet der er tilgængeligt alle steder i applikationen, f.eks. generel fejlhåndtering. Caching Når klient applikationen starter op gemmes udvalgte data i en cache for at undgå stor belastning af båndbredden. Alle elementer i cachen har en levetid på 12 timer og fornyes herefter. Der caches følgende data på webserveren: Vejliste Kommuneliste DAR 0.9 Systembeskrivelse Side 8 Version 1.3

9 Landsejerlavsliste Lister til vejnavn og matrikel lookup En rettelse af disse data vil først slå igennem når cachens levetid er nået eller hvis webhomet genstartes via IIS en (Internet Information Services) OIO snitflade OIO snitfladen er den anden måde at tilgå DAR 0.9 på. 3. parts systemer kan benytte en OIO snitflade til at opdatere adressedata. BBR benytter ligeledes en OIO snitflade til at kalde DAR. Hvis en adresseanvender kun har behov for at læse adressedata, henvises den til AWS suiten. OIO snitfladen er udarbejdet efter OWSA Model T standarden (OIO Web Service Arkitektur model Transportbaseret sikkerhed). Modellen bygger på SOAP, HTTPS, OCES certifikater og OIOXML. Se afsnit 3.1 Snitflader, som DAR udstillerfor yderligere detaljer for de udstillede OIO snitflader. 2.2 Applikationslag Applikationslaget er baseret på Microsoft.NET platform. Applikationslaget er implementeret som en serviceorienteret arkitektur og udstiller forretningslogikken som services Service Interface Lag De udstillede services er Windows Communication Foundation Services (WCF). WCF er Microsofts framework til at bygge service-orienterede applikationer. Både ADK adresseklienten, OIOXML snitfladerne og de interne services mellem BBR og DAR benytter de samme WCF services Batch Lag For at indlæse data fra CPR eller danne totaludtræk til AWS benyttes Windows service hhv. scheduled tasks som tilgår DARs Data Access Lag Forretnings Lag Forretningslaget definerer forrentningsobjekter og alt forretningslogik. Se afsnit 4.1 Den logiske datamodel for en detaljeret beskrivelse af forretningsobjekterne samt kapitel 5 Forretningslogik for en beskrivelse af forretningslogikken inkl. valideringsreglerne Data Access Lag Data Access komponenten sørger for mapningen mellem database objekter og forretningslagets business objekter. DARs Data Access Logik bruger Entity Framework til at mappe database tabeller til business objekter, ligeledes foregår kommunikationen mellem DARs Data Access Logik og databasen igennem Entity Framework. DAR 0.9 Systembeskrivelse Side 9 Version 1.3

10 2.3 Datalag Datalaget er ligesom resten af systemet bygget på Microsoft teknologier og kører derfor på Windows Server med SQL Server. DAR 0.9 Systembeskrivelse Side 10 Version 1.3

11 3 Dataudveksling med andre systemer Dette afsnit ser på hvordan DAR på overordnet niveau interagerer med andre systemer. Nedenstående figur viser et overblik over DARs sammenhæng med forskellige andre systemer. De blå cirkler symboliserer hver et system, som DAR har en afhængighed til Pilene i tegningen symboliser dataflowet mellem DAR og disse systemer. Det kan forekomme, at DAR har flere snitflader til et system. CPR GST Koordinater til adresser Vejstykker mm. Ekstern OIO snitflade Ajourføringsservices(OIO) DAR AWS Adresse data i ny datamodel BBR DAR interne services(oio) BBR Hent certifikater Certificeringsce nter Figur 2 Kontekstdiagram for DAR I de følgende afsnit er hver enkelt snitflade listet. Afsnit Snitflader som DAR udstiller lister alle snitflader, som DAR udstiller og som således kan kaldes af andre systemer. DAR 0.9 Systembeskrivelse Side 11 Version 1.3

12 Afsnit Udtræk som DAR leverer lister alle udtræk, som DAR leverer. Afsnit Data som modtages og indlæses i DAR lister alle snitflader, hvor der indlæses dataudtræk fra andre systemer. Afsnit Snitflader som DAR kalder lister alle snitflader, som DAR kalder online. 3.1 Snitflader, som DAR udstiller System Intern OIO snitflade til BBR OIO snitflade til 3. part Snitflade til AWS BBR kan oprette og slette adresser i DAR. 3. part kan benytte OIO snitfladen til at opdatere adressedata. AWS kan kalde en snitflade for at hente adresseopdateringer Snitflade til BBR (DAR udstiller, BBR kalder) Denne interne snitflade mellem BBR og DAR bestå af et antal helt specifikke services, som udelukkende benyttes af BBR/DAR. Disse services udstilles ikke til andre. Disse services er udarbejdet som sikre webservices baseret på TLS og certifikater, så BBR 1.7 og DAR 0.9 kan driftsafvikles i separate miljøer. Disse services er udarbejdet efter OWSA Model T (OIO Web Service Arkitektur model Transportbaseret sikkerhed). Når enheder slettes i BBR med en enhedsadresse, som ikke benyttes på andre BBR entiteter, slettes adressen i DAR, hvis det ikke er den sidste enhedsadresse til en adgangsadresse. Når enheder oprettes i BBR med en enhedsadresse, som ikke findes i forvejen, bliver adressen automatisk oprettet i DAR, hvis brugeren har den nødvendige rolle. Der er således identificeret følgende interne services som DAR udstiller til BBR: AdresseOpret AdresseSlet Når den sidste adresse under et adgangspunkt slettes, slettes husnummeret ligeledes. Adgangspunktet slettes ikke. Det er på samme måde forretningslaget virker når en adresse slettes igennem OIO snitfladen eller ADK Adresseklienten. Der oprettes en bruger i BBR, som foretager alle kaldene for alle kommuner til den interne snitflade i DAR. Brugeren skal som den eneste have tilknyttet rollen DARKaldfraBBR, som giver BBR lov til at kalde DARs interne services. Det er denne BBR bruger, som kommer til at stå som bruger for disse opdateringer i DAR, dvs. i DAR vil man ikke kunne identificere den enkelte kommunale bruger Eksterne ajourføringsservices til 3. part I DAR 0.9 implementeres nye ajourføringsservices baseret på den del af den ny informationsmodel, som implementeres i DAR 0.9 dvs. entiteterne Adgangspunkt, Husnummer og Adresse. Disse services udarbejdes efter OWSA Model T standarden. Der er i DAR 0.9 ikke implementeret ajourføringsservices til sagsreferencer, idet sagsreferencebegrebet i DAR 0.9 ikke svarer til det kommende sagsreferencebegreb i DAR 1.0. DAR 0.9 Systembeskrivelse Side 12 Version 1.3

13 Følgende services er udarbejdet: AccessPointCreate AccessPointDelete AccessPointGetById AccessPointUpdate HouseNumberCreate HouseNumberDelete HouseNumberGetById HouseNumberUpdate AddressCreate AddressDelete AddressGetById AddressUpdate Der er valgt at udarbejde simple services med CRUD funktionerne, som forventes at understøtte behovet for services. En mere detaljeret beskrivelse findes ved at findes i snitfladebskrivelsen (afsnit Snitfladebeskrivelse til AddressV1) Snitflade til AWS suiten DAR 0.9 skal levere adresser til AWS i henhold til den nye datamodel med adgangspunkter, husnumre og adresser. AWS mapper efterfølgende fra den nye model til den gamle adresse datamodel og leverer efterfølgende adresser i den gamle datamodel til BBR. Der findes to snitflader mellem DAR 0.9 og AWS: Webservice til Realtidsopdatering af adresser fra DAR 0.9 til AWS Fuldstændigt adresseudtræk fra DAR 0.9 til AWS Webservicen er beskrevet nedenfor, mens totaludtrækket er beskrevet i afsnit Levering af totaludtræk til AWS. Webservice til AWS Interfacet til AWS implementeres som en webservice som DAR udstiller til AWS. AWS henter således selv opdateringer til Adgangspunkter, Husnumre og Adresser. Udover dette hentes ændringer til vejnavne via DAR (vejnavnene vedligeholdes dog i et register der vedligeholdes af CPR). For at modtage ændringer til adgangspunkter kalder AWS webservicen med parametrene dato fra og dato til. F.eks. http(s)://dar-kommune.dk/services/hentadgangspunkt?fra= :10:50&til= :09:50. Webservicen er beskyttet ved hjælp af IP-begrænsning. Webservicen som udstiller adresseoplysninger til AWS indeholder følgende 4 metoder: HentAdresse(DateTime datefra, DateTime til); DAR 0.9 Systembeskrivelse Side 13 Version 1.3

14 HentHusnummer(DateTime datefra, DateTime til); HentAdgangspunkt(DateTime datefra, DateTime til); HentVejnavn(DateTime datefra, DateTime til); Levering af hændelser Hændelser levereres via HTTP protokollen og der anvendes JSON som transportformat. Hændelser leveres ved at DAR udstiller en webservice som AWS kalder med et HTTP Get request til en angiven URL, f.eks. http(s)://dar-kommune.dk/services/hentadresse?fra=x&til=x. Leveringen af hændelser skal overholde følgende: Overførslen af hændelser beskyttes ved hjælp af IP-begrænsning Hvert request indeholder en liste af hændelser for hver entitetstype (adgangspunkt, adresse etc.). Der vil højest kunne returneres entiteter i en forespørgsel. Hvis resultatet indeholder mere end entiteter returneres de første entiteter i en ordnet rækkefølge efter opdateret timestamp. DAR garanterer at der maksimalt findes entiteter med samme timestamp i databasen. DAR garanterer at data vil være tilgængelig for AWS minimum 60 sekunder efter at data er oprettet i DAR. Der er ikke krav til at entiteter som hører sammen sendes i samme transaktion. Hverken med hensyn til foreign key constraints mellem typer eller relationer mellem versioner inden for samme type. Vejnavn, postnummer, postdistrikt og supplerende-bynavn leveres i 4 komplette udtræk en gang dagligt via FTP og AWS sørger selv for at sammenkoble disse parametre. Metode og struktur Interfacet til AWS implementeres som en Webservice som DAR udstiller til AWS. For at modtage ændringer til adgangspunkter kalder AWS webservisen med parametrene dato fra og dato til. Fx http(s)://dar-kommune.dk/services/hentadgangspunkt?fra= t12:16: :00&til= t12:16: :00. Metoderne og deres struktur er beskrevet for de enkeltvis nedenfor. I modsætning til den nuværende service, fortæller den nye service ikke hvad der skal ske med entiteten. I stedet medsendes en statuskode svarende til status i DAR og det vil så være op til AWS at håndtere hvad der skal ske med entiteten ud fra dens status. Fx Hvis et adgangspunkt har statuskode 2 (Nedlagt) betyder dette at entiteten skal slettes mens statuskode 1 (Gældende) betyder at der skal foretages en ændring eller at entiteten skal oprettes hvis den ikke allerede findes hos AWS. DAR 0.9 Systembeskrivelse Side 14 Version 1.3

15 HentAdresse Metoden HentAdresse returnerer en liste over adresser, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over adresser med følgende struktur: (JSON)[{ 'versionid':'4e3df510-1e3e-408c-b389-c72b3f93ccfd', 'id':'0a3f50b b8-e ba298018', 'husnummerid':'0a3f5088-ec8b-32b8-e ba298018', 'statuskode':'1', 'etagebetegnelse':'st', 'doerbetegnelse':'', 'esdhreference':'', 'journalnummer':'e ba298018', 'kildekode':'1', 'ikrafttraedelsesdato': ' T12:16: :00', 'registreringstart': ' T12:16: :00', 'registreringslut':'', 'virkningstart': ' T12:16: :00', 'virkningslut:'', }, ] Statuskoden angiver om adressen er Gældende (1), Nedlagt (2), Foreløbig (3) eller Henlagt (4). HentHusnummer Metoden HentHusnummer returnerer en liste af husnumre, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over husnumre med følgende struktur: (JSON)[{ 'versionid':'b0a5468e-777d-4d97-8c25-325fbdc66c94', 'id':'0a3f5088-ec87-32b8-e ba298018', 'adgangspunktid':'0a3f5088-ec87-32b8-e ba298018', 'registreringstart': ' T12:16: :00', 'registreringslut':'', 'virkningstart': ' T12:16: :00', 'virkningslut':'', 'vejkode':'11', 'husnummer':'003', 'statuskode':'1', 'kildekode':'1', 'ikrafttraedelsesdato': ' T12:16: :00', }, ] Statuskoden angiver om husnummeret er Gældende (1), Nedlagt (2), Foreløbig (3) eller Henlagt (4). HentAdgangspunkt Metoden HentAdgangspunkt returnerer en liste af adgangspunkter, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over adgangspunkter med følgende struktur: (JSON)[{ 'versionid':'7c13ace4-1d a9ae-50fbcead300b', 'id':'0a3f5088-ec87-32b8-e ba298018', 'statuskode':'1', 'kildekode':'5', 'nord':' ', 'oest':' ', 'tekniskstandard':'tk', 'noejagtighedsklasse':'a', 'retning':'234', 'placering':'5', DAR 0.9 Systembeskrivelse Side 15 Version 1.3

16 'kommunenummer':'461', 'esdhreference':'', 'journalnummer':'', 'revisionsdato': ' T12:16: :00', 'registreringstart': ' T12:16: :00', 'registreringslut':'', 'virkningstart': ' T12:16: :00', 'virkningslut':'', }, ] Statuskoden angiver om adgangspunktet er Gældende (1), Nedlagt (2), Foreløbig (3) eller Henlagt (4). HentVejnavn Metoden HentVejnavn returnerer en liste af vejnavne, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over vejnavne med følgende struktur: (JSON)[{ 'kommunekode':'101', 'vejkode':'1010', 'navn':'niels Bohrs Alle', 'adresseringsnavn':'niels Bohrs Alle', 'oprettimastamp': ' T12:16: :00', 'aendringstimestamp': ' T12:16: :00', 'ophoerttimestamp': ' T12:16: :00' }, ] DAR 0.9 skal ikke levere ejendomsnummer til AWS. AWS skal have oplysninger om ejendomsnummer og matrikeloplysninger fra OIS eller GST. Formatering Datoformatet for snitfladen mellem DAR og AWS er ISO8601 med roundtrip formatspecifier (Ex T12:16: :00) Felter med værdien null, angives også som null i json formatet. For decimaltal anvendes punktun som decimal separator. Prefixede foranstående 0 og foranstående samt efterstillede white-space fjernes. 3.2 Udtræk som DAR leverer System AWS - totaludtræk Data DAR leverer en gang i døgnet et totaludtræk til AWS en Levering af totaludtræk til AWS DAR 0.9 leverer fuldstændige adresseudtræk til AWS efter samme principper som BBR i dag leverer fuldstændige adresseudtræk til AWS. Dannelse af udtrækket sker via en scheduled task. DAR sender entiteter med alle statusser til AWS. DAR 0.9 Systembeskrivelse Side 16 Version 1.3

17 DAR 0.9 leverer adresser til AWS i henhold til den nye datamodel med adgangspunkter, husnumre, adresser samt vejnavne. AWS mapper fra den nye til den gamle adresse datamodel og leverer efterfølgende adresser i den gamle datamodel til BBR. AWS Udtræks-scheduler Udtræks-scheduleren leverer et komplet udtræk af samtlige adresser, husnumre, adgangspunkter samt vejnavne, supplerende-bynavn, postdistrikt og vejstykke som vedligeholdes af CPR. Udtrækkene leveres komplet i en fil for hver entitetstype (Adresse, Husnummer, Adgangspunkt, Vejnavn, Supplerendebynavn, Postdistrikt og Vejstykke) og pakkes herefter til en zip-fil (AWS_dato.zip fx AWS_ zip). Zip-filen uploades efterfølgende til den nuværende FTP server hvor AWS har ansvaret for løbende at fjerne filerne. De enkelte filer vil blive gemt med følgende filnavn: Adresse.csv Husnummer.csv Adgangspunkt.csv Vejnavn.csv Supplerendebynavn.csv Vejstykke.csv Postdistrikt.csv Strukturen for de enkelte fil-typer vises på de følgende sider Adresse 'versionid [uniqueidentifier]'; 'id [uniqueidentifier]'; 'husnummerid [uniqueidentifier]'; 'statuskode [tinyint]'; 'etagebetegnelse [char(2)]'; 'doerbetegnelse [char(4)]'; 'esdhreference [varchar(200)]'; 'journalnummer [varchar(60)]'; 'kildekode [tinyint, null]'; 'ikrafttraedelsesdato [datetime, nul]'; 'registreringstart [datetime]'; 'registreringslut [datetime, null]'; 'virkningstart [datetime, null]'; 'virkningslut [datetime, null]'; Husnummer 'versionid [uniqueidentifier]'; 'id [uniqueidentifier]'; 'adgangspunktid [uniqueidentifier]'; 'registreringstart [datetime]'; 'registreringslut [datetime, null]'; 'virkningstart [datetime, null]'; 'virkningslut [datetime, null]'; 'vejkode [smallint]'; 'husnummer [varchar(4)]'; 'statuskode [tinyint]'; DAR 0.9 Systembeskrivelse Side 17 Version 1.3

18 'kildekode [tinyint]'; 'ikrafttraedelsesdato [datetime, null]' Adgangspunkt 'versionid [uniqueidentifier]'; 'id [uniqueidentifier]'; 'statuskode [tinyint]'; 'kildekode [tinyint]'; 'nord [decimal(18,2)]'; 'oest [decimal(18,2)]'; 'tekniskstandard [char(2)]'; 'noejagtighedsklasse [char(1)]'; 'retning [decimal(18,2)]'; 'placering [tinyint, null]'; 'kommunenummer [smallint]'; 'esdhreference [varchar(200)]'; 'journalnummer [varchar(60)]'; 'revisionsdato [datetime, null]'; 'registreringstart [datetime]'; 'registreringslut [datetime, null]'; 'virkningstart [datetime, null]'; 'virkningslut [datetime, null]' Vejnavn 'kommunekode [smallint]'; 'vejkode [smallint]'; 'navn [varchar(40)]'; 'adresseringsnavn [varchar(20)]'; 'oprettimestamp [datetime, null]'; 'aendringstimestamp [datetime]'; 'ophoerttimestamp [datetime, null]' Supplerendebynavn 'kommunekode [smallint]'; 'vejkode [smallint]'; 'byhusnummerfra [char(4)]'; 'byhusnummertil [char(4)]'; 'byvejside [char(1)]'; 'bynavn [varchar(50)]'; 'oprettimestamp [datetime]'; 'aendringstimestamp [datetime]'; 'ophoerttimestamp [datetime, null]' Postdistrikt 'postdistriktnummer [smallint]' 'postdistriktnavn [varchar(20)]'; 'oprettimestamp [datetime]'; 'aendringstimestamp [datetime]'; 'ophoerttimestamp [datetime, null]' Vejstykke 'kommunekode [smallint]'; 'vejkode [smallint]'; 'byhusnummerfra [char(4)]'; 'byhusnummertil [char(4)]'; 'vejstykkeside [char(1)]'; 'postdistriktnummer [smallint]'; 'oprettimestamp [datetime]'; 'aendringstimestamp [datetime]'; 'ophoerttimestamp [datetime, null]' DAR 0.9 Systembeskrivelse Side 18 Version 1.3

19 Specifikation af CSV format Alt data pakkes ind i qoutes, hvis data i forvejen indeholder qoutes, escapes disse med karakteren \. Prefixede foranstående 0 og foranstående samt efterstillede white-space fjernes. Special-karakterer som newline og carriage return fjernes fra csv-filen. Hvis felter indeholder null-værdier angives der ingen karakterer. CSV filen leveres i formatet UTF-8. For decimaltal anvendes punktun som decimal separator. 3.3 Data, som modtages og indlæses i DAR System CPR veje, vejstykker, vejnavne m.m. Data DAR indlæser data, som modtages fra CPR (en gang dagligt) Indlæsning af data fra CPR Der indlæses dagligt opdateringer fra CPR omkring veje, vejstykker, postdistrikter, bynavne og lokalitet i DAR 0.9. Opdatering sker ved at hente ajourføringsudtræk fra CPR og opdatere relevante tabeller i DAR, herunder attributter på Husnummer tabellen. Indlæsningen sker via en Windows service. 3.4 Snitflader, som DAR kalder System GST geodata til Bygninger, Teknisk anlæg og Adresser Certificeringscenter BBR Data DAR implementeres henter geodata for adresser i GST: - DAR henter koordinater til en matrikel - DAR henter matrikel til givne koordinater - DAR tjekker om en koordinat ligger indenfor kommunegrænsen - DAR henter matrikler ud fra et ejendomsnummer - DAR henter ejendomsnummeret ud fra en matrikel Denne snitflade bruges i forbindelse med autentifikation af brugere ved logon med certifikat (medarbejder-, funktions- og virksomhedscertifikater). DAR kalder BBR for at - Tjekke om en adresse hhv. et husnummer er i brug i BBR - Autentificere brugeren Snitflade til GST Snitflade i DAR, som henter geodata for Adresser: DAR henter koordinater til en matrikel DAR 0.9 Systembeskrivelse Side 19 Version 1.3

20 DAR henter matrikel til givne koordinater DAR verificerer om et angivet punkt ligger inden for kommunens grænser. DAR henter matrikler ud fra et ejendomsnummer DAR henter ejendomsnummeret ud fra en matrikel Snitflade til certificeringscenter DAR autentificerer brugere ved logon med certifikat (medarbejder-, funktions- og virksomhedscertifikater) Snitflade til BBR (BBR udstiller, DAR kalder) DAR benytter BBRs brugere og BBRs brugeradministration til at oprette brugere og tildele dem roller. DAR skal autentificere brugere ved at kalde en intern snitflade i BBR 1.7. Hvis oplysninger kan godkendes, returneres brugerens roller til DAR. Idet BBR skal håndtere brugeradministration for DAR, skal der implementeres en snitflade, som gør det muligt for DAR at hente brugerrettigheder i BBR. Se afsnit Sikkerhed og brugeradgang for yderligere detaljer. En adgangsadresse/enhedsadresse kan ikke slettes, hvis den benyttes i bygning/bolig delen i BBR. På adressefanen er der et flueben, som angiver, om en adgangsadresse/enhedsadresse benyttes i bygning/bolig delen i BBR Der er således identificeret følgende interne services som BBR udstiller: EnhedsadresseIBrug AdgangsadresseIBrug Services til autentifikation og autorisation af en bruger Disse services udarbejdes som sikre webservices baseret på TLS og certifikater, så BBR 1.7 og DAR 0.9 kan driftsafvikles i separate miljøer. Disse services udarbejdes efter OWSA Model T (OIO Web Service Arkitektur model Transportbaseret sikkerhed). Der oprettes en bruger i DAR, som foretager alle kaldene for alle kommuner til den interne snitflade i BBR. Brugeren skal som den eneste have tilknyttet rollen BBRKaldfraDAR, som giver DAR lov til at kalde BBRs interne services. DAR 0.9 Systembeskrivelse Side 20 Version 1.3

21 4 Datamodel I dette kapitel beskrives informationsarkitekturen i løsningen. I afsnit 4.1 beskrives den logiske datamodel. I afsnit 4.2 beskrives den fysiske datamodel. I afsnit 4.3 beskrives kort den gennemførte konvertering af adressedata fra BBR til DAR Den logiske datamodel I dette afsnit beskrives løsningens logiske datamodel. Nedenstående figur viser DAR 0.9s informationsmodel, dvs. modellens entiteter og deres indbyrdes relationer set ud fra et logisk synspunkt Se afsnit til for en oversigt over alle felter for de vigtigste entiteter i den logiske datamodel. DAR 0.9 Systembeskrivelse Side 21 Version 1.3

22 Figur 3 Informationsmodel for DAR 0.9 DAR 0.9 Systembeskrivelse Side 22 Version 1.3

23 Den logiske datamodel har følgende entiteter: Adgangspunkt: Et adgangspunkt er defineret som et geografisk punkt i terrænplan, som udpeger en særskilt adgang fra en navngiven vej og ind på et areal eller ind i en BBR-bygning. Adgangspunktet svarer til geometripunktet i den hidtidige BBR Adresse model. Adresse: En adresse er defineret som en struktureret betegnelse, der angiver en særskilt adgang til et areal, en bygning eller en del af en bygning efter reglerne i adressebekendtgørelsen. I en bygning kan flere adresser (med forskellig etage og dørbetegnelse) dele det samme adgangspunkt. Husnummer: Alle adresser, som ligger under et adgangspunkt, deler husnummeret. Husnummeret indgår således i den samlede og fuldstændige adressebetegnelse for hver af disse. Husnummerbetegnelsen består af et tal 1-999, som evt. kan være efterfulgt af et stort bogstav A..Z. På grund af risikoen for forveksling må bogstaverne I, J, O og Q ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Husnummeret svarer til adgangsadressen i den hidtidige BBR Adresse model. Sagsreference: En sagsreference er en samling af adresseobjekter, der berøres af den samme opdatering af adresseregisteret. En sagsreference er således en slags paraply, som samler referencer til et antal entiteter, og en sagsreference giver på den måde et samlet overblik over de adresseobjekter, der indgår i en opdatering af adressedata. Man kan forestille sig det på den måde, at det er referencen, men ikke selve entiteten, der ligger i sagen. Det betyder også, at hvis entiteten ændres udenom sagen, vil det være synligt i sagen. Ud over at en sagsreference samler adresseobjekter, giver sagsreferencen mulighed for at registrere oplysninger på sagsniveau. Det er f.eks. sagsnummer, titel, et dokument, en kommentar fra ejeren eller en kommentar fra sagsbehandleren. Både foreløbige og gældende adgangspunkter kan ligge i en sag. Adgangspunktsagsreference: For hvert adgangspunkt i en sag kan der tilknyttes nogle sagsrelevante oplysninger, dvs. oplysninger, som kun er relevante i forbindelse med sagen, men ikke efterfølgende, når sagen er afsluttet. Det kan f.eks. være en angivelse af, hvilken slags anvendelse adgangspunktet har, et dokument som viser beliggenheden eller en kommentar fra ejeren. Dokument: Der kan knyttes dokumenter til en sagsreference og til en adgangspunktsagsreference. Husnummersagsreference: I DAR 0.9 kan du kun knytte adgangspunkter til en sagsreference og denne entitet benyttes derfor ikke endnu. Adressesagsreference: I DAR 0.9 kan du kun knytte adgangspunkter til en sagsreference og denne entitet benyttes derfor ikke endnu. De følgende afsnit beskriver de enkelte attributter på entiteterne adgangspunkt, husnummer, adresse og sagsreference. Desuden beskrives forretningsregler for de enkelte felter. DAR 0.9 Systembeskrivelse Side 23 Version 1.3

24 4.1.1 Adgangspunkt Felt Id Beskrivelse UUID Feltet sættes automatisk af systemet. Status Status Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Kommunenummer ESDH-ref Journal nr. Ejendomsnummer Kommunenummer ESDH Reference til kommunens eget ESDH system (max 200 tegn) Journalnummer (max 60 tegn) Ejendomsnummer Feltet er ikke en del af den fysiske datamodel. Data hentes fra GST ud fra koordinaterne. Matrikel Matrikel (Landsejerlav og matrikelnummer) Felterne er ikke en del af den fysiske datamodel. Data hentes fra GST ud fra koordinaterne. Oprettelsesdato Oprettelsesdato for adgangspunkt. Feltet sættes automatisk af systemet. Senest ændret dato Seneste ændringsdato for adgangspunkt. Feltet sættes automatisk af systemet. Information udledes af Registreringstid. Revisionsdato Revisionsdato Dato for seneste revision (godkendelse eller ændring) af geometridata (felterne x-koordinat, y-koordinat, retning). Placering Placering af husnummer i forhold til indsætningspunktet i kortet. Placeringskode (tekstjustering) af husnr.; kodesæt 1-9, jf. DSFL Kilde Kilde til geometri Kodeværdier: DAR 0.9 Systembeskrivelse Side 24 Version 1.3

25 1 - Oprettet maskinelt på baggrund af teknisk kort 2 - Oprettet maskinelt på baggrund af matrikelnummer tyngdepunkt 3 - Eksternt indberettet af konsulent på vegne af kommunen 4 - Eksternt indberettet af kommunes GIS- eller kortkontor o.l. 5 - Oprettet af kommunens BBR- eller adresseansvarlige (teknisk forvaltning) Teknisk standard Kode for teknisk standard for geometridata Kodeværdier: TD - Husnummer placeres 3 meter inde i bygningen ved det sted hvor indgangsdør e.l. skønnes placeret, eventuelt med en retningsvinkel der er orienteret i forhold til den adressegivende vejs vejmidte TK - Udtrykkelig TK-standard: 3 meter inde i bygning, midt for længste side mod vej og roteret TN - Alm. teknisk standard: bygningstyngdepunkt eller blot i bygning og roteret UF - Uspecificeret/foreløbig; ikke nødvendigvis placeret i bygning, ikke nødvendigvis roteret Nøjagtighedsklasse Nøjagtighedsklasse for adressens koordinater Kodeværdier: Adgangspunktretning Retningsvinkel A - Absolutte adressekoordinater - stedfæstelsen bør pege på det rigtige objekt, jf. specifik f. teknisk kort B - Beregnet koordinatsæt, foreløbig, omtrentlig stedfæstelse U - Adresse uden koordinater - stedfæstelse ukendt Retningsvinkel for tekst i gon, jf. TK-standard: Koordinat (x) X-koordinat i UTM ETRS89 Zone 32 Koordinat (y) Y-koordinat i UTM ETRS89 Zone 32 FindesDARsag Boolean True hvis adgangspunktet ligger i en sagsreference. Feltet findes ikke i den fysiske database, men bliver beregnet. LiggerIKommunen Boolean True hvis adgangspunktet ligger indenfor kommunegrænsen. Feltet findes ikke i den fysiske database, men bliver beregnet vedhjælp af kald til GST. Virkningstid Se afsnit Bitemporale egenskaber DAR 0.9 Systembeskrivelse Side 25 Version 1.3

26 Registreringstid Se afsnit Bitemporale egenskaber Husnummer Felt Id Beskrivelse UUID Feltet sættes automatisk af systemet. AdgangspunktId Status Id for adgangspunktet som husnummeret referer til Status Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Oprettelsesdato Oprettelsesdato for husnummeret. Datoen sættes automatisk. Senest ændret dato Seneste ændringsdato for husnummeret. Datoen sættes automatisk. Information udledes af Registreringstid. Ikrafttrædelsesdato Dato for husnummerets ikrafttrædelse. Ikrafttrædelsesdato er normalt den dato, hvor husnummeret ændrer status fra Foreløbig til Gældende. Vejkode + vejnavn Husnummer + bogstav Vejkode og vejnavn. Husnummerbetegnelse. Et husnummer består af indtil fire tegn. Et husnummer består altid af et tal i intervallet fra 1 til 999 som eventuelt kan være suppleret af ét stort bogstav fra A til Z. På grund af risikoen for forveksling må bogstaverne I, J, O og Q dog ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Feltet kan indberettes med store og små bogstaver, men bliver gemt i databasen med store bogstaver. Postnummer Postnummer Feltet opdateres automatisk ud fra vejkode og husnummeret. Postdistrikt/navn Postdistrikt DAR 0.9 Systembeskrivelse Side 26 Version 1.3

27 Feltet opdateres automatisk ud fra vejkode og husnummeret. Suppl. bynavn Supplerende bynavn Feltet opdateres automatisk ud fra vejkode og husnummeret. Kilde Kilde til husnummeret Kodeværdier: 1 - Oprettet af kommunen iht. adressecirkulæret 2 - Oplysning fra ejer 3 - Oplysning fra teknisk kort 4 - Oplysning fra KRR Manuel 5 - Oplysning fra KRR Administrativ 6 - Oplysning fra ESR 7 - Oplysning fra CPR 8 - Oplysning fra CVR 9 - Oplysning fra post 10 - Oplysning fra 112 o.l Oplysning fra anden kilde FindesDARsag Boolean True hvis husnummeret ligger i en sagsreference. Feltet findes ikke i den fysiske database, men bliver beregnet. IBrugIBBR Boolean True hvis husnummeret (adgangsadressen) benyttes i BBR. Feltet findes ikke i den fysiske database, men bliver beregnet. Virkningstid Registreringstid Se afsnit Bitemporale egenskaber Se afsnit Bitemporale egenskaber Adresse Felt Id Beskrivelse UUID Feltet sættes automatisk af systemet. HusnummerId Status Husnummeret som adressen referer til. Status Kodeværdier: 1- Gældende 2- Nedlagt DAR 0.9 Systembeskrivelse Side 27 Version 1.3

28 3- Foreløbig 4- Henlagt Etagebetegnelse Korrekte etagebetegnelse kan være følgende BLANK ST Stuen KL Kælder Feltet kan indberettes med store og små bogstaver, men bliver gemt i databasen med store bogstaver. Dørbetegnelse Side/dørnummer kan indeholde: BLANK TV, MF, TH, , bogstaver,kombinationer af bogstaver (A-Z) og tal, samt tegnene skråstreg og bindestreg. Feltet kan indberettes med store og små bogstaver, men bliver gemt i databasen med store bogstaver. ESDH reference Journal Bemærkning Kilde ESDH Reference til kommunens eget ESDH system (max 200 tegn) Journalnummer (max 60 tegn) Bemærkning til adressen (max 200 tegn) Kilde til adressen Kodeværdier: Ikrafttrædelsesdato Ikrafttrædelsesdato 1 - Oprettet af kommunen iht. adressecirkulæret 2 - Oplysning fra ejer 3 - Oplysning fra teknisk kort 4 - Oplysning fra KRR Manuel 5 - Oplysning fra KRR Administrativ 6 - Oplysning fra ESR 7 - Oplysning fra CPR 8 - Oplysning fra CVR 9 - Oplysning fra post 10 - Oplysning fra 112 o.l Oplysning fra anden kilde Ikrafttrædelsesdato er normalt den dato, hvor adressen ændrer status fra Foreløbig til Gældende. Oprettelsesdato Oprettelsesdato Datoen sættes automatisk. DAR 0.9 Systembeskrivelse Side 28 Version 1.3

29 Senest ændret dato Seneste ændringsdato Datoen sættes automatisk. Information udledes af Registreringstid. FindesDARsag Boolean True hvis adressen ligger i en sagsreference. Feltet findes ikke i den fysiske database, men bliver beregnet. IBrugIBBR Boolean True hvis adressen (enhedsadressen) benyttes i BBR. Feltet findes ikke i den fysiske database, men bliver beregnet. Virkningstid Registreringstid Se afsnit Bitemporale egenskaber Se afsnit Bitemporale egenskaber Sagsreference Felt Status Sagsnummer Beskrivelse Status angiver om sagen stadig er aktiv eller om den er nedlagt. Sagsnummer Sagsnummer skal være entydigt. Oprettelsesdato Oprettelsesdato Feltet opdateres automatisk af systemet. Titel Max-X Max-Y Min-X Max-X Titel på sagen Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Kommentar fra ejer Kommentar fra ejer Kommentar fra sagsbeh. Kommentar fra sagsbehandler DAR 0.9 Systembeskrivelse Side 29 Version 1.3

30 Dokumenter Det er muligt at uploade dokumenter til en sag. Dokumenter skal være af typen.docx eller.pdf. 4.2 Den fysiske datamodel Den fysiske datamodel er lavet på baggrund af den logiske datamodel. Nogle felter fra den logiske datamodel er dog beregnede og er derfor ikke en del af den fysiske datamodel: Matrikel (felterne landsejerlavskode, matrikelnummer), oplysning findes i GST Ejendomsnummeret, oplysning findes i GST IBrugIBBR (er adressen i brug i BBR) FindesDARSag (ligger entiteten i en DAR sag) Nøgler Primærnøgler i databasen er implementeret som integer, som automatisk tælles et op. Entiteternes unikke identifier (UUID) angives med præfiks BK_ Fremmednøgler har i databasen præfiks FK_ Entiteter med historik (Adgangspunkt, husnummer, adresse, sagsreference) Den fysiske datamodel består for hver entitet (som har historik) af en hovedtabel og en versionstabel. Disse tabeller er lavet for at håndtere historik (bitemporale egenskaber). Se afsnit Bitemporale egenskaber for yderligere detaljer vedrørende bitemporale egenskaber i DAR. De to implementerede tabeller hedder f.eks. Adresse og AdresseVersion. Den ene tabel (f.eks. Adresse) håndterer relationer til øvrige entiteter. Den anden tabel (f.eks. AdresseVersion) indeholder alle tidligere samt de aktuelle versioner. Der oprettes desuden 3. tabel per entitet (f.eks. AdresseAktuelt), som kun indeholder den aktuelle gældende version af en entitet. Årsagen til denne implementering er performancehensyn. Nedenstående figur viser den fysiske database for de tre entiteter Adgangspunkt, Husnummer of Adresse. DAR 0.9 Systembeskrivelse Side 30 Version 1.3

31 AdgangspunktAktuelt (dbo) Adgangspunkt_id FK_AdgangspunktVersion_id BK_Adgangspunkt_id StatusKode KildeKode Oest Nord TekniskStandard Noejagtighedsklasse Retning Placering KommuneNummer ESDHReference Journalnummer Revisionsdato VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringStart_Aktoe RegistreringStart HusnummerAktuelt (dbo) Husnummer_id FK_HusnummerVersion_id BK_Husnummer_id FK_Adgangspunkt_id BK_Adgangspunkt_id Vejkode Husnummer StatusKode KildeKode Vejnavn Postnummer Postdistrikt SupplerendeByNavn IKrafttraedelsesDato VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringStart_Ak... RegistreringStart BK_RegistreringStart_Aktoer_id RegistreringSlut BK_RegistreringSlut_Aktoer_id AdresseAktuelt (dbo) Adresse_id FK_AdresseVersion_id BK_Adresse_id FK_Husnummer_id BK_Husnummer_id StatusKode ESDHReference Journalnummer KildeKode IKrafttraedelsesDato Doerbetegnelse Etagebetegnelse Bemaerkning VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringS... RegistreringStart BK_RegistreringStart_Akt... RegistreringSlut BK_RegistreringSlut_Akt... Adgangspunkt (dbo) Adgangspunkt_id BK_Adgangspunkt_id FK_RegistreringStartTransakti... DBRegistreringStartTimestamp Husnummer (dbo) Husnummer_id BK_Husnummer_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp Adresse (dbo) Adresse_id BK_Adresse_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp AdgangspunktVersion (dbo) AdgangspunktVersion_id FK_Adgangspunkt_id StatusKode KildeKode Oest Nord TekniskStandard Noejagtighedsklasse Retning Placering KommuneNummer ESDHReference Journalnummer Revisionsdato VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion_id HusnummerVersion (dbo) HusnummerVersion_id FK_Husnummer_id FK_Adgangspunkt_id Vejkode Husnummer StatusKode KildeKode IKrafttraedelsesDato VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktio... DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion... AdresseVersion (dbo) AdresseVersion_id FK_Adresse_id FK_Husnummer_id StatusKode ESDHReference Journalnummer KildeKode IKrafttraedelsesDato Doerbetegnelse Etagebetegnelse Bemaerkning VirkningStart VirkningSlut DBRegistreringStartTimestam FK_RegistreringStartTransakti DAR 0.9 Systembeskrivelse Side 31 Version 1.3

32 4.2.3 Transaktioner og timestamps Der er indført en tabel Transaktion for at kunne sammenknytte rækker der er blevet opdateret som følge af en sammenhængende opdatering af relaterede entiteter i en transaktion. Ved indsættelsen af en række i f.eks. Adgangspunkt sættes FK_RegistreringStartTransaktion_id til den transaktion der forårsager indsættelsen og det vil være igennem denne transaktion at logiske felter som RegistreringStart, OpretBruger og AendretFunktion udledes. DBRegistreringStartTimestamp er det faktiske tidspunkt hvor rækken blev indsat i tabellen og er ikke det samme som RegistreringStart da RegistreringStart er delt på tværs af alle entiteter der er blevet opdateret samlet. DBRegistreringStartTimestamp er udelukkende tænkt til intern brug i systemet i forbindelse med f.eks. fejlsøgning men bliver måske også nødvendig i forbindelse med udtrækkene til AWS, for at sikre at en oprettelse og en nedlæggelse der kommer i forbindelse med samme transaktion vil komme i den rigtige rækkefølge i opdateringerne til AWS. Adgangspunkt (dbo) Adgangspunkt_id BK_Adgangspunkt_id FK_RegistreringStartTransaktio... DBRegistreringStartTimestamp Transaktion (dbo) Transaktion_id BK_Aktoer_id RegistreringTimestamp Funktion DBRegistreringStartTimestamp AdgangspunktVersion (dbo) AdgangspunktVersion_id FK_Adgangspunkt_id StatusKode KildeKode Oest Nord TekniskStandard Noejagtighedsklasse Retning Placering KommuneNummer ESDHReference Journalnummer Revisionsdato VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion_id DAR 0.9 Systembeskrivelse Side 32 Version 1.3

33 Hovedtabel Hver række i hovedtabellen bliver kun rørt 1 gang, når den oprettes. DBIndsaetTimestamp: Faktiske tidspunkt for hvornår entiteten blev oprettet. FK_RegistreringStartTransaktion_id: Transaktion, som har oprettet rækken i databasen. Versionstabel Hver række i Versionstabellen bliver kun rørt 2 gange: når den oprettes og når der sættes Registeringsslut tidspunktet. DBRegistreringStartTimestamp: Faktiske tidspunkt for hvornår entiteten blev oprettet. DBRegistreringSlutTimestamp: Fatiske tidspunkt for hvornår entiteten blev opdateret. Desuden referer hver række i Versionstabellen til to transaktioner, som gemmes i en Transaktion tabel: FK_RegistreringStartTransaktion_id: peger på den transaktion, som har oprettet rækken i databasen, RegistreringTimestamp i den transaktion svarer til RegsitreringStart tidspunktet. FK_OpdatererTransaktion_id: peger på den transaktion, som har opdateret rækken i databasen. RegistreringTimestamp i den transaktion svarer til RegsitreringSlut tidspunktet. Transaktiontabel Her findes oplysninger om - Tidspunkt for transaktionen (RegistreringTimestamp) - Brugeren som udførte transaktionen - Den funktion i programmerne som udførte transaktionen En fuldstændig oversigt over den fysiske database kan først leveres på et senere tidspunkt Tegning af databasemodellen Datamodellen for DAR 0.9 ser ud som vist på de to nedenstående tegninger. Første tegning er uden sagsreference tabellerne, mens 2. tegning viser sagsreference tabellerne. DAR 0.9 Systembeskrivelse Side 33 Version 1.3

34 DarLog (dbo) DarLog_id BK_DarLog_id FK_Transaktion_id CategoryID EventID Transaktion (dbo) Transaktion_id BK_Aktoer_id RegistreringTimestamp Funktion DBRegistreringStartTimestam... Adgangspunkt (dbo) Adgangspunkt_id BK_Adgangspunkt_id FK_RegistreringStartTransakti... DBRegistreringStartTimestam... Husnummer (dbo) Husnummer_id BK_Husnummer_id FK_RegistreringStartTransakti... DBRegistreringStartTimestam... Adresse (dbo) Adresse_id BK_Adresse_id FK_RegistreringStartTransakti... DBRegistreringStartTimesta... Priority SeverityID Title LogTimestamp MachineName ProcessName HandlingInstanceID AdgangspunktVersion (dbo) AdgangspunktVersion_id AdgangspunktAktuelt (dbo) Adgangspunkt_id HusnummerVersion (dbo) HusnummerVersion_id HusnummerAktuelt (dbo) Husnummer_id AdresseVersion (dbo) AdresseVersion_id AdresseAktuelt (dbo) Adresse_id FK_Bruger_id FK_Adgangspunkt_id FK_AdgangspunktVersion_id FK_Husnummer_id FK_HusnummerVersion_id FK_Adresse_id FK_AdresseVersion_id ElapsedTime StatusKode BK_Adgangspunkt_id FK_Adgangspunkt_id BK_Husnummer_id FK_Husnummer_id BK_Adresse_id ExternalElapsedTime KildeKode StatusKode Vejkode FK_Adgangspunkt_id StatusKode FK_Husnummer_id ServiceName Oest KildeKode Husnummer BK_Adgangspunkt_id ESDHReference BK_Husnummer_id Action Nord Oest StatusKode Vejkode Journalnummer StatusKode Message TekniskStandard Nord KildeKode Husnummer KildeKode ESDHReference FormattedMessage Noejagtighedsklasse TekniskStandard IKrafttraedelsesDato StatusKode IKrafttraedelsesDato Journalnummer ResultID Retning Noejagtighedsklasse VirkningStart KildeKode Doerbetegnelse KildeKode ClientType Placering Retning VirkningSlut Vejnavn Etagebetegnelse IKrafttraedelsesDato LogXml KommuneNummer Placering DBRegistreringStartTimesta... Postnummer Bemaerkning Doerbetegnelse KommuneKode ESDHReference KommuneNummer FK_RegistreringStartTransakti... Postdistrikt VirkningStart Etagebetegnelse Journalnummer ESDHReference DBRegistreringSlutTimestamp SupplerendeByNavn VirkningSlut Bemaerkning Revisionsdato Journalnummer FK_RegistreringSlutTransakti... IKrafttraedelsesDato DBRegistreringStartTimestam... VirkningStart Valideringsfejl (dbo) Valideringsfejl_id VirkningStart VirkningSlut Revisionsdato VirkningStart VirkningStart VirkningSlut FK_RegistreringStartTransakti... DBRegistreringSlutTimestamp VirkningSlut FoersteRegistreringStart Kode DBRegistreringStartTimestamp VirkningSlut FoersteRegistreringStart FK_RegistreringSlutTransaktio... BK_FoersteRegistreringStart_Aktoer_id Tekst FK_RegistreringStartTransaktion_id FoersteRegistreringStart BK_FoersteRegistreringStart_A... RegistreringStart OpretTimestamp DBRegistreringSlutTimestamp BK_FoersteRegistreringStart_Akto... RegistreringStart BK_RegistreringStart_Aktoer_id AendretTimestamp FK_RegistreringSlutTransaktion_id RegistreringStart BK_RegistreringStart_Aktoer_id RegistreringSlut AendretFunktion BK_RegistreringStart_Aktoer_id RegistreringSlut BK_RegistreringSlut_Aktoer_id FK_AktoerOpret_id RegistreringSlut BK_RegistreringSlut_Aktoer_id FK_AktoerAendret_id BK_RegistreringSlut_Aktoer_id OphoertTimestamp Felt (dbo) Felt_id Entitetnavn Feltnavn Kraevet OpretTimestamp AendretTimestamp AendretFunktion FK_AktoerOpret_id FK_AktoerAendret_id OphoertTimestamp Figur 4: Den fysiske datamodel for DAR 0.9 (uden sagsreferencer) DAR 0.9 Systembeskrivelse Side 34 Version 1.3

35 Sagsreference (dbo) Sagsreference_id BK_Sagsreference_id FK_RegistreringStartTran... DBRegistreringStartTime... SagsreferenceAktuelt (dbo) Sagsreference_id FK_SagsreferenceVersion_id BK_Sagsreference_id Kommunenummer Sagsnummer Titel Sagsbehandler SagsreferenceVersion (dbo) SagsreferenceVersion_id FK_Sagsreference_id Kommunenummer Sagsnummer Titel Sagsbehandler MinX AdgangspunktSagsreferenceVersion (dbo) AdgangspunktSagsreferenceVersion_id FK_AdgangspunktSagsreference_id FK_Sagsreference_id FK_Adgangspunkt_id AdgangspunktAnvendelseKode Etageadgang KommentarSagsbehandler KommentarEkstern VirkningStart VirkningSlut DBRegistreringStartTimestamp HusnummerSagsreferenceVersion (dbo) HusnummerSagsreferenceVersion_id FK_HusnummerSagsreference_id FK_Sagsreference_id FK_Husnummer_id VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion_id AdresseSagsreferenceVersion (dbo) AdresseSagsreferenceVersion_id FK_AdresseSagsreference_id FK_Sagsreference_id FK_Adresse_id VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion_id MinX MaxX FK_RegistreringStartTransaktion_id MaxX MinY DBRegistreringSlutTimestamp MinY MaxY FK_RegistreringSlutTransaktion_id MaxY DybtLink KommentarSagsbehandler KommentarEkstern StatusKode VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringStart_Akt... RegistreringStart BK_RegistreringStart_Aktoer_id RegistreringSlut BK_RegistreringSlut_Aktoer_id DybtLink KommentarSagsbehandler KommentarEkstern StatusKode VirkningStart VirkningSlut DBRegistreringStartTimestam... FK_RegistreringStartTransakti... DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktio... AdgangspunktSagsreferenceAktuelt (dbo) AdgangspunktSagsreference_id FK_AdgangspunktSagsreferenceVersion_id BK_AdgangspunktSagsreference_id FK_Sagsreference_id BK_Sagsreference_id FK_Adgangspunkt_id BK_Adgangspunkt_id AdgangspunktAnvendelseKode Etageadgang KommentarSagsbehandler KommentarEkstern VirkningStart VirkningSlut HusnummerSagsreferenceAktuelt (dbo) HusnummerSagsreference_id FK_HusnummerSagsreferenceVersion_id BK_HusnummerSagsreference_id FK_Sagsreference_id BK_Sagsreference_id FK_Husnummer_id BK_Husnummer_id VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringStart_Aktoer_id RegistreringStart BK_RegistreringStart_Aktoer_id RegistreringSlut BK_RegistreringSlut_Aktoer_id AdresseSagsreferenceAktuelt (dbo) AdresseSagsreference_id FK_AdresseSagsreferenceVersion_id BK_AdresseSagsreference_id FK_Sagsreference_id BK_Sagsreference_id FK_Adresse_id BK_Adresse_id VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringStart_Aktoer_id RegistreringStart BK_RegistreringStart_Aktoer_id RegistreringSlut BK_RegistreringSlut_Aktoer_id FoersteRegistreringStart BK_FoersteRegistreringStart_Aktoer_id RegistreringStart BK_RegistreringStart_Aktoer_id RegistreringSlut BK_RegistreringSlut_Aktoer_id HusnummerSagsreference (dbo) HusnummerSagsreference_id BK_HusnummerSagsreference_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp AdresseSagsreference (dbo) AdresseSagsreference_id BK_AdresseSagsreference_id FK_RegistreringStartTransaktion_id AdgangspunktSagsreference (dbo) AdgangspunktSagsreference_id DBRegistreringStartTimestamp BK_AdgangspunktSagsreference_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp Husnummer (dbo) Husnummer_id Adgangspunkt (dbo) Adgangspunkt_id BK_Adgangspunkt_id FK_RegistreringStartTransa... BK_Husnummer_id FK_RegistreringStartTr... DBRegistreringStartTi... Adresse (dbo) Adresse_id BK_Adresse_id FK_RegistreringStartTr... DBRegistreringStartTi... DBRegistreringStartTimest... Figur5: Den fysiske datamodel: Sagsreferencer DAR 0.9 Systembeskrivelse Side 35 Version 1.3

36 4.2.5 Andre systemtabeller i den fysiske datamodel Endvidere er der i den fysiske datamodel tilføjet nogle systemtabeller som benyttes internt i DAR 0.9 og som ikke har en logisk pendant. Valideringsfejl Tabellen Valideringsfejl benyttes til at gemme alle valideringsbeskeder som findes i DAR. Darlog Tabellen Darlog benyttes til at gemme logninger. (se også kapitel 8 Logning). Felt Tabellen Felt indeholder alle felter, som findes, sammen med den entitet de ligger på og sammen med angivelse af, om felterne er krævede (attribut Kraevet ). DAR 0.9 Systembeskrivelse Side 36 Version 1.3

37 4.2.6 Tabeller til CPR data Følgende tabeller vedligeholdes ved indlæsning af data fra CPR. Vej Vejstykke Postdistrikt By Bitemporale egenskaber I DAR er implementeret dobbelthistorik ved hjælp af bitemporale egenskaber. Det dobbelte består i, at to tidsaspekter virkningstid og registreringstid håndteres i sammenhæng. Alle entiteter repræsenteres fysisk i to tabeller - en hovedtabel, som indeholder id/nøgle, og en versionstabel, som indeholder entitetens attributter i en eller flere versioner. Hver gang der foretages en opdatering af en entitet, indsættes en ny række i versionstabellen. Alle versioner betragtes som dele af stamdataobjektet, og har den samme identifikation. Ændres en enkelt attributværdi, betragtes dataobjektet som ændret og dermed versioneret. Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. OBS: Vær opmærksom på, at selv om modellen understøtter bitemporale egenskaber så der i nuværende version ikke er muligt at håndtere/benytte flere virkningstider igennem OIO snitfladerne eller igennem ADK adresseklienten. Når data rettes, gemmes den gamle version med RegisteringsSlut og der oprettes to nye versioner i Version tabellen. Eksempel for et adresselivsforløb I det følgende beskrives et livsforløb for en adresse i DAR 0.9: Adressen oprettes Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV Adressen ændres til gældende reel ændring Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV Foreløbig ST TV Gældende ST TV Adressen nedlægges Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV Foreløbig ST TV Gældende ST TV Gældende ST TV Nedlagt ST TV I DAR 0.9 vil alle ændringer blive håndteret som reelle ændringer og der er ingen mulighed for at lave fejlrettelser tilbage i tiden. DAR 0.9s datastruktur er dog forberedt til at kunne understøtte dette senere. DAR 0.9 Systembeskrivelse Side 37 Version 1.3

38 4.3 Konvertering fra BBR adresser til DAR 0.9 Dette afsnit vil give et kort overblik over konverteringen af adresser fra BBR til DAR 0.9. Detaljer for den gennemførte konvertering fremgår af konverteringsnotatet og beskrives ikke her. Adresserne fra BBR Adresse og ADK 0.9 (BBRs udvidede datamodel) er blevet kopieret til DAR 0.9 og danner datagrundlaget for DAR 0.9. BBR ADK 0.9 DAR 0.9 Fra BBR til DAR 0.9 Entiteterne fra BBR (tabellerne geometri, adgangsadresse og enhedsadresse) er blevet konverteret til entiteterne i DAR 0.9 (tabellerne adgangspunkt, husnummer og adresse). De entiteter der hørte sammen i BBR hører også sammen i DAR nu efter konverteringen. BBRs adressesager (tabel Adressesag) er ikke konverteret til DAR 0.9. Overordnet kan man sige, at et adgangsadressepunkt (geometripunkt) konverteres til et adgangspunkt, en adgangsadresse til et husnummer, og en enhedsadresse til en adresse. GEOMETRI ADGANGSADRESSE ENHEDSADRESSE Konverteres til Konverteres til Konverteres til ADGANGSPUNKT HUSNUMMER ADRESSE Fra ADK 0.9 til DAR 0.9 Konverteringen af data fra ADK 0.9 (BBRs udvidede datamodel) til DAR 0.9 er foregået mere eller mindre en-til-en. Konvertering af status fra BBR /ADK 0.9 til DAR 0.9 BBR DAR Godkendt/Gældende Gældende 2 Slettet Nedlagt 3 Foreløbig Foreløbig 4 Afsluttet sagsentitet Konverteres til Henlagt 5 Foreslået Foreløbig Konvertering af historik fra BBR/ADK 0.9 til DAR 0.9 BBRs adresser er konverteret til DAR 0.9 under hensyntagen af den ovenfor beskrevne model for historik med registrerings- og virkningstid. Det samme gælder for konverteringen af BBRs felthistorik. Alle ændringer i BBR er i den forbindelse håndteret som reelle ændringer. DAR 0.9 Systembeskrivelse Side 38 Version 1.3

39 BBRs tidsstempler skal konverteres til den ovenfor omtalte model med virkningstid og registreringstid. Registreringer i BBR er i dag altid gældende fra det tidspunkt opdateringen foretages. Dvs. at der hverken registreres med tilbagevirkende kraft eller med virkning gældende fra en fremtidig dato. Det betyder konkret, at virkningstid-start og registreringstid-start altid vil være ens. For hver række i BBRs tabel oprettes der en række i tilsvarende stamdataobjekt tabel i DAR og en række i tilhørende versions-tabel. I forbindelse med konvertering af historik vil der blive tilføjet yderligere rækker i versionstabellen med historisk registreringstid, hvis entiteten er blevet rettet siden dens oprettelse. DAR 0.9 Systembeskrivelse Side 39 Version 1.3

40 5 Forretningslogik I dette kapitel beskrives DARs forretningslogik. Forretningslaget sørger for feltvalidering af de indberettede data hvad enten disse indberettes gennem ADK adresseklienten eller gennem de etablerede OIO snitflader, idet begge tilgange benytter de samme webservices i applikationslaget. Om et felt er krævet eller ej, gemmes i database tabellen Felt. Det er denne tabel, forretningslaget slår op i for at validere krævede felter. Ud over den i forretningslaget implementerede validering, foretages der skemavalidering for de data der indberettes gennem de eksterne OIO snitflader. Skemavalideringen sikrer, at de indberettede data overholder de datarestriktioner skemaerne definerer. 5.1 Matrikel-adresse relation Der findes ingen administrative ESR matrikler i DAR 0.9. Adgangspunkter kan således kun knyttes til GST matrikler. Det er adgangspunktets koordinat, som bestemmer matriklen. Matrikel-adresse relationen i DAR er således en afledt relation ud fra adgangspunktets koordinat. Matrikel oplysninger persisteres ikke i DAR. 5.2 Adresseforekomsters liv Et adgangspunkt, et husnummer eller en adresse bibeholder altid sin entydige ID. En adresse kan ikke flyttes til et andet husnummer, men vil altid være tilknyttet det samme husnummer i sin levetid. Et husnummer kan desuden ikke flyttes til et andet adgangspunkt, men vil altid være tilknyttet det samme adgangspunkt i sin levetid. 5.3 Krav om vejkode og husnummer, samt CPR vejstykke Gældende adresser skal have vejkode og husnummer, og de skal ligge på et CPR vejstykke. Foreløbige adresser behøver ikke at have en vejkode hhv. et husnummer og de behøver således ikke ligge på CPR vejstykker. 5.4 Tilknytning af adresser til entiteter i BBR Når adresser tilknyttes til niveauer i BBR kan følgende husnumre/adresser benyttes: Gældende husnumre/adresser Foreløbige husnumre/adresser med vejkode og husnummer (dog ligger de ikke nødvendigvis på godkendte CPR vejstykker). Husnumre (adgangsadresser i BBR) må ikke slettes i DAR hvis de er i brug i BBR. Ligeledes må adresser (enhedsadresser i BBR) ikke slettes i DAR hvis de er i brug i BBR. DAR 0.9 Systembeskrivelse Side 40 Version 1.3

41 Husnu mmer Adresse 5.5 Statusværdier Statusværdier for entiteterne adgangspunkt, husnummer og adresse i DAR 0.9 er følgende: Foreløbig Gældende Nedlagt Henlagt Entiteten er oprettet, men har ikke nødvendigvis vejkode, husnummer m.m. Adressen kan kun knyttes til BBR entiteter hvis den har vejkode og husnummer. Adressen behøver ikke at ligge på et godkendt CPR vejstykke. Entiteten er gældende. Entiteten er nedlagt og har tidligere været gældende. Entiteten er henlagt og har tidligere været foreløbig. 5.6 Sammenhæng mellem statusværdier En adresse skal ligge under et husnummer som er mindst lige så betydende. Et husnummer skal ligge under et adgangspunkt som er mindst lige så betydende. Dvs. der kan ikke ligge entiteter med en højere status under entiteter med en lavere status. En entitet med status gældende må ikke rettes tilbage til status foreløbig. En entitet med status henlagt må ikke rettes tilbage til status foreløbig. En entitet med status nedlagt må ikke rettes tilbage til status gældende. Skemaet nedenfor viser de lovlige kombinationer. Husnummer Gældende (1) Nedlagt (2) Foreløbig (3) Henlagt (4) Gældende (1) X Nedlagt (2) X X - - Foreløbig (3) X - X - Henlagt (4) X X X X Adgangspunkt Gældende (1) Nedlagt (2) Foreløbig (3) Henlagt (4) Gældende (1) X Nedlagt (2) X X - - Foreløbig (3) X - X - Henlagt (4) X X X X Automatiske statusændringer (gælder kun ved benyttelse af Adresseklienten ADK) Når et adgangspunkt i DAR ændrer status fra foreløbig til gældende i Adresseklienten ADK, så ændres også status på husnummeret og adresserne under adgangspunktet til gældende. Bemærk, at underliggende entiteter med status foreløbig og angiven fremdateret ikrafttrædelsesdato vil ikke ændre status til gældende. DAR 0.9 Systembeskrivelse Side 41 Version 1.3

42 Det samme gælder for husnumre. Når et husnummer skifter status fra foreløbig til gældende i Adresseklienten ADK, vil underliggende adresser også ændre status til gældende. Bemærk, at underliggende adresser med status foreløbig og angiven fremdateret ikrafttrædelsesdato vil ikke ændre status til gældende. 5.7 Adressernes entydighed Husnumre med status foreløbig og gældende skal være entydig på kommunenummer, vejkode og husnummer (hvis vejkode og husnummer er angivet). Gældende husnumre skal være entydige på kommunenummer, vejkode og husnummerbetegnelse. Der må gerne eksistere flere foreløbige husnumre uden vejkode eller uden husnummerbetegnelse. Foreløbige husnumre uden vejkode eller husnummerbetegnelse kan ikke knyttes til entiteter i BBR. Foreløbige husnumre, som har vejkode og husnummer skal være entydige på kommunenummer, vejkode og husnummerbetegnelse. Husnumre (gældende og foreløbige med vejkode og husnummer) skal være entydige på kommunenummer, vejkode og husnummerbetegnelse. Dvs. der må ikke findes et gældende og et foreløbigt husnummer med samme kommunenummer, vejkode og husnummerbetegnelse. Denne regel er mere restriktiv end det er tilfældet i BBR i dag. Gældende og foreløbige adresser skal være entydige på husnummeret, etage og side/dørnummer. Dette gælder også hvis det tilhørende husnummer ikke har en vejkode eller en husnummerbetegnelse. 5.8 Diverse valideringsregler på entitetsniveau Adgangspunkt Felt Status DAR Feltet er krævet og de gældende kodeværdier skal benyttes. Se også afsnit 0 og 5.6. Kilde Feltet er krævet for alle adgangspunkter uanset status. De gældende kodeværdier skal benyttes. ADK Adresseklient I ADK adresseklienten sættes kilde automatisk til Oprettet maskinelt på baggrund af matrikelnummer tyngdepunkt (kode 2) hvis brugeren angiver matrikeloplysninger (ny opret funktionalitet). Koden sættes til Oprettet af Teknisk Forvaltning (kode 5) hvis brugeren sætter punktet på kortet eller flytter/retter eksisterende punkt på kortet DAR 0.9 Systembeskrivelse Side 42 Version 1.3

43 OIO I OIO snitfladerne kan alle kodeværdier vælges. X,Y koordinater Felterne er krævede for alle adgangspunkter uanset status. Der må ikke oprettes eller opdateres koordinater med værdien (0,0). x, y koordinater skal ligge i kommunen. Reglen vedligeholdes i DAR 0.9 ved hjælp af webservice kald til GST. Adgangspunktet kan oprettes/opdateres selv om GST ikke kan levere et passende kommunenummer eller GST leverer et andet kommunenummer. I givet fald leveres der en besked tilbage som gør brugeren opmærksom på, at punktet ligger udenfor kommunen. ADK Beregnede koordinater i klient (ny opret funktionalitet) I forbindelse med den nye opret funktionalitet i ADK Adresseklient hentes foreløbige koordinater fra GST ud fra matriklen. Punktet kan efterfølgende flyttes på plads i kortet. OIO Når der opdateres data igennem OIO snitfladerne hentes der ikke beregnede koordinater fra GST, men koordinaterne skal angives. Nøjagtighedsklasse Feltet er krævet for alle adgangspunkter uanset status. Der må ikke oprettes adgangspunkter uden at der er angivet koordinater, derfor er kodeværdien U ikke tilladt ved oprettelser og opdateringer. Ved opdatering kan en dårlig nøjagtighedsklasse ikke overskrive en bedre nøjagtighedsklasse. ADK Adresseklient Når et adgangspunkt oprettes igennem ADK Adresseklienten, sættes nøjagtighedsklasse automatisk til enten A eller B, alt efter om brugeren sætter punktet i kortet eller om brugeren angiver matrikeloplysninger i stedet for. Når nøjagtighedsklassen er B og brugeren efterfølgende flytter adgangspunktet på plads i kortet eller opdaterer dens retning, sættes nøjagtighedsklassen automatisk til A. OIO Feltet skal angives. I OIO snitfladerne kan alle kodeværdier (undtagen U) vælges. Revisionsdato Feltet er krævet. Ved opdatering skal revisionsdato være lig med DAR 0.9 Systembeskrivelse Side 43 Version 1.3

44 eller nyere end eksisterende revisionsdato. Revisionsdatoen må ikke fremdateres. Hvis revisionsdatoen ikke angives eller hvis revisionsdatoen er uændret, men koordinaterne eller retning er ændret, sættes revisionsdatoen automatisk til dagsdato. Dette gælder både for ADK adresseklienten og OIO snitfladen. ADK Adresseklient I ADK Adresseklient sættes revisionsdato automatisk til dagsdato hvis koordinat eller retning ændres. OIO I OIO snitfladen angives revisionsdato ved oprettelser og opdateringer. Hvis datoen ikke angives eller er uændret, sættes den til dagsdato, hvis koordinat eller retning er ændret. Journalnummer ESDH reference Journalnummer må højst bestå af 60 tegn. ESDH reference må højst bestå af 200 tegn. Placering Et heltal: 1, 2, 3, 4, 5, 6, 7, 8 eller 9. Feltet er krævet uanset status. Hvis feltet ikke angives, sættes værdien automatisk til 5 ved oprettelser. ADK Adresseklient I ADK Adresseklient er feltet per default sat til 5, men kan ændres. Når et adgangspunkt oprettes igennem Adresseklientens nye opret funktionalitet sættes feltet automatisk til 5. Sagsbehandleren kan efterfølgende rette værdien på adgangspunktet skærmbilledet. OIO I OIO snitfladerne angives placering ved oprettelser og opdateringer. Hvis feltet ikke angives ved oprettelser, sættes den til 5. Retning Et decimaltal mellem 0.00 og Feltet er krævet for alle adgangspunkter uanset status. Hvis feltet ikke angives, sættes værdien automatisk til 200 ved oprettelser. ADK Adresseklient I ADK opdateres feltet via kortet. Feltet er sat til per DAR 0.9 Systembeskrivelse Side 44 Version 1.3

45 default. Når et adgangspunkt oprettes igennem Adresseklientens nye opret funktionalitet sættes feltet automatisk til Sagsbehandleren kan efterfølgende rette værdien på adgangspunktet skærmbilledet. OIO I OIO snitfladerne angives retning ved oprettelser og opdateringer. Hvis feltet ikke angives ved oprettelser, sættes retning til Teknisk standard Feltet er krævet for alle adgangspunkter uanset status. Alle kodeværdier kan benyttes. ADK Adresseklient I ADK adresseklienten sættes teknisk standard automatisk til UF hvis brugeren opretter adgangspunktet ved at angive en matrikel (uden at angive punktet på kortet) Hvis punktet er oprettet med teknisk standard UF og senere flyttes på plads i kortet, kan sagsbehandleren rette koden til. OIO I OIO snitfladerne angives teknisk standard ved oprettelser og opdateringer og alle kodeværdier kan benyttes Husnummer Felt Status DAR Feltet er krævet og de gældende kodeværdier skal benyttes. Se også afsnit 0 og 5.6. Husnummerbetegnelse Feltet er krævet for gældende husnumre. Feltet skal opfylde de officielle definitioner i hvert fald hvis det indberettes. Der gælder følgende ifølge adressebekendtgørelsen: På grund af risikoen for forveksling må bogstaverne I, J, O og Q ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Både OIO snitfladen og ADK 0.9 klienten giver fejl hvis man prøver at oprette eller ændre et husnummer til et husnummer med de uhensigtsmæssige bogstaver. Det vil dog være muligt at opdatere et eksisterende husnummer som har de uhensigtsmæssige bogstaver. Dette resulterer ikke i nogen beskeder hverken i ADK Adresseklienten eller OIO DAR 0.9 Systembeskrivelse Side 45 Version 1.3

46 snitfladen. Vejkode Feltet er krævet for gældende husnumre. Feltet vejkode skal opfylde de officielle definitioner i hvert fald hvis det indberettes. Vejkoden skal eksistere i kommmunen. Kilde Feltet er krævet for alle husnumre uanset status. ADK Adresseklient Når et husnummer oprettes eller rettes igennem ADK, sættes kilde automatisk til Oprettet af kommunen iht. adressecirkulæret (kode 1). OIO I OIO snitfladerne er feltet krævet ved oprettelser og opdateringer og alle kodeværdier kan vælges. Ikrafttrædelsesdato Med version DAR må ikrafttrædelsesdatoen fremdateres. ADK Adresseklient I ADK Adresseklient sættes ikrafttrædelsesdato automatisk til den dato, hvor husnummeret ændrer status fra Foreløbig til Gældende. OIO I OIO snitfladen angives ikrafttrædelsesdatoen ved oprettelser og opdateringer. Hvis datoen ikke angives, sættes den til dagsdato, når husnummret ændrer status fra Foreløbig til Gældende. Ikrafttrædelsesdatoen på husnumre kan fra version fremdateres, dvs. for husnumre, der har status foreløbig, kan der indberettes en fremtidig ikrafttrædelsesdato. Udfyldes ikrafttrædelsesdatoen vil husnummeret stadig være foreløbig, men når man kommer til den angivne dato vil der automatisk blive skiftet status til gældende. For at et husnummer kan få indberettet en ikrafttrædelsesdato, skal alle valideringsregler for gældende husnumre være opfyldte. Når ikrafttrædelsesdatoen indtræder, sørger en automatisk kørsel for at status automatisk skifter fra foreløbig til gældende. Den automatiske kørsel prøver at gøre alle foreløbige husnumre med ikrafttrædelsesdato lige eller mindre end dags dato og status foreløbig gældende. Har overliggende adgangspunkt ikke sat status til gældende, vil det blive sat til gældende. Hvis det skulle ske, at et husnummer ikke kan gøres gældende, vil den automatiske kørsel springe dette husnummer over. Den næste kørsel vil så igen prøve at gøre entiteten gældende. Som ikrafttrædelsesdato gemmes altid den dato, hvor DAR 0.9 Systembeskrivelse Side 46 Version 1.3

47 husnummeret reel er blevet gældende, selv om husnummeret skulle have haft en anden ikrafttrædelsesdato Adresse Felt Status Validering Feltet er krævet og de gældende kodeværdier skal benyttes. Se også afsnit 0 og 5.6. Kilde Feltet er krævet for alle adresser uanset status. ADK Adresseklient Når en adresse oprettes eller rettes igennem Adresseklienten, sættes kilde automatisk til Oprettet af kommunen iht. adressecirkulæret (kode 1). OIO I OIO snitfladerne er feltet krævet og ved oprettelser og opdateringer kan alle kodeværdier vælges. Etage, sidedør Felterne etage og side/dørnummer skal opfylde de officielle definitioner for felterne i hvert fald hvis de indberettes. Etagebetegnelse for adresser må ikke være 00. Korrekt etagebetegnelse kan være følgende BLANK ST Stuen KL Kælder Side/dørnummer kan være følgende BLANK TV, MF, TH, , bogstaver, kombination af bogstaver (A-Z) og tal, samt tegnene skråstreg og bindestreg Journalnummer ESDH reference Ikrafttrædelsesdato Journalnummer må højst bestå af 60 tegn. ESDH reference må højst bestå af 200 tegn. Med version DAR må ikrafttrædelsesdatoen fremdateres. ADK Adresseklient I ADK Adresseklient sættes ikrafttrædelsesdato automatisk til den dato, hvor adressen ændrer status fra Foreløbig til Gældende. OIO DAR 0.9 Systembeskrivelse Side 47 Version 1.3

48 I OIO snitfladen angives ikrafttrædelsesdatoen ved oprettelser og opdateringer. Hvis datoen ikke angives, sættes den til dagsdato, når adressen ændrer status fra Foreløbig til Gældende. Ikrafttrædelsesdatoen på adresser kan fra version fremdateres, dvs. for adresser, der har status foreløbig, kan der nu indberettes en fremtidig ikrafttrædelsesdato. Udfyldes ikrafttrædelsesdatoen vil adressen stadig være foreløbig, men når man kommer til den angivne dato vil der automatisk blive skiftet status til gældende. For at en adresse kan få indberettet en ikrafttrædelsesdato, skal alle valideringsregler for gældende adresser være opfyldte. Indberetning af en ikrafttrædelsesdato på en adresse kræver at det overliggende husnummer har en ikrafttrædelsesdato eller er gældende. Når ikrafttrædelsesdatoen indtræder sørger en automatisk kørsel for at status skiftes automatisk fra foreløbig til gældende. Den automatiske kørsel prøver at skifte status til gældende for alle foreløbige adresser med ikrafttrædelsesdato lige eller mindre end dags dato og status foreløbig. Har overliggende husnummer eller adgangspunkt ikke sat status til gældende, vil de blive sat til gældende. Her skal det bemærkes, at der ikke ændres ved andre adresser under husnummeret. Dvs. ligger der for eksempel 2 foreløbige adresser under et foreløbigt husnummer/adgangspunkt og kun den ene adresse har sat ikrafttrædelsesdatoen, så er det kun den ene adresse der vil få skiftet status til gældende, sammen med husnummeret og adgangspunktet, når ikrafttrædelsesdatoen indtræffer. Adressen uden ikrafttrædelsesdato vil ikke få skiftet status i denne situation. Hvis det skulle ske, at en adresse ikke kan gøres gældende, vil den automatiske kørsel springe denne entitet over. Den næste kørsel vil så igen prøve at gøre entiteten gældende. Som ikrafttrædelsesdato gemmes altid den dato, hvor adressen reel er blevet gældende, selv om adressen skulle have haft en anden ikrafttrædelsesdato. 5.9 Valideringsbeskeder I nedenstående tabel er alle valideringsbeskeder fra DAR listet. 100 Feltet "&replacetext1;" skal udfyldes 1999 Nøjagtighedsklasse må ikke være U, der skal angives koordinater Nøjagtighedsklasse skal være A eller B 2001 Adgangspunktets status skal være gældende eller foreløbig 2002 Journalnummer må ikke indeholde mere end 60 tegn 2003 ESDHReference må ikke indeholde mere end 200 tegn 2004 Uoverensstemmelse i kommunekode DAR 0.9 Systembeskrivelse Side 48 Version 1.3

49 2005 Placering skal have en værdi mellem 1 og Retning skal have en værdi mellem 0 og Tekniskstandard skal have en af værdierne: TD, TK, TN eller UF 2008 Adgangpunktets kilde er ikke gyldig 2010 Matrikel ikke fundet 2016 Adgangspunktet ligger i en sagsreference og må derfor ikke slettes Søgningen tager for lang tid. Prøv at indskrænke søgekriterierne 2029 Der skal angives en matrikel hhv. et ejendomsnummer Der kunne ikke findes matrikler til ejendomsnummeret Matrikel kunne ikke entydigt identificeres Husnummeret findes men den angivne matrikel er ikke i overensstemmelse med husnummerets adgangspunkt Matrikelkoordinater kunne ikke findes ved GST Koordinater ligger udenfor kommunen 2035 Revisionsdato må ikke fremdateres 2036 Revisionsdato skal ligge efter sidst indberettet Revisionsdato Adressen er den sidste adresse under husnummeret og må ikke slettes. (kald fra BBR) 2038 Nord og øst-koordinat skal angives Husnummerets status skal være gældende eller foreløbig 3001 Vejkoden findes ikke i kommunen 3002 Husnummerbetegnelsen er ikke gyldig.husnummerbetegnelsen skal bestå af et tal eventuelt efterfulgt af et bogstav fra A-Z 3003 Husnummerets kilde er ikke gyldig 3004 Adressen "&replacetext1;" ligger ikke på et vejstykke i CPR og kan derfor ikke være gældende eller foreløbig med ikrafttrædelsesdato Der findes ikke et Adgangspunkt med Id=&replacetext1; 3016 Kun entiteter med status Foreløbig eller Gældende kan blive slettet 3017 Du kan ikke gemme husnummeret som gældende idet adgangspunktet har status foreløbig Adressen "&replacetext1;" findes allerede En gældende adresse må ikke rettes til status foreløbig Et gældende husnummer må ikke rettes til status foreløbig 3021 Et gældende adgangspunkt må ikke rettes til status foreløbig 3030 Nøjagtighedsklasse B må ikke overskrive nøjagtighedsklasse A 3031 På grund af risikoen for forveksling må bogstaverne I, J, O og Q ikke benyttes for et nyt husnummer, eller når et husnummer ændres Husnummeret må ikke flyttes til et andet adgangspunkt DAR 0.9 Systembeskrivelse Side 49 Version 1.3

50 3033 Adressen må ikke flyttes til et andet husnummer 3034 Husnummeret er nedlagt og kan ikke læses Husnummeret er henlagt og kan ikke læses Adressen er nedlagt og kan ikke læses Adressen er henlagt og kan ikke læses 3038 Adgangspunktet er henlagt og kan ikke læses Adgangspunktet er nedlagt og opdateringen er ikke mulig Husnummeret "&replacetext1;" findes allerede Adressens status skal være gældende eller foreløbig 4001 Dør betegnelse er ikke gyldig 4002 Etage betegnelse er ikke gyldig 4003 Adressens kilde betegnelse er ikke gyldig 4004 Journalnummer må ikke indeholde mere end 60 tegn 4005 ESDHReference må ikke indeholde mere end 200 tegn 4006 Der findes ikke et Husnummer med Id=&replacetext1; 4007 Husnummer skal sendes med ved oprettelse af Adresse 4014 Adressen ligger i en sagsreference og må derfor ikke slettes Adressens husnummer ligger i en sagsreference og må derfor ikke slettes Du kan ikke gemme adressen som gældende idet husnummeret har status foreløbig Bemærkning må ikke indeholde mere end 200 tegn 4024 Husnummeret skal have vejkode og husnummerbetegnelse når det ellers dens adresser benyttes i BBR Der kunne ikke afgøres, om husnummeret eller en underliggende adresse er i brug i BBR. Derfor er det ikke muligt at fjerne vejkode eller husnummerbetegnelse 4026 Hvis der søges på matrikelnummer, skal landsejerlav være udfyldt 4027 Ejendomsnummer/Matrikel blev ikke fundet Husnummeret findes, men der kan ikke hentes matrikeloplysninger fra GST og den angivne matrikel/ejendomsnummer kan ikke verificeres. Fjern matrikel hhv. ejendomsnummer under adgangspunkt 5000 Der findes ikke et Adgangspunkt med Id=&replacetext1; 5001 Der findes ikke en Sagsreference med Id=&replacetext1; 5002 Anvendelse er ikke gyldig 6000 Der findes ikke en AdgangspunktSagsreference med Id=&replacetext1; 6001 Der findes ikke en Sagsreference med Id=&replacetext1; 6002 Beskrivelse må ikke indeholde mere end 500 tegn 6003 AdgangspunktId eller AdgangspunktSagsreferenceId skal udfyldes DAR 0.9 Systembeskrivelse Side 50 Version 1.3

51 6004 Navn må ikke indeholde mere end 254 tegn 6005 Mimetype må ikke indeholde mere end 254 tegn 7000 Kommentar må ikke indeholde mere end 1500 tegn 7001 Kommentar må ikke indeholde mere end 1500 tegn 7002 Sagsbehandler må ikke indeholde mere end 50 tegn 7003 Sagsnummer må ikke indeholde mere end 32 tegn 7004 Titel må ikke indeholde mere end 100 tegn 7005 Der findes allerede en sag med det angivne sagsnummer 7006 Sagsreference status skal have en af værdierne: Aktiv, Nedlagt 8000 Der findes ikke en Sagsreference med Id=&replacetext1; 8001 Beskrivelse må ikke indeholde mere end 500 tegn 8002 Navn må ikke indeholde mere end 254 tegn 8003 Mimetype må ikke indeholde mere end 254 tegn 9000 Der findes ikke en Adresse med Id=&replacetext1; 9001 Der findes ikke en Sagsreference med Id=&replacetext1; 9002 Adgangspunktet ligger allerede i en anden sagsreference Der findes ikke et Husnummer med Id=&replacetext1; Der findes ikke en Sagsreference med Id=&replacetext1; Vejkode og husnummer skal angives for en gældende adresse eller for en foreløbig adresse med ikrafttrædelsesdato Husnummeret kan ikke slettes, da det er i brug i BBR Adressen kan ikke slettes, da den er i brug i BBR Der kunne ikke afgøres, om husnummeret eller en underliggende adresse er i brug i BBR. Derfor er det ikke muligt at slette husnummeret Der kunne ikke afgøres, om adressen er i brug i BBR. Derfor er det ikke muligt at slette adressen Der kunne ikke hentes foreløbige koordinater fra GST Ikrafttrædelsesdato må ikke fremdateres når status er Gældende Adressens ikrafttrædelsesdato skal fremdateres når status er foreløbig Husnummerets ikrafttrædelsesdato skal fremdateres når status er foreløbig Ikrafttrædelsesdato på adresse skal sættes til dagsdato Ikrafttrædelsesdato må ikke ændres når status er Gældende Når adressen er foreløbig og har en ikrafttrædelsesdato, skal husnummeret være gældende eller også have en ikrafttrædelsesdato Ikrafttrædelsesdatoen må ikke fjernes fra husnummeret når en underliggende adresse har en ikrafttrædelsesdato Husnummeret må ikke have en ikrafttrædelsesdato som ligger senere end ikrafttrædelsesdatoen for en underliggende adresse. DAR 0.9 Systembeskrivelse Side 51 Version 1.3

52 23325 Adressen må ikke have en ikrafttrædelsesdato som ligger tidligere end husnummerets Ikrafttrædelsesdato på husnummer skal sættes til dagsdato. DAR 0.9 Systembeskrivelse Side 52 Version 1.3

53 6 Sikkerhed og brugeradgang 6.1 Brugeradministration Brugeradministrationen er fælles for BBR og DAR og brugerne til DAR administreres i BBR 1.7. Denne beslutning er truffet for ikke at skulle udvikle en brugeradministration i DAR 0.9, som alligevel skal skiftes ud, når Grunddata programmets fælles sikkerhedsmodel bliver implementeret. Der henvises til BBRs systemdokumentation for yderligere detaljer. 6.2 Adgang til webservices Til eksterne OIO webservices benytter OWSA model T. Når webservicene kaldes sker følgende: Det medsendte OCES certifikat valideres og der kontrolleres om certifikatet er trukket tilbage (autentifikation). Der foretages autorisationstjek via den interne service, som BBR udstiller til DAR. For at kunne kalde den eksterne webservice (OIO snitflade) skal brugeren have tilknyttet rollen DARAjourfoer. Der vil ikke være grund til at skelne mellem læse- og skriverettigheder i forbindelse med de ny eksterne ajourføringsservices. Hvis en bruger kun har behov for at læse, henvises de til AWS suiten. For at kunne kalde den interne snitflade til DAR, skal brugeren have tilknyttet rollen DARKaldfraBBR. 6.3 Adgang til ADK klienten Der kan logges på ADK Adresseklienten enten via certifikat eller via brugernavn og password. Hvis brugeren logger på med certifikat sker følgende: Det medsendte OCES certifikat valideres og der kontrolleres om certifikatet er trukket tilbage (autentifikation). Der foretages autorisationstjek via den interne service, som BBR udstiller til DAR. Hvis brugeren logger på med brugernavn og password, kalder DAR BBRs interne snitflade for både autentifikation og autorisation af brugeren. Adgangen til ADK Adresseklienten styres af to roller AdresseklientRead og AdresseklientWrite. Brugere kan altså have enten læse- eller skriverettigheder til Adresseklienten. DAR 0.9 Systembeskrivelse Side 53 Version 1.3

54 7 Samtidighedsaspekter Når DAR og BBR bliver delt i to registre, og data hentes via interne snitflader, kan de hentede oplysninger være forældede inden behandlingen er gennemført i klienterne. 7.1 Eksempel 1: Adresseanvendelse i DAR Registerføreren i DAR fremsøger en adresse, som ikke er i brug i BBR, fluebenet på skærmbilledet vil vise, at adressen ikke er i brug. Kort efter tilknytter BBR registerføreren selvsamme adresse til en entitet i BBR. I DAR udfører registerføreren nu slet adresse funktionen idet det ser ud til at adressen ikke er i brug i BBR. For at sikre sig at adressen ikke slettes i DAR fordi den nu er i brug i BBR, skal DAR kalde BBR og tjekke adressens brug en ekstra gang før sletningen gennemføres. Adressen skal kun slettes hvis dette nye tjek viser, at adressen ikke er i brug. 7.2 Eksempel 2: BBRs mulighed for at oprette og slette adresser i DAR Når BBR kalder DARs interne services Opret adresse og Slet adresse, skal BBR tage højde for, at disse hændelser kort tid efter indlæses som en INSERT hhv. DELETE hændelse fra AWS en. Ved kaldet Slet adresse skal DAR give lov til at slette adressen på trods af, at den stadig er benyttet i BBR. DAR 0.9 Systembeskrivelse Side 54 Version 1.3

55 8 Logning Alle kald som foretages og alle fejl som opstår logges i databasen i tabellen DARLog. Tabellen referer desuden til tabellen Transaktion, så efterfølgende fejlsøgning lettes. DAR 0.9 Systembeskrivelse Side 55 Version 1.3

56 9 Produktions- og demomiljø Dette afsnit beskriver løsningens teknologiarkitektur. I denne beskrivelse er der fokus på de enkelte komponenters fordeling på fysiske servere. Følgende diagram viser den overordnede netværks topologi i DAR: User Firewall Internet Load balancing Presentation Layer Application Layer MS SQL Server Figur 5 Generel netværks topologi i DAR BBR og DAR løsningerne er designet i en flerlagsarkitektur, hvor løsningernes komponenter er separeret i logiske arkitekturlag. Lagene udgøres af et præsentationslogiklag, et forretningslogiklag, samt et datalogiklag. Lagdelingen af applikationerne tjener det formål at sikre en høj sikkerhed af den samlede løsning. Klienter tilgår løsningen over internet via browser og databærende trafik er altid krypteret på transportlaget (https). Præsentationslogik og forretningslogik er adskilt på web/applikationsframens servere og kører i egne applikationsinstanser under separate sikkerhedskonti. Services på præsentations- og forretningslagene er udstillet via en Applikation Content Delivery service (BIGIP load balancer). ADC en sikrer fordeling af load i farmen både fra klienter til præsentationsservices, såvel som fra præsentationslaget til forretningsservices. DAR 0.9 Systembeskrivelse Side 56 Version 1.3

57 ADC en fungerer som en fuld TCP proxy, som terminerer SSL trafikken. Herved bidrager ADC en både til at reducere den mulige angrebsflade på serverne i web/applikations-farmen, samtidig med at den sikrer en optimal udnyttelse af ressourcerne i serverfarmen og aflaster serverfarmen ved at håndtere SSL trafikken. Data er placeret i eget lag i egen sikkerhedszone. Der er etableret et demo- og et produktionsmiljø. 9.1 Produktionsmiljø Internet FRONT Server Type: Størrelse : A3 EQU_ID : vcpu : 4 stk vmem : 7168 MBMB C-disk : 60GB D-disk : 40GB Windows Server 2012R2 Webserver/ App Windows Server 2012R2 Webserver/ App Windows Server 2012R2 Webserver/ App Windows Server 2012R2 Webserver/ App Windows Server 2012R2 Application Server Ftp/Batch Server Type: Størrelse : A2 EQU_ID : vcpu : 2 stk vmem : 3584 MB C-disk : 60GB D-disk : 40GB Server Type: Størrelse : Cloud Large EQU_ID : vcpu : 4 stk vmem : 32 GB C; OS : 60 GB d: BIN : 25 GB e: TMP : 50 GB f: LOG : 100 GB g:dat : 200 GB SQL Server 2012 Report BACK SQL Server 2012 BBR/DAR Server Type: Størrelse : Cloud Large EQU_ID : vcpu : 4 stk vmem : 32 GB C; OS : 60 GB d: BIN : 25 GB e: TMP : 50 GB f: LOG : 200 GB g:dat : 500 GB JR5000PD JR5000PD Figur 6 DARs produktionsmiljø DAR 0.9 Systembeskrivelse Side 57 Version 1.3

58 9.2 Demomiljø Internet FRONT Server Type: Størrelse : A3 EQU_ID : vcpu : 4 stk vmem : 7168 MBMB C-disk : 60GB D-disk : 40GB Windows Server 2012 Web/App-server BACK DB 1 SQL Server 2012 BBR/DAR Figur 7 DARs demomiljø I demomiljøet findes én webserver, én applikationsserver samt en SQL server. Demomiljøet kan f.eks. benyttes af KOMBIT/MBBL til test af ny funktionalitet i ADK Adresseklienten samt af 3. parts applikationer til test af OIO snitfladerne. DAR 0.9 Systembeskrivelse Side 58 Version 1.3