Aanbevelingen Notificeren
Deze pagina is onderdeel van de Architectuur Notificeren in het Federatief Datastelsel. Het bevat een aantal aanbevelingen voor het op professionele wijze omgaan met notificaties. Het start met een samenvatting van de belangrijkste aanbevelingen uit de architectuur die eerder is opgesteld in het VNG project Notificatieservices. Vervolgens worden een aantal aanvullende aanbevelingen gedaan. Er is een separate pagina met richtlijnen voor het creëren van afleverbetrouwbaarheid met API's.
Aanbevelingen uit project Notitifcatieservicesbewerken
- Communiceer asynchroon tussen publisher en consumers om tijdonafhankelijk te functioneren. Bij notificeren hoeven niet alle betrokken applicaties gelijktijdig actief te zijn. Dit vereist een vorm van ‘bufferen’ waarbij de producer geen onmiddellijk antwoord nodig heeft.
- Gebruik het Publish-Subscribe patroon bij het ontwerpen van notificatieoplossingen. Dit is een bekend, bewezen en vaak toegepast patroon voor notificeren. Het is geschikt om gegevens over plaatsgevonden gebeurtenissen te delen tussen ontkoppelde publishers en een onbeperkt aantal (evt. bij publishers onbekende) consumers.
- Zorg dat de producer of intermediair het tempo waarin notificaties worden verstrekt kan aanpassen aan de mogelijkheden van consumers. Aanbiedende applicaties die in hoog tempo notificaties verstrekken mogen geen last hebben van afnemende applicaties die notificaties niet in dat tempo kunnen verwerken.
- Zorg dat wijzigingen van notificaties beheersbaar verlopen en consumers de gelegenheid hebben om ze te blijven verwerken. Notificeren moet blijven functioneren als de inhoud van notificaties in de loop der tijd wijzigt. Bijv. door tijdelijke meerdere versies van notificaties te verstrekken of door gebruik te maken van versionering van notificaties.
- Neem privacyaspecten vroegtijdig mee bij ontwerp van notificatieprocessen ('privacy by design'). Het is belangrijk om te voldoen aan privacywetgeving zoals de AVG. Dit vraagt in ieder geval dat vantevoren goed wordt nagedacht over grondslag en doelbinding van gegevens die worden uitgewisseld. Daarnaast is dataminimalisatie uitgangspunt.
- Versleutel binnen notificatieprocessen waar mogelijk het payload-gedeelte van berichten. Voor attributen binnen het payload-gedeelte van een bericht geldt dat ze zodanig versleuteld kunnen worden dat alleen consumers (en dus geen intermediaries) gegevens kunnen lezen. Het biedt extra garanties dat gegevens niet door onbevoegden worden ingezien. Dit is alleen relevant als er gevoelige gegevens worden uitgewisseld en transportversleuteling onvoldoende zekerheid biedt.
- Neem maatregelen op verschillende niveaus voor het borgen van privacy. Borgen van privacy bij notificeren vereist maatregelen op verschillende niveaus. Er moet worden gezorgd dat notificatieberichten niet meer informatie bevatten dan noodzakelijk en toegestaan is.
- Laat consumer-specifieke filtering uitvoeren door consumers. Soms is het niet mogelijk of wenselijk om alle wensen met betrekking tot ontvangst van notificaties via op te geven filtercriteria te realiseren. Het voorkomt het realiseren van complexe filtervoorzieningen voor een beperkt aantal consumers, voor situaties waarin alleen de consumers kunnen beslissen.
- Gebruik context-attributen voor content-filtering. Het op de CloudEvents-specificatie gebaseerde NL GOV profile for CloudEvents schrijft dit voor. Hierdoor wordt vergaande standaardisatie en verwerking door een veelheid aan intermediaries mogelijk. Payload-gegevens worden door een intermediary bij voorkeur beschouwd als een 'black box met gegevens‘ die moet worden overgebracht van Producer naar Consumers.
- Laat consumers waar nodig zelf objecten filteren om in overeenstemming met doelbinding notificaties te kunnen verstrekken. Producers kunnen niet altijd beoordelen of consumers recht hebben op bepaalde notificaties. Consumers kunnen daarom zelf aangeven voor welke objecten (bijv. personen) zij notificaties mogen en willen ontvangen. Bij deze vorm van ‘objectfiltering’ ligt de verantwoordelijkheid voor het in overeenstemming met doelbinding filteren en verstrekken van notificaties expliciet bij de afnemer. Controle hierop kan bijv. via periodieke audits worden gedaan.
- Filter waar nodig attributen om in overeenstemming met doelbinding notificaties te kunnen verstrekken. Dit is een manier om te zorgen dat consumers niet meer gegevens ontvangen dan waar ze recht op hebben. Bij het samenstellen van notificaties uit beschikbare attributen wordt dan rekening wordt gehouden met voor een specifieke afnemer(s) geldende autorisatieregels. Dit wordt bij voorkeur belegd bij producers omdat zij beschikken over de noodzakelijke domeinkennis.
- Gebruik de CloudEvents gegevensformaat-specificaties. Hiermee wordt verdergaande standaardisatie gerealiseerd waarmee de interoperabiliteit van oplossingen wordt vergroot.
- Gebruik JSON als gegevensformaat. JSON wordt steeds vaker toegepast voor gegevensuitwisseling, binnen en buiten de overheid.
Aanvullende aanbevelingenbewerken
Gebruik het Nederlands profiel op CloudEvents.
Er is inmiddels een Nederlands profiel op de CloudEvents standaard ontwikkeld. NL GOV profile for CloudEvents is een set Nederlandse afspraken over het gebruik van de internationale standaard CloudEvents. Deze standaard wordt beheerd door Logius. Het gebruik van dit profiel verhoogt de standaardisatie en daarmee de interoperabiliteit van de uitwisseling van notificaties.
Het Nederlands profiel standaardiseert ondermeer de eigenschappen die onderdeel uit zouden moeten maken van een notificatie. Dit betreft eigenschappen zoals een unieke identificatie, de bron, de versie van het profiel en het gebeurtenistype. Er is ook een handreiking bij de standaard vanuit Logius beschikbaar. Deze beschrijft dat er drie modes zijn om notificaties te versturen (gestructureerd, batched en binair) en standaardiseert hun eigenschappen. Het beschrijft verder op welke wijze gegevens in JSON zouden moeten worden opgenomen in notificaties. Het beschrijft ook een standaard werkwijze voor het gebruik van Web Hooks.
Publiceer gebeurtenistypes en aanbieders in een catalogus.
Vindbaarheid van gebeurtenistypes en aanbieders van gebeurtenissen is essentieel om notificaties te kunnen ontvangen en gebruiken. Gebeurtenistypes zijn vergelijkbaar met API's en we vinden het ook belangrijk dat hebruikbare API's vindbaar zijn in catalogi.
Catalogi kunnen zowel binnen organisaties of domeinen bestaan, naast landelijke catalogi. Voor elk datastelsel zou er een catalogus beschikbaar moeten zijn.
Voorkom waar mogelijk persoonsgegevens in notificaties.
Persoonsgegevens zijn gevoelig en compromittering ervan moet worden voorkomen. Voorkomen is beter dan genezen. Voor versleuteling en pseudonimisering zijn aanvullende maatregelen noodzakelijk, die niet triviaal zijn. Als notificaties naar meerdere consumers worden verstuurd door een intermediair kan standaard PKI versleuteling naar de consumer niet worden ingezet om persoonsgegevens inhoudelijk te versleutelen. Intermediairs kunnen namelijk standaard niet worden vertrouwd en het is dus onverstandig om persoonsgegevens onversleuteld bij een intermediair te verwerken.
Door gebruik te maken van informatiearme notificaties met daarin uitsluitend een betekenisloze identificatie van de gebeurtenis kunnen consumers vervolgens zelf op veilige wijze de bijbehorende gevoelige gegevens opvragen. Bij deze bevraging kunnen reguliere standaarden voor beveiliging worden gevolgd. Als er geen intermediair wordt gebruikt en de producer de consumers wel zelf kent, dan is het ook mogelijk om PKI toe te passen voor het versleutelen van gegevens per specifieke consumer.
Voorkom waar mogelijk afhankelijkheid van volgordelijkheid van notificaties.
Het is technisch ingewikkeld om te borgen dat notificaties die worden verzonden ook altijd exact in die volgorde worden verwerkt. Het omgaan met volgordelijkheid is ook primair een applicatieverantwoordelijkheid.
Bepaal dus situationeel of volgordelijkheid van berichten wel echt belangrijk is om af te dwingen. De consumer moet intelligent genoeg zijn om de verwerking goed te laten verlopen.
Borg dat notificaties minimaal één keer worden afgeleverd.
Notificaties waarbij de producer geen enkele vorm van vertrouwen van ontvangst krijgt hebben weinig waarde. Er zijn allerlei niveaus van aflevergaranties. At-least-once is eenvoudig te implementeren en biedt een belangrijke vertrouwensbasis. Producers weten niet hoeveel waarde een notificatie heeft voor een consumer en hebben daarom een verantwoordelijkheid om hun uiterste best te doen om notificaties af te leveren. Exactly-once is ingewikkelder te implementeren en in veel gevallen niet nodig. At-most-once biedt onvoldoende garanties.
Borg bij het gebruik van communicatiekanalen die zelf geen aflevergaranties bieden dat de aflevering bij de consumer idempotent is. Idempotent betekent dat eenmalige verwerking dezelfde impact en betekenis heeft als meermalige verwerking. Door gebruik te maken van idempotentie kan het verzenden van de notificatie net zo lang worden geprobeerd totdat de consumer de aflevering heeft bevestigd. Het is daarbij de verantwoordelijkheid van de consumer om duplicaten te filteren. Gebruik van de richtlijn op developer.overheid.nl is aanbevolen.
Ontwikkel notificaties contract-first.
Het heeft een aantal belangrijke voordelen om eerst specificaties op te stellen en af te stemmen, alvorens te starten met de implementatie van notificaties. Het ontkoppelt de teams/partijen, doordat vooraf duidelijk is wat de afhankelijkheden zijn en wat de betekenis is van de gehanteerde begrippen. De kans op grotere wijzigingen wordt hierdoor ook veel kleiner. Het leidt tot betere documentatie en daarmee ook tot snellere onboarding en testbaarheid.
Dit betekent dat voorafgaand aan het implementeren van notificaties eerst de gebeurtenistypes formeel worden beschreven. Ook de gebruikte begrippen en het gehanteerde gegevensmodel zouden eerst moeten zijn uitgekristalliseerd.
Producers definiëren gebeurtenissen.
Een gebeurtenis is iets dat gebeurt in het domein van de producer en staat daarmee in de basis los van het gebruik door een consumer. Consumers kunnen uiteraard wel bepaalde informatiebehoeften hebben, die invloed kunnen hebben op welke gegevens over gebeurtenissen worden vastgelegd en uitgewisseld. Het is echter uiteindelijk aan de producer om te bepalen of deze gegevens ook ingewonnen kunnen worden en tegen acceptabele kosten.
Producers leveren dan ook de specificatie van gebeurtenissen, na afstemming van consumers over hun informatiebehoeften. Gebeurtenissen hanteren daarbij de taal zoals gangbaar bij de producer. Deze dient dan ook duidelijk gedefinieerd te zijn in de vorm van begrippen en gegevensmodellen. Bij het notificeren kunnen er wel filters worden gedefinieerd die een voor een consumer relevante selectie maken van de gegevens over de gebeurtenis.
21 april 2026 08:23:01
2 december 2025 07:15:16
21 april 2026 08:23:01
29
Informatief
