Beste bezoeker,

op dit moment wordt er een nieuwe release doorgevoerd op GEMMA Online. Hierdoor is de omgeving tijdelijk niet beschikbaar.

Vragen? Stuur een e-mail naar gemmaonline@vng.nl

Met vriendelijke groet, Kenniscentrum Architectuur VNG Realisatie

Binnengemeentelijk beschikbaar stellen basis- en kerngegevens

Laatst bewerkt: 13 juli 2021, 14:00:44

Vanuit diverse processen is er tijdens de uitvoering van de processen behoefte aan gegevens uit basis- en kernregistraties. Deze gegevens kunnen door de processen worden opgehaald bij de bron op het moment dat de gegevens binnen een proces nodig zijn maar er kan ook voor gekozen worden om kopieën van de gegevens bij te houden binnen de administratie van de component die het proces automatiseert. De kopiegegevens worden in dat geval actueel en synchroon gehouden met de bron door een distributiemechanisme [1]. We spreken hierbij over zogenaamde ‘push’ en ‘pull’ mechanismes.

Pullmechanisme – Bij een pullmechanisme haalt een afnemer de gegevens die nodig zijn bij de uitvoering van een proces op bij de bron. De afnemer houdt zelf geen kopieën van deze gegevens bij. De implementatie van een pullmechanisme heeft de voorkeur boven een pushmechanisme aangezien bij een pullmechanisme gegevens niet onnodig door het systeemlandschap gedistribueerd worden. Een pullmechanisme wordt vaak in combinatie met de Inwinnen en routeren van notificaties integratiestijl gebruikt. Gebeurtenissen worden dan door bronnen via notificaties aan afnemers kenbaar gemaakt en de afnemers halen op basis van deze gebeurtenissen de bij de gebeurtenis behorende gegevens op.

Pushmechanisme - Bij een pushmechanisme worden kopieën van gegevens in een administratie actueel gehouden via een distributiemechanisme en bij een pullmechanisme worden gegevens uit de bron gelezen op het moment dat ze nodig zijn. De keuze voor implementatie van een pull- of een push-mechanisme is mede afhankelijk van de beschikbaarheid van bronnen. Op het moment dat de serviceniveaus van bronnen niet aansluiten bij de gewenste serviceniveaus vanuit processen wordt veelal een push-mechanisme gebruikt. De reden hiervoor is dat bij gebruik van een push-mechanisme de afnemer altijd beschikt over near-realtime gegevens en bevraging van de bron daardoor onnodig is. Dit systeem wordt ook wel datareplicatie genoemd. Bij datareplicatie worden gegevens van een bronsysteem door andere informatiesystemen opgeslagen binnen hun eigen opslag en near real-time bijgehouden.

In dit patroon wordt beschreven op welke manier basis- en kerngegevens via een pushmechanisme beschikbaar kunnen worden worden gesteld gebruik makend van de GEMMA referentiecomponenten.

Beschrijving GEMMA patroon

In dit patroon zijn een aantal keuzes gemaakt ten aanzien van de wijze waarop gegevens beschikbaar worden gesteld aan afnemers en de manier waarop afnemers gerede twijfel aan de juistheid van gegevens kunnen melden.

  • Basisgegevens - De keuze is gemaakt om voor het binnengemeentelijk beschikbaar stellen van basisgegevens gebruik te maken van een pushmechanisme via de berichtuitwisseling integratiestijl. Er wordt ten aanzien van de gegevens uit basisregistraties dus gekozen voor datareplicatie. De reden voor deze keuze is het feit dat niet alle basisregistraties op een efficiënte en effectieve wijze bevraagbaar zijn via een pull-mechanisme en niet de serviceniveaus bieden die door gemeenten gewenst zijn. De keuze voor datareplicatie betekent dat basisregistraties mutaties van basisgegevens doorgeven aan gemeenten en gemeenten de verdere distributie van deze mutaties regelen via een gegevensdistributie-component;
  • Kernregistratiegegevens - De keuze is gemaakt om voor het binnengemeentelijk beschikbaar stellen van gegevens uit kernregistraties, zoals de kernregistratie medewerkers, via een pull-mechanisme te verlopen. De reden voor deze keuze is dat de gemeente zelf in-control is van serviceniveaus die geboden worden door kernregistraties. Het intern afstemmen van deze serviceniveaus op de door processen gewenste serviceniveaus is daardoor mogelijk en replicatie van de kerngegevens binnen taakspecifieke componenten is hiermee overbodig. De kerngegevens kunnen immers door processen direct uit de bron betrokken worden. Dit doet recht aan de principes van eenmalige vastlegging en meervoudig gebruik;
  • Terugmelding van gerede twijfel aan de juistheid van gegevens wordt door taakspecifieke componenten gemeld via de terugmeldingenregistratiecomponent. Deze component biedt functionaliteit om terugmeldingen van gerede twijfel te ontvangen en te routeren naar hetzij een basis- hetzij een kernregistratie.

Onderstaande figuur geeft schematisch de binnengemeentelijke levering en gebruik van gegevens uit basis- en kernregistraties weer.

Generieke weergave van de gemeentelijke kernregistraties. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (ApplicationComponent) Kernregistratiecomponent Generieke weergave van de landelijke basisregistraties. Deze generieke weergave wordt gebruikt in de modellering van GEMMA patronen. (ApplicationComponent) Basisregistratie Component voor het doen van terugmeldingen over gegevens bij twijfel aan de juistheid daarvan. (ApplicationComponent) Terugmeldingen-registratiecomponent Abstract verzamelcomponent voor Specifieke procesafhandelcomponenten. Dit zijn taak-specifieke systemen waarin zaakgericht gewerkt of op zijn minst zaakgericht geregistreerd wordt. Systemen die invulling geven aan deze referentiecomponent moeten zaakinformatie kunnen bijwerken in een Zakenregistratiecomponent (ZRC) via de standaard Zaak-documentservices. (ApplicationComponent) Specifiek zaakafhandelcomponent (abstract component) Component voor distributie van gemeentelijke basis-, en optioneel, kerngegevens naar afnemende applicaties binnen de gemeente. Het gegevensdistributiesysteem wordt gevoed vanuit applicaties die basis- en kerngegevens onderhouden. (ApplicationComponent) Gegevensdistributiecomponent Component voor opslag en ontsluiting van basis- en aangehaakte gegevens. (ApplicationComponent) Gegevensmagazijncomponent FlowRelationship afnemen kerngegevens FlowRelationship FlowRelationship levering kennisgevingen van mutatie van gegevens FlowRelationship Melding gerede twijfel FlowRelationship Melding gerede twijfel FlowRelationship aanleveren kerngegevens FlowRelationship terugmelden gerede twijfel FlowRelationship instelllen distributieregel- s FlowRelationship instellen abonnementen FlowRelationship plaatsen afnemerindicati- es FlowRelationship leveren kennisgevingen FlowRelationship synchroniseren gegevens FlowRelationship leveren kennisgevingen FlowRelationship synchroniseren gegevens FlowRelationship instellen abonnementen FlowRelationship instellen distributieregel- s Deze svg is op 13-09-2021 14:47:46 CEST gegenereerd door ArchiMedes™ © 2016-2021 ArchiXL. ArchiMedes 13-09-2021 14:47:46 CEST


Aandachtspunten

De keuze voor datareplicatie bij basisgegevens via een gegevensmagazijncomponent is ingegeven door het feit dat er geen alternatieven zijn. Redenen hiervoor zijn de door basisregistraties geboden serviceniveaus en restricties op de afname van gegevens door afnemers bij basisregistraties. Datareplicatie is in de visie van VNG Realisatie een tijdelijke oplossing. Zodra de basisregistraties geschikt zijn voor directe bevraging kan worden overgestapt op een pull-mechanisme.

Standaarden

Ten aanzien van de distributie van basisgegevens dient binnengemeentelijk gebruik gemaakt te worden van StUF-BG berichten. Aanlevering van mutaties door basisregistraties verloopt via diverse (StUF) berichtsoorten. De BRP levert mutaties via StUF-BG, de NHR levert StUF-HR, de BRK levert BRK-Leveringen en de BAG levert StUF-BAG.