Business rules ZTC-010 en ZTC-011 maken het vrijwel onmogelijk concept zaaktypes te wijzigen en nieuwe versies van zaaktypes te maken #1838
Comments
Deze beschreven werkwijze is niet correct en niet zoals de Catalogi API bedoeld is. Een Zaaktype is in feite een geheel van Zaaktype en gerelateerde typen zoals Roltypen, Besluittypen, Informatieobjecttypen, Statustypen, Resultaattypen, zaaktype-informatieobjecttypen. De status van de gerelateerde typen is afhankelijk van de status van het Zaaktype. Is het Zaaktype niet meer concept zijn ook de gerelateerd typen niet meer in concept. Het is dus niet toegestaan een nieuw Zaaktype te maken en hier bestaande gerelateerde typen aan te koppelen. Dit is technisch ook niet te doen, immers, ni een gerelateerd type wordt verwezen naar 1 zaaktype. wanneer deze verwijzing zou veranderen hou je een zaaktype over wat niet meer compleet is: Een deel van de gerelateerde typen is gekoppeld aan een ander Zaaktype en het is niet meer mogelijk om het oude Zaaktype in zijn geheel op te vragen. De oplossing hiervoor is bij het maken van de kopie van het oude Zaaktype ook de bestaande gerelateerde typen te kopieren en deze aan de kopie van het Zaaktype te koppelen. |
|
"Een Zaaktype is in feite een geheel van Zaaktype en gerelateerde typen zoals Roltypen, Besluittypen, Informatieobjecttypen, Statustypen, Resultaattypen, zaaktype-informatieobjecttypen." |
|
Edit: Nadat ik het geval nog eens bekeken had en uitgewerkt had in een uitleg kwam ik tot de conclusie dat mijn eerdere idee over een backwards incompatible wijziging niet klopte. Eigenlijk is het heel simpel: De relaties tussen Zaaktype en bijvoorbeeld Rtatustype, Roltype, Eigenschap etc zijn 1 op n. Zie ook de diagrammen op deze pagina's: De relatie tussen zaaktype en informatieobjecttype is wel n op n. Die relatie wordt in de API via de relatieklasse ZaaktypeInformatieobjecttype gelegd. Bij het aanmaken (POST), bijwerken (PUT, PATCH) is het niet mogelijk urls naar relevante Informatieobjecttypen mee te geven. Die urls komen wel terug in het antwoord maar dat is puur voor het gemak. Zo kun je in één keer zien welke Informatieobjecttypen relevant zijn voor welk Zaaktype en andersom. Volgens mij moet het met de relatieklasse ZaaktypeInformatieobjecttype mogelijk zijn om een Informatieobjecttype te relateren aan meer dan één (versie van een) Zaaktype. |
Ja, dat is ook mogelijk, je kan die relatie leggen zo lang minimaal één van de twee (ZT of IOT) nog in concept is. Dat is de uitzondering die geformuleerd is in ZTC-010 "Voor ZaakType-InformatieObjectType gelden bovenstaande regels (ztc-010) alleen in het geval waarbij zowel het ZaakType als het InformatieObjectType concept=False hebben". Dan het probleem met ZTC-011. Als je een nieuw ZT maakt is dat uiteraard nog concept. Zodra je daar een gepubliceerd IOT aan koppelt, zegt ZTC-011 dat je het concept ZT niet meer mag aanpassen omdat het een relatie heeft naar een gepubliceerd object. Dat is ontzettend onpraktisch, want dat betekent dat je wijzigingen aan het concept ZT in een precieze volgorde moet doen. Doordat ZTC-012 nog steeds afdwingt dat je een ZT niet mag publiceren zolang er relaties zijn met concept objecten, levert het schrappen van ZTC-010 en ZTC-011 helemaal geen probleem op. Die regel dwingt immers af dat bij gepubliceerde zaaktypen alle relaties correct zijn naar gepubliceerde IOT's en BT's, waardoor het schrappen van ZTC-010 en ZTC-011 alleen impact heeft op concept Zaaktypen. |
|
Wat het lastig maakt is dat de n op n relatie tussen Zaaktypen en Informatieobjecttypen gelegd wordt met een relatieklasse. De relatie tussen Besluittypen en Zaaktypen wordt rechtstreeks gelegd, in het objecttype zelf. Tot op zekere hoogte is dat logisch omdat de relatieklasse extra metainformatie bevat over die relatieklasse. De relatie tussen Besluittypen en Zaaktypen heeft dat niet, daarom is er geen relatieklasse. Een oplossing kan zijn al de n-op-n relaties te leggen via een relatieklasse (koppeltabel eigenlijk). Dat is geen afwijking van het ImZTC, het is een technische invulling voor het leggen van een relatie zoals die is beschreven in het Semantische Informatiemodel. Dit zou dan ook gelden voor bijvoorbeeld ProductenOfDiensten. Nu ik er zo over nadenk is een deel van het probleem dat er geen 1-op-1 of 1-op-n relaties bestaan. Zodra een nieuwe versie van een Zaaktype aan een bestaand objecttype gekoppeld wordt is er al sprake van een 1-op-n (n-op-1) relatie. Ik verwacht eigenlijk dat op de achtergrond een implementatie al zoiets zal doen via een koppeltabel of iets dergelijks. Bij het opvragen van objecttypen kunnen de relaties wel in het antwoord opgenomen worden. Dus zoals nu ook al gebeurt. Het voordeel van het gebruik van aparte resources om (alle) relaties te leggen is dat ZTC-009 en ZTC-010 gaan werken zoals nu voor ZaaktypeInformatieobjecttype beschreven staat. Los van het voordeel dat het leggen van relaties dan altijd op dezelfde manier werkt. Wel moet er dan een betere invulling van ZTC-011 komen. Het moet minder ingewikkeld worden om een Zaaktype in te richten. Iets als dat het mogelijk is om nieuwe relaties via een relatieklasse te leggen wanneer het Zaaktype nog niet gepubliceerd is. In dit geval loopt de relatie van "Zaaktype heeftRelevant Informatieobjecttype". Zaaktype mag dan niet concept=false zijn, de Informatieobjecttypen wel. Er verandert immers niet aan het Informatieobjecttype. Het vervelende van de huidige ZTC regels is dat niet gekeken wordt naar de richting van de relatie. Bij het leggen van de relatie moet gekeken worden naar de conceptstatus van het objecttype van waaruit de relatie gelegd wordt. Die status mag niet zijn concept=false. Maar een nieuw objecttype mag best verwijzen naar een al bestaand objecttype. Zolang dat bestaande objecttype niet veranderd hoeft te worden. Dat laatste hoeft niet wanneer de relaties gelegd worden vanuit de relatieklasse in plaats van in een attribuut in het objecttype zelf. @HenriKorver Wat vind jij? |
|
Op zich niet slecht om de relaties tussen opzichzelfstaande entiteiten zoals Zaaktypen, Besluittypen en Informatieobjecttypen altijd via een relatie-object te leggen, zoals nu al bij de ZT-IOT relatie. Om het helemaal consequent te maken, zou dat dan in mijn ogen ook moeten gelden voor ZT-ZT relaties (voor mogelijke deelzaaktypen of gerelateerde zaaktypen). Want volgens een strikte interpretatie van business rule ZTC-010 zou die business rule ook gelden voor deze ZT-ZT relaties, ook al is er zo ver ik weet geen enkele ZGW implementatie die dat zo doet, Open Zaak en de VNG Referentie-implementatie in ieder geval niet. Het maakt echter de standaard wel weer complexer, met nog meer entiteiten. Maar het is binnen de huidige standaard wel gewoon mogelijk om een implementatie te maken die business rules ZTC-010 en ZTC-011 negeert, zonder enige consequentie voor de rest van de werking. Als wij in onze ZGW implementatie het volgen van ZTC-010 en ZTC-011 uitzetten (daar hebben we een instelling voor gemaakt), dan voldoet het verder nog aan alle andere business rules, ook volgens het Postman referentie-testproject. Wij zien hier ook functioneel geen negatieve gevolgen aan. Wel positieve, omdat dit het mogelijk maakt om de ZTC op te bouwen conform de geest van het het informatiemodel. Belangrijk daarvoor is dan wel dat ZTC-012 gehandhaafd blijft. Er zijn overigens ook heel andere routes om ditzelfde probleem op te lossen. De oplossingen besproken voor ZT-ZT relaties in item 1851 zouden dit probleem ook voor de ZT-IOT en ZT-BT relaties kunnen oplossen. Dus ofwel relaties leggen op een versie-onafhankelijke code i.p.v. URI ofwel het objecttype-objecttypeversie datamodel adopteren, zoals voorgesteld door @MarcoKlerks in dat issue. Dat laatste is uiteraard wel een nog veel ingrijpendere aanpassing. |
|
Ik ben nu bezig met dit puzzeltje en wil dit graag bij de eerstkomende bijeenkomst van de technische gebruikersgroep (uitnodiging volgt) bespreken. Ook kijkende naar #1656 en #1851 neig ik er naar om de relaties tussen typen met een identificatie te leggen in plaats van een absolute url naar een specifieke versie van een type. Dit maakt het wel noodzakelijk dat er logica geimplementeerd wordt om de correcte versie (tijdvakgeldigheid) van een type op te halen maar heeft als voordeel dat bij een wijziging van een type niet bij wijze van spreken de hele catalogus opnieuw hoeft te worden gedefinieerd. Het maakt het ook een stuk eenvoudiger om bijvoorbeeld een nieuwe versie van een zaaktype te maken en die naar ongewijzigde versies van besluittype, informatieobjecttype etc. te laten verwijzen. Het enige echte nadeel is: Dit is volgens mij een breaking change ten opzichte van het verwijzen met urls. Dat zou betekenen dat er een niuewe major versie, Catalogi API 2.0, uitgebracht moet worden. Hoewel ik dat liever zo min mogelijk doe zou ik een verbetering die heel veel praktische problemen oplost het liefst zo snel mogelijk uitbrengen om onnodig werk aan het implementeren van Catalogi API versie 1.x te voorkomen. Mocht ik me vergissen en is het verwijzen via een identificatie ipv een url wel backwards compatible dan kan dit natuurlijk in de volgende minor versie, Catalogi API 1.2, opgelost worden. |
|
Hallo Michiel, fijn dat dit wordt opgepakt! |
|
Omdat ik toch goed wilde begrijpen waarom de Catalogi API zo anders werkt als voor ogen is in het ImZTC en wat ook naar voren komt in dit issue ben ik nog maar eens dingen op een rijtje gaan zetten. Ook ter voorbereiding voor de technische gebruikersgroep. Het zou mooi zijn wanneer in ieder geval @ArjanKloosterboer , @hdksi, @Hugo-ter-Doest , @MNIJ en @johannesbattjes dit eens goed door willen lezen en eventuele denkfouten er uit willen halen. Maar iedereen is welkom te reageren, laat dit svp. duidelijk zijn. Achterliggende reden waarom het probleem optreedt is het volgende: Daarmee is het noodzakelijk om bij een nieuwe versie van een zaaktype ook nieuwe versies van alle gerelateerde objecttypen te maken. Uitzonderingen zijn Besluittypen en Informatieobjecttypen. Deze kennen wel een begin-/eind geldigheid. Door het Zaaktype-Informatieobjecttype is het mogelijk bestaande Informatieobjecttypen concept=false te koppelen aan nieuwe Zaaktypen, voor Besluittypen geldt dit echter niet omdat die relatie rechtstreeks wordt gelegd. Er zijn verschillende manieren om dit probleem op te lossen.
Voor die laatste wijze is het volgende nodig:
Hierdoor is het mogelijk om:
Bijvoorbeeld:
Documenten:
Tot slot een aantal scenario’s waar de API niet aansluit bij hoe de huidige Zaaktype Catalogi in de praktijk gebruikt worden.
Alles nieuw aanmaken geeft weinig problemen. De volgende situaties worden lastig bij het maken van een nieuwe versie van een bestaand Zaaktype: Andersom, wanneer van een Zaaktype wat als hoofdzaak ingericht is is het niet meer mogelijk om een bestaand Zaaktype wat niet veranderd is als Deelzaaktype te relateren. (ztc-010) De volgende resources leggen zelf een relatie naar Zaaktype:
Wanneer deze resources gerelateerd zijn aan een type met concept=false dan mogen deze niet bijgewerkt worden (inclusief de relatie naar Zaaktype) (ztc-010) Met de huidige regels moet echter voor een nieuwe versie van een zaaktype (=nieuwe resource Zaaktype) ook van de gerelateerde objecttypen een nieuwe versie aangemaakt worden terwijl dit misschien helemaal niet noodzakelijk is omdat daar geen veranderingen in zijn. Ook is het niet toegestaan om een compleet nieuw zaaktype te relateren aan Besluittypen die al aan een ander, in gebruik zijnd, zaaktype gerelateerd zijn.
De volgende resources leggen zelf een relatie naar IOT: De volgende resources leggen zelf een relatie naar IOT via create Zaaktype-Informatieobjecttype:
Dit mag via create Zaaktype-Informatieobjecttype , ook wanneer deze objecttypen zelf al gerelateerd zijn aan een Zaaktype met concept=false (ztc-010)
De volgende resources leggen zelf een relatie naar IOT via create Zaaktype-Informatieobjecttype:
=> create/update Eigenschap Deze operaties mogen alleen relateren naar een Zaaktype concept=true of een Zaaktype-Informatieobjecttype waarvan tenminste of het Zaaktype of het IOT concept=true is. (ztc-11) |
|
Het lukt me niet hier nu uitgebreid naar te kijken en dit is eigenlijk een zijstapje bij dit issue, maar dit
is volgens mij geen shortcut maar een correcte interpretatie van het ImZTC aangeeft. Namelijk dat objecten gerelateerd aan zaaktypen (behalve besluittypen in informatieobjecttypen):
Ergo: begin en einde geldigheid van gerelateerde objecten vallen altijd samen met begin en einde geldigheid van een zaaktype(versie). Vastleggen van deze datums bij zowel het zaaktype als gerelateerde resources in de Catalogi API zou dus (behalve voor besluittypen en informatieobjecttypen - die inderdaad eigen attributen voor begin en einde geldigheid kennen) redundant zijn. Let op: hiermee zeg ik niet dat de harde koppeling tussen (één) zaaktype en gerelateerde objecten in stand moet blijven. Als daar behoefte aan is valt absoluut te overwegen het informatiemodel en de Catalogi API-standaard aan te passen. Echter zie ik de aanleiding daartoe niet meteen in deze user story die immers ging om besluittypen en informatieobjecttypen. Edit, toevoeging naar aanleiding van de suggestie van @mnji:
De laatste twee gedragsregels dwingen ook af dat je bijvoorbeeld geen nieuw resultaattype (zonder conceptstatus) aan een bestaand, gepubliceerd zaaktype (concept=false) hangt - iets wat ZTC-012 niet kan voorkomen, maar in het ImZTC niet is toegestaan. Ik vraag me af of je die beperking niet wél in stand wil houden gezien de moeite die er op andere plekken is gestopt in het onmogelijk maken van mutaties op het zaaktype zonder dat daarbij een nieuwe versie ontstaat. Maar dit is misschien een vraag voor de verantwoordingsspecialisten onder ons. Edit: ik was in de (verkeerde) veronderstelling dat alle resources in de Catalogi API een concept-flag hadden. Nu dat alleen geldt voor Informatieobjecttypen en Besluittypen gaat het bovenstaande niet op... |
|
@hdksi Waar het mis gaat is dat de resource Zaaktype een versie van een Zaaktype is en niet hetzelfde als een Zaaktype zoals beschreven in het ImZTC.
Dit klopt volgens mij niet helemaal., tenminste niet voor alle gerelateerde objecten. |
Het informatiemodel ImZTC maakt het mogelijk om met functionele koppeling te werken. De userstory gaat over de regels ZTC-010 en ZTC-011 die gevolgen hebben voor het onderhoud van objecttypen en relaties. Dat gaat verder dan alleen informatieobjecttypen en besluittypen. Regel ZTC-010 is ook een beetje krom in de zin dat zoals het er nu staat mogelijk lijkt een relatie tussen een zaak die reeds gepubliceerd is (concept=false) en een Informatieobjecttype wat nog niet gepubliceerd is (concept=true). Tenminste, dit zou kunnen wanneer je de tekst letterlijk neemt: "Voor ZaakType-InformatieObjectType gelden bovenstaande regels (ztc-010) alleen in het geval waarbij zowel het ZaakType als het InformatieObjectType concept=False hebben" Maar een dergelijke relatie mag volgens mij helemaal niet gelegd worden, het zaaktype is immers in gebruik en dan mag je het niet zomaar veranderen. Of ik moet het verkeerd begrijpen maar dan is de tekst niet duidelijk genoeg. |
Ah, ik dacht juist dat dit een bewuste keuze was, om het mogelijk te maken om een nieuw IOT aan bestaand ZT te kunnen koppelen. Dan maak je het nieuwe IOT als concept aan, koppelt het aan alle bestaande ZTen waar het relevant voor is en publiceert vervolgens het IOT. Bijvoorbeeld: gemeente wil zienswijzen als Instagram Videos mogelijk maken, creeert nieuw IOT "Instagram Zienswijze" en koppelt het aan alle bestaande zaaktypen waar zienswijzen van belang zijn. Dat scenario wordt in ieder geval mogelijk door die formulering van de business rule. Of dit ook een wenselijk/noodzakelijk scenario is, is een tweede. Mocht dit scenario sneuvelen, is het immers altijd nog mogelijk om nieuwe versies van die ZTen aan te maken. |
|
Dat het scenario mogelijk zie ik maar volgens mij is dat juist niet wenselijk: Je verandert immers "iets" aan het zaaktype zonder een nieuwe versie van dat zaaktype te maken. En dat mag niet. |
Dat dacht ik ook. Maar mogelijk kan @ArjanKloosterboer hier meer zekerheid over geven.
Volgens het ImZTC is dit inderdaad niet toegestaan: een nieuwe relatiesoort ZAAKTYPE heeft gerelateerd ZAAKTYPE (of ZAAKTYPE is deelzaaktype van ZAAKTYPE) ontstaat of eindigt "alleen op een datum die gelijk is resp. een dag ligt voor een (en dezelfde) Versiedatum van het zaaktype en het gerelateerd zaaktype." Toevoeging: reactie op eerdere bijdrage van @mnji:
Is het probleem verholpen als we eenzelfde uitzondering voor Zaaktype-Besluittypen zouden toevoegen?
Bij ZTC-011 zie ik - analoog aan ZTC-010 - een uitzondering voor relaties tussen Zaak- en Informatieobjecttypen: "Voor ZaakType-InformatieObjectType gelden bovenstaande regels (ztc-011) alleen in het geval waarbij zowel het ZaakType als het InformatieObjectType concept=False hebben". Op basis van deze uitzondering triggert het relateren van een bestaand, gepubliceerd Informatieobjecttype (concept=false) aan een concept-Zaaktype (concept=true) deze regel niet. Ook hier is te overwegen de bestaande uitzondering uit te breiden naar Besluittypen. |
Voorstel 2. is een heel goede oplossing voor dit probleem. Maar het is volgens mij niet nodig om dit zo generiek voor alle objecttypen te doen. Er is qua datamodellering een groot verschil tussen objecttypen die een 1 op 1 relatie hebben met een zaaktype en objecttypen die op zichzelf staan en gerelateerd kunnen zijn aan meerdere zaaktypen. Die eerste categorie bevat objecctypen zoals roltype, statustype e.d. Dit zijn geen op opzichzelfstaande objecten, ze hebben alleen bestaansrecht in combinatie met een zaaktype en zijn in het datamodel gerelateerd aan één zaaktype. Het is dan prima om ze ook direct te koppelen aan één specifieke versie van dat zaaktype, precies zoals de huidige standaard dat doet. Als er een nieuwe versie van het zaaktype moet komen, kunnen al deze gerelateerde objecten gewoon gekopieerd worden en dit heeft geen impact op de rest van de ZTC. Dus voor deze objecttypen introduceert de oplossing alleen maar extra complexiteit zonder dat het een probleem oplost. Deze oplossing is wel heel goed voor die tweede categorie van objecttypen, die op zichzelf staan en relaties kunnen hebben met meerdere zaaktypen. Daarin vallen de zaaktypen zelf, besluittypen en informatieobjecttypen en het gaat dus om de volgende relaties:
Voor de ZT - ZT relaties is een heel vergelijkbare oplossing al voorgesteld in #1851 en het is een goed idee om het op dezelfde manier voor al deze relaties te doen. Zaaktypen kennen al een identificatie attribuut waarop de relatie gelegd kan worden, zo'n attribuut zou dan moeten worden toegevoegd aan BT en IOT. Alle drie deze objecttypen hebben al begin- en eindegeldigheid attributen. Het identificatie attribuut zou dan wel verplicht moeten worden (is het nu niet bij Zaaktype). Ik begrijp nog niet helemaal wat je bedoelt met "Relaties worden gelegd op basis van de identificatie in combinatie met tijdvakgeldigheid." De kern van het probleem en deze oplossing is juist dat je niet van tevoren weet wanneer er een aanpassing nodig gaat zijn aan een gerelateerd objecttype en dus de relaties tussen deze objecttypen tijd- en versie onafhankelijk moet zijn. Uiteraard speelt de begin/einde geldigheid wel een rol bij het aanmaken van instanties van een objecttype. (als je een ZAAK aanmaakt, moet dat zijn van de op moment geldige versie van het ZAAKTYPE en net zo voor BESLUIT en INFORMATIEOBJECT) |
@hdksi dat zou het probleem voor de ZT - BT relatie verminderen, maar niet oplossen. Mocht er dan een nieuwe versie van het BT komen, is het nog steeds noodzakelijk om ook alle ZTen die dat BT gebruiken aan te passen. En bovendien is hierboven al geconstateerd dat juist deze uitzondering potentieel een ongewenst bij-effect heeft. De oplossing om de relaties op een versie-onafhankelijke identificatie te leggen is veel robuuster en zuiverder. |
|
Als ontwikkelaar van de ZGW API-specificaties en "interprator" van het ImZTC wil ik hier wel even op reageren. Voor de lezers zal ik ook even verwijzen naar de exacte tekst uit de specificatie: https://vng-realisatie.github.io/gemma-zaken/standaard/catalogi/index#ztc-010 Michiel verwoordt het basisprincipe correct:
Hier zou ik ook niet aan willen tornen. Een versie was inderdaad heilig maar ik zie wel de problematiek. Het gaat vooral om "de waarheid" en die moet niet ongemerkt aangepast kunnen worden. Idee Doordat we niet meer alle gegevens kopieren van zaaktype naar zaak, moet de waarheid bij de bron dus bewaakt worden. Een IOT / BT toevoegen aan een ZT zonder een nieuwe versie van dat ZT op te voeren is daarmee onwenselijk omdat de geldigheidsdatum alleen ligt bij het ZT (en BT en IOT) en niet ook op de relatie tussen ZT en BT / IOT. Als de begin/eind datum op de relatie wordt vastgelegd, heb ik er ook minder problemen mee dat de relatie wordt gelegd met gepubliceerde typen. Je kan immers achterhalen sinds wanneer een nieuw BT/IOT beschikbaar is gekomen voor een bepaald ZT. Je bent dan niet de waarheid kwijt. Ik pleit dan wel voor de relatieklasse (zei ik dat nou echt?) Als we dichter bij het huidige model willen blijven Als het probleem is dat een gepubliceerd informatieobjecttype niet kan worden gerelateerd aan een concept zaaktype, dan is dat wel een probleem dat opgelost moet worden. Het lijkt me dat ZTC-10 en ZTC-11 aangepast moeten worden om dit mogelijk te maken, door expliciet te spreken over de hoofd-resources (ZT, IOT, BT, zeg maar de many-to-many's) en geneste resources (Statustype, Eigenschap, Resultaattype, de many-to-one's). Voor een gepubliceerd ZT blijft echter gelden dat je hier geen nieuwe IOT en BT relaties naar mag leggen. Omgekeerd vind ik dit minder interessant maar dat maakt het ook minder consistent. PS. Ik zou zelf nog even wegblijven van de versie-onafhankelijke identificatie. |
|
Voor de goede orde, de insteek van dit issue was niet om het mogelijk te maken om nieuwe IOT of BT relaties te leggen naar een gepubliceerd ZT. Dat kan nu voor IOTs wel, maar dat is een (blijkbaar onbedoeld) bij-effect van de uitzondering geformuleerd in ZTC-011. Geen enkel probleem als die mogelijkheid in een nieuwe versie wordt afgesneden. Sterker nog wij ondersteunen dit momenteel sowieso al niet via de UI van onze ZTC beheertool. De insteek van dit issue is dat het mogelijk moet worden om aan een Concept ZT relaties toe te voegen naar al gepubliceerde BT en IOT. En dat het mogelijk moet zijn om een Concept ZT nog aan te passen als deze relaties heeft naar al gepubliceerde BT, IOT en/of andere ZT. Dat is namelijk een daadwerkelijke blokkade voor beheer van de ZTC. Dat kan gerealiseerd worden met het herschrijven of schrappen van business rules ZTC-010 en ZTC-011 en dat heeft natuurlijk veel minder impact dan de relaties versie-onafhankelijk leggen, ook al vind ik dat persoonlijk wel een robuustere oplossing. Voor de ZT - ZT relaties is het niet zo eenvoudig op te lossen volgens mij. Maar daar is inderdaad ticket #1851 voor. Edit ter aanvulling: de problemen beschreven in #1851 bestaan nog steeds ook voor BT en IOT als ZTC-010 en ZTC-011 worden aangepast. Stel, een BT wordt gebruikt in vijf zaaktypen en nu moet er iets aangepast worden in dat BT. Dan moet je een nieuwe versie van dat BT maken, maar dus ook nieuwe versies van die vijf ZTs. Maar mijn inschatting is dat dat in de praktijk een minder groot probleem is dan bij ZT - ZT relaties, omdat mijn aanname is dat wijzigingen aan BTs of IOTs veel zeldzamer zijn dan aan ZTs. Maar dat kan ook een foute aanname zijn. |
|
@michielverhoef vroeg me te reageren. Nu dan. Ik heb alle bijdragen gelezen en pogen te begrijpen. Al met al kan ik me niet aan de indruk onttrekken dat het ImZTC niet in de API geimplementeerd is zoals het bedoeld is. Wat m.i. tot de genoemde problemen leidt. |
|
Hieronder wordt per geval gekeken hoe het leggen van een relatie tussen objecttypen gedaan moet worden. Vuistregel is dat wanneer versie van een objecttype aan meer dan één versie van een ander objecttype gerelateerd kan worden dit gebeurt via een identificatie. Op basis van de begin-/einddatum wordt dan gekeken welke versie van het gerelateerde objecttype van toepassing is. NB. Dit is een voorstel, nog geen besluit hoe relaties te leggen! Voor het gebruik van zaaktypen vanuit een consumer applicatie kunnen zowel de identificatie als de url gebruikt worden. Bijvoorbeeld het aanmaken van een zaak, dat gebeurt met een identificatie. Deze hoeft dan niet te veranderen wanneer een nieuwe versie van dat zaaktype gemaakt wordt. Een aangemaakte zaak kan middels de url verwijzen naar de exacte versie van het zaaktype. Dit maakt terugzoeken weer veel eenvoudiger. Eenzelfde methode kan gebruikt worden voor het maken van Informatieobjecten of Besluiten. Vragen die gesteld kunnen worden:
Zaaktype concept=true -> gerelateerdZaaktype concept=true/falseGelegd via identificatie. Het gerelateerde Zaaktype kan veranderen zonder dat dat van invloed is op dit Zaaktype. Is de relatie niet meer van toepassing wordt in een nieuwe versie van het Zaaktype de relatie verwijderd. Zaaktype concept=true -> is Deelzaaktype van Zaaktype concept=true/falseGelegd via identificatie. Het gerelateerde hoofdzaak Zaaktype kan veranderen zonder dat dat van invloed is op dit deelzaak Zaaktype. Is de relatie niet meer van toepassing wordt in een nieuwe versie van het deelzaak Zaaktype de relatie verwijderd. Zaaktype concept=true -> Besluittype concept=true/falseGelegd via URL. Wanneer iets aan een Besluittype verandert verandert ook het Zaaktype en komt daar een nieuwe versie van. Zaaktype concept=true -> Zaaktype-Informatieobjecttype -> Informatieobjecttype concept=true/falseZaaktype-Informatieobjecttype is een relatieklasse. Relaties via identificatie. Een Informatieobjecttype kan voor meerdere versies van een Zaaktype van toepassing zijn. Een nieuwe versie van een Informatieobjecttype kan leiden tot een nieuwe versie van een Zaaktype maar dat hoeft niet. Is een Informatieobjecttype niet meer van toepassing voor een Zaaktype wordt de relatieklasse beëindigd. Roltype -> Zaaktype concept=trueRelaties via identificatie. Een Roltype kan voor meerdere versies van een Zaaktype van toepassing zijn. Een nieuwe versie van een Roltype kan leiden tot een nieuwe versie van een Zaaktype maar dat hoeft niet. Leggen van een relatie Roltype naar Zaaktype mag alleen indien Zaaktype concept=true. Statustype -> Zaaktype concept=trueRelaties via identificatie. Een versie van een Statustype kan voor meerdere versies van een Zaaktype van toepassing zijn. Een nieuwe versie van een Statustype leidt tot een nieuwe versie van een Zaaktype. Leggen van een relatie Statustype naar Zaaktype mag alleen indien Zaaktype concept=true. Statustype -> Zaaktype-Informatieobjecttype -> Informatieobjecttype concept=true/false , Zaaktype concept=trueRelaties via url. Een versie van een Statustype kan voor meerdere versies van een Zaaktype van toepassing zijn. Een nieuwe versie van een Statustype leidt tot een nieuwe versie van een Zaaktype, een Zaaktype-Informatieobjecttype kan aan meerdere versies van een Zaaktype gekoppeld zijn. Eigenschap -> Zaaktype concept=trueGelegd via URL. Eigenschap is een per zaaktype definieerbaar attribuut van dat zaaktype dus moet bij een nieuwe versie van een zaaktype ook de eigenschap opnieuw aangemaakt worden. Zaakobjecttype -> Zaaktype concept=trueGelegd via identificatie. Voorbeeld: Een zaakobjecttype “ligplaats” is een verwijzing naar RSGB object wat van belang is bij een Zaaktype voor de aanvraag van een ligplaats voor een boot. Dat verandert niet wanneer een nieuwe versie van het zaaktype gemaakt wordt. Op het moment dat er een andere versie van een zaakobjecttype van toepassing is, is er ook sprake van een nieuwe versie van een zaaktype. Resultaattype -> Zaaktype concept=trueGelegd via identificatie. Hetzelfde Resultaattype kan van toepassing zijn voor meerdere versies van een Zaaktype. Dat verandert niet wanneer een nieuwe versie van het zaaktype gemaakt wordt. Op het moment dat er een andere versie van een resultaattype van toepassing is, is er ook sprake van een nieuwe versie van het gerelateerde zaaktype. Resultaattype -> Zaaktype-Informatieobjecttype -> Informatieobjecttype concept=true/false, Zaaktype concept=trueRelaties via url. Een versie van een Resultaattype kan voor meerdere versies van een Zaaktype van toepassing zijn. Een nieuwe versie van een Resultaattype leidt tot een nieuwe versie van een Zaaktype, een Zaaktype-Informatieobjecttype kan aan meerdere versies van een Zaaktype gekoppeld zijn. |
|
Vast even een korte reactie, in afwachting van de meeting over o.a. dit onderwerp later vandaag. Met een groot deel van bovenstaand voorstel van @michielverhoef ben ik het eens, bij een aantal dingen heb ik nog vraagtekens. Maar om te zorgen dat alle relevante relaties gedekt zijn, wil ik in ieder geval even noemen:
|
|
Om op het laatste in te gaan: Dat gaat over de relatie https://www.gemmaonline.nl/index.php/Imztc_2.2/doc/relatiesoort/resultaattype.heeft_verplichte_zaak-informatieobject-type |
Ah, een relatie die nog niet bestaat in de ZGW ZTC 1.1 dus. |
|
Klopt, deze relatie moet nog toegevoegd worden in 1.2.0. Dit hoort bij #1876 |
|
TODO: uitwerking beperkt historiemodel toevoegen @michielverhoef |
|
Aanpassing van ZTC-11 is beschreven in #2209 |
…1838 Implementatie historiemodel Catalogi API #1838
Volgens business rules ZTC-010 en ZTC-011 is het volgende niet mogelijk:
• Een gepubliceerd Besluittype relateren aan een concept Zaaktype;
• Een concept Zaaktype bewerken als er een relatie is met een gepubliceerd Besluittype of gepubliceerd Informatieobjecttype.
Waarom is dit een groot probleem?
Als we in onze ZTC-beheertool een nieuwe versie van een zaaktype willen maken, willen we het oude Zaaktype kopiëren inclusief relaties naar (reeds gepubliceerde) besluittypes en informatieobjecttypes. Maar door ZTC-011 kunnen de bestaande besluittypen niet aan het nieuwe concept zaaktype gekoppeld worden. En door ZTC-010 kan dit nieuwe concept-Zaaktype niet meer bewerkt worden. Een nieuwe versie kan dus niet gemaakt worden.
Hetzelfde probleem speelt ook als je een geheel nieuw zaaktype zou willen maken op basis van gepubliceerde besluittypes en informatieobjecttypes.
Het is (volgens het informatiemodel) wel de bedoeling dat een Besluittype en Informatieobjecttype aan meerdere zaaktypes gerelateerd kunnen zijn. Maar de business rules ZTC-010 en ZTC-011 maken het vrijwel onmogelijk dat in de ZTC-beheertool te realiseren. Bij Informatieobjecttypes is het in theorie mogelijk reeds gepubliceerde informatieobjecttypes op het allerlaatst toe te voegen vlak voor het publiceren van het zaaktype, maar dat is onwerkbaar. Bij besluittypes is dit in het geheel niet mogelijk.
Voorstel: verwijder ZTC-010 en ZTC-011 uit de standaard.
The text was updated successfully, but these errors were encountered: