SF Terminalservice UDK. Serviceversion Integrationsbeskrivelse - version 3 KDI

Transkript

1 SF Serviceversion version 3 KDI

2 Versionshistorik Relevans Dato Initialer Version Kommentarer EDM Klargjort til publicering EDM Tilpasset løsning med orkestreret kald mod Ydelsesindekset for 98 kommuner (relevant for SP alene) EDM Tilpasset med review kommentarer fra TBJ EDM Tilpasset løsning uden orkestrering med token for UDK på vegne af tilmeldte kommuner og omvendt (relevant for SP alene) JJN Opdateret med forudsætninger og vilkår for tilslutning er tilføjet. - Kapitel 1.5 og er omskrevet JJN Opdateret med forudsætninger og vilkår for tilslutning er tilføjet. - Kapitel Opdateret reference til [WSDL-SP], som pegede på forkert fil (service der er refereret til fandtes ikke) JJN Mindre redaktionelle ændringer til TS101 og TS JJN Kapitel Oprindelige krav til TerminalService er slette Kapitel Output formatet er beskrevet Kapitel Mapning er slettet og der henvises til kapitel XEHL Opdateret til ny teknisk specifikation med Liberty Basic Soap Binding. Heraf opdatering af referencen [WSDL-SP], og tabel i afsnit Opdatering af bilagsfil til opdateret bilag for Ydelsesindeksintegrationen, samt opdatering af versioner til reference af [ANVISNING] til gældende anvisninger CWM Tilføjet BevilgetYdelseId til økonomiskydelseseffektuering-relation CWM Tilføjet beskrivelse af udvidet dato afgrænsning på 1-6 måneder KLR 3 Større gennemskrivning af n på baggrund af dialog med UDK. n indgår i aftalegrundlaget mellem KOMBIT og ATP om kommunernes adgang af UDKdata og visa versa. KY og KSD er fjernet som anvendere. Referencer til gældende version og teknisk specifikationsmateriale er opdateret. KOMBIT A/S Halfdansgade København S CVR Side 2 af 31

3 Referencer Ref Titel Kommentarer [SPref] [STS-ref] Se Note vedrørende servicemål for Serviceplatformen.pdf på følgende link: Se SLA og åbningstider på Støttesystemerne på følgende link: [SIKKERHED] Use cases for brug af sikkerhedsmodeller på Serviceplatformen - v [STS-Sikkerhed] [WSDL-SP] [WSDL-EXT] [Baggrund] [ANVISNING] [GVF] [KDIDrift] Se vilkår Bilag 2 - Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen version 2.0 på nedenstående link n refererer til SF2860 Teknisk spec zip som indeholder WSDL på serviceplatformen, og er placeret i samme mappe som integrationsbeskrivelsen, se link Notat om persondataretlige spørgsmål i relation til 8, stk. 1, i lov om Udbetaling Danmark (kammeradvokatsnotat) SAPAs databehandleraftale, bilag 3.0 og 3.1 Anvisninger for anvendelse af indekserne: n refererer til SF1490 Bilag SF1490 bilag zip som indeholder WSDL/WADL/XSD af eksterne interfaces, som er placeret i samme mappe som integrationsbeskrivelsen, se link Reference til Generelle vilkår og forudsætninger, der skal være på plads før Snitflader kan anvendes: Generelle vilkår og forudsætninger Hjemmeside med informationer om drift og forvaltning af KDIs Services: Baggrundsmateriale for servicen Følgende versioner for anvisninger er anvendt i denne beskrivelse: Vejledning til anvisninger for Indeksene v.1.1 Anvendelse af Bevillingsobjektet i Ydelsesindekset v1.2 Anvendelse af Økonomisk Effektuerings-objektet i Ydelsesindekset v1.1 Anvisninger til Klassifikationer i Indeksene v1.2.3 KOMBIT A/S Halfdansgade København S CVR Side 3 af 31

4 [KDITest] Hjemmeside med informationer om ibrugtagning og test af KDIs Services: Indholdsfortegnelse Læsevejledning Overordnet beskrivelse Integrationens formål Overordnet forretningsflow i integrationen Servicebetingelser for den samlede integration Teststrategi Forudsætninger for produktionssætning Kontekst for integrationsparter Generelt om lovhjemmel for denne service Serviceaftaler Kontekst for SAPA Specifikation for integrationsparter Specifikation af endpoints for SAPA Specifikation af endpoints for Ydelsesindeks Beskrivelse for integrationsplatforme Beskrivelse for Serviceplatformen KOMBIT A/S Halfdansgade København S CVR Side 4 af 31

5 Læsevejledning Dataejer (for denne service Udbetaling Danmark og kommunerne) bør læse hele dokumentet for at sikre, at data behandles efter hensigten. Leverandør for anvendersystemer bør læse afsnit 1, 2 og 3. Leverandør for afsendersystemet bør læse afsnit 1 og 3. Leverandør for serviceplatforman bør læse afsnit 1 og 4. Bilaget beskriver i udgangspunkt den måde Terminalservicen fungere på i den udpegede version. Visse funktionelle mangler i servicen er beskrevet i røde -afsnit, og vil blive indarbejdet i integrationsbeskrivelsen, når servicen er tilpasset disse mangler. Af de røde -afsnit fremgår det samtidigt, at anvendersystemet SAPA håndtere disse mangler lokalt i en midlertidig løsning. 1 Overordnet beskrivelse 1.1 Integrationens formål Terminalservicen har til formål at understøtte styret og datafiltreret adgang til ydelsesdata på tværs af kommunerne og Udbetaling Danmark, herefter benævnt UDK. Udveksling af ydelsesdata er underlagt lovgivningsmæssige begrænsninger, hvorfor der er behov for at styre dels adgangen til og dels graden af data, der udveksles, hvilket ikke kan lade sig gøre via Ydelsesindeksets eksisterende servicegrænseflade. Læs mere om den relevante lovgivning og fortolkning i afsnit 2, som beskriver konteksten for anvenderne og dermed deres lovhjemmel til anvendelse af snitfladen, samt i afsnit 3 hvor snitfladens filtrering af data på baggrund af lovfortolkningen gennemgås. 1.2 Overordnet forretningsflow i integrationen Jf. figuren nedenfor indgår følgende forretningsflow i integrationen. KOMBIT A/S Halfdansgade København S CVR Side 5 af 31

6 Terminalservice Terminalservicen Anvender Forespørg ydelsesdata Valider/tilføj søgeparametre for dispositionsdato på baggrund af anvenders lovhjemmel Token = UDK? Ja Videresend forespørgsel som UDK på vegne af 98 kommuner Nej Videresend forespørgsel som kommune på vegne af UDK Modtag ydelsesdata Filtrer data på baggrund af anvenders lovhjemmel Ydelsesindeks Modtag forespørgsel og fremfind dataafgrænsede data Integrationen indeholder et flow, som er baseret på en gennemstilling af Støttesystemernes Ydelsesindeks gennem Serviceplatformen, hvor det samtidigt sikres, at myndigheden har adgangstilladelse, at der forespørges på den tilladte periode, samt at data i svaret filtreres, således at man opfylder de lovmæssige krav stillet i Loven om Udbetaling Danmark 8 stk. 1 om brug af terminaladgang til ydelsesdata mellem kommunerne og UDK. Nedenfor beskrives flowet kort. KOMBIT A/S Halfdansgade København S CVR Side 6 af 31

7 1. Forespørg ydelsesdata Anvendersystemet (fagsystemet) fremsender en forespørgsel med: a. Part (cpr-nummer på den bevillingsmodtager der ønskes data om) b. Tidsperiode (for ydelser udbetalt inden for de seneste 3 måneder) c. KLE-nummer (i tilfælde af yderligere indsnævring af resultatsættet, hvis man fx ikke ønsker ydelser fra alle ydelsesområder hos den pågældende myndighed) Forespørgselsformatet for terminalservicen er det samme som forespørgselsformatet for STS ydelsesindekset (SF1490). 2. Valider/tilføj søgeparametre for dispositionsdato på baggrund af anvenders lovhjemmel Serviceplatformen vil default ud fra dags dato indsætte en dataafgrænsning/søgeparameter i kaldet på dispositionsdato på den økonomiske effektuering, således at der bliver datoafgrænset i henhold til UDK-loven. Manglende datafiltrering Datoafgrænsningen var oprindeligt specificeret til løbende måned + 3 måneder tilbage i tiden fra dags dato. UDK har præciseret, at det følger af 8, stk. 1, at datoafgrænsningen skal være præcis 3 måneder fra fremsøgningens dato. Denne ændring skal rettes hurtigst muligt. Den midlertidige rettelse sker i anvendersystemet SAPA og skal fremgå af SAPAs databehandleraftale, underbilag 3.1 om lokal datafiltrering i SAPA. Datoafgrænsningen er specificeret til løbende måned + 3 måneder tilbage i tiden fra dags dato. Hvis kaldet fra anvendersystemet allerede indeholder en afgrænsning på dispositionsdatoen, valideres det, at afgrænsningen holder sig inden for anvendersystemets lovhjemmel. Hvis den ikke gør, returneres en fejl til anvendersystemet Terminalservicen ændrer ikke i datoafgrænsningen i kaldet. 3. Videresend forespørgsel som Terminalservicen undersøger ud fra myndighed i STS SAML-token, om det er UDK eller en kommune, der kalder. Hvis det er UDK, skal Terminalservicen benytte et token for UDK på vegne af tilmeldte (98) kommuner og kalde Ydelsesindekset. Hvis det er en kommune, skal Terminalservicen kalde Ydelsesindekset som kommunen på vegne af UDK. (læs mere om nødvendige serviceaftaler i afsnit 2.2). Den tilpassede forespørgsel videresendes til Ydelsesindekset med brug af det relevante token. 4. Modtag forespørgsel og fremfind dataafgrænsede data Ydelsesindekset fremfinder på baggrund af forespørgslen de relevante data og returnerer dem til terminalservicen. Ydelsesindekset opfatter terminalservicen som en hvilken som KOMBIT A/S Halfdansgade København S CVR Side 7 af 31

8 helst anden anvender på Ydelsesindeksets fremsøgsnitflade og gør ikke noget særligt i forhold til terminalservicen. 5. Filtrer data på baggrund af anvenders lovhjemmel Terminalservicen modtager det resulterende datasæt tilbage fra Ydelsesindekset og fjerner de felter/attributter fra datasættet, som anvenderen jf. Loven om Udbetaling Danmark ikke må modtage (læs mere om hvilke data der returneres til anvenderen i afsnit ). Det filtrerede datasæt sendes derefter videre til anvendersystemet. 6. Modtag ydelsesdata Anvendersystemet modtager det filtrerede datasæt fra Terminalservicen. 1.3 Servicebetingelser for den samlede integration Terminalservicen er implementeret som en service på serviceplatformen, hvorfor nedenstående servicebetingelser følger serviceplatformens vilkår Servicemål Parameter Flow 1 Tidsrum Serviceplatformen driftsafvikles hele døgnet alle dage bortset fra når der udføres ændringer/hvor der er servicevinduer [SPref]. Ydelsesindekset har kontinuerlig drift 24*7. Kun fatale fejl må betyde nedetid [STS-ref]. 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 Ydelsesindekset har forskellig SLA på svartid alt efter forespørgselskompleksitet og fraktil: SLA for læsning i Ydelsesindekset: Simpel: Ønskede 0,3 sekund - Maksimal 0,6 sekunder Mellem: Ønskede 0,5 sekunder - Maksimal 1 sekunder Kompleks: Ønskede 1 sekund - Maksimal 2 sekunder SLA ønskede svartider: 95% SLA maksimal svartid : 99,9% KOMBIT A/S Halfdansgade København S CVR Side 8 af 31

9 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]. Servicemålene for Ydelsesindeksets driftseffektivitet er 99,85% i begge måleperioder [STS-ref]. Spidsbelastningsperiode Servicevinduer Spidsbelastningen for Serviceplatformen og Ydelsesindekset må antages at være i perioden 06:00-18:00 på arbejdsdage [SPref][STS-ref]. 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 mandag kl. 06:00. Varsling 1. måned, varighed max 8 timer [SPref]. Ydelsesindekset: Mindre opdateringer: Servicevindue: 1 gang om ugen i tidsrummet lørdag kl CET Varighed: 1 time Varsling: 1 uge Større og kritiske opdateringer: Servicevindue: Op til 1 gang pr. måned i tidsrummet lørdag kl til lørdag kl CET Varighed: 3 timer Varsling:1 måned Omlægning af miljøer, arkitektur og services: Servicevindue: 1 gang pr. kvartal i tidsrummet lørdag kl til lørdag kl CET Varighed: 8 timer Varsling: 2 måneder Service Management Informationer om driftsmeddelelser, forespørgsler og kontaktinformationer, findes på siden for Drift og Forvaltning af KDIs Services her: [KDIDrift]. KOMBIT A/S Halfdansgade København S CVR Side 9 af 31

10 1.4 Teststrategi Den planlagte test af services til installation på Serviceplatformen omfatter pt., at der udføres automatiserede tests af services og unittests. Der er tale om en robust test af sikkerhed, routing og anden kernefunktionalitet i integrationen, samt en mere simpel test af, om de enkelte operationer kan benyttes, stikprøvekontrol. Testen omfatter ikke samtlige dataelementer i operationerne. Leverandøren af Serviceplatformen er ansvarlig for denne test. Det generelle udgangspunkt for KOMBITs teststrategi er, at alle involverede parter har gennemført en robust systemtest af egen løsning, før der gennemføres test parterne imellem. Generelle informationer om ibrugtagning og test, samt kontaktinformationer for specifikke ønsker, kan findes via [KDITest]. 1.5 Forudsætninger for produktionssætning For at kunne anvende snitfalden, er der en række vilkår og forudsætninger, som skal være opfyldt af en integrationspart, der skal tilsluttes. Ved integrationspart skal forstås anvendersystemer, kildesystem osv. Disse vilkår og forudsætninger er opdelt i en generelle vilkår og forudsætning, som gælder på tværs af snitfladerne og i specifikke vilkår og forudsætninger for tilslutning til selve snitfladen. De generelle vilkår og forudsætninger er beskrevet i et samlet dokument [GVF], mens de specifikke aktiviteter der skal udføreres som forudsætning for tilslutning af en integrationspart er beskrevet for hver enkelt tilslutningspart i kapitel Køreplan for Implementering Nedenstående diagram viser køreplanen for udrulningen af et anvendersystem inden for KOMBIT rammearkitektur under monopolbrudsprojektet. Det væsentlige i køreplanen er faserne, mens en egentlig tidsplan vil følge af den faktiske implementeringsplan. Aktiviteter, som er forudsætninger og betingelser i forbindelse med ibrugtagning af en snitflade, som følge af en udrulning af et anvendersystem, vil referere til den fase, den hensigtsmæssig kan udføres i. Serviceplatformen: Ved idriftsættelse af en snitflade er alle aktiviteter afsluttet, og snitfladen er klar til anvendelse. Kildesystem: Alle aktiviteter i forhold til serviceplatformen er afsluttet, men der kan være yderligere aktiviteter i forbindelse med tilslutning af et anvendersystem eller en kommune i forhold til kildesystemet. Anvendersystem og kommune: Ved tilslutning af et anvendersystem og/eller en kommune, er der en række aktiviteter op til idriftsættelse, dels af aftalemæssig karakter, og dels også af konfigurationsmæssig karakter, som skal udføres. Er der aktiviteter, som medfører konfiguration på Serviceplatformen, vil dette ske i forbindelse med leverandørens oprettelse af serviceaftalen for kommunen. KOMBIT A/S Halfdansgade København S CVR Side 10 af 31

11 1.5.2 Særlige vilkår Der er ingen specielle vilkår for brug af nærværende service ud over de generelle vilkår, der er beskrevet under vilkår for hhv. leverandører og kommuner Supplerende information om tilslutning Intet. KOMBIT A/S Halfdansgade København S CVR Side 11 af 31

12 2 Kontekst for integrationsparter 2.1 Generelt om lovhjemmel for denne service Det anførte hjemmelsgrundlag er bestemt af det enkelte og relevante fagprojekt i KOMBIT på bestillingstidspunktet. 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 understrege, at læseren af dette dokument udelukkende skal læse hjemmelsgrundlaget som en orientering. Terminalservicen er som tidligere beskrevet implementere med det hovedformål at afgrænse udveksling af data om ydelser mellem Udbetaling Danmark og kommunerne. Derfor gennemgås den generelle lovkontekst i dette afsnit. Det forvaltningsmæssige formål er at udveksle ydelsesrelaterede informationer mellem UDK og kommunerne. Denne udveksling mellem myndigheder er imidlertid underlagt lovgivningsmæssige begrænsninger. Begrænsningerne gør sig gældende i det tilfælde, at: en kommune ønsker adgang til information om ydelser, der ejes af myndigheden UDK UDK ønsker adgang til information om ydelser ejet af en kommune Begrænsningerne er beskrevet i Loven om Udbetaling Danmark 8, stk. 1. 8, stk1 I Loven om Udbetaling Danmark, 8, stk. 1 står der: Udbetaling Danmark og kommunen har til brug for vurdering af, om oplysningen skal videregives til den anden myndighed, jf. 6, 7 og 9, og til brug for myndighedsopgaver efter den sociale og den beskæftigelsesmæssige lovgivning terminaladgang til et register med nødvendige oplysninger om, hvilke typer af kontante ydelser og økonomiske tilskud borgeren har modtaget de seneste 3 måneder, samt oplysninger om størrelsen på ydelsen og tilskuddet. For at sikre den korrekte fortolkning af 8, stk. 1 har UDK fået udarbejdet følgende notat fra kammeradvokaten: Notat om persondataretlige spørgsmål i relation til 8, stk. 1, i lov om Udbetaling Danmark. Notatet er udarbejdet af Advokatfirmaet Poul Schmith den 8. maj De i dette dokument beskrevne dataafgrænsninger for 8, stk. 1 følger dette notat. Hvis man som myndighed via et anvendersystem skal have adgang til Terminalservicen jf. 8, stk 1, får man adgang til et subsæt af information om effektueringer inden for de seneste 3 måneder + løbende måned samt de tilhørende bevillinger. Læs mere om dataafgrænsningen i afsnit KOMBIT A/S Halfdansgade København S CVR Side 12 af 31

13 Manglende datafiltrering Datoafgrænsningen var oprindeligt specificeret til løbende måned + 3 måneder tilbage i tiden fra dags dato. UDK har præciseret, at det følger af 8, stk. 1, at datoafgrænsningen skal være præcis 3 måneder fra fremsøgningens dato. Denne ændring skal rettes hurtigst muligt. Den midlertidige rettelse sker i anvendersystemet SAPA og skal fremgå af SAPAs databehandleraftale, underbilag 3.1 om lokal datafiltrering i SAPA. 2.2 Serviceaftaler Serviceaftaler er en teknisk aftale mellem to systemer om udveksling af data. Leverandøren (her Netcompany) af det system, som ønsker adgang til data i et andet system skal oprette en serviceaftale i det fælleskommunale støttesystem Administrationsmodulet. Serviceaftalen beskriver, at Modtagersystemet for Datamodtager ønsker adgang til Afsendersystemets data som ejeres af Dataejeren. Som det fremgår af ovenstående illustration skal der, for at fx en kommune kan få adgang til ydelsesdata fra Udbetaling Danmark, indgås to serviceaftaler. Én serviceaftale på forsiden af Terminalservicen mellem i dette tilfælde modtagersystemet SAPA og afsendersystemet Terminalservice, og én på bagsiden af Terminalservicen mellem modtagersystemet Terminalservice og afsendersystemet Ydelsesindeks. Disse vil blive beskrevet kort nedenfor. KOMBIT A/S Halfdansgade København S CVR Side 13 af 31

14 2.2.1 Serviceaftale på bagsiden Selve videregivelsen af data mellem to myndigheder sanktioneres via den serviceaftale der indgås mellem Terminalservicen og Ydelsesindekset på bagsiden af Terminalservicen. Denne serviceaftale giver Terminalservicen adgang til at hente data fra en myndighed og videregive disse data til en anden myndighed. Et eksempel på serviceaftalens indhold vises nedenfor: System (modtagersystemet) = SF2860 Terminalservice Service (afsendersystemet) = SF1490 Ydelsesindeks Datamodtager = Korsbæk Kommune Dataejer = Udbetaling Danmark Eftersom dataejer og datamodtager ikke er samme myndighed, er der tale om videregivelse af data mellem myndigheder. Serviceaftalen vil henvise til, at den giver adgang til data som specificeret i integrationsbeskrivelsen for Terminalservicen (nærværende dokument), og den skal godkendes af både datamodtager og dataejer = dobbelt myndighedsgodkendelse. I tilfældet, hvor UDK skal have adgang til ydelsesdata fra kommunerne, vil der ved datamodtager stå Udbetaling Danmark og ved dataejer stå en liste af alle 98 kommuner, og hver kommune skal godkende serviceaftalen Serviceaftale på forsiden For at et modtagersystem kan anvende Terminalservicen skal modtagersystemet for en kommune eller UDK indgå en serviceaftale med Terminalservicen, hvor kommunen eller UDK er datamodtager. Denne serviceaftale skal være uden videregivelse af data fra anden myndighed, da videregivelsen sker på bagsiden af Terminalservicen, og serviceaftalen skal derfor kun godkendes af den myndighed, der er datamodtager. Et eksempel på serviceaftalens indhold vises nedenfor: System (modtagersystemet) = SAPA Service (afsendersystemet) = SF2860 Terminalservice Datamodtager = Korsbæk Kommune Denne serviceaftale vil ligeledes henvise til, at den giver adgang til data som specificeret i integrationsbeskrivelsen for Terminalservicen (nærværende dokument). KOMBIT A/S Halfdansgade København S CVR Side 14 af 31

15 2.3 Kontekst for SAPA Lovhjemmel og forvaltningsmæssigt formål SAPA skal agere overblikssystem for både kommunale og UDK-medarbejdere, og skal i den forbindelse understøtte behovet for som ydelsesmedarbejder eller som frontmedarbejder (fx borgerserivice) med rådgivningsopgaver, at kunne se de tilladte data om en borgers ydelser hos en anden myndighed. SAPAs lovhjemmel følger Lov om Udbetaling Danmark, 8, stk Ønsker og forventninger til kapacitets- og servicekrav fra denne integrationspart De generelle krav til Ydelsesindekset er følgende: Baseline for forbrug: 76 mio. Servicetransaktioner Forventet forbrug år 2: 150 mio. Servicetransaktioner Forventet forbrug år 3: 180 mio. Servicetransaktioner Forventet forbrug år 4: 220 mio. Servicetransaktioner Spidsbelastning: DP: 20 Servicetransaktioner pr. sekund (spidsbelastning) DP + 1 år: 40 Servicetransaktioner pr. sekund (spidsbelastning) DP + 2 år: 50 Servicetransaktioner pr. sekund (spidsbelastning) DP + 3 år: 60 Servicetransaktioner pr. sekund (spidsbelastning) Det er ikke mulig at fordele transaktioner mellem Ydelsesindeks og Terminaladgang Specifikke forsætninger for tilslutning SAPA skal vise ydelsesdata fra anden myndighed både for kommunerne og for UDK. Nedenfor listes de aftalemæssige opgaver der skal gennemføres, for at en myndighed kan få adgang til at modtage ydelsesdata fra anden myndighed Kommune skal have adgang til UDK-data Dette kapitel beskriver de opgaver, som skal gennemføres i relation til snitfladen, for at en kommune gennem et anvendersystem kan benytte snitfladen. ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TS101 Indgåelse af Databehandleraftale mellem hver kommune og KOMBIT Aftale Kommune/ KOMBIT KOMBIT KOMBIT Fase 1 Aftale er indgået KOMBIT A/S Halfdansgade København S CVR Side 15 af 31

16 TS102 TS103 TS104 TS105 Anmodning om serviceaftale for Terminalservicens adgang til SF1490 Godkendelse af serviceaftale for Terminalservicens adgang til SF1490 Anmodning om serviceaftale for anvendersystemets adgang til SF2860 Godkendelse af serviceaftale for anvendersystemets adgang til SF2860 Konfiguration Administrationsmodul Konfiguration Administrationsmodul Konfiguration Administrationsmodul Leverandør af Terminalservice Kommune og UDK Konfiguration Administrationsmodul Leverandør af anvendersystem Leverandør af Terminalservice Kommune og UDK Leverandør af fagsystem Fase 2.2 Fase 2.2 Fase 2.2 Kommune Kommune Fase 2.2 TS101 TS102 TS103 TS104 TS105 Kommunerne skal indgå databehandler aftale med KOMBIT. Det er KOMBIT der har ansvaret for at udarbejde aftalen, kommunerne skal kun tiltræde. Aftalen er allerede indgået. Leverandøren af Terminalservicen skal via Serviceplatformens administrationsmodul anmode kommunerne og UDK om indgåelse af serviceaftale for adgang til SF1490 STS Ydelsesindeks jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. Kommunen skal godkende serviceaftalen som datamodtager og UDK skal godkende serviceaftalen som dataejer jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed] Leverandøren af anvendersystemet (SAPA) skal via Serviceplatformens administrationsmodul anmode hver kommune om indgåelse af serviceaftale jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. I forbindelse med tilslutning til 2860, skal korrekte endpoints for snitfladen angives. Serviceaftalen dækker alle services, beskrevet i denne integrationsbeskrivelse. Kommunen skal godkende serviceaftalen jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed] UDK skal have adgang til kommunernes data Dette kapitel beskriver de opgaver, som skal gennemføres i relation til snitfalden, for at UDK gennem et anvendersystem kan benytte snitfladen. KOMBIT A/S Halfdansgade København S CVR Side 16 af 31

17 ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TS201 TS202 TS203 TS204 TS205 Indgåelse af Databehandleraftale mellem ATP og KOMBIT Anmodning om serviceaftale for Terminalservicens adgang til SF1490 Godkendelse af serviceaftale for Terminalservicens adgang til SF1490 Anmodning om serviceaftale for anvendersystemets adgang til SF2860 Godkendelse af serviceaftale for anvendersystemets adgang til SF2860 Aftale ATP/ KOMBIT Konfiguration Administrationsmodul Konfiguration Administrationsmodul KOMBIT KOMBIT Fase 1 Aftale er indgået Konfiguration Administrationsmodul Leverandør af Terminalservice Kommune og UDK Konfiguration Administrationsmodul Leverandør af anvendersystem Leverandør af Terminalservice Kommune og UDK Leverandør af fagsystem Fase 2.2 Fase 2.2 Fase 2.2 UDK UDK Fase 2.2 TS201 TS202 TS203 TS204 ATP skal indgå databehandler aftale med KOMBIT. Det er KOMBIT der har ansvaret for at udarbejde aftalen, ATP skal kun tiltræde. Aftalen er allerede indgået. Leverandøren af Terminalservicen skal via Serviceplatformens administrationsmodul anmode kommunerne og UDK om indgåelse af serviceaftale for adgang til SF1490 STS Ydelsesindeks jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. UDK skal godkende serviceaftalen som datamodtager og kommunerne skal godkende serviceaftalen som dataejer jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS- Sikkerhed] Leverandøren af anvendersystemet (SAPA) skal via Serviceplatformens administrationsmodul anmode UDK om indgåelse af serviceaftale jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed]. I forbindelse med tilslutning til 2860, skal korrekte endpoints for snitfladen angives. Serviceaftalen dækker alle services, beskrevet i denne integrationsbeskrivelse. KOMBIT A/S Halfdansgade København S CVR Side 17 af 31

18 TS205 UDK skal godkende serviceaftalen jf. Vilkår for anvendelse af sikkerhedsmodellen i Rammearkitekturen [STS-Sikkerhed] 3 Specifikation for integrationsparter 3.1 Specifikation af endpoints for SAPA I dette afsnit gennemgås de enpoint der er relevante for anvendersystemerne Overordnet forretningslogik Fagsystemet kalder Endpoint EP_FS1 med f.eks. Bevillingsmodtager, Periode og KLE-nummer på Serviceplatformen. Terminalservicen sikrer adgangsstyring, kald til ydelsesindekset samt lovmedholdelig filtrering af data Oversigt over endpoints ID Navn Reference til wsdl* Servicenavn på Serviceplatformen** Version på Serviceplatformen*** EP_FS1 TerminaladgangService [WSDL- SP]/wsdl/token/ TerminalAdgang- Service.wsdl TerminalAdgang 4.0 eller 5.0 Servicenavn: TerminalAdgang- Service Operationsnavn: fremsoeg * Referencen [WSDL-SP] findes i referencelisten i starten af dette dokument, og i referencelisten henviser til entydig version af referencen. ** Servicenavn refererer til det navn man kan finde servicen under på Serviceplatformens administrationsside (i relevant miljø). *** Version referer til den version af servicen på Serviceplatformens administrationsside, som denne integrationsbeskrivelse omhandler Beskrivelse af endpoint EP_FS1 - TerminaladgangService Transportspecifikation Serviceudstiller Serviceplatform er serviceudstiller. KOMBIT A/S Halfdansgade København S CVR Side 18 af 31

19 Serviceanvender Fagsystemer er serviceanvender Teknologisk understøttelse Snitfladen er implementeret som en SOAP webservice, version Teknisk endpoint Endpointoplysning er angivet i tabellen i afsnit Teknisk retning for udveksling Fagsystemet kalder Serviceplatformen for at hente ydelsesdata Dataretning for udveksling Serviceplatformen leverer begrænsede data fra Ydelsesindekset til fagsystemet Service invokation / Triggers Kommunikationen initieres af, at en sagsbehandler i et fagsystem har behov for at se de samlede ydelser for kommunerne og UDK Dataspecifikation Da der er tale om en transformationsintegration med dataafgrænsning (filtrering) svarer dataspecifikationen for servicen til dataspecifikationen i schema-filerne udstillet fra Ydelsesindekset Inputdata: Der vil ikke være filtrering på requestet udover nedenstående håndtering af periode i forhold til effektueringens dispositionsdato. Terminalservicen undersøger, om requestet indeholder en datoafgrænsning på Økonomisk effektuerings dispositionsdato: Hvis requestet indeholder en datoafgrænsning, undersøges det, om den angivede datoafgrænsning overholder nedenstående regler. o Hvis den angivede datoafgrænsning ikke overholder nedenstående regler, afvises requestet og der sendes en fejlmeddelelse tli anvendersystemet. Hvis requestet IKKE indeholder en datoafgrænsning, indsætter Terminalservicen en datoafgrænsning efter nedenstående regler. Følgende felter i request udfyldes: yi:fremsoegydelseindeksinput/yi:soegudtryk/yi:soegoekonomiskeffektueringindeks/oef:attributliste/gd:lokaludvidelseliste/oef:soegegenskaberlokaludvidelse/oef:dispositionsdatointerval/go:fratidspunkt = StartTidspunkt for afgrænsning yi:fremsoegydelseindeksinput/yi:soegudtryk/yi:soegoekonomiskeffektueringindeks/oef:attributliste/gd:lokaludvidelseliste/oef:soegegenskaberlokaludvidelse/oef:dispositionsdatointerval/go:tiltidspunkt = SlutTidspunkt for afgrænsning KOMBIT A/S Halfdansgade København S CVR Side 19 af 31

20 Regler for datoafgrænsning: Anvendersystemet modtager effektueringer med en dispositionsdato inden for 3 måneder + løbende måned. Datoafgrænsningen anvender feltet Dispositionsdato på Økonomisk effektuering og beregnes ud fra dags dato som vist i eksemplet her (dags dato = 15. januar 2016): StartTidspunkt for afgrænsning = 1. oktober 2015 SlutTidspunkt for afgrænsning = 31. januar 2016 Manglende datafiltrering Datoafgrænsningen var oprindeligt specificeret til løbende måned + 3 måneder tilbage i tiden fra dags dato. UDK har præciseret, at det følger af 8, stk. 1, at datoafgrænsningen skal være præcis 3 måneder fra fremsøgningens dato. Denne ændring skal rettes hurtigst muligt. Den midlertidige rettelse sker i anvendersystemet SAPA og skal fremgå af SAPAs databehandleraftale, underbilag 3.1 om lokal datafiltrering i SAPA. Outputdata: Svaret er en delmængde af det svar, som YdelsesIndekset udstiller ved forespørgsel med samme parameter. Indholdet indeholder følgende delmængde data, beskrevet med reference til ydelsesindekset. Indholdet af de enkelte felter er beskrevet i [ANVISNING]. Standardretur ID Bevilling ID Bevillingssag yi:fremsoegydelseindeksoutput/sd:standdardretur sd:statuskode sd:fejlmeddelelse yi:fremsoegydelseindeksoutput/yi:bevillingfiltreretoejebliksbillede/ bi:objekttype/sd:uuididentifikator yi:fremsoegydelseindeksoutput/yi:bevillingfiltreretoejebliksbillede/ Sagstype bi:registrering/bi:relationliste/bi:bevillingssag/gd:type Kan være URN eller UUID ReferenceId Sagsreference bi:registrering/bi:relationliste/bi:bevillingssag/gd:referenceid Kan være URN eller UUID Brugervendtnøgle Brugervendt id bi:registrering/bi:relationliste/bi:bevillingssag/bi:brugervendtnoegle Fulde navn Sagens titel bi:registrering/bi:relationliste/bi:bevillingssag/bi:fuldtnavn BrugerRef bi:registrering/bi:relationliste/bi:bevillingspart/gd:virkning/sd:aktoerref Kan være URN eller UUID Bevillingspart relationsrolle Be- UUID bi:registrering/bi:relationliste/bi:bevillingspart/gd:rolle Kan være URN eller villings- modtager KOMBIT A/S Halfdansgade København S CVR Side 20 af 31

21 Ansvarlig og/eller Ejer attributer attributer attributer attributer attributer attributer bi:registrering/bi:relationliste/bi:bevillingspart/gd:referenceid bi:registrering/bi:relationliste/bi:bevillingspart/bi:brugervendtnoegle bi:registrering/bi:relationliste/bi:bevillingspart/bi:fuldtnavn bi:registrering/bi:relationliste/bi:bevillingspart/bi:cpr-nr bi:registrering/bi:relationliste/bi:bevillingspart/bi:cvr-nr bi:registrering/bi:relationliste/bi:bevillingspart/bi:se-nr bi:registrering/bi:relationliste/bi:bevillingspart/bi:p-nr bi:registrering/bi:relationliste/bi:bevillingsaktoer/gd:referenceid Kan være URN eller UUID Kan være URN eller UUID BevilgetYdelse Virkning Id relationsrolle Ejer bi:registrering/bi:relationliste/bi:bevillingsaktoer/gd:rolle eller Ansvarlig objekttype bi:registrering/bi:relationliste/bi:bevillingsaktoer/gd:type OrgEnhed yi:fremsoegydelseindeksoutput/yi:bevillingfiltreretoejebliksbillede/ FraTidspunkt Kan være Tidsstempel- DatoTid eller Graense- Indikator Kan være Tidsstempel- DatoTid eller Graense- Indikator TilTidspunkt bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:virkning/sd:fratidspunkt bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:virkning/sd:tiltidspunkt bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:id Kan være URN eller UUID. Aktør kan kun være Ansvarlig og/eller ejer Kan være URN eller UUID Relationsid bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:itsystem/bi:referenceid Kan være URN eller UUID Ansvarlig IT system og/eller Afsender IT system Relationsrolle "Master" Systemnavn SystemURI bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:itsystem/bi:rolle bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:itsystem/bi:systemnavn bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:itsystem/bi:systemuri Kan være URN eller UUID Primær KlassifikatioceID Reference bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:ydelse/bi:klassifikation/bi:referen- UUID "Primaer- bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:ydelse/bi:klassifikation/bi:rolle UUID på rollen Klasse" Opgave klassifikation KLE-nummer bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:ydelse/bi:klassifikation/bi:brugervendtnoegle Ydelsesklasse bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:ydelse/bi:referenceid Kan være URN eller UUID Ydelsesnavn bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:ydelse/bi:ydelsesnavn bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:oekonomiskeffektueringsplan/bi:beregningsfrekvens bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:oekonomiskeffektueringsplan/bi:forudbagud bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:oekonomiskeffektueringsplan/bi:dispositionsdag Dispositionsdag Ydelsesbeløb yi:fremsoegydelseindeksoutput/yi:bevillingfiltreretoejebliksbillede/ Effektueringsplan Beregningsfrekvens ForudBagud Tekstuel beskrivelse af, udbetalingdsagen fx sidste bankdag i månede. Det bevilgede bruttobeløb, hvilket der tages udgangspunkt i ved beregning af den enkelte effektuering. bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:oekonomiskeffektueringsplan/bi:ydelsesbeloeb Hvor ofte udbetales ydelsen fx månedligt. KOMBIT A/S Halfdansgade København S CVR Side 21 af 31

22 YdeleId bi:registrering/bi:attributliste/bi:bevilgetydelse/bi:oekonomiskeffektueringsplan/bi:manueltgodkendes yi:fremsoegydelseindeksoutput/yi:oekonomiskeffektueringfiltreretoejebliksbillede/ Skal Manuelt godkendes Økonomisk Ydelseseffektuering YdelsesperiodeStartdato YdelsesperiodeSlutdato Ydelsesbeløb oei:registrering/oei:relationliste/oei:oekonomiskydelseeffektueringrelation/oei:ydelsesperiodestartdato oei:registrering/oei:relationliste/oei:oekonomiskydelseeffektueringrelation/oei:ydelsesperiodeslutdato oei:registrering/oei:relationliste/oei:oekonomiskydelseeffektueringrelation/oei:ydelsesbeloeb Bruttobeløbet på den enkelte ydelse, som udbetales på effektueringen. Klassifikationsbeskrivelse ReferenceID oei:registrering/oei:relationliste/oei:oekonomiskydelseeffektueringrelation/oei:klassifikationsbeskrivelse oei:registrering/oei:relationliste/oei:oekonomiskydelseeffektueringrelation/gd:referenceid oei:registrering/oei:relationliste/oei:oekonomiskydelseeffektueringrelation/ oei:bevilgetydelseid JA eller NEJ UUID på den Økonomiske effektuering, som ydelseseffektueringen er knyttet til. Idet på den bevilgede ydelse, som effektueringen er tilknyttet. KOMBIT A/S Halfdansgade København S CVR Side 22 af 31

23 Mangler i datafiltrering I den version af Terminalservicen, som denne integrationsbeskrivelse beskriver, mangler følgende filtrering af outputtet for at følge lovhjemlen i Lov om Udbetaling Danmark, 8, stk. 1: Anvendersystemet modtager bevillingsobjekter tilbage, hvortil der ikke er tilknyttet effektueringer inden for den angivede periode. Disse bevillingsobjekter skal sorteres fra inden anvendelse af output i anvendersystemet. Anvendersystemet modtager udover positive effektueringsobjekter også effektueringsobjekter med negative og 0-beløb. Disse effektueringer må jf. UDK ikke udstilles af anvendersystemet, da de giver viden om modregninger, som anden myndighed ikke må få indsigt i. Bevillingen skal altid vises uanset om beløbet er negativt, positivt eller et 0- beløb. Anvendersystemet modtager i output ydelsesbeløbet for den enkelte økonomiske ydelseseffektuering. Dermed skal anvendersystemet selv opsummere beløbene for hver Økonomisk effektuering. I stedet burde outputtet indeholde attributten SamletBruttobeloeb, som ligger på den Økonomiske effektuering, så anvendersystemet ikke selv skal foretage summering for at finde det samlede effektuerede beløb. Anvendersystemet modtager i output datoerne YdelsesperiodeStartdato og YdelsesperiodeSlutdato for den enkelte økonomiske ydelseseffektuering. I stedet burde outputtet indeholde attributterne Startdato og Slutdato fra den Økonomiske effektuering. Anvendersystemet skal derfor, når der skal vises en periode for den samlede effektuering, vise den tidligste YdelsesperiodeStartdato og den seneste YdelsesperiodeSlutdato, som er knyttet til effektueringen. Anvendersystemet må ikke vise perioderne for de enkelte ydelseseffektueringer. Den manglende datafiltrering vil midlertidigt blive foretaget i anvendersystemet SAPA jf SAPAs databehandleraftale, underbilag 3.1 om lokal datafiltrering i SAPA. Fejlbesked Ved fejl bliver der genereret en standard soap-fault med følgende indhold: Niv Feltnavn Kard Værdisæt Betegnelse 1 TransportKvittering 2 TransportValideringKode 1 Ok Advarsel Angiver resultatet af valideringen. Ved Fejl er beskeden ikke behandlet, og må derfor genfremsendes når problemet er løst. Fejl 2 Begrundelse 0:1 Tekst Dette er en tekst fra modtageren, der forklarer hvorfor et objekt er afvist. KOMBIT A/S Halfdansgade København S CVR Side 23 af 31

24 Niv Feltnavn Kard Værdisæt Betegnelse 2 FejlListe 0:n - Lister alle de valideringsfejl der er identificeret. Benyttes kun ved Advarsel eller Fejl. 3 FejlKode 1 Tekst Entydig identifikation af fejlen 3 FejlTekst 1 Tekst Beskrivelse af fejlen Sikkerhed Servicen skal udstilles som en fælleskommunal service, der benytter det fælleskommunale støttesystem Adgangsstyring til at autentikere og autorisere, som defineret i RA STS [STS-Sikkerhed] Leverancesikkerhed og fejlhåndtering Såfremt Endpoint er utilgængelig er det fagsystemets ansvar at gentage kaldet. Fejl fra Ydelsesindekset gennemstilles til fagsystemet, som skal agere ud fra disse koder Servicemål Se afsnit Testplan Se afsnit Specifikation af endpoints for Ydelsesindeks Integrationen benyttes til at Serviceplatformen på vegne af en myndighed kan få adgang til myndighedens ydelsesdata. Ydelsesindekset udstiller denne søge-service, hvor der kan fremsøges Ydelsesdata i Ydelsesindekset. KOMBIT A/S Halfdansgade København S CVR Side 24 af 31

25 3.2.1 Overordnet forretningslogik Serviceplatformen kalder Endpoint EP_YI1 med f.eks. Part, Aktør, Periode og KLE-nummer på Ydelsesindekset for at hente myndighedens (Aktør) Ydelsesdata for en Bevillingsmodtager (Part) med begrænsninger i Periode og KLE-nummer Oversigt over endpoints ID Navn EP_YI1 YdelseIndeksService Operation Fremsoeg (operation på BevillingIndeks og ØkonomiskEffektueringIndeks) Beskrivelse af endpoint EP_YI1 YdelseIndeksService (Fremsoeg) Transportspecifikation Serviceudstiller Ydelsesindekset er serviceudstiller Serviceanvender Serviceplatformen er serviceanvender Teknologisk understøttelse Snitfladen er implementeret som en SOAP webservice, version Teknisk endpoint Følgende specificerer endpoint-oplysninger for produktionsmiljø og testmiljø. Miljø: Produktion URI til WSDL [WSDL-EXT] Se filen wsdl\ydelseindeks.wsdl Endpoint navn [Afklaring/SP: Endelig Url skal indsættes] Endpoint IP [Afklaring/SP: Endelig IP skal indsættes] Miljø: Test URI til WSDL [WSDL-EXT] Se filen wsdl\ydelseindeks.wsdl Endpoint navn KOMBIT A/S Halfdansgade København S CVR Side 25 af 31

26 [Afklaring/SP: Endelig Url skal indsættes] Endpoint IP [Afklaring/SP: Endelig IP skal indsættes] Teknisk retning for udveksling Serviceplatformen kalder Ydelsesindekset for at hente ydelsesdata Dataretning for udveksling Ydelsesindekset leverer data fra Ydelsesindekset til Serviceplatformen Service invokation / Triggers Kommunikationen initieres af, at en sagsbehandler i et fagsystem har behov for at se de samlede ydelser for kommunerne og UDK Dataspecifikation Da der er tale om en transformationsintegration med dataafgrænsning (filtrering) svarer dataspecifikationen for servicen til dataspecifikationen i schema-filerne udstillet fra Ydelsesindekset: [Eksempel på beskrivelse af XSD endpoint] Miljø: Produktion Inputdata [WSDL-EXT]/XSD FremsoegYdelseIndeksInput i YdelseIndeksOperationer.xsd Outputdata [WSDL-EXT] /XSD FremsoegYdelseIndeksOutput i YdelseIndeksOperationer.xsd Sikkerhed Servicen benytter det fælleskommunale støttesystem Adgangsstyring til at autentikere og autorisere, som defineret i RA STS [STS-Sikkerhed] Leverancesikkerhed og fejlhåndtering Servicen leverer forespørgsler At least once. Ved eventuelle fejl videresender serviceplatformen fejlen til det spørgende fagsystem, som herefter vil genfremsende forespørgslen Servicemål Se afsnit Testplan Se afsnit 1.4. KOMBIT A/S Halfdansgade København S CVR Side 26 af 31

27 4 Beskrivelse for integrationsplatforme 4.1 Beskrivelse for Serviceplatformen Nærværende afsnit angiver den integrationsfunktionalitet, som Terminalservicen håndterer i interaktionen mellem integrationsparter. En integration kan understøttes af flere integrationsflow, som vil være beskrevet hver for sig i nærvæ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. Figuren nedenfor viser hvilke komponenter og endpoints, der indgår i integrationen. Fagsystem EP_FS1 Serviceplatformen IF01 TerminalAdgang EP_YI1 Ydelsesindeks Oversigt over integrationsflows ID Navn IF01 TerminalAdgang Integrationsflow IF01: TerminalAdgang Anvendte service endpoints Endpoint ID Navn på endpoint Dokument-reference EP_FS1 TerminaladgangService Afsnit EP_YI1 YdelseIndeksService Afsnit Integrationstype Integrationen er en transformationsintegration, hvor Terminalservicen sikrer at tilføje dato-afgrænsninger i request samt hvis den kaldende myndighed i token er UDK, skal der kaldes mod Ydelsesindekset som UDK på vegne af 98 kommuner, og hvis den kaldende myndighed er en kommune, KOMBIT A/S Halfdansgade København S CVR Side 27 af 31

28 skal Ydelsesindekset kaldes af kommunen på vegne af UDK. Responset filtres efterfølgende ud fra regler beskrevet i transformationsafsnittet Diagram over integrationsflowet Jf. figuren nedenfor indgår følgende integrationsflows i integrationen. Anvendersystem Terminalservice Ydelsesindeks Synkront kald Terminalservice Terminalservicen indsætter dato-afgrænsning EP_FS1 Kald YI som UDK på vegne af 98 kommuner YI returnerer resultat Kald YI som kommune på vegne af UDK YI returnerer resultat Terminalservicen filtrerer data i response Terminalservcien returnerer data til FS Myndighed UDK Kommune EP_YI1 EP_YI1 1 Anvendersystemet kalder TerminaladgangServicen med søgeparametre. 2 Terminalservicen validerer dato-afgrænsning i request 2.1 Default er 3 måneder. Hvis der er oprettet en parameter for det kaldende IT system og denne er forskellig fra de 3 måneder, så bruges denne i stedet for forudsat, at KOMBIT har sikkerhed for, at reglerne omkring perioder bliver korrekt ift. udstillingen af data til brugerne. 3 Terminalservicen tjekker kaldende myndighed: 3.1 Hvis UDK kaldes YdelsesIndeksService med token for UDK på vegne at tilladte (98) kommuner 3.2 Hvis kommune kaldes YdelsesIndeksService med token for kommune på vegne af UDK 4 Terminalservice filtrer svar til anvendersystemet. 5 Terminalservice returnerer svar til anvendersystemet Datatransformering Datatransformation request Requestet og transformation af samme er beskrevet i kapitel Dataspecifikation. Datatransformation response KOMBIT A/S Halfdansgade København S CVR Side 28 af 31

29 Responset fra Ydelsesindekset skal mappe over i det format, som er beskrevet i kapitel Dataspecifikation. Datatransformation fejl Ved fejl i svaret fra Ydelsesindekset, skal dette, StandardRetur, mappes til Serviceplatformens standard fejl og udløse en soap fault. Det benytte samme mapning som til snitflade SF1490 YdelsesIndeks v Datapersistering N/A Databerigelse Der skal laves en datatransformation på både request og response som beskrevet i Routing N/A Orkestrering N/A Sikkerhed Servicen benytter det fælleskommunale støttesystem Adgangsstyring til at autentikere og autorisere, som defineret i RA STS [STS-Sikkerhed]. På Serviceplatformen udstilles en del af sikkerhedsmodellen i CallContext, hvor den på Ydelsesindeks-siden benytter information i Soap Header. Serviceplatformen skal mappe mellem disse to modeller. Servicen skal ud fra kaldende myndighed i STS-token lave følgende skift af token: Myndighed = UDK, skal servicen kalde YdelsesIndeksServicen for UDK på vegne af tilmeldte (98). Myndighed = kommune, skal servicen kalde YdelsesIndeksServicen for kommunen på vegne af UDK. Terminalservicen kaldes med et token baseret på aftalen mellem anvendersystem og Terminalservicen. Terminalservicen skal kalde Ydelsesindekset på vegne af den myndighed, som der skal kaldes på vegne af skift fra UDK til 98 kommuner eller kommune til UDK. I den forbindelse skal Terminalservicen hente et ny token fra den nye myndighed, som skal benyttes i kaldet mod Ydelsesindekset baseret på den aftale der er mellem Terminalservicen og Ydelsesindekset (UC-SEC-04). Terminalservicen skal derfor indgå serviceaftaler med ydelsesindekset med videregivelse af data. KOMBIT A/S Halfdansgade København S CVR Side 29 af 31

30 Der skal indgås separate skriftlige aftaler mellem UDK og de 98 kommuner om at få adgang til Terminaladgangsdata på vegne af den anden myndighed Logning Det samlede revisionsspor skal logges, så det er muligt at afgøre, hvilke myndigheder, der har hentet hvilke data og hvornår. Logdata opbevares i 400 dage, hvorefter de slettes Testdata og testfaciliteter Se afsnit Konfiguration Se afsnit Supplerende information Ingen supplerende information Tilslutning til integrationspart: Serviceplatformen Dette kapitel liste de forudsætninger, som skal være opfyldt for at Serviceplatformen kan udstille den pågældende snitflade. ID Aktivitet Opgavekategori Komponent Ansvarlig Udførende Fase og afhængighed Kommentar TSP01 Registrering af Serviceinformation for Terminalservicen i Serviceplatformen Konfiguration Serviceplatformen KOMBIT/ KDI KOMBIT/ KDI Fase 1 TSP02 Registrering af Terminalservice i Administrationsmodul Konfiguration Administrationsmodul KOMBIT/ KDI KOMBIT/ KDI Fase 1 TSP01 - Der skal registres information vedrørende Terminalservice og Ydelsesindekset i Serviceplatformen, så der kan oprettes serviceaftaler for kommunerne, bl.a. skal logiske og fysiske endpoint skal være relateret. KOMBIT A/S Halfdansgade København S CVR Side 30 af 31