ZRC-005 en BRC-005 leiden tot gegevensverdubbeling en zijn strijdig met common ground

[johannesbattjes]

Eén van de basisprincipes van common ground is eenmalige vastlegging: "We leggen gegevens eenmalig vast en vragen op bij de bron."

ZRC-005 luidt "Wanneer een relatie tussen een INFORMATIEOBJECT en een ZAAK gemaakt of bijgewerkt wordt, dan MOET het ZRC in het DRC ook deze relatie aanmaken/bijwerken." BRC-005 heeft een soortgelijke strekking (Bij VRC lijkt de regel te ontbreken, al kent de DRC wel een objectinfomatieobject-objecttype "verzoek"). Deze regels leiden tot gegevensverdubbeling en zijn dus strijdig met het common groundprincipe van eenmalige vastlegging. In de praktijk leidt de synchronisatie ook tot problemen, omdat in foutsituaties gegevens uiteen kunnen gaan lopen tussen DRC, ZRC, en BRC. Zowel het synchronisatiemechanisme als het foutherstelmechanisme zijn kostbaar om te bouwen, implementeren en onderhouden ervan gaat ten koste van het maken van nuttige functies.

Voorstel is de gegevensverdubbeling te stoppen. Twee oplossingsrichtingen zijn denkbaar:

(1) Verwijder de entiteit objectinformatieobject en bijbehorende Api-methodes uit de DRC. Omdat client apps verplicht zijn de relatie aan te maken in ZRC en BRC (en niet DRC), heeft deze oplossing wellicht de minste impact. DRC-008 moet dan ook aangepast worden zodat de DRC de eventuele relaties opvraagt uit de ZRC en BRC

(2) Verwijder de entiteit zaakinformatieobject, besluitinformatieobject, verzoekinformatieobject en bijbehorende Api-methodes uit de ZRC, BRC en VRC. Consumers moeten dan de relaties direct in de DRC aanmaken met de bestaande API methodes in de DRC, waarvan nu is aangemerkt dat deze niet voor consumers bedoeld zijn. Daarmee is deze oplossing een breaking change.

Overigens bestaat de entiteit objectinformatieobject al niet meer in de plaat CLASS Documenten Api 1.1.0 maar dat lijkt een fout te zijn aangezien de entiteit nog wel methodes en businness rules kent.

[michielverhoef]

Het in twee registers vastleggen van relaties is niet strijdig met common ground. Immers, deze relatie wordt slechts éénmaal vastgelegd in de twee betrokken registers en niet ook nog in andere registers/systemen.

De keuze en verantwoording om relaties zowel in de source als de target vast te leggen staat beschreven in https://vng-realisatie.github.io/gemma-zaken/themas/achtergronddocumentatie/ontwerpkeuzes onder het kopje "Many-to-many relaties verspreid over API’s". Om te kunnen borgen dat er niet per ongeluk gerelateerde objecten verwijderd worden is het nodig dat bij het gerelateerde object vastgelegd wordt dat het gerelateerd is aan een object in een ander register en aan welk object dat dan is.

Wel zie ik dat de plaat met entiteiten voor de DRC bijgewerkt moet worden, zeker nu we inmiddels al bij Documenten API versie 1.4.x zijn.

[johannesbattjes]

Beste Michiel @michielverhoef ,

zou je deze willen heropenen? De problemen die wij beschrijven zijn serieus.

Bedankt verder voor de link naar de many-to-manyregel die wij niet kenden. Het lijkt er op dat de regel is bedacht als maatregel voor een situatie die wij niet tegen komen: één drc met honderden zrc's/brc's. In de praktijk is de relatie DRC-ZRC en DRC- BRC 1 op 1. en niet 1 op n. Verder kan ik maar één situatie vinden waarbij de drc een check doet op het bestaan van de relatie en dat is drc-008. Deze check hoeft alleen gedaan te worden bij verwijderen. Meestal is dat vernietiging in het kader van archiefbeheer. hoe dan ok verwijderen komt maar één keer in het leven van een enkelvoudiginformatieobject voor. De overhead van de check is dus gering. Een andere vraag is ook of een dergelijke check wel gedaan moet worden door DRC - of dat het de verantwoordelijkheid is van bijvoorbeeld de archiefbeheer-app