W118 Uitfaseren mailboxserver - fase I

1 Probleemstelling

1.1 Omschrijving

Sinds 1992 wisselen gemeenten en afnemers persoonsgegevens uit via de mailboxserver (als onderdeel van de BRP Berichtendienst) waarbij de verstrekkingen aan afnemers vanaf 2012 via de landelijke BRP-Verstrekkingsvoorziening plaatsvinden. Jaarlijks worden ca. 185 miljoen berichten via de Berichtendienst getransporteerd. Het contract met de huidige leverancier OpenText voor het beheer en onderhoud van de mailboxserver loopt in maart 2025 af.

De nieuwe stelseldoelarchitectuur BRP van RvIG zal dan echter nog geen andere voorziening leveren, waardoor een oplossing nodig is om het bestaande, noodzakelijke berichtenverkeer te continueren.

Het huidige contract kan niet rechtmatig verlengd worden. Bovendien maakt de huidige mailboxserver gebruik van zeer verouderde techniek, treden er steeds vaker problemen op (zoals het niet automatisch kunnen verwerken van persoonslijsten met meer van 19.000 tekens) in de berichtencycli en voldoet de mailboxserver niet aan de beveiligingseisen die de RvIG stelt ten aanzien van het wachtwoord.

Strategische keuze

Door zowel de gemeentelijke leveranciers als de RvIG is de voorkeur uitgesproken voor het bouwen van een centrale voorziening die REST API's aanbiedt aan bijhouders en afnemers, waarmee berichten in JSON-formaat kunnen worden uitgewisseld. Dit lost de huidige knelpunten op en kan worden gezien als een eerste stap richting de nieuwe architectuur, zonder daar al te ver op vooruit te lopen.

Deze nieuw te bouwen centrale voorziening kan ingezet worden voor al het huidige berichtenverkeer, maar dit project is een goede aanleiding om te bezien of er van sommige berichtsoorten en berichtencycli afscheid kan worden genomen.

1.2 Herkomst

Deze wijziging komt voort uit initiatief ARC-01-01 van programma Toekomst BRP.

1.3 Raakvlakken

Deze wijziging is de eerste van een aantal LO-wijzigingen die nodig zijn in het kader van het uitfaseren van de mailboxserver. Daarnaast zijn sommige andere voorgestelde wijzigingen in het LO een uitvloeisel van deze wijziging, zoals W190 Uitfaseren Hq01 en Xq01 berichtencycli en W208 BRP Afnemersindicaties API.

2 Oplossing

2.1 Huidige situatie

Via de huidige mailboxserver (MBS) worden berichten uitgewisseld tussen (bijna) alle deelnemers van het stelsel. De MBS is een combinatie van een Message Transfer Agent (MTA) en een Message Store (MS) in een X.400 berichtuitwisselingssysteem. Berichten kunnen door een Message Client (MC) worden geplaatst in de mailbox van de ontvanger, of worden opgehaald uit de eigen mailbox. Die berichten hebben een zogenaamd TLV (Tag Length Value) structuur, worden uitgewisseld volgens het sPd of het turbo-sPd protocol en maken gebruik van de Teletex codering. Ze worden uitgewisseld door bepaalde commando's aan te roepen op de mailboxserver. Zowel het protocol als de berichtenstructuur als de Teletex codering zijn flink verouderd en er zijn allerlei knelpunten, zoals een maximale lengte van berichten en van wachtwoorden.

2.2 Oplossing

Omdat het niet wenselijk is om van alle partijen te eisen dat zij zelf een API aanbieden waarmee direct (en synchroon) berichten naar hen kunnen worden verzonden, is het nodig dat er een nieuwe centrale voorziening komt voor berichtuitwisseling waarin elke deelnemer een postvak heeft. Deze voorziening zal worden ontsloten via een API die het verzenden en ophalen van berichten ondersteunt. Berichten krijgen een nieuwe JSON structuur en de tekencodering wordt UTF-8. Verder blijven alle berichtencycli zoals ze zijn, houden de berichten hun huidige naam, blijft de structuur van de berichten in JSON dicht bij de indeling die ze in het TLV-formaat ook hadden en blijft de tekenset beperkt tot tekens die ook in Teletex worden ondersteund.

Voor afnemers is er al een alternatief voor de MBS: de webservice StuurGBAbericht. Via deze webservice kunnen berichten worden verzonden en opgehaald uit BRP-V, waarbij BRP-V het verzenden naar en ophalen uit de MBS verzorgt. De uit te wisselen berichten hebben nog de TLV-structuur en worden integraal in de XML-berichten van de webservice opgenomen. Op termijn zal ook deze webservice verdwijnen en moeten alle afnemers gebruik gaan maken van de nieuwe voorziening.

De nieuwe voorziening zal alle bestaande berichtencycli ondersteunen. Er wordt nog onderzocht of het mogelijk is om afscheid te nemen van sommige berichtencycli, omdat het efficiënter is om ze te vervangen door afzonderlijke API's (denk aan de Ap01-cyclus t.b.v. plaatsen afnemersindicaties, de Av01-cyclus t.b.v. verwijderen afnemersindicaties, de Lg01-cyclus t.b.v. synchronisatie met BRP-V). Ook wordt onderzocht of het mogelijk is om afscheid te nemen van de verwijsberichten en de vrije berichten. Maar dat is voor de beschrijving van de nieuwe voorziening allemaal niet relevant. In deze LO-wijziging wordt er vanuit gegaan dat alle berichtencycli blijven gehandhaafd, maar worden uitgewisseld via de nieuwe voorziening en voorzien van een nieuwe berichtenstructuur.

Tenslotte wordt de TLV-structuur van berichtendienstberichten ook gebruikt in de webservices VraagAI, VraagPL en de functie ControleerPL van de webservice StuurGBAbericht. Ook die (functies van) webservices zullen worden vervangen door aparte API's.

Omdat niet alle aangesloten partijen op het zelfde moment zullen kunnen overstappen op de BRP Berichten API, wordt er ook een tijdelijke voorziening gerealiseerd die berichten kan vertalen en doorsturen van afzenders die al wel zijn overgestapt naar ontvangers die dat nog niet zijn, en andersom. Deze ‘brug’ is een tijdelijke voorziening die daarom niet in het Logisch Ontwerp BRP zal worden beschreven: de koppelvlakken ervan zijn immers RvIG-intern.

BRP-V zal zelfstandig (onafhankelijk van de brug) kunnen bepalen via welk kanaal (Berichtendienst, StuurGBAbericht of BRP Berichten API) een afnemer gegevens verstrekt moet krijgen. De brug en BRP-V doen dit op basis van element 97.12 Aangesloten op de berichtendienst in tabel 59 BRP-deelnemerstabel. Dit element krijgt daarom een iets andere naam: Aansluiting voor berichtuitwisseling. De mogelijke waardes zijn nu nog 0 (Niet aangesloten) en 1 (Wel aangesloten), maar die wijzigen iets:

0 = StuurGBAbericht
1 = BRP Berichtendienst
2 = BRP Berichten API

Let wel: de huidige betekenis van de waarde 0 (Niet aangesloten op de Berichtendienst) ís al dat een deelnemers is aangesloten op StuurGBAbericht.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Er zijn geen relaties met wijzigingen in wet- en regelgeving.

2.4 Openstaande punten

In deze LO-wijziging wordt alleen nog de BRP Berichten API toegevoegd aan het Logisch Ontwerp BRP, als derde mogelijke manier voor het uitwisselen van berichten, naast de MBS en de webservice StuurGBAbericht. In een latere LO-wijziging zal de MBS worden uitgefaseerd (en de beschrijving ervan dus ook worden verwijderd uit het LO). Nog weer later zal ook de webservice StuurGBAbericht worden uitgefaseerd en wordt ook de beschrijving dáárvan uit het LO verwijderd.

3 Invoering

In deze LO-wijziging wordt enkel nog maar de BRP Berichten API geïntroduceerd als derde oplossing voor het uitwisselen van berichten. Deze wijziging verplicht nog niet tot het gebruik ervan. Vanaf de datum waarop deze wijziging in werking treedt (de planning hiervoor is 1 juli 2025) zal de BRP Berichten API in productie beschikbaar zijn. Dat geldt ook voor de brug en voor BRP-V. Daardoor is het vanaf dat moment in principe voor elke op de MBS aangesloten partij mogelijk om over te stappen op de BRP Berichten API. Om het aantal overstappers een beetje te spreiden stelt RvIG een migratieplan op.

Op 1 juli 2026 mag geen enkele partij meer gebruik maken van de mailboxserver, waardoor deze kan worden uitgezet en afgevoerd. Dat betekent dat alle partijen moeten zijn overgestapt op ofwel StuurGBAbericht, ofwel de BRP Berichten API. Afnemers die dan nog gebruik maken van StuurGBAbericht moeten voor 1 januari 2027 zijn overgestapt op de BRP Berichten API.

4 Gevolgen

4.1 Documentatie

De werking van de BRP Berichten API en de structuur van berichten die via deze API worden uitgewisseld moeten worden beschreven in het Logisch Ontwerp BRP, maar ook in LO BES.

4.2 Gemeenten

Alle gemeenten zijn voor hun bijhoudingstaak aangesloten op de BRP Berichtendienst. Deze LO-wijziging verplicht nog niet tot het overstappen naar de BRP Berichten API, en heeft dus strikt genomen geen directe gevolgen. In overleg met leveranciers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.3 Afnemers

Deze LO-wijziging verplicht nog niet tot het overstappen naar de BRP Berichten API, en heeft dus strikt genomen geen directe gevolgen voor afnemers die gebruik maken van de BRP Berichtendienst. Zij hebben bovendien de keuze om eerst over te stappen op de webservice StuurGBAbericht. In overleg met leveranciers én zelfbouwers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.4 IND

De IND is zowel voor haar taak als bijhouder als voor haar rol als afnemer aangesloten op de BRP Berichtendienst. Deze LO-wijziging verplicht de IND nog niet tot het overstappen naar de BRP Berichten API, en heeft dus strikt genomen geen directe gevolgen. In overleg met leveranciers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.5 Caribische landen en Caribisch Nederland

In Caribische delen van het Koninkrijk wordt geen gebruik gemaakt van de mailboxserver, maar worden berichten uitgewisseld via een FTPS-server. Die berichten hebben echter wel het TLV-formaat dat in het LO BRP en LO BES beschreven is, dus ook de PIVANOBO-systemen zullen moeten worden aangepast. Hiertoe ontstaat echter pas een verplichting als het oude formaat niet meer wordt ondersteund, en dat is in deze LO-wijziging nog niet het geval. In overleg met leveranciers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.6 RvIG-systemen

Bij de RvIG is er een heel aantal systemen dat berichten uitwisselt via de huidige berichtendienst en dat dus op enig moment zal moeten worden aangepast. Hiertoe bestaat echter met de inwerkingtreding van deze LO-wijziging nog géén verplichting. Het betreft de onderstaande systemen:

• RNI (Register Niet-Ingezetenen)
• BRP-V (BRP-Verstrekkingsvoorziening)
• PIVA-V (PIVA-Verstrekkingsvoorziening)
• Daft (Data Analysis & Fingerprint Tool)
• TAPP (Tabellen Applicatie)
• PBK (PIVA-BRP-Koppeling)
• BV BSN (BeheerVoorziening BSN)
• BR (Basisregister Reisdocumenten)
• RPS (Register PaspoortSignaleringen)

Wanneer elk van deze systemen over kan stappen op de BRP Berichten API, moet duidelijk worden uit het migratieplan van RvIG.