Algemene Beschrijving Gegevensuitwisseling Index

Prj. PensionRegister – PensionRegister: algemene beschrijving gegevensuitwisseling

10-Apr-08

Algemene Beschrijving Gegevensuitwisseling Index Algemene Beschrijving Gegevensuitwisseling ...................................................................... 1 Index....................................................................................................................................... 1 Doel van het document........................................................................................................... 2 Scope ...................................................................................................................................... 2 1. Glossarium...................................................................................................................... 2 1.1. Functioneel ............................................................................................................. 2 1.2. Technisch................................................................................................................ 2 1.3. Domeinmodel ......................................................................................................... 3 2. Beschrijving gegevensuitwisseling ................................................................................ 3 2.1. Wijze van uitwisseling ........................................................................................... 3 2.1.1. Actoren ........................................................................................................... 3 2.1.2. Architectuur van de stroom ............................................................................ 3 2.1.3. Algemeen scenario ......................................................................................... 4 2.2. Berichten ................................................................................................................ 4 2.3. XSD’s - Overzicht request/reply en vraag/antwoord ............................................. 5 3. Opvolging en beschikbaarheid ....................................................................................... 5 3.1. Logging .................................................................................................................. 5 3.2. Beschikbaarheid ..................................................................................................... 5 4. Controles ........................................................................................................................ 5 4.1. De controles............................................................................................................ 5 4.1.1. Controle op het gebruik van de dienst............................................................ 5 4.1.2. Controles op het xml-bericht.......................................................................... 5 4.1.3. Controle integratie.......................................................................................... 6 4.1.4. Controle op de geraadpleegde bronnen .......................................................... 6 4.1.5. Controle op de gevraagde gegevens............................................................... 6 4.2. Integratie controle................................................................................................... 6 4.2.1. Blokkerend of niet-blokkerend....................................................................... 6 4.2.2. Periode van integratie controle....................................................................... 7 5. Aangeboden webservices ............................................................................................... 7 5.1. Service ID en Service version ................................................................................ 7 6. Consultatie via Batch...................................................................................................... 7 6.1. Wijze van uitwisseling ........................................................................................... 7 6.2. Bestanden ............................................................................................................... 8 6.3. Exploitatie .............................................................................................................. 8 6.4. Richtlijnen .............................................................................................................. 8

Algemene beschrijving gegevensuitwisseling PK Consultatie.doc

1/9


10-Apr-08

Doel van het document Dit document zal een beschrijving geven van de dienst voor consultatie van het pensioenkadaster. Zowel de KSZ-functionaliteit als de kadering in het geheel zal geschetst worden. Voor specifieke pensioenkadaster-gerelateerde informatie verwijzen we naar de documentatie die door Smals ter beschikking wordt gesteld1.

Scope Het pensioenkadaster, dat fysiek beheerd wordt door de Smals, wordt opengesteld aan instellingen binnen en buiten de sociale zekerheid. Er zullen zowel consultaties voorzien worden als mutaties. Dit document handelt uitsluitend over consultaties. Het kadaster bevat van alle pensioengerechtigden de pensioengegevens die verplicht dienen te worden aangegeven door de pensioeninstellingen. Dit gaat over de rechten van de eerste en tweede pijler, samen met de betalingen die hiermee gepaard gaan. Doelstelling: de gegevens in het PK beschikbaar stellen via consultaties

1. Glossarium 1.1. Functioneel Term Vrager Leverancier Functioneel antwoord Betrokkene, targetSSIN

Verklaring Participerende instelling die een informatieaanvraag doet naar het kadaster om pensioengegevens op te vragen. Participerende instelling die de gevraagde informatie ter beschikking stelt aan een vrager. In casu meestal het pensioenkadaster. Antwoord dat de gevraagde (functionele) gegevens bevat. De persoon over wie informatie uitgewisseld wordt in het kader van zijn/haar pensioen.

1.2. Technisch Term Request (voorlegging) Reply (resultaat) Voorlegger Online/synchroon

Batch/asynchroon

Verklaring Een bericht gericht aan de KSZ of (vanuit de KSZ) aan een pensioeninstelling. Een antwoordbericht uitgaande van de KSZ als antwoord op een request. Een participerende instelling die een voorlegging doet aan de KSZ. Het is de voorlegger die de communicatie initieert. Voorleggingen aan de KSZ die op een online manier gebeuren. Dit wil zeggen: na een voorlegging volgt er in ieder geval onmiddellijk (=op een synchrone manier) een reply. Deze reply bevat hetzij een technisch, hetzij een functioneel antwoord. Een aantal requesten wordt gegroepeerd in één bestand dat wordt verzonden naar de KSZ. De KSZ verwerkt de ontvangen bestanden op regelmatige tijdstippen (bvb dagelijks) en stelt op de zelfde manier een antwoord samen in één bestand dat naar de vragende

1

Deze documentatie bevindt zich ook op de website van de KSZ: http://www.kszbcss.fgov.be/documentation/nl/documentation/Flux%20de%20donn%E9es/flux/Cadastre%20des%20pensions /XSD-Description_V2.6.pdf


2/9


10-Apr-08

instelling gestuurd wordt. Online webservice waarnaar een vrager of leverancier zijn voorlegging stuurt. De unieke referentie per voorlegging naar de KSZ.

Dienst Ticket

1.3. Domeinmodel Een persoon gekenmerkt door een INSZ heeft mogelijk een aantal pensioendossiers. Zo een dossier kan een aanvraag zijn, of reeds een toegekend recht, waarvoor er al dan niet reeds betalingen zijn. Per recht kan men een aangevende, toekennende en betalende instelling identificeren. De gegevens over een pensioendossier bevinden zich in het pensioenkadaster tenminste vanaf het moment dat er betalingen zijn voor het recht.. Bij een consultatie van pensioendossiers worden een aantal zoekcriteria opgegeven. Als antwoord krijgen we het gevraagde zoekresultaat met de informatie over de pensioendossiers. Ook hier verwijzen we naar de documentatie van Smals in verband met het pensioenkadaster voor meer gedetailleerde informatie.

2. Beschrijving gegevensuitwisseling 2.1. Wijze van uitwisseling De gegevensuitwisseling zal hoofdzakelijk via online webservices gebeuren. Er wordt echter ook een batchapplicatie voorzien om aan de behoeften van de instellingen te voldoen. Merk op dat de uitwisseling tussen KSZ en Smals wel steeds via online webservices zal gebeuren!

2.1.1. Actoren • • •

Consulterende instellingen: instellingen van binnen en buiten de sociale zekerheid die het pensioenkadaster wensen te consulteren. KSZ: Kruispuntbank van de Sociale Zekerheid Smals - PK: het pensioenkadaster bevindt zich fysiek bij de Smals.

2.1.2. Architectuur van de stroom

Figure 1: Deployment diagram - overzicht architectuur stroom

De instelling die wenst te consulteren zal dit via de KSZ doen. De KSZ zal op haar beurt de gegevens opvragen bij het pensioenkadaster. Alle uitwisseling van gegevens tussen de kruispuntbank en het pensioenkadaster verloopt via het gebruik van webservices en dus op


3/9


10-Apr-08

een online manier. Het gebruikte protocol is hier SOAP over http(s). Dit is eveneens het geval voor de instellingen die online wensen te consulteren. Voor meer informatie over het protocol voor de online gegevensuitwisseling verwijzen we hier naar de website van de KSZ1. Andere instellingen wensen bijkomend een batch-consultatie: ze stellen een bestand samen met een lijst van consultaties die ze wensen te doen en verzenden dit via een protocol geschikt voor bestandsoverdracht zoals FTP of WebDAV. De KSZ zal vervolgens op geregelde tijdstippen (bvb dagelijks) deze bestanden verwerken en een output-bestand creëren dat op gelijkaardige manier aan de instelling beschikbaar wordt gesteld. Ook voor meer informatie over de batchuitwisseling verwijzen we hier naar de website van de KSZ.

2.1.3. Algemeen scenario Onderstaand schema (zie Error! Reference source not found.) geeft de grote lijnen weer van de uit te voeren logica aan de kant van de KSZ2. Het weergegeven scenario handelt uitsluitend over de gegevensuitwisseling via de KSZ. Het schema is een weerspiegeling van het main succes scenario van de algemene usecase, met toevoeging van enkele uitzonderingen. Het gaat hier over een volledige online consultatie, m.a.w. de klant roept bij de KSZ webservices op.

Figure 2: Sequence diagram: functionaliteit KSZ.

1

http://www.ksz-bcss.fgov.be/Nl/documentation/document_6.htm Het weergegeven scenario handelt uitsluitend over de gegevensuitwisseling via de KSZ. Voorafgaande logica of functionaliteit na de consultatie wordt hier niet in opgenomen. 2


4/9


10-Apr-08

2.2. Berichten De te ontwikkelen diensten zullen de mogelijkheid bieden aan de instellingen om de pensioengegevens die zich bevinden in het pensioenkadaster te raadplegen, zowel rechten als bijhorende betalingen. Hiertoe voorziet men de volgende gegevens in de vraag: ¾ Het INSZ van de persoon waarvan men gegevens wil raadplegen. ¾ De periode waarvoor de opzoeking dient te gebeuren. ¾ Een indicatie of de periode een referentieperiode of een betalingsperiode is. ¾ De gewenste gegevens. ¾ De taal waarin men het antwoord wenst te krijgen In totaal zijn er momenteel 6 vraagstellingen voorzien voor de consultatie, die worden bepaald door (de combinatie van) de volgende criteria ¾ Gevraagde gegevens Enkel rechten Rechten met minimale gegevens betalingen Rechten met maximale gegevens betalingen ¾ Aard van gegevens Pensioenen 1e pijler Pensioenen 1e en 2e pijler

2.3. XSD’s - Overzicht request/reply en vraag/antwoord Zie documentatie die door Smals beschikbaar wordt gesteld. Zie ook de instructies PK te vinden op: https://www.socialsecurity.be/site_nl/Applics/pkcp/documents/instructions_N.pdf en https://www.socialsecurity.be/site_nl/Applics/pkcp/index.htm.

3. Opvolging en beschikbaarheid 3.1. Logging KSZ: volgens de minimale veiligheidsnormen van de KSZ en specifieke regels voor webservices.

3.2. Beschikbaarheid ¾ Smals: beschikbaar van 7u tot 21u op werkdagen. Onbeschikbaarheid is mogelijk buiten deze uren als gevolg van geplande interventies of onvoorziene omstandigheden (geen onmiddellijke interventies mogelijk). ¾ KSZ: de beschikbaarheid van webservices van de KSZ staan beschreven op de website, zie http://www.ksz.fgov.be/Nl/documentation/document_1.htm.

4. Controles 4.1. De controles Wanneer gegevens worden opgevraagd voor een bepaalde persoon dienen de volgende controles te gebeuren.

4.1.1. Controle op het gebruik van de dienst Æ Heeft de instelling machtiging om de webservice(s) bij de KSZ op te roepen? Dit is een generieke controle op het niveau van de beveiligingsinstellingen en toegekende autorisaties door de veiligheidsdienst van de KSZ, teneinde de dienst te mogen oproepen


5/9


10-Apr-08

om gegevens op te vragen. Om toegang tot de webservice te verkrijgen, dient er een veiligheidsaanvraag te worden ingediend (zie website KSZ).

4.1.2. Controles op het xml-bericht Æ Zijn de gegevens in het xml-bericht correct en consistent? Er dienen een aantal controles uitgevoerd te worden op de request1: ¾ TargetSSIN in SSDNRequest moet overeenkomen met TargetSSIN in de ServiceRequest. Er zal bovendien gecontroleerd worden dat het blok “PersonInformation” (waarin TargetSSIN zich bevindt) maximaal éénmaal voorkomt. ¾ MessagePeriod in SSDNRequest moet overeenkomen met Period in de ServiceRequest (ConsultationPeriodType). Ook hier controleren we of er maximaal één Inscription element wordt opgegeven. ¾ Een einddatum mag niet eerder vallen dan een begindatum

4.1.3. Controle integratie Æ Mag de vragende instelling de gegevens van een persoon met een gegeven INSZ opvragen? Controle of er voor een bepaalde persoon gegevens mogen worden opgevraagd. Dit is dus een controle op het niveau van toegang tot de persoonlijke gegevens van een individu. Zie ook punt 4.2 voor een uitgebreide uiteenzetting over de integratiecontrole.

4.1.4. Controle op de geraadpleegde bronnen Æ Bij welke instellingen mag/wenst de vragende instelling gegevens raadplegen? De instelling die de vraag stelt moet toegang hebben om een aantal bronnen te raadplegen, waaronder voornamelijk het kadaster.

4.1.5. Controle op de gevraagde gegevens Æ Welke inhoudelijke gegevens mag/wenst de vragende te raadplegen over de persoon? De gegevens mogen enkel worden opgezocht en teruggegeven wanneer de vragende instelling hiertoe de machtiging heeft. Dit is echt een controle op de inhoud van de gegevens (pensioeninformatie van welke pijlers, informatie over rechten/betalingen, … zie ook 2.2). Dit moet door KSZ geconfigureerd worden per [sector, type instelling en hoedanigheidscode]. Indien geen controle integratie gebeurd voor een bepaalde [sector, type instelling], dient dit uiteraard enkel te worden geconfigureerd voor [sector, type instelling].

4.2. Integratiecontrole 4.2.1. Blokkerend of niet-blokkerend Er kan geconfigureerd kunnen worden dat, wanneer een instelling wenst te consulteren met gegeven • de sector, • de type instelling, een van de volgende acties gebeuren: • blokkerende controle integratie, 1

zie ook de documentatie over het SSDNRequest-formaat op de website van de KSZ: http://www.kszbcss.fgov.be/Nl/documentation/document_6.htm


6/9


10-Apr-08

• niet-blokkerende controle integratie, • géén controle integratie, met hierbij • de geldige hoedanigheidscodes • indicatie of de periode in acht genomen dient te worden of niet en dit zowel voor de sector van de vrager als de sector van het PK onafhankelijk van elkaar. Indien er integratie controle dient te gebeuren, dient men eveneens per sector en type instelling op te geven welke hoedanigheidscodes geldig zijn. Het komt er dus op neer dat voor elke combinatie [sector, type instelling, hoedanigheidscode] van een consulterende instelling, een regel uit onderstaande tabel van toepassing is. Integratiecontrole sector vrager Blokkerend Blokkerend Blokkerend Niet-blokkerend Niet-blokkerend Niet-blokkerend Geen controle Geen controle Geen controle

Integratiecontrole sector PK Blokkerend Niet-blokkerend Geen controle Blokkerend Niet-blokkerend Geen controle Blokkerend Niet-blokkerend Geen controle

4.2.2. Periode van integratie controle De controle integratie wordt uitgevoerd op basis van een door de klant meegegeven integratieperiode. Hierbij wordt op minstens één dag overlap gecontroleerd. De klant toont dus aan voor welke periode de persoon is geïntegreerd waardoor hij gemachtigd is om daarvoor de gegevens op te vragen. De klant van de webservice kan deze integratieperiode meegeven in het gedeelte PersonInformation/Inscription van SSDNRequest (versie 1.1). De controle integratie gebeurt met de hoedanigheidscode die de klant opgeeft in het de SSDNheader (PersonInformation/Inscription).

5. Aangeboden webservices 5.1. Service ID en Service version Om op een consistente manier een dienst en de versie van deze dienst te identificeren, wordt er gebruikt gemaakt van een service ID en service version. Deze gegevens dienen bij elke oproep naar de dienst te worden opgegeven in het xml-bericht. De huidige gegevens zijn: ServiceID: ServiceVersion:

PensionRegisterConsult 20071212


7/9


10-Apr-08

6. Consultatie via Batch 6.1. Wijze van uitwisseling We herhalen dat naast de online consultatie via webservice er een batch-applicatie zal worden voorzien om aan de behoeften van de instellingen te kunnen voldoen. Merk op dat de uitwisseling tussen KSZ en Smals wél steeds via een online webservice gebeurt! Dit wordt nogmaals geïllustreerd in onderstaand schema.

ISS

Smals PK

BCSS online File

FTP

WS

File Figuur 3 Concept gegevensuitwisseling

Zoals beschreven in 2.1.2 verloopt de uitwisseling via een combinatie van batch en online communicatie. De vragende instelling verstuurt een batch-bestand naar de KSZ via een gepast kanaal (FTP of WebDAV). Het PensioenKadaster (Smals) voorziet echter enkel een online consultatie. De aanvragen die zich in het bestand bevinden, zullen daarom een voor een worden behandeld door de KSZ en via een (online) webservice-call naar het PK wordt de benodigde informatie opgevraagd. Alle requests worden met andere woorden een na een geïnjecteerd in het online circuit. De antwoorden van deze webservice-oproepen worden ten slotte opnieuw gebundeld tot één bestand dat als antwoord terug naar de instelling wordt verzonden via het eerder gebruikte medium (FTP of WebDAV). Wanneer de webservice niet beschikbaar is of fatale fouten geeft, zal de batchverwerking worden stopgezet en na een zekere tijd automatisch worden herstart.

6.2. Bestanden Op niveau van KSZ zijn er géén beperkingen op aantal records. Voor een vermindering van de doorlooptijd kunnen zeer grote bestanden eventueel wel worden gesplitst. Het batchframework van de KSZ heeft tools voor het splitsen van bestanden. Dit proces kan echter niet geautomatiseerd worden, zodat het in ieders voordeel is dit niet te hoeven doen. De ISS kunnen eventueel zelf naar hun eigen wensen en behoeften meerdere bestanden aanmaken i.p.v. één groot bestand. De mailboxbestanden volgen het SSDNBatch-formaat, gedocumenteerd op de website van de KSZ. Dit is een XML-bestandsformaat.

6.3. Exploitatie Wanneer een instelling wenst te consulteren via batch, dienen er eerst een aantal afspraken gemaakt te worden per sector en type instelling. • Er moet een keuze worden gemaakt tussen FTP en WebDAV • Er moeten naming-conventions worden afgesproken waaraan de bestanden moeten voldoen die worden verzonden.


8/9


10-Apr-08

• Het formaat van de bestanden is zip of bij voorkeur gzip. Documentatie over de formaten en protocols voor batchverwerking vindt men op de website van de KSZ. De verantwoordelijke voor de opvolging van deze activiteiten is Filip Bauters ([email protected]).

6.4. Richtlijnen Hieronder volgen enkele richtlijnen wat betreft beheer en inplanning van de batchverwerking binnen de KSZ. 1. Voor de algemene beschikbaarheid van de online diensten is het verkiesbaar om batchverwerking uitsluitend ’s nachts te laten doorgaan of op andere momenten waarop de servers minder belast zijn. 2. We wensen overdag voorrang te geven aan de online consultatie van het pensioenkadaster. Door de batchen buiten deze periodes te draaien, wordt de werklast van de webservice aan de kant van Smals ook verdeeld. 3. Voor grote batch-bestanden is het wenselijk de records in parallel te verwerken om op die manier een redelijke doorlooptijd te garanderen. 4. Wanneer de webservice van KSZ of Smals-PK niet beschikbaar is, wordt de batchverwerking automatisch gestopt. Na een vastgestelde tijd wordt de verwerking (automatisch) herstart. 5. Wanneer er een initiële load gebeurt, dient deze tijdig te worden ingepland. Op niveau van KSZ zijn er géén beperkingen op aantal records. Echter om een vlotte en tijdige werking te kunnen garanderen, wordt van de ISS gevraagd deze bestanden te beperken in grootte.


9/9

Algemene Beschrijving Gegevensuitwisseling Index

Recommend Documents