1 Aansluitspecificaties Kennisgevingen - init levering ... · 1.0.0 04-05-2007 RJ definitief...

Versie 1.0.6 11 januari 2010

Aansluitspecificaties Kennisgevingen Deel 1: Initiële levering, communicatie- en berichtenhandboek

Dienst Persoons- en Geo-informatie

Gemeente Amsterdam Dienst Persoons- en Geo-informatie Aansluitspecificaties Kennisgevingen


3

Voorwoord

Dienst Persoons- en Geo-informatie (DPG) voert de basisregistraties adressen, gebouwen, percelen en topografie voor de gemeente Amsterdam. Haar systeem DIstributie Vastgoed Amsterdam (DIVA) ontsluit deze gegevens voor afnemers van deze basisregistraties. Deze aansluitspecificaties beschrijven voor afnemers hóe met DIVA te communiceren, en wát met DIVA te communiceren. De aansluitspecificaties documentatie bestaat uit meerdere delen: Deel 1: initiële levering, communicatie- en berichtenhandboek. Het 1e gedeelte hiervan

beschrijft de initiële levering die voor afnemers nodig is om te komen tot de nulstand die voorwaarde is om een aansluiting live te laten gaan. Het 2e gedeelte beschrijft communicatie met DIVA d.m.v. web services en het 3e beschrijft de uit te wisselen berichten.

Deel 2: het gegevenswoordenboek. Deze beschrijft alle gegevens die DIVA kan leveren. Dit deel is weer opgesplitst in twee documenten a en b. Deel 2a bevat alle entiteiten die DIVA levert en alle informatie daarover, deel 2b bevat een uitgebreide beschrijving van alle attributen die horen bij deze entiteiten.

DIVA ontsluit haar gegevens zowel via een kennisgeving service, als via een vraag/antwoord service. Dit document betreft primair de levering van gegevens door middel van de kennisgeving service. Naar de vraag/antwoord service wordt waar relevant wel verwezen, maar deze is vooralsnog niet gerealiseerd.



5

Inhoud

Voorwoord 3

Documentversies 8

1 Inleiding 11 1.1 DIVA 11 1.2 Uitgangspunten 12 1.3 Opbouw van dit document 12 1.4 Toegepaste versies 13

2 Initiële leveringen 14

3 Communicatiehandboek 16 3.1 Het Lagenmodel 16 3.2 Laag 1: Transport 18 3.2.1 SOAP-berichten 18

3.2.2 Transportfouten en afhandeling 18

3.3 Laag 2: Bericht 20 3.3.1 StUF 20

3.3.2 Domeinspecifieke uitbreidingen op StUF 20

3.3.3 StUF foutBerichten 21

3.4 Laag 3: Interactie 22 3.4.1 Functionaliteit 22

3.4.2 Functionele eisen 23

3.4.3 Interactieproces 24

3.4.4 WSDL; beschrijving web service afnemer 27

3.5 Versiebeheer StUF web services 29 3.6 Informatiebeveiliging DIVA 32

4 Berichtenhandboek 34 4.1 Gegevensgroepen 34 4.2 XML schema’s / DIVA XSD 36 4.3 Soorten berichten 40 4.3.1 berichttypen 40



6

4.3.2 Stuurgegevens 43

4.3.3 Mutatiesoorten 45

4.3.4 Interpretatie van de kennisgevingsberichten 46

4.3.5 Sleutelgebruik 53

4.4 Entiteiten 55 4.4.1 Openbare Ruimte (OPR) 61

4.4.2 Woonplaats (WPL) 63

4.4.3 Gemeente (GME) 65

4.4.4 Stadsdeel (SDL) 66

4.4.5 Buurt (BRT) 67

4.4.6 Bouwblok (BBK) 69

4.4.7 Pand (PND) 70

4.4.8 Ligplaats (LIG) 72

4.4.9 Standplaats (STA) 74

4.4.10 Verblijfsobject (VBO) 76

4.4.11 Kadastraal Object (KOT) 79

4.4.12 Filiatie (FLE) 82

4.4.13 Zakelijk Recht (ZRT) 83

4.4.14 Transactie (TTE) 85

4.4.15 Kadastraal Subject (KST) 87

4.4.16 Subject Relatie 91

4.4.17 Belemmering Kadastraal Object 92

4.4.18 Belemmering Zakelijk Recht 94

4.4.19 Register 9 Kop 95

4.4.20 Register 9 Tekst 97



7

4.4.21 Rente 98

4.4.22 Onzelfstandig Deel 99

4.4.23 tabelentiteiten 100

4.5 Voorbeeldberichten 101

Bijlage 1 Testen ontvangst applicatie 102

Bijlage 2 Afkortingen 103

Bijlage 3 E-net acties 106

Bijlage 4 Terugmelding van fouten 108 4.1 Terugmeldproces vastgoed gegevens 108 4.2 Terugkoppelen van incidenten met de aansluiting 108

Bijlage 5 Handreiking bij beëindiging van objecten 109

Bijlage 6 Wijzigingsprocedure van aansluitspecificaties 110

Bijlage 7 Bronnen 111 7.1 Documenten 111 7.2 Hyperlinks 111



8

Documentversies

versie datum auteur status omschrijving

0.1 JdV concept Initiële versie

0.2 JdV concept correcties

0.9 JdV, AO,

NdG, AW

concept Voorlaatste concept

0.9.1 JdV concept Bijgewerkt naar XSD’s 200611

0.9.5 31-03-2007 RJ concept Herstructurering aansluitspecificaties;

Gegevenswoordenboek volledig gelijklopend gemaakt met DIVA xsd

jan07;

Verwerking nieuwe inzichten n.a.v. overleggen DPG intern en met

afnemers. 0.9.6 10-05-2007 RJ, ET concept Uitbreiding van informatie over StUF stuurgegevens (§Fout!

Verwijzingsbron niet gevonden.); StUF foutberichten paragraaf aangepast (§3.3.3 );

Kleine uitbreiding van §3.4.3 (Interactieproces);

Herziening van alle plaatjes bij hoofdstuk Fout! Verwijzingsbron niet gevonden.;

Uitbreiding van §Fout! Verwijzingsbron niet gevonden.(Fout! Verwijzingsbron niet gevonden.);

Kleine aanpassingen aan §Fout! Verwijzingsbron niet gevonden.(Fout! Verwijzingsbron niet gevonden.) ter

verduidelijking datum cycli.

Toevoeging van informatie m.b.t. sleutelgebruik (§Fout! Verwijzingsbron niet gevonden.);

Voorbeeld testsets uitgewerkt (§4.5 + ‘3. Aansluitspecificaties DIVA -

Testsets cq Voorbeeldberichten v1.0.0.zip’);

1.0.0 04-05-2007 RJ definitief Compatibiliteit DIVA – xsd – aansluitspecificaties toegevoegd in

versiebeheer.

Kleine correcties n.a.v. interne review GVI.

1.0.1 14-11-2007 RJ concept Bijlage 1 aangepast op basis van testplan aansluiten.

Juiste servers en ip-adressen ingevoerd in Bijlage 3,

Figuur 83.

Toelichting bij stuurgegeven ‘sectormodel’ in Fout! Verwijzingsbron niet gevonden..

1.0.3 23-02-2009 JVR definitief Berichtvolgorde aangepast

Namespace verwijzing aangepast

Uitleg gebruik n:m relaties uitgebreid



9

1.0.4 14-09-2009 JVR concept Gebruik UVA2 aangepast

Gebruik waarde onbekend toegevoegd

Gebruik tabelentiteiten toegevoegd

Wijzigingsproces aansluitspecificaties toegevoegd

Tekstuele aanpassingen

1.0.5 06-10-2009 JVR definitief Gebruik tabelentiteiten gewijzigd

Toelichting Sleutelgebruik

Handreiking bij beëindiging toegevoegd

1.0.6 12-01-2010 RV definitief Huisstijlaanpassingen



10

Compatibiliteit DIVA – DIVA xsd – Aansluitspecificaties

DIVA versie DIVA xsd versie Aansluitspecificaties versie 1.0.1 (release candidate) 2007/01 0.9.5 (concept)

0.9.6 (concept) 1.0.0 (definitief)

1.0.3 2007/01 1.0.0 (definitief) 1.0.4 1.1.0

2008/11 1.0.3 (definitief)

2008/11 1.0.4 (concept) 2008/11 1.0.5 (definitief)



11

1 Inleiding

1.1 DIVA

DPG is verantwoordelijk voor het beheer en de distributie van vier basisregistraties: De basisregistratie adressen; De basisregistratie gebouwen; De basisregistratie percelen (afkomstig van het Kadaster); De basisregistratie topografie (kleinschalig en grootschalig).

Daarnaast heeft DPG ook aanvullende gegevensverzamelingen zoals luchtfoto’s, cyclorama’s etc. Deze gegevens worden op verschillende manieren aan afnemers geleverd door middel van het distributiesysteem DIVA (Distributie Vastgoed Amsterdam), zoals Figuur 1 laat zien.

Figuur 1 Overzicht DIVA applicatie.

In de distributielaag worden drie manieren van distributie gehanteerd: 1. Kennisgevingen: DPG stuurt mutatiemeldingen naar afnemers die deze verwerken in

hun eigen gegevensbestanden. 2. Vraag/antwoord: een extern systeem vraagt op het moment dat het nodig is,

gegevens op uit het magazijn en krijgt direct antwoord terug (synchroon). 3. Levering van bestanden: verschillende media (Cd-rom, FTP, gedrukte kaarten etc.). Kennisgevingen en Vraag / Antwoord distributie vindt plaats door middel van op StUF1 en Webservice standaarden gebaseerde automatische koppelingen.

1 Zie http://www.egem-iteams.nl/stuf-gebruik.

Webservices

Magazijn

Vraag / antwoordKennisgevingen Leveringen

AtlasExterne applicaties Afnemers



12

DPG heeft in eerste instantie kennisgevingen ontwikkeld. De specificaties van DIVA kennisgevingsberichten zijn in dit document opgenomen. De specificaties van Vraag / Antwoord berichten zullen in een later stadium worden opgenomen. 1.2 Uitgangspunten

De volgende uitgangspunten zijn bij het ontwerp van de aansluiting gehanteerd: 1 De berichtenuitwisseling wordt door middel van webservice technologie gerealiseerd. 2 DPG maakt gebruik van StUF2.04 voor de inhoud (payload) van de berichten. 3 DPG maakt gebruik van WSDL en SOAP voor de service specificatie en envelop (het

communicatieprotocol) van de berichten. 4 DPG bepaalt het WSDL en bijbehorende XSD welke de ontvangende web service van

afnemers dient te implementeren om de koppeling te realiseren. 5 DPG breidt de EGEM XSD van StUF-BG uit en stelt de XSD’s beschikbaar aan de

afnemer voor het valideren van de te ontvangen berichten. 6 DPG maakt gebruik van een catalogus BRA en BGR op basis van concept EGEM

Referentiemodel voor gemeentelijke basisregistraties (GFO 2006). Hierop baseert zij haar eigen DIVA uitlevermodel en bijbehorend gegevenswoordenboek.

1.3 Opbouw van dit document

Als een afnemer kennisgevingsberichten wil kunnen ontvangen moet deze een ontvangende web service inrichten waarheen DPG de kennisgevingsberichten kan versturen. Bij de inrichting van een dergelijke service is kennis nodig over: de beginsituatie waarvan de service uit moet gaan, de specificaties waaraan de service moet voldoen, de structuur en inhoud van de verschillende soorten berichten, het onderliggende gegevensmodel.

Hoofdstuk 2 beschrijft het proces van initiële leveringen dat nodig is om de zgn. nulstand te bereiken die voorwaarde is voor het starten van de kennisgeving koppeling. Hoofdstuk Fout! Verwijzingsbron niet gevonden.bevat het communicatiehandboek, welke definieert hóe gecommuniceerd moet worden met DIVA. Het uitlevermodel van gegevens en de verschillende typen berichten staan apart beschreven in hoofdstuk Fout! Verwijzingsbron niet gevonden.: berichtenhandboek. Hier wordt gedefinieerd wát er met DIVA wordt gecommuniceerd. Het gegevenswoordenboek van het onderliggende gegevensmodel is in aparte documenten 2a en 2b ondergebracht.



13

1.4 Toegepaste versies

In de aansluiting die dit document beschrijft, zijn de volgende versies standaarden, specificaties, etc. toegepast: SOAP: 1.1 StUF: 02.04, ReferentieStelsel Gemeentelijke Basisgegevens (RSGB): 0.7 DIVA sectormodel: 2008_11



14

2 Initiële leveringen

Nulstand Belangrijk onderdeel van het aansluittraject van DIVA afnemers is het gelijktrekken van alle vastgoed gegevens die de afnemer heeft met alle vastgoed gegevens in DIVA. Het betreft dan wel enkel díe gegevensgroepen2 die de afnemer ook daadwerkelijk gaat opslaan en gebruiken in haar bedrijfsprocessen. Wanneer de gegevens van de afnemer gelijklopen met DIVA spreekt men van de zgn. nulstand. Wanneer deze nulstand is bereikt zal DIVA starten met het aanmaken (en verzenden) van dagelijkse mutatieberichten voor de afnemer. Het komen tot de juiste nulstand d.m.v. de initiële levering, als laatste stap in de bestandsschoning, wordt beschouwd als apart deelproject van het aansluiten. Exacte specificatie, bouw (conversiescripts) en testen kent daarbij een eigen parallel traject met eigen oplever en acceptatiemomenten. De juiste nulstand is randvoorwaarde voor een correcte start van de koppeling. Initiële levering Het onderwerp ‘initiële levering’ betreft de uit te wisselen gegevens en de processen om deze te verkrijgen aan DIVA zijde en te verwerken aan afnemer zijde. Het einddoel van een initiële levering is het bereiken van een nulstand. DPG biedt een initiële levering in de vorm van UVA2 bestanden:

UVA2 levering. DPG maakt platte tekstbestanden aan met daarin alle entiteiten en attributen die DIVA bevat. Deze bestanden lijken qua bestandsformaat op de huidige UVA3 levering, maar is qua gegevensmodel volledig anders, namelijk afgestemd op de DIVA entiteiten en attributen. Voordeel van dit formaat is dat het volledig database onafhankelijk is. De afnemer zal een procedure moeten opstellen en script(s) moeten schrijven om haar eigen database te vullen op basis van de gegevens in deze bestanden. Het proces loopt in deze als volgt:

• DPG maakt de benodigde bestanden aan (UVA2). • DPG levert de bestanden aan de afnemer. • Afnemer schrijft scripts om de DIVA dataset te matchen met haar eigen

gegevens. • Afnemer neemt nieuwe gegevens (o.a. technische sleutels) over uit de DIVA

dataset. • Geconstateerde afwijkingen worden met DPG afgestemd.

Een UVA2 levering bestaat uit meerdere bestanden, een voor elke tabel in DIVA. Per entiteit tabel, code tabel, relatie tabel wordt een bestand aangemaakt. Deze

2 Zie paragraaf 4.1 voor een beschrijving van de gegevensgroepen. 3 Uitwisselingsformaat Vastgoed Amsterdam



15

bestanden zijn gecombineerd per gegevensgroep. De afnemer kan aangeven in welke gegevensgroep zij geïnteresseerd is, dan zal DPG enkel de bestanden leveren die hierop van toepassing zijn. Een UVA2 levering kan rekening houden met historische en toekomstige gegevens. Voor het bereiken van de nulstand is het van belang dat een levering met de volledige administratie gebruikt wordt, waarin alle historische en toekomstige levenscycli van de gegevens zijn opgenomen. Alleen met deze levering kan een correcte nulstand worden bereikt.

Voor volledige informatie m.b.t. UVA2 bestandlevering: zie UVA2 productbeschrijving4. Reset Het kan voorkomen dat kennisgevingsberichten niet (goed) verwerkt worden, waardoor de gegevenssets van DPG en de afnemers uit elkaar gaan lopen. Ook nieuwe berichten kunnen daardoor mogelijk niet goed meer verwerkt worden. De enige manier waarop dit gecorrigeerd kan worden, is door opnieuw de nulstand te bereiken met een initiele levering. Dit is in feite een reset op de berichtverwerking. DPG adviseert afnemers ieder half jaar zo’n reset uit te voeren, of tenminste de technische mogelijkheid te hebben om dit ieder half jaar te doen.

4 Verkrijgbaar op http://www.gvi.amsterdam.nl/diva.



16

3 Communicatiehandboek

3.1 Het Lagenmodel

De verschillende aspecten van de aansluiting op de kennisgevingen van DPG zijn in dit document in verschillende lagen ondergebracht (zie figuur).

afnemerGVI

(DIVA) bericht

transport

interactie

Figuur 2 Lagenmodel. Naar [VROM].

De lagen zijn: 1 Transportlaag

Dit is de technische laag waarover alle communicatie gaat. Het is een laag op framework niveau. De transportlaag is gebaseerd op algemene (open) internet standaarden en is niet specifiek voor DPG.

2 Berichtenlaag Hierin wordt de berichtendefinitie uitgewerkt. Deze laag bevindt zich op applicatieniveau omdat het specifiek voor bepaalde applicaties5 is gedefinieerd.

3 Interactielaag Deze laag beschrijft de interactie met DPG en hoe er omgegaan moet worden met uitzonderingssituaties als foutmeldingen.

Voor de (applicatieonafhankelijke) transportlaag wordt SOAP / HTTP toegepast. De SOAP web services worden daarbij in een WSDL beschreven. De berichten, op applicatieniveau, zijn conform StUF gestructureerd. StUF is een extensie op XML en de definitie van StUF-berichten ligt in XML-schema’s vast. Voor het toepassingsdomein van de basisregistraties is de StUF-standaard verder gespecialiseerd. De volgende afbeelding geeft de verschillende protocolsessies weer voor een normale request/response verloop.

5 Met applicatie wordt hier bijvoorbeeld het versturen van kennisgevingsberichten bedoeld. Het gaat dus niet om specifieke, al dan niet fabrikantafhankelijke, software of systemen.



17

DIVA

afnemer

gegevens

HTTPhandler

(web server /service)

SOAPhandler

StUFhandler

berichthandler

SOAPbericht

StUFbericht

(XML)bericht transactie

Figuur 3 Protocolsessies voor een normale request/response verloop.

In de volgende paragrafen worden de genoemde lagen verder uitgewerkt. Paragraaf 3.1 behandelt laag 1 (de transportlaag) en betreft de applicatieonafhankelijke structuur van de berichten. De structuur die specifiek voor de aansluiting is, in laag 2 (de berichtenlaag), wordt in Paragraaf 3.3 beschreven. Beide paragrafen samen definiëren de inhoud en structuur van berichten. Het communicatieproces in laag 3 (de interactielaag) wordt in paragraaf 3.4 beschreven. Het beschrijft de opzet van de (SOAP-) web services en de verschillende interactiepatronen. Subparagraaf 3.4.4 beschrijft de WSDL, Paragraaf 3.5 beschrijft hoe met verschillende versies wordt omgegaan. Paragraaf 3.6 beschrijft de beveiliging van de communicatie.



18

3.2 Laag 1: Transport

3.2.1 SOAP-berichten

Het berichtenverkeer tussen DPG en afnemers verloopt via SOAP web services. SOAP web services worden beschreven in WSDL (Web Services Definition Language). De uitgewisselde berichten zijn SOAP-berichten. Voor een uitgebreide beschrijving van de SOAP-standaard wordt o.m. verwezen naar http://www.w3.org/TR/soap/. Het berichtenverkeer vindt plaats binnen het gemeentelijke E-net. Hieruit volgt dat de SOAP-berichten over HTTP worden verstuurd, en dat op OS-niveau het TCP/IP protocol wordt toegepast. Voor meer informatie over E-net wordt verwezen naar het Servicehuis ICT.

3.2.2 Transportfouten en afhandeling

De transportlaag, de berichtenlaag en de interactielaag stellen elk eigen specifieke eisen ten aanzien van de afhandeling van fouten: HTTP fouten binnen de transportlaag, SOAP fouten binnen de berichtlaag, en functionele fouten binnen de interactielaag. HTTP fouten In het geval zich bij de gegevensuitwisseling een HTTP fout voordoet (een fout binnen de transportlaag), wordt geen SOAP-ENV:Envelope samengesteld. Er wordt alleen binnen de transportlaag een foutcode geretourneerd. Als binnen de connection timeout voor de HTTP-server geen antwoord van de ontvanger komt, wordt een HTTP-fout gegenereerd. Zolang DIVA geen bevestigingsbericht heeft ontvangen, is het haar verantwoordelijkheid er voor te zorgen dat het bericht bij de ontvanger komt. StUF definieert geen additionele foutafhandeling boven op de standaard foutafhandeling rond time-outs voor HTTP. De meest voorkomende standaard foutcategorieën in de http-standaard zijn:

4xx: een foutboodschap die door de cliënt (typisch een webbrowser) veroorzaakt is, zoals het verkeerd typen van een URL

5xx: een foutboodschap die door de webserver veroorzaakt is, zoals een fout in een CGI script

SOAP fouten Er kunnen transport problemen op SOAP protocol niveau optreden, bijvoorbeeld doordat een verkeerde versie van SOAP wordt toegepast. In het geval zich bij de gegevensuitwisseling een SOAP Fault voordoet, wordt de SOAP-ENV:Body binnen de SOAP-ENV:Envelope gevuld met een standaard SOAP-ENV:Fault structuur.



19

Afhandeling van HTTP en SOAP fouten Communicatie bij de kennisgeving service loopt altijd van DIVA naar de afnemer. Bovenstaande fout soorten zullen hierdoor altijd aan de kant van DIVA duidelijk worden. DIVA beheer zal deze fouten herkennen en in samenwerking met de afnemer herstellen.



20

3.3 Laag 2: Bericht

3.3.1 StUF

De berichten op applicatieniveau zijn gestructureerd conform het Standaard Uitwisselingformaat voor applicaties (StUF). StUF is een extensie op XML en wordt ten behoeve van het gebruik binnen bepaalde toepassingsdomeinen verder gespecialiseerd. De StUF standaard onderkent de volgende berichtensoorten: Kennisgevingsbericht Synchroon vraagbericht Synchroon antwoordbericht Asynchroon vraagbericht Asynchroon antwoordbericht Bevestigingsbericht Foutbericht

DIVA biedt vooralsnog geen (a)synchrone vraag/antwoord services aan, waardoor het (a)synchrone vraagbericht en het (a)synchrone antwoordbericht in de communicatie met DIVA niet voorkomt. De specificaties van synchrone vraag/antwoord berichten zullen in een later stadium worden opgenomen. Voor een uitgebreide beschrijving van StUF en de daarin voorkomende berichttypen wordt o.m. verwezen naar de website van EGEM: http://www.egem-iteams.nl/stuf-gebruik Van StUF zijn meerder versies in omloop, voor informatie over welke de huidge versie van DIVA ondersteunt zie paragraaf 3.5 .

3.3.2 Domeinspecifieke uitbreidingen op StUF

De berichtstructuur, inclusief de uitbreidingen en de specialisaties, is vastgelegd in een aantal XSD’s. Deze subparagraaf beschrijft deze XSD’s op functioneel niveau. Het gaat hier om de functionele toelichting op de XSD, niet de XSD zelf. De schemastructuur bij DPG bestaat uit aparte schema’s voor: StUF definitie Gegevensdefinitie Berichtendefinitie

De StUF-definitie is de landelijk beschikbare definitie. De gegevensdefinitie beschrijft de te bevragen entiteiten, attributen en relaties. In DIVA is een apart schema voor landelijke definities van entiteiten, en een schema waarin deze worden gespecialiseerd voor de gemeentelijke situatie. (bg.ent.xsd, resp. DIVA.ent.xsd).

Bovendien is de entiteitdefinitie gescheiden van de attribuutdefinitie, in bg.attr.xsd, resp. DIVA.attr.xsd. Deze schema’s worden door een include aan de entiteiten gekoppeld.



21

De verschillende typen berichten zijn ondergebracht in gescheiden schema’s. Voor kennisgevingsberichten is dat bijvoorbeeld DIVA.kennisgeving.msg.xsd (zie Figuur 4).

stuf0204.xsd bg.ent.xsd

diva.ent.xsd

bg.attr.xsd

diva.attr.xsd

diva.kennisgeving.msg.xsd

Figuur 4 In DIVA is onderscheid gemaakt tussen de basisgegevens, de Amsterdamse uitbreiding hierop, en de berichtendefinitie. Bovendien zijn de entiteiten gescheiden van de kenmerken.

3.3.3 StUF foutBerichten

In de vorige paragrafen is aangeven welke foutmeldingen kunnen voorkomen in de transportlaag (http- en SOAP-fouten). Op berichtniveau kunnen ook fouten voorkomen. Deze fouten moeten door het ontvangende systeem kunnen worden opgeworpen en verpakt in een StUF foutbericht6. Een foutbericht in StUF heeft 3 elementen in zijn body die de fout beschrijven: de code, de plek en een omschrijving van de fout (zie [StUF]). De op te werpen fouten zijn7:

Tabel 1 StUF foutcodes.

code plek omschrijving

StUF001 client De stuurgegevens zijn onjuist gevuld.

StUF005 server Er heeft zich in de StUF-communicatie een time-out voorgedaan.

StUF009 client Het bericht is gericht aan een niet bekend systeem.

StUF011 client De syntax van het StUF bericht is onjuist.

StUF012 server Het ontvangende systeem ondersteunt niet de afhandeling van <berichttype> berichten.

StUF013 client Het systeem is bij het ontvangende systeem niet bekend.

StUF014 client Het bericht is niet valideerbaar: <foutbericht>

StUF500 server Er is een onverwachte fout opgetreden: <fout detail>.

StUF014 en StUF500 zijn door DPG toegevoegd en maakt geen deel uit van de StUF standaard. StUF002, StUF003, StUF004, StUF006, StUF007, StUF008 en StUF010 zijn weggelaten omdat deze voor DIVA kennisgevingsberichten niet van belang zijn.

6 Hoofdstuk Fout! Verwijzingsbron niet gevonden.beschrijft de verschillende berichttypen die in StUF worden onderscheiden. Foutberichten worden echter hier besproken omdat de inhoud van foutberichten de communicatie zelf betreffen. 7 In de specificatie van StUF is de formulering van de foutomschrijvingen alleen geschikt voor vraag/antwoord verkeer. In deze tabel is deze formulering wel overgenomen, maar zijn de delen die voor kennisgevingsberichten niet van toepassing zijn tussen haakjes geplaatst.



22

DIVA staat toe dat afnemers extra StUF codes hanteren. In dit geval is het wel zeer wenselijk dat in het veld omschrijving zeer duidelijk wordt beschreven wat de fout situatie is, zodat beheerders uit het foutbericht genoeg informatie kunnen halen om het probleem op te lossen. 3.4 Laag 3: Interactie

3.4.1 Functionaliteit

De kennisgeving web service aan de afnemende kant moet minimaal de volgende functionaliteit bieden:

ontvangen van kennisgevingsberichten, synchroon versturen ontvangstbevestiging, evt. synchroon versturen foutbericht.

Als een initiële levering wordt verwerkt, dan moet het ontvangende systeem kennisgevingsberichten kunnen ontvangen die na de aanmaak van de initiële levering worden aangemaakt. De ontvangen kennisgevingsberichten kunnen echter pas worden verwerkt nadat de initiële levering is verwerkt (zie ook [DPG]). Aan afnemende partijen wordt geadviseerd om de volgende functionaliteit te realiseren:

faciliteren meerdere versies van StUF en meerdere sectormodellen, plaatsen van ontvangen berichten in een queue, in een apart proces verwerken van de queue, toepassen van filtering op de ontvangen gegevens, bijhouden van berichthistorie.

Het eerstgenoemde punt is met name van belang voor transitiefases tussen verschillende versies van sectormodellen en/of StUF. Een mogelijke oplossing bestaat uit de volgende componenten (zie afbeelding): web server; Apache of Oracle Application Server application server; Tomcat of Oracle Application Server SOAP handler; AXIS queue; Java StUF handler; Java OR-mapper; functionaliteit binnen Oracle DBMS



23

DBMSapplication server

queue

w eb server

GVI

StUF handler OR - mapperSOAPhandler

WSDL

StUF

kennisgevingsbericht

ontvangstbevestiging

StUF StUF XML tree

Figuur 5 Voorbeeld oplossing afnemer applicatie.

Voor het proces van acceptatie en in productie name van een gerealiseerde ontvangst applicatie zie Bijlage 1 Testen ontvangst applicatie.

3.4.2 Functionele eisen

Aan de ontvangende services worden de volgende eisen gesteld: asynchrone verwerking De ontvangst van een kennisgevingsbericht moet direct (synchroon) worden

beantwoord met een bevestigingsbericht. De verdere verwerking van deze berichten in het afnemende systeem vindt bij voorkeur asynchroon plaats. Doordat DIVA alleen hoeft te wachten op een correcte ontvangst van een bericht, en niet op een correcte verdere verwerking, kunnen meerdere berichten vlot na elkaar worden gezonden.

Ontvangstbevestigingen worden synchroon in reactie op elk kennisgevingsbericht verstuurd; ook als een bepaalde kennisgeving al eerder ontvangen was en daarom niet verder wordt verwerkt.

Na het versturen van de ontvangstbevestiging is het afnemende systeem verantwoordelijk voor het succesvol verwerken van de kennisgeving (ook in het geval dat er problemen met dit systeem optreden). DPG verwijdert na ontvangst van een ontvangstbevestiging het bericht uit haar eigen queue en is vanaf dat moment niet meer verantwoordelijk voor verdere verwerking.

verwerking van kennisgeving in interne datamodel De afnemende zijde dient de logica te implementeren die de binnenkomende

kennisgevingen verwerkt en de relevante gegevens op slaat in het interne datamodel. Indien een ontvangend systeem slechts geïnteresseerd is in een deel van de

gegevens binnen de gedefinieerde gegevenssets dan is het de taak van het ontvangende systeem om filtering toe te passen op binnenkomende kennisgevingsberichten.

het ontvangende systeem moet in staat te zijn om (in uitzonderlijke gevallen) eenzelfde kennisgeving vaker te verwerken. Dit zal bijvoorbeeld het geval zijn bij bepaalde communicatie problemen.

initiële leveringen Vanaf het moment dat DPG een initiële levering (zie §2 Initiële leveringen) voor een

afnemer heeft aangemaakt om door deze verwerkt te worden, bewaart DPG de nakomende berichten in een buffer.



24

Zodra de initiële levering is verwerkt, geeft de afnemer aan dat de nakomende berichten kunnen worden ontvangen.

De verwerking van de gebufferde kennisgevingsberichten vindt bij afnemers pas plaats nadat de initiële levering is verwerkt.

bulkleveringen DPG biedt geen apart mechanisme voor het versturen van bulkleveringen (zeer grote

hoeveelheden berichten in een relatief kort tijdsbestek). Afnemers moeten in staat zijn om ook bulkleveringen via de reguliere web service koppeling te verwerken.

web services Om een kennisgevingsbericht te kunnen versturen, wordt een verzoek gestuurd aan

een ontvangende web service van de afnemer. M.a.w.: bij de afnemers draait een ontvangende web service.

DPG zal het WSDL/XSD dicteren welke een dergelijke ontvangende web service dient te implementeren om de koppeling te realiseren.

3.4.3 Interactieproces

Het interactieproces tussen DIVA en de ontvangst applicatie van de afnemer volgt een aantal stappen:

1. Klaarzetten van kennisgevingsberichten [DIVA]; 2. Verzenden van kennisgevingsberichten [DIVA]; 3. Ontvangst en opslag kennisgevingsbericht [afnemer]; 4. Verzenden van ontvangstbevestiging of foutbericht [afnemer]; 5. Ontvangen van ontvangstbevestiging of foutbericht [DIVA]; 6. Verwerken van kennisgevingsberichten [afnemer]; 7. (optioneel) Herzenden van laatst verzonden kennisgevingsbericht [DIVA] 8. (optioneel) Foutafhandeling door DPG en/of afnemer. [DIVA / afnemer]

Figuur 6 geeft genoemde stappen schematisch weer. Klaarzetten van kennisgevingsberichten DPG houdt een wachtrij bij met berichten. Aan de hand van de abonnementsgegevens worden voor elke afnemer specifiek aan hem geadresseerde berichten opgesteld. Pas als een bericht is verzonden en de ontvangst is bevestigd, wordt een bericht uit de wachtrij verwijderd. Verzenden van kennisgevingsberichten Het initiatief voor verzenden van kennisgevingen ligt bij DIVA. Alle berichten in de wachtrij van een afnemer zullen één voor één door DIVA naar de afnemer web service worden verstuurd. Het versturen van berichten start zodra de wachtrij gevuld wordt.



25

Figuur 6 Interactieproces DIVA – afnemer applicatie

Ontvangst en opslag kennisgevingsberichten De afnemer ontvangt het bericht en slaat het op. Inhoudelijk doet zij nog niets met het bericht, de verwerking vind asynchroon plaats t.o.v. het interactieproces. Verzenden van ontvangstbevestigingen / foutberichten Voor elk kennisgevingsbericht dat de afnemer ontvangt, moet de afnemer een bevestigingsbericht of (in het geval van een foutsituatie) een foutbericht sturen. De afnemer moet de ontvangst van de kennisgevingen synchroon bevestigen, d.w.z. in 1 webservice call. Vervolgens kan de afnemer het volgende kennisgevingsbericht ontvangen. Ontvangstbevestigingen worden in reactie op elk kennisgevingsbericht verstuurd; ook als een bepaalde kennisgeving al eerder ontvangen was. Een bevestigingsbericht mag door de afnemer pas gestuurd worden als hij heeft gewaarborgd dat het bericht niet meer verloren kan gaan. Na het versturen van de ontvangstbevestiging is het afnemende systeem verantwoordelijk voor het succesvol verwerken van de kennisgeving (ook in het geval dat er problemen met dit systeem optreden). Dit betekent in de praktijk veelal dat na een succesvolle plaatsing van de



26

kennisgeving in de queue pas van dit bericht een ontvangstbevestiging in StUF formaat wordt gecreëerd en ‘ingepakt’ in een SOAP bericht.8 Het kan voorkomen dat een kennisgevingsbericht meerdere keren wordt ontvangen. Dat komt bijvoorbeeld voor als er niet tijdig een ontvangstbevestiging wordt verstuurd waardoor DIVA een nieuwe verzendpoging doet. Ook als het herzonden bericht niet verder wordt verwerkt, moet de ontvangst hiervan wel met een ontvangstbevestiging worden verstuurd. validatie van berichten Voordat DIVA berichten verstuurd valideert zij deze met behulp van het DIVA xsd. Afnemers mogen er derhalve vanuit gaan dat berichten die zij ontvangen voldoen aan het sectormodel en de StUF standaard zoals in de DIVA xsd vastgelegd. DPG adviseert om met validatie aan afnemer zijde als volgt om te gaan: Geen validatie in de communicatie component: het bericht is al door DIVA gevalideerd

en nogmaals valideren vertraagt de communicatie. In de verwerking component validatie op een van volgende manieren:

Expliciete validatie: met behulp van het xsd. Impliciete validatie: de verwerking starten zonder expliciet het bericht te valideren,

maar hierbij rekening houden met de kans dat gegevens incorrect kunnen zijn of missen en hiervoor correcte foutafhandeling inbouwen.9 Wanneer een bericht op deze wijze uit zou vallen betekent dat, dat DIVA een incorrect bericht zou hebben verstuurd. Dit dient altijd als incident gemeld te worden bij DPG.

Ontvangen van ontvangstbevestigingen / foutberichten Pas wanneer DIVA een bevestiging van de afnemer heeft ontvangen van bericht zal zijn het volgende bericht sturen. Wanneer DIVA geen bevestiging ontvangt, maar een foutbericht zal via foutafhandeling procedures de fout worden hersteld (bij DPG, de afnemer, of beide). Wanneer de fout is hersteld kan het proces worden hervat. Afhankelijk van de fout die is opgetreden wordt hetzelfde bericht nogmaals verstuurd of wordt met het volgende bericht verder gegaan. Verwerken van kennisgevingsberichten De verwerking van berichten dient asynchroon plaats te vinden t.o.v. het interactieproces; dit houdt in dat het terugzenden van de ontvangstbevestiging moet plaatsvinden direct na ontvangst en opslag, en vóór de verwerking ervan.

DIVA gaat uit van een volgordelijke verwerking van berichten; als een bericht wordt verwerkt, dan moeten alle voorgaande berichten al eerder zijn verwerkt. De volgorde wordt daarbij bepaald door het veld ‘referentienummer’. Het maakt dus niet uit wanneer een bericht verwerkt wordt, als het maar voor nakomende berichten gebeurt.

8 Alternatief: creëer het bevestigingsbericht vóór het bericht in de queue op te slaan, maar verzend het pas na dit wel te hebben gedaan. Wanneer er een fout mocht optreden in het creëren van het bevestigingsbericht zit je in dit geval niet opgescheept met een al opgeslagen bericht dat je niet kunt bevestigen. (Zo’n fout kan b.v. voorkomen wanneer er onverhoopt iets met de stuurgegevens is mis gegaan.) Tevens versnelt deze werkwijze de omlooptijd van de web service iets. 9 Feitelijk betreft dit enkel het inbouwen van een correcte foutherkenning en afhandeling, iets dat een vereiste is voor elke applicatie.



27

Herzenden van kennisgevingsberichten Als na verzending van een kennisgevingsbericht binnen een bepaalde tijd door DIVA geen bevestigingsbericht is ontvangen, zal DIVA het kennisgevingsbericht opnieuw proberen te versturen. Na een aantal pogingen, die met toenemende tijdsintervallen plaats vinden, wordt de verzending van alle kennisgevingsberichten aan die specifieke afnemer gestopt. Het bericht, en alle nakomende berichten worden in een buffer bewaard. DIVA verwijdert een kennisgevingsbericht voor een bepaalde afnemer pas nadat voor dat bericht een ontvangstbevestiging is ontvangen. Het herhaalschema is instelbaar per afnemer en heeft de volgende vorm: pogingnummer (#) wachttijd (msec.) blokkeren (J/N) 1 wt_1 N … … N n wt_n J/N Er kan een ‘n’ aantal pogingen worden ondernomen. Bij elke poging wordt aangegeven hoeveel milliseconden moet worden gewacht (wanneer deze poging faalt) tot de volgende poging. De laatste poging kan oneindig worden herhaald door blokkeren op N(ee) te zetten, of hierna kan het herhaalmechanisme stopgezet worden door blokkeren op J(a) te zetten. Wanneer DIVA bezig is met herhaalpogingen, of wanneer het proberen te verbinden met een bepaalde afnemer is gestopt wordt hiervan automatisch melding gemaakt bij DIVA beheer. Wanneer de verbinding met een afnemer ‘down’ is, zal DIVA beheer stappen ondernemen om dit te herstellen, afhankelijk van de oorzaak van het probleem zal de afnemer zelf, of DPG, of wellicht E-net het probleem dienen op te lossen. Foutfafhandeling Voor meer over foutafhandeling: zie Bijlage 4.

3.4.4 WSDL; beschrijving web service afnemer

ontvangKennisgeving Op het moment van dit schrijven is in DIVA alleen de service voor de kennisgevingsberichten gedefinieerd. Afnemers moeten een ontvangende service inrichten conform het door DPG opgestelde WSDL. Figuur 7 geeft een overzicht van deze WSDL.



28

Figuur 7 DIVA WSDL.

De kennisgevingservice bestaat uit een service die één operation kent: ontvangKennisgeving. De invoer hiervoor is een bericht van het type ‘kennisgevingsBericht’, de uitvoer is een bericht van het type ‘bevestigingsBericht’. Foutmeldingen worden in berichten van het type ‘foutBericht’ geretourneerd. relatie met Paraplu Paraplu is het distributiesysteem van de basisregistratie Personen van de gemeente Amsterdam. Deze wordt ook door DPG gevoerd. Paraplu en DIVA hebben soortgelijke taken, namelijk de distributie verzorgen voor basisregistraties. Ook de wijze waarop, m.b.v. StUF berichten, is soortgelijk. Afnemers van zowel DIVA en Paraplu zullen merken dat het aansluiten op beide systemen voor een gedeelte een overlappend traject is. Vooralsnog zijn voor DIVA en Paraplu twee aparte WSDL’s beschikbaar. Dat houdt in dat een afnemer die op zowel DIVA als op Paraplu wil aansluiten, ook twee web services moet inrichten (zie afbeelding).

DPG

GVI

afnemer

Paraplu

DIVA

DIVA service

ontvangKennisgeving

Paraplu service

ontvangKennisgeving

verwerking

WSDL

WSDL

Figuur 8 Web services DIVA / Paraplu.



29

Het is sterk aan te bevelen om een aantal modules in de verwerking van de berichten, zoals de SOAP en de StUF handlers, generiek te maken en voor beide aansluitingen te herbruiken. 3.5 Versiebeheer StUF web services

De datadistributie web services van DIVA en Paraplu bestaan uit een aantal specificaties en protocollen die voortdurend doorontwikkeld worden. Het is dan ook noodzakelijk dat tussen de aanbieders en afnemers van de services steeds goede afspraken worden gemaakt over de versies van gebruikte protocollen en specificaties. De volgende protocollen en specificaties zijn van belang: naam huidige versie in DIVA HTTP(s) 1.1 SOAP 1.1 WSDL 1.1 XML 1.0 StUF 2.04 compatibiliteit Er is een aantal regimes voor compatibiliteit mogelijk: 1 De versies van protocollen moeten altijd bij alle betrokken partijen op ieder moment

exact gelijk zijn om een goede werking van de communicatie te kunnen garanderen. In theorie lijkt dit de beste oplossing; interoperabiliteit is gegarandeerd. In de praktijk zou dit echter betekenen dat alle systemen die aangesloten zijn op de basisregistraties op exact hetzelfde moment geüpgrade moeten worden naar een nieuwe versie. De releaseplanningen van alle betrokken software pakketten moeten dan op elkaar afgestemd worden; een onhaalbare en dus ongewenste oplossing (dit geldt dan vooral voor de StUF versies).

2 Een bericht van een ‘oudere’ versie kan door een service van een ‘nieuwere’ versie worden verwerkt (neerwaarts compatibel). De nieuwe service begrijpt de oude taal uit het bericht.

3 Een bericht van een ‘nieuwere’ versie kan door een service van een ‘oudere’ versie worden verwerkt (voorwaarts compatible). De oude service negeert de nieuwe elementen uit het bericht.

4 Er is sprake van een breaking change; de nieuwe versie is zo ingrijpend veranderd dat neerwaartse en voorwaartse compatibiliteit niet meer mogelijk is.

Voor de versies van HTTP, SOAP, WSDL (de specificatie en niet de inhoud van het WSDL) en XML geldt het eerste regime. De versies van deze protocollen zullen overal gelijk moeten zijn.



30

Voor de StUF specificaties zal bij voorkeur gelden dat versies zowel downwards als forwards compatible zijn. Voor afnemers die uit verschillende basisregistraties gegevens krijgen betekent dat al tijdens het ontwerp rekening gehouden moet worden dat er tegelijkertijd (of naast elkaar) meerder XSD’s ondersteund moeten worden. Het valt bovendien niet uit te sluiten dat er eens in de paar jaar ook sprake is van een breaking change. frequentie Uit het oogpunt van beheer is het wenselijk versies zo lang mogelijk stabiel te houden. Er is dan voldoende tijd voor ontwikkeling, testen en implementatie. Nieuwe functionaliteit of gegevens kunnen echter alleen in de vorm van een nieuwe StUF versie geleverd worden. Bovendien kan een versie ook fouten bevatten die men over het algemeen snel wenst op te lossen. In een dergelijke situatie kan er dan sprake zijn van de ontwikkeling en distributie van een patch, maar voor een beheerder is dit bijna hetzelfde als een nieuwe versie omdat ook een patch pas na testen en accepteren geïmplementeerd kan worden. Er moet in Amsterdam nog ervaring worden opgedaan met gestandaardiseerde berichtenuitwisseling en het is daarom moeilijk te zeggen wat een werkbare frequentie is voor het uitbrengen van nieuwe versies. Eén keer per jaar is daarbij op termijn een goed uitgangspunt. Duur ondersteuning oude versies. DIVA is in staat om berichten op te stellen conform verschillende versies van StUF en specialisaties daarvan. Dat houdt in dat als er bijvoorbeeld een nieuwe versie van StUF wordt vastgesteld, de vorige versie nog steeds aan bestaande afnemers kan worden verzonden (zie afbeelding).

afnemer B

GVI / DIVA

StUFhandler

afnemer A

serviceStUF02.04

serviceStUF02.05

StUF02.04

StUF02.05

Figuur 9 Ondersteuning meerdere StUF versies.

Hoe lang oudere versies van services ondersteund moeten blijven wordt, in overleg met de betrokken partijen, nog nader bepaald. Beheer StUF standaard



31

De VNG heeft EGEM gevraagd zorg te dragen voor de ontwikkeling en het beheer van de StUF-standaard en de gemeentebreed inzetbare modellen StUF-BG en StUF-Zaken. Om aan die ontwikkel- en beheertaken een goede invulling te geven bouwt EGEM aan een beheermodel en -organisatie waarin alle belanghebbende partijen zijn vertegenwoordigd. Zo is de StUF community opgezet die openstaat voor alle belanghebbenden en zijn recent alle leden van de community uitgenodigd zitting te nemen in een werkgroep die zich bezighoudt met de doorontwikkeling van StUF aan de hand van wijzigingsvoorstellen. Deze werkgroep kan een opmaat zijn voor de Change Advisory Board in een definitief beheermodel. In de werkgroep zijn op dit moment naast EGEM ook gemeenten en leveranciers vertegenwoordigd.



32

3.6 Informatiebeveiliging DIVA

De informatiebeveilgiing van DIVA is conform het door DPG opgestelde beveiligingsprotocol. Beschikbaar op Viadesk. De informatiebeveiliging van DIVA kent drie facetten: 1 Beschikbaarheid 2 Integriteit 3 Vertrouwelijkheid Deze paragraaf beschrijft hoe in DIVA met deze facetten wordt omgegaan, en doet een uitspraak over de technische beveiliging van het berichtenverkeer. Beschikbaarheid Beschikbaarheid bevat de garanties voor het afgesproken niveau van dienstverlening gericht op de beschikbaarheid van de dienst op de afgesproken momenten (bedrijfsduur, waarbij rekening wordt gehouden met uitvalstijden, storingen en incidenten). DPG hanteert voor de beschikbaarheid van DIVA het nivo van het E-net concerndomein.

De beschikbaarheidsafspraken worden in de afzonderlijke leveringsovereenkomsten met afnemers gedetailleerd en expliciet vastgelegd. Het gaat dan naast de beschikbaarheid van het systeem ook om de beschikbaarheid van de servicedesk (servicewindows) en van gegevens (back-up/ herstel mogelijkheden). Integriteit Integriteit is het kwaliteitsbegrip dat juistheid, volledigheid en tijdigheid van de gegevens en transacties omvat. Het bewaken van de integriteit van de gegevens die DIVA distribueert is een kerntaak van DPG. Zij waarborgt door middel van proces- en kwaliteitsbewaking de integriteit van haar gegevens. De basis hiervoor vormt het door B&W vastgestelde reglement op de Vastgoedregistratie van 15 juli 2006.

De integriteit van de transacties ofwel de distributie wordt gewaarborgd door gebruikmaking van het StUF protocol. StUF bevat diverse maatregelen om de integriteit van de distributie te controleren. Er zal in samenspraak met afnemers in een later stadium een methode en functionaliteit worden ontwikkeld om periodiek een verschilanalyse te kunnen maken tussen de basisregistraties en de gegevensset bij een afnemer. Vertrouwelijkheid Vertrouwelijkheid is het kwaliteitsbegrip waaronder privacybescherming maar ook de exclusiviteit van informatie gevangen kan worden. Het waarborgt dat alleen geautoriseerden toegang krijgen en dat informatie alleen gebruikt kan worden voor overeengekomen doeleinden.



33

De vastgoedgegevens van DPG zijn niet privacygevoelig. Ook de kadastrale eigendomsgegevens zijn openbaar zolang het gaat om enkelvoudige bevraging met de ingang adres. De vraag ‘Geef mij al het eigendom van natuurlijk persoon X’ is echter een vraag die alleen aan geautoriseerde personen beantwoord mag worden. Ook andere analyses die mogelijk worden doordat een organisatie / gebruiker de totale gegevensset tot zijn beschikking heeft zijn mogelijk privacy schendend. Een organisatie die door middel van door DPG geleverde gegevens over (een kopie van) de gegevensset beschikt is zelf verantwoordelijk voor de naleving van de wetgeving op dit vlak en zal het gebruik van deze gegevens moeten reguleren. In de dienstverleningsovereenkomst met afnemers zullen de gebruiksvoorwaarden worden opgenomen. Technische beveiliging: Het berichtenverkeer met binnengemeentelijke afnemers zal via het basisdomein van de E-net infrastructuur plaats vinden. Het is niet nodig deze berichten te versleutelen (onnodige belasting van het verkeer en onderhoud) omdat de afzonderlijke berichten niet vertrouwelijk zijn. E-net verbinding Om een aansluiting te realiseren tot de bij DPG beheerde basisregistraties moet er door de aan te sluiten diensten aan enige technische voorwaarden voldaan worden. de aan te sluiten dienst moet beschikken over een E-net aansluiting. door E-net moeten wijzigingen in de Access Controle Lists (ACL’s) aangebracht

worden. Bijlage 3 beschrijft de acties die een afnemer moet ondernemen voor het verkrijgen van een goed werkende E-net verbinding.



34

4 Berichtenhandboek

Een afnemer die aansluit op DIVA krijgt berichten met daarin mutaties op de vastgoed registraties die DPG beheert. De vorm en inhoud van die berichten wordt in dit berichtenhandboek beschreven. 4.1 Gegevensgroepen

De kennisgevingsberichten die DIVA naar afnemers verstuurt hebben betrekking op één van de volgende drie verzamelingen10: Adressen en Gebouwen (BAG), Kadaster, Gebieden.

Dit zijn meteen de abonnementsvormen die DPG haar afnemers aanbiedt. Daarnaast biedt DPG nog een bijzonder abonnement: POK11.

Dit POK abonnement is feitelijk een abonnement op één bericht soort; het KOTVBO bericht. Dit abonnement is voor afnemers die wel de BAG afnemen, maar zelf een directe koppeling met het kadaster hebben. De POK legt de relatie tussen deze twee registraties. De geleverde gegevens kunnen daarbij beperkt worden tot de gegevens die betrekking hebben tot een bepaald stadsdeel. Verdere beperkingen, bijvoorbeeld op de te leveren kenmerken, zijn niet mogelijk, maar kunnen door afnemers aan de afnemende kant natuurlijk wel gerealiseerd worden door een berichtenfilter in te bouwen. Fout! Verwijzingsbron niet gevonden. toont het DIVA uitlevermodel waarin alle entiteiten12 met onderlinge relaties van de verschillende gegevensgroepen zijn opgenomen.

10 De grootschalige en kleinschalige topografische gegevens van DPG worden in deze versie van de aansluiting

niet via kennisgevingsberichten ontsloten. 11 POK = Perceel Object Koppeling, oftewel de relatie tussen het verblijfsobject en het kadastraal object. 12 Voor de term entiteit wordt in de aansluitspecificaties ook de term object gebruikt.



35

Figuur 10 DIVA uitlevermodel.



36

4.2 XML schema’s / DIVA XSD

Het uitlevermodel, waarvan in de vorige paragraaf een overzicht is gegeven, is voor het berichtenverkeer in een aantal XML-schema’s ondergebracht. Deze vormen de formele specificatie van de uit te wisselen berichten. In hoofdstuk Fout! Verwijzingsbron niet gevonden.is al aangegeven, dat het landelijke model basisgegevens en de Amsterdamse specialisatie hiervan in twee aparte schema’s is ondergebracht. Het Amsterdamse schema erft daarbij van het landelijke schema over. In deze paragraaf wordt getracht de structuur toe te lichten alsmede een aantal ontwerpbeslissingen. In onderstaande figuur is de onderlinge structuur van de verschillende XSD bestanden weergegeven. Daarnaast is een scheiding aangebracht tussen de entiteiten zelf en de kenmerken hiervan. Door deze modulaire opzet zijn wijzigingen betere te beheersen. Als bijvoorbeeld de naam van een fundamentele entiteit wijzigt, kan het schema voor de objectkenmerken ongewijzigd blijven.

stuf0204.xsd bg.ent.xsd

diva.ent.xsd

bg.attr.xsd

diva.attr.xsd

diva.kennisgeving.msg.xsd

Figuur 11 DIVA XML schema’s.

Er is tijdens de ontwikkeling van DIVA voor gekozen om een opdeling te kiezen die hergebruik mogelijk maakt en onderhoud zoveel mogelijk vereenvoudigd. De onderlinge structuur van de XML schema's is dan ook modulair opgezet. Zo erven de onderliggende schema de basisdefinitie van de bovengelegen schema's en breiden deze uit met aanvullende definitie(s). Idealiter zou pas in het onderste XML schema (berichten definitie) de integratie met StUF worden toegepast echter staat de structuur van StUF dit helaas niet toe. Dit betekent in de praktijk dat de DIVA XML schema's gekoppeld zijn (d.m.v. import) aan een specifieke versie van StUF. Zo zal er voor de ondersteuning van nieuwere versies van StUF ook een nieuwe versie van de DIVA schema's beschikbaar gesteld moeten worden. Zoals in het bovenstaande figuur te zien is wordt hier gebruik gemaakt van StUF versie 2.04. De in DIVA gebruikte XML schema's zijn in feite verdeeld in drie groepen met binnen de gegevensdefinitie een extra onderverdeling: Protocoldefinitie (stuf0204.xsd)

XML specificatie van StUF zoals die door de EGEM is opgesteld. Gegevensdefinitie

Landelijk XML datamodel (bg.attr.xsd & bg.ent.xsd) Definitie van landelijk geldende entiteiten en hun eigenschappen en is derhalve herbruikbaar (als basis) voor andere gemeenten. Aangezien de



37

geldende versie van het landelijke BG model uit 1997 stamt is er voor gekozen om vooruitlopend op het nieuwe BG model een nieuw BG model te definiëren.

Amsterdam specifiek XML datamodel (diva.attr.xsd & diva.ent.xsd) Uitbreiding van de landelijke gegevens met aanvullende eigenschappen en entiteiten welke specifiek voor Amsterdam zijn.

Berichtendefinitie (diva.kennisgeving.msg.xsd) Voor de kennisgevingen service is in dit XML schema gedefinieerd voor welke entiteiten wijzigingen kunnen worden opgenomen in een kennisgevingsbericht.

Namespaces en versiebeheer Er is in het ontwerp van de XSD's getracht om de verschillende verantwoordelijkheden duidelijk te definiëren en in afzonderlijk te onderhouden schema's vast te leggen. Om dit verder te verduidelijken is er voor gekozen om deze aan separate namespaces te koppelen. Dit resulteert in 3 namespaces naast de StUF namespace: Gegevensmodel landelijk: http://www.gviservices.intranet.amsterdam.nl/StUF/sector/bg/ent/2008/11 Gegevensmodel Amsterdam: http://www.gviservices.intranet.amsterdam.nl/StUF/sector/diva/ent/2008/11 Sectormodel (berichtenmodel) Amsterdam: http://www.gviservices.intranet.amsterdam.nl/StUF/sector/diva/msg/2008/11 Hierdoor is het mogelijk om alle schema's/namespaces afzonderlijk her te gebruiken en/of uit te breiden (binnen of buiten de namespace). Daarnaast is binnen de namespace een scheiding aangebracht tussen de entiteiten zelf en de kenmerken hiervan. Door deze modulaire opzet kunnen kenmerk definities hergebruikt worden en zijn wijzigingen beter te beheersen. Benaming dient binnen dezelfde namespace natuurlijk altijd uniek te zijn. Zoals tevens te zien is aan de URI's die worden gebruikt voor de namespaces is hier tevens versioning toegepast volgens het model zoals W3C (“http://.../2008/11”) dit gebruikt. Nadat een XML schema wordt vrijgegeven is deze onlosmakelijk verbonden aan de bijbehorende namespace (inclusief versie). Hierdoor is altijd duidelijk welke versie gebruikt is in een xml instance document (door het gebruik van de prefix en de prefix definitie in het document). Globale versus lokale elementen type definities Binnen de XML schema's wordt bewust slechts zeer beperkt gebruik gemaakt van globale element definities in tegenstelling tot type definities welke (voor zover nuttig) globaal worden gedefinieerd. Voor element definities geldt immers dat deze (indien deze globaal zijn gedefinieerd) in XML instances (documenten/berichten) voor mogen komen. Dit willen we echter tot een minimum beperken want er mogen enkel kennisgevingsberichten worden verzonden met hun strikte structuur definitie. Alle uit te wisselen data wordt (bij toepassing van het StUF protocol) in de door het protocol gedefinieerde berichten ge-encapsuleerd. Om deze reden is enkel het “kennisgevingsbericht” element globaal gedefinieerd in het



38

diva.kennisgeving.msg.xsd schema. Alle andere element definities zijn lokaal gedefinieerd (dus binnen andere type definities). Voor type definities (zowel voor kenmerken als voor entiteiten) geldt dat deze juist wel globaal worden gedefinieerd. Dit is omdat globaal gedefinieerde types zowel binnen als buiten de namespace kunnen worden (her)gebruikt en/of uitgebreid. Hierdoor wordt de herbruikbaarheid gemaximaliseerd. Er dient echter wel rekening mee gehouden te worden dat daarmee versiebeheer (nog) belangrijker wordt aangezien schema’s welke zijn gebaseerd op een schema dat een wijziging ondergaat mogelijk dienen te worden aangepast. Mede hierdoor worden binnen DIVA versies gebruikt binnen de namespaces. Hierdoor is het ten alle tijde duidelijk op welke definitie (versie) een schema is gebaseerd. Structuur en hergebruik in DIVA XML schema's Er is een poging gewaagd om de structuur van types en de manier waarop hergebruik (door uitbreiding/extensie of verwijzing) visueel te verduidelijken in Fout! Verwijzingsbron niet gevonden.. In plaats van de term kenmerk wordt de term eigenschap gebruikt in het schema. Kenmerken/eigenschappen worden als XML elementen gemodelleerd. Om een enigszins begrijpelijk UML class diagram te krijgen zijn er enkele vereenvoudigingen uitgevoerd. Er is duidelijk weergegeven welke zaken in welk schema/namespace gedefinieerd zijn. Op sommige plaatsen is gebruik gemaakt van een base entiteit type. Vervolgens worden deze gebruikt in de definitie van lokale elementen voor tabel- en relatie entiteiten. Een ander punt dat verduidelijking verdiend is het definieren van de zogenaamde “Amsterdamse Fundamentele Entiteit Definities – StUF Attributen/Eigenschappen”. StUF vereist dat de eigenschappen “TijdvakGeldigheid” en “ExtraElementen” onderdeel zijn van fundamentele entiteiten. Om de mogelijkheid om de voor Amsterdam gedefinieerde entiteiten uit te breiden is het niet mogelijk om die in de Amsterdamse definitie op te nemen. Indien dan een uitbreiding wordt gedefinieerd dan komen deze eigenschappen midden tussen de andere eigenschappen te staan. Vandaar dat deze in separate specialisaties zijn gedefinieerd. Hierdoor blijven dus de bovenliggende entiteiten beschikbaar voor hergebruik.



39

Figuur 12 Structuur en hergebruik DIVA xsd.



40

4.3 Soorten berichten

4.3.1 berichttypen

In de communicatie op basis van kennisgevingsberichten komen 3 berichttypen voor13: kennisgevingsbericht, bevestigingsbericht, foutbericht.

Het bevestigingsbericht en het foutbericht worden door de StUF-standaard gedefinieerd in het schema stuf0204.xsd (hier aangegeven met de namespace aanduiding ‘StUF’, zie figuren).

Figuur 13 StUF:bevestigingsBericht

Figuur 14 StUF:foutBericht

Het kennisgevingsbericht is in het gespecialiseerde schema diva.kennisgeving.msg.xsd gedefinieerd (Fout! Verwijzingsbron niet gevonden.). Zoals al gedeeltelijk in dit schema te zien is, is de opbouw (in xml) van een kennisgevingsbericht ruwweg zoals in Fout! Verwijzingsbron niet gevonden. beschreven. Let op dat de technische sleutel van een entiteit direct bij de entiteit gegeven wordt in het xml-attribuut sleutelVerzendend. Voor meer over sleutel gebruik zie §Fout! Verwijzingsbron niet gevonden..

13 Zie ook paragraaf 3.3.1



41

Figuur 15 Opbouw kennisgevingsbericht.

Het kennisgevingsbericht wordt verstuurd door DIVA naar afnemers en bevat mutaties op entiteiten van de vastgoed registraties. In respons hierop verzend de afnemer naar DIVA een bevestigingsbericht, of wanneer een foutsituatie zich voordoet een foutbericht. Zie Figuur 6.



42

Figuur 16 StUF: kennisgevingsBericht.



43

4.3.2 Stuurgegevens

Elk StUF bericht wordt voorzien van StUF stuurgegevens waarin metadata over het bericht is opgenomen zoals door wie het verstuurd is, welke StUF versie gebruikt wordt, wanneer het bericht verstuurd is, etc. Zie Fout! Verwijzingsbron niet gevonden. en Fout! Verwijzingsbron niet gevonden.. De meeste stuurgegevens hebben een vaste waarde, of een vast waardebereik. Fout! Verwijzingsbron niet gevonden. toont deze waarden. Voor een beschrijving van de betekenis van StUF stuurgegevens; zie ‘stuf0204.pdf’ (verkrijgbaar via http://egem-iteams.nl/stuf).

Tabel 2 Waarde(bereik) StUF stuurgegevens DIVA.

StUF stuurgegeven waarde(bereik) opmerking berichtsoort Lk01 (kennisgeving)

Bv01 (bevestiging) Fo01 (fout)

DIVA verstuurt enkel kennisgevingsberichten. De afnemer moet in staat zijn zowel bevestigingsberichten als foutberichten als response naar DIVA te sturen.

entiteittype Alle entiteiten (fundamenteel en tabel) uit het DIVA uitlevermodel.

Zie Fout! Verwijzingsbron niet gevonden..

sectormodel DIVA Het DIVA sectormodel is een door DPG opgesteld model, dat vooruitloopt op het landelijke BAG model en het RSGB model. Het is een uniek model dat voldoet aan StUF0204, maar niet overeenkomt met b.v. het landelijk model BG0204.

versieStUF 0204 versieSectormodel 0100 zender: organisatie DPG zender: applicatie DIVA_Kennisgevingen zender: administratie - Veld wordt niet gebruikt. zender: gebruiker - Veld wordt niet gebruikt. ontvanger: organisatie Afnemer organisatie naam. De afnemer dient de waarde

hiervoor bij DPG bekend te maken. ontvanger: applicatie Afnemer applicatie naam. De afnemer dient de waarde

hiervoor bij DPG bekend te maken. ontvanger: administratie - Veld wordt niet gebruikt. ontvanger: gebruiker - Veld wordt niet gebruikt. referentienummer Uniek, oplopend, nummer. De waarde hiervan is uniek en

oplopend, maar loopt niet met één op per afnemer. Dit veld kan dus niet gebruikt worden om te controleren of de afnemer berichten



44

‘gemist’ heeft. tijdstipBericht Tijdstip (YYYYMMDDhhmmssmm). Tijdstip van verzenden bericht. kennisgeving: mutatiesoort T (toevoeging)

W (wijziging) C (correctie) V (verwijdering)

Zie §Fout! Verwijzingsbron niet gevonden.. DIVA maakt feitelijk geen gebruik van mutatiesoort V.

kennisgeving: indicatorOvername V (verplicht) I (informatief)

In de huidige versie van DIVA wordt geen gebruik gemaakt van informatieve berichten.

kennisgeving: tijdstipMutatie Tijdstip (YYYYMMDDhhmmssmm). Tijdstip waarop de mutatie is ingevoerd in de registratie bij DPG.

bevestiging: crossRefNummer Uniek, oplopend, nummer. Referentienummer van kennisgevingsbericht dat bevestigd wordt.

fout: crossRefNummer Uniek, oplopend, nummer. Referentienummer van kennisgevingsbericht dat bevestigd wordt.



45

Figuur 17 StUF stuurgegevens.

4.3.3 Mutatiesoorten

StUF onderkent vier verschillende mutatiesoorten voor kennisgevingsberichten: T: toevoeging W: wijziging C: correctie



46

V: verwijdering

Figuur 18 StUF mutatiesoorten.

De mutatiesoort toevoeging houdt in dat de geleverde entiteit nieuw is en moet worden opgevoerd. Een wijziging betekent dat de attributen van de entiteit veranderd zijn. Een correctie geeft aan dat eerder geleverde gegevens incorrect zijn gebleken en gewijzigd dienen te worden naar de gegevens in het bericht. Een verwijdering betekent dat de entiteit niet meer voorkomt en moet worden verwijderd uit de administratie. Bij toevoegingen en verwijderingen wordt ten allen tijde één entiteit meegegeven die moet worden opgevoerd dan wel afgevoerd. Bij wijzigingen en correcties worden meestal twee entiteiten meegegeven, waarbij de eerste entiteit de ‘WAS’ situatie aanduidt en de tweede entiteit de ‘WORDT’ situatie. In specifieke gevallen komt er bij wijzigingen en correcties maar een entiteit mee; dit is bijvoorbeeld het geval bij een wijzigingsbericht die het beëindigen van een relatie doorgeeft. DIVA maakt géén gebruik van verwijderingsberichten. Binnen DIVA worden entiteiten nooit verwijderd: wanneer een entiteit niet meer bestaat wordt haar einddatum geldigheid ingevuld en geen nieuwe cyclus gestart. Deze wijziging wordt uiteraard wel aan afnemers gecommuniceerd.

4.3.4 Interpretatie van de kennisgevingsberichten

In veel gevallen spreekt de inhoud van de berichten voor zich. Er zijn echter een paar attributen en situaties waarbij een nadere toelichting noodzakelijk is. Deze worden hieronder weergegeven en vervolgens verder besproken: 4 Omgang met historie, 5 Gebruik van het attribuut Indicatie-vervallen, 6 Omgang met 1:n relaties, 7 Omgang met n:m relaties. 8 Gebruik van lege waarden en waarde onbekend 9 Omgang met tabelentiteiten Ad 1. Omgang met historie



47

De historie van een object wordt in de berichten weergegeven in het StUF-element TijdvakGeldigheid. Daarbinnen wordt via de begindatumTijdvakGeldigheid en einddatumTijdvakGeldigheid aangegeven over welke periode de waarden van de opgenomen attributen gelden. Op deze wijze wordt in de loop van de tijd voor een object een reeks van historische cycli opgebouwd. Telkens wordt daarbij de voorgaande cyclus afgesloten door een einddatum in te vullen en wordt een nieuwe cyclus met een nieuwe begindatum van kracht. Conform de StUF-voorschriften worden bij mutaties overigens alleen de attributen die daadwerkelijk wijzigen in het bericht opgenomen, attributen die niet in het bericht zijn opgenomen houden dus ook in de nieuwe situatie hun oude waarde. StUF schrijft voor dat mutaties alleen op actuele gegevens mogen plaatsvinden en niet op historische gegevens. Onder actuele gegevens wordt binnen StUF altijd de laatst geldende cyclus verstaan, ongeacht of hiervan de einddatum is gevuld. Voor afnemers geldt dat DPG er van uitgaat dat zij alle actuele gegevens (dus de laatst geldende cyclus), voor zover zij die in hun bedrijfsprocessen gebruiken, overnemen. Het bijhouden van historie is optioneel, maar wordt door het hier beschreven mechanisme wel mogelijk gemaakt. Wanneer een object verdwijnt wordt hiervoor vanuit DPG geen verwijderingsbericht verzonden maar een mutatiebericht waarbij de einddatum van het tijdvak geldigheid wordt gevuld, en er geen nieuwe cyclus is opgenomen. Functioneel betekent dit vanuit DPG dat het object in de praktijk niet meer bestaat en dus verwijderd zou kunnen worden, vanuit StUF blijft echter de laatste cyclus het actuele gegeven. Het is mogelijk dat een einddatumTijdvakGeldigheid ten onrechte gevuld is. In dat geval zal via een correctiebericht de einddatum weer verwijderd worden om het object te ‘re-activeren’. Uiteraard is dit alleen voor de laatste cyclus mogelijk, eerdere cycli kunnen niet meer actief gemaakt worden. Een ontvangend systeem wat op basis van de gevulde einddatum een object fysiek verwijdert moet er dus rekening mee houden dat de mogelijkheid bestaat dat het object terug gehaald zal worden. Opbouw van berichten Het wijzigingsbericht bij het invoeren van de einddatum, zonder dat een nieuwe cyclus volgt ziet er uit zoals getoond in Fout! Verwijzingsbron niet gevonden.14. Let wel dat de begin en eind data in de ‘was’ en ‘wordt’ situatie gelijk zijn aangezien er geen nieuwe cyclus wordt gestart. Verder kunnen er ook andere elementen binnen het bericht opgenomen worden die gewijzigd worden, in de praktijk zal dat echter niet snel gebeuren omdat het object immers in dezelfde actie wordt afgesloten.

14 Alle opgenomen voorbeeldberichten geven alleen de informatie die voor de beschreven situatie relevant is. Ter wille van de leesbaarheid zijn attributen als sleutelverzendend en namespaces niet opgenomen en wordt alleen de body getoond.



48

<body>

<NUM verwerkingssoort=”W”>

<TijdvakGeldigheid>

<begindatumTijdvakGeldigheid>begindatum oud</begindatumTijdvakGeldigheid>

<einddatumTijdvakGeldigheid>einddatum nieuw</einddatumTijdvakGeldigheid>

</TijdvakGeldigheid>

</NUM>

<NUM verwerkingssoort=”W”>

<TijdvakGeldigheid>

<begindatumTijdvakGeldigheid>begindatum oud</begindatumTijdvakGeldigheid>

<einddatumTijdvakGeldigheid>einddatum nieuw</einddatumTijdvakGeldigheid>

</TijdvakGeldigheid>

</NUM>

</body>

Figuur 19 Voorbeeld wijzigingsbericht: beëindiging van een nummeraanduiding. Merk op dat de einddatum in de WAS-situatie niet leeg is, maar is gevuld met de einddatum van de entiteit. De begin- en einddatum in de WORDT-situatie zijn gelijk aan die van de WAS-situatie.

Het correctiebericht bij het weer activeren van het object ziet er uit zoals getoond in Fout! Verwijzingsbron niet gevonden.. Hier zijn de begindatum nieuw en de begindatum oud aan elkaar gelijk. In het voorbeeld wordt de nieuwe einddatum leeg gelaten zodat het object weer ‘bestaat’. Het is natuurlijk ook mogelijk dat een gewijzigde einddatum wordt opgenomen, het object blijft dan vervallen, maar vanaf een andere datum. Ook kunnen er andere elementen binnen het bericht opgenomen worden die gewijzigd worden, maar in de praktijk zal dat niet vaak gebeuren.



49

Figuur 20 Voorbeeld correctiebericht: correctie van de beëindiging van een entiteit.

Ad 2. Gebruik van het attribuut Indicatie-vervallen Een aantal entiteiten kent het attribuut Indicatie-vervallen. Deze heeft de waarde J of N. Normaal gesproken zal de waarde van het attribuut N zijn, wat aangeeft dat het gegeven normaal geldig is (binnen de omgang met historie zoals verderop beschreven wordt). Wanneer de waarde van het attribuut Indicatie-vervallen J is, dan geeft dit aan dat het object foutief is opgevoerd en in de werkelijkheid niet bestaat. Gegevens met een waarde J voor Indicatie-vervallen mogen dus niet gebruikt worden om verdere gegevens aan te koppelen. Wanneer de Indicatie-vervallen van een entiteit op J wordt gezet, zal ook einddatumTijdvakGeldigheid ingevuld worden. Het voorkomen van de entiteit wordt daarmee ook beëindigd en in historie geplaatst. Aangezien er in de meeste gevallen alleen met actuele gegevens wordt gewerkt, zorgt deze extra maatregel ervoor dat de vervallen gegevens niet per ongeluk worden gebruikt. Ad 3. Omgang met 1:n relaties Het datamodel van het gegevensmagazijn kent vele 1:N relaties, bijvoorbeeld een nummeraanduiding heeft een relatie met 1 openbare ruimte, de openbare ruimte heeft een relatie met vele (N) nummeraanduidingen. Wanneer bij een nummeraanduiding attributen wijzigen én de relatie naar de openbare ruimte wijzigt, dan wordt een mutatie- of correctiebericht opgesteld waarin de nummeraanduiding als gewijzigde fundamentele entiteit, de relatie als gewijzigde relatie entiteit en de openbare ruimte als identificatie entiteit is opgenomen. StUF biedt de vrijheid om mutaties in een fundamentele entiteit en bijbehorende relaties in hetzelfde bericht op te nemen.



50

Wanneer echter alleen de relatie naar de openbare ruimte wijzigt dan wordt dit binnen de berichten beschouwd als een mutatie van de nummeraanduiding. Het bericht wordt dan ook identiek opgesteld als een mutatie binnen de openbare ruimte. Functioneel gezien is dit niet onlogisch omdat de relatie het meeste gewicht heeft aan de veel-kant. Ook technisch gezien is deze oplossing het meest direct omdat op de database de foreign key ook aan de veel-kant in de tabel aanwezig is. Het aanpassen van de relatie volgt daarmee hetzelfde spoor als het aanpassen van de entiteit. Kort gezegd wordt een 1:N relatie altijd vanuit de veel (N) kant uitgeleverd, richting de één (1) kant. Opbouw van berichten De berichten zien er daarbij als volgt uit (Fout! Verwijzingsbron niet gevonden.):

Figuur 21 Voorbeeldbericht: wijziging van een 1:N relatie.

Ad 4. Omgang met N:M relaties



51

Mutaties op n:m relaties worden altijd vanuit één leidende entiteit aangegeven. Binnen DPG wordt de keuze gemaakt welke entiteit dat is. In het model bestaat bijvoorbeeld een n:m relatie tussen verblijfsobject en kadastraal object. Iedere mutatie op deze (en andere) N:M relatie wordt in een separaat bericht opgenomen waarbij telkens de relatie vanuit het kadastraal object naar het verblijfsobject opgenomen wordt. Stel bijvoorbeeld dat kadastraal object A gerelateerd is aan verblijfsobject X. Er komt nu een mutatie waarbij die relatie vervalt en kadastraal object A gerelateerd wordt aan verblijfsobject Y. In berichten betekent dit dat de relatie tussen A en X beëindigd wordt en de relatie tussen A en Y nieuw wordt toegevoegd. De berichten die hier uit voortkomen zijn wijzigingsberichten op de leidende fundamentele entiteit. In het voorbeeld is dit het kadastraal object. Van deze fundamentele entiteit worden alleen de identificerende gegevens geleverd, gevolgd door de relatie, met daarin de gerelateerde entiteit. Merk op dat er geen tijdvakGeldigheid van de fundamentele entiteit wordt geleverd. Deze entiteit wijzigt zelf namelijk niet; alleen de relatie wijzigt. Binnen de relatie wordt wel het tijdvakRelatie geleverd, met een begindatum- en einddatumGeldigheid. Opbouw van berichten Het beëindigen van de relatie gaat via volgend mutatiebericht (Fout! Verwijzingsbron niet gevonden.):

Figuur 22 Voorbeeldbericht: beëindigen van een N:M relatie (KOTVBO). Let op de verwerkingssoort “E”.



52

Het toevoegen van de nieuwe relatie gaat via een volgend toevoegingsbericht (Fout! Verwijzingsbron niet gevonden.):

Figuur 23 Voorbeeldbericht: toevoegen van N:M relatie (KOTVBO).

Ad 5. Gebruik van lege waarden en waarde onbekend De attributen van een entiteit zijn doorgaans gevuld met een waarde, maar kunnen ook leeg zijn. Een lege waarde wordt in een bericht met het attribuut StUF:noValue doorgegeven. Bij sommige attributen kan er ook worden aangegeven dat de waarde niet zozeer leeg is alswel onbekend. Dit geeft aan dat de waarde van het betreffende attribuut altijd gevuld moet zijn, maar nog niet bekend is. Let op dat zo’n attribuut in sommige gevallen alsnog leeg kan zijn. Dit gebeurt wanneer het attribuut niet gebruikt wordt bij een bepaald type van een entiteit. Welke attributen gebruik maken van de waarde onbekend staat beschreven in het gegevenswoordenboek. Opbouw van berichten Een attribuut waarvan de waarde leeg is, wordt als een lege XML-tag geleverd met daarbij het XML-attribuut StUF:noValue=”geenWaarde”. Dit kan voorkomen bij de huisletter van een nummeraanduiding. Deze hoeft immers niet altijd gevuld te zijn. <body>

<NUM>

<Huisnummer>1</Huisnummer>

<Huisletter StUF:noValue=”geenWaarde” xsi:nil=”true” />

</NUM>

</body>



53

Als een attribuut gevuld moet zijn, maar de waarde hiervan is niet bekend, dan wordt het attribuut ook als een lege XML-tag geleverd met ditmaal het XML-attribuut StUF:noValue=”waardeOnbekend”. Een voorbeeld hiervan is de oppervlakte van een verblijfsobject. Een verblijfsobject heeft namelijk altijd een oppervlakte. <body>

<VBO>

<OppervlakteVerblijfsobject StUF:noValue=”waardeOnbekend” xsi:nil=”true” />

</VBO>

</body>

Ad 6. Omgang met tabelentiteiten Fundamentele entiteiten kunnen toegevoegd, gewijzigd en gecorrigeerd worden. Daarbij leveren toegoegingen en wijzigingen en nieuwe levencyclus op, terwijl correcties een aanpassing op de laatste levenscyclus inhouden. Bij tabelentiteiten werkt dit echter anders, omdat deze entiteiten geen tijdskenmerken hebben en dus ook geen levenscyclus. Een tabelentiteit kan daarom in principe alleen toegevoegd worden. Moet een tabelentiteit veranderen, dan wordt hiervoor een nieuwe tabelentiteit toegevoegd naast de bestaande. Vanaf dat moment zal de nieuwe entiteit gehanteerd worden. De bestaande entiteit zal overigens nooit beëindigd of verwijderd worden. Tabelentiteiten kennen ook correctieberichten, maar deze zijn alleen bedoeld om een bestaande omschrijving van een entiteit te verbeteren. Zo kan een omschrijving een spelfout bevatten die gecorrigeerd moet worden, of een onduidelijke omschrijving die verduidelijkt moet worden. De code en omschrijving zullen nooit (inhoudelijk) gewijzigd worden. In plaats daarvan zal altijd het toevoegingsmechanisme gebruikt worden, zoals hierboven beschreven.

4.3.5 Sleutelgebruik

Elke entiteit kent in het DIVA uitlevermodel twee soorten sleutels:

1.) De technische sleutel. Dit is hét identificerend attribuut van een entiteit. Dit wordt ook wel de DIVA-sleutel genoemd. In StUF berichten wordt deze sleutel gecommuniceerd in het veld sleutelVerzendend. Zie Fout! Verwijzingsbron niet gevonden. voor de plaatsing van sleutelVerzendend in een StUF kennisgevingsbericht.

2.) De functionele sleutel. Ook wel logische sleutel genaamd. Deze sleutel is opgebouwd uit een of meerdere attributen die de entiteit gezamenlijk uniek identificeren. In het DIVA uitlevermodel zijn deze attributen bestempeld als kerngegevens.

Beide soorten sleutels zullen bij kennisgevingsberichten altijd aanwezig zijn. De technische sleutel moet gezien worden als leidend en moet verplicht worden overgenomen in de registratie van afnemers. Het is aan te raden om ook ten alle tijde de functionele sleutel over te nemen, maar DPG stelt dit niet verplicht.



54

Matchen van afnemer sleutels met DIVA sleutels Voordat de afnemer is aangesloten beschikt zij zeker nog niet over de technische sleutels, en mogelijk nog niet over bepaalde functionele sleutels. Tijdens het initiële levering proces (zie Hoofdstuk 2 ) worden deze bij de afnemer bekend gemaakt. Afnemers hebben uiteraard in hun eigen database al sleutels voor hun eigen objecten. Om de sleutels van de afnemer te koppelen aan die van DIVA kunnen in dit stadium zgn. ‘match sleutels’ worden onderkend. Dit is een combinatie van attributen waarvan bekend is dat zij gezamenlijk de entiteit uniek kunnen identificeren, en die zowel bij DIVA als bij de afnemer bekend is. Voor nummeraanduidingen zou dit bijvoorbeeld kunnen zijn: Huisnummer, Huisletter, Huisnummer toevoeging, Straatcode. Zodra de DIVA sleutels bij de afnemer bekend zijn moet verder worden afgezien van het identificeren van entiteiten m.b.v. dit soort match sleutels. Dit is van belang, omdat de match sleutels op termijn niet meer uniek identificerend zullen zijn, zoals bij ingrijpende verbouw, samenvoeging of splitsing. Bij deze gebeurtenissen zullen de oude verblijfsobjecten en de daarbij behorende nummeraanduidingen beëindigd worden en zullen er nieuwe verblijfsobjecten en nummeraanduidingen worden toegevoegd. Zo’n nieuwe nummeraanduiding kan daarbij dezelfde combinatie van Huisnummer, Huisletter, Huisnummertoevoeging en Straatcode hebben, maar zal altijd een andere DIVA-sleutel hebben. Het kan daarbij zelfs voorkomen dat de oude nummeraanduiding nog niet is beëindigd, terwijl de nieuwe al wordt toegevoegd, aangezien die al bekend is. Zo kunnen er twee actuele nummeraanduidingen zijn met dezelfde match sleutel.



55

4.4 Entiteiten

In StUF fundamentele entiteiten en tabelentiteiten komen standaard de elementen ExtraElementen, TijdvakGeldigheid en TijdvakRelatie voor. Onderstaande figuren geven de defintitie hiervan weer.

Figuur 24 Definitie van ExtraElementen.

Figuur 25 Definitie van TijdVakGeldigheid.

Figuur 26 Definitie van TijdVakRelatie.

Het element ExtraElementen wordt door DIVA niet gebruikt. Door overerving van de StUF standaard komt het wel voor in het DIVA sectormodel, maar zal nooit gevuld zijn. TijdvakGeldigheid en TijdvakRelatie daarentegen zijn zeer belangrijke elementen in berichten die DIVA verstuurd. TijdvakGeldigheid bevat twee velden die respectievelijk de start en eind datum aangeven van de geldigheid van de verstrekte gegevens. Wanneer de eind datum gevuld is betreft het automatisch een historisch gegeven, is deze leeg dan betreft het een actueel gegeven. TijdvakRelatie bevat soortgelijke velden die respectievelijk de begin en eind datum van de relatie tussen twee entiteiten weergeeft. Volgorde van entiteiten en relaties De verschillende entiteiten worden binnen DIVA in een vaste volgorde verwerkt. Deze is hieronder aangegeven (Fout! Verwijzingsbron niet gevonden.). Daarbij is ook aangegeven welke relaties uitgeleverd worden. Relaties worden altijd naar één kant uitgeleverd, een 1:n relatie altijd aan de n-kant, voor 1:1 en n:m relaties is een keuze gemaakt bij welke entiteit de relatie wordt uitgeleverd. In de tabel zijn de 1:n-relaties direct achter de entiteit geplaatst waarbij ze uitgeleverd worden, de n:m relaties zijn apart aangegeven in de volgorde waarin ze worden uitgeleverd.



56

Direct gevolg van deze volgorde van verwerken is dat berichten naar afnemers ook in deze volgorde verstuurd zullen worden. De gekozen volgorde zorgt ervoor dat wanneer een relatie gelegd wordt de entiteit waarnaar deze gelegd wordt ten allen tijde al bestaat doordat deze al eerder is gecommuniceerd. Bij het beeindigen van entiteiten en relaties daartussen wordt dezelfde volgorde gehanteerd. Bij sloop van een compleet pand b.v. zullen eerst alle adressen beëindigd worden, vervolgens alle verblijfsobjecten, dan de relatie tussen vorige twee, dan het pand en als laatste de relatie tussen pand en verblijfsobjecten.

Tabel 3 Volgorde van verwerken van entiteiten.15

volgorde entiteit relaties 0 Codetabellen (AVR, BRN, EGM, FNG, GBK,

LOC, LGG, MNT, OVR, TGG, STS)

1 Gemeente (GME) 2 Stadsdeel (SDL) SDLGME 3 Buurt (BRT) BRTSDL 4 Bouwblok(BBK) BBKBRT 5 Woonplaats (WPL) WPLGME 6 Openbare ruimte (OPR) OPRWPL 7 Nummeraanduiding (NUM) NUMOPR 8 Ligplaats (LIG) LIGBRT 9 Standplaats (STA) STABRT 10 Verblijfsobject (VBO) VBOBRT 11 NUMLIGHFD

NUMLIGNVN NUMSTAHFD NUMSTANVN NUMVBOHFD NUMVBONVN

12 Pand (PND) PNDBBK 13 PNDVBO 14 Kadastraal Object (KOT) 15 KOTVBO 16 Register9kop (R9K) R9KKOT 17 Register9tekst (R9T R9TR9K 18 Filiatie (FLE) FLEKOTNIW

FLEKOTOUD 19 Kadastraal Subject (KST) 20 Subject Relatie (SRE) SREKSTVAN

SREKSTNAR 21 Transactie (TTE) TTEKSTABR

TTEKSTBPE 22 Zakelijk recht (ZRT) ZRTKOT

ZRTKST

15 Verschillende relaties binnen één rij van deze tabel worden in volgorde van mutatie verwerkt.



57

ZRTTTE 23 Belemmering zakelijk recht (BZT) BZTKST

BZTZRT 24 Belemmering kadastraal object (BKT) BKTKOT

BKTKST Entiteitenoverzicht De volgende paragrafen geven per entiteittype weer hoe deze in kennisgevingsberichten wordt geleverd. Per entiteit worden de volgende twee diagrammen gegeven: Een entiteitoverzicht van de relaties tussen de fundamentele entiteiten, relatie-

entiteiten en de tabelentiteiten. Een attributenoverzicht met een gedeelte uit het XML-schema

diva.kennisgeving.msg.xsd. Deze bevat de in het xsd beschreven attributen en relaties van de entiteit.16

De relaties uit het eerste overzicht komen terug in het tweede. Let op: relaties zijn tweezijdig in het DIVA uitlevermodel en in de DIVA xsd, maar elke relatie wordt maar vanaf één kant uitgeleverd (zie gegevenswoordenboek). In het eerste diagram wordt enkel de daadwerkelijk uitgeleverde relatie getoond, maar in het tweede diagram zijn ook de relaties vanaf de andere, niet uitgeleverde, zijde te zien. Voor uitgebreidere informatie over de entiteiten, attributen en relaties wordt verwezen naar document 2a en 2b van de aansluitspecificaties: het gegevenswoordenboek. legenda In het entiteitoverzicht worden de symbolen gehanteerd zoals te zien in Fout! Verwijzingsbron niet gevonden..

tabelentiteit

fundamentele entiteit

fundamentele entiteit

relatie-entiteit

relatie-entiteit

Figuur 27 Symbolen entiteitenoverzicht.

Bij het attributenoverzicht wordt het sequence symbool gebruikt (Fout! Verwijzingsbron niet gevonden.). Alle elementen die in een sequence voorkomen kunnen opeenvolgend voorkomen. Onder de attributen staat aangegeven of deze verplicht voorkomen of niet; [0..1] geeft optionaliteit aan, [1] verplicht en [0..∞] multipliciteit. Bij elke attribuut staat tevens de namespace URL vermeld. Op basis hiervan kan worden afgeleid uit welke schema (StUF, BG of DIVA) het attribuut komt.

16 In het attributenoverzicht vind je de gelaagdheid terug die het gevolg is van de gelaagde structuur van het DIVA xsd. Zie §Fout! Verwijzingsbron niet gevonden.voor een beschrijving van deze structuur.



58

Figuur 28 Sequence symbool.



59

NUM

NUMSTS

NUMBRN

NUMLIGNVN

NUMLIGHFD

NUMSTAHFD

NUMOPR

LIG

LIG

OPR

STA

NUMSTANVN

NUMVBOHFD

NUMVBONVN

BRN

STS

STA

VBO

VBO

Figuur 29 Opbouw van de entiteit Nummeraanduiding.



60

Figuur 30 Nummeraanduiding attributen en relaties (DIVA xsd).



61

4.4.1 Openbare Ruimte (OPR)

Figuur 31 Opbouw van de entiteit Openbare Ruimte.



62

Figuur 32 Openbare Ruimte attributen en relaties (DIVA xsd).



63

4.4.2 Woonplaats (WPL)

Figuur 33 Opbouw van de entiteit Woonplaats.



64

Figuur 34 Woonplaats attributen en relaties (DIVA xsd).



65

GEBIEDEN REGISTRATIE

4.4.3 Gemeente (GME)

Figuur 35 Opbouw van de entiteit Gemeente.

Figuur 36 Gemeente attributen en relaties (DIVA xsd).



66

4.4.4 Stadsdeel (SDL)

Opmerking vooraf: In Amsterdam wordt de entiteit stadsdeel gebruikt i.p.v. de landelijke standaard ‘Wijk’.

Figuur 37 Opbouw van de entiteit Stadsdeel.

Figuur 38 Stadsdeel attributen en relaties (DIVA xsd).



67

4.4.5 Buurt (BRT)

Figuur 39 Opbouw van de entiteit Buurt.



68

Figuur 40 Buurt attributen en relaties (DIVA xsd).



69

4.4.6 Bouwblok (BBK)

Figuur 41 Opbouw van de entiteit Bouwblok.

Figuur 42 Bouwblok attributen en relaties (DIVA xsd).



70

GEBOUWEN REGISTRATIE

4.4.7 Pand (PND)

PND

BBKPNDBBK

PNDVBO VBO

Figuur 43 Opbouw van de entiteit Pand.



71

Figuur 44 Pand attributen en relaties (DIVA xsd).



72

4.4.8 Ligplaats (LIG)

Figuur 45 Opbouw van de entiteit Ligplaats.



73

Figuur 46 Ligplaats attributen en relaties (DIVA xsd).



74

4.4.9 Standplaats (STA)

Figuur 47 Opbouw van de entiteit Standplaats.



75

Figuur 48 Standplaats attributen en relaties (DIVA xsd).



76

4.4.10 Verblijfsobject (VBO)

VBO

VBOBRN

VBOAVR

VBOFNG

VBOEGM

VBOLOC

VBOGBK

VBOLGG

VBOMNT

VBOTGG

VBOOVR

VBOSTS

VBOBRT

OVR

STS

BRT

MNT

TGG

LGG

LOC

GBK

FNG

EGM

BRN

AVR

Figuur 49 Opbouw van de entiteit Verblijfsobject.



77

Figuur 50 Verblijfsobject attributen en relaties (DIVA xsd) [1/2[.



78

Figuur 51 Verblijfsobject attributen en relaties (DIVA xsd) [2/2].



79

KADASTER REGISTRATIE

4.4.11 Kadastraal Object (KOT)

KOT

KOTVBO VBO

Figuur 52 Opbouw van de entiteit Kadastraal Object.



80

Figuur 53 Kadastraal Object attributen en relaties (DIVA xsd) [1/2].



81

Figuur 54 Kadastraal Object attributen en relaties (DIVA xsd) [2/2].



82

4.4.12 Filiatie (FLE)

Figuur 55 Opbouw van de entiteit Filiatie.

Figuur 56 Filiatie attributen en relaties (DIVA xsd).



83

4.4.13 Zakelijk Recht (ZRT)

ZRT

ZRTKST

ZRTKOT

ZRTTTE

KOT

KST

TTE

Figuur 57 Opbouw van de entiteit Zakelijk Recht.



84

Figuur 58 Zakelijk Recht attributen en relaties (DIVA xsd).



85

4.4.14 Transactie (TTE)

TTE

TTEKSTBPE

TTEKSTABR KST

KST

Figuur 59 Opbouw van de entiteit Transactie.



86

Figuur 60 Transactie attributen en relaties (DIVA xsd).



87

4.4.15 Kadastraal Subject (KST)

Figuur 61 Opbouw van de entiteit Kadastraal Subject.



88

Figuur 62 Kadastraal Subject attributen en relaties (DIVA xsd) [1/3].



89




90




91

4.4.16 Subject Relatie

Figuur 65 Opbouw van de entiteit Subject Relatie.

Figuur 66 Subject Relatie attributen en relaties (DIVA xsd).



92

4.4.17 Belemmering Kadastraal Object

BKT

BKTKOT

BKTKST KST

KOT

Figuur 67 Opbouw van de entiteit Belemmering Kadastraal Object.



93

Figuur 68 Belemmering Kadastraal Object attributen en relaties (DIVA xsd).



94

4.4.18 Belemmering Zakelijk Recht

BZT

BZTZRT

BZTKST KST

KST

Figuur 69 Opbouw van de entiteit Belemmering Zakelijk Recht.

Figuur 70 Belemmering Zakelijk Recht attributen en relaties (DIVA xsd).



95

4.4.19 Register 9 Kop

Figuur 71 Opbouw van de entiteit Register 9 Kop.



96

Figuur 72 Register 9 Kop attributen en relaties (DIVA xsd).



97

4.4.20 Register 9 Tekst

Figuur 73 Opbouw van de entiteit Register 9 Tekst.

Figuur 74 Register 9 Tekst attributen en relaties (DIVA xsd).



98

4.4.21 Rente

Figuur 75 Opbouw van de entiteit Rente.

Figuur 76 Rente attributen en relaties (DIVA xsd).



99

4.4.22 Onzelfstandig Deel

Figuur 77 Opbouw van de entiteit Onzelfstandig Deel

Figuur 78 Onzelfstandig Deel attributen en relaties (DIVA xsd).



100

4.4.23 tabelentiteiten

In diva.kennisgeving.msg.xsd zijn de volgende tabelentiteiten gedefinieerd: BRN: Bron STS: Status AVR: Reden Afvoer EGM: Eigendomsverhouding FNG: Financiëringswijze GBK: Gebruik LOC: Locatie-ingang LGG: Ligging MNT: Monument OVR: Reden Opvoer TGG: Toegang

BRN

STS

AVR

EGM

FNG

GBK

LOC

LGG

MNT

OVR

TGG

Figuur 79 Tabelentiteiten.

Figuur 80 Tabelentiteiten attributen (DIVA xsd).



101

4.5 Voorbeeldberichten

Er zijn sets van berichten beschikbaar om inzicht te geven in hoe berichten er precies uit komen zien. Deze testsets worden beschreven in begeleidende documentatie. Een overzicht van beschikbare sets wordt gegeven in Tabel 4. Deze testsets zijn beschikbaar op Viadesk Amsterdam (http://intranet.viadesk.amsterdam.nl/), of op aanvraag bij DPG. De files zijn gezipt samengevoegd in de file ‘3. Aansluitspecificaties Kennisgevingen - Testsets cq Voorbeeldberichten v1.0.0.zip’.

Tabel 4 Beschikbare testsets.

naam testset file testset beschrijving file Templates DIVA Testset -Templates-

v1.0.zip DIVA Testset beschrijving -Templates- v1.0.doc

Klein Amsterdam DIVA Testset -Klein Amsterdam- v2.2.zip

DIVA Testset beschrijving -Klein Amsterdam- v2.2.doc



102

Bijlage 1 Testen ontvangst applicatie

Nadat bij de afnemer een ontvangende webservice en verwerkende functionaliteit is ingericht, moeten de verbinding en de functionaliteit getest worden. Als de testen succesvol verlopen kan de initiële levering worden verwerkt, waarna het reguliere berichtenverkeer gestart kan worden. Tijdens en na de ontwikkeling van het ontvangende systeem voorziet DPG in de volgende testen: 10 Verbindingstest; 11 Communicatietest; 12 Bericht verwerking (technisch) test; 13 Bericht verwerking (functioneel inhoudelijk) test; 14 Performance test; 15 Initiële levering test. 16 Schaduwdraaien. Meer gedetailleerde informatie is beschikbaar middels het document ‘testplan aansluiten afnemers’. Voor afstemming van het testtraject kan de afnemer contact opnemen met de testcoördinator ‘aansluiten DIVA’ van DPG. (Uw contactpersoon bij DPG kan u vertellen wie deze rol op moment van lezen vervult.)



103

Bijlage 2 Afkortingen

fundamentele entiteiten BBK: Bouwblok BKT: Belemmering kadastraal object BRT: Buurt BZT: Belemmering zakelijk recht FLE: Filiatie GME: Gemeente KOT: Kadastraal Object KST: Kadastraal Subject LIG: Ligplaats NUM: Nummeraanduiding ODL: Onzelfstandig deel OPR: Openbare Ruimte PND: Pand R9K: Register 9 kop R9T: Register 9 tekst RTE: Rente SDL: Stadsdeel SRE: Subject relatie STA: Standplaats TTE: Transactie VBO: Verblijfsobject WPL: Woonplaats ZRT: Zakelijk recht tabelentiteiten AVR: Reden Afvoer BRN: Bron EGM: Eigendomsverhouding FNG: Financieringswijze GBK: Gebruik LOC: Locatie-ingang LGG: Ligging MNT: Monument OVR: Reden Opvoer TGG: Toegang STS: Status relatie-entiteiten De afkortingen van relatie-entiteiten bestaan uit een samenvoegsel van de afkorting van de fundamentele entiteit en de gerelateerde entiteit. De relatie verblijfsobject (VBO) met Buurt (BRT) is bijvoorbeeld afgekort met VBOBRT.



104

hoofd- en nevenadressen Bij relaties met nummeraanduidingen (NUM) geeft een extra afkorting aan of het een hoofdadres (HFD) of een nevenadres (NVN) betreft. De relatie tussen een verblijfsobject en een bijbehorend nevenadres (= nummeraanduiding) wordt afgekort met VBONUMNVN. relaties tussen Kadastraal Subject en Transactie Bij relaties met Kadastraal subjecten (KST) en transacties (TTE) geeft een extra afkorting aan of het de belastingplichtige (BPE) of de aanbieder (ABR) betreft. De relatie tussen een transactie en een bijbehorende aanbieder wordt bijvoorbeeld afgekort met TTEKSTABR. filiatie Omdat filiatie een aantal eigen kenmerken heeft, zoals een register-9 nummer, is filiatie niet als relatie-entiteit, maar als fundamentele entiteit gemodeleerd. De relatie tussen oorspronkelijke en nieuwe kadastrale objecten is daarmee via de fundamentele entiteit Filiatie (FLE) vastgelegd. Bijvoorbeeld: Een perceel ‘A’ wordt gesplitst in percelen ‘B’ en ‘C’. Op een later tijdstip worden deze percelen weer samengevoegd tot perceel ‘D’.

A

B

C

D

t

Figuur 81 Splitsing van percelen.

De filiatie tussen percelen A, B, en C wordt in een aparte fundamentele Filiatie-entiteit vastgelegd. Hetzelfde geldt voor de filiatie tussen percelen B, C, en D. De percelen B en C die ontstaan uit splitsing van perceel A zijn vanuit KOT A te benaderen via: KOT A KOTFLENIW FLE FLEKOTNIW KOT B / C. Het perceel A waaruit KOT B is ontstaan is vanuit KOT B te benaderen via: KOT B KOTFLEOUD FLE FLEKOTOUD KOT A.



105

KOT A FLEA,B,C

FLEB.C.D

KOT B

KOT C

KOT D

KOTFLENIW

KOTFLENIW

KOTFLENIW

FLEKOTNIWFLEKOTNIW

FLEKOTNIWKOTFLEOUD

KOTFLEOUD

KOTFLEOUD

FLEKOTOUD

FLEKOTOUD

FLEKOTOUD

Figuur 82 Filiatie relatie illustratie.



106

Bijlage 3 E-net acties

Om een aansluiting te realiseren tot de bij DPG beheerde basisregistraties moet er door de aan te sluiten diensten aan enige technische voorwaarden voldaan worden. de aan te sluiten dienst moet beschikken over een E-net aansluiting. door E-net moeten wijzigingen in de Access Controle Lists (ACL’s) aangebracht

worden. De communicatie tussen de aan te sluiten dienst en DPG is tweerichting communicatie. Om deze communicatie mogelijk te maken moeten er bij E-net twee wijzigingsverzoeken ingediend worden (zie ook afbeelding). 17 toegang vanuit de afnemer tot DIVA

Het eerste verzoek zorgt ervoor dat de aan te sluiten dienst toegang kan krijgen tot de DIVA systemen bij DPG. Dit wijzigingsverzoek bij E-net zal door DPG verzorgd worden.

18 toegang vanuit DIVA tot de afnemer Het tweede verzoek zorgt ervoor dat het DIVA systeem kan communiceren met het systeem bij de aan te sluiten dienst. Dit wijzigingsverzoek zal bij de aan te sluiten dienst door de E-net contactpersoon verzorgd moeten worden. Indien deze gegevens tussentijds wijzigen zal dit aan de E-net contactpersoon worden doorgegeven.

Het wijzigingsverzoek zal door de E-net contactpersoon bij de aan te sluiten dienst door middel van een standaardformulier bij E-net ingediend moeten worden. Dit formulier is op de E-net website beschikbaar: http://www.loket.e-net.amsterdam.nl/live/index.jsp?nav=3929&loc=24039&det=3772 Aangezien er alleen communicatie tussen server systemen zal plaatsvinden is het belangrijk te weten wat de IP adressen van de betreffende servers zijn. Nadat de wijzigingen in de ACL’s door E-net zijn uitgevoerd dienen de wijzigingen getest te worden. De projectleider zal u hierover nader informeren. DPG adviseert de deelnemende diensten de wijzigingsverzoeken bij E-net zo snel als mogelijk in te dienen. Naast bovenstaande wijzigingen in E-net kan het ook nog noodzakelijk zijn dat de beheerder van de aan te sluiten dienst wijzigingen in de lokale infrastructuur moet aanbrengen (denk hierbij aan firewall e.d.)



107

Figuur 83 E-net aansluiting DPG – afnemer.



108

Bijlage 4 Terugmelding van fouten

4.1 Terugmeldproces vastgoed gegevens

Wanneer een afnemer twijfels heeft over de juistheid van de vastgoedgegevens, dan dient zij dit via het terugmeldproces aan DPG aan te geven. De beschrijving van dit proces maakt geen onderdeel van dit document. Verdere informatie over het terugmeldproces is opgenomen in het convenant of de overeenkomst die de afnemer met DPG sluit. Voor inhoudelijke vragen over de gegevens kan ook via dit proces contact worden opgenomen met DPG. 4.2 Terugkoppelen van incidenten met de aansluiting

Wanneer fouten optreden met de aansluiting kan een afnemer dit terugkoppelen aan de DIVA helpdesk. Een afnemer kan hier ook terecht voor vragen over het leveringsproces. De contactgegevens van de helpdesk en de wijze waarop vragen en incidenten worden afgehandeld staan beschreven in het convenant of de overeenkomst die de afnemer met DPG sluit.



109

Bijlage 5 Handreiking bij beëindiging van objecten

De BAG registreert de verblijfsobjecten, waar mensen in kunnen wonen en werken, met de daaraan gekoppelde nummeraanduidingen. Deze administratieve verblijfsobjecten komen overeen met de fysieke woningen, kantoren, winkels, etc., zoals die in de werkelijkheid bestaan en de nummeraanduidingen zijn de adressen waarmee de objecten kunnen worden aangewezen. Er is een strikte relatie tussen deze verblijfsobjecten en hun nummeraanduidingen. De één kan namelijk niet bestaan zonder de ander. Wanneer een verblijfsobject beëindigd wordt, zal tegelijkertijd ook de bijbehorende nummeraanduiding beëindigd worden. Een dergelijke beëindiging vindt plaats bij een samenvoeging, een splitsing, een sloop of ingrijpende verbouwing. Het bestaande verblijfsobject wordt dan samen met de nummeraanduiding beëindigd. In veel gevallen zullen daar (op termijn) één of meerdere verblijfsobjecten voor in de plaats komen, met ieder een eigen nummeraanduiding. Er is echter geen directe relatie tussen de beëindigde verblijfsobjecten en de nieuwe objecten.

Praktijkvoorbeeld: De twee winkelruimten op Dorpstraat 10 en 11 worden samengevoegd tot één nieuwe winkel, omdat kledingzaak De Mantel op nummer 10 wil gaan uitbreiden. In dit geval zullen de twee verblijfsobjecten die de afzonderlijke winkelruimten vertegenwoordigen beëindigd worden en worden tevens de gerelateerde nummeraanduidingen, nummer 10 en 11, beëindigd. Na de samenvoeging ontstaat er een nieuw verblijfsobject, namelijk de nieuwe winkelruimte, met een nieuwe gerelateerde nummeraanduiding. De aanduiding is in dit geval nummer 10 geworden.

De oude en nieuwe verblijfsobjecten en nummeraanduidingen staan geheel los van elkaar. Niet alleen qua identificatie, maar ook qua tijd. Zo kan een nieuw verblijfsobject wel een half jaar later worden, nadat het oude object is beëindigd. Ook kan het nieuw object al worden opgevoerd, voordat de oude is beeindigd. Dat hetzelfde ‘adres’ weer terugkomt, in dit geval nummer 10, is een logische toevalligheid. De oude en nieuwe nummeraanduiding hebben geen enkele relatie. In de praktijk zal de kledingzaak altijd geregistreerd moeten zijn op een adres, danwel verblijfsobject. Aangezien er geen administratieve relatie is tussen het oude en het nieuwe adres/object, zal er bij beëindiging altijd nagegaan moeten worden hoe de nieuwe situatie zal worden. Dit is in sommige gevallen logisch af te leiden, maar zal in veel gevallen nagevraagd moeten worden; in dit geval bij de kledingzaak zelf. Een afnemer zal hiervoor een proces in moeten richten.



110

Bijlage 6 Wijzigingsprocedure van aansluitspecificaties

De aansluitspecificaties met het bijbehorende DIVA schema vormen technisch gezien het contract tussen DPG en de afnemers op basis waarvan gegevens kunnen worden uitgewisseld. Het is daarom van belang dat wijzigingen op deze specificaties op een duidelijke en gecontroleerde wijze worden doorgevoerd. Daarbij wordt een onderscheid gemaakt tussen functionele wijzigingen en tekstuele wijzigingen. Functionele wijzigingen Deze wijzigingen hebben gevolgen voor de gegevens die geleverd worden en/of de werking van de berichten. Dit soort wijzigingen zullen worden voorgelegd aan de afnemers, zodat zij de impact van de wijzigingen kunnen bepalen en dit kunnen terugkoppelen aan DPG. DPG kan hier dan rekening mee houden bij het plannen van de wijzigingen. Het streven is om deze review een half jaar voor de implementatie van de wijzigingen door te voeren, zodat afnemers voldoende tijd krijgen zich voor te bereiden op de wijzigingen. Tekstuele wijzigingen Dit soort wijzigingen zijn alleen bedoeld ter verduidelijking van de beschrijvingen en zullen geen gevolgen hebben voor de ontvangende programmatuur van afnemers. Deze wijzigingen worden alleen intern door DPG gereviewd waarna de aangepaste aansluitspecificaties op internet beschikbaar worden gesteld. Afnemers worden op de hoogte gesteld als er een nieuwe versie beschikbaar is.



111

Bijlage 7 Bronnen

7.1 Documenten

[DPG] gem. Amsterdam, DPG, ‘FO/TO Initiele levering Kennisgevingen.’ Amsterdam: 2006. [StUF] Egem, ‘StUF 02.04: EGEM Aanbeveling’. 2006. [VROM] VROM, ‘Koppelvlakbeschrijving. Bronhouders Landelijke Voorziening BAG’. Den Haag: 2006. 7.2 Hyperlinks

Axis: http://ws.apache.org/axis E-net: http://www.loket.e-net.amsterdam.nl SOAP: http://www.w3.org/TR/soap/ StUF: http://www.egem.nl/kennisbank/informatievoorziening/uitwisseling/stuf VROM: http://bag.vrom.nl/

1 Aansluitspecificaties Kennisgevingen - init levering ... · 1.0.0 04-05-2007 RJ definitief...

Documents

Transcript of 1 Aansluitspecificaties Kennisgevingen - init levering ... · 1.0.0 04-05-2007 RJ definitief...