In de communicatie tussen BAG- en WOZ-applicaties wordt gebruik gemaakt van de berichtencatalogus BAG. Deze catalogus ondersteunt voor kennisgevingen alleen de samengestelde kennisgevingen die gebaseerd zijn op gebeurtenissen. Wanneer er een nieuwe koppeling wordt gelegd tussen een BAG- en een WOZ-applicatie, zal de WOZ-applicatie moeten worden voorzien van de gegevens van de BAG-applicatie. Hiervoor is een confrontatie/initiële vulling vereist. Een veel gebruikte techniek hiervoor is nu om een (datadistributie-) systeem toevoegingen te laten sturen van alle beschikbare objecten. Deze kunnen dan door de ontvanger worden verwerkt en zo mogelijk worden gematcht met al aanwezige gegevens. Met het gebruik van de berichtencatalogus is dit feitelijk niet toegestaan (de ontvanger hoeft alleen samengestelde berichten te kunnen verwerken). Het is ook niet mogelijk om op basis van gebeurtenissen deze confrontatie uit te voeren: er is geen bericht voor en geen gebeurtenis gedefinieerd. Zou het niet wenselijk zijn om binnen de berichtencatalogus BAG ook berichten op te nemen voor deze situatie?
di, 22-10-2013 - 15.00u
#1
Confrontatie BAG/WOZ en berichtencatalogus BAG
Ik ben het eens met Sid dat het een goede uitbreiding zou zijn voor de berichtencatalogus om te omschrijven hoe er met een vulling moet worden omgegaan.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR305.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Toen VROM de definitieve versie van de BAG berichtencatalogus heeft opgesteld, is een deel uit de laatste "werk versie" niet opgenomen. In Hoofdstuk 5 "Generieke uitgangspunten" stond toen als eerste opmerking, zie bijlage: (begin citaat) Initieel vullen/aansluiten van een WOZ-applicatie op de BAG-applicatie gebeurt door complete berichten (T) of door synchronisatieberichten. (einde citaat). Op basis van deze opmerking heeft GeoTax besloten voor de initiële vulling vanuit de BAG applicatie Lk01-T berichten aan te bieden, met als gebeurtenis code "BAG-INIT".
Bijlage
Ik ben het helemaal met Han eens dat voor een initiële vulling gewoon toevoegkennisgevingen of synchronisatieberichten gebruikt moet worden. Deze zijn al beschikbaar. Als er ergens in de BAG berichtencatalogus staat dat een initiële vulling niet op deze manier uitgevoerd mag worden, dan zou dit verwijderd moeten worden. Zo niet, lijkt me het gebruik van berichten gedefinieerd binnen bg0310 gewoon toegestaan voor een initiële vulling waar gebeurtenissen niet relevant. Ik kan me voorstellen dat we dit verduidelijken in de BAG berichtencatalogus, te meer omdat dit lijkt te zijn weg gevallen.
Tijdens de StUF Expertgroep van 17 september 2014 gaf Henri Korver aan dat dit issue mogelijk te maken heeft met het feit dat Sid Brouwer de term koppelvlak en berichtencatalogus met elkaar verwart. Henri zei dat in de berichtcatalogus niet staat beschreven hoe je initieel vullen moet doen en dat dat correct is want dit staat beschreven in het BAG koppelvlak. De vraag is verder nog of we het extraElement ‘codeGebeuretnis’ gaan gebruiken om aan te geven of een StUF mutatie een initiële vulling is. Anemiek Droogh vroeg of het een idee was om de discussie aan te vullen met dat idee. Henri werd verzocht om dat wat hij in deze vergadering verteld heeft even op het forum plaatsen en ook Vicrea daar even van op de hoogte te stellen. We behandelen dit punt in de volgende vergadering evt. weer.
Bijgaand (zie bijlage) het "koppelvlak BAG". Hierin staat keurig beschreven dat een initiële vulling plaatsvindt middels kennisgevingen en synchronisatieberichten.
Bijlage
Tijdens de StUF Expertgroep van 28 januari 2015 is besloten dit erratum af te wijzen.