Modernisering af CPR Opdateringsservices
FormÄl
Som led i den lÞbende modernisering af CPR-systemet konverteres CPR Services til en Java-platform, hvilket medfÞrer tilpasninger og Êndringer. Moderniserede versioner af services vil blive frigivet lÞbende. I en overgangsperiode vil bÄde den 'gamle' service og den 'nye' service blive udstillet.
Denne side beskriver, hvad der er nyt ved de moderniserede services, og hvordan disse services kan testes.
Scope
Denne side henvender sig specifikt til private kunder af CPR's opdateringsservices og deres behov. Derfor vil siden indeholde mindre information, end hvad der er relevant for offentlige kunder, som i stedet henvises til https://cprservicedesk.atlassian.net/wiki/spaces/EXMYN/pages/2292514823 .
Hvad er nyt?
De moderniserede services indeholder fÄ, mindre Êndringer i den overordnede GCTP-protokol og i de enkelte services.
I hovedsagen ĂŠndres fĂžlgende i GCTP-protokollen:
GCTP behandles som XML, og derfor skal bÄde GCTP-forespÞrgsler og -svar vÊre velformede XML-dokumenter jf. https://www.w3.org/TR/xml/#sec-well-formed .
GCTP-forespĂžrgsler valideres for at sikre, at forespĂžrgselsindholdet er gyldigt jf. GCTP XSD-skemaet.
FormÄlet med Êndringerne er at sikre, at bÄde CPR's egne systemer samt andre fagsystemer kan benytte standardiserede XML-vÊrktÞjer og tredjepartsbiblioteker, nÄr de integreres med CPR Services. XML fordrer ikke, at elementerne i XML-dokumenterne er i en bestemt rÊkkefÞlge, sÄ rÊkkefÞlgen pÄ elementerne kan afvige fra den rÊkkefÞlge, som elementerne havde i de nuvÊrende services.
Lokale tilpasninger og forberedelse
Anvendertest og anvenders risikomitigering
Anvendere af CPRâs services er selv ansvarlige for at vurdere risikoen for egen virksomhed, bl.a. risikoen for, at forespĂžrgsler ikke bliver accepteret grundet ugyldig XML eller GCTP, samt at der indrapporteres forkerte data i tilfĂŠlde, hvor manuel indtastning nu er pĂ„krĂŠvet, osv. Det anbefales, at der foretages en grundig test af de anvendte services fra anvenderside.
GCTP ajourfĂžrende services konverteres som udgangspunkt 1:1 i forhold til eksisterende natural services, dog med en rĂŠkke undtagelser.
GCTP AjourfĂžrende services snitflade er XML baseret
Da XML ikke fordrer nogen specifik rĂŠkkefĂžlge af elementer, vil elementerne i den nye snitflade ikke nĂždvendigvis forefindes i samme rĂŠkkefĂžlge i requests og responses
Tabeller i GCTP skal identificeres med nĂžgler, igen fordi XML ikke fordrer en rĂŠkkefĂžlge
Attributter, der tidligere har vĂŠret behandlet som tomme (f.eks. a=ââ), vil blive opfattet som nullvĂŠrdier. I XML vil attributter med nullvĂŠrdier ikke vĂŠre til stede
Elementer, der indeholder koder (f.eks. myndighedskode), vil altid have de samme attributter med ud pÄ elementet, f.eks. t og tl
Der anvendes et simplificeret tegnsĂŠtsregelsĂŠt som beskrevet i dokumentationen
Services kĂžrer udelukkende med ISO-8859-1 som tegnsĂŠt
Der kan forekomme smÄ afvigelser i forretningslogikken som fÞlge af Êndringer i den enkelte service
XML-parser
Den klare forventning er, at anvendere, som bruger tidssvarende og standardiserede XML-parsere, ikke vil have behov for at foretage lokale tilpasninger.
Anvendere, der bruger en selvudviklet XML-parser, bĂžr foretage en grundig test.
Dokumentation af services
Dokumentation af de relevante services findes i Servicebeskrivelser . Hvis I anvender en service, som ikke findes pÄ listen, skal I kontakte CPRs servicedesk om den manglende servicebeskrivelse for opdateringsservices, der henvender sig til private.
Endvidere henvises der til servicehÄndbogen for en generel beskrivelse af integration med GCTP-services.
Overgang til moderniserede CPR Services
Overgangen til moderniserede services foretages med fokus pÄ risikomitigering.
Moderniserede services vil benytte en ny GCTP-protokolversion - version 2.0.
Kald, der i dag modtages med version 1.0 eller uden versionsnummer i <Gctp>
-tagget, vil fortsat blive betjent af den 'gamle' service i servicens overgangsperiode.
NÄr overgangsperioden er udlÞbet, vil den gamle serviceversion blive lukket, og alle kald til den pÄgÊldende service vil herefter blive betjent af en moderniseret service - uanset versionsnummer i <Gctp>
-tagget.
Default service
FĂžr overgangsperioden (fĂžr release): Standard servicen er den gamle service. Det er ikke muligt at benytte version 2.0 service.
Under overgangsperioden: Standard servicen er stadig den gamle service. Det er muligt at benytte version 2.0 service.
Under udfasningsperioden: Standard servicen er den nye 2.0 service. Det er ikke muligt at benytte den gamle service. CPR forbeholder sig retten til uden varsel at rulle tilbage til "overgangsperioden", hvor den gamle service er standard.
Efter udfasningsperioden: Standard servicen er den nye 2.0 service. Det er ikke muligt at benytte den gamle service, og der kan ikke rulles tilbage til den gamle service.
BemĂŠrk: Efter overgangsfasen kan og vil CPR uden varsel og kommunikation ĂŠndre den standard service, der betjener servicekald uden versionsnummer i tagget.
Anvenders lokale tilpasninger skal derfor tage hĂžjde for, at standard servicen kan ĂŠndres uden varsel efter overgangsperioden.
Anvendertest
I overgangsperioden vil anvendere have mulighed for at teste integrationen med de moderniserede services. Se mere i afsnittet 'VĂŠrktĂžjer til test af ĂŠndringer i CPR Services'.
TilgĂŠngelighed og modernisering
Der er fokus pÄ at fastholde systemets tilgÊngelighed i hele forlÞbet.
Strategien herfor er fĂžlgende:
1:1 konvertering af en service
Hvor det er muligt og hensigtsmÊssigt, foretages der ikke Êndringer til servicens requests og responses. Dette vil gÊlde for de fleste services. Derfor forventes det ogsÄ, at de fleste ajourfÞringsservices konverteres pÄ en sÄdan mÄde, at der i hovedsagen ikke foretages Êndringer, der pÄvirker servicens requests og responses.
Imidlertid anvendes CPRâs ajourfĂžringsservices ikke helt identisk pĂ„ tvĂŠrs af private og offentlige kunder. Det mĂ„ derfor forventes, at nogle anvendere vil opfatte dette som en ĂŠndring.
Services, der konverteres 1:1, vil i en periode vÊre i drift samtidigt med bÄde en Java (ny) version og en Natural (gammel) version.
Afvigelser til ajourfĂžrende services
I forbindelse med konverteringen af services er der foretaget en rĂŠkke mindre afvigelser for at ensarte og simplificere anvendelsen. Hver af disse afvigelser er beskrevet herunder.
Tabeller
En rÊkke GCTP-services understÞtter indberetning af data i tabeller, hvor der sÄledes kan vÊre flere rÊkker. I den gamle version af GCTP er der ikke et krav om, at hver rÊkke skal vÊre identificeret med en nÞgle, men dette er et krav ved anvendelse af tabeller i de moderniserede GCTP-services. NÞgler skal altid udfyldes, og de nÞgler, som en GCTP-service eventuelt har udstedt under initiering, skal anvendes.
NĂžglerne skal vĂŠre unikke.
En rÊkke i GCTP fÞr modernisering kunne eksempelvis fremstÄ som vist herunder, hvor det Þnskes at foretage en ny registrering af notatlinje 1 i de kommunale notater.
<Rolle r="HovedRolle">
<Table r="Notatlinier" >
<Row>
<Field r="CNTA_SLETDATO"/>
<Field r="CNTA_NOTATLINIE" v="Eksempel tekst"/>
<Field r="CNTA_STARTDATO" v="20220101"/>
<Field r="CNTA_NOTATNR" v="01"/>
<Field r="CNTA_STARTMYNKOD" v="0012" a="S" t="ATP"/>
</Row>
</Table>
</Rolle>
I den moderniserede GCTP skal k attributten vĂŠre udfyldt med en unik nĂžgle, herunder med vĂŠrdien k="NOTAT1_NOEGLE"
<Rolle r="HovedRolle">
<Table r="Notatlinier" >
<Row k="NOTAT1_NOEGLE">
<Field r="CNTA_SLETDATO"/>
<Field r="CNTA_NOTATLINIE" v="Eksempel tekst"/>
<Field r="CNTA_STARTDATO" v="20220101"/>
<Field r="CNTA_NOTATNR" v="01"/>
<Field r="CNTA_STARTMYNKOD" v="0012" a="S" t="ATP"/>
</Row>
</Table>
</Rolle>
Character Encoding
Der understĂžttes kun ISO-8859-1-kodning.
Ensartet anvendelse af xml attributter i GCTP
I de nuvĂŠrende services kunne enkelte elementer i GCTP-strukturen blive behandlet forskelligt, men dette er ensrettet i den nye GCTP-protokol, sĂ„ledes at attributter pĂ„ det enkelte XML-element opfĂžrer sig ens. For eksempel kan man i services opleve, at en attribut har en tom vĂŠrdi: tl=ââ. I den nye protokol vil denne attribut blive betragtet som null og derfor slet ikke vĂŠre til stede pĂ„ elementet. Elementer, som indeholder koder, for eksempel myndighedskoder, vil altid have de samme tekstattributter medfĂžlgende. For eksempel t=âKĂžbenhavnâ.
Endvidere er der nu krav til felter, som er markeret som obligatoriske, at disse skal sendes ind i forbindelse med servicekald for at sikre, at en anvender af servicen forholder sig til indholdet i feltet. Tidligere har nogle services accepteret, at disse ikke indsendes, og i stedet anvendt den vÊrdi, der var fremkommet under initiering. Nu er det pÄkrÊvet.
VĂŠrktĂžjer til test af ĂŠndringer i CPR Services
FĂžlgende vĂŠrktĂžjer kan anvendes til at understĂžtte overgangen til de moderniserede services (version 2.0 eller nyere).
GCTP 2.0 XSD skema
Skemaer for GCTP version 2.0 kan anvendes til at validere GCTP-forespĂžrgsler.
Filer sidst opdateret 29. februar 2024 kl. 14.32
Request validering i DEMO-miljĂžet (CPRâs kundevendte testmiljĂž)
Kunder kan med fordel kalde GCTP-valideringsendpointet i DEMO-miljÞet for at teste egen integration med de moderniserede services. URL'en til endpointet er https://gctp-demo.cpr.dk/cpr-online-gctp/validate. Endpointet kan tilgÄs uden session (login) og krÊver, at forespÞrgslen indsendes via POST-metoden.
Eksempel gyldigt request/respons
De fleste vĂŠrdier i forespĂžrgslen, som fx System
og Service
, har ingen betydning i forbindelse med validering alene. ForespĂžrgslen skal blot overholde GCTP-skemaet.
curl -i https://gctp-demo.cpr.dk/cpr-online-gctp/validate -d '
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<root xmlns="http://www.cpr.dk">
<Gctp v="2.0">
<System r="CprSoeg">
<Service r="STAMP">
<CprServiceHeader r="STAMP">
<Key>
<Field r="PNR" v="..."/>
</Key>
</CprServiceHeader>
</Service>
</System>
</Gctp>
</root>
'
GCTP-forespĂžrgslen er gyldig, og der returneres et <Kvit>
-element i svaret:
Eksempel pÄ ugyldig request/respons
Eksempel hvor forespĂžrgslen ikke overholder XML-standarden: </ CprServiceHeader>
i stedet for </CprServiceHeader>
GCTP-forespĂžrgslen er ugyldig, og der returneres <Kvit>
-elementet i responsen, hvor attributten v
har vĂŠrdien 999
, og attributten t
har en vĂŠrdi, der beskriver valideringsfejlen.
Serviceoversigt
Dette afsnit giver et overblik over de CPR-opdateringsservices, der anvendes af private brugere, samt deres moderniserede ĂŠndringer og vigtige datoer for overgangsperioden og udfasningsperioden.
Generelle ĂŠndringer
Herunder findes en liste med en opsummering af de generelle ĂŠndringer, der er foretaget i forbindelse med konverteringen af GCTP-ajourfĂžringsservices. Disse ĂŠndringer er beskrevet i detaljer i de tidligere afsnit. NĂžgleordene anvendes som referencer i konverteringsplanens tabel.
Ăndringer (nĂžgleord) | Forklaring |
---|---|
XML | Alle forespĂžrgsler og svar er udformet som gyldig XML |
ADGANGSSTYRING | Der anvendes en nyudviklet adgangsstyring, som er beskrevet i servicehÄndbogen. De individuelle regler for hver service findes i servicedokumentationen |
ISO | Der anvendes udelukkende ISO-8859-1 som kodning for tegnsĂŠt. |
TABEL | Tabeller skal have nĂžgler i alle rĂŠkker |
Specifikke ĂŠndringer
SÄfremt en service har specifikke Êndringer, vil de fremgÄ af dette afsnit.
Konverteringsplan
Planen angiver blandt andet:
HvornÄr en service kan testes i demo
HvornÄr en service releases til produktion
HvornÄr overgangsperioden for en service afsluttes
HvornÄr udfasningsperioden for en service afsluttes
Eventuelle problemer med de moderniserede CPR-services kan indrapporteres til CPR Servicedesk.
Dato Demo: HvornÄr servicen er blevet lagt i Demo-miljÞet og er klar til at blive testet af eksterne anvendere
Dato Produktion: HvornÄr servicen er lagt i Produktion
Overgangsperiode slut: Angiver datoen, hvorefter alle kald til servicen vil blive betjent af den moderniserede (version 2.0) service, og udfasningsperioden starter
Udfasningsperioden slut: Angiver datoen for udfasningsperiodens afslutning
Servicenavn | Beskrivelse | Dokumentation | Dato Demo | Dato Produktion | Overgangsperiode slut | Udfasningsperiode slut | Generelle ĂŠndringer |
---|---|---|---|---|---|---|---|
PNRABN-I | Personnummerabonnement privat/offentlig - indberet/slet | 25. april 2024 | 25. april 2024 |
|
| XML, ADGANGSSTYRING, ISO, TABEL |