VTB component (Concept)

Auteur: Rutger Haagsma | Status: CONCEPT

Inleiding

Binnen de architectuur van het Platform Generieke Dienstverlening wordt gebruik gemaakt van het mechanisme ‘informatie-arm notificeren’. Berichten tussen componenten kunnen a-synchroon worden verstuurd. Dit houdt in dat er geen direct verbinding is tussen componenten op laag 4. Berichten vanuit een versturend component worden op laag 1 wordt geplaatst, waarna een ontvangend component wordt geïnformeerd dat er een bericht klaarstaat. Daarmee is een ontkoppeling gerealiseerd tussen componenten op laag 4. Dit draagt bij aan vervangbaarheid van componenten, stabiliteit en schaalbaarheid.

Tot op heden wordt dit gedaan voor patronen voor Verzoeken, Taken en Berichten – waarbij er weer subtypes kunnen bestaan, zoals ‘betaaltaak’.

Het platform generieke dienstverlening is van start gedaan met het plaatsen van deze berichten in de https://vng.nl/projecten/overige-objecten-registratie-api. Dit component is flexibel, maar niet gebouwd voor dit doel. Nu het gebruik groeit worden de beperkingen gevoeld. Denk aan:

  • Rechten. Elk component kan elk bericht inzien, en besluit pas na het lezen van het bericht of het verwerkt moet worden. Bij beperkte toepassing is dat prima, maar bij het grootschaliger gebruik is het niet wenselijk dat elk component elk bericht kan inzien. (denk doelbinding en gevoelige gegevens)

  • Verkeer. Er loopt onnodig verkeer over de API’s. Bij grootschalig gebruik gaat dat wellicht wel een punt van aandacht zijn.

  • Het afdwingen van kwaliteit. De JSON schema's dwingen af dat bepaalde informatie wordt meegestuurd, maar er is geen geen logica toe te passen. Bijvoorbeeld: afdwingen dat een taaknummer uniek is.

Standaard

CloudEvents is een standaard voor het uitwisselen van gebeurtenisgegevens in cloud-native omgevingen. Het doel van CloudEvents is om een gestandaardiseerd formaat te bieden voor het beschrijven van gebeurtenisgegevens, zodat verschillende systemen deze kunnen verwerken zonder dat specifieke aanpassingen nodig zijn. Hierdoor wordt interoperabiliteit tussen cloudgebaseerde applicaties en services vergemakkelijkt. https://cloudevents.io/

Het CloudEvents-formaat is flexibel genoeg om zowel informatiearm als informatierijk te notificeren.

Informatie-arme notificatie houdt in dat een event of gebeurtenis slechts minimale informatie bevat die voornamelijk aangeeft dat er iets is gebeurd, zonder dat gedetailleerde gegevens worden meegestuurd. Dit kan handig zijn in situaties waarin het versturen van alleen een "trigger" voldoende is, en de ontvanger zelf meer details kan ophalen wanneer dat nodig is.

In CloudEvents kun je de data-sectie, die bedoeld is voor gedetailleerde gebeurtenisgegevens, leeg laten of minimaliseren. In plaats daarvan kun je alleen de verplichte attributen gebruiken, zoals:

  1. ID: Een unieke identifier voor de gebeurtenis.

  2. Source: De bron van de gebeurtenis.

  3. Type: Het type gebeurtenis (bijv. "item.gecreëerd" of "status.gewijzigd").

  4. SpecVersion: De versie van de CloudEvents-specificatie.

Landelijke ontwikkeling NL Gov voor CloudEvents

Gebaseerd op deze standaard is een profiel gemaakt voor Nederlandse overheidspartijen. Het Nederlands profiel en de standaard krijgen een plek in het Federatief Datastelsel. Het wordt beheerd door Logius. https://www.logius.nl/actueel/publieke-consultatie-op-het-nlgov-profiel-op-cloudevents

Voorstel: vastleggen gebruik te maken van het NL Gov profiel op CloudEvents.

Verzoeken, taken en berichtencomponent

Zoals in de inleiding beschreven word de inhoudelijke informatie van verzoeken, berichten en taken nu opgeslagen in de objecten API. Voorstel is deze te vervangen door een VTB-compontent. Het VTB-component voorziet in de opslag, archivering, ontsluiting en toegangscontrole van de berichten. Dit omvat:

  • Verzoeken

    • Verzoek

    • Zaakverzoek

    • Producverzoek (?)

  • Berichten

  • Taken

    • Betaaltaken

    • Externe taken

Eisen

  • PBAC

  • Integratie met OpenNotificaties / onderdeel worden van ON (minder compontenten)

  • Handelingsgedreven API's

  • Snelheid < 50ms / call

  • Load tbd

  • Aansluiting op logging standaard / framework

  • Auditfunctionaliteit

Last updated