6. Dataudveksling med andre systemer... 2

Transkript

1 Indholdsfortegnelse 6. Dataudveksling med andre systemer Kontekstdiagram for Nyt BBR Kort om NYT BBR s dataudveksling Udtræk fra NYT BBR Total udtræk (Totalkopi) Udtrækkenes formater Data fra Nyt BBR til OIS BBR Snitfladerne De generelle oioxml-snitflader OIOXML-snitflade for bygninger og boliger OIOXML-snitfladen for adresser OIOXML-snitfladen for adressegeometri OIOXML-snitfladen Utility Eksempel på WSDL erne OIOXML-snitfladerne & BBR-Kommune Masseopdatering Systemspecifikke snitflader Overordnede betragtninger Integration ud fra hændelser Skabelon til beskrivelse af systemintegration BBR KMS BBR - ESR Online opslag, som henter hændelser fra ESR On-line opslag, som henter oplysninger fra ESR On-line opslag, som sender oplysninger til ESR BBR Bossinf-STB BBR CPR BBR OIS Periodevise kørsler, dataudtræk mv Påmindelser ved overskridelse af tidsfrister Kapitel 6 version 6 Side 1 af 49

2 6. Dataudveksling med andre systemer Dataudveksling med andre systemer vil i Nyt BBR fortrinsvis foregå som systemtil-system integration. Dataudvekslingen sker dels vha. udtræk og dels vha. snitflader. Snitfladerne kan opdeles i de helt generelle oioxml-snitflader og i de systemspecifikke snitflader. Kapitel 6 version 6 Side 2 af 49

3 6.1 Kontekstdiagram for Nyt BBR Signaturforklaring = Kommer senere = I drift Kontekstdiagram for Nyt BBR = Delvis i drift BBR Version 1.4 Kapitel 6 version 6 Side 3 af 49

4 6.1.1 Kort om NYT BBR s dataudveksling KMS Geografisk sammenhæng for matrikler, benyttes til dannelse og vedligeholdelse af grunde. (se beskrivelse i afsnit om vedligeholdelse af matrikulære data i Nyt BBR) Kortforsyningen benyttes til at hente koordinater. Matrikeldata for Frb. og KBH Data kommer fra ESR (København overgår sandsynligvis til MiniMax i 2010) CPR Vi henter dagligt oplysninger fra CPR. De skal bruges ved oprettelse af adresser i Nyt BBR. Folkeregistrene skal have adgang til en standard webservice i Nyt BBR. Plansystem.dk Nyt BBR henter data fra Plansystem.dk til skærmbilledet Ejendomsoplysninger (a la det skærmbillede som man tidligere kendte som C182 i KMD BBR). Statens Arkiver Der skal hvert år afleveres en komplet kopi af landsdækkende BBR-data (stamdata). Formatet skal overholde krav fra Statens Arkiver. Danmarks Statistik Danmarks Statistik skal kunne foretage online udtræk af landsdækkende BBR-data (såvel stamdata som sagsdata). OIS Daglige online overførsler. OIS bruges til adresseopslag i forbindelse med BBR-meddelelser. Skattemappen BBR-Meddelelser skal kunne udsendes via eller E-boks i PDFformat med et følgebrev og kunne kobles til Skattemappen. Certificeringscenter Denne snitflade bruges i forbindelse med logon med certificater (medarbejder- og virksomhedscertifikater). Print/e-Boks BBR-Meddelelser skal kunne udsendes via eller E-boks i PDFformat med et følgebrev og kunne kobles til Skattemappen. OIO-snitflader Alle BBR-data skal udstilles via webservices og snitflader i OIOXMLformat. Modtageboksen Kapitel 6 version 6 Side 4 af 49

5 Med Modtageboksen får kommunen mulighed for at godkende de enkelte BBR-data. Her gennemfører vi samme maskinel validering og kvalitetssikring som når data ryger direkte ind. BOSSINF STB KMD stiller en webservice til rådighed således at koden for Offentlig støtte på længere sigt kan overføres til Nyt BBR fra BOSSINF-STB. På kort sigt skal brugeren selv indtaste feltet i Nyt BBR. ESR ESR udstiller en lang række hændelser (matrikulære, ejerskifte mm.) som nyt BBR abonnerer på. I forbindelse med udskrift af BBR-Meddelelser hentes ejere fra ESR. KRR Krydsreferencen holdes opdateret via synkroniseringen og udstillede webservices. KMD BBR KMD BBR holdes opdateret via synkroniseringen. Kapitel 6 version 6 Side 5 af 49

6 6.2 Udtræk fra NYT BBR Der kan foretages udtræk af landsdækkende BBR-data (såvel stamdata som sagsdata) Total udtræk (Totalkopi) Total udtræk af BBR-data, foretages på baggrund af den fysiske implementering af databasen. Udtrækket laves som semikolonsepareret filer, en fil pr. tabel, med en række pr. record. Udtrækket leveres med afblænding af felter der er omfattet af sikkerhedsklassifikation. Udtrækket består af data fra 26 tabeller (hvor tabellen antal er en tabel der angiver hvor mange rækker der er i de øvrige tabeller): AdgangsAdresse Adressesag Antal Brugsenhed By Byggesag Bygning Ejerskab Enhed EnhedEnhedsAdresse EnhedOpgang EnhedsAdresse Etage Geometri Grund KommunaltEjerlav Kommune Lokalitet Matrikel Notat Opgang Postdistrikt Rum Tekniskanlaeg Vej Vejstykke Udtrækkenes formater Det er muligt at levere udtræk fra NYT BBR i følgende formater: Standard formater Eksempler på modtagere Kapitel 6 version 6 Side 6 af 49

7 OIO-XML og CSV-filer Særlige formater OIS-XML Statens Arkivers formater Skat EBST Danmarks Statistik Modtagere OIS Statens Arkiver Data fra Nyt BBR til OIS Der skal dagligt køres et program der skaber et udtræk, dette udtræk placeres på et ftp server, hvorfra OIS henter data. Dataformatet er lavet i overensstemmelse med OIS s krav til snitflade, som OIS har beskrevet i dokumentet OIS_DBvaert_XML_Snitflade. De daglige udtræk består af de ændringer der er foretaget i Nyt BBR siden sidste udtræk. De enkelte entiteters timestamp bestemmer, hvilke data der skal overføres. Disse timestamps udløser en xml-record til OIS som følgende: OpretTimestamp AendrtTimestamp OphoertTimestamp O Opret record R Ændrings record S Slette record. Kapitel 6 version 6 Side 7 af 49

8 6.3 BBR Snitfladerne De generelle oioxml-snitflader Nyt BBR s funktionalitet bliver stillet til rådighed som OIOXML-baserede webservices, således at de generelt vil kunne tilfredsstille andre systemers behov for data og opdatering. OIOXML-skemaer og WSDL-beskrivelser publiceres på Digitaliser.dk OIOXML-snitflade for bygninger og boliger En af de OIOXML-snitflader, som BBR systemet stiller til rådighed, er Estate.wsdl. Baggrunden for denne snitflade er, at man ønsker at registrere og opdatere Bygninger og boliger -data i BBR ved webservicebaseret overførsel fra et eksternt system i OIOXML-format. Snitfladen giver kort sagt mulighed for fremsøgning samt opdatering af data om bygninger og boliger i BBR, herunder grunde, bygninger, opgange/indgange, etager, enheder, tekniske anlæg, rum, brugsenheder og ikke mindst byggesager OIOXML-snitfladen for adresser Snitfladen Address.wsdl dækker over BBR systemets adressedel og stiller metoder til hentning og opdatering af adgangs- og enhedsadresser til rådighed. Snitfladen for adresser kan det samme som snitfladen for adressegeometri. Adressegeometrisnitfladen er blot mere rettet mod GISleverandørerne end adressesnitfladen OIOXML-snitfladen for adressegeometri Baggrunden for denne snitflade er, at man ønsker at registrere og opdatere adressepunkter (geografiske adressekoordinater) i NYT BBR ved webservicebaseret overførsel fra et ekstern GIS eller kortsystem i OIOXML format. Adressegeometrisnitfladen stiller to operationer til rådighed: Fremsøgning af adressekoordinater Opdatering af adressekoordinater OIOXML-snitfladen Utility Snitfladen Utility.wsdl stiller funktionalitet til rådighed, som er relevant både når man benytter de øvrige ovennævnte snitflader. Snitfladen indeholder følgende funktionalitet: Hentning af alle vejnavne og vejkoder i en kommune Hentning af alle adgangsadresser i en kommune Hentning af rettigheder Hentning af kodelister Kapitel 6 version 6 Side 8 af 49

9 Eksempel på WSDL erne Alle services beskrives i et WSDL-dokument. Herunder er et eksempel på et WSDL-dokument (eksemplet er hentet fra oioxml-snitfladen Utility ). <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:wsdl=" xmlns:soap=" xmlns:http=" xmlns:xs=" xmlns:soapenc=" xmlns:mime=" xmlns:tns="urn:oio:bbr:wsdl:1.0.0" targetnamespace="urn:oio:bbr:wsdl:1.0.0" xmlns:ns="urn:oio:bbr:1.0.0"> <wsdl:types> <xs:schema targetnamespace="urn:oio:bbr:1.0.0" elementformdefault="qualified"> <xs:include schemalocation="../xsd/municipalitystreetnamesgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/municipalitystreetnamesgetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/streetnameaddressesgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/streetnameaddressesgetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entitygetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entitygetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetbyentityrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetbyentityresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entitypermissiongetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetbyentityfieldrequeststructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetbyentityfieldresponsestructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/codelistgetresponsestructure.xsd"/> <xs:include schemalocation="../xsd/entityfieldgetrequeststructure.xsd"/> <xs:include schemalocation="../xsd/entityfieldgetresponsestructure.xsd"/> </xs:schema> </wsdl:types> <wsdl:message name="municipalitystreetnamesgetrequest"> <wsdl:part name="request" element="ns:municipalitystreetnamesgetrequeststructure"/> </wsdl:message> <wsdl:message name="municipalitystreetnamesgetresponse"> <wsdl:part name="response" element="ns:municipalitystreetnamesgetresponsestructure"/> </wsdl:message> <wsdl:message name="streetnameaddressesgetrequest"> <wsdl:part name="request" element="ns:streetnameaddressesgetrequeststructure"/> </wsdl:message> <wsdl:message name="streetnameaddressesgetresponse"> <wsdl:part name="response" element="ns:streetnameaddressesgetresponsestructure"/> </wsdl:message> <wsdl:message name="entitygetrequest"> <wsdl:part name="request" element="ns:entitygetrequeststructure"/> </wsdl:message> <wsdl:message name="entitygetresponse"> <wsdl:part name="response" element="ns:entitygetresponsestructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetbyentityrequest"> <wsdl:part name="request" element="ns:entitypermissiongetbyentityrequeststructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetbyentityresponse"> <wsdl:part name="response" element="ns:entitypermissiongetbyentityresponsestructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetrequest"> <wsdl:part name="request" element="ns:entitypermissiongetrequeststructure"/> </wsdl:message> <wsdl:message name="entitypermissiongetresponse"> <wsdl:part name="response" element="ns:entitypermissiongetresponsestructure"/> </wsdl:message> <wsdl:message name="codelistgetbyentityfieldrequest"> <wsdl:part name="request" element="ns:codelistgetbyentityfieldrequeststructure"/> </wsdl:message> <wsdl:message name="codelistgetbyentityfieldresponse"> <wsdl:part name="response" element="ns:codelistgetbyentityfieldresponsestructure"/> </wsdl:message> <wsdl:message name="codelistgetrequest"> <wsdl:part name="request" element="ns:codelistgetrequeststructure"/> Kapitel 6 version 6 Side 9 af 49

10 </wsdl:message> <wsdl:message name="codelistgetresponse"> <wsdl:part name="response" element="ns:codelistgetresponsestructure"/> </wsdl:message> <wsdl:message name="entityfieldgetrequest"> <wsdl:part name="request" element="ns:entityfieldgetrequeststructure"/> </wsdl:message> <wsdl:message name="entityfieldgetresponse"> <wsdl:part name="response" element="ns:entityfieldgetresponsestructure"/> </wsdl:message> <wsdl:porttype name="utility"> <wsdl:operation name="municipalitystreetnamesget"> <wsdl:input name="municipalitystreetnamesgetrequest" message="tns:municipalitystreetnamesgetrequest"/> <wsdl:output name="municipalitystreetnamesgetresponse" message="tns:municipalitystreetnamesgetresponse"/> </wsdl:operation> <wsdl:operation name="streetnameaddressesget"> <wsdl:input name="streetnameaddressesgetrequest" message="tns:streetnameaddressesgetrequest"/> <wsdl:output name="streetnameaddressesgetresponse" message="tns:streetnameaddressesgetresponse"/> </wsdl:operation> <wsdl:operation name="entityget"> <wsdl:input name="entitygetrequest" message="tns:entitygetrequest"/> <wsdl:output name="entitygetresponse" message="tns:entitygetresponse"/> </wsdl:operation> <wsdl:operation name="entitypermissiongetbyentity"> <wsdl:input name="entitypermissiongetbyentityrequest" message="tns:entitypermissiongetbyentityrequest"/> <wsdl:output name="entitypermissiongetbyentityresponse" message="tns:entitypermissiongetbyentityresponse"/> </wsdl:operation> <wsdl:operation name="entitypermissionget"> <wsdl:input name="entitypermissiongetrequest" message="tns:entitypermissiongetrequest"/> <wsdl:output name="entitypermissiongetresponse" message="tns:entitypermissiongetresponse"/> </wsdl:operation> <wsdl:operation name="codelistgetbyentityfield"> <wsdl:input name="codelistgetbyentityfieldrequest" message="tns:codelistgetbyentityfieldrequest"/> <wsdl:output name="codelistgetbyentityfieldresponse" message="tns:codelistgetbyentityfieldresponse"/> </wsdl:operation> <wsdl:operation name="codelistget"> <wsdl:input name="codelistgetrequest" message="tns:codelistgetrequest"/> <wsdl:output name="codelistgetresponse" message="tns:codelistgetresponse"/> </wsdl:operation> <wsdl:operation name="entityfieldget"> <wsdl:input name="entityfieldgetrequest" message="tns:entityfieldgetrequest"/> <wsdl:output name="entityfieldgetresponse" message="tns:entityfieldgetresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="utility" type="tns:utility"> <soap:binding style="document" transport=" <wsdl:operation name="municipalitystreetnamesget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#municipalitystreetnamesget" style="document"/> <wsdl:input name="municipalitystreetnamesgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="municipalitystreetnamesgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> Kapitel 6 version 6 Side 10 af 49

11 </wsdl:operation> <wsdl:operation name="streetnameaddressesget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#streetnameaddressesget" style="document"/> <wsdl:input name="streetnameaddressesgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="streetnameaddressesgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entityget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entityget" style="document"/> <wsdl:input name="entitygetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entitygetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entitypermissiongetbyentity"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entitypermissiongetbyentity" style="document"/> <wsdl:input name="entitypermissiongetbyentityrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entitypermissiongetbyentityresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entitypermissionget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entitypermissionget" style="document"/> <wsdl:input name="entitypermissiongetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entitypermissiongetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="codelistgetbyentityfield"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#codelistgetbyentityfield" style="document"/> <wsdl:input name="codelistgetbyentityfieldrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="codelistgetbyentityfieldresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="codelistget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#codelistget" style="document"/> <wsdl:input name="codelistgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="codelistgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="entityfieldget"> <soap:operation soapaction="urn:oio:bbr:wsdl:1.0.0:#entityfieldget" style="document"/> <wsdl:input name="entityfieldgetrequest"> <soap:body parts="request" use="literal"/> </wsdl:input> <wsdl:output name="entityfieldgetresponse"> <soap:body parts="response" use="literal"/> </wsdl:output> Kapitel 6 version 6 Side 11 af 49

12 </wsdl:operation> </wsdl:binding> <wsdl:service name="utility"> <wsdl:port name="utility" binding="tns:utility"> <soap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions> OIOXML-snitfladerne & BBR-Kommune Der findes to adgange til BBR: BBR-Kommune, dvs. klienten, som er kommunernes webadgang til BBR Kommuneklienten, dvs. OIOXML-snitfladerne, som tilgår BBR via en service gateway Begge adgange tilgår den samme applikationsserver og har dermed adgang til samme forretningslogik. Kapitel 6 version 6 Side 12 af 49

13 Masseopdatering I forbindelse med masseopdateringer af Nyt BBR vil det være hensigtsmæssigt at benytte sig af den funktionalitet, der er stillet til rådighed via de generelle OIOXML-baserede snitflader, som sikrer at alle felter kan opdateres (for så vidt som man har autorisation til det) og at alle forretningsreglerne bliver overholdt. Kapitel 6 version 6 Side 13 af 49

14 6.3.2 Systemspecifikke snitflader Overordnede betragtninger I forbindelse med system-til-system integration er der nogle overordnede overvejelser, der skal foretages for at denne integration kan fungere så optimalt som muligt. System-til system integration vil altid introducere en ekstra kompleksitet i de implicerede systemer, hvad angår tilgængelighed, synkronisering og performance. Det vil her være hensigtsmæssigt at skelne mellem databærende og dataanvendende system. Ideelt set skal det være det databærende system, der indeholder dets data og som udstiller dem via et sæt af services, som andre systemer kan tilgå. Imidlertid giver dette problemer omkring søgning, tilgængelighed og svartider, når det anvendende system til stadighed skal tilgå. Måden hvorpå man håndterer dette er i reglen ved at introducere dataredundans i de anvendende systemer, således at de relevante data kan fremfindes på en hurtig måde, hvilket imidlertid giver et problem omkring opdateringer og pålideligheden af de relevante data. Håndteringen af problemstillingen (redundante data vs. opdaterede data) kan ske på tre forskellige måder: 1) Man opgiver dataredundans og fremfinder de relevante data i det databærende system. 2) Man lader det databærende system opdatere det eller de anvendende systemer. 3) Man anvender en publisher/subscriber mekanisme til at håndtere opdateringen, således at det data-anvendende system abonnerer på ændringer i det databærende system. På denne måde afkobles relationen mellem de to systemer og det databærende system skal ikke bekymre sig om at opdatere de anvendende systemer. Alle tre løsninger har fordele og ulemper. Vanskelighederne ved 1) har allerede været nævnt, mens 2) introducerer en kompleksitet i det databærende system, som bliver forøget betragteligt, hvis der er mange systemer der skal opdateres. Hvis blot et af de systemer der skal opdateres ikke er tilgængeligt, kan opdateringen ikke gennemføres, hvis den skal være pålidelig. I en SOA orienteret verden, er det en løsning der så vidt muligt skal undgås. 3) derimod har ikke disse vanskeligheder, til gengæld kan den ikke sikre at data er pålidelige. Nedenstående skema opsumerer de vigtigste forskelle i fordele og ulemper mellem de forskellige metoder: Pålidelighed Tilgængelighed Simpelhed 1) Ingen dataredundans ) Opdatering fra databærende system + (-) - 3) Publish/Subscribe - + (+) I forbindelse med Nyt BBR vil det være nødvendigt at inddrage disse overvejelser med hvert enkelt tilfælde af system-til-system integration. Kapitel 6 version 6 Side 14 af 49

15 Integration ud fra hændelser I det følgende beskrives overordnet hvilke systemer der integreres i forbindelse med hvilke hændelser: BBR/KMS 1) Hent GSH-oplysninger fra KMS 2) Ajourføring af adressedata 3) Hentning af matrikelkoordinater 4) Søgning af matrikel i KMS på basis af adressekoordinater 5) Søgning af matrikel i KMS på basis af bygningskoordinater BBR/ESR On-line opslag som henter hændelser fra ESR 1) Opdatering af ejerforholdskode i ESR 2) Ejerskifte 3) Opdatering af etagemeter (tinglyst areal) i ESR 4) Oprettelse af matrikel i ESR 5) Sletning af matrikel i ESR 6) Flytning af matrikler i ESR 7) Approbationer i ESR 8) Opdatering af ejerlavskoder og tekster i ESR 9) Ret udskrivningsmatrikel i ESR 10) Ret KMS_SFENR i ESR Online opslag som henter oplysninger fra ESR 11) Hent ejerforholdskode i ESR 12) Hent CPRnr/CVRnr/løbenr og alternativ adresse 13) Hent matrikelsammenhæng (København & Frederiksberg) 14) Hent ejerlejligheds-oplysninger 15) Hent ejendomsoplysninger fra ESR til Ejendomsoversigten i NYT BBR 16) Hent markering for ejerlejlighedsmatrikler fra ESR til Nyt BBR Online opslag som sender oplysninger til ESR Kapitel 6 version 6 Side 15 af 49

16 17) Ajourføring af adressedata BBR/BOSSINF 1) Hentning af offentlig støtte i BOSSINF på enhed BBR/CPR 1) Hentning af adresser ud fra CPR-nummer 2) Opslag fra CPR af adresse i Nyt BBR 3) Opdatering af Udlejningsforhold 2 ved samkøring af ESR, CPR og NYT BBR. BBR/OIS 1) Hentning af navn og adresser ud fra kommuenr. og ejendomsnr. Derudover er der nogle potentielle snitflader ud fra det notat der har erstattet de oprindelige krav. Data fra andre offentlige systemer Kræver nærmere afklaring fra KOMBIT vedrørende: Fredningsforhold og bevaringsværdi fra Kulturarvsstyrelsen Husleje/udlejningsforhold (fra ejere) Tilskud til energibesparende varmeinstallationer Oplysninger fra skorstensfejere (supplerende varme) Arbejdstilsynet. Kapitel 6 version 6 Side 16 af 49

17 Skabelon til beskrivelse af systemintegration Nedenfor præsenteres en skabelon for de services, der skal udvikles i forbindelse med Nyt BBR s integration til andre systemer samt nogle eksempler. Disse vil tjene både til udvikling og dokumentation af de udviklede services. Skabelonen er godkendt af KOMBIT som model til beskrivelse af de enkelte services. Klient <den der bruger servicen> Server <den der udfører servicen> Beskrivelse: <Overordnet beskrivelse af snitfladen> Inputparametre: <Hvilke inputparametre skal anvendes> Outputparametre: <Hvilke outputparametre skal anvendes> Entitet: <Hvilke entiteter arbejdes der på> Attributter: <Hvilke attributter> Entitet: <Hvilke entiteter arbejdes der på> Attributter: <Hvilke attributter> Betingelse: <Hvilke betingelser skal programmæssigt være opfyldt> Resultat: <Resultat af servicens eksekvering, ie. Hvilken tilstand er serveren i> Sikkerhed: <Hvilke sikkerhedsmæssige aspekter er involveret> Fejlhåndtering: <Hvorledes rapporteres fejl til klienten (afhængig af hvordan servicen implementeres)> Isolation/Uafhængighed: <Hvilken indflydelse har servicen på systemernes funktionalitet> On-line tilgængelighed: <Er det nødvendigt at informationen er tidstro> Svartider: <Er svartiden kritisk> Synkronisering: <Er sync af databaser essentiel> Kompleksitet: <Er servicen kompleks i forhold til afhængigheder, betingelser og operationer> Logistik: <Med hvem og hvad skal der aftales> Overholdelse af Kontrakten: Kommentarer: <Kommentarer i øvrigt> To Do: <Hvad skal der gøres> To Do: <Hvad skal der gøres> Status: <Status for implementering af service> Kapitel 6 version 6 Side 17 af 49

18 BBR KMS 1. Webservice GSH-oplysninger fra KMS Server KMS Beskrivelse: Webservicen skal ud fra en matrikelidentifikation returnere en liste med samtlige matrikelidentifikationer og deres geografiske sammenhæng for den samlede faste ejendom, som den kaldende matrikelidentifikation indgår i. Inputparametre: Landsejerlavskode, Matrikelnummer Outputparametre: En liste af nedenstående data for samtlige matrikler for den samlede faste ejendom, som den kaldende matrikelidentifikation indgår i: Landsejerlavskode Matrikelnummer SFE nummer GSHkode (Geografisk SammenHængskode), GSHkode en entydig kode for de matrikelnumre der er geografisk sammenhængende indenfor en samlet fast ejendom. Koden genereres af KMS. Entitet: Grund, matrikel Attributter: Betingelse: Matrikel skal eksistere Resultat: Implementering: KMS udstiller en webservice Sikkerhed: Fejlhåndtering: Status: Webservice er implementeret. Ingen udestående. Kommentarer: 2. Ajourføring af adressedata KMS Server KMS Beskrivelse: Overfører adressedata til KMS ved oprettelse af, eller ændring af adgangsadresse Inputparametre: Kommunenummer, Matrikelnummer, Ejendomsnummer, adgangsadresse Outputparametre: OK Entitet: Grund Attributter: Adgangsadresse Entitet: Matrikel Attributter: Adgangsadresse Betingelse: Matriklen skal eksistere Resultat: Matriklens adgangsadresse er ændret Implementering: KMS udstiller en webservice Kapitel 6 version 6 Side 18 af 49

19 Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis KMSs webservice er nede kan ajourføringen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMS Overholdelse af Kontrakten: Krav Kommentarer: Status: Denne webservice er endnu ikke udviklet og implementeret. KOMBIT aftaler webservice med KMS 3. Hentning af matrikelkoordinater Server KMS Beskrivelse: Leverer koordinaterne til en matrikel Inputparametre: Kommunenummer, Matrikelbetegnelse Outputparametre: Matrikelkoordinater, adressekoordinaterne samt angivelse af nøjagtighedsklasse ( B ), Teknisk standard ( UF ), kilde til geometri ( 2 ), revisionsdato ( dagsdato ), retning ( 200 ) og placering ( 5 ). Entitet: Matrikel, Adgangsadresser, Bygning Attributter: Matrikelkoordinater Entitet: Matrikel Attributter: Matrikelkoordinater Status: Webservice er implementeret. Ingen udestående. Betingelse: Matriklen skal eksistere Resultat: Adgangsadresse eller bygning får opdateret koordinater med værdierne fra KMS. Implementering: KMS udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis KMSs webservice er nede kan ajourføringen kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMS Overholdelse af Kontrakten: Krav 5.1.4, 2. punkt Kommentarer: Kapitel 6 version 6 Side 19 af 49

20 4. Søgning af matrikel i KMS på basis af adressekoordinater Klient NYT BBR Server KMS Beskrivelse: Henter matrikel i KMS på basis af adressekoordinater Inputparametre: Kommunenummer, adressekoordinater Outputparametre: Liste af matrikler indenfor koordinaterne Entitet: Attributter: Entitet: Matrikler Attributter: Matrikel Betingelse: Adressekoordinater skal eksistere Resultat: Matrikeloplysninger er hentet Implementering: KMS udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis KMSs webservice er nede kan forespørgslen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider Status: Webservice er implementeret. Ingen udestående. Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med nyt BBR Overholdelse af Kontrakten: Krav 5.1.4, 2. punkt Kommentarer: Kapitel 6 version 6 Side 20 af 49

21 5. Søgning på matrikel i KMS ud fra bygningskoordinater Server KMS Beskrivelse: Henter matrikel i KMS på basis af bygningskoordinater Inputparametre: Kommunenummer, bygningskoordinater Outputparametre: Liste af matrikler indenfor koordinaterne Entitet: Bygninger Attributter: Entitet: Matrikel Attributter: Matrikelbetegnelsen Betingelse: Bygningskoordinater skal eksistere Resultat: Matrikeloplysninger er hentet Implementering: KMS udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis nyt BBR er nede kan forespørgslen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider Status: Webservice er implementeret. Ingen udestående. Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med nyt BBR Overholdelse af Kontrakten: Krav Kommentarer: 6. Vedligeholdelse af matrikulære data i NYT BBR Matrikulære data i Nyt BBR vedligeholdes både ved hjælp af ESR og KMS s matrikelsystem minimaks. I det følgende beskrives den implementerede model: Kapitel 6 version 6 Side 21 af 49

22 minimaks København/Frederiksberg ESR Nyt BBR 4 6 1) Matrikulære ændringer sendes til ESR fra minimaks (undtagelse er København og Frederiksberg Kommune) 2) Der foretages sagsbehandling i ESR. ESR tilføjer bl.a. ejendomsnummer; alle matrikler har et ejendomsnummer tilknyttet i ESR. 3) ESR gemmer matrikulære ændringer i en hændelsestabel, hvor de bliver læst af Nyt BBR (snitflade 4 til 10 i afsnit ). 4) Nyt BBR behandler den modtagne hændelse. 5) Nogle hændelser fra ESR, fx oprettelse af en ny matrikel eller ændring af SFEnummer initierer et kald til minimaks for at hente den geografiske sammenhæng for den modtagne eller ændrede matrikel (snitflade 1 i afsnit 6.5.2). For København og Frederiksberg hentes denne geografiske sammenhæng i ESR (snitflade 13 i afsnit ). 6) Nyt BBR opdaterer matrikulære data på baggrund af den modtagne hændelse og information. Fx resulterer en oprettelse af en ny matrikel i ESR i, at matrikelnummeret tilføjes til en eksisterende grund som denne matrikel hører til eller i en oprettelse af en ny grund. Opdateringen i NYT BBR afhænger af, om der i forvejen ligger en grund, som denne matrikel skal knyttes til. Kapitel 6 version 6 Side 22 af 49

23 En sletning af et matrikelnummer resulterer i fjernelse af matrikelnummeret fra dens grund i Nyt BBR og grunden slettes hvis den ikke har andre matrikelnumre tilknyttet. ESR sikrer, at der ikke er bygninger på grunden. Eventuelle adresser på matriklen flyttes til UMAT (uden matrikel). Ud over opret- og slet-matrikel-hændelser findes der flere ESR-hændelser som initierer en opdatering af matrikulære data i Nyt BBR. De mulige hændelser som modtages fra ESR er beskrevet i kapitel Kapitel 6 version 6 Side 23 af 49

24 BBR - ESR Der kommunikeres med ESR på 3 forskellige måder: Online opslag som henter hændelser fra ESR (snitflade 1 til 10). Når der sker opdateringer i ESR, som har betydning for BBR, stiller ESR disse opdateringer til rådighed via en hændelsestabel, som BBR kan læse i via en webservice. BBR sørger for, at BBR s data opdateres med disse ændringer. Som eksempel kan nævnes, at der oprettes eller opdateres grunde i BBR som konsekvens af oprettelse eller sletning af matrikler i ESR. Et andet eksempel er bestilling af BBR-Meddelelser ved ejerskifte i ESR. Disse hændelser/snitflader er beskrevet i afsnit Online opslag som henter oplysninger fra ESR (snitflade 11 til 16) I forbindelse med sagsbehandling i BBR hentes der online ESR-oplysninger. Som eksempel kan nævnes, at der hentes BBR oplysninger i forbindelse med skærmbilledet Ejendomsoversigten. Disse kald er beskrevet i afsnit Online opslag som sender oplysninger til ESR (snitflade 17) Adresseopdateringer i BBR har betydning for ESR. Derfor sendes disse opdateringer til ESR. Dette kald er beskrevet i afsnit Online opslag, som henter hændelser fra ESR 1. Opdatering af ejerforholdskoden i ESR Server ESR Beskrivelse: Opdatering af oplysninger om opdaterede ejerforholdskoder i ESR. Når der ændres i ejerforholdskoden på en ejendom skal ESR gøre oplysningerne tilgængelige for Nyt BBR. Der er 3 hændelsestyper inden for opdatering af ejerforholdskoden i ESR: 001: ret ejerforholdskode i forbindelse med opret ejer 002: ret ejerforholdskode i forbindelse med historisk ejer 003: ret ejerforholdskode i forbindelse med ret ejer Inputparametre: - Outputparametre: (det er de samme outputparametre ved de 3 hændelsestyper) MessageType Kommunenummer Ejendomsnr EjerlejlighedsEjdnr EjendomsRef Entitet: Grund, Bygning, Teknisk anlæg, enhed Attributter: Ejerforholdskode Entitet: Ejer Attributter: Kommunenummer, Ejerforholdskode, Ejendomsnummer, Ejendomsreference, Betingelse: Resultat: Oplysninger giver mulighed for at opdatere Nyt BBR, således at grunden opdateres Kapitel 6 version 6 Side 24 af 49

25 med den nye ejerforholdskode. Er der tale om en moderejendom for ejerlejligheder skal ejerforholdet registreres for de pågældende ejerlejligheder (jf. krav 5.4.2) Status: Webservice er implementeret. Ingen udestående. Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og ejerforholdskoden ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: 2. Ejerskifte i ESR Server ESR Beskrivelse: Ejerskifte i ESR Når der foretages ejerskifte i ESR, skal ESR gøre oplysningerne tilgængelig for Nyt BBR, da det skal medføre en udskrivning af en BBR-Meddelelse. Der er 2 hændelsestyper inden for opdatering af ejerskifte i ESR: 501: ejerskifte 502: ejerskifte i forbindelse med historisk ejer Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr EjendomsRef Dcprcir Entitet: Ejendom, Grund, Bygning (ejerlejlighed), Enhed (ejerlejlighed) Attributter: Entitet: Ejendom (ejerlejlighed) Attributter: Kommunenummer, Ejendomsnummer, Ejendomsreference Betingelse: Ejerskab skal eksistere Resultat: Nyt BBR skal gøre klar til udskrivning af en BBR-Meddelelse (med årsag ejerskifte ) Implementering: ESR udstiller en service Kapitel 6 version 6 Side 25 af 49

26 Status: Webservice er implementeret. Ingen udestående. Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og ejerforholdskoden ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav 7.1, 7.7 Kommentarer: 3. Opdatering af etagemeter (tinglyst areal) i ESR Server ESR Beskrivelse: Opdatering af oplysninger om etagemeter i ESR. Når der opdateres i etagemeter (som svarer til feltet tinglyst areal i Nyt BBR) skal ESR gøre oplysningen tilgængelig for Nyt BBR. Der er 1 hændelsestype inden for opdatering af etagemeter (tinglyst areal) i ESR: 101: ret etagemeter Inputparametre: - Outputparametre: MessageType Kommunenummer EjerlejlighedsEjdnr Artskode EjendomsRef Etagemeter Entitet: Enhed (Ejerlejlighed) Attributter: Tinglyst areal Entitet: Ejendom (Ejerlejlighed) Attributter: Kommunenummer, Ejerlejlighedens Ejendomsnummer, Ejendomsreference, Etagemeter Betingelse: Resultat: Oplysninger giver mulighed for at opdatere BBR-feltet tinglyst areal med etagemeter Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Kapitel 6 version 6 Side 26 af 49

27 Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og tinglyst areal ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Status: Webservice er implementeret. Ingen udestående. Kommentarer: Kommunen vil under Systemadministration kunne vælge om oplysningen om tinglyst areal skal vises i Nyt BBR. 4. Oprettelse af matrikel i ESR Server ESR Beskrivelse: ESR opretter en matrikel. Dette skal Nyt BBR har besked om så tilsvarende matrikel automatisk oprettes i Nyt BBR. Der er 1 hændelsestype inden for opret matrikel i ESR: 201: opret matrikel Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Kms_sfenr Entitet: Grund, matrikel Entitet: Ejendom, matrikel Attributter: Fuld matrikelbetegnelse Betingelse: Ejendommen skal eksistere Resultat: Oplysninger giver mulighed for at opdatere Nyt BBR med nye matrikler Kapitel 6 version 6 Side 27 af 49

28 Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og matriklen ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: en følge af brug af ESR-matriklen (krav 5.1.1, 51.2, allonge 1, ændringsbilag 32 og 37, se beskrivelse i afsnit 6.1.2) Kommentarer: Hvis oplysningerne ikke sendes fra ESR når de opstår, vil det på ejendomme/grunde som allerede er oprettet i Nyt BBR, ikke være muligt at placere bygninger på disse matrikler, da matriklerne ikke vil komme til Nyt BBR s kendskab. Kommentarer: Status: Webservice er implementeret. Ingen udestående. 5. Sletning af matrikel i ESR Server ESR Beskrivelse: ESR sletter en matrikel. Dette skal Nyt BBR have besked om så evt. tilsvarende matrikel kan slettes i Nyt BBR. ESR tjekker i KRR om der er bygninger på matriklen (senere skal der tjekkes op mod Nyt BBR). Hvis der er bygninger på matriklen kan sletningen ikke gennemføres. Hvis der ikke er bygninger på matriklen gennemføres sletningen og der lægges en hændelse i hændelsesregisteret. Der er 1 hændelsestype inden for slet matrikel i ESR: 301: slet matrikel Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Kapitel 6 version 6 Side 28 af 49

29 Matrikel_id Entitet: Grund, matrikel Entitet: Ejendom, matrikel Attributter: Fuld matrikelbetegnelse Betingelse: Ejendommen skal eksistere Resultat: Oplysninger giver mulighed for at slette matrikler i Nyt BBR Resultat: Readonly Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og matriklen ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: en følge af brug af ESR-matriklen (krav 5.1.1, 51.2, allonge 1, ændringsbilag 32 og 37, se beskrivelse i afsnit 6.1.2) Kommentarer: Nyt BBR skal have faciliteter til at flytte en bygning fra en matrikel til en anden. Denne facilitet skal implementeres i Nyt BBR under alle omstændigheder. Bygningens placering skal synkroniseres til KRR. Kommentarer: Status: Webservice er implementeret. Ingen udestående. 6. Flytning af matrikler i ESR Server ESR Beskrivelse: Der flyttes matrikler mellem to ejendomme i ESR. Det laves mod Nyt BBR som opret og slet af matrikel, se pkt. 5 Sletning af matrikler i ESR. 7. Approbationer i ESR Server ESR Beskrivelse: De foreløbige matrikler oprettes i Nyt BBR på linje med almindelige matrikler. Se opretning af ny matrikel. Når approbationen er gennemført laves en opretning af matriklen, og en sletning af den foreløbige matrikel. Se pkt. 4 Oprettelse af matrikel i ESR og pkt. 5 Sletning af matrikler i ESR. Kapitel 6 version 6 Side 29 af 49

30 8. Opdatering af ejerlavskoder og tekster i ESR Server ESR Beskrivelse: ESR opdaterer i ejerlavskoder og tekster. Følgende skal gøres tilgængelig for Nyt BBR: Oprettelse af eller ændring i landsejerlavskode Oprettelse af eller ændring i landsejerlavstekst Oprettelse af eller ændring i kommunal ejerlavskode Der er 3 hændelsestyper inden for opdatering af ejerlavskoder og tekster i ESR: 401: ret ejerlavskode og tekster 402: opret ejerlavskode og tekster 403: slet ejerlavskode og -tekster Inputparametre: - Outputparametre: MessageType Gl_Kommunenummer Gl_Landsejerlavskode Gl_Landsejerlavstekst Gl_KomEjerlavskode Gl_KomEjerlavstekst Ny_kommunenummer Ny_landsejerlavskode Ny_landsejerlavstekst Ny_ejerlavskode Ny_ejerlavstekst Resultat: Oplysninger giver mulighed for at opdatere Nyt BBR med landsejerlavskode, landsejerlavstekst og kommunale ejerlav Entitet: Landsejerlav, kommunalt ejerlav Attributter: Landsejerlavskode, landsejerlavstekst, kommunal ejerlavskode Betingelse: Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og ejerlavet ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: Første gangs indlæsning i Nyt Kommentarer: Kapitel 6 version 6 Side 30 af 49

31 BBR skal ske via konverteringen. Status: Webservice er implementeret. Ingen udestående. 9. Ret udskrivningsmatrikel i ESR Server ESR Beskrivelse: Opdaterer oplysninger om udskrivningsmatriklen i ESR. Der er 1 hændelsestype inden for ret udskrivningsmatrikel i ESR: 102: ret udskrivningsmatrikel Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Kms_sfenr Entitet: Enhed (Ejerlejlighed) Attributter: Tinglyst areal Entitet: Matrikel Attributter: Kommunenummer, Ejerlejlighedens Ejendomsnummer, Ejendomsreference, Etagemeter Betingelse: Resultat: Oplysninger giver mulighed for at opdatere BBR-feltet tinglyst areal med etagemeter Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og tinglyst areal ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroniseringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Kapitel 6 version 6 Side 31 af 49

32 Status: Webservice er implementeret. Ingen udestående. Overholdelse af Kontrakten: Kommentarer: Kommunen vil under Systemadministration kunne vælge om oplysningen om tinglyst areal skal vises i Nyt BBR. 10. Ret KMS_SFENR i ESR Server ESR Beskrivelse: Opdaterer oplysninger om KMS_SFENR i ESR. Der er 1 hændelsestype inden for ret KMS_SFENR i ESR: 103: ret KMS_SFENR Inputparametre: - Outputparametre: MessageType Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Udskrivningsmatr Matrikel_id Kms_sfenr Entitet: Enhed (Ejerlejlighed) Attributter: Tinglyst areal Entitet: Matrikel Attributter: Kommunenummer, Ejerlejlighedens Ejendomsnummer, Ejendomsreference, Etagemeter Betingelse: Resultat: Oplysninger giver mulighed for at opdatere BBR-feltet tinglyst areal med etagemeter Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om ESR er nede og tinglyst areal ikke er opdateret. ESR kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er asynkron. Svartider: Intet overhead Synkronisering: Der kan være minimale synkroni- Kapitel 6 version 6 Side 32 af 49

33 Status: Webservice er implementeret. Ingen udestående. seringsproblemer, da opdateringen er asynkron Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Kommentarer: Kommunen vil under Systemadministration kunne vælge om oplysningen om tinglyst areal skal vises i Nyt BBR On-line opslag, som henter oplysninger fra ESR 11. Hent ejerforholdskode i ESR Server ESR Beskrivelse: Henter oplysninger om ejerforholdskode i ESR. Når Nyt BBR opretter en grund skal ejerforholdskoden hentes i ESR. Når Nyt BBR opretter en enhed, bygning eller teknisk anlæg som er en ejerlejlighed, skal ejerforholdskoden hentes i ESR. Inputparametre: Kommunenummer, Ejendomsnummer, Ejerlejlighedsejendomsnummer (udfyldes ved artskode 02 og 32), Ejendomsreference Outputparametre: Kommunenummer, Ejendomsnummer, Ejerlejlighedsejendomsnummer (udfyldes ved artskode 02 og 32), Ejendomsreference, Ejerforholdskode Entitet: Grund, Bygning, Teknisk anlæg, Enhed (ejerlejlighed) Attributter: Entitet: Ejendom Attributter: Kommunenummer, Ejendomsnummer, Ejerlejlighedsejendomsnummer, Ejendomsreference, Ejerforholdskode Betingelse: Ejendommen skal eksistere Resultat: De hentede oplysninger giver mulighed for at opdatere Nyt BBR med oplysningerne, således at grunden opdateres med ejerforholdskode. Er der tale om en moderejendom for ejerlejligheder skal ejerforholdet registreres for de pågældende ejerlejligheder (jf. krav 5.4.2) Implementering: ESR udstiller en service til hentning af ejerforholdskoden Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Oprettelsen af entiteten kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kapitel 6 version 6 Side 33 af 49

34 Status: Webservice er implementeret. Ingen udestående. Kommentarer: 12. Hent CPRnr/CVRnr/løbenr og alternativ adresse Server ESR Beskrivelse: Henter ejers CPRnr/CVRnr/løbenr i forbindelse med udskrivning af fx BBR-Meddelelse. I forbindelse med udlejningsforhold dannes der desuden et udtræk, der skal sammenholdes med udtræk fra CPR. Inputparametre: Kommunenummer, Ejendomsnummer, Ejertype (altid a ) Outputparametre: Liste af Ejeres CPR-numre eller CVR-numre eller løbenr samt alternativ adresse. Samt om adressen er adressebeskyttet. Markering for administrator eller ejer. Ejertype (kun for ejere). Administratorkode (kun for adminstratorer) Entitet: Bygning, enhed Attributter: Entitet: Ejer, ejendom Attributter: CPRnr eller CVRnr eller løbenr og alternativ adresse Betingelse: Ejendommen skal eksistere Resultat: Liste af ejere. Der kan kaldes videre til OIS for at få navn og adresse til adressering af fx BBR-Meddelelser. Status: Webservice er implementeret. Ingen udestående. Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Udskrivningen af ejermeddelelse kan ikke gennemføres/ajourføringen af Udlejningskode kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: krav 7.2, EBST nota med ændringer til krav 5.3 Kommentarer: Kapitel 6 version 6 Side 34 af 49

35 13) Hent matrikelsammenhæng (Kbh & Frederiksberg) Server ESR Beskrivelse: Webservicen skal ud fra en matrikelidentifikation returnere en liste med samtlige matrikelidentifikationer, som hører til den samme faste ejendom som den kaldende matrikelidentifikation. For København udledes matrikelsammenhænget ud fra feltet SamletFastEjendom. For Frederiksberg udledes matrikelsammenhænget ud fra feltet Noteringskode. Inputparametre: Landsejerlavskode, Matrikelnummer Outputparametre: En liste af nedenstående data for samtlige leverede matrikler: Landsejerlavskode Matrikelnummer (nr og bogstav) SFE nummer Noteringskode Entitet: Grund, matrikel Attributter: Betingelse: Matrikel skal eksistere Resultat: Implementering: ESR udstiller en webservice Sikkerhed: Fejlhåndtering: Status: Webservice er implementeret. Ingen udestående. Kommentarer: 14) Hent ejerlejligheds-oplysninger Server ESR Beskrivelse: Ved oprettelse af en ejerlejlighed hentes ejerlejlighedsoplysninger fra ESR. Samtidig kontrolleres det at ejerlejligheden eksisterer i ESR Inputparametre: Kommunenummer, matrikelnummer, ejerlejlighedsejendomsnr. Outputparametre: Ejerlejlighedsnr., etagemeter, ejerforholdskode, liste af matrikelbetegnelser Entitet: Enhed, Bygning, Teknisk Anlæg Entitet: Ejendom, matrikel Attributter: Fuld matrikelbetegnelse, etagemeter, ejerforholdskode Betingelse: Ejendommen skal eksistere Resultat: Enheden (ejerlejligheden) kan opdateres med aktuelle ejerlejlighedsoplysninger. Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Kapitel 6 version 6 Side 35 af 49

36 Isolation/Uafhængighed: Oprettelse af grund kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Krav Kommentarer: Matrikelbetegnelsen skal ikke benyttes direkte i Nyt BBR, men videre i synkroniseringen med KMD-BBR (og KKR). Hvis der i Nyt BBR flyttes en bygning indeholdende ejerlejligheder - fra en matrikel til en anden matrikel skal der på ny hentes oplysninger om ejerlejligheden. Kommentarer: Status: Webservice er implementeret. Ingen udestående. 15) Hent ejendomsoplysninger fra ESR til Ejendomsoversigten i NYT BBR Server ESR Beskrivelse: Ved dannelse af Ejendomsoversigten hentes matrikel- og planoplysninger i ESR. Inputparametre: Kommunenummer Ejendomsnr. Landsejerlavskode Ejerlavskode Matrikelnr Matrikelbogstav Delnr Opdelingsnr Artskode Outputparametre: Returkode Systemkode Tekst Ejerlavskode Matrikelnr Matrikelbogstav Delnr Opdelingsnr Artskode Zonestatus Cnote (noteringskode) Udskrivningsmatr Fmatar (matrikelareal) Fvej (Heraf vejareal) Fdivar (Diverse areal) Plantype Plantypetekst Plannr Plannavn Entitet: Grund Entitet: Matrikel Attributter: Kapitel 6 version 6 Side 36 af 49

37 Resultat: Betingelse: Ejendommen skal eksistere Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Oprettelse af grund kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Appendiks 1 i Allonge 1 - Ekstra krav og Ejendomsoplysninger. Kommentarer: Kommentarer: Status: Webservice er implementeret. Ingen udestående. 16) Hent markering for ejerlejlighedsmatrikler fra ESR til Nyt BBR Server ESR Beskrivelse: Hent markering for ejerlejlighedsmatrikler fra ESR til Nyt BBR Inputparametre: Kommunenummer Ejendomsnr Ejerlavskode Matrikelnr Matrikelbogstav Delnr Ejerlejlighedsnr Opdelingsnr Artskode Outputparametre: Matrikelmarkering Returkode Systemkode Tekst Entitet: Grund Entitet: Matrikel Attributter: Betingelse: Ejendommen skal eksistere Resultat: Implementering: ESR udstiller en service Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Kapitel 6 version 6 Side 37 af 49

38 Isolation/Uafhængighed: Oprettelse af grund kan ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med KMD/ESR Overholdelse af Kontrakten: Appendiks 1 i Allonge 1 - Ekstra krav og Ejendomsoplysninger. Kommentarer: Kommentarer: Status: Webservice er implementeret. Ingen udestående On-line opslag, som sender oplysninger til ESR 17) Ajourføring af adressedata ESR Server ESR Beskrivelse: Overfører adressedata til ESR ved oprettelse af, eller ændring af adgangs- eller enhedsadresse Inputparametre: Kommunenummer, Matrikelnummer, Ejendomsnummer, adresse (adgangs- eller enhedsadresse) Outputparametre: OK Entitet: Attributter: Entitet: Adgangs- og Enhedsadresse Attributter: Betingelse: Status: Webservice er implementeret. Ingen udestående. Resultat: ESR adressedata opdateres Implementering: ESR udstiller en webservice Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis ESRs webservice er nede kan ajourføringen ikke gennemføres On-line tilgængelighed: Operationen er tidstro Svartider: Der vil være et overhead i form af et kald til et eksternt system Synkronisering: Ingen synkroniseringsproblemer Kompleksitet: Simpel Logistik: Aftales med ESR Overholdelse af Kontrakten: Krav Kommentarer: Kapitel 6 version 6 Side 38 af 49

39 BBR Bossinf-STB Overførsel af kode for offentlig støtte til Nyt BBR Server Bossinf Beskrivelse: Opdatering af kode for offentlig støtte i Nyt BBR Inputparametre: Outputparametre: Offentlig støtte (ja/nej) Entitet: Enhed Attributter: offentlig støtte Entitet: Ejendom Attributter: Offentlig støtte Betingelse: Enheden skal eksistere Resultat: Enheden opdateres med den angivne kode Implementering: Bossinf udstiller en hændelsestabel som Nyt BBR tilgår via en webservice. Sikkerhed: Autentificering er nødvendig Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Nyt BBR kan fungere selv om Bossinf er nede og offentlig støtte ikke er opdateret. Bossinf kan fungere selv om Nyt BBR er nede. On-line tilgængelighed: Operationen er ikke nødvendigvis tidstro, afhængig af implementering Synkronisering: Der kan være synkroniseringsproblemer, hvis opdateringen ikke er tidstro Kompleksitet: Simpel Overholdelse af Kontrakten: Krav Kommentarer: Koden overføres ikke til KMD- BBR i dag. To Do: Kommune Holding afklarer med Bossinf om overførslen Kapitel 6 version 6 Side 39 af 49

40 BBR CPR 1. Hentning af navn og adresse ud fra CPR-nummer Server CPR Beskrivelse: I forbindelse med adressering af bl.a. BBR-Meddelelse skal man bruge ejerens navn og adresse. Inputparametre: CPR-nummer Outputparametre: Navn og Adresse Entitet: Flere Attributter: Entitet: Flere Attributter: Navn og Adresse Betingelse: Resultat: Mulighed for at påtrykke navn og adresse på bl.a. BBR-Meddelelse. Sikkerhed: Autorisation ud fra brugernavn og password. Fejlhåndtering: En fejlkode til klienten Isolation/Uafhængighed: Hvis man ikke kan foretage opslaget, så er det ikke muligt at få oversat CPRnr og dermed ikke muligt at adressere bl.a. BBR-Meddelelse. On-line tilgængelighed: Ikke nødvendigvis tidstro. Svartider: I forbindelse med masseudskrivninger er svartiden kritisk. Synkronisering: Nej Kompleksitet: Nej Logistik: KH stiller snitfladerne til rådighed. Overholdelse af Kontrakten: Kommentarer: Servicen benyttes kun hvis der er adressebeskyttelse (da navn og adresse da ikke kan leveres fra OIS) eller det ikke er ejeren man skal adressere til. To Do: To Do: KH aftaler med CPR. Status: Webservice er implementeret. Ingen udestående. Kapitel 6 version 6 Side 40 af 49

41 2. Opslag fra CPR af adresse i Nyt BBR Klient CPR Server Nyt BBR Beskrivelse: I forbindelse med flytningen af boligregisteret til Nyt BBR skal CPR fremover have adgang til hvilke adresser der er oprettet i Nyt BBR via en snitflade. Inputparametre: Adresse Outputparametre: Oplysning om, om adressen findes Entitet: Adgangs- og enhedsadresse Attributter: Entitet: Adgangs- og enhedsadresse Attributter: Betingelse: Resultat: Sikkerhed: Krypteret forbindelse med autorisation via certifikat. Fejlhåndtering: Fejl logges på klienten. Isolation/Uafhængighed: Der kan opstå inkonsistens, hvis CPR ikke oplyses om at en given adresse ikke findes i Nyt BBR. On-line tilgængelighed: Systemet bruges til her og nu opslag ved CPR. Svartider: Forsinkelser i svartider opleves hos CPR. Synkronisering: Den er ønskværdig, men ikke kritisk. Kompleksitet: Lav Logistik: Nyt BBR stiller WebService til rådighed for CPR. Overholdelse af Kontrakten: Kommentarer: Data leveres i OIOXML. To Do: To Do: Status: Det er aftalt, at folkeregisteret skal tilgå BBR-data via de generelle OIOXML-snitflader Kapitel 6 version 6 Side 41 af 49

42 3. Opdatering af Udlejningsforhold ved samkøring af ESR, CPR og Nyt BBR Server CPR, ESR Beskrivelse: I forbindelse med opdatering af udlejningsforhold sammenkøres udtræk fra CPR og ESR med data fra Nyt BBR. Inputparametre: Outputparametre: Udtræk af alle ejere og lejere i CPR. Entitet: Attributter: Entitet: Attributter: Udlejningsforhold Betingelse: Resultat: Opdatering af udlejningsforhold i Nyt BBR. Sikkerhed: Overførsel af data sker via FTPS. Fejlhåndtering: I forbindelse med kørslen udskrives en fejlliste. Isolation/Uafhængighed: Alle systemer er nødvendige. On-line tilgængelighed: Dette er en batch-kørsel. Svartider: Nej Synkronisering: Nej Kompleksitet: Middel Logistik: Data overføres fra ESR og CPR i flade filer til Nyt BBR. Her læses de ind i Nyt BBR i tilknyttede tabeller. Efter indlæsningen køres der en stored procedure der opdaterer udlejningsforhold. Overholdelse af Kontrakten: Kommentarer: To Do: To Do: Status: Webservice er implementeret. Ingen udestående. Opdatering af udlejningsforhold sker ved samkøring af ESR, BBR og CPR. I opdatering af udlejningsforhold indgår 3 datasæt: Udtræk fra ESR som indeholder kommunenr, ejendomsnr, ejerlejlighedsnr og CPRnr. Dette hentes via FTPS på en FTP-server hos KMD. Udtræk fra CPR som indeholder oplysninger om CPRnr. og adresse. Dette hentes via FTPS på en FTP-server hos CSC. Udtræk fra Nyt BBR som indeholder kommunenr, ejendomsnr, ejerlejlighedsnr, adresse, boligtypekode og anvendelseskode. Kapitel 6 version 6 Side 42 af 49

43 Når ESR-udtrækket er hentet, læses det ind i tabel ESR_Ejer i database JR5000PD i Nyt BBR via et SSIS job. Når udtrækket fra CPR er hentet, læses det ind i tabel CPR_Adresse i database JR5010PD i Nyt BBR via det job, som indlæser og opdaterer data fra CPR. Jobbet hedder OpdaterCPRData.exe. Når data er indlæst køres stored procedure bbr_domain.usp_enhedupdatebatchudlejningsforhold2, som herefter opdaterer kolonnen Udlejningsforhold2 i tabellen Enhed. Proceduren opdaterer udlejningsforhold med én af følgende værdier: 1. Udlejet 2. Benyttet af ejer 3. Ikke benyttet Først opsættes kode 3. Hvis BBR-enheden ikke er i CPR_Adresse tabellen. Derefter opsættes kode 2, hvis et CPR nummer fra CPR_Adresse, der bebor en enhed, matcher tabellen ESR_ejer på den pågældende ejendom. De resterende sættes til kode 1. Tabellerne ESR_ejer, BBR_Adresse og CPR_Adresse er arbejdstabeller og indgår derfor ikke i den logiske datamodel. Kørslen vil ske 3 gange årligt (april, september og december). Kapitel 6 version 6 Side 43 af 49

44 Kapitel 6 version 6 Side 44 af 49