Serviceplatformens opsætningsguide til leverandører

Transkript

1 Serviceplatformens opsætningsguide til leverandører Udarbejdet for: KOMBIT A/S Halfdansgade København S $Revision: 1.12$ $Date: 23 Jun 2016$ Side 1

2 Indholdsfortegnelse 1. Serviceplatformen - opsætningsguide (Ekstern testmiljø) Indledning Forberedelse til anvendelse af Serviceplatformen Medarbejdercertifikat (MOCES) Virksomhedscertifikat / funktionscertifikat Opsætning af Serviceplatformen Oprettelse af leverandør Oprettelse af leverandør som kommune Registrering af it-system Anmod om Serviceaftale Sikkerhedsmodeller på Serviceplatformen og i rammearkitekturen Anvendelse af InvocationContext Anvendelse af AuthorityContext (Myndighedskontekst) Anvendelse af token sikkerhed (KOMBIT token) Anvendelse af CallContext Opsætning af klient Opsætning af SoapUI klient Eksempler ADRSOG1 CPR Opslag (lokal) Version 1.0 InvocationContext ADRSOG1 CPR Opslag (lokal) Version 1.1 InvocationContext CPR Kommunekode Service InvocationContext CPR SERVICE Version 1.0 InvocationContext Familie CPR Opslag (lokal) Version 1.0 InvocationContext Familie CPR Opslag (lokal) Version 1.1 InvocationContext Familie+ CPR Opslag (lokal) Version 1.0 InvocationContext Familie+ CPR Opslag (lokal) Version 1.1 InvocationContext navne3 CPR Opslag (lokal) Version 1.0 InvocationContext navne3 CPR Opslag (lokal) Version 1.1 InvocationContext Person stamdata (lokal) InvocationContext STAM CPR Opslag (lokal) Version 1.0 InvocationContext STAM CPR Opslag (lokal) Version 1.1 InvocationContext STAM+ CPR Opslag (lokal) Version 1.0 InvocationContext STAM+ CPR Opslag (lokal) Version 1.1 InvocationContext $Revision: 1.12$ $Date: 23 Jun 2016$ Side 2

3 CVR Online 3.0 InvocationContext OIS Service InvocationContext CPR dokumentation Fejlsøgning ServiceUUID er forkert i forhold til den kaldte service Forkert syntaks for det angivne ServiceUUID Fejlsøgning CPR KOMBIT token er udløbet Forskelligt certifikat brugt til webservice kald og STS token udstedning Serviceaftale fra støttesystemet er udløbet Timeout ved kald af eksterne kilder $Revision: 1.12$ $Date: 23 Jun 2016$ Side 3

4 1. Serviceplatformen - opsætningsguide (Ekstern testmiljø) 1.1 Indledning Denne opsætningsguide skal hjælpe med at komme i gang med at kalde services på Serviceplatformen test- og produktionsmiljø. Guiden består af følgende sektioner: 1. Forberedelse til anvendelse af Serviceplatformen. 2. Opsætning af Serviceplatformen. 3. Opsætning af klient. 4. Eksempler på kald til Serviceplatformen. 1.2 Forberedelse til anvendelse af Serviceplatformen Inden et it-system fra en kommune eller UDK/ATP kan kalde Serviceplatformen, er der en række forudsætninger, som skal være på plads. Disse forudsætninger gælder for anvendelse af Serviceplatformens eksterne testmiljø og produktionsmiljøet. Sikkerheden på Serviceplatformen er baseret på certifikater medarbejdercertifikater (MOCES) samt virksomhedscertifikater (VOCES) eller funktionscertifikater (FOCES). Opsætningen af certifikaterne beskrives i de nedenstående afsnit Medarbejdercertifikat (MOCES) Man skal have installeret et Medarbejdercertifikat (MOCES) på sin lokale PC. Dette bruges til at logge på Serviceplatformens selvbetjening. Certifikatet kan bestilles via DanID Virksomhedscertifikat / funktionscertifikat For at kalde en webservice på Serviceplatformen, skal man have et virksomhedscertifikat (VOCES) eller et funktionscertifikat (FOCES). Hvert registreret it-system på Serviceplatformen kræver et særskilt certifikat, som skal bruges for at kunne kalde webservices på Serviceplatformen. Til kald mod services i produktionsmiljøet skal dette certifikat være et produktionscertifikat, mens det ved kald mod services i det eksterne testmiljø alternativt kan være et testcertifikat. Certifikatet kan bestilles via DanID. Dette certifikat kommer indpakket i en p12 fil, og skal eksporteres til filtypen.cer. Certifikatet, der skal bestilles, er som udgangspunkt for leverandøren. Hvis kommunen agerer både som kommune og leverandør, skal kommunens certifikat bruges. 1.3 Opsætning af Serviceplatformen Når brugeren har både et MOCES og et VOCES/FOCES certifikat, kan denne påbegynde sin opsætning af Serviceplatformen Oprettelse af leverandør For at kunne kalde webservices på Serviceplatformen, skal leverandørens organisation være oprettet som leverandør- organisation på Serviceplatformen. Dette gøres ved at kontakte Helpdesk eller helpdesk@serviceplatformen.dk, og bede om en oprettelsesblanket for en leverandør I denne blanket vil ansøgeren blive bedt om at udfylde sit RID ID, som er det ID, som findes i ansøgerens medarbejdercertifikat (MOCES). Denne blanket udfyldes og sendes til Helpdesk. $Revision: 1.12$ $Date: 23 Jun 2016$ Side 4

5 Når denne oprettelse er blevet godkendt, oprettes organisationen. Samtidig oprettes den første administrator for organisationen. Denne kan efterfølgende selv oprette brugere i egen organisation Oprettelse af leverandør som kommune Hvis kommunen selv drifter egne it-systemer, der driftes internt i kommunen, og ønsker at tilslutte dem til Serviceplatformen, skal kommunen ved siden af oprettelse som kommune også oprettes som leverandør med leverandørroller. Dette gøres ved at kontakte Helpdesk eller helpdesk@serviceplatformen.dk og bede om en oprettelsesformular for en leverandør jf. ovenstående proces Registrering af it-system Brugerne kan nu logge på Serviceplatformens selvbetjening og vælge rollen Bruger for at registrere et nyt itsystem. Ved registrering af nyt it-system (Figur 1), skal brugeren angive VOCES/FOCES certifikat. Registreres itsystemet i produktionsmiljøet skal der angives et produktionscertifikat, mens det i testmiljøet enten kan være et produktions- eller et testcertifikat. Det angivne certifikat benyttes efterfølgende til at kalde services på Serviceplatformen. I forbindelse med registrering af it-systemet accepteres også vilkår for it-systemets tilslutning til Serviceplatformen. Det er muligt at oprette flere it-systemer for en organisation, med unikt certifikat. Figur Anmod om Serviceaftale Når leverandøren har registreret et it-system, skal der angives, hvilke services it-systemet ønsker at kalde. Der kan angives én eller flere services. Dette gøres ved at tilføre de respektive services til en anmodning om en serviceaftale (Figur 2). Dernæst vælges hvilken kommune/udk/atp aftalen skal gælde for. I eksternt testmiljø kan der kun vælges support, da denne aftale godkendes automatisk. I produktionsmiljøet skal aftalen godkendes af de relevante kommuner/atp/udk, som er angivet under kommuner. Det er først når aftalen er godkendt, at det er muligt at kalde services. Bemærk at en aftale, der godkendes af flere myndigheder resulterer i flere underliggende serviceaftaler med unikke UUID er. $Revision: 1.12$ $Date: 23 Jun 2016$ Side 5

6 Figur Sikkerhedsmodeller på Serviceplatformen og i rammearkitekturen Der er ved anvendelse af services på Serviceplatformen forskellige sikkerhedsmodeller, som kommer i anvendelse ved kald til de enkelte services. Der er pt. 3 sikkerhedsmodeller: InvocationContext, AuthorityContext og KOMBIT token sikkerhed. Den enkelte service understøtter én eller flere af disse sikkerhedsmodeller. Den overordnede forskel på de tre sikkerhedsmodeller er: InvocationContext er etableret inden rammearkitekturen var tilstede og evaluerer derfor alene om der er en adgangsgivende aftale ved opslag i databasen på Serviceplatformen. Denne model understøtter derfor ikke rolle- eller dataafgrænsninger. AuthorityContext og KOMBIT token er begge en del af sikkerheden i rammearkitekturen. Med disse modeller baseres adgang på fremsøgning af en adgangsgivende aftale provisioneret fra støttesystemets sikkerhed. Rolle- eller dataafgrænsninger understøttes af KOMBIT token men ikke AuthorityContext. Begge modeller understøtter CallContext, der er en måde at fremsende samme valgfrie felter som InvocationContext tilbyder (se afsnit 1.4.4). Den konkrete anvendelse af de enkelte sikkerhedsmodeller og forskellene på disse bliver gennemgået nedenfor Anvendelse af InvocationContext Ved webservice kald til en service, som understøtter denne sikkerhedsmodel, er det krævet at man sender en række informationer med i XML kaldet, for at identificere sig selv, og blive godkendt adgang til at kalde webservicen. Der udfyldes følgende informationer i InvocationContext i XML en (eksempler på dette ses under afsnittet Eksempler): Feltnavn ServiceAgreementUUID UserSystemUUID UserUUID ServiceUUID OnBehalfOfUser CallersServiceCallIdentifier Værdi Aftale UUID fra Serviceplatformen under Serviceaftaler System UUID fra Serviceplatformen under Serviceaftaler Kommune UUID fra Serviceplatformen under Serviceaftaler Service UUID fra Serviceplatformen under Find service eller Serviceaftaler Eget navn og firma (valgfrit felt) F.eks. SoapUI eller systemnavn (valgfrit felt) $Revision: 1.12$ $Date: 23 Jun 2016$ Side 6

7 AccountingInfo Evt. faktureringsinformation (valgfrit felt) Figur 3 fra Serviceplatformen viser hvor man kan læse værdierne for ServiceAgreementUUID, UserSystemUUID, UserUUID og ServiceUUID. Figur Anvendelse af AuthorityContext (Myndighedskontekst) Ved webservice kald til en service, som understøtter denne sikkerhedsmodel, er det krævet, at man angiver følgende værdi for at identificere den kommune, der opereres på vegne af: Feltnavn MunicipalityCVR Værdi CVR nummer for den kommune, der kaldes på vegne af (krævet felt) $Revision: 1.12$ $Date: 23 Jun 2016$ Side 7

8 Der er yderligere to værdier, som afledes af kaldet, som anvendes i denne sammenhæng. Disse er: Servicen der kaldes. Det kaldende it-system, der er identificeret via det OCES certifikat, der bliver anvendt til kaldet. Idet denne model giver adgang baseret på fremsøgningen af en adgangsgivende aftale fra støttesystemets sikkerhed, er det krævet at der er oprettet en aftale i støttesystemets sikkerhed, inden der gennemføres et kald mod Serviceplatformen. Aftalen refereres ikke direkte i requesten, men fremsøges på grundlag af de givne og afledte værdier. For information om hvorledes en aftale oprettes i STS henvises til dokumentet Bilag 2 - Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen version 2.0, der beskriver denne arbejdsgang Anvendelse af token sikkerhed (KOMBIT token) For at anvende token baseret sikkerhed, skal anvendersystemet sikre sig et token ved at oprette en aftale og foretage et kald til STS, inden anvendersystemet gennemfører et kald til Serviceplatformen. Opnås et token betyder dette, at der findes en adgangsgivende aftale, idet det token som modtages fra STS indeholder de rettigheder, der er givet i forbindelse med, at den pågældende aftale blev godkendt fra den relevante kommune. For information om hvorledes en aftale oprettes i STS henvises til dokumentet Bilag 2 - Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen version 2.0, der beskriver denne arbejdsgang. For yderligere information om denne sikkerhedsmodel henvises til dokumentet Bilag 2A - Beskrivelse af sikkerhedsmodellen i Rammearkitekturen version 2.0, afsnit 5.1. Det flow, som skal gennemføres, er vist i Figur 4: STS kalder user store for at slå anvendersystemet op, og søger i den sammenhæng også efter aftalestrukturer der giver adgang til service der kaldes ind på User store svarer med de ønskede informationer til STS Anvendersystem kalder STS - metode RequestSecurityToken (WS- Trust) 2 3 Rammearkitekturens Secure Token Service STS svarer med et RequestSecurity-TokenResponse. Heri ligger et KOMBIT SAML token der repræsenterer anvendersystemets adgang 1 4 Anvendersystem kalder SOAP service med CERT eg sikkerhed på transport niveau (to-vejs SSL) Desuden angives en WS- Secuirity sektion hvor SAML token er placeret 5 Serviceplatformen kalder kildesystemet med Den relevante sikkerhedsmodel 6 Anvendersystem (eksternt system) Service platformen Kildesystem (KOMBIT system) 8 7 Serviceplatformen returnerer response til anvendersystem og benytter i dette scenarie den stadig åbne SSL/TSL tunnel. Kildesystemet svarer med et response. Evt. data afgrænsning er foretaget af kildesystemet på baggrund af indholdet i SAML token (roller) Figur 4 $Revision: 1.12$ $Date: 23 Jun 2016$ Side 8

9 Processen med at sikre sig et token hos STS via et WS-Trust kald er beskrevet i dokumentet Snitfladebeskrivelse-STS-OIO WS Trust.pdf, og vil ikke blive beskrevet yderligere her. I kaldet til Serviceplatformen skal den token, som er modtaget fra STS, placeres i en WS-Security header sektion. Dette er udtrykt i WSDL filer for de services, som anvender denne sikkerhedsmodel. Denne policy kan ses nedenfor: Anvendelse af CallContext Webservices der understøtter token sikkerhed og/eller AuthorityContext accepterer også fremsendelsen af en såkaldt CallContext. CallContext gør det muligt at fremsende samme oplysninger som InvocationContext ens valgfrie felter gør, dvs.: Feltnavn OnBehalfOfUser CallersServiceCallIdentifier AccountingInfo Værdi Eget navn og firma (valgfrit felt) F.eks. SoapUI eller systemnavn (valgfrit felt) Evt. faktureringsinformation (valgfrit felt) I tilfældet at en service både tillader InvocationContext og CallContext og begge fremsendes, tager felterne i CallContext præference over samme felter i InvocationContext. 1.5 Opsætning af klient En god start til at teste kald mod Serviceplatformen, er at opsætte SoapUI. Via SoapUI, kan der hurtigt testes, om eksempelvis udfyldelse af InvocationContext er korrekt og hvordan strukturen af svaret ser ud Opsætning af SoapUI klient Opsætning af keystore SoapUI skal bruge et funktionscertifikat pakket ind i Javas keystore-format for at kunne læse indholdet. Dette oprettes ved at læse virksomheds- (VOCES) / funktionscertifikatet (FOCES) ud i en JKS fil via Java- værktøjet keytool. Dette køres i en kommandolinje (i windows: cmd.exe) Kaldet, der skal udføres, ser således ud: keytool -v -importkeystore -srckeystore "<filnavn>.p12" -srcstoretype PKCS12 -destkeystore funkcert.jks Den fil der dannes, skal beskyttes af et password, som ikke behøver at være det samme password som til certifikatet. Nogle værktøjer (fx Visual Studio) kræver dog, at de to passwords er ens. $Revision: 1.12$ $Date: 23 Jun 2016$ Side 9

10 Herefter åbnes SoapUI på følgende måde (Figur 5): 1. Vælg File Preferences 2. Vælg fanebladet SSL Settings og udfyld stien til KeyStore og KeyStore Password 3. Tryk ok. VOCES/FOCES certifikat er nu klar til at blive brugt med kaldet mod Serviceplatformen. Figur 5 Viser hvilket certifikat der bruges af SoapUI $Revision: 1.12$ $Date: 23 Jun 2016$ Side 10

11 Hent WSDL fil En WSDL-fil beskriver hvilken struktur, webservicen forventer at modtage fra klienten, og hvilken struktur webservicen returnerer. Denne WSDL-fil bruges af SoapUI til at opbygge XML strukturen af webservicekaldet. WSDL-filer findes for hver version af en service under menupunktet Find service. Vælg den service, du ønsker at kalde, og klik på Teknisk Dokumentation (se Figur 6) for at downloade et ZIP arkiv som bl.a. indeholder servicens WSDL-fil. I dette eksempel bruges CPR Service version 1.0 og dennes WSDL-fil. Den benyttede sikkerhedsmodel i eksemplet er InvocationContext. Figur 6 Viser hvor bruger kan finde Service WSDL en Opret projekt Dernæst opret et nyt projekt i SoapUI (Figur 7), for at opsætte kaldet mod en given webservice på Serviceplatformen. Projektet oprettes således: 1. Angiv et projektnavn. 2. Indsæt stien til den downloadede og udpakkede WSDL-fil. 3. Klik på OK $Revision: 1.12$ $Date: 23 Jun 2016$ Side 11

12 Figur 7 Oprettelse af SoapUI projekt SoapUI opretter et projekt med et tomt request/kald ud fra WSDL-filen. Klik ind på projektet og kontrollér, at alt er oprettet korrekt for callgctpservice som figuren nedenfor (Figur 8). Dette vil vise, at SoapUI har oprettet en XML struktur, som nu kan modificeres med bl.a. værdier i InvocationContext. $Revision: 1.12$ $Date: 23 Jun 2016$ Side 12

13 Figur 8 Oprettet xml struktur fra WSDL Ændre endpoint I WSDL-filen er endpointet (stien til kald af servicen) ikke sat korrekt, så først skal man klikke på dropdownpilen (Figur 9) ud for endpointet (der starter med og vælge [add new endpoint ]. Indsæt et nyt endpoint med adressen: $Revision: 1.12$ $Date: 23 Jun 2016$ Side 13

14 Figur 9 Ændring af endpoint / URL til servicekald Alle endpoints kan findes under Find service på konkrete service, ved klik på Læs mere (Figur 10). Informationerne kan tilgåes fra følgende links: Miljø Ekstern test Produktion Link $Revision: 1.12$ $Date: 23 Jun 2016$ Side 14

15 Figur Opsætning af SOAP og GCTP kald XML kaldet skal opdateres, så alle oplysningerne passer (Se venligst nedenstående XML). Dette betyder at værdier i InvocationContext skal indsættes med de UUID er som findes for jeres respektive serviceaftaler Udfyld InvocationContext. Værdierne, der skal indsættes i InvocationContext, er beskrevet i afsnittet Udfyldelse af InvocationContext. xmlns:kom=" <kom:forwardtocprservicerequest> <invctx:usersystemuuid>usersystemuuid </invctx:usersystemuuid> <invctx:useruuid>useruuid </invctx:useruuid> <invctx:serviceuuid>8ee213c7-25a9-11e d4bed98c63db</invctx:serviceuuid> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 15

16 <kom:gctpmessage> <![CDATA[ <Gctp v="1.0" > <Service r="adresse3"> <CprServiceHeader r="adresse3"> <Field r="pnr" v="xxxxxxxxxx"/> <Field r="akx" v="x"/> </kom:forwardtocprservicerequest> Udførsel af SOAP og GCTP kald Når XML en er sat op, trykkes på Play -knappen og kaldet udføres. I det returnerede svar, er også CDATAindpakket og uden linjeskift. Eksempel: <env:envelope xmlns:env=" <env:header/> <env:body> <ns2:forwardtocprserviceresponse xmlns=" xmlns:ns2=" <ns2:result><![cdata[... GCTP-XML...</ns2:result> </ns2:forwardtocprserviceresponse> </env:body> </env:envelope> For nemmere at læse svaret fra eksempelvis CPR, kan man vælge at fjerne alt andet end GCTP-XML en fra tekstboksen, og derefter trykke på Alt+F for at vise XML en pænt formateret med linieskift (Figur 11). $Revision: 1.12$ $Date: 23 Jun 2016$ Side 16

17 Figur 11 Viser formateret xml, med linieskift 1.6 Eksempler Ved kald af nedenstående eksempler husk at ændre sti til den specifikke service, og henholdsvis miljø (test/produktion). I testmiljøet er det muligt at kalde alle services, såfremt disse indgår i den aftale, der er automatisk godkendt. I produktionsmiljøet skal aftalen først være godkendt af de relevante kommuner/atp/udk, inden servicen kan kaldes. Bemærk, at der i produktionsmiljøet altid skal angives det korrekte UUID for den aftale og myndighed, man ønsker at kalde på vegne af ADRSOG1 CPR Opslag (lokal) Version 1.0 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>d e3-9ed6-e376a4d43aa6</invctx:serviceuuid> <kom:gctpmessage> <![CDATA[ <Service r="adrsog1"> <CprServiceHeader r="adrsog1"> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 17

18 <Field r="komk" v="1111"/> <Field r="vejk" v="1111"/> </kom:callgctpcheckservicerequest> ADRSOG1 CPR Opslag (lokal) Version 1.1 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>6538f113-b1e6-4b21-8fe1-28b7bf78a1bd</invctx:serviceuuid> <kom:gctpmessage> <![CDATA[ <Service r="adrsog1"> <CprServiceHeader r="adrsog1"> <Field r="komk" v="1111"/> <Field r="vejk" v="1111"/> </kom:callgctpcheckservicerequest> CPR Kommunekode Service InvocationContext xmlns:ns=" xmlns:invctx=" xmlns:ns2=" <ns:getmunicipalitycoderequest> <invctx:serviceuuid>cdf2d790-63ed-11e3-96c7-000c f</invctx:serviceuuid> <ns2:pnr> </ns2:pnr> </ns:getmunicipalitycoderequest> CPR SERVICE Version 1.0 InvocationContext Bemærk at denne service har en særlig omkostningsstruktur og anbefales kun benyttet for de it-systemer, med forretningsbehov for direkte opslag i CPR-registeret. $Revision: 1.12$ $Date: 23 Jun 2016$ Side 18

19 xmlns:kom=" <kom:forwardtocprservicerequest> <invctx:serviceuuid>8ee213c7-25a9-11e d4bed98c63db</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Gctp v="1.0" > <Service r="adresse3"> <CprServiceHeader r="adresse3"> <Field r="pnr" v="xxxxxxxxxx"/> <Field r="akx" v="x"/> </kom:forwardtocprservicerequest> CPR service er et forward kald mod CPR registreret. Det kan bruges til at modtage forskellige informationer fra CPR, afhængig af GCTP XML en i kaldet. Nedenstående viser flere specifikke eksempler på kald af CPR Service. Bemærk at nedenstående dog skal pakkes ind i Serviceplatformens SOAP XML Søgning på myndigheder <Service r="myn2"> <CprServiceHeader r="myn2"> <Field r="myte" v="farum"/> <Field r="aia" v="x"/> <Field r="maxa" v="15"/> Søgning på en fødselsdato i en bestemt kommune (hér: Aalborg) <Service r="fodsog2"> <CprServiceHeader r="fodsog2"> <Field r="aia" v="x"/> <Field r="fodt" v=" "/> <Field r="komk" v="0851"/> Søgning på forældre til et givent CPR nummer $Revision: 1.12$ $Date: 23 Jun 2016$ Side 19

20 <Service r="morfar"> <CprServiceHeader r="morfar"> <Field r="pnr" v=" "/> Familie CPR Opslag (lokal) Version 1.0 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>dc3706bd e3-9ed6-e376a4d43aa6</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="familie"> <CprServiceHeader r="familie"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> Familie CPR Opslag (lokal) Version 1.1 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>2419e94b fc5-935c-2419ac956e79</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="familie"> <CprServiceHeader r="familie"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 20

21 1.6.7 Familie+ CPR Opslag (lokal) Version 1.0 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>d55c9d e3-9ed6-e376a4d43aa6</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="familie+"> <CprServiceHeader r="familie+"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> Familie+ CPR Opslag (lokal) Version 1.1 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>a34cf599-26e bfbd-2490d3d1c3ab</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="familie+"> <CprServiceHeader r="familie+"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> navne3 CPR Opslag (lokal) Version 1.0 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 21

22 <invctx:serviceuuid>e1f24e e3-9ed6-e376a4d43aa6</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="navne3"> <CprServiceHeader r="navne3"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> navne3 CPR Opslag (lokal) Version 1.1 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>e3f e-4b8f-8a15-674a4f8abaad</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="navne3"> <CprServiceHeader r="navne3"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> Person stamdata (lokal) InvocationContext xmlns:ns=" xmlns:invctx=" xmlns:ns2=" <ns:callcprbasicinformationrequest> <invctx:serviceuuid>d84f1ac8-76ca-11e3-abab bdf</invctx:serviceuuid> <ns2:pnr> </ns2:pnr> </ns:callcprbasicinformationrequest> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 22

23 STAM CPR Opslag (lokal) Version 1.0 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>ed3a77cd e3-9ed6-e376a4d43aa6</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="stam"> <CprServiceHeader r="stam"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> STAM CPR Opslag (lokal) Version 1.1 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>7ae c-4b0a e97b12197</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="stam"> <CprServiceHeader r="stam"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> STAM+ CPR Opslag (lokal) Version 1.0 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 23

24 <invctx:serviceuuid>e6ff0b e3-9ed6-e376a4d43aa6</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="stam+"> <CprServiceHeader r="stam+"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> STAM+ CPR Opslag (lokal) Version 1.1 InvocationContext xmlns:kom=" <kom:callgctpcheckservicerequest> <invctx:serviceuuid>7baec3a5-26a fd-37f3bad3dfcb</invctx:serviceuuid> <kom:gctpmessage><![cdata[ <Service r="stam+"> <CprServiceHeader r="stam+"> <Field r="pnr" v=" "/> </kom:callgctpcheckservicerequest> CVR Online 3.0 InvocationContext xmlns:x.=" xmlns:ns=" xmlns:x.1=" <x.:getlegalunitrequest level="1"> <ns:invocationcontext> <ns:serviceagreementuuid>serviceagreementuuid</ns:serviceagreementuuid> <ns:usersystemuuid>usersystemuuid</ns:usersystemuuid> <ns:useruuid>useruuid</ns:useruuid> <ns:serviceuuid>93a48b e d4bed98c63db</ns:serviceuuid> </ns:invocationcontext> <x.1:legalunitidentifier>xxxxxxxx</x.1:legalunitidentifier> </x.:getlegalunitrequest> $Revision: 1.12$ $Date: 23 Jun 2016$ Side 24

25 OIS Service InvocationContext xmlns:ois=" xmlns:ns=" <ois:execproc> <ns:invocationcontext> <ns:serviceagreementuuid>serviceagreementuuid</ns:serviceagreementuuid> <ns:usersystemuuid>usersystemuuid</ns:usersystemuuid> <ns:useruuid>useruuid</ns:useruuid> <ns:serviceuuid>a02ebddc-389d-11e2-8d27-5c260a88aed0</ns:serviceuuid> </ns:invocationcontext> <!--Optional:--> <ois:proc>sel_adressevalg</ois:proc> <!--Optional:--> <ois:par>421,1510</ois:par> </ois:execproc> 1.7 CPR dokumentation Følgende Excel-dokument beskriver feltbetegnelser, koder osv. Dette dokument er ment som supplement til CPR dokumentation. Titel URL Supplerende CPR dokumentation tform/hjemmesidematerialer/supplerende%20dokumentation%20af%20cp R_april2015.xls 1.8 Fejlsøgning I nedenstående findes de typiske fejlbeskeder og løsninger ServiceUUID er forkert i forhold til den kaldte service Hvis Serviceplatformen returnerer en fejl kontrollér da den modtagne fejlbesked. Der gives typisk en konkret fejlbeskrivelse hvis f.eks. ServiceUUID er forkert i forhold til den kaldte service. Dette giver fejlen: com.systematic.kombit.common.exception.messagekombitexception: Service called with wrong service UUID = <Kaldt ServiceUUID> Forkert syntaks for det angivne ServiceUUID Dette kan skyldes at der er tastet et mellemrum eller tabulering foran eller bagved UUID et. Dette giver fejlen: com.systematic.kombit.common.exception.messagekombitexception: Service UUID = <Kaldt ServiceUUID> must be an UUID Fejlsøgning CPR Hvis CPR ikke finder nogle data, så returneres en tom GCTP besked med en enkelt tom række. Hvis GCTP kaldet er forkert, gives blot beskeden: Exception message: com.systematic.kombit.common.exception.messagekombitexception: Gctp error in request $Revision: 1.12$ $Date: 23 Jun 2016$ Side 25

26 1.8.4 KOMBIT token er udløbet Tokens udstedt af rammearkitekturens STS er kun gyldig i en begrænset tidsperiode. Sendes en udløbet token til Serviceplatformen, vil dette give følgende fejl: com.systematic.kombit.common.exception.messagekombitexception: The passed security token was invalid Forskelligt certifikat brugt til webservice kald og STS token udstedning Serviceplatformen kræver at certifikatet beskrevet som subject i en modtaget KOMBIT token matcher certifikatet brugt til at kalde en webservice på Serviceplatformen, dvs. certifikatet registreret for den adgangsgivende aftale. Stemmer disse ikke overens, vil dette give følgende fejl: com.systematic.kombit.common.exception.messagekombitexception: Client certificate did not match the subject certificate of the security token Serviceaftale fra støttesystemet er udløbet Ved kald med KOMBIT token eller AuthorityContext fremsøges den adgangsgivende aftale som udgangspunkt i støttesystemets sikkerhed. Såfremt aftalen er udløbet (eller endnu ikke er gyldig) vil dette give følgende fejl: com.systematic.kombit.common.exception.configurationkombitexception: Service agreement with UUID = <Benyttet ServiceAgreementUUID> is inactive. Contact RA-STS support for help. Sker ovenstående fejl, kontakt da supporten for rammearkitekturens støttesystemer (RA-STS) og ikke Serviceplatformens Helpdesk. 1.9 Timeout ved kald af eksterne kilder Ved kald af eksterne kilder fra Serviceplatformen benyttes følgende timeouts for hvert kald. ConnectionTimeout: 5000 ms ReceiveTimeout: ms $Revision: 1.12$ $Date: 23 Jun 2016$ Side 26