Berichtuitwisseling in keten op basis van insert/only koppelvlak

Samenvatting - Berichtuitwisseling tussen een bron en kopieën in een keten op basis van insert/only koppelvlak

Dit voorstel betreft het onderwerp ‘kopieën van een bron’. De bron is vaak een authentieke basisregistratie en de gegevens worden via XML berichten naar de kopie gestuurd, vaak een Landelijke voorziening en daarna naar Afnemers van de Landelijke Voorziening. Uitgangspunt waar we in het stelsel van basisregistraties het, in het kader van het bijhouden van kopieën (zolang dit nog gebeurd), over eens (zouden moeten) zijn is dat implementaties om een kopie bij te houden eenvoudig gehouden moeten worden.

Echter, in de praktijk is dit (nog) niet eenvoudig gemaakt. Mutaties die ontstaan bij de bronhouder, tijdens mutatieprocessen, zouden zodanig naar de keten doorgeleverd moeten worden dat er voor een juiste verwerking minimale kennis nodig is. Anders gezegd, zo min mogelijk kans is op interpretatieverschillen, want deze leiden tot vervelende fouten en verstoringen.

Dit voorstel laat zien dat het mogelijk is om op basis van simpele regels een eenvoudig koppelvlak te definiëren, waarbij een kopie heel simpel kan worden bijgewerkt. Er is hierbij dan voor bijwerking van de kopie geen kennis over complexere processen, zoals inactief maken, correctie en synchronisatie en ook niet over materiële en formele historie. Deze hoeven niet (bewust) geïmplementeerd te worden; de kopie hoeft hiervan geen enkele kennis te hebben en ook niet van het historiemodel van de authentieke bron, noch van andere specifieke keuzes die bij de bron worden gemaakt.

Gevolg van het voorstel is dat Afnemers zich alleen hoeven te concentreren op gebruik van de gegevens, en (vrijwel) niet op de verwerking. De voorgestelde eenvoudige verwerkingsmethode maakt implementaties voor het bijhouden van een kopie zeer eenvoudig. Dit scheelt een hoop kosten in de keten, maar vereist wel dat de vertaling van gemeenteprocessen naar het insert/update koppelvlak t.b.v. de keten gedaan wordt voordat XML berichten (verder) de keten in wordt gestuurd.

Het initiële verzoek is om de doelstelling te onderschrijven dat, voor het bijhouden van een kopieen in de keten, koppelvlakken zodanig te definieren dat deze eenvoudig zijn, met lage kosten en bovenal niet gevoelig zijn voor interpretaties. StUF heeft dit al als doelstelling en dit voorstel ligt in deze lijn, maar gaat verder dan StUF nu doet. Een vervolg verzoek zou kunnen zijn om de aanpak in dit voorstel te beoordelen voor opname in StUF.

NB. Complexiteit zou overigens nog verder (onnodig) toenemen als, voor het bijhouden van een kopie, er gekozen zou worden om in plaats van mutaties gebeurtenissen te versturen. Gebeurtenissen, waaruit de mutaties nog uit afgeleidt zouden moeten worden, is nog interpretatie gevoeliger en daarmee geen route naar een eenvoudige succesvolle keten.

1 Inleiding

Dit voorstel betreft het onderwerp ‘kopieën van een bron’. De bron is vaak een authentieke basisregistratie en de gegevens worden via XML berichten naar de kopie gestuurd, vaak een Landelijke voorziening of een Afnemer van de Landelijke Voorziening.

Het voorstel wordt ingebracht vanuit Lennart van Bergen (Kadaster ICT [1] ) en beschrijft een eenvoudige verwerkingsmethode voor van het bijhouden van een kopie. De kopie kan bijgehouden worden in bijvoorbeeld een Landelijke Voorziening en bij afnemers van een Landelijke Voorziening; dit vanuit het gegeven dat afnemers vaak nog kiezen voor een kopie. Met de bijhouding van kopieën is ervaring opgedaan vanuit de BAG, BGT, WKPB en EPC en sinds kort ook de WOZ. Er is voor Landelijke Voorzieningen een speciaal team bij Kadaster ICT die het beheer voert over diverse koppelvlakken, software en databases.

[1] Hoewel de inbreng is besproken met een aantal personen binnen het kadaster uit de verderop in de tekst genoemde diensten is er geen sprake van een algemeen kadaster standpunt.

Relatie met StUF

In de StUF expert groep kunnen voorstellen worden ingebracht.

StUF maakt momenteel gebruik van was-wordt mutaties op het niveau van objecten. Het object was voor de mutatie X en is na de mutatie Y geworden. Echter, er vinden ook mutaties/bijwerkingen op het bestaande voorkomen plaats, zoals de einddatum geldigheid, tijdstip vervallen van de formele historie, en bv. een statusveld zoals inactief. Deze bijwerking op bestaande voorkomens is complex, en heeft soms ook gevolgen voor voorliggende voorkomens, die helemaal niet in de was-wordt mutaties van het object zijn meegegeven. Deze verborgen mutaties zijn interpretatiegevoelig. Dit voorstel biedt een oplossing om hier foutloos mee om te kunnen gaan, zonder dat er kennis nodig is bij de verwerkingssoftware van de kopie.

Belangrijke opmerking vooraf: in algemeenheid het streven zou moeten zijn om zo min kopieën in een samenwerkingsketen te creëren, omdat het niet eenvoudig is om de gegevens actueel en gelijk te houden. Toch wordt hier in de praktijk nog wel vaak voor gekozen. Het is daarom van belang om implementaties zo eenvoudig mogelijk te houden voor elke partij in de keten. Dit voorstel gaat hier op in.

2 Beschrijving situatie en probleem

2.1 Toepassingsgebied

Gegevens worden van de ene schakel in de keten naar een volgende schakel in de keten doorgestuurd. De afspraak is dat deze uitwisseling op basis XML gebeurt via op XML gebaseerde koppelvlakken. Onderliggende software implementatie verzorgt de opslag in de database.

2.2 Probleem beschrijving

Voor het bijhouden van een kopie is het nodig om berichten te ontvangen van de voorliggende schakel in de keten. Deze implementaties worden gemaakt bij bijvoorbeeld een Landelijke Voorziening, en bij 10-tallen Afnemers. Het is absoluut niet de bedoeling dat deze partijen hiervoor hoge investeringen moeten doen. Dit gebeurt echter in de praktijk wel.

De oorzaken hiervan zijn:

• interpretatieverschillen en hiaten in specificaties met verschillende implementaties tot gevolg
• bugs in de implementatie waardoor deze gegevens anders verwerkt dan in de bron
• kennis vereist van de specifieke wijze waarop de bronhouders hun registratie bijwerken.

2.3 Doelstelling

Uitgangspunt waar we het in het kader van het bijhouden van kopieën over eens (zouden moeten) zijn is dat implementaties om een kopie bij te houden eenvoudig gehouden moeten worden. Echter, in de praktijk worden mutaties die ontstaan bij de bronhouder tijdens mutatieprocessen zodanig geleverd dat er voor een juiste verwerking bij een kopie alsnog kennis vereist is van correcties, intrekken mutaties in de toekomst, synchronisaties en het bijhouden van formele historie. De rijkheid van een basisregistratie komen zo in software terecht die de kopie bijhoudt.

Het is echter nagenoeg onmogelijk om bij de LV en elke afnemer de verwerking precies gelijk te implementeren als de bronhouder doet. Een dergelijke implementatie kost ook al snel enkele honderden dagen. Het initiële verzoek is om deze doelstelling te onderschrijven.

Het voorstel in deze notitie werkt de doelstelling uit door een methode te beschrijven waarmee de bijhouder van de kopie eigenlijk in het geheel geen interpretatie hoeft te doen. Dit resulteert in een eenvoudige en goedkope manier een copy-conform kopie kan bijhouden.

3 Voorstel: insert en/of update per voorkomen

3.1 Mindset

De overtuiging is om, als het doel is een kopie bij te houden, een replicatie mindset te hanteren, waarbij de logica voor het bijhouden van de gegevens alleen bij de basisregistratie c.q. de bron ligt. De rest van de keten volgt de basisregistratie en zou géén enkele interpretatie hoeven te doen voor het verwerken van de gegevens naar de kopie.

Dit kan wanneer de volgende strategie wordt gevolgd voor het bijhouden van een kopie:

als een nieuw voorkomen/versie van een object ontstaat: doe een insert

als een bestaand voorkomen/versie van een object wordt gewijzigd: doe een update

Uitgangspunten die gehanteerd zijn is dat de kopie wordt bijgehouden door middel van het doorgeven van mutaties via XML berichten en dat de gegevensdefinitie één op één de (desbetreffende versie) van de gegevenscatalogus volgt.

3.2 Toe te passen regels bij berichtdefinitie

De regels uit deze paragraaf zorgen ervoor dat een kopie zeer eenvoudige en (vrijwel) foutloze software kan hebben. De definitie van mutaties en berichten werkt met de volgende regels:

Een mutatie heeft als scope één object. Meerdere mutaties die bij elkaar horen worden tegelijk met elkaar meegeven in één bericht. Van elke versie van een object worden alle attributen meegegeven. Een mutatie wordt per nieuw en/of bestaand voorkomen van een object weergegeven Van elk voorkomen wordt de was en de wordt situatie meegegeven

Deze regels zijn generiek. Er zit geen enkele interpretatie logica in, waardoor de kopie van de bron geen kennis nodig heeft van complexe mutatieprocessen zoals inactief maken, correcties of synchronisatie.

Ad 1. In een database zitten tabellen die per objecttype worden gedefinieerd. De definitie komt uit de gegevenscatalogus.

Ad 1 en 2. Het is mogelijk om metagegevens van gebeurtenis hierbij mee te geven, zoals de gebeurtenis identificatie (individueel herkenbaar) en de gebeurtenis code en datum.

Ad 3. Dit is vereist om een simpele insert of update uit te voeren. Hier worden berichten wel groter van, maar ook heel standaard.

Ad. 4 en 5. Een object heeft voorkomens. Een mutatie op een object heeft meestal tot gevolg dat er een nieuw voorkomen ontstaat en meestal ook tot gevolg dat een bestaand voorkomen bijgewerkt moet worden bijgewerkt. Bijvoorbeeld een ingevulde einddatum van de materiële historie, een tijdstip vervallen van de formele historie of een status indicatie waarmee een gegeven inactief of gecorrigeerd wordt.

4 Voorbeeld berichten

4.1 Opvoer van een object

Nieuw voorkomen 1 ontstaat op formeel historie tijdstip F0 met materiële historie 1/1/2013.

Voorkomen	Functionele sleutel	Overige attributen
1	object id	datum begin	volgnummer	Datum einde	Inactief	Attribuut1
was	-	-	-	-	-	-
wordt	1	1/1 2013	1	-	Nee	aaa

4.2 Wijziging van een object

Nieuw voorkomen 2 ontstaat op formeel historie tijdstip F1 met materiële historie 2/2/2013.

Voorkomen	Functionele sleutel	Overige attributen
2	object id	datum begin	volgnummer	Datum einde	Inactief	Attribuut1
was	-	-		-	-	-
wordt	1	2/2/2014	2	-	Nee	bbb

De kopie van de bron verwerkt dit als volgt: insert voorkomen 2 met de ‘wordt’ gegevens. Verder is er geen logica vereist over bijwerking van andere voorkomens, omdat deze aanpak per enkelvoudig voorkomen werkt.

Bestaand voorkomen 1 vervalt op formeel historie tijdstip F1.

Voorkomen	Functionele sleutel	Overige attributen
1	object id	datum begin	volgnummer	Datum einde	Inactief	Attribuut1
was	1	1/1 2014	1	-	Nee	aaa
wordt	1	1/1 2014	1	2/2/2013	Nee	aaa

De kopie van de bron verwerkt dit als volgt: update voorkomen 1 met de ‘wordt’ gegevens. Verder is er geen logica vereist over bijwerking van andere voorkomens, omdat deze aanpak per enkelvoudig voorkomen werkt.

N.B. Alle andere mutatie processen zoals correcties, intrekken mutaties in de toekomst, synchronisaties etc. zijn vanuit het gezichtspunt van de kopie van de bron precies dezelfde was-wordt verwerkingen als de bovenstaande. Dit komt omdat er gewerkt wordt met mutaties op het niveau van een voorkomen i.p.v. op een object. Deze mutatieprocessen zijn wel uitgewerkt in de volgende paragrafen, omdat de bron deze complexere mutaties wel moet vertalen naar bovenstaande simpele mutaties Voor de verwerking bij de kopie is de logica uit de volgende paragrafen niet meer relevant. Het eindresultaat is hetzelfde.

4.3 Inactief maken van het laatste voorkomen (geen kennis voor nodig bij kopie)

Een actueel voorkomen wordt inactief gemaakt. Bv. bij het intrekken van een mutatie met een begindatum in de toekomst. Voorliggende gegevens worden weer geldig. Bestaand voorkomen 1 mag niet gewijzigd worden want dan raakt historie verloren (einddatum). Voorkomen 1 wordt dan ook niet gemuteerd (geen was-wordt).

Voorkomens 1 en 2 bevatten beide verkeerde informatie en moeten inactief worden gemaakt tijdstip F2. Voorkomen 2 bevat gegevens die worden ingetrokken. Dit is echter onvoldoende, want voorkomen 1 bevat een ingevulde datum einde en alleen voorkomen 2 inactief maken resulteert in een gat in de tijdslijn.

Voorkomen 2 wordt inactief op formeel historie tijdstip F2.

Voorkomen	Functionele sleutel	Overige attributen
2	object id	datum begin	volgnummer	Datum einde	Inactief	Attribuut1
was	1	2/2/2014	2	-	Nee	bbb
wordt	1	2/2/2014	2	-	Ja	bbb

De kopie van de bron verwerkt dit als volgt: update voorkomen 1 met de ‘wordt’ gegevens.

Voorkomen 1 wordt ook inactief formeel historie tijdstip F2.

Voorkomen	Functionele sleutel	Overige attributen
1	object id	datum begin	volgnummer	Datum einde	Inactief	Attribuut1
was	1	1/1 2014	1	2/2/2013	Nee	aaa
wordt	1	2/2/2014	2	2/2/2013	Ja	bbb

NB. Het is niet toegestaan om datum einde leeg te maken. Dan raakt het gegeven verloren dat datum einde op formele historie F1 nog 2/2/2013 was.

De kopie van de bron verwerkt dit als volgt: update voorkomen 1 met de ‘wordt’ gegevens.

Nieuw voorkomen 3 met de gegevens van voorkomens 1 ontstaat op formeel historie tijdstip F2.

Voorkomen	Functionele sleutel	Overige attributen
3	object id	datum begin	volgnummer	Datum einde	Inactief	Attribuut1
was	-	-	-	-	-	-
wordt	1	1/1 2013	3	-	Nee	aaa

De kopie van de bron verwerkt dit als volgt: insert voorkomen 2 met de ‘wordt’ gegevens.

4.4 Correctie (geen kennis voor nodig bij kopie)

Een correctie volgt dezelfde verwerking als bij het inactief maken van een voorkomen, maar met andere attribuutwaarden voor Attribuut 1.

Er kan hierbij ook sprake zijn dat er meerdere voorkomens gecorrigeerd moeten worden gemaakt en dat er meerdere voorkomens in verbeterde vorm met een juiste materiële historie worden opgevoerd met een actuele formele historie. Dit is niet altijd eenvoudig. Echter, zolang er gebruik gemaakt wordt van de insert en/of update strategie, is dit voor de kopie transparant. Deze ontvangt immers gewoon inserts en updates en na verwerking hiervan is de kopie weer gelijk aan de bron.

4.5 Synchronisatie (geen kennis voor nodig bij kopie)

Synchronisatie is nodig wanneer er onbedoeld verschillen zijn ontstaan tussen de schakels in de keten.

Uitgangspunt is dat de kopie weer in sync komt met de voorliggende schakel in de keten.

Verschillen zijn vrijwel altijd een gevolg van een foutsituatie, waarin:

• Een bericht niet is verwerkt vanwege een fout en de bron deze fout niet afhandelt
• De bron een fout corrigeert en deze niet via gewone mutaties doorgeeft aan de volgende in de keten.
• De kopie een bericht verkeerd heeft verwerkt als gevolg van een software fout
• Een crash bij de bron of een kopie, gevolgd door een back-up, waardoor recente mutaties kwijt zijn

De voorgestelde verwerkingsmethode gaat deze foutsituaties uiteraard niet voorkomen, maar kan wel van pas komen bij het oplossen van de ontstane verschillen. Synchronisatie is in de verwerkingsmethode eigenlijk gewoon een reeks van insert en updates op bestaande voorkomens, of wanneer een voorkomen helemaal niet in de kopie zit, ook op nieuwe voorkomens. De bron stuurt de levenscyclus van een object op. De kopie kijkt of deze de voorkomens al heeft. Zo ja, geen actie nodig. Zo nee, de insert of update uitvoeren.

Opmerkingen bij synchronisatie

• StUF schrijft bij synchronisatie een methode voor waarin de mutaties op object niveau nogmaals worden opgestuurd/afgespeeld. In het geval een software fout is het echter niet mogelijk om de levenscyclus weer opnieuw op te bouwen via gewone mutaties. Immers, deze mutaties zullen ook verkeerd verwerkt worden via dezelfde foute software. Dit recreëert de fout en zorgt niet voor synchronisatie. In de bovenstaande voorgestelde verwerkingsmethode is de kans op een foute implementatie veel kleiner.
• In feite hoeven bij synchronisatie alleen ongelijke voorkomens te worden verbeterd. Het is ongewenst dat goede, juiste voorkomens in dit proces onnodig inactief worden gemaakt, of gecorrigeerd worden waarbij de voorkomens in het geheel niet veranderen. Hierdoor wordt de formele historie en/of registratietijdstippen in een kopie onnodig vernieuwd.

5 Conclusie

Het is mogelijk om op basis van simpele regels een eenvoudig koppelvlak te definiëren, waarbij een kopie heel simpel kan worden bijgewerkt.

Er is hierbij dan voor bijwerking van de kopie geen kennis over complexere processen zoals inactief maken, correctie en synchronisatie en ook niet over materiële en formele historie. Deze hoeven niet geïmplementeerd te worden; de kopie hoeft hiervan geen enkele kennis te hebben en ook niet van het historiemodel van de authentieke bron, noch van andere specifieke keuzes die bij de bron worden gemaakt.

De voorgestelde verwerkingsmethode maakt implementaties voor het bijhouden van een kopie zeer eenvoudig. Dit scheelt een hoop kosten in de keten.

Verzoek is om het hierboven beschreven voorstel ‘insert en/of update op het niveau van voorkomens’ te behandelen in de toekomstvisie van StUF.

Het voorstel is, indien gewenst, mogelijk ook geschikt om vanuit StUF te worden mee ontworpen en om als open source geschikt/beschikbaar worden gemaakt.

Bijlage: variant “insert only”

Deze variant is net wat anders dan was-wordt. Deze aanpak lijkt wel sterk op de was-wordt aanpak, maar hiervoor worden alleen de nieuwe voorkomens uitgewisseld. Alleen het opvoer scenario wordt toegepast in de uitwisseling en in de verwerking naar de kopie is er geen aanvullende verwerkingslogica nodig

Voordeel van deze aanpak is dat een kopie alleen inserts hoeft te doen. Nadeel is dat het gewijzigde attribuut in de berichtuitwisseling niet zichtbaar is. Deze is wel zichtbaar bij de was-wordt aanpak.

Bij de insert only aanpak worden geen mutaties op bestaande voorkomens doorgegeven, de einddatums of inactief waardes van bestaande voorkomens worden niet bijgewerkt, maar impliciet afgesloten door het nieuwe voorkomen. Bij een normale wijziging is de einddatum van een bestaande afleidbaar vanuit de begindatum van het erna liggende voorkomen. Inactief of gecorrigeerde voorkomens zijn herkenbaar aan dezelfde functionele sleutel, maar met een verhoogd volgnummer, welke uniek is per voorkomen van een object.

Een bijkomend voordeel van zo’n volgnummer is dat mutaties in willekeurige volgorde verwerkt kunnen worden, omdat mutaties geen enkele invloed meer hebben op elkaar. Dit is bij a-synchrone uitwisseling een voordeel.

Het genoemde volgnummer is niet altijd onderkend in informatiemodellen, en het bij het raadplegen afleiden van welk voorkomen actief is, wat de datum einde geldigheid van een voorkomen is en wanneer een voorkomen wat betreft formele historie is vervallen, is complexer dan bij een aanpak waarin deze gegevens wel worden vastgelegd c.q. wel worden bijgewerkt via was-wordt updates.

De afweging is of een eenvoudigere berichtuitwisseling opweegt tegen het complexer worden van raadplegingen. Gezien de eenvoud van was-wordt per voorkomen (dit document) lijkt de balans door te slaan naar was-wordt. Insert only is wel een stuk eenvoudiger dan was-wordt op het niveau van objecten.

[ tekst in dit voorstel is afkomstig van: 20130613 Voorstel insert-update aanpak voor bijhouden kopie v0_31.doc ]