Bij het notificeren worden ketenpartners op de hoogte gebracht van gebeurtenissen binnen processen bij andere ketenpartners. Een verbreding van deze scope betreft de gebeurtenissen vanuit Europa en overheidsbrede gebeurtenissen vanuit andere ketens. Dit maakt het mogelijk voor partners om te acteren op die gebeurtenissen en stelt ze in staat op het juiste moment relevante informatie op te vragen en te gebruiker.
De gebeurtenistypen zijn door de aanbieder vooraf gedefinieerd en vastgelegd in een catalogus, zodat ketenpartners zich kunnen abonneren op de voor hen relevante notificaties. De notificaties bevatten uitsluitend gegevens over de gebeurtenis bij een v-nummer; indien meer details nodig zijn, kan een ketenpartner aanvullend de gegevens over de gebeurtenis opvragen bij de desbetreffende ketenpartner. In de opvolgende paragrafen gaan we hier nader op in.
Het patroon notificeren over gebeurtenissen volgt het patroon uit de bedrijfsarchitectuur, zoals beschreven in Gebeurtenissen in de keten.
Het patroon omvat het notificeren over gebeurtenissen die in de bedrijfsprocessen bij een specifieke ketenpartner hebben plaatsgevonden. Op basis van een vooraf bepaalde lijst van gebeurtenistypen worden ketenpartners, die hebben aangegeven hierin geïnteresseerd te zijn, op de hoogte gesteld van het optreden van deze gebeurtenis. Dit noemen we een notificatie.
Notificaties zijn beperkt tot enkele identificerende gegevens over de gebeurtenis. Het is aan de afnemer om te bepalen wat hij hiermee doet. Geeft de gebeurtenis aanleiding tot een informatiebehoefte, dan kan deze verkregen worden via patroon Informatie verkrijgen.
Belangrijke principes uit de MIRA Thema’s en principes die op dit patroon van toepassing zijn:
Ketenpartners zijn op de hoogte van voor hen relevante gebeurtenissen.
Notificeren via een overheidbrede standaard.
Notificeren als apart patroon notificeren.
Gebruik maken van API's voor o.a. abonneren op notificaties en opvragen details over een gebeurtenis.
In onderstaande figuur de architectuur voor het patroon notificeren over gebeurtenissen getekend.
In dit patroon kan elke ketenpartner een bron of ontvanger van notificaties zijn. Europa gedraagt zich in dezen ook als ketenpartner. Het bronsysteem detecteert een gebeurtenis en stuurt een notificatie naar de notificatiebroker.
De broker controleert welke ketenpartners zich hebben geabonneerd op dit gebeurtenistype en/of het v-nummer waarop de gebeurtenis betrekking heeft en stuurt de notificatie naar deze ontvangers. In deze component vindt ook een check plaats op de doelbinding behorende bij abonnement op een notificatie van dit type.
Toelichting op de nummers in de plaat:
* omdat notificaties ook v-nummers zullen bevatten en hier bovenop zeker ook de combinatie van een bepaald v-nummer en een type gebeurtenis privacygevoelig kunnen zijn, mag niet iedereen zich zomaar op elk type gebeurtenis abonneren. Er dient hier dus ook een mechanisme (technisch en/of procedureel) aanwezig te zijn om dit te kunnen bewaken.
Het succes van notificeren vereist duidelijke afspraken over de definities van gebeurtenistypen en de bijbehorende kaders. Dit zorgt voor een eenduidig begrip bij alle ketenpartners over wat een gebeurtenis inhoudt, hoe deze wordt vastgelegd en gedeeld, en welke informatie in een notificatie mag worden opgenomen.
Zoals in de bedrijfsarchitectuur beschreven is het de aanbiedende partij die de gebeurtenis, notificatie definieert in de catalogus. Dat kan voor een afnemer inhouden dat deze in gesprek moet gaan met een aanbiedende partij om na te gaan welke gebeurtenis uit de context van de aanbieder relevant is vanuit het afnemer perspectief. We willen nadrukkelijk voorkomen dat er context uit de bedrijfsprocessen van de afnemer terugkomen in de gebeurtenis.
De ketenpartner die verantwoordelijk is voor het bedrijfsproces achter een gebeurtenis beheert de administratie in een gebeurtenissencatalogus. In deze catalogus registreert en beheert de ketenpartner alle gebeurtenistypen zorgvuldig. Dit omvat niet alleen de beschrijving en metadata van elke gebeurtenis, maar ook informatie over wie verantwoordelijk is voor het beheer en welke partijen notificaties mogen ontvangen.
Om ervoor te zorgen dat notificaties consistent blijven, voldoen aan afspraken en zich verder ontwikkelen, is centrale regie essentieel. Deze regie wordt georganiseerd via een gebruikersoverleg, waar ketenpartners gezamenlijk afspraken maken en verbeteringen bespreken. Hierdoor blijft het notificatiesysteem effectief en uniform binnen de hele keten. De afstemming over gebeurtenissen van buiten de keten vindt hier plaats.
Het is essentieel om elke gebeurtenis in de Migratieketen nauwkeurig te definiëren en te beschrijven. Dit houdt in dat elke gebeurtenis wordt voorzien van relevante metadata, waaronder:
In een nog op te stellen handreiking is het definiëren en beschrijven van gebeurtenissen verder uit te werken. De beschrijvingen moeten gestructureerd worden volgens een nog vast te stellen informatiemodel voor gebeurtenissen. Dit model zorgt ervoor dat alle ketenpartners op een uniforme en consistente manier met gebeurtenisgegevens kunnen werken. Door deze standaardisatie wordt de samenwerking binnen de keten en de interoperabiliteit verbeterd.
Het gebruik van Cloudevents NL Gov profile biedt een standaard manier om gebeurtenissen te definiëren en notificaties te versturen. Dit patroon maakt het mogelijk om interoperabiliteit en technische uniformiteit te realiseren binnen de keten en met andere overheidsorganisaties.
Voor meer informatie:
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Europaloket | Een centrale voorziening in de migratieketen die de brug vormt tussen de nationale systemen en de Europese (JBZ-)systemen voor migratie, opsporing en veiligheid. | |
| abonnementenregistratie | Een centrale voorziening waarin wordt bijgehouden welke afnemer een abonnement heeft op notificaties van welk type |
|
| gebeurtenissencatalogus | Een centrale voorziening waarin de gebeurtenissen die aangeboden worden door de keten- of samenwerkingspartners binnen de Migratieketen worden bijgehouden en gepubliceerd. | De catalogus bevat beschrijvingen van gebeurtenissen en relevante metadata, zoals bron en betrokken processen. Partners kunnen zich abonneren op specifieke gebeurtenissen. |
| notificatiebroker | Een centrale dienst die notificaties ontvangt en doorstuurt naar de geabonneerde ketenpartners. |
|
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Gebeurtenis aanlever api | API waarmee het bronsysteem een notificatie over een gebeurtneis kan aanleveren aan de notificatiebroker | |
| Gebeurtenis abonneer api | API waarmee een afnemend systeem zich kan abonneren op notificaties op gebeurtenissen van een bepaald type | |
| Gebeurteniscatalogus registratie api | API waarmee gebeurtenis geregistreerd kan worden in ketenbrede gebeurtenissencatalogus. | |
| Gebeurteniscatalogus zoek api | API waarmee op een gebeurtenis kenmerk gezocht kan worden in ketenbrede gebeurtenissencatalogus. | Deze API geeft de overeenkomstige gebeurtenissen terug die binnen de keten beschikbaar zijn. Dit met oog op geautomatiseerde koppelingen vanuit applicaties. |
| Naam | Omschrijving | Toelichting |
|---|---|---|
| Aanbieder specifieke gebeurteniscatalogus | Een eigen gebeurtenissencatalogus om van daaruit een (keten-relevante) gebeurtenis in de ketenbrede catalogus te registreren. | Dit kan een groeipad zijn met aansluiting naar een overheidsbrede gebeurtenissencatalogus. |
| Afnemend systeem notificaties | Systeem van partij die notificaties over gebeurtenissen afneemt | Het staat ketenpartners vrij om ook notificaties van andere overheidspartijen te accepteren volgens deze standaard. Toegang tot de gebeurtenissencatalogus is echter beperkt tot de eerder genoemde groepen. |
| Bronsysteem Gebeurtenissen | Systeem van partij die waarin gebeurtenissen ontstaan | Voor het patroon notificeren kunnen het ketenpartners, samenwerkingspartners of eventueel externe aanbieders zijn die notificaties aanbieden. |
| Has target element | Omschrijving | Toelichting |
|---|---|---|
| Ontvang Notificatie API | Een API voor ontvangst van een notificatie | |
| Gebeurtenissen API | Een API waarmee een details van een specifieke gebeurtenis op te vragen zijn | Of dit een referentie is naar een andere API, een Sigma gegeven of een registratie van aanvullende details is nog de vraag. |
Doordat een notificatie uitsluitend notificeert over een gebeurtenis zonder inhoudelijk data de gebeurtenis mee te leveren wordt er al flink aan data-minimalisatie gedaan. Notificaties zorgen ervoor dat informatie over bedrijfsgebeurtenissen actief wordt gedeeld, een 'push-notificatie', waardoor handmatige stappen en dubbele controles worden gereduceerd.
Bij het notificeren speelt het Europaloket een centrale rol in de communicatie tussen de Migratieketen en Europese partners. Het Europaloket fungeert als een ketenpartner die notificaties ontvangt via de notificatiebroker en deze vertaalt of doorstuurt naar Europese partners. Dit maakt het mogelijk om informatie efficiënt en volgens gestandaardiseerde protocollen te delen.
Een voorbeeld van een gebeurtenis die genotificeerd kan worden, is de verwijdering van een dossier in het kader van het Entry/Exit System (EES). Deze gebeurtenis wordt via een notificatie door een ketenpartner naar het Europaloket gestuurd, waarna het Europaloket de notificatie verder distribueert naar relevante Europese partners die achter het loket functioneren.
Dit hoofdstuk beschrijft de stappen en overwegingen voor de transitie van de huidige situatie naar het in deze architectuur geschetste doel. Hoewel deze aanpak indicatief is, biedt het een overzicht van de benodigde acties om de impact en betekenis van het voorgestelde notificatiepatroon te beoordelen. Na goedkeuring van deze architectuur volgt een verdere uitwerking in een gedetailleerd en integraal transitieplan.
De implementatie van het notificatiepatroon is complementair aan de bestaande communicatiepatronen. De ontwikkeling zit daarmee niet vast aan de doorontwikkeling van de bestaande patronen.
Hierbij is telkens aangegeven of deze vraagstukken in een volgende versie van deze architectuur of in de onderliggende solutions moeten worden uitgewerkt.
| Onderwerp | Toelichting | Wanneer uitwerken | Uitwerking |
|---|---|---|---|
| Gaan we bij de start uit van deelname aan een overheidsbrede catalogus? | We gebruiken de overheidsbrede standaard, maar is er ook al een overheidsbreed stelsel om op aan te kunnen sluiten? | In een volgende versie | |
| Wat is de werkwijze in het kader van foutherstel? Wat is de positionering van een audit log? | Zijn er aanvullende afspraken nodig hoe om te gaan met excepties? | In de nadere uitwerking | |
| Is het delen van notificaties met strafrecht (VRIS) noodzakelijk, toegestaan? | Er is overlap, bv. mbt VRIS. Het is wenselijk om hierover genotificeerd te worden. Maar hoe past dit in ene breder kader van samenwerking tussen de ketens? | Een volgende versie | |
| Volstaat filteren op type en V-nummer of is er meer nodig? | Wat is de behoefte uit de business? | Vraag meenemen in Quick-scan en PoC |
Deze pagina is voor het laatst bewerkt op 10 mrt 2025 om 15:26.