Skip to content

BRMO voor beheerders

Mark Prins edited this page Aug 20, 2019 · 7 revisions

introductie

BasisRegistraties MidOffice is een centrale database, een voorziening voor het opslaan van basisregistraties. Het is een implementatie van het RSGB (Referentiemodel Stelsel van Gemeentelijke Basisgegevens) datamodel, ontwikkeld door het Kwaliteitsinstituut Nederlandse Gemeenten (KING).

Introductie brmo

werking

In de werking van de BRMO-service kunnen we twee hoofd fasen onderscheiden:

  1. Het ophalen van gegevens bij/van een basisregistratie en ‘staging’ (klaarzetten)
  2. Het transformeren van data basisregistratie naar RSGB (definitief beschikbaar maken)

introductie

De verschillende taken binnen de BRMO-service worden uitgevoerd middels Automatische Processen. Automatische processen kunnen via een taakplanner worden gestart en/of met de hand.

Automatische processen worden aangemaakt en beheerd vanuit de beheer interface, er is een apart tabblad met automatische processen. Om een nieuw proces aan te maken maak je een keuze uit de lijst en gebruik je vervolgens de "Nieuw" knop. Hierna kan/moet het proces verder worden geconfigureerd.

automatische processen

BRMO-service heeft Automatische Processen welke in 4 categoriën onder te verdelen zijn.

Overzicht automatische processen

geavanceerde functies

Geavanceerde functies hebben betrekking op beheer van de staging database. (exporteren, repareren, archiveren/verwijderen)

Overzicht geavanceerde functies

snelle updates

Te gebruiken bij aanpassingen van het data model of transformatie, bijvoorbeeld als onderdeel van een versie upgrade. Doel is om een deel van de berichten nog eens te transformeren, veelal zal in de upgrade instructies vermeld worden als dit gedaan dient te worden.

Overzicht snelle updates

monitoring

Bij problemen wilt u kunnen zoeken naar oorzaken, onder de motorkap van het voertuig kijken. Wanneer iets mis is gegaan: waar en hoe? Overzicht Monitoring

  1. logging per automatisch proces
  2. logging per bericht
  3. applicatie logfile

dagelijks beheer en troubleshooting

Aangezien iedere configuratie anders is geven we hier slechts een paar generieke aanwijzingen. De details zijn volkomen afhankelijk van de geladen basis registraties en mechanismes waarmee dat is gedaan.

status checks

De belangrijkste indicatie voor de gezondheid van het systeem is de status van de berichten. Berichten zullen in eerste instantie binnenkomen met een STAGING_OK status waarna ze verder verwerkt worden. Gebruik hiervoor het BerichtstatusRapport, eventueel in combinatie met de MailRapportage.

Als er iets mis is dan zal het aantal xxxxx_NOK berichten sterk groeien.

voor de status RSGB_BAG_NOK is het groeien helaas niet ongebruikelijk, deze status wordt ingesteld als de referentiële integriteit niet kan worden opgebouwd, dat gebeurt regelmatig bij de BAG, bijvoorbeeld een woonplaats zit in een jonger bericht dan een object in de woonplaats)

logfiles

bekijk regelmatig de logfile van de applicatie

opmerkingen inspectie

Via de berichten en/of laadprocessen pagina kan per bericht/laadproces de log worden bekeken. Initieel zal deze veelal de inhoud "undefined" hebben, het veld wordt gevuld tijdens verder verwerking. Het is mogelijk om de kolommen te filteren op soort en status, op zeker moment zal de database echter dermate groot (en traag) worden dat er timeouts optreden, in dat geval is het zaak uit te wijken naar een SQL tool.

berichten opzoeken in de database

Berichten worden geidentificeerd aan de hand van hun object_ref de natuurlijke sleutel van het object uit de basis registratie Vanwege de AVG wordt BSN niet gebruikt als sleutel, daar wordt een hash van de natuurlijke sleutel gebruikt.

opschonen staging database

Middels de Geavanceerde functies kan er databeheer worden gepleegd op de staging database, over het algemeen is het zo dat het onverstandig is om BRK berichten te beheren met deze processen (dus BRK niet archiveren of opschonen) Voor de BAG is het voor de meeste omgevingen wel zinvol.

bijwerken woonplaats/gemeente koppeling

Gemeenten zijn geen onderdeel van de BAG daarom moet de woonplaats/gemeente koppeling met de hand worden bijgewerkt. Dit gaat met behulp van de sql procedure 201_update_wnplts_gemcode.sql welke voor de verschillende database omgevingen te vinden is in: https://github.com/B3Partners/brmo/tree/master/datamodel/utility_scripts Het script wordt periodiek bijgewerkt aan de hand van de koppeltabel die Kadaster verstrekt (zie: https://www.kadaster.nl/bag-woonplaatscodes) deze wordt tenmiste eenmaal per jaar bijgewerkt.

Clone this wiki locally