Verzoektype als contract
Auteur: Rutger Haagsma | Joeri Bekker Status: Definitief
Last updated
Auteur: Rutger Haagsma | Joeri Bekker Status: Definitief
Last updated
Via het “Verzoek” communiceren componenten in het ZGW landschap met elkaar, primair nu Formuliercomponenten met taak- en zaakafhandelcomponenten. In praktijk blijkt dat er in hoog tempo veranderingen worden doorgevoerd in formulieren, doordat ‘de business’ iteratief aanpassingen doorgevoerd wil zien in formulieren. Deze veranderingen hebben effect op de componenten verderop in de keten.
Concreet: een verandering van een veld in een formulier heef gevolgen voor mogelijk het zaakdetailobject en taakformulieren in een ZAC, achterliggende email templates en PDF templates. Dit heeft twee gevolgen:
de kosten van een verandering zijn mogelijk hoger dan ‘de business’ overziet;
de aanpassingen worden niet altijd afgestemd, waardoor fouten ontstaan in de keten, wat frustratie geeft bij gebruikers en beheerders.
De applicatie die een verzoek behandelt (bijv. GZAC) moet van te voren weten wat voor gegevens in een verzoek zitten. Dit betekent dat de applicatie die het verzoek aanmaakt (bijv. Open Formulieren) ook rekening moet houden met op welke manier de gegevens in dat verzoek terecht komen.
De structuur van de inhoudelijke gegevens moet dus vastliggen, als ware een contract.
Het hebben van een contract betekent dat geen van beide partijen (GZAC en Open Formulieren) dit contract eenzijdig zomaar kunnen wijzigen. Voor een formulier-beheerder, betekent dit ook dat het formulier niet zomaar aangepast mag worden. Immers, de gegevens uit een formulier vullen het verzoek. En voor dat verzoek is een contract.
Technisch moet dit contract vastgelegd worden als een Objecttype in de Objecttypen API. Op deze manier kunnen verzoeken, als Objecten in de Objecten API, worden vastgelegd volgens het geldende contract, ofwel het Objecttype.
Een contract is een overeenstemming tussen twee componenten. Het wordt met instemming van beide (beheerders van) componenten opgesteld, en kan niet eenzijdig worden gewijzigd.
Het contract is geversioneerd.
Zender en ontvanger hebben vrijheid in het aanpassen van hun interne processen - voor zolang ze zich maar houden aan het contract.
Het contract wordt vastgelegd en afgedwongen door het Object type.
Beschrijft het meest gunstige scenario.
Met de business wordt vastgesteld welke informatie nodig is voor een verzoek. Bijvoorbeeld: Een klacht bestaat uit de attributen omschrijving, naam en e-mailadres waarbij enkel omschrijving verplicht is.
Het verzoek wordt ingericht als Objecttype in de Objecttypen API. Het JSON-schema hiervan ziet er ongeveer zo uit:
In de afhandel-applicatie wordt dit Objecttype geselecteerd en ingeladen. Er wordt een “mapping” gemaakt op basis van de attributen Objecttype, naar velden in de applicatie. De afhandel-applicatie ontvangt bijvoorbeeld dit:
In de formulier-applicatie wordt dit Objecttype geselecteerd en ingeladen. De gegevens uit het formulier moeten dus voldoen aan deze attributen. Je kan dus enkel 3 velden in het formulier stoppen, wederom: omschrijving, naam en e-mailadres. Eventueel moet er een mapping komen van formulier-veld naar objecttype-attribuut.
Als een formulier-beheerder het formulier inhoudelijk wil wijzigen.
Maak een nieuwe versie van het Objecttype aan.
In de afhandel-applicatie: Selecteer de nieuwe versie van het Objecttype, en zorg dat er een mapping komt van attributen naar velden voor deze versie. De afhandel-applicatie kan nu 2 versies aan van dit Objecttype.
In de formulier-applicatie: Selecteer de nieuwe versie van het Objecttype, en zorg dat het formulier alle attributen van het Objecttype kan vullen. Na publicatie van het formulier zal versie 2 van het Objecttype worden gebruikt voor verzoeken.
Als een formulier net gebouwd wordt zal het waarschijnlijk nog vaak wijzigen. Ook als het proces nog niet helemaal is uitgekristalliseerd is het wenselijk om agile met de gegevens om te kunnen gaan. Het is daarom wenselijk dat er niet altijd een strict contract nodig is.
Zorg dat er een flexibel contract is door een Objecttype aan te maken waar je alles aan kan toevoegen. Ter illustratie:
In de afhandel-applicatie: Selecteer dit Objecttype als tijdelijke oplossing.
In de formulieren-applicatie: Selecteer dit Objecttype als tijdelijke oplossing.
Na het doen van een Verzoek kan het voorkomen dat er aanleiding (een ’event’) is voor de verzoeker om het Verzoek in te trekken of te wijzigen. Twee concrete voorbeeld:
Een klant/inwoner vraagt een gehandicaptenparkeervergunning aan, met een doorloooptijd van 8 weken. Na zes weken besluit de klant te verhuizen naar een andere gemeente, waardoor de noodzaak voor de aanvraag vervalt.
Een klant/organisatie vraagt een herziening aan voor het erfpachtrecht voor een uitbouw van een schoolgebouw. Enkele weken na de aanvraag blijkt dat er een fout in de tekeningen zit en er 50m2 uitbouw te weinig is aangevraagd. De klant wil de aanvraag aanpassen op basis van het nieuwe metrage.
Een Verzoek kan niet worden gewijzigd. De combinatie van de mogelijke aanpassingen in het Verzoek in combinatie met de status van de zaakafhandeling levert een groot aantal scenario’s op die ondersteund moeten worden - wat de beheersbaarheid complex maakt. Daarom wordt een verzoek tot wijziging apart ingediend. Dit is een ‘ZaakVerzoek’.
