Verzoekregistratiecomponent
Opdracht aan PO-groep tot samenstellen werkgroep en terugkoppelen reactie
Auteur: Joeri Diederen | Status: Review
Inleiding
Er is een groeiende behoefte aan een centrale API voor verzoekdefinities INCLUSIEF een register voor geregistreerde verzoeken.
Analysevraag werkgroep
Werk onderstaande onderzoeksvraag uit, met inachtneming van best practices van;
Open Zaak, overige objecten, waar de lesson learned is dat data over instanties in dezelfde API als de definities horen.
Gedeelde datasets en Domeinregistratie waarin governance besproken wordt over wijzigingen op een informatiemodel.
Vragen;
Vorm een beargumenteerde zienswijze over de scope van deze registratie:
Wordt dit een component voor alleen initiële verzoeken
Wordt dit losstaand component voor alle typen verzoeken, zoals
'Aanvraag’verzoeken
productverzoeken (verlenging, etc),
zaakverzoeken (intrekking, etc)
Een toevoeging op het informatiemodel van bestaande componenten, zoals Open Zaak, Open Klant, Open Product etc
Onderdeel van een breder nog te realiseren component, zoals een Verzoeken, Taken, Berichten-component?
Achtergrond
Wanneer een component een verzoek verwerkt, wordt dit geregistreerd als een verzoekobject. Denk aan een formuliercomponent, een scanapplicatie of een chatbot. Om te bepalen welke data nodig is om het verzoek uiteindelijk te kunnen leveren, wordt het verzoekobjecttype gebruikt. Dit verzoektype heeft twee functies:
Definiëren van eigenschappen: Het bepaalt de eigenschappen van een verzoekobject. Andere componenten kunnen deze eigenschappen lezen en zo proberen het verzoekobject zo volledig mogelijk aan te maken, zodat de behandeling zo effectief mogelijk kan plaatsvinden. Voorbeeld: voor een verhuisverzoek is een adres nodig.
Validatie van het object: Het controleert of het object dat wordt opgeslagen vanuit het component dat het verzoek registreert, voldoet aan de gestelde eisen. Als dat niet zo is, wordt het object afgekeurd. Dit is belangrijk om te garanderen dat het achterliggende systeem de informatie op dezelfde manier ontvangt als deze verwerkt wordt—een soort 'contract' met afspraken. Voorbeeld: de postcode voor een verhuisverzoek moet volgens een bepaald formaat zijn.
Een verzoektype (gerelateerd aan producttype) bevat gegevens die nodig zijn om een verzoek te verwerken. Sommige van deze gegevens zijn specifiek voor een bepaald type verzoek, zoals het adres bij een verhuizing. Deze specifieke gegevens blijven per organisatie en per verzoek te definiëren.
Daarnaast zijn er gegevens die voor alle verzoeken van toepassing zijn, zoals:
Informatie over de initiator van het verzoek.
Standaardmetadata van het verzoek, zoals datum, tijd en kanaal.
Registratie van betalingen die hebben plaatsgevonden.
Locatiegegevens van een verzoek.
De manier waarop bijlagen worden geregistreerd.
Deze notitie richt zich op het standaardiseren van deze algemene gegevens.
Probleemstelling
Niet ophalen bij de bron: Deze standaardgegevens worden momenteel per verzoekobjecttype gekopieerd. Volgens het Common Ground-principe halen we deze liever op bij de bron.
Slecht beheersbaar: Door het vele kopiëren zijn deze gegevens slecht beheersbaar. Als er bijvoorbeeld een authenticatiemethode zoals machtigen wordt toegevoegd, moeten alle verzoekobjecttypen handmatig van de juiste definitie worden voorzien.
Per applicatie anders: Idealiter conformeert het afnemende systeem zich aan de standaard. Maar omdat er geen standaard is, bepaalt het afnemende systeem de standaard. Dat zorgt voor afwijkende verzoekobjecttypes per applicatie.
Per organisatie anders: De gegevens die worden vastgelegd verschillen ook per organisatie. Daardoor is het voor leveranciers van niet-Common Ground-applicaties verwarrend om aan te sluiten op dit landschap.
Oplossingsrichting
Het voorstel is om opdracht te verstrekken voor de realisatie van een verzoeken-API, waardoor standaardelementen landelijk gestandaardiseerd worden.Deze API biedt de mogelijkheid om aanvullende schema's (typen) te definiëren voor lokale aanvraaggegevens, maar zorgt primair voor standaardisatie van de generieke set.
Standaard met maatwerk
Een belangrijk onderdeel van deze oplossing is het gebruik van een standaard API die ruimte laat voor zelf te definiëren JSON-schema's. De JSON-schema's hebben betrekking op een element in de API met de naam 'verzoekgegevens'. De schema's kunnen alleen aspecten binnen dat element definiëren.
Organisaties kunnen daardoor specifieke velden en structuren definiëren die relevant zijn voor hun unieke processen, zonder afbreuk te doen aan de algemene standaardisatie.[JD8]
Scope en eisen
De opdracht omvat het ontwikkelen van een verzoeken-API en mogelijk een verzoekregistratiecomponent, alsmede de documentatie die leveranciers nodig hebben om op deze API aan te sluiten. I
Technische eisen
Het verzoekregistratiecomponent wordt opgezet volgens de blauwdruk van het bestaande zaakregistratiecomponent, zodat het naadloos integreert met de bestaande infrastructuur en aansluit bij de Common Ground-principes. Dit betekent integratie met generieke voorzieningen zoals autorisatie, logging, auditing, notificaties en archivering. Op basis van ervaringen met Open Zaak wordt gestreefd naar het samenvoegen van API's voor definities en instanties.
Beheer
De API wordt voorlopig beheerd door de Common Ground-beweging en na vaststelling overgedragen aan de VNG voor beheer. Versiecontrole is een complex vraagstuk waarvoor we een voorstel zullen doen. Het is belangrijk om zowel de standaard API als de zelf gedefinieerde schema's binnen het 'verzoekgegevens'-element goed te versioneren.
Last updated