Page History

Versions Compared

Old Version 3

changes.mady.by.user Unknown User (henrik.rikard@capgemini.com)

Saved on 09-10-2017

compared with

New Version Current

changes.mady.by.user Mads Falch Udengaard

Saved on 19-04-2024

Key

This line was added.
This line was removed.
Formatting was changed.

Navitabs

root	Stamdatamodul (SDM)
firsttab	Registerudtrækservices (SDM)
includeroot	true

...

Formål

Dokument målrettet systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.

Driftsvejledningen skal indeholde information om komponentens version, standard placering af logfiler og konfigurationsfiler, eksterne afhængigheder, og evt. krav til genstart af applikationer hvis komponenten bliver ikke-responsiv.

Start/stop vejledning for komponenten beskrives, herunder hvilke andre applikationer der evt. skal genstartes.

Kendte fejlkoder som skrives i logfiler dokumenteres, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning. En generel læsevejledning til logfiler vedlægges.

Det bør angives hvorledes komponenten bedst lader sig overvåge, dvs. en generisk beskrivelse af overvågningen, der ikke er værktøjsafhængig.

Evt. specielle krav til backup beskrives, ligesom procedure ved reetablering af komponenten ud fra backup beskrives.

Table of Contents

...

Omfattede komponenter

Dette dokument omfatter driften af alle Stamdata

...

komponenterne

...

i FMKi projektet.

Listen herunder beskriver hver komponent med type status URL og navnet på filen som skal deployes. Status URL’en kan løbende polles for at checke komponentens status. Status sider er beskrevet mere detaljeret senere i dokumentet.

...

2.1 Stamdata importer komponenter

2.1.1 Stamdata Data Importere

Hver stamdata importer ligger i sin egen WAR fil, hver importer har sin egen overvågnings URL, der enten fortæller om den enkelte importer er operationsdygtig (HTTP 200 OK), eller om der er fejl i importeren (HTTP 500 ERROR), Overvågningssiden vil give et bud på hvad fejlen er, dog bør man kigge i log-filen for at få alle detaljer med.

Type: Batch

Status Url: http://<hostname>:<port>/<komponent-navn>/
Filnavn: <komponent>.war

3 Opdatering til nye versioner

Når nye versioner af Stamdata komponenterne udkommer, vil der medfølge release notes som forklarer database-migrering, rollback-procedure, service vinduer mv. Til installation af første version af stamdata komponenterne henvises til installationsguiden.

4 Daglig Drift

4.1 Stamdata Importere

Stamdataimporterne er en gruppe filparsere og batch jobs som indlæser og vedligeholder data fra forskellige registre og gemmer dem i en MySQL database. Hver importer har sin egen inbox-mappe som automatisk oprettes når servicen startes. Roden for disse inboxmapper er:

<JBOSS_HOME>/domain/data/sdm4/

Komponenten kigger i sin inboxmappe for at se om der kommer nye filer til import. Det er driftens opgave at placere filer i inboxmapperne når tiden er inde for en opdatering. Hvilke filer der skal bruges og hvor ofte registrene skal opdateres er beskrevet i slutningen af dokumentet. Hver inbox er logisk navngivet efter den tilhørende importer. Se afsnittet om overvågning for monitorering af servicen

4.1.1 Fremgangsmåde for indlæsning af nye data

Parserne forventer data at blive lagt i undermapper af deres rod-mappe, f.eks.:

<JBOSS_HOME>/domain/data/sdm4/<importer>/20120822T201121S231/<file.txt>

<JBOSS_HOME>/domain/data/sdm4/<importer>/20120822T201121S231/<file2.txt>

Undermappernes navne er underordnede. De importeres i leksikografisk orden, og det vil derfor være oplagt at lægge dem så undermappernes navne er tidsstempler som vist i eksemplet.

Skulle der ske en fejl under import, vil der blive lagt en fil ved navn

"LOCKED" i parserens inbox, f.eks.:

<JBOSS_HOME>/domain/data/sdm4/<importer>/LOCKED

Parseren vil ikke forsætte før denne fil er slettet manuelt. Fejl-beskeden kan findes i loggen.

4.1.2 Eksempel for import af nye CPR-data

Her en et eksempel på strukturen for en parsers filsystem. I dette tilfælde er det CPR-parseren:

<JBOSS_HOME>/domain/data/sdm4/cprimporter/

Placeres filen ’D100312.L431101’ (som er en typisk CPR Person fil) i inputmappen begynder parseren at stabilisere data. Man kan gå ind på komponentens monitoreringsside for at se status for import:

http://<hostname>:<port>/cprimporter/status

Her vil man kunne se om CPRimporteren kører, hvornår CPRimporteren sidst har kørt, og hvilken status den har.

5 Enkeltopslag i registre

Stamdataservicen tilbyder en service til såkaldte enkeltopslag i følgende registre:

Autorisationsregistret
CPR-registret

Enkeltopslag i et af de ovennævnte registre foregår som et webservice kald til stamdataservicen på NSP med angivelse af søgekriterier. De konkrete parametre og eventuelle særlige forhold der gør sig gældende for kald til enkeltopslags-snitfladen på stamdataservicen er beskrevet i de følgende afsnit.

5.1 Forespørgsler og dataformat

Enkeltopslags-snitfladen er udstillet som en DGWS 1.0.1 identitetsbaseret webservice. Adgang til enkeltopslagsservices forudsætter en aftale med NSP-operatøren (adgang styres på CVR-nummer). Metoderne for de udstillede registre er beskrevet i separate WSDL-filer, der kan rekvireres ved henvendelse til NSP-operatøren.

Fælles for de udstillede enkeltopslagsservices er at der kræves STS-signerede system ID-kort (dvs. DGWS niveau 3).

5.2 Enkeltopslag i autorisationsregistret

...

[2] Servicen giver et øjebliksbillede af personens autorisationer, dvs. udløbne og fremtidige autorisationer returneres ikke.

...

Uddannelseskode

...

Faggruppenavn

...

4498

...

Optiker

...

5151

...

Fysioterapeut

...

5153

...

Ergoterapeut

...

5155

...

Fodterapeut

...

5158

...

Radiograf

...

5159

...

Bioanalytiker

...

5166

...

Sygeplejerske

...

5175

...

Jordemoder

...

5265

...

Kiropraktor

...

5431

...

Tandplejer

...

5432

...

Klinisk Tandtekniker

...

5433

...

Tandlæge

...

5451

...

Klinisk diætist

...

7170

...

Læge

...

9495

...

Bandagist

...

NSP komponenter

Stamdata Kopi-Register Service

Type: Webservice
Status Url: <serverurl>/stamdata-batch-copy-ws/status
Filnavn: stamdata-batch-copy-ws.war
Type: Webservice
Status Url: <serverurl>/stamdata-authorization-lookup-ws/status
Filnavn: stamdata-authorization-lookup-ws.war
Type: Webservice
Status Url: <serverurl>/stamdata-cpr-ws/status
Filnavn: stamdata-cpr-ws.war
Type: Webservice
Status Url: <serverurl>/stamdata-yder-lookup-ws/status
Filnavn: stamdata-yder-lookup-ws.war
Type: REST service
Status Url: <serverurl>/stamdata-personinformation/status
Filnavn: stamdata-personinformation.war

Stamdata AutorisationsregisteretEnkeltopslag

Stamdata CPREnkeltopslag

Stamdata YderregisterEnkeltopslag

Opdatering til nye versioner

Daglig Drift

Wildfly jndi datasource

Wildlfy skal være opsat med en jndi datasource til mysql, den kan fx se ud som nedenfor:

wildfly/standalone/configuration/standalone.xml

<connection-url>jdbc:mysql://localhost:3306/sdm_warehouse</connection-url>

<driver>mysql</driver>

<pool>

<min-pool-size>10</min-pool-size>

<initial-pool-size>10</initial-pool-size>

<max-pool-size>100</max-pool-size>

<allow-multiple-users>true</allow-multiple-users>

</pool>

<check-valid-connection-sql>select 1</check-valid-connection-sql>

<validate-on-match>false</validate-on-match>

<background-validation>false</background-validation>

</validation>

<user-name>sdm</user-name>

<password>papkasse</password>

</security>

<idle-timeout-minutes>1</idle-timeout-minutes>

</timeout>

</datasource>

<driver-class>com.mysql.jdbc.Driver</driver-class>

</driver>

</drivers>

</datasources>

Jndi navnet indsættes i de enkelte komponeneters sdm.JNDIName.

Stamdata Autorisation Enkeltopslag

Konfiguration af Autorisation Enkeltopslag

Konfigurationsfil kan finde på (oprettet i driften):

$JBOSS_HOME/server/default/conf/stamdata-authorization-lookup-ws.properties

Properties

db.connection.jdbcUrl	Udgået - Skal være tom
db.connection.username	Udgået - Skal være tom
db.connection.password	Udgået - Skal være tom
sdm.JNDIName	VIGTIG Denne skal være sat Jndi datasource navn fx: java:/SDMDS
security	Enten dgws eller dgwsTest. Hvis dgwsTest anvendes accepterer servicen id kort underskrevet af Test STS’. Dette kan bruges til f.eks. Load Test. (dgws)
dk.nsi.stamdata.security.allowed.actors	Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser
allowed.idws.audience	Skal være tom (Borgerkald ikke tilladt)

Til rettighedsstyring benyttes tabellen whitelist_config i Stamdata databasen. For hver klient der skal have adgang laves en ny række med component_name 'SDM' og klientens CVR i cvr kolonnen. (Dette har tidligere været en kommasepareret liste af SSN i stamdata-authorization-lookup-ws.properties så hvis der findes en eksisterende liste konfigureret i driften skal denne liste migreres til rækker i whitelist_config tabellen.

Stamdata Yderregister Enkeltopslag

Konfiguration af Yderregister Enkeltopslag

Konfigurationsfil kan finde på (oprettet i driften):

$JBOSS_HOME/server/default/conf/stamdata-yder-lookup-ws.properties

Properties

db.connection.jdbcUrl	Udgået - Skal være tom
db.connection.username	Udgået - Skal være tom
db.connection.password	Udgået - Skal være tom
sdm.JNDIName	VIGTIG Denne skal være sat Jndi datasource navn fx: java:/SDMDS
security	Enten dgws eller dgwsTest. Hvis dgwsTest anvendes accepterer servicen id kort underskrevet af Test STS’. Dette kan bruges til f.eks. Load Test. (dgws)
dk.nsi.stamdata.security.allowed.actors	Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser,HealthCareProfessional
allowed.idws.audience	Skal være tom (Borgerkald ikke tilladt)

Stamdata Kopi-Register-Service og Stamdataregister Fleropslagsservice

Konfiguration

Konfigurationsfiler kan findes på https://svn.nspop.dk/svn/components/sdm/trunk/ under /compose/configuration. Der anvendes følgende konfigurationsfiler:

SKRS: stamdata-batch-copy-ws-krs.properties
SRFS: stamdata-batch-copy-ws-rfs.properties

Properties

db.connection.jdbcUrl	Udgået - Skal være tom
db.connection.username	Udgået - Skal være tom
db.connection.password	Udgået - Skal være tom
sdm.JNDIName	VIGTIG Denne skal være sat Jndi datasource navn fx: java:/SDMDS
dk.nsi.stamdata.security.allowed.actors	Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser
allowed.idws.audience	Skal være tom (Borgerkald ikke tilladt)

Rettighedsstyring

I kopi-register servicen (KRS) og fleropslagsservicen (RFS) kan alle stamdatas registre kopieres via en webservice. Det er derfor vigtigt at kunne styre meget nøjagtigt hvilke data en klient har adgang til.

NB. Rettighedsstyring i KRS ligger i databasen og er besværligt at styre manuelt. Oprindeligt havde KRS en tilhørende GUI til rettighedsstyring. GUI’en eksisterer ikke længere, og pga. den fint kornede rettighedsstyring er det lidt akavet. Der findes pt. ikke nogen måde at enkelt give en klient adgang til alle datatyper i et register eller en datatype i flere versioner.

Opretning af ny bruger

Log ind i stamdatas database og derefter:

INSERT INTO Client (name, subjectSerialNumber) VALUES (’<NAVN>’, ’CVR:12345678-UID:1234’);

SubjectSerialNumber feltet skal indeholde et subject serial number som vist i eksemplet herover. Det er underordenet hvilken UID der står i feltet, brugere identifiseres udelukkende på CVR nummeret. Dette felt er udelukkende af et subject serial number af historiske årsager.

Ændring af en brugers rettigheder

Noter id fra den nye bruger. Id’et skal bruges til at bestemme brugerens rettigheder:

SELECT id FROM Client WHERE name = ’<NAVN>’;

INSERT INTO Client_permissions (client_id, permissions) VALUES (<ID>, ’<RETTIGHED>’);

En <RETTIGHED> består af fire komponenter: register, registerversion, datatype og datatypeversion. Registerversion er valgfri af hensyn il bagudkompatibilitet. Indholdet af <RETTIGHED> er på formen <register>(/<registerversion>)?/<datatype>/<version>, hvor registerversion som sagt er valgfri.

Whitelist til alle datatyper, i alle versioner af registret: <register>/
Whitelist til alle versioner for specifik datatype: <register>/<datatype>/
Whitelist til specifik version: <register>/<datatype>/<version>
Whitelist til alle datatyper i specifik version af registret: <register>/<registerversion>

Eksempel på en liste af rettigheder

Feltet <RETTIGHED> skal indeholde en streng der beskriver datatypen der skal whitelistes, for cpr register person tabellen vil det være:

’cpr/person/v1’ - Dette vil give klienten ret til at hente datatypen Person i version1.

’cpr/person/’ - Dette vil give klienten ret til at hente datatypen Person i alle kendte version.

’cpr/’ - Dette vil give klienten ret til at hente alle kendte datatypen i alle kendte version i cpr regisret

'cpr/v2/person/v2' - Dette vil give klienten ret til at hente datatypen Person i version 2 i version 2 af cpr-registret.

Se dokumentationen for registerspecifikationer for navne på de respektive data type navne

Konfiguration af opslagskolonner i SRFS

SRFS-tjenesten gør det muligt at lave opslag i stamdata ud fra en liste af id'er. For at sådanne opslag kan laves, skal det være angivet i SKRSColumns-tabellen hvilken kolonne der skal anvendes som nøgle for en tabel. Til dette formål bruges kolonnen isLookupColumn. Kolonnen indeholder en boolsk værdi, som angiver at tableColumnName skal bruges som nøgle ved SRFS-opslag. Hvis man f.eks. ønsker at tilbyde opslag på Person-objekter i CPR-registret, skal det angives at kolonnen CPR i tabellen Person skal bruges som nøgle. Bemærk at der kun er understøttelse for at angive én nøglekolonne per tabel.

For at kunne konfigurere SRFS-opslag for en datatype, skal man kende følgende:

Id på det ViewMap, der skal tilbydes opslag på.
Navn på den tabelkolonne, der skal bruges som nøglekolonne.

For at finde ViewMap-id'et skal man kende følgende:

Hvilket register datatypen befinder sig i. (Fremgår af SKRSViewMapping.register)
Hvad datatypen hedder (Fremgår af SKRSViewMapping.datatype)
Hvilken version og registerversion af datatypen der skal tilbydes opslag på (Fremgår af SKRSViewMapping.version og SKRSViewMapping.registerVersion)

For at finde navnet på nøglekolonnen, inspiceres tabeldefinitionen for den tabel der skal tilbydes opslag i.

Nedenfor er vist to eksempler på, hvordan man konfigurerer en kolonne som nøglekolonne.

Code Block

language	sql

UPDATE SKRSColumns set isLookupColumn = 1 where viewMap = (SELECT idSKRSViewMapping FROM SKRSViewMapping WHERE register = 'cpr' AND datatype = 'person' and version = 1 and registerVersion = 1) AND tableColumnName = 'CPR';
UPDATE SKRSColumns set isLookupColumn = 1 where viewMap = (SELECT idSKRSViewMapping FROM SKRSViewMapping WHERE register = 'yderregister' AND datatype = 'yder' and version = 3 and registerVersion = 1) AND tableColumnName = 'YdernrYder';

I eksemplet opsættes opslag i CPR-registrets Person-tabel ud fra kolonnen 'CPR', samt opslag i yderregistrets Yder-tabel ud fra kolonnen 'YdernrYder'. Versionsnumrene passer til det lokale udviklingsmiljø. Der kan være andre versionsnumre i test og produktion.

CPR-Services

Denne komponent skal deployes på NSP’erne.

Konfiguration

Konfigurationsfil kan finde på (oprettet i driften):

$JBOSS_HOME/server/default/conf/stamdata-cpr-ws.properties

db.connection.jdbcUrl	Udgået - Skal være tom
db.connection.username	Udgået - Skal være tom
db.connection.password	Udgået - Skal være tom
sdm.JNDIName	VIGTIG Denne skal være sat Jndi datasource navn fx: java:/SDMDS
dk.nsi.stamdata.security.allowed.actors	Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=Citizen,SystemUser,HealthCareProfessional
allowed.idws.audience	Det tilladte audience på indkommende idws requests f.eks.: https://fsk
field.default.<felt>	Default værdier for felter der er markeret som "unreliable" Formatet for datoer er 'yyyy-MM-dd HH:mm:ss' Indsættes værdien <trhow> vil anvenderen få en fejl retur såfremt feltet er markeret som unreliable. Der skal være en default værdi for alle følgende felter: fornavn, mellemnavn, efternavn, coNavn, lokalitet, vejnavn, bygningsnummer, husnummer, etage, sideDoerNummer, bynavn, postnummer, postdistrikt, status, statusDato, gaeldendeCPR, stilling, vejKode, kommuneKode, navnebeskyttelseslettedato, navnebeskyttelsestartdato, navnTilAdressering, vejnavnTilAdressering, foedselsdatoMarkering, foedselsdato

Statsborgerskabs mapning

Statsborgerskabsland for grænsegængere kan ske kun at være udfyldt med kode. Landet mappes i det tilfælde fra en liste, som indeholder landekode=landenavn. Listen findes default i filen country-mapper-internal.properties, som er bygges ind i komponenten.

Filen (UTF-8) er skabt 11. august 2022 med data fra siden https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes, søjlerne "country name" og "alfa-2 code".

Der er muligt at overstyre denne fil, med en anden: country-mapper-external.properties

country-mapper-external.properties skal findes på (oprettet i driften):

$JBOSS_HOME/standalone/configuration/country-mapper-external.properties

Eksempel på country-mapper-internal.properties indhold (start af filen):

Code Block
AD=Andorra AE=United Arab Emirates (the) AF=Afghanistan AG=Antigua and Barbuda AI=Anguilla AL=Albania AM=Armenia AO=Angola

Rettighedsstyring

Offentlige myndigheder skal whitelistes for at kunne hente data uden adresse og navnebeskyttelse.

Rettighedsstyring foregår ved at tilføje myndighedens CVR nummer til database tabellen whitelist_config.

Så for at whiteliste myndighed med CVR 12345678 køres følgene SQL op i mod databasen:

INSERT INTO whitelist_config(component_name, cvr) VALUES('SDM','12342678');

Bemærk værdien af component_name skal være ’SDM’ pånær for AuthorizationCodeLookup hvor den er SDMAuthorizationCode. For SCES er mulige component_name-værdier beskrevet i anvenderguidens afsnit 5.4.2.

PersonInformation

Denne komponent skal deployes på NSP’erne.

Konfiguration

Konfigurationsfil kan finde på https://svn.nspop.dk/svn/components/sdm/trunk/compose/configuration/stamdata-personinformation.properties

db.connection.jdbcUrl	Udgået - Skal være tom
db.connection.username	Udgået - Skal være tom
db.connection.password	Udgået - Skal være tom
sdm.JNDIName	VIGTIG Denne skal være sat Jndi datasource navn fx: java:/SDMDS
service.endpoint	Endpoint for servicen. Anvendes som del af URL i openapi dokumentationen. F.eks. http://localhost:8080

Backup

Alle tabeller i stamdatas database skal have daglig backup. Backup må ikke gemmes længere end 2 år pga. lovkrav.

Da der er tale om store mængder data er det vigtigt at holde for øje at det kan tage meget lang tid at genetablere et database image for stamdata.

Overvågning

Statussider

For hver komponent er der en status-side som periodisk kan kaldes for at tjekke om servicen kører. Hvis en service ikke kan overvåges via en simple status side vil det fremgå af dens driftsdokumentation.

Status sider fungerer over HTTP, og har følgende statuskoder:

200	Alt er OK.
500	Der er opstået en fejl, og driften bør undersøge komponentens log for fejlmeddelelser. Kan fejlen ikke opklares simpelt, bør driften kontakte support.

URL’s for status sider kan findes tidligere i dette dokument.

Speciel overvågning af SOR og SOR-Relationer importerne

Da SOR behandles af to forskellige importere, er det et problem for datakonsistensen, hvis den ene af disse to parsere fejler på et datasæt som den anden parser ikke fejler på.

Skulle en af de to parsere afvise en import, er det en hastesag at få rettet den fejl der resulterer i afvisningen i den anden parser, så de to registre kan komme i sync så hurtigt som muligt.

Logning

Alle Stamdata komponenter logger vha. JBoss’s logging api. Da logging API’en i JBoss 6.0.Final er defekt har komponenterne ikke hver sin logfil. Alle log entries bliver logget til:

$JBOSS_HOME/server/default/log/server.log

Fejlsøgning

Opstår der en fejlsituation i en komponent, skal driften undersøge den pågældende komponents logfil for loghændelser på ERROR-niveau. F.eks. i tilfælde af at komponenten ikke kan forbinde til databasen. Visse andre fejl er ikke-kritiske. Det vil sige at komponenten kan forsætte med at fungere. De bliver også logget på ERROR-niveau da der hændelsen bør undersøges. Komponenterne vil i så vid udstrækning som muligt forsøge at forsætte på trods af fejl.

Anvendes Splunk til indeksere logfiler bør alle de konfigurerede filer indekseres. Der kan opsættes alarmer i Splunk som aktiveres hvis en hændelse med ERROR-niveau logges. Dette niveau anvendes udelukkende ved alvorlige fejl. Der udover er også hændelser på WARN-niveau interessante da de f.eks. fortæller om folk forsøger at tilgå servicen uden tilladelse ol.

Liste af Registre

Hvert register har sin egen registerspecifikations fil som ligger i register mappen sammen med dokumentationen.

Stamdata Filter Management Service (SFMS)

Konfiguration

Konfigurationsfiler kan findes på https://svn.nspop.dk/svn/components/sdm/trunk/ under /compose/configuration/filter-management-ws-sfm.properties.

Properties

dk.nsi.stamdata.security.allowed.actors	Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser
allowed.idws.audience	Skal være tom
db.connection.jdbcUrl	Udgået - Skal være tom
db.connection.username	Udgået - Skal være tom
db.connection.password	Udgået - Skal være tom
sdm.JNDIName	java:jboss/datasources/SDMDS
service.endpointPersonInformation	http://<url>:<port>/stamdata-personinformation

5.2.1 Eksempel: Én eller flere autorisationer

Nedenfor ses et ”solskinsscenarie”, hvor der forespørges på en sundhedsfaglig, der har en enkelt gyldig autorisation.

Code Block

language	java
title	Forespørgsel
collapse	true

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
    …
  </S:Header>
  <S:Body>
    <AuthorizationRequestStructure xmlns="http://nsi.dk/-/stamdata/3.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
      <cpr>1111122222</cpr>
    </AuthorizationRequestStructure>
  </S:Body>
</S:Envelope>

Code Block

language	java
title	Svar
collapse	true

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
         …
  </S:Header>
  <S:Body>
    <AuthorizationResponseStructure xmlns="http://nsi.dk/-/stamdata/3.0" >
      <cpr>1111122222</cpr>
      <firstName>Peter</firstName>
      <lastName>Andersen</lastName>
      <authorization>
        <authorizationCode>B1114</authorizationCode>
        <educationCode>2131</educationCode>
      </authorization>
    </AuthorizationResponseStructure>
  </S:Body>
</S:Envelope>

I eksemplet er Peter Andersen tilknyttet CPR 1111122222, og han har en autorisation.

5.2.2 Eksempel: Ingen gyldige autorisationer

Forespørges der på en ikke-eksisterende person eller en person, der ikke har en gyldig autorisation, svares der blot med en tom AutorizationResponseStructure.

I eksemplet nedenfor er headere udeladt, og der henvises til eksemplet i afsnit 5.2.1 for en tilsvarende forespørgsel hvor headere er vist.

Code Block

language	java
title	Forespørgsel
collapse	true

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
    …
  </S:Header>
  <S:Body>
    <AuthorizationRequestStructure xmlns="http://nsi.dk/-/stamdata/3.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
      <cpr>1111122244</cpr>
    </AuthorizationRequestStructure>
  </S:Body>
</S:Envelope>

Code Block

language	java
title	Svar
collapse	true

<soapenv:Envelope …>
  <soapenv:Header>…</soapenv:Header>
  <soapenv:Body>
    <AuthorizationResponseStructure xmlns="http://nsi.dk/-/stamdata/3.0">
  <cpr>1111122222</cpr>
</AuthorizationResponseStructure> 
</soapenv:Body>
</soapenv:Envelope>

Da der ikke er nogen tilknyttede autorisationer, returneres en tom AuthorizationResponseStructure uden angivelse af for- og efternavn.

5.3 CPR-registret: Det Gode CPR-opslag

Stamdataservicen udstiller mulighed for enkeltopslag i CPR-registret gennem en implementering af ’Det Gode CPR-opslag’ som specificeret af MedCom (http://www.medcom.dk/wm110491).

5.3.1 WSDL

WSDL-filer for servicen kan findes på medcoms svn her:

http://svn.medcom.dk/svn/drafts/CPR-opslag/trunk/CPR-opslag/wsdl/

Vær opmærksom på, at der tilføjes Den Gode WebService-felter på, så det vil nok være nemmere at hente wsdl direkte fra servicen. Dette gøres ved at kalde endpoint med ?wsdl tilføjet sådan: http://endpointurl?wsdl

Denne indeholder de tilføjede felter.

Sidst men ikke mindst kan de også hentes med dgws-felter direkte fra leverandørens svn her:

https://fisheye.nspop.dk/browse/public/components/sdm/latest/code/nsp/cpr-ws/src/main/webapp/WEB-INF/wsdl

5.3.2 Endpoints

Det gode CPR-opslag er udstillet i version 1.0.0 og version 1.0.2, som er tilgængelige på hver deres endpoints.

For 1.0.0:

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag

For 1.0.2

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.2

Det anbefales at køre på version 1.0.2, da ikke alle personer kan hentes i 1.0.0 uden valideringsfejl.

5.3.3 Mangelfuldt datagrundlag

Datagrundlaget kan i nogle tilfælde mangle værdier som er påkrævet af wsdl skemaet, hvis dette er tilfældet vil felterne udfyldes med en erstatningsværdi.

For PersonInformationStructureType drejer sig om følgende felter:

...

Felt

...

Erstatningsværdi

...

PersonGivenName

...

UKENDT

...

PersonSurnameName

...

UKENDT

...

PersonNameForAddressingName

...

UKENDT

...

PostCodeIdentifier

...

0000

...

DistrictName

...

UKENDT

...

MunicipalityCode

...

0000

...

StreetCode

...

0000

For AssociatedGeneralPractitionerStructure er det følgende felter:

Felt	Erstatningsværdi
PostCodeIdentifier	0000
DistrictName	UKENDT

...

Hvis der ikke kan findes en tilknyttet læge i datagrundlaget vil AssociatedGeneralPractitionerStructure være udfyldt med følgende værdier:

...

Felt

...

Erstatningsværdi

...

AssociatedGeneralPractitionerIdentifier

...

000000

...

AssociatedGeneralPractitionerOrganisationName

...

UKENDT

...

DistrictName

...

UKENDT

...

EmailAddressIdentifier

...

UKENDT@example.com

...

PostCodeIdentifier

...

0000

...

StandardAddressIdentifier

...

UKENDT

...

TelephoneSubscriberIdentifier

...

00000000

5.3.4 Fejlfyldt CPR-data

Udover ovenstående erstatningsværdier kan der også være tale om data, som ikke har kunnet indlæses pga. fejlfyldt kildedata. Det kan fx være en dato, der ikke har kunne parses. Hvis der laves opslag på en person, som har fejlfyldt data vil der blive indsat erstatningsværdier for de felter, der er markeret som fejlfyldte eller der vil blive sendt en soap-fejl med beskeden ”Data for personen er markeret som upålideligt”.

Hvorvidt der kommer en fejl eller der anvendes erstatningsværdier og hvad disse vil være sat til, afhænger af konfigurationen, se mere på http://www.nspop.dk

5.3.5 Navne- og adressebeskyttelse

For CPR-opslag gælder det generelt, at hvis en record i CPR-registret er markeret med navne- og adressebeskyttelse, da vil output være beskyttet ud fra følgende regler:

...

Søgning via

...

Hvilke data er beskyttet

...

getPersonInformation

...

Alle output-felter på nær CPR-nummer

...

getPersonWithHealthCareInformation

...

Alle output-elementer dog ikke:

CPR-nummer
Information om tilknyttet læge
Information om sygesikringsgruppe.

...

getPersonDetails

...

Output er ikke beskyttet

Beskyttelse af data sker ved indsættelse erstatningsværdier, værdierne som der bliver erstattet med er afhængig af hvilken XSD type elementet har (dvs. der tages hensyn til de navnebeskyttede felters skema-definition).

Hvorvidt en person er adressebeskyttet kan i svaret bestemmes ud fra ”PersonInformationProtectionIndicator” uanset om output er beskyttet eller læsbart.

5.4 CPR-registret: getPersonDetails

Stamdataservicen udstiller endvidere en variant af ’Det Gode CPR-opslag’, der kan anvendes til søgninger i CPR-registret med følgende input.

CPR-nummer
liste af CPR-numre
fødselsdato
navn

Servicen har en enkelt snitflade: getPersonDetails, der er implementeret i forskellige udgaver og muliggør forskellige typer af søgninger. I de følgende afsnit er kaldmulighederne beskrevet med tilhørende eksempler.

Servicen er formelt beskrevet i WSDL og XSD-skemaer, der kan findes her:

Code Block
<src-root>/Dokumentation/bilag/StamdataPersonLookupService/

Eller direkte på driftsoperatørens SVN:

...

Servicen tager hensyn til navnebeskyttelse, og det anbefales at undersøge elementet PersonInformationProtectionIndicator for om værdien er true, da personen i så fald er navnebeskyttet.

5.4.1 Endpoints

På samme måde som DetGodeCprOpslag findes der to endpoints:

http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup

samt

http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup-1.0.1

...

Det anbefales man anvender StamdataPersonLookup-1.0.1 i nye projekter, wsdl-filerne til denne kan findes i PERSONLOOKUP_1.0.1-mappen.

5.4.2 Mangelfuld data og fejlfyldt CPR-data

Se 5.3.3: Mangelfuldt datagrundlag og 5.3.4: Fejlfyldt CPR-data

5.4.3 Eksempel 1: getPersonDetails(<Personnummer>)

I denne variant af getPersonDetails søges på et specifikt CPR-nummer. Findes personen i CPR-registret, returneres de tilhørende CPR-informationer. Findes personen ikke i CPR-registret, returneres et tomt svar.

I dette eksempel vises et kald, og en række mulige svar, afhængigt af søgeresultatet.

Code Block

language	java
title	Kald 1: (Opslag vha. CPR-nummer)
collapse	true

<stam:PersonLookupRequest>
  <CivilRegistrationNumberPersonQuery>
    1234567890
  </CivilRegistrationNumberPersonQuery>
</stam:PersonLookupRequest>

Giver anledning til følgende svar:

Code Block

language	java
title	Svar 1: (Personen blev fundet)
collapse	true

<stam:PersonLookupResponse>
  <ns:PersonInformationStructure>
    <ns1:RegularCPRPerson>
      <ns1:SimpleCPRPerson>
        <ns2:PersonNameStructure>
          <ns3:PersonGivenName>Peter</ns3:PersonGivenName>
          <ns3:PersonSurnameName>Andersen</ns3:PersonSurnameName>
        </ns2:PersonNameStructure>
        <ns1:PersonCivilRegistrationIdentifier>
          1234567890
        </ns1:PersonCivilRegistrationIdentifier>
        …
      </ns1:SimpleCPRPerson>
      …
      <ns6:PersonInformationProtectionIndicator>
        false
      </ns6:PersonInformationProtectionIndicator>
      </ns1:RegularCPRPerson>
    <ns:PersonAddressStructure>…</ns:PersonAddressStructure>
  </ns:PersonInformationStructure>
</stam:PersonLookupResponse>

Hvis søgningen ikke giver et positivt resultat, returneres der et tomt svar:

Code Block

language	java
title	Svar 2: (Personen blev ikke fundet)
collapse	true

<stam:PersonLookupResponse />

...

getPersonDetails understøtter også søgninger på personnavn. Svar ved kald til denne variant er strukturelt identiske med svar ved søgninger på CPR-nummer eller liste af CPR-numre, og der henvises til disse eksempler for svarmuligheder.

Code Block

language	java
title	Søgning på personnavn
collapse	true

<stam:PersonLookupRequest>
  <NamePersonQuery>
    <ns:PersonGivenName>Anne</ns:PersonGivenName>
    <!-- Det er ikke nødvendigt at angive mellemnavn -->
    <ns:PersonMiddleName>Søgaard</ns:PersonMiddleName>
    <ns:PersonSurnameName>Petersen</ns:PersonSurnameName>
  </NamePersonQuery>
</stam:PersonLookupRequest>

Angives mellemnavnet ikke, ignoreres det og records med matchende for- og efternavn returneres. Se kaldet med en liste af CPR-numre for at se scenariet, hvor flere personelementer returneres.

5.4.5 Kald 3: (Opslag vha. fødselsdato)

getPersonDetails understøtter også søgninger på fødselsdato. Svar ved kald til denne variant er strukturelt identiske med svar ved søgninger på CPR-nummer eller liste af CPR-numre, og der henvises til disse eksempler for svarmuligheder:

Code Block

language	java
title	Søgning på fødselsdato
collapse	true

<stam:PersonLookupRequest>
    <BirthDatePersonQuery>1991-09-22</BirthDatePersonQuery>
</stam:PersonLookupRequest>

...

getPersonDetails understøtter også søgninger med en liste af CPR-numre som input. For hvert CPR-nummer på listen returneres CPR.informationerne eller et tomt svar, hvis CPR-nummeret ikke findes.

Code Block

language	java
title	Søgning på liste med CPR-numre
collapse	true

<stam:PersonLookupRequest>
  <CivilRegistrationNumberListPersonQuery>
    <CivilRegistrationNumber>1111111111</CivilRegistrationNumber>
    <CivilRegistrationNumber>2222222222</CivilRegistrationNumber>
    <CivilRegistrationNumber>3333333333</CivilRegistrationNumber>
  </CivilRegistrationNumberListPersonQuery>
</stam:PersonLookupRequest>

Code Block

language	java
title	Svar 4: (Resultat med flere records)
collapse	true

<stam:PersonLookupResponse>
  <ns:PersonInformationStructure>
    …
    <ns:PersonCivilRegistrationIdentifier>
      1111111111
    </ns:PersonCivilRegistrationIdentifier>
    …
  </ns:PersonInformationStructure>
  <ns:PersonInformationStructure>
    …
    <ns:PersonCivilRegistrationIdentifier>
      3333333333
    </ns:PersonCivilRegistrationIdentifier>
    …
  </ns:PersonInformationStructure>
</stam:PersonLookupResponse>

5.5 CPR-Abonnementsservice

Stamdata tilbyder mulighed for at man for en liste af CPR-numre kan abonnere på ændringer i CPR-registret. Brugen af abonnementsservicen er skarpt opdelt i to snitflader:

Vedligeholdelse af abonnementslisten (tilføj og slet CPR-numre)
Udtræk af ændringer for CPR-numrene på listen

Vedligeholdelsen af abonnementslisten er implementeret ved hjælp af den Generiske Opsamlingsservice (GOS), der er en NSP-baseret service til opsamling af informationer af forskellig art. Til brug for abonnementsservicen anvendes en særlig opsamlingstype, der giver mulighed for dels at tilføje, dels at slette CPR-numre fra listen. I afsnittet nedenfor er det angivet, hvordan dette gøres i praksis.

Udtræk af ændringer for CPR-numrene på abonnementslisten fås ved kald til abonnementsservicen, der overvåger CPR-registret og returnerer en liste af CPR-numre, der har fået opdateret oplysninger i CPR-registret siden sidste udtræk. I kaldet kan det også angives at svaret skal indeholde de komplette CPR-oplysninger for de berørte CPR-numre.

Image Removed

Figur 1 – Skitse af det samlede flow ved brug af abonnementsservicen

Detaljeret information om indholdet af forespørgsler og svar for de enkelte kald findes i de følgende afsnit.

5.5.1 Vedligehold af abonnementslisten

Tilføjelse eller sletning af et CPR-nummer på abonnementslisten håndteres ved et kald til GOS med et request, hvor payload overholder dette skema:

Code Block
<src-root>/common/src/main/resources/xsd/stamdata/subscription.xsd

Ved tilføjelse af et CPR-nummer til abonnementslisten benyttes elementet subscribe som payload. Ved sletning af et CPR-nummer fra abonnementslisten benyttes elementet unsubscribe.

Et eksempel på payload ved tilføjelse af CPR-nummer 1234567890 ser således ud:

Code Block

language	java
title	Eksempel på tilføjelse af CPR-nummer
collapse	true

<subscribe xmlns="http://nsi.dk/stamdata/2011/09/">
   <cpr>1234567890</cpr>
</subscribe>

...

Code Block

language	java
title	Eksempel på sletning af CPR-nummer
collapse	true

<unsubscribe xmlns="http://nsi.dk/stamdata/2011/09/">
   <cpr>1234567890</cpr>
</unsubscribe>

...

Code Block
<src-root-til-Behandlingsrelations-servicen>/doc/gos/Guide til Anvendere.docx

5.5.2 Udtræk af ændringer i CPR-data

Der findes to metoder til at få ændringer i CPR-data for CPR-numrene på abonnementslisten:

getChangedCprs, der returnerer en liste af CPR-numre, for hvilke CPR-data er ændret
getSubscribedPersonDetails, der returnerer samme liste som getChangedCprs, men som også indeholder CPR-oplysninger for hvert CPR-nummer på listen

Metoderne tager samme input, nemlig en valgfri angivelse af et tidspunkt, hvorfra ændringer skal registreres, men har forskellig output som beskrevet ovenfor. Angives der ikke et tidspunkt, holder abonnementsservicen selv regnskab med hvornår metoderne er kaldt sidst. Hvis der ved første udtræk af ændringer ikke angives et tidspunkt, sætter servicen selv tidspunktet til en fortidig værdi (1. januar 1970).

Highlight

color	cyan

Bemærk: De to metoder har fælles lagring af seneste tidspunkt for et kald til en given abonnementsliste. Et kald til den ene metode vil derfor medføre, at ved et efterfølgende kald uden tidsangivelse til den anden metode vil tidsstemplet fra det første kald blive anvendt automatisk. Det anbefales derfor at anvendere af abonnementsservicen enten selv holder regnskab med ”siden sidst”, alternativt udelukkende anvender den ene af de to metoder.
Det bemærkes endvidere, at både abonnementslister og tidspunkterne for kald til udtræksmetoderne deles på tværs af samtlige NSP-instanser ved brug af platformens replikeringsmekanisme. Da disse to replikeringer ikke foretages øjeblikkeligt, skal man som klient være forberedt på, at fremtidige requests der foretages tidsmæssigt tæt på det oprindelige, kan returnere cpr-numre, man har set ved tidligere kald.

Fælles for begge metoder er at abonnementslisten automatisk identificeres på basis af det medsendte system IDkort. Cvr-nummer angives derfor ikke eksplicit.

Følgende WSDL’er gælder for de to metoder:

getChangedCprs: cprabbs.wsdl
getSubscribedPersonDetails: StamdataPersonLookupWithSubscription.wsdl

De to WSDL’er samt relaterede skemadefinitioner kan rekvireres ved henvendelse til NSP-operatøren.

I Bilag A: Eksempel på kald til abonnementsservicen ses et eksempel på request og response ved et kald til getSubscribedPersonDetails, hvor relevante headere er inkluderet i eksemplet. Nedenfor følger et eksempel på et kald til getChangedCprs, hvor kun body er inkluderet i forespørgsel og svar:

Code Block

language	java
title	Forespørgsel
collapse	true

<CprAbbsRequest xmlns=”http://nsi.dk/cprabbs/2011/10”>
         <since>2008-09-29T03:49:45</since>
</CprAbbsRequest>

Code Block

language	java
title	Svar
collapse	true

<CprAbbsResponse xmlns==”http://nsi.dk/cprabbs/2011/10”>
    <changedCprs>1234567890</cpr>
    <changedCprs>2345678901</cpr>
</CprAbbsResponse>

6 Ændringslog

Kilden til dette dokument kan fås ved henvendelse til NSP-operatøren.

...

Version

...

Dato

...

Ændring

...

Ansvarlig

...

1.0

...

2011-04-28

...

Initielt Dokument

...

Trifork

...

1.1

...

2011-09-26

...

Opdateret med cpr tjenester

...

Trifork

...

1.2

...

2011-12-01

...

Kvalitetssikring

...

Lakeside

...

1.3

...

2012-06-19

...

Opdateret med bemyndigelse og NPI-SOR relationer

...

Trifork

...

1.4

...

2013-05-14

...

Tilføjet information om krs endpoint url

...

Trifork

...

1.5

...

2013-05-21

...

Opdateret det gode cpr opslag med wsdl og endpoints

...

Trifork

...

1.6

...

2014-05-14

...

Tilføjet beskrivelse af erstatningsværdier i cpr opslag

...

Trifork

...

1.7

...

2014-07-15

...

Opdateret information om adressebeskyttelse

...

Trifork

Bilag A: Eksempel på kald til abonnementsservicen

Nedenfor ses et eksempel på et kald til abonnementsservicen og det tilhørende svar. Eksemplet indeholder komplette headers, inklusiv IDkort, dog er signaturen og certifikatet erstattet med ”[...]”.

Code Block

language	java
title	Forespørgsel
linenumbers	true
collapse	true

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
    <ns2:Security xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns11="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns12="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns13="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns14="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns15="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns16="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns17="http://www.w3.org/2000/09/xmldsig#" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns5="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns6="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns7="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns8="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns9="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/">
      <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsu:Created>2011-12-08T09:10:31Z</wsu:Created>
      </wsu:Timestamp>
      <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2011-12-08T09:05:31Z" Version="2.0" id="IDCard">
        <saml:Issuer>TheSOSILibrary</saml:Issuer>
        <saml:Subject>
          <saml:NameID Format="medcom:other">123</saml:NameID>
          <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</saml:ConfirmationMethod>
            <saml:SubjectConfirmationData>
              <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:KeyName>OCESSignature</ds:KeyName>
              </ds:KeyInfo>
            </saml:SubjectConfirmationData>
          </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2011-12-08T09:05:31Z" NotOnOrAfter="2011-12-09T09:05:31Z"/>
        <saml:AttributeStatement id="IDCardData">
          <saml:Attribute Name="sosi:IDCardID">
            <saml:AttributeValue>BWMWK+OPPwTlBMxLxucS6w==</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute Name="sosi:IDCardVersion">
            <saml:AttributeValue>1.0.1</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute Name="sosi:IDCardType">
            <saml:AttributeValue>system</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute Name="sosi:AuthenticationLevel">
            <saml:AttributeValue>3</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute Name="sosi:OCESCertHash">
            <saml:AttributeValue>pFQXTvhBFAsCwPy2VkYI6GDTnFQ=</saml:AttributeValue>
          </saml:Attribute>
        </saml:AttributeStatement>
        <saml:AttributeStatement id="SystemLog">
          <saml:Attribute Name="medcom:ITSystemName">
            <saml:AttributeValue>ACME Pro</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute Name="medcom:CareProviderID" NameFormat="medcom:cvrnumber">
            <saml:AttributeValue>12345678</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute Name="medcom:CareProviderName">
            <saml:AttributeValue>dk</saml:AttributeValue>
          </saml:Attribute>
        </saml:AttributeStatement>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" id="OCESSignature">
          <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <ds:Reference URI="#IDCard">
              <ds:Transforms>
                <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              </ds:Transforms>
              <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
              <ds:DigestValue>IVexeSZomox+Mq9cNYlSp1L+GX8=</ds:DigestValue>
            </ds:Reference>
          </ds:SignedInfo>
          <ds:SignatureValue>[...]</ds:SignatureValue>
          <ds:KeyInfo>
            <ds:X509Data>
              <ds:X509Certificate>[...]</ds:X509Certificate>
            </ds:X509Data>
          </ds:KeyInfo>
        </ds:Signature>
      </saml:Assertion>
    </ns2:Security>
    <ns18:Header xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns11="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns12="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns13="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns14="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns15="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns16="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns17="http://www.w3.org/2000/09/xmldsig#" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns5="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns6="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns7="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns8="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns9="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/">
      <medcom:SecurityLevel xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">3</medcom:SecurityLevel>
      <medcom:Linking xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
        <medcom:FlowID>ccfd937c-91bb-4d7e-8772-ea72573cc96c</medcom:FlowID>
        <medcom:MessageID>42foobar</medcom:MessageID>
      </medcom:Linking>
      <medcom:RequireNonRepudiationReceipt xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">no</medcom:RequireNonRepudiationReceipt>
    </ns18:Header>
  </S:Header>
  <S:Body>
    <ns22:CprAbbsRequest/>
  </S:Body>
</S:Envelope>

Code Block

language	java
title	Svar
collapse	true

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
    <ns3:Security xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns6="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns9="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/" xmlns:ns11="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns12="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns13="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns14="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns15="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns16="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns17="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/">
      <ns19:Timestamp>
        <ns19:Created>2011-12-08T09:10:32Z</ns19:Created>
      </ns19:Timestamp>
    </ns3:Security>
    <ns18:Header xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns6="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns9="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/" xmlns:ns11="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns12="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns13="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns14="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns15="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns16="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns17="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/">
      <ns18:Linking>
        <ns18:FlowID>ccfd937c-91bb-4d7e-8772-ea72573cc96c</ns18:FlowID>
        <ns18:MessageID>743e57ca-f3c2-462a-9fd3-f54e8414dfbd</ns18:MessageID>
        <ns18:InResponseToMessageID>42foobar</ns18:InResponseToMessageID>
      </ns18:Linking>
      <ns18:FlowStatus>flow_finalized_succesfully</ns18:FlowStatus>
    </ns18:Header>
  </S:Header>
  <S:Body>
    <ns23:PersonLookupResponse xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns6="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns9="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/" xmlns:ns11="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns12="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns13="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns14="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns15="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns16="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns17="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/">
      <ns15:PersonInformationStructure>
        <ns15:CurrentPersonCivilRegistrationIdentifier>0201270145</ns15:CurrentPersonCivilRegistrationIdentifier>
        <ns20:RegularCPRPerson>
          <ns20:SimpleCPRPerson>
            <ns6:PersonNameStructure>
              <ns5:PersonGivenName>Peter</ns5:PersonGivenName>
              <ns5:PersonMiddleName>Sigurd</ns5:PersonMiddleName>
              <ns5:PersonSurnameName>Andersen</ns5:PersonSurnameName>
            </ns6:PersonNameStructure>
            <ns7:PersonCivilRegistrationIdentifier>0101822231</ns7:PersonCivilRegistrationIdentifier>
          </ns20:SimpleCPRPerson>
          <ns21:PersonNameForAddressingName>Peter,Andersen</ns21:PersonNameForAddressingName>
          <ns5:PersonGenderCode>male</ns5:PersonGenderCode>
          <ns17:PersonInformationProtectionIndicator>false</ns17:PersonInformationProtectionIndicator>
          <ns17:PersonBirthDateStructure>
            <ns10:BirthDate>2011-12-06+01:00</ns10:BirthDate>
            <ns17:BirthDateUncertaintyIndicator>false</ns17:BirthDateUncertaintyIndicator>
          </ns17:PersonBirthDateStructure>
          <ns20:PersonCivilRegistrationStatusStructure>
            <ns17:PersonCivilRegistrationStatusCode>1</ns17:PersonCivilRegistrationStatusCode>
            <ns20:PersonCivilRegistrationStatusStartDate>2011-12-07+01:00</ns20:PersonCivilRegistrationStatusStartDate>
          </ns20:PersonCivilRegistrationStatusStructure>
        </ns20:RegularCPRPerson>
        <ns15:PersonAddressStructure>
          <ns8:CareOfName>Søren Petersen</ns8:CareOfName>
          <ns12:AddressComplete>
            <ns9:AddressAccess>
              <ns7:MunicipalityCode>0461</ns7:MunicipalityCode>
              <ns7:StreetCode>0234</ns7:StreetCode>
              <ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
            </ns9:AddressAccess>
            <ns12:AddressPostal>
              <ns10:StreetName>Ørstedgade</ns10:StreetName>
              <ns7:StreetNameForAddressingName>Østergd.</ns7:StreetNameForAddressingName>
              <ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
              <ns5:FloorIdentifier>12</ns5:FloorIdentifier>
              <ns5:SuiteIdentifier>tv</ns5:SuiteIdentifier>
              <ns10:DistrictSubdivisionIdentifier>Birkely</ns10:DistrictSubdivisionIdentifier>
              <ns10:PostCodeIdentifier>6666</ns10:PostCodeIdentifier>
              <ns10:DistrictName>Überwald</ns10:DistrictName>
            </ns12:AddressPostal>
          </ns12:AddressComplete>
          <ns14:CountyCode>1083</ns14:CountyCode>
        </ns15:PersonAddressStructure>
      </ns15:PersonInformationStructure>
      <ns15:PersonInformationStructure>
        <ns15:CurrentPersonCivilRegistrationIdentifier>1302642907</ns15:CurrentPersonCivilRegistrationIdentifier>
        <ns20:RegularCPRPerson>
          <ns20:SimpleCPRPerson>
            <ns6:PersonNameStructure>
              <ns5:PersonGivenName>Peter</ns5:PersonGivenName>
              <ns5:PersonMiddleName>Sigurd</ns5:PersonMiddleName>
              <ns5:PersonSurnameName>Andersen</ns5:PersonSurnameName>
            </ns6:PersonNameStructure>
            <ns7:PersonCivilRegistrationIdentifier>0101821234</ns7:PersonCivilRegistrationIdentifier>
          </ns20:SimpleCPRPerson>
          <ns21:PersonNameForAddressingName>Peter,Andersen</ns21:PersonNameForAddressingName>
          <ns5:PersonGenderCode>male</ns5:PersonGenderCode>
          <ns17:PersonInformationProtectionIndicator>false</ns17:PersonInformationProtectionIndicator>
          <ns17:PersonBirthDateStructure>
            <ns10:BirthDate>2011-12-06+01:00</ns10:BirthDate>
            <ns17:BirthDateUncertaintyIndicator>false</ns17:BirthDateUncertaintyIndicator>
          </ns17:PersonBirthDateStructure>
          <ns20:PersonCivilRegistrationStatusStructure>
            <ns17:PersonCivilRegistrationStatusCode>1</ns17:PersonCivilRegistrationStatusCode>
            <ns20:PersonCivilRegistrationStatusStartDate>2011-12-07+01:00</ns20:PersonCivilRegistrationStatusStartDate>
          </ns20:PersonCivilRegistrationStatusStructure>
        </ns20:RegularCPRPerson>
        <ns15:PersonAddressStructure>
          <ns8:CareOfName>Søren Petersen</ns8:CareOfName>
          <ns12:AddressComplete>
            <ns9:AddressAccess>
              <ns7:MunicipalityCode>0461</ns7:MunicipalityCode>
              <ns7:StreetCode>0234</ns7:StreetCode>
              <ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
            </ns9:AddressAccess>
            <ns12:AddressPostal>
              <ns10:StreetName>Ørstedgade</ns10:StreetName>
              <ns7:StreetNameForAddressingName>Østergd.</ns7:StreetNameForAddressingName>
              <ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
              <ns5:FloorIdentifier>12</ns5:FloorIdentifier>
              <ns5:SuiteIdentifier>tv</ns5:SuiteIdentifier>
              <ns10:DistrictSubdivisionIdentifier>Birkely</ns10:DistrictSubdivisionIdentifier>
              <ns10:PostCodeIdentifier>6666</ns10:PostCodeIdentifier>
              <ns10:DistrictName>Überwald</ns10:DistrictName>
            </ns12:AddressPostal>
          </ns12:AddressComplete>
          <ns14:CountyCode>1083</ns14:CountyCode>
        </ns15:PersonAddressStructure>
      </ns15:PersonInformationStructure>
    </ns23:PersonLookupResponse>
  </S:Body>
</S:Envelope>

...

Content

Space Tools

Page History

Versions Compared

Old Version 3

New Version Current

Key

Formål

Omfattede komponenter

2.1 Stamdata importer komponenter

2.1.1 Stamdata Data Importere

3 Opdatering til nye versioner

4 Daglig Drift

4.1 Stamdata Importere

4.1.1 Fremgangsmåde for indlæsning af nye data

4.1.2 Eksempel for import af nye CPR-data

5 Enkeltopslag i registre

5.1 Forespørgsler og dataformat

5.2 Enkeltopslag i autorisationsregistret

NSP komponenter

Stamdata Kopi-Register Service

Stamdata AutorisationsregisteretEnkeltopslag

Stamdata CPREnkeltopslag

Stamdata YderregisterEnkeltopslag

Opdatering til nye versioner

Daglig Drift

Wildfly jndi datasource

Stamdata Autorisation Enkeltopslag

Konfiguration af Autorisation Enkeltopslag

Stamdata Yderregister Enkeltopslag

Konfiguration af Yderregister Enkeltopslag

Stamdata Kopi-Register-Service og Stamdataregister Fleropslagsservice

Konfiguration

Rettighedsstyring

Konfiguration af opslagskolonner i SRFS

CPR-Services

Konfiguration

Statsborgerskabs mapning

Rettighedsstyring

PersonInformation

Konfiguration

Backup

Overvågning

Statussider

Speciel overvågning af SOR og SOR-Relationer importerne

Logning

Fejlsøgning

Liste af Registre

Stamdata Filter Management Service (SFMS)

Konfiguration

Properties

5.2.1 Eksempel: Én eller flere autorisationer

5.2.2 Eksempel: Ingen gyldige autorisationer

5.3 CPR-registret: Det Gode CPR-opslag

5.3.1 WSDL

5.3.2 Endpoints

5.3.3 Mangelfuldt datagrundlag

5.3.4 Fejlfyldt CPR-data

5.3.5 Navne- og adressebeskyttelse

5.4 CPR-registret: getPersonDetails

5.4.1 Endpoints

5.4.2 Mangelfuld data og fejlfyldt CPR-data

5.4.3 Eksempel 1: getPersonDetails(<Personnummer>)

5.4.5 Kald 3: (Opslag vha. fødselsdato)

5.5 CPR-Abonnementsservice

5.5.1 Vedligehold af abonnementslisten

5.5.2 Udtræk af ændringer i CPR-data

6 Ændringslog

Bilag A: Eksempel på kald til abonnementsservicen