Notificatieservice

Context

Binnen MijnOverheid Zakelijk is betrouwbare, tijdige en kanaalonafhankelijke communicatie richting burgers en ondernemers essentieel om te voldoen aan de Wet MEBV. Waar de Profiel Service voorziet in het vastleggen van contactgegevens en voorkeuren, faciliteert de Notificatie Service het daadwerkelijk versturen van berichten en attenderingen via verschillende kanalen (zoals e‑mail, sms, push of toekomstige kanalen) en het registreren van de afleversstatus.

De Notificatie Service opereert als generieke voorziening tussen overheidsdiensten en verzendkanalen/platforms. Dit maakt het mogelijk om notificaties consistent aan te bieden, kanaalkeuzes van de gebruiker te respecteren en technische verschillen tussen verzendproviders af te schermen.

Uitdagingen

• Fragmentatie van kanalen en leveranciers: elke dienstverlener heeft eigen integraties en afleverbewijzen.
• Doelbinding en voorkeuren: notificaties moeten aansluiten op door de gebruiker opgegeven voorkeuren en rechtmatig worden verzonden.
• Betrouwbaarheid en traceerbaarheid: afleversstatus, retries, dead‑lettering en auditlogs moeten uniform worden geborgd.
• Schaalbaarheid en piekbelasting: grote aantallen attenderingen & kennisgevingen bij gebeurtenissen.
• Beveiliging en privacy: persoonsgegevens minimaliseren, end‑to‑end beveiliging en conformiteit met wet‑ en regelgeving (o.a. AVG, MEBV).
• Toekomstvastheid: eenvoudig nieuwe kanalen en providers kunnen aansluiten zonder wijzigingen bij afnemende diensten.

Doel

Overheidsorganisaties/Dienstverleners kunnen via één generieke interface templates aanmaken, en via een API deze afleveren over meerdere kanalen.

Ondernemers ontvangen attenderingen & kennisgevingen volgens hun opgegeven voorkeuren via betrouwbare, herkenbare en veilige kanalen.

De Notificatie Service abstraheert kanaalspecifieke complexiteit, past verzendbeleid en throttling toe, en registreert gebeurtenissen en afleversresultaten voor inzicht en verantwoording.

Functioneel overzicht

Inleiding

Dit hoofdstuk bouwt voort op de context en verwijst naar aanvullende documentatie en diagrammen. Het biedt kort en duidelijk inzicht in wat de Notificatie Service doet, voor wie het dat doet en hoe de belangrijkste informatiestromen lopen.

Overzicht

De Notificatie Service biedt één generieke voorziening waarmee overheidsorganisaties notificaties (attenderingen/kennisgevingen) kunnen aanmaken, routeren en afleveren via meerdere kanalen (o.a. e‑mail, sms, push en toekomstige kanalen). De service schermt kanaalspecifieke verschillen af, respecteert voorkeuren en doelbinding.

Wat het systeem feitelijk doet, is notificatieverzoeken betrouwbaar aannemen, verrijken, en afleveren, met observatie op status en foutafhandeling. Belangrijke gebruikers en hun behoeften zijn:

• Dienstverlener/Vakapplicaties: via API een notificatie kunnen aanmaken, met feedback over (tussen)status en eindresultaat.
• Kanaalproviders/voorzieningen (bijv. NotifyNL): gestandaardiseerde aansturing en terugmeldingen via uniforme contracten.

Kernfunctionaliteiten in het kort:

• Notificaties aanmaken: API voor het registreren van een notificatieverzoek met metadata (template, correlatie‑ID).
• Routering en aflevering: aanbieden aan het juiste kanaal of provider; ondersteunen van meerdere providers en failover.
• Status & callbacks: vastleggen van (tussen)statussen; callbacks/webhooks naar de aanroeper; idempotente statusupdates.
• Retries & dead‑lettering: configureerbare retry‑strategie per kanaal; Dead Letter Queue (DLQ) voor niet‑afleverbare berichten.
• Logging & audit: gebeurtenissen vastleggen conform LDV; correlatie‑ID’s voor traceerbaarheid end‑to‑end.

Belangrijkste processen en informatiestromen:

1. Aanname notificatieverzoek – Een vakapplicatie doet een verzoek tot notificatie.

   • De Notificatie Service valideert het verzoek, bewaart een initiële status (bijv. Accepted/Queued).
   • Koppelt terug wanneer de status uiteindelijk naar Succeeded/Failed gaat.

2. Kanaalkeuze en voorkeursverwerking – De aannamen is dat de vakapplicatie de kanaal en voorkeur al heeft vastgelegd.

   • In sommige van de scenario’s is de notificatie service wel verantwoordelijk voor kanaalherstel & het ophalen van adresgegevens.

3. Aflevering en status – De service biedt het bericht aan bij de gekozen provider (bijv. NotifyNL) en registreert tussenstappen (Enqueued, Sent, Delivered/Failed).

   • Callbacks vanaf de provider worden verwerkt en beschikbaar gesteld aan de aanroeper.

4. Retries, failover en fallback – Bij tijdelijke fouten worden retries toegepast met circuit-breaker ‘back‑off’’.

   • Indien overeengekomen, kan de OMC als fallback overschakelen naar een alternatieve kanaalstrategie.
   • ^ TODO DISCUSSIEPUNT, moet het mogelijk zijn een geprioriteerde lijst van contactmethodes op kunnen sturen naar de notificatie service

Scenario’s

Onderstaande scenario’s illustreren de samenwerking tussen vakapplicatie, Notificatie Service, Profiel Service en verzendvoorzieningen. Dit zijn de welbekende scenario’s over hoe overheidsdiensten zouden kunnen interacteren met de Notificatie Service. Scenario 9 staat hier nog niet, maar is idem aan scenario 8, met de toevoeging van kanaalherstel.

Scenario 2 — Vakapplicatie belt direct de Notificatie Service

mermaid
sequenceDiagram
    actor Medewerker
    Medewerker->>Vakapplicatie:
    activate Vakapplicatie
    Vakapplicatie->>Notificatie service:Verstuur verzoek tot notificatie
    activate Notificatie service
    Notificatie service-->>Vakapplicatie:
    deactivate Vakapplicatie
    Notificatie service-->>Vakapplicatie:Notificatie status update callback
    deactivate Notificatie service
    activate Vakapplicatie
    Vakapplicatie->>Vakapplicatie:Afhandeling callback
    deactivate Vakapplicatie

Scenario 8 — Vakapplicatie via OMC met profielverrijking en fallback

mermaid
sequenceDiagram
    actor Medewerker
    Medewerker->>Vakapplicatie:'
    activate Vakapplicatie
    Vakapplicatie->>OMC:Verstuur verzoek tot notificatie
    deactivate Vakapplicatie
    activate OMC
    OMC->>Profiel service:Haal contact inforamtie op o.b.v. kvknummer
    activate Profiel service
    Profiel service-->>OMC:'
    deactivate Profiel service
    OMC->>Notificatie service:Verstuur verzoek tot notificatie
    activate Notificatie service
    deactivate OMC
    
    Notificatie service-->>OMC:Notificatie status update callback
    deactivate Notificatie service
    activate OMC
    alt status = mislukt
    OMC->>Profiel service:Haal adres gegevens op o.b.v. kvknummer
    activate Profiel service
    Profiel service-->>OMC:'
    deactivate Profiel service
    OMC->>Notificatie service:Stuur verzoek tot brief
    activate Notificatie service
    Notificatie service-->>OMC:Brief callback
    deactivate Notificatie service
    end
    deactivate OMC
    OMC-->>Vakapplicatie:Optionele callback

Inleiding

Dit hoofdstuk vat de belangrijkste niet-functionele eisen voor de Notificatie Service samen. De eisen zijn zo veel mogelijk SMART geformuleerd en sluiten aan op het functioneel overzicht en de context. Waar relevant verwijzen we naar architectuurkeuzes in de ADR’s en ondersteunende documentatie.

Overzicht

De onderstaande kwaliteitseisen zijn architectonisch significant en sturen ontwerp- en implementatiekeuzes:

• Beveiliging & Privacy (AVG, authenticatie/authorisatie, dataminimalisatie)
• Beschikbaarheid & Continuïteit
• Performance & Schaalbaarheid
• Betrouwbaarheid & Afleverzekerheid (deliverability, retries)
• Auditability & Logging (LDV)
• Interoperabiliteit & Open Standaarden
• Observeerbaarheid (monitoring, metrics, tracing)
• Herstelbaarheid (back-up/restore, DR)
• Toegankelijkheid & Gebruiksvriendelijkheid (waar van toepassing voor beheer/UI)

Waar zaken bewust buiten scope vallen, is dit expliciet benoemd.

Beveiliging & Privacy

• Authenticatie: Service‑to‑service authenticatie via OIDC/OAuth 2.0 (conform ADR 0006). Tokens met beperkte scopes, geen long‑lived secrets in code.
• Autorisatie: Scope‑gebaseerde autorisatie per dienst/dienstverlener, met dataminimalisatie. Alleen minimaal noodzakelijke persoonsgegevens worden verwacht en niet redundantly opgeslagen.
• Privacy/AVG: verwerkingsregister en grondslagregistratie op orde (AVG art. 6 en 30). DPIA uitgevoerd vóór productie. Pseudonimiseer of hash waar mogelijk correlatie‑ID’s zonder persoonsherleidbaarheid in logs.
• Dataretentie: operationele logs max. 90 dagen; audit‑logs conform bewaartermijnen uit ADR 0005/0007. Payloads met persoonsgegevens niet in applicatielogs opslaan.
• Transport & opslag: TLS 1.2+ in transit; secrets via sealed secrets/secret manager; encryptie‑at‑rest waar toepasbaar.

Beschikbaarheid & Continuïteit

• Doel beschikbaarheid betafase: ≥ 50% tijdens kantoortijden. Doel productie: ≥ 99,9% 24x7 (excl. gepland onderhoud). Vastgelegd als SLO en gemonitord.
• Onderhoud: onaangekondigd mogelijk in betafase; productie onderhoud gecommuniceerd via standaard releaseproces.
• Degradatie: bij uitval van een kanaal moet de service gedegen degraderen (queueing, retries, failover) zonder dat upstream systemen blokkeren.

Performance & Schaalbaarheid

• TODO, dit is een beetje verzonnen BS, maar zoiets moeten we gaan bepalen.
• Aanname notificatieverzoek (API): p95 latency ≤ 150 ms binnen hetzelfde DC; p99 ≤ 300 ms (excl. downstream kanaal‑roundtrip).
• Callback‑verwerking: p95 ≤ 100 ms per event; idempotent binnen 24 uur zodat dubbele provider‑callbacks geen inconsistenties veroorzaken.
• Throughput initiële doelstelling: 50 notificaties/sec per instance; horizontaal schaalbaar naar ≥ 500/sec door te schalen.
• Wachtrijen gebruiken back‑pressure; geen onbegrensde in‑memory buffers. Batch‑publish naar providers waar toegestaan.

Betrouwbaarheid & Afleverzekerheid

• Retries: Exponentiële back‑off per kanaal; max retry‑duur configureerbaar. Niet‑afleverbare berichten gaan naar DLQ met reden.
• Ordering: Geen harde ordering‑garantie over kanalen, wel best‑effort ordering.
• Statusmodellering: eenduidige statussen (Geaccepteerd, In de wachtrij geplaatst, Verzonden, Geleverd, Mislukt, Verlopen). Overgangen zijn audit‑baar en herleidbaar.

Auditability & Logging (LDV)

• Audit log: conform ADR 0005 en ADR 0007. Mutaties en externe afleverresultaten worden gelogd.
• Onweerlegbaarheid: timestamps (UTC), correlatie‑ID, provider‑referenties en verificatie op event‑integriteit. Toegang tot audit‑logs strikt geautoriseerd.

Interoperabiliteit & Open Standaarden

• API‑contracten in OpenAPI 3.0+, JSON over HTTPS. HTTP‑statuscodes volgens REST best practices.
• Afstemming met Federatief Data Stelsel (FDS) en LDV‑implementatie (ADR 0010).

Observeerbaarheid

• Metrics minimaal: request‑latency (p50/p95/p99), error‑rate per endpoint, queue‑diepte, retry‑tellingen, DLQ instroom/doorlooptijd, callback‑verwerkingstijden.
• Tracing: Tracing over inkomende verzoeken, provider‑aanbieding en callbacks; correlatie‑ID propagatie verplicht.
• Logging: Log op INFO/WARN/ERROR; geen persoonsgegevens in logs, gebruik referenties/ID’s.

Herstelbaarheid (Back‑up/Restore, DR)

• TODO, dit is een beetje verzonnen BS, maar zoiets moeten we gaan bepalen.
• RPO/RTO: pilot RTO ≤ 1 werkdag; productie RPO ≤ X minuten, RTO ≤ Y minuten (waarden nader te bepalen met beheer).
• Back‑ups: TODO hebben we hier iets van backups, van berichten die nog net niet verzonden zijn ofzo?
• DLQ‑replay: gecontroleerde replay voorziening met filtering om incidenten te herstellen zonder duplicaten.

Toegankelijkheid & Gebruiksvriendelijkheid

• Frontend voldoet aan WCAG 2.1 A+AA; toetsing via Lighthouse en handmatige audit.
• Ondersteunde browsers: Chrome, Edge, Safari, Firefox (laatste twee versies), inclusief responsive weergave, conform beleid Rijksoverheid.

Open Standaarden

TODO iets over forum standaardisatie en beslisboom open standaard

Kwaliteitsmeting en borging

• Geautomatiseerde kwaliteitscontroles (linting, security scanning/CVE), contracttests op API’s in CI/CD.
• Lighthouse voor eventuele UI’s; Accessibility & Best Practices prioriteit. SEO/PWA niet van toepassing.
• SLO’s/SLA’s worden actief gemonitord; afwijkingen leiden tot incidenten en verbeteracties.

Buiten scope / expliciete uitsluitingen

• Offline‑first gebruik is uitgesloten.

Beperkingen

Inleiding

Deze sectie beschrijft de expliciete randvoorwaarden en beperkingen waarbinnen de Notificatie Service wordt ontworpen en gerealiseerd. Doel is om gemaakte keuzes en context te borgen en later te kunnen herleiden waarom bepaalde opties zijn overwogen.

Overzicht

De volgende categorieën beperkingen zijn van toepassing. Per punt noemen we wat de beperking inhoudt, door wie/waarom deze is opgelegd en de impact op de architectuur.

Organisatorische en tijd/budget beperkingen

• Betafase: lever een werkende beta met kernfunctionaliteit (aanname, routering, status/callbacks, retries/DLQ) binnen beperkte tijd en middelen. Opgelegd door programma. Impact: focus op ‘must haves’; nice-to-haves en minder gebruikte kanalen worden gefaseerd toegevoegd. Ontwerp blijft uitbreidbaar richting productie.

Identiteit, authenticatie en autorisatie

• Service‑to‑service authenticatie via OIDC/OAuth2 verplicht (ADR 0006). Opgelegd door rijksbeleid en interoperabiliteitseisen. Impact: geen eigen credential management; integratie met IDP/token provider bepaalt token‑handling; korte TTL’s en beperkte scopes.
• Scope‑gebaseerde autorisatie voor dienstverleners via FDS; scopes beperken toegang tot minimaal noodzakelijke rechten (least privilege) en doelbinding. Impact: alle API’s moeten scopes/claims afdwingen.

Juridisch en compliance

• AVG en LDV‑vereisten (ADR 0007, 0010): auditeerbare gebeurtenissen, transparantie en bewaartermijnen zijn verplicht; geen persoonsgegevens in applicatielogs, alleen referenties/ID’s. Opgelegd door wet‑ en regelgeving. Impact: centrale auditlog, correlatie‑ID’s en idempotentie zijn noodzakelijk; logging wordt gestructureerd ingericht m.b.v LDV.
• Bewijslast/afleverbewijs: afleverstatus en relevante provider‑referenties moeten reproduceerbaar zijn. Impact: eenduidige statusmodellering en opslag van provider‑referenties zonder overtreding dataminimalisatie.

Technologiestack en standaarden

• API’s in OpenAPI 3.0+, JSON over HTTPS; gebruik van standaard HTTP‑protocollen. Opgelegd door interoperabiliteit. Impact: geen propriëtaire protocollen; contract‑first ontwikkeling.
• Digitoegankelijk wordt rekening mee gehouden bij het ontwikkelen van front-end zaken. Opgelegd door UX‑kaders Rijksoverheid. Impact: UI‑componentkeuze is beperkt; consistentie en toegankelijkheid worden geborgd.
• Java in combinatie met Quarkus. Opgelegd door beoogde beheerpartij. Impact: minimaal.

Integraties en afhankelijkheden

• Afhankelijkheid van kanaalproviders/voorzieningen (bijv. NotifyNL). Opgelegd door functionele doelstelling en bestaande voorzieningen. Impact: beschikbaarheid/performance mede bepaald door externe SLA’s; timeouts, retries, circuit breakers en back‑pressure noodzakelijk.
• Callbackmechanismen zijn provider‑gedreven en niet uniform. Impact: normalisatielaag/adapters nodig; idempotente event‑verwerking en DLQ verplicht.

Deploy- en hostingkader

• Uitrol op picard platform van Logius. Opgelegd door beoogde beheerpartij. Impact: keuze voor specifieke PaaS‑diensten of databases kan beperkt zijn; encryptie‑at‑rest en netwerkpolicies volgen platform‑standaard.
• Netwerkbeperkingen: alleen uitgaand verkeer naar whitelisted endpoints. Impact: service discovery en integraties moeten binnen deze restricties werken; egress‑controle en proxy’s waar nodig.

Ontwikkelproces en team

• Gedeelde capaciteit met andere deelprojecten (Profiel service, MOZa-Portaal, BBO). Opgelegd door programma. Impact: prioritering op kernflows, gefaseerde oplevering; automatisering (CI/CD, contracttests) is essentieel om snelheid/kwaliteit te borgen.

Data, opslag en retentie

• Geen langdurige opslag van berichtinhoud met persoonsgegevens in operationele logs; minimale opslag van status en referenties. Opgelegd door AVG. Impact: design richt op metadata‑opslag en verwijzingen i.p.v. payloads; retentiebeleid afdwingen (auditlogs conform ADR 0005/0007).
• Greenfield start, geen migratie van oude notificatie historiek.

Waarom deze beperkingen ertoe doen

Beperkingen versnellen ontwerp en implementatie, maar sturen ook de architectuur:

• Federatieve auth/scopes vereisen strikte scheiding en dataminimalisatie
• AVG dwingt auditability en gestructureerde logging
• Afhankelijkheid van externe providers vereist robuuste integratiepatronen (timeouts, retries, circuit breakers, DLQ) en een eenduidig statusmodel. Door deze constraints expliciet te maken, voorkomen we schijnbaar ‘vreemde’ keuzes achteraf.

Verwijzingen

• ADR 0002 – Notify onderzoek
• ADR 0003 – Scenario bepaling
• ADR 0005 – AuditLog & EventSourcing
• ADR 0006 – Federatieve authenticatie en autorisatie op basis van OIDC en eIDas
• ADR 0007 – Logboek Dataverwerking (LDV)
• ADR 0009 – NL Design System
• ADR 0010 – LDV implementatie

Design Principes

Inleiding

Het doel van dit hoofdstuk is om expliciet te maken welke principes we volgen, zodat ontwerp- en implementatiekeuzes consistent en uitlegbaar zijn voor alle betrokkenen. Waar van toepassing verwijzen we naar onderliggende ADR’s en overige documentatie.

Principes

De onderstaande principes ondersteunen de kwaliteitseisen in het kwaliteitseisen hoofdstuk en vormen samen met de ADR’s de basis voor ontwerpkeuzes in de software‑architectuur van de Notificatie Service.

• Open standaarden, tenzij We geven de voorkeur aan open, breed gedragen standaarden voor interoperabiliteit. Voorbeelden: OpenAPI 3 voor API’s, JSON/HTTP, OIDC/OAuth 2.0 voor service‑to‑service authenticatie.

• Contract‑first API‑ontwikkeling (OpenAPI) API’s worden beschreven in OpenAPI; semantic versioning op contracten; backward compatibility binnen een major versie. Documentatie en try‑out via Swagger/Redoc. Contracttests bewaken compatibiliteit met afnemers en providers.

• Kanaal‑agnostische interfaces, adapters per provider Het domeinmodel en de publieke API abstraheren kanaalspecifieke details. Integraties met providers (bijv. NotifyNL/OMC) gebeuren via adapters/ports, zodat providers vervangbaar zijn zonder breaking changes voor afnemers.

• Beveiliging en privacy by design Alleen noodzakelijke gegevens, least‑privilege scopes, encryptie in transit, geen persoonsgegevens in logs. Audit van mutaties en statusovergangen. Pseudonimiseer referenties waar mogelijk. Verwijzingen: ADR 0005, ADR 0006, ADR 0007, ADR 0010.

• Idempotentie en correlatie als first‑class concerns Callback‑ en statusupdates zijn idempotent, herhaalde provider‑events veroorzaken geen dubbele acties.

• Eenduidig statusmodel en callback‑gedreven verwerking Notificaties volgen een expliciet statusmodel (Ex.Geaccepteerd, In de wachtrij geplaatst, Verzonden, Geleverd, Mislukt, Verlopen). Callbacks en polling leveren consistente, herleidbare staten op, state transitions zijn auditeerbaar.

• Betrouwbaarheid via retries, back‑off en DLQ Tijdelijke fouten worden behandeld met exponentiële back‑off, structurele fouten gaan naar een DLQ met reden. Replay van DLQ gebeurt gecontroleerd en gefilterd om duplicaten te vermijden.

• Resilience patterns standaard Timeouts, circuit breakers, bulkheads en back‑pressure op queues beschermen tegen cascaderende fouten en provider‑uitval.

• Hoge cohesie, lage koppeling Duidelijke scheiding tussen public API, applicatie‑/routeringslogica, provider‑adapters en persistente lagen. Modules hebben een beperkte verantwoordelijkheid en communiceren via expliciete contracten.

• Stateless services Instances zijn stateless; state zit in expliciete data stores (status, audit) en messaging. Dit vereenvoudigt horizontale schaalbaarheid en rolling upgrades.

• Consistente foutafhandeling en API‑conventies RESTful paden, semantisch correcte HTTP‑methoden en statuscodes, eenduidige foutstructuur (problemdetails). Heldere, mens‑ en machineleesbare foutmeldingen zonder persoonsgegevens.

• Configuratie boven code voor kanaalbeleid Kanaalkeuze, throttling, blackout‑windows en provider‑prioriteiten zijn runtime‑configureerbaar (feature flags waar passend) en niet hard‑gecodeerd.

• Versiebeheer en gecontroleerde uitrol Backward‑compatible wijzigingen worden gefaseerd uitgerold, breaking changes alleen in nieuwe major. Feature flags ondersteunen gefaseerde activatie per kanaal/provider.

• Testbaarheid en kwaliteit geautomatiseerd Unit‑ en integratietests voor statusmachine en adapters, contracttests met afnemers en providers, performance‑ en soak‑tests op queues en callbacks.

Software architectuur

Architectuurschets Notificeren

Het eerste onderwerp van het programma om te verkennen is een Rijksbrede voorziening voor het notificeren, waarbij een kanaalherstel functionaliteit een vereiste is om te kunnen voldoen aan de Wet Modernisering Elektronisch Bestuurlijk Verkeer (MEBV).

Daarvoor zijn door Paul Janssen, architect bij de VNG, een aantal scenario’s geschetst die verschillende situaties oplossen in verschillende evoluties van het notificatie proces. Wij hebben daaruit een selectie van 2 scenarios uitgewerkt in prototypes, namelijk #2 en #8. Naar aanleiding van verder onderzoek is gebleken dat er nog een extra scenario nodig is, welke we tot scenario #9 hebben benoemd, waarbij ook het kanaalherstel wordt gefasciliteerd.

In het Notificatie Service context diagram is de Notificatie Service uitgewerkt en wordt weergegeven hoe de drie scenario’s interacteren met de Notificatie Service. De belangrijkste aandachtspunten in deze afbeelding zijn de vier services die binnen het Logius-landschap opereren: de Berichtenbox voor Burgers en Ondernemers (BBO), de Kanaalhersteldienst, de Notificatie Service en de Profiel Service. De eerste twee zijn grijs weergegeven om aan te duiden dat het bestaande systemen betreft.

In het Notificatie Service Container Diagram wordt verder ingezoomd op de onderdelen van de Notificatie Service. Deze bestaat uit twee componenten: NotifyNL en de Kennisgeving Service.

Daarnaast zijn ook de Kanaalhersteldienst en de Profiel Service opgenomen. Deze twee componenten zijn bepalend voor de onderlinge verschillen tussen de drie scenario’s: de BD maakt gebruik van zowel de Profiel Service als de Kanaalhersteldienst, het UWV raadpleegt enkel de Profiel Service, en de DV maakt van geen van beide gebruik.
Meer over dit onderscheid wordt zichtbaar in het scenario onder het kopje Belastingdienst, waarin beide componenten actief worden ingezet.

De drie scenario’s illustreren verschillende vormen van notificaties. Scenario 2 betreft een attendering, terwijl scenario’s 8 (UWV) en 9 (BD) betrekking hebben op kennisgevingen.

Scenario 2

Dit is nog steeds het eenvoudigste scenario: de DV roept hierbij rechtstreeks NotifyNL aan, die vervolgens de notificatie verstuurt naar de zakelijke gebruiker. De Profiel Service wordt hierbij niet gebruikt, wat betekent dat DV zelf de contactgegevens moet aanleveren. Ook wordt de Kanaalhersteldienst niet aangeroepen; bij een kanaalstoring zou DV dit dus zelf moeten afhandelen.

Scenario 8

In scenario 8, vertegenwoordigd door het DV, wordt eerst de contactinformatie opgehaald bij de Profiel Service voordat NotifyNL wordt aangeroepen om de notificatie te versturen. Dit betekent dat er in geval van kanaaluitval geen kanaalherstel plaatsvindt vanuit de Notificatie Service.

Scenario 9

In dit scenario roept de BD de Berichtenbox voor Burgers en Ondernemers (BBO) aan, die vervolgens het notificatieproces namens hen uitvoert. De BBO haalt de profielinformatie op bij de Profiel Service en geeft deze door aan de Kennisgeving Service. Deze is vervolgens verantwoordelijk voor het versturen van de notificatie naar NotifyNL.

Belangrijk om te vermelden is dat de BD ook de mogelijkheid heeft om het notificatieproces niet via de BBO, maar rechtstreeks te initiëren via de Kennisgeving Service. In dat geval slaat de BD de BBO over en levert zelf de benodigde gegevens aan. De verdere afhandeling, waaronder het ophalen van profielinformatie en het versturen van de notificatie naar NotifyNL, verloopt vervolgens identiek.

Indien het afleveren van de notificatie mislukt door kanaaluitval, start de Kennisgeving Service automatisch het kanaalherstelproces. Hierbij worden opnieuw de adresgegevens opgehaald bij het handelsregister, waarna deze worden doorgegeven aan de Kanaalhersteldienst voor verdere afhandeling.

De scenario’s

In dit hoofdstuk worden de drie scenario’s verder toegelicht. Zie ook ADR-0003 en hoofdstuk 2.8 voor aanvullende context. In de onderstaande diagram worden alle 3 de scenarios tegelijk weergegeven.

Scenario 2

Dit scenario representeert het versturen van een attendering.
De RVO beschikt over een interne service die notificaties (e-mail, sms of brief) wil versturen naar zakelijke gebruikers. Deze service roept rechtstreeks de Notificatie Service aan en levert daarbij zelf de benodigde contactgegevens aan. De Notificatie Service verstuurt de notificatie direct.

Als het afleveren van de notificatie mislukt (bijvoorbeeld door kanaalproblemen), meldt de Notificatie Service dit terug aan de RVO. De verdere afhandeling van de fout ligt volledig bij de RVO.

Scenario 8

Scenario 8 is functioneel uitgebreider dan scenario 2. Ook hier is sprake van een interne service — de DV Service — die een notificatie wil versturen naar een zakelijke gebruiker. In plaats van direct met de Notificatie Service te communiceren, stuurt de DV Service de aanvraag door naar een Output Management Component (OMC).

De OMC is verantwoordelijk voor het ophalen van de contactgegevens bij de Profiel Service. Met deze informatie wordt de notificatie via de Notificatie Service verzonden. In dit scenario is er nog geen sprake van geautomatiseerd kanaalherstel: als aflevering faalt, is het aan de OMC of de DV om het probleem op te lossen.

Scenario 9

Scenario 9 lijkt in grote lijnen op scenario 8, maar bevat enkele technische verschillen.

De BD Service initieert de verzending van een notificatie naar een zakelijke gebruiker. De aanvraag wordt doorgestuurd naar de OMC, die — net als in scenario 8 — de contactinformatie ophaalt bij de Profiel Service.

Daarna heeft de BD twee routes om de notificatie te versturen: direct via de Notificatie Service of indirect via de BBO. In beide gevallen verloopt het proces grotendeels hetzelfde en is het eindresultaat identiek. Bij directe verzending stuurt de BD de notificatie rechtstreeks naar de Notificatie Service. In het geval van de BBO-route levert de OMC de benodigde gegevens aan bij de Berichtenbox voor Burgers en Ondernemers (BBO), die op haar beurt contact opneemt met de Notificatie Service om de notificatie af te leveren.

Als de Notificatie Service een foutmelding geeft vanwege kanaaluitval, start de Kennisgeving Service, een container binnen de Notificatie Service, automatisch het kanaalherstelproces. Daarbij worden de adresgegevens opgehaald bij de het handelsregister en doorgegeven aan de Kanaalhersteldienst voor verdere afhandeling.

Code

Data

Deployment

View

Omgeving

Broncode

Beheer en Support