Integration SF1320 A - CPR - Hændelser · CPR-041 Slut afsoning Notatlinje 3 eller 4 udfyldt...

Integration SF1320_A - CPR - Hændelser

Integrationsbeskrivelse - version 2.0.0

Kommunernes Datafællesskab - KDF

9Integrationsbeskrivelse

SF1320_A - CPR - Hændelser

KOMBIT A/S Halfdansgade 8 2300 København S www.kombit.dk CVR 19 43 50 75 Side 2 af 33

Versionshistorik

Relevans Dato Initialer Version Kommentarer

2014-01-10 PBO 0.1 Første version kopieret fra gammel skabelon

2014-01-10 PBO 0.2 Opdateret til fase 1

2014-11-18 PBO 0.3 Opdateret til fase 2

2015-03-17 EHE 0.5 Klargjort til SP

2015-08-18 EDM 0.5.1 Forkert systemnavn i integrationsflow 4.1 rettet til CPR.

2015-09-01 EDM 2.0.0 Generelle ændringer omkring Beskedfordeler. Afsnit 1.5 Forud-

sætninger, afsnit 3.1.3 ModtageBesked, afsnit 3.3 Serviceplat-

formen som Beskedagent og 4.1.2 Beskrivelse af Beskedkuvert.

Interne referencer opdateret.

Referencer

Ref Titel Kommentarer

[SPref] Bilag 7B Ydelser og servicemål for Serviceplatformen

[BFref] [Afklaring/KDF – indsæt reference dokumentation af

servicemål for BF]

Endnu ikke udarbejdet

[SIKKERHED] Use cases for brug af sikkerhedsmodeller på Ser-

viceplatformen - v.0.4.3

[STS-Sikkerhed] Se vilkår Bilag 2 - Vilkår for anvendelse af sikker-

hedsmodellen i Rammearkitekturen version 2.0 på

nedenstående link https://share-komm.kom-

bit.dk/P024/Delte%20dokumenter/Forms/Integrati-

onsvilkr.aspx

[SFTP] https://www.serviceplatformen.dk/administra-

tion/help/provider-tech-guide

”USM0005 Vejledning til Serviceplatformens SFTP

Service.pdf”

Vejledning med xsd.

[VBF] Se vilkår Underbilag 2N - Vilkår for integration til støt-

tesystemet Beskedfordeler version 2.0 på nedenstå-

ende link

https://share-komm.kombit.dk/P024/Delte%20doku-

menter/Forms/Integrationsvilkr.aspx

[SF1460_A] Modtag besked Beskrivelse af protokol for Besked-

fordeler

[SF1460_B] Vedligehold værdiliste i beskedabonnement Beskrivelse af protokol for Besked-

fordeler

[SF1460_C] Aflever besked Beskrivelse af protokol for Besked-

fordeler

[SF1460_D] Modtag besked via pull Beskrivelse af protokol for Besked-

fordeler

https://www.serviceplatformen.dk/administration/help/provider-tech-guide

https://www.serviceplatformen.dk/administration/help/provider-tech-guide




[WSDL-SP] Integrationsbeskrivelsen refererer til SF1320_A Tek-

nisk Spec 20150901.zip som indeholder WSDL på

serviceplatformen, og er placeret i samme mappe

som integrationsbeskrivelsen, se link https://share-

komm.kombit.dk/p089/Integrationsbeskrivelser/

[WSDL-EXT] Integrationsbeskrivelsen refererer til SF1320_A Bilag

20150901.zip som indeholder WSDL/WADL/XSD af

eksterne interfaces, som er placeret i samme mappe

som integrationsbeskrivelsen, se link https://share-

komm.kombit.dk/p089/Integrationsbeskrivelser/

Indholdsfortegnelse

1 Overordnet beskrivelse ............................................................................................. 4

1.1 Integrationens formål ............................................................................................ 4

1.2 Overordnet forretningsflow i integrationen .................................................................... 4

1.3 Servicebetingelser for den samlede integration ........................................................... 10

1.4 Teststrategi ...................................................................................................... 12

1.5 Forudsætninger for produktionssætning .................................................................... 13

2 Kontekst for integrationsparter .................................................................................. 14

2.1 Kontekst for KY[!@IP_FS1@!] ............................................................................... 14

2.2 Kontekst for KSD [!@IP_FS1@!] ............................................................................ 14

2.3 Kontekst for SAPA [!@IP_FS1@!] ........................................................................... 15

2.4 Kontekst for CPR [!@IP_CPR1@!] .......................................................................... 15

3 Specifikation for integrationsparter ............................................................................. 17

3.1 Specifikation af endpoints for fagsystem KY, KSD, SAPA[!@KY@!][!@KSD@!] [!@SAPA@!] ... 17

3.2 Specifikation af endpoints for CPR .......................................................................... 20

3.3 Specifikation af endpoints for Serviceplatformen som afsendende beskedagent [!@Systematic@!]

23

4 Beskrivelse for integrationsplatforme ........................................................................... 25

4.1 Beskrivelse for Serviceplatformen [!@Systematic@!] .................................................... 25

https://share-komm.kombit.dk/p089/Integrationsbeskrivelser/







1 Overordnet beskrivelse

1.1 Integrationens formål

Integrationen har til formål at tilvejebringe og videresende relevante personhændelser på CPR-om-

rådet for fagsystemer, der benyttes af offentlige myndigheder via det fælleskommunale støttesy-

stem Beskedfordeler (Beskedfordeler).

Dette vil gøre fagsystemer i stand til at kunne reagere på personhændelser ift. de myndighedssa-

ger og arbejdsgange i forbindelse med forvaltningsvirksomhed som fagsystemet it-understøtter.

Integrationen leverer kun hændelser fra CPR registret og således ikke personhændelser fra fx ud-

lændingeområdet.

1.2 Overordnet forretningsflow i integrationen

Det overordnede flow for integrationen er som følger.

Serviceplatformen henter personhændelser fra CPR-registeret dagligt. Herefter analyseres data for

at afgøre hvilke forretningsmæssige personhændelser, som har fundet sted. Til sidst afleveres

data til Beskedfordeler med en besked per hændelse.

Fagsystemer skal oprette et abonnement i Beskedfordeler med angivelse af filtre på kuvertens me-

tadata, herunder relevante personhændelser, personnumre eller adresser. Fagsystemets adgang

til typer af personhændelser fra Beskedfordeler skal opsættes i det fælleskommunale støttesystem

Adgangsstyring.

Fagsystemet vil således kun kunne modtage personhændelser fra Beskedfordeler på angivne be-

skedtyper og som er indeholdt i fagsystemets abonnement.

Integrationen er en gennemstillingsintegration med ”content based routing” og transformation, som

integrerer til Beskedfordeler.




Nedenfor er illustreret flowet i integrationen:

Se

rvic

ep

latfo

rme

nF

ag

syst

em

(n)

CP

RBe

sked

ford

eler

Modtag personhændelse

Hent data

Dan

forretnings-

hændelser

Opdater

lokalt

repository

Send

Besked

Modtag

Besked

Distribuer

besked til

dueslag

Udstil

besked

Modtag

Besked

Dan udtræk

Periodisk

Udstil

Persondata

CPR genererer hver nat et udtræk til Serviceplatformen på alle recordtyper, der er ændret i CPR-

registeret siden sidste udtræk, og Serviceplatformen kan derfor modtage alle personhændelser for

alle personer i CPR.

Serviceplatformen henter udtrækket og udregner for hver personhændelse en eller flere forret-

ningshændelser, som beskriver hvilken ændring, der har fundet sted. Derefter opdateres det lokale

CPR-repository, og endelig sendes beskederne til Beskedfordeler.

Beskedfordeler modtager beskederne og udregner hvilke abonnementer, som skal modtage be-

skeden og distribuerer herefter beskeder til de korrekte dueslag. Fagsystemerne kan selv opsætte

og administrere deres dueslag.

Fagsystemet modtager beskeden og behandler den efter egne forretningsregler jf. snitflade

SF1460_A/SF1460_D. Denne snitflade omhandler kun Serviceplatformens modtagelse af person-

hændelser og afsendelse af forretningshændelser vedr. person (Part).

1.2.1 Ændringer til den eksisterende snitflade for CPR Abonnement

Serviceplatformen skal implementere flowet beskrevet i punkt 1.2 herunder:




Serviceplatformen skal benytte det eksisterende ændringsudtræk fra CPR.

Serviceplatformen skal udarbejde en komponent til at generere forretningshændelser for

personhændelser jf. punkt 1.2.2.

Serviceplatformen skal benytte den eksisterende funktionalitet til at opdatere det lokale re-

pository.

Serviceplatformen skal udarbejde en integration til Beskedfordeler, herunder skal Service-

platformen oprettes som et afsendersystem til Beskedfordeler i det fælleskommunale støt-

tesystem Adgangsstyring.

Systematic skal udarbejde et XSD over indholdet af Personbeskeder som afsendes. XSD

skal godkendes af KOMBIT.

1.2.2 Service Management

1.2.2.1 Incident Management

Der er pt. ingen yderligere krav, i forhold til den gældende aftale for Serviceplatformen.

1.2.2.2 Problem Management


1.2.2.3 Change Management


1.2.3 Liste over forretningshændelser

Ud fra de modtagne personhændelser genereres forretningshændelser i Serviceplatformen som

beskrevet i nedenstående tabel.

[Afklaring/KDF – afventer endelige definition af hvorledes de forretningsmæssige hændelser kan

generes ud fra hændelser fra CPR]

Tabellen har følgende kolonner:

Hændelse ID, Serviceplatformens brugervendte ID på hændelsen.

Hændelse Navn, Navnet på hændelsen.

De næste to kolonner beskriver reglen for hvilke ændringer i data, som medfører en bestemt

hændelse på baggrund af en ændring på et CPR nummer modtaget i et CPR ændringsudtræk.

Tidligere Data: Tilstanden af det lokale replika på Serviceplatformen inden opdatering fra

CPR ændringsudtrækket udføres.

Nuværende Data: Det opdaterede data tilhørende et CPR nummer, som modtages i et

CPR ændringsudtræk.




Hæn-

delse ID

Hændelse navn Tidligere data Nuværende data

CPR-001 Ændring af registrering Ikke relevant Nye data modtaget

CPR-002 Fødsel Ingen registrering Ny registrering, indrejsedato er

tom.

CPR-003 Navngivning Ingen navnedata Navnedata tilføjet

CPR-004 Navneændring Andet navn Navnedata ændret

CPR-005 Dødsfald Status ikke 90 Status ændret til 90

CPR-006 Dødsfald - som for-

svundet

Status 70 Status ændret til 90

CPR-007 Dødsfald - som udvan-

dret

Status 80 Status ændret til 90

CPR-008 Dødsfald som nyfødt Ingen fødselsregistrering Status ændret til 90

CPR-009 Dødsfald – ægtefælle Ægtefælle status ikke 90 Ægtefælle status ændret til 90

CPR-010 Forsvinding Status ikke 70 Status ændret til 70

CPR-011 Genfinding Status 70 Status ændret fra 70

CPR-012 Indvandring Ingen registrering Ny registrering, samt en angi-

velse af indrejsedato samt ud-

landsadresse

CPR-013 Udvandring Status ikke 80 Status ændret til 80

CPR-014 Genindvandring Status 80 Status ændret fra 80

CPR-015 Nynummerering Ingen registrering Nyt CPR nummer

CPR-016 Omnummerering nyt

nummer

Ingen registrering på

gældende personnum-

mer

Hændelse angiver andet CPR-

nummer, Feltet ”Afledtmarke-

ring” angiver typen, Feltet

”pnrgaeld” angiver gældende

personnummer og vil være til-

svarende PNR.

CPR-017 Sletning af personnum-

mer

Status ikke 30 Status ændret til 30




CPR-018 Tidligere dobbelt num-

mer


CPR-019 Udgår grundet omnum-

merering


CPR-020 Myndiggørelse Alder <18 eller Umyn-

diggjort

Alder>18 eller Umyndighed

slut

CPR-021 Umyndiggørelse Ikke umyndiggjort Umyndiggørelse start dato

CPR-022 Folkekirketilknytning

ændret

Folkekirkeforhold ændret Folkekirkeforhold ændret

CPR-023 Statsborgerskab æn-

dret

Statsborger landekode

ændret

Statsborger landekode ændret

CPR-024 Faderskab – far Barn far oprettet eller

ændret

Barn far oprettet eller ændret

CPR-025 Fødsel – mor Barn mor oprettet eller

ændret

Barn mor oprettet eller ændret

CPR-026 Faderskab – barn Barn far oprettet eller

ændret

Barn far oprettet eller ændret

CPR-027 Adoption – barn Barn mor oprettet eller

ændret

Barn mor oprettet eller ændret

CPR-028 Vielse Civilstand ikke "G" Civilstand ændret til "G"

CPR-029 Separation startet Separation ikke oprettet Separation startdato

CPR-030 Separation ophørt Separation oprettet Separation slettet

CPR-031 Skilsmisse Civilstand ikke "F" Civilstand ændret til "F"

CPR-032 Ændring vedrørende

ægtefælle

Ikke relevant Nye data modtaget og civ. "G"

CPR-033 Ændring vedrørende

slægtskab

Ændring af mor eller far Ændring af mor eller far

CPR-034 Flytning til kommunen Anden kommune Kommune ændret

CPR-035 Flytning fra kommunen Aktuel kommune i lokalt

repository

Kommune ændret




CPR-036 Fraflytning inden for

kommunen

Kommune uændret + Ny

adresse


adresse

CPR-037 Tilflytning inden for

kommunen


adresse


adresse

CPR-038 Indkaldelse til militæret Suppl. adresse ikke ud-

fyldt

Suppl. adresse angivet

CPR-039 Hjemsendelse fra mili-

tæret

Suppl. adresse angivet Suppl. adresse slettet

CPR-040 Start afsoning Notatlinje 3&4 ikke ud-

fyldt

Notatlinje 3 eller 4 ændret

CPR-041 Slut afsoning Notatlinje 3 eller 4 udfyldt Notatlinje 3&4 slettet




1.3 Servicebetingelser for den samlede integration

1.3.1 Servicemål

For Serviceplatformen gælder på punkterne tidsrum, svartid, tilgængelighed og servicevindue de

generelle betingelser fra driftsaftale for Serviceplatformen. Se [SPref].

Parameter CPR Hændelser

Tidsrum Serviceplatformen driftsafvikles hele døgnet alle dage

bortset fra når der udføres ændringer/hvor der er ser-

vicevinduer [SPref].

Beskedfordeler driftsafvikles hele døgnet alle dage

bortset fra når der udføres ændringer/hvor der er ser-

vicevinduer [BFref].

CPR driftsafvikles hele døgnet alle dage bortset fra,

når der udføres ændringer/hvor der er servicevinduer

Se ”vk50_offentlige_vilkaar.pdf” [WSDL_EXT].

Svartid Serviceplatformen har forskellig SLA på svartid alt efter

hvilken integrationskompleksitet, der er tale om [SPref]:

Simpel = 1 sekund

Mellem = 1,5 sekund

Kompleks = 4 sekunder

Svartid for Beskedfordeler er beskrevet i [BFref].




Tilgængelighed Servicemålene for Serviceplatformen driftseffektivitet er

99,8% for perioden 06:00 -18:00 på arbejdsdage samt

98,5 % i den øvrige tid [SPref].

Tilgængelighed for Beskedfordeler er beskrevet i

[BFref].




Spidsbelastningsperiode Spidsbelastningen for Serviceplatformen må antages

at være i perioden 06:00 -18:00 på arbejdsdage

[SPref].




Spidsbelastning for Beskedfordeler er beskrevet i

[BFref].




Servicevinduer Ved mindre opdateringer for Serviceplatformen:

En gang om ugen i tidsrummet 05:00 -06:00. Varsling: 1. uge, varighed (naturligvis) max en time. Ved større og kritiske opdateringer:

Optil 1 gang om måneden i tidsrummet mandag kl. 03:00 til mandag kl. 06:00. Varsling: 1. uge, Varighed: max 3 timer

Ved omlægning af miljøer, arkitektur og services for Serviceplatformen:

1 gang pr. kvartal i tidrummet søndag kl. 22:00 til man-dag kl. 06:00. Varsling 1. måned, varighed max 8 timer [SPref].

Servicevinduer for Beskedfordeler er beskrevet i

[BFref].





Eventuelle tilretninger og præciseringer i integrationens beskrivelse og specifikation, vil indtil inte-

grationen ligger på Serviceplatformens eksterne testmiljø, blive håndteret af Kommunernes Data

Fællesskab (KDF). Spørgsmål vedr. specifikation sendes til [email protected]. KDF sørger

for at involverede parter i integrationen oplyses om tilretningerne og præciseringerne.

Se oversigten over hvornår de enkelte integrationer forventes at være tilgængelige i eksternt test-

miljø her: https://share-komm.kombit.dk/p089/

Når servicen er tilgængelig i det eksterne testmiljø på Serviceplatformen, vil den overgå til Service-

platformens governanceproces. Beskrivelse af denne tilgår senere.


[Afklaring/Programmet – rejst emne: skal der være spoc på integrationer der anvender forskellige

integrationsplatforme, eller afgøres det pr. integration]

mailto:[email protected]

https://share-komm.kombit.dk/p089/










1.3.3 Lifecycle Management

[Afklaring/Programmet: Håndteres i programemnelog #14]

1.4 Teststrategi

Den planlagte test af services til installation på Serviceplatformen omfatter pt., at Systematic udfø-

rer automatiserede tests af services og unit tests. Se [SPref] for detaljer.

Derudover:

[Afklaring/Programmet: Teststrategi håndteres i programemnelog #1]

1.4.1 Test i forbindelse med udvikling



Derudover:


1.4.1.1 Testfaciliteter og testmiljø



Derudover:


1.4.1.2 Testdata


1.4.2 Test i forbindelse med produktionssætning

I forbindelse med produktionssætning er det omfattet af gældende aftale med Systematic, at der

gennemføres følgende 3 prøver:

Overtagelsesprøve

Idriftsættelsesprøve

Driftsprøve




Se [SPref] for detaljer.

Derudover:


1.5 Forudsætninger for produktionssætning

Leverandøren skal være oprettet som tilslutningspart i rammearkitekturens administrationsmodul,

og leverandøren skal oprette en tilslutningsaftale for it-systemet i administrationsmodulet. Leveran-

døren skal tiltræde, og overholde, vilkårene i den til enhver tid gældende aftale for tilslutning af it-

systemer til den fælleskommunale rammearkitektur. Leverandøren af It-systemet er ansvarlige for

at It-systemet tilsluttes via rammearkitekturens administrationsmodul, med den, eller de, systemty-

per (brugervendt system, anvendersystem og/eller serviceudbyder), der er relevante for It-syste-

met jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed].

[Afklaring/KDF: Tilføj yderligere dokumentation med vejledning i brug af sikkerhedsmodellen, her-

under brug af Security Token Servicen, støttesystemer, mv. i Rammearkitekturen, når denne mod-

tages fra STS]

1.5.1 Funktionalitet på Serviceplatformen

Leverandøren skal anmode om indgåelse af serviceaftale for de myndigheder, der skal bruge ser-

vicen, i rammearkitekturens administrationsmodul, og myndigheden skal godkender denne anmod-

ning jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed].

De nødvendige beskedtyper og opsætninger skal være oprettet i Beskedfordeler, så systemet kan

sende de beskeder, der indgår i integrationen jf. Vilkår for integration til støttesystemet Beskedfor-

deler [VBF].

Leverandøren skal være oprettet som tilslutningspart på SF1460_C.

Serviceplatformen skal have et opdateret lokalt replika for CPR for alle personer ved idriftsættelse.

1.5.2 Forudsætninger for tilslutning til integrationspart: CPR

KOMBIT har indgået aftale med CPR på vegne af kommunerne.

CPR beskriver tilslutningskravene i ”vk50_offentlige_vilkaar.pdf” [WSDL_EXT].

1.5.3 Forudsætninger for tilslutning til integrationspart: Fagsystemet

De nødvendige abonnementer og opsætninger skal være oprettet i Beskedfordeler, så systemet

kan modtage de beskeder, der indgår i integrationen jf. Vilkår for integration til støttesystemet Be-

skedfordeler [STS-Sikkerhed].

Leverandøren skal være oprettet som tilslutningspart på SF1460_A/SF1460_D og SF1460_B.




2 Kontekst for integrationsparter

SF1320_A indeholder følgende integrationsparter:

Kommunernes Ydelsessystem, der modtager information om personhændelser via Besked-

fordeler.

Kommunernes Sygedagpengesystem, der modtager information om personhændelser via

Beskedfordeler.

SAPA, der modtager information om personhændelser via Beskedfordeler.

CPR som leverer ændringsudtræk for persondata, som anvendes af Serviceplatformen

2.1 Kontekst for KY[!@IP_FS1@!]

2.1.1 Lovhjemmel og forvaltningsmæssigt formål

Som beskrevet i punkt 1.1

Det anførte hjemmelsgrundlag er bestemt af det enkelte og relevante fagprojekt i KOMBIT på be-

stillingstidspunktet. Det er fastsat på baggrund af en rimelig og dækkende analyse. Henvisningen

til hjemmelsgrundlaget bliver ikke vedligeholdt, hvorfor KOMBIT naturligvis ikke kan indestå for, at

denne henvisnings indehold og retsvirkning til alle tider vil være korrekt. KOMBIT skal derfor un-

derstrege, at læseren af dette dokument udelukkende skal læse hjemmelsgrundlaget som en ori-

entering.

2.1.2 Kapacitets- og servicekrav

KY har 314.000 berørte personer om året (2012 tal). KOMBIT har estimeret at der vil være ca.

40.000 CPR ændringer til disse personer per år, ud fra tal fra Danmarks statistik om flytninger,

fødsler, dødsfald, vielser og skilsmisser.

Dvs. ca. 3.500 opdateringer om måneden.

2.1.3 Specifikke forhold for tilslutning af system

Det skal bemærkes at beskedfordeleren modtager beskeder for samtlige kommuner. Derfor skal

KY enten kun abonnere på beskeder for relevante kommuner, eller ignorere meddelelser for kom-

muner der ikke er aktive i KY.

2.2 Kontekst for KSD [!@IP_FS1@!]


Som beskrevet i punkt 1.1.









entering.


Det er estimeret at der maksimalt vil være 75.000 ændringer per måned. Hver ændring kan godt

medføre udsendelse af flere beskeder.


For hver idriftsættelse af KSD (udrulning sker pr. kommune), vil der blive tegnet abonnement på

alle parter i sager i den kommune hvor KSD tages i drift.

2.3 Kontekst for SAPA [!@IP_FS1@!]








entering.


Alle kommuner som benytter SAPA vil udtrykkes som et geografisk abonnement, det forventes at

SAPA rulles ud i bølger til kommunerne.

SAPA forventes at modtage personhændelser på alle borgere i de kommuner som benytter SAPA.

Det vil sige op til cirka 5000 ændringer om dagen. Dette svarer ca. til alle hændelser der genereres

på Serviceplatformen.


Det skal bemærkes at beskedfordeleren modtager beskeder for samtlige kommuner. Derfor skal

SAPA enten kun abonnere på beskeder for relevante kommuner, eller ignorere meddelelser for

kommuner der ikke er aktive i SAPA.

2.4 Kontekst for CPR [!@IP_CPR1@!]











entering.


CPR udstiller cirka 5000 ændringer om dagen.


Udtrækket leveres på CPR ftp platform og hentes via sftp af Serviceplatformen som beskrevet i

https://cpr.dk/kunder/produktdokumentation,-guides-og-tjeklister/ftp-(cpr-udtraek)/




3 Specifikation for integrationsparter

SF1320_A indeholder følgende integrationsparter:

Kommunernes Ydelsessystem, der modtager information om personhændelser via Besked-

fordeler. Kommunernes Ydelsessystem beskrives i afsnit 3.1.

Kommunernes Sygedagpengesystem, der modtager information om personhændelser via

Beskedfordeler. Kommunernes Sygedagpengesystem beskrives i afsnit 3.1.

SAPA, der modtager information om personhændelser via Beskedfordeler. SAPA beskrives

i afsnit 3.1.

CPR som leverer ændringsudtræk for persondata, som anvendes af Serviceplatformen.

CPR beskrives i afsnit 3.2.

Integrationen mellem Serviceplatformen og Beskedfordeler beskrives i afsnit 3.3.

Sammenhængen mellem endpoints er illustreret i afsnit 4.1.

3.1 Specifikation af endpoints for fagsystem KY, KSD, SAPA[!@KY@!][!@KSD@!] [!@SAPA@!]

Integrationen benyttes af fagsystemet til at modtage beskeder med ændringer i personoplysninger

fra Beskedfordeler. Fagsystemet benytter også integrationen til at vedligeholde værdilister på Be-

skedfordeler.

3.1.1 Overordnet forretningslogik

Fagsystemet modtager beskeder om ændringer i personoplysninger fra Beskedfordeler:

Fagsystemet modtager beskeder (push / pull) via EP_FS1

Fagsystemet opretter og vedligeholder et abonnement (værdiliste) på Beskedfordeler via

EP_FS2

3.1.2 Oversigt over endpoints

ID Navn

EP_FS1 ModtagBesked (ændringer til personoplysninger) [SF1460_A/SF1460_D]

EP_FS2 AdministrerVaerdiliste [SF1460_B]

3.1.3 Beskrivelse af endpoint EP_FS1 – ModtagBesked

Beskrivelsen af endpoint findes i Modtag besked [SF1460_A] og Modtag besked via pull

[SF1460_D]. Fagsystemet vælger selv om der benyttes pull eller push.

Beskedfordeler udstiller beskeder fra CPR. Endpoint benyttes af fagsystemerne i forbindelse med

ændringer i personoplysninger.




3.1.3.1 Abonnementsvilkår

Fagsystemet skal oprette abonnement på beskedtypen ’CPRopdatering’.

Beskedernes objekt er ”Person” identificeret med CPR-nummer.

Beskeden kan indeholde 7 relaterede objekter i denne orden:

0) CPR hændelseskode (urn 3 karakterer)

1) Mor (CPR-nr)

2) Far (CPR-nr)

3) Ægtefælle eller tidl. Ægtefælle (CPR-nr)

4) Barn (CPR-nr)

5) Gammelt CPR eller dobbelt (CPR-nr)

6) Adresse (urn)

Hvor det er muligt at udvælge det man ønsker i abonnementet. Adresse-urn er defineret som

urn:oio:adresse:nnnn;nnnn,aaaa;aa;aaaa;aaaa, hvilket er KOMKOD, VEJKOD, HUSNR,

ETAGE,SIDEDOER og BNR fra CPR-udtræksformat record 3. Dette vil give en entydig adresse i

urn’en.

Hvis man kun ønsker at få CPRopdateringer på de personer, som er tilknyttet fagsystemet, skal

fagsystemet vedligeholde en værdiliste med personkreds, som navngives ”Personkreds”. Værdili-

sten vedligeholdes som angive i afsnit Fejl! Henvisningskilde ikke fundet..

Tilsvarende kan fagsystemet tilknytte en adresseobservationsliste, hvor man vedligeholder en liste

med adresse-urn’er for de adresse som man ønsker at modtage CPRopdateringer på, kaldet

”Adresser”.

Eksempler på abonnementsudtryk:

”Giv alle beskeder, hvor personer er i værdilisten ’Personkreds’”:

Forretningsobjektets type er ”Person”, der har et UUID ”126667fa-edeb-40c6-9288-

58bb7de17a7b”.

Personkreds er vedligeholdt i en liste med navnet ”Personkreds”.

Match udtrykket bliver da:

((Haendelsesbesked.Beskedkuvert.Filtreringsdata.ObjektRegistrering[0].Obj

ektType = “126667fa-edeb-40c6-9288-58bb7de17a7b”) AND

(Haendelsesbesked.Beskedkuvert.Filtreringsdata.ObjektRegistrering[0].Obje

ktId IN @Personkreds))

”Giv alle beskeder, hvor relaterede personer er i værdilisten ’Personkreds’”:

Forretningsobjektets type er ”Person”, der har et UUID ”126667fa-edeb-40c6-9288-

58bb7de17a7b”.




Personkreds er vedligeholdt i en liste med navnet ”Personkreds”.


(((Haendelsesbesked.Beskedkuvert.Filtreringsdata.RelateretObjekt[1].Objek

tType = “126667fa-edeb-40c6-9288-58bb7de17a7b”) AND

(Haendelsesbesked.Beskedkuvert.Filtreringsdata.RelateretObjekt[1].ObjektI

d IN @Personkreds)) OR

((Haendelsesbesked.Beskedkuvert.Filtreringsdata.RelateretObjekt[2].Objekt

Type = “126667fa-edeb-40c6-9288-58bb7de17a7b”) AND


d IN @Personkreds))OR












d IN @Personkreds)))

”Giv alle beskeder, hvor relaterede adresser er i værdilisten ’Adresser’”:

Forretningsobjektets type er ”Adresse”, der har et UUID ”<Indsæt UUID for ”Adresse”>”.

Adresselisten er vedligeholdt i en liste med navnet ”Adresser”.



Type = “<Indsæt UUID for ”Adresse”>”) AND


d IN @Adresser))

”Giv alle beskeder, hvor beskedhandling er ”Fødsel”:

Forretningsobjektets handling er ”Fødsel”, der har et UUID ”<Indsæt UUID for ”Fødsel”>”.


((Haendelsesbesked.Beskedkuvert.Filtreringsdata.ObjektRegistrering[0].Obj

ektHandling = “<Indsæt UUID for ”Fødsel”>”))




3.1.3.2 Dataspecifikation

For beskedtyper og beskedindhold se beskrivelse i afsnit 4.1.2.4.

3.1.4 Beskrivelse af endpoint EP_FS2 – AdministrerVaerdiliste

Beskrivelsen af endpoint findes i Vedligehold værdiliste i beskedabonnement [SF1460_B].

Beskedfordeler udstiller administrationsinterface til vedligehold af værdilister i beskedabonnemen-

ter. Endpoint kaldes af fagsystemerne i forbindelse med vedligehold af værdilister i beskedabonne-

ment.

Kapitel 3.x.y.z Værdiliste

Fagsystemerne skal vedligeholde værdilister for de personkredse og adresselister, det ønsker at

abonnere på.

Værdilisterne skal oprettes med følgende navn:

Personkreds – ”Personkreds”

Adresseliste – ”Adresser”

Service Management

Beskrivelsen af Service Management findes i Modtag besked [SF1460_A], Modtag besked via pull

[SF1460_D] og Vedligehold værdiliste i beskedabonnement [SF1460_B].

3.2 Specifikation af endpoints for CPR

Serviceplatformen modtager dagligt en liste af personændringer fra CPR.


Hvert døgn udstiller CPR ændringer i personoplysninger, udtrækket udstiller alle ændringer og re-

turnerer alle rækker. Serviceplatformen modtager således en fuld kopi af personens nuværende

oplysninger fra CPR ved hver ændring.

Serviceplatformen henter ændringerne fra CPR ftp service (EP_CPR1) og Serviceplatformen op-

daterer det lokale cpr replika og udsender beskeder om ændringer i det fælleskommunale støttesy-

stem Beskedfordeler.


ID Navn

EP_CPR1 Modtag ændrede persondata fra CPR. EP_CPR1 svarer til den eksisterende integration

mellem Serviceplatformen og CPR.




3.2.3 Beskrivelse af endpoint EP_CPR1

3.2.3.1 Transportspecifikation

3.2.3.1.1 Integrationsmønster

Integration til CPR fra Serviceplatformen via filoverførsel

3.2.3.1.2 Serviceudstiller

CPR er serviceudstiller

3.2.3.1.3 Serviceanvender

Serviceplatformen er serviceanvender

3.2.3.1.4 Teknologisk understøttelse

CPR Snitfladen er implementeret som en filoverførsel. CPR giver mulighed for sikkerhedsopsæt-

ning via SFTP eller FTPS: I denne integration anvendes SFTP.

Se flere detaljer på:


3.2.3.1.5 Teknisk endpoint

Miljø: Produktion

URI til WSDL [Besvares senere af Systematic]

Endpoint navn

Endpoint IP

Miljø: Præproduktion

URI til WSDL [Besvares senere af Systematic]

Endpoint navn

Endpoint IP

3.2.3.1.6 Teknisk retning for udveksling

Serviceplatformen henter ændringsudtræk hos CPR.

3.2.3.1.7 Dataretning for udveksling

CPR udstiller ændringer til Serviceplatformen.

3.2.3.1.8 Service invokation / Triggers

Kommunikation initieres af at Serviceplatformen en gang i døgnet.





Dataformatet er baseret på U12170-p, der modtages alle recordtyper. Udtrækket er identisk med

den eksisterende integration til CPR abonnement.

Se https://cpr.dk/kunder/offentlige-myndigheder/udtraek/dokumentation-for-udtraek-til-offentlige/

3.2.3.3 Sikkerhed

Sikkerhed er baseret på SFTP.

3.2.3.4 Leverancesikkerhed og fejlhåndtering

Serviceplatformen skal hente alle ændringer til personnumre, samt håndtere fejl som er angivet i

recordtype 910 i udtrækket.

3.2.3.5 Servicemål

Følgende underafsnit indeholder oplysninger vedrørende servicemål for aftalt driftstid.

3.2.3.5.1 Aftalt driftstid

Parameter Værdi

Tidsrum [Udfyldes med tidsrummet hvor der sikres normal drift]

Svartid [Udfyldes med angivelse af det maksimale svartid for dataud-

vekslingen.]

Tilgængelighed [Udfyldes med krav til oppetid inden for aftalt driftstid – fx 99,5

pct.]

Spidsbelastningsperiode [Udfyldes med tidsrummet hvor, der forventes spidsbelastning.]

Servicevinduer [Udfyldes med oplysninger om aftalte servicevinduer og varsling

af nedetid.]



[Indhold afventer generel afklaring af governancestrukturer.]





https://cpr.dk/kunder/offentlige-myndigheder/udtraek/dokumentation-for-udtraek-til-offentlige/




3.2.5 Testplan

3.2.5.1 Integrationstest

[Indhold afventer generel afklaring af test]

3.2.5.2 Produktionssætningstest


3.3 Specifikation af endpoints for Serviceplatformen som afsendende beskedagent [!@Systematic@!]

Integrationen benyttes af Serviceplatformen til at sende CPRopdateringsbeskeder til Beskedforde-

ler.


Serviceplatformen beregner og sender CPRopdateringsbeskeder til Beskedfordeler:

Serviceplatformen kalder EP_SP1

Beskedfordeler returnerer et synkront svar til afsender


ID Navn

EP_SP1 AfsendBesked

3.3.3 Beskrivelse af endpoint EP_SP1 – AfsendBesked

Beskrivelsen af endpoint findes i Aflever besked [SF1460_C].

Serviceplatformen sender CPRopdateringsbeskeder. Endpoint kaldes ved ændring i CPR.


En besked består af en kuvert og et beskedindhold.

3.3.3.1.1 Beskedkuverten dataspecifikation

Dataspecifikationen for beskedkuverten findes i følgende schema-filer:

Miljø: Produktion og Test

Inputdata Se [SF1460_C]

Outputdata Se [SF1460_C]




Beskedkuverten udfyldes som beskrevet i afsnit 4.1.2.4.

3.3.3.1.2 Beskedindhold dataspecifikation

Dataspecifikationen for indholdet af selve beskeden findes i følgende schema-filer:

Miljø: Produktion og Test

Inputdata Se [SF1520]

Outputdata


Beskrivelsen af Service Management findes i Aflever besked [SF1460_C].




4 Beskrivelse for integrationsplatforme

4.1 Beskrivelse for Serviceplatformen [!@Systematic@!]

Nærværende afsnit angiver den integrationsfunktionalitet, som Serviceplatformen håndterer i inter-

aktionen mellem integrationsparterne. Snitfladerne er defineret således i forhold til forretningsflo-

wet.

En integration kan understøttes af flere integrationsflow, som vil være beskrevet hver for sig i nær-

værende afsnit. I hvert integrationsflow vil der indgå en række endpoints. Hvert endpoint vil være

specificeret i integrationsbeskrivelserne for integrationsparterne, jf. ovenstående afsnit 3.

Jf. figuren nedenfor indgår følgende komponenter og endpoints i integrationen.

IF01CPR

Serviceplatformen

EP_CPR1

Fagsystem(n)

SF1460_A/D

EP_FS1SF1460_B

EP_FS2

Beskedfordeler

EP_SP1

SF1460_C

4.1.1 Oversigt over integrationsflows

ID Navn

IF01 Hent og Distribuer CPR Hændelser

4.1.2 Integrationsflow [IF01]: Hent CPR Hændelser

4.1.2.1 Anvendte service endpoints

Endpoint ID Navn på endpoint Dokument-reference

EP_CPR1 Snitflade til at afhente personhændelser. Afsnit 3.2.3




EP_SP1 Snitflade til aflevere beskeder om personhændelser. Afsnit Fejl! Henvis-

ningskilde ikke fun-

det.

4.1.2.2 Integrationstype

Integrationen er en beskedagentintegration med transformation.

Forretningsbeskeder udsendes via det fælleskommunale støttesystem Beskedfordeler

[SF1460_C].

4.1.2.3 Diagram over integrationsflowet

Jf. figuren nedenfor indgår følgende integrationsflows i integrationen.

Fagsystem(n) Beskedfordeler Serviceplatformen CPR

Hent CPR Udtræk

EP_CPR1

Gentag indtil alt sendt

4.1.2.4 Datatransformering

Data skal transformeres fra CPR’s GCTP format til xsd format i beskeder som afsendes via det

fælleskommunale støttesystem Beskedfordeler.

Beskedkuverten skal udfyldes, således at det er muligt at abonnere på ændringer.

Værdier angivet med ” ” er faste værdier, der skal sættes ind i Beskedkuverten. Andre værdier skal

afsendersystemet selv udfylde.

[De fleste Id’er er baseret på UUID dog med undtagelse af:

KLE - urn:oio:kle:nn.nn.nn

CPR - urn:oio.cpr:nnnnnnnnnn

CVR - urn:oio:cvr:nnnnnnnn

PNR – urn:oio:pnr:nnnnnnnnnn

Fuldtnavn - urn:oio:fuldtnavn:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Adresse - urn:oio:adresse:nnnn;nnnn,aaaa;aa;aaaa;aaaa




da disse ikke repræsenteret af et UUID og derfor skal benytte urn.]

[Afklaring/KDF: Endelig definition af urn]

Element Beskrivelse Værdifelt udfyldelse

Filtreringsdata

Beskedtype ”CPRopdatering” [Afklaring/KDF: UUID for beskedtypen

”CPRopdatering”]

BeskedAnsvarligAktør Det it-system, der afsender

beskeden, er CPR

[Afklaring/KDF: UUID for it-systemet CPR]

TilladtModtager Borgerenes bopælskom-

mune

Tomt

RelateretObjekt[0] ”CPR Hændelseskode”

ObjektId CPR hændelseskode på 3

tegn

[Afklaring/KDF: urn for CPR hændelses-

kode]

ObjektType Forretningsobjektet ”CPR

Hændelseskode”

[Afklaring/KDF: UUID for forretningsobjek-

tet ”CPRhændelseskode”]

ObjektRolle Tomt

RelateretObjekt[1] ”Mor”

ObjektId CPR-nummer på ”Mor” ”urn:oio:cpr:nnnnnnnnnn” (hvor

nnnnnnnnnn erstattes med 10-cifret CPR-

nummer uden bindestreg)

ObjektType Forretningsobjektet ”Per-

son”


tet ”Person”]

ObjektRolle

RelateretObjekt[2] ”Far”

ObjektId CPR-nummer på ”Far” ”urn:oio:cpr:nnnnnnnnnn” (hvor







son”


tet ”Person”]

ObjektRolle

RelateretObjekt[3] ”Ægtefælle (evt. tidligere)”

ObjektId CPR-nummer på ægtefælle ”urn:oio:cpr:nnnnnnnnnn” (hvor




son”


tet ”Person”]

ObjektRolle

RelateretObjekt[4] ”Barn”

ObjektId CPR-nummer på barn ”urn:oio:cpr:nnnnnnnnnn” (hvor




son”


tet ”Person”]

ObjektRolle

RelateretObjekt[5] ”Gammelt/Dobbelt CPR”

ObjektId Gammelt CPR-nummer på

borgeren

”urn:oio:cpr:nnnnnnnnnn” (hvor




son”


tet ”Person”]

ObjektRolle

RelateretObjekt[6] ”Adresse”

ObjektId Adresse [Afklaring/KDF:

”urn:oio:adresse:nnnn;nnnn,aaaa;aa;aaaa;

aaaa”]

ObjektType Forretningsobjektet

”Adresse”

[Afklaring/KDF: Indsæt UUID for forret-

ningsobjektet ”Adresse”]




ObjektRolle

Objektregistrering

ObjektRegistreringId Identifikation af hændelsen,

der ligger til grund for be-

skeden.

[Afklaring/KDF: urn:kombit:cpr-tran-

sid:nnnnnn-nnnnnn for CPR udtræk id – re-

cord 000 OPGAVENR-PRODDTO]

RegistreringsAktoer Det it-system, der har gene-

reret hændelsen, er SP

[Afklaring/KDF: UUID for SP]

Registreringstidspunkt Tidspunkt for hændelsens

udsendelse fra kilden

SP’s tid i DateTime format

ObjektAnsvarligMyndighed Borgerenes bopælskom-

mune (CVR)

”urn:oio:cvr:nnnnnnnn” (hvor nnnnnnnn

er et 8-cifret CVR nummer).

ObjektId Borgerens CPR-nummer ”urn:oio:cpr:nnnnnnnnnn” (hvor




son”

[Afklaring/KDF: UUID for ”Person”]

ObjektHandling Handlingen ”CPRopdate-

ring”

[Afklaring/KDF: UUID for ”CPR-001” –

”CPR-041”]

OpgaveEmne

Leveranceinformation

Dannelsestidspunkt Tidspunkt hvor beskeden

opstod


Sikkerhedsklassificering Klassificeringen f.eks. ”Per-

sonfølsomt”

[Afklaring/KDF: UUID for ”Personfølsomt”]

GyldighedFra Tidspunkt hvor hændelsen

skal gælde fra


De relaterede objekter udfyldes forskelligt ud fra handlingstypen.

[Afklaring/KDF: Nedenstående tabel angiver de 5 felter i kuverten, som skal udfyldes forskelligt for

specifikke hændelser for personer (CPR-001 til CPR-041) – er under opdatering af SAPA – skal

indeholde klare regler for generering af beskeder].




Felter markeret i citationstegn (””) angiver at det er en statisk tekststreng som er ens for alle be-

skeder. Felter markeret med (tom) betyder at feltet ikke skal udfyldes for alle beskeder.

Personen som ændres skal være indeholdt som en objektregistrering, adresse er indeholdt som et

relateret objekt. Tilknytningskommune, bopælskommune og fraflytningskommune er angivet som

ObjektAnsvarligMyndighed og TilladtModtager.

ID fra afsnit 1.2.3 Beskedtype Beskedtypetekst RelateretObjek

t

ObjektAnsvarli

gMyndighed

TilladtModtage

r

Ændring af regi-

strering CPR-001

Ændring af regi-

strering

URN på tilflytnings-

adresse

Fraflytningskom-

mune Tilflytningskommune

Fødsel CPR-002 Fødsel (tom) Bopælskommune (tom)

Navngivning CPR-003 Navngivning (tom) Bopælskommune (tom)

Navneændring CPR-004 Navneændring (tom) Bopælskommune (tom)

Dødsfald CPR-005 Dødsfald (tom) Bopælskommune (tom)

Dødsfald - som

forsvundet CPR-006

Dødsfald - som for-

svundet (tom) Bopælskommune (tom)

Dødsfald - som

udvandret CPR-007

Dødsfald - som ud-

vandret (tom) Bopælskommune (tom)

Dødsfald som ny-

født CPR-008

Dødsfald som ny-

født (tom) Bopælskommune (tom)

Dødsfald – ægte-

fælle CPR-009

Dødsfald – ægte-

fælle (tom) Bopælskommune (tom)

Forsvinding CPR-010 Forsvinding URN på fraflytnings-

adresse

Fraflytningskom-


Genfinding CPR-011 Genfinding URN på tilflytnings-

adresse

Fraflytningskom-


Indvandring CPR-012 Indvandring URN på tilflytnings-

adresse

Fraflytningskom-


Udvandring CPR-013 Udvandring URN på fraflytnings-

adresse

Fraflytningskom-


Genindvandring CPR-014 Genindvandring URN på tilflytnings-

adresse

Fraflytningskom-


Nynummerering CPR-015 Nynummerering (tom) Bopælskommune (tom)

Omnummerering

nyt nummer CPR-016

Omnummerering

nyt nummer (tom) Bopælskommune (tom)

Sletning af per-

sonnummer CPR-017

Sletning af person-

nummer (tom) Bopælskommune (tom)




Tidligere dobbelt

nummer CPR-018

Tidligere dobbelt

nummer (tom) Bopælskommune (tom)

Udgår grundet

omnummerering CPR-019

Udgår grundet om-

nummerering (tom) Bopælskommune (tom)

Myndiggørelse CPR-020 Myndiggørelse (tom) Bopælskommune (tom)

Umyndiggørelse CPR-021 Umyndiggørelse (tom) Bopælskommune (tom)

Folkekirketilknyt-

ning ændret CPR-022

Folkekirketilknyt-

ning ændret (tom) Bopælskommune (tom)

Statsborgerskab

ændret CPR-023

Statsborgerskab

ændret (tom) Bopælskommune (tom)

Faderskab – far CPR-024 Faderskab – far (tom) Bopælskommune (tom)

Fødsel – mor CPR-025 Fødsel – mor (tom) Bopælskommune (tom)

Faderskab – barn CPR-026 Faderskab – barn (tom) Bopælskommune (tom)

Adoption – barn CPR-027 Adoption – barn (tom) Bopælskommune (tom)

Vielse CPR-028 Vielse (tom) Bopælskommune (tom)

Separation startet CPR-029 Separation startet (tom) Bopælskommune (tom)

Separation ophørt CPR-030 Separation ophørt (tom) Bopælskommune (tom)

Skilsmisse CPR-031 Skilsmisse (tom) Bopælskommune (tom)

Ændring vedrø-

rende ægtefælle CPR-032

Ændring vedrø-

rende ægtefælle (tom) Bopælskommune (tom)

Ændring vedrø-

rende slægtskab CPR-033

Ændring vedrø-

rende slægtskab (tom) Bopælskommune (tom)

Flytning til kom-

munen CPR-034

Flytning til kommu-

nen


adresse, URN på fra-

flytningsadresse

Fraflytningskom-


Flytning fra kom-

munen CPR-035

Flytning fra kom-

munen



flytningsadresse

Fraflytningskom-


Fraflytning inden-

for kommunen CPR-036

Fraflytning indenfor

kommunen



flytningsadresse

Fraflytningskom-


Tilflytning inden-

for kommunen CPR-037

Tilflytning indenfor

kommunen



flytningsadresse

Fraflytningskom-


Indkaldelse til mi-

litæret CPR-038

Indkaldelse til mili-

tæret

URN på bopæls-

adresse Bopælskommune Bopælskommune




Hjemsendelse fra

militæret CPR-039

Hjemsendelse fra

militæret

URN på bopæls-


Start afsoning CPR-040 Start afsoning URN på bopæls-


Slut afsoning CPR-041 Slut afsoning URN på bopæls-


Beskedindholdet’s XSD skal være tilsvarende XSD fra SF1520. Systematic skal eventuelt udar-

bejde et forslag til XSD for beskedindholdet i beskeddata for persondata, som modtages i forbin-

delse med en ændring modtaget fra CPR.

Beskedkuverten i hver besked skal indeholde ”Hændelseskoden” fra cpr udtrækket, såfremt et æn-

dringsudtræk fra CPR indeholder flere hændelseskoder, så skal der udløses en besked for alle

hændelseskoder, ud fra forretningsreglerne. CPR-001er en generel CPR-ændring og skal kun ud-

løses én gang per CPR-nummer, og kan benyttes til at opdatere et lokalt replika af CPR. Besked-

indhold er altid det nye dataindhold i SP’s CPR replika.

4.1.2.5 Datapersistering

Det lokale replika skal opdateres med ændringer modtaget fra CPR.

Beskeder skal opbevares indtil de er modtaget af Støttesystemet Beskedfordeler.

4.1.2.6 Databerigelse

Data beriges ikke, men transformeres jf. afsnit 4.1.2.4.

4.1.2.7 Routing

Ændringer i CPR vil medføre en eller flere beskeder jf. transformeringen i afsnit 4.1.2.4

4.1.2.8 Orkestrering

N/A

4.1.2.9 Sikkerhed

Der er sikkerhedsopsætning i EP_CPR1, EP_SPB1, EP_FS1 og EP_FS2.

EP_CPR1 er en integration, hvor serviceplatformen henter ændringer hos CPR. Systematic skal

anvende SFTP for at afhente det ændringer.

Sikkerhedsopsætningen hos CPR er dokumenteret i https://cpr.dk/kunder/produktdokumentation,-

guides-og-tjeklister/ftp-(cpr-udtraek)/






EP_SPB1 er en integration til det fælleskommunale støttesystem Beskedfordeler. Serviceplatfor-

mens service skal oprettes som et anvendersystem og være autoriseret til at sende personbeske-

der. Integrationsmønsteret skal følge UC-SEC-04 og benytte Tokens til autentificering og autorise-

ring mellem Serviceplatform og Beskedfordeler.

4.1.2.10 Logning

Det skal logges at beskeder er modtaget af det fælleskommunale Støttesystem Beskedfordeler.

4.1.2.11 Testdata og testfaciliter


4.1.2.12 Konfiguration

Det skal være muligt for en systemadministrator at administrere hvilke forretningshændelser som

beskrevet i afsnit 1.2.3 som er aktive/inaktive. Det skal være muligt at tilføje og fjerne forretnings-

hændelser.

4.1.2.13 Supplerende information

Ingen

Integration SF1320 A - CPR - Hændelser · CPR-041 Slut afsoning Notatlinje 3 eller 4 udfyldt...

Documents

Transcript of Integration SF1320 A - CPR - Hændelser · CPR-041 Slut afsoning Notatlinje 3 eller 4 udfyldt...