Tilbudsportalen Servicespecifikation

Transkript

1 Socialstyrelsen Tilbudsportalen Servicespecifikation Web-services Version 1 Ole Martin Henriksen, Socialstyrelsen

2 DOKUMENTHISTORIK Navn Dato Ændring Ole Martin Henriksen (Socialstyrelsen) Version 0.9 Ole Martin Henriksen (Socialstyrelsen) Version 1.0 Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 2

3 INDHOLD 1 Indledning Målgruppe Dokumentets disposition Forvaltningsprincipper Integrationsaftale Services udstilles i et servicekatalog Versionering Opbygning af servicekataloget Læsevejledning Formen af beskrivelse af web services og -operationer Roller og ansvar Generelle tekniske forhold REST Sikkerhed Authentication af system-til-system (S2S) bruger HTTP-Headere Konkret overholdelse af standarder Kaldeeffekt-kategorier Tilbudsportalen Tilbud Forretningsmæssigt overblik Strukturen af data til et tilbud Organisation It-bruger Personale Målgruppepakke Indsats IndsatsTakst YdelsesTakst FagligTilgang Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 3

4 Metode Stamoplysninger Barn BrugerBetalingType BrugerBetalingPris BrugerBetaling Pladser Medarbejder Adresse Tilsynsblanket Paabud Audit - Indberetning Forretningsmæssigt overblik Begrebsmodel til Audit Kvalitetsmodel Procesinformation REST Services - Tilbudsportalen Ressourcer Metadata.xml Entity/view.xml Overblik Unik identifikation Use Cases Use case: henttilbudsdetaljer Use case: oprettilbud Tilsynsblanket Use case: indberettilsynsblanket Audit data Use case: indberetauditdata Filer Use case: henttilbudsfil Sikkerhed Definitioner System-til-System autentifikation med Basic Authentication og SSL Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 4

5 5.3 Single-signon X-REST-identity header Fejlhåndtering Overordnet om fejlsituationer Kommunikationsscenarier Fejlhåndtering ved synkron kommunikation Konkrete fejlsituationer Konkrete fejlbeskeder FAQ Spørgsmål: Stamoplysninger vs stamoplysninger_r Spørgsmål: Målgruppekategorier Spørgsmål: Indberetter på et tilbud Spørgsmål: Sygefravær på tilbuddet Spørgsmål: Recursive = Spørgsmål: Faggrupper og timetal Spørgsmål: Arbejdstimer pr. uge for tilbud og afdeling Spørgsmål: Driftsaftaler Spørgsmål: Paragraffer på indsats Spørgsmål: Resultatmetoder Spørgsmål: Felter på tilsynsblanket Spørgsmål: Navne på afdelinger Spørgsmål: Relation mellem organisation og indsatser Spørgsmål: Navgivning af takstniveauer Spørgsmål: kvalitetsmodel Spørgsmål: konklusioner på tilsynsblankt og audit - kvalitetsmodel Entiteter og attributter Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 5

6 Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 6

7 1 Indledning Formålet med denne servicespecifikation er at sikre en formel beskrivelse og en forståelse af de services Tilbudsportalen (TP) udbyder til eksterne aktører. Servicespecifikationen er udarbejdet med fokus på system-til-system snitflader. I figur 1 markeret med rød skravering data ind data ud data ind data ud data ind data ud data ind Figur 1 - Tilbudsportalens grænseflader og snitflader Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 7

8 Figur 2 viser eksempler på system-til-system-integration mellem eksterne aktører og Tilbudsportalen. Figur 2 - Tilbudsportalen og eksterne aktører Bemærk: Det er ikke servicespecifikationens formål at give læseren en dybere forretningsmæssig indsigt i Tilbudsportalen. Det betyder at viden om muligheder og begrænsninger for de enkelte indberetninger skal hentes via andre kilder. En af disse er de informationer Tilbudsportalen stiller til rådighed på deres hjemmeside - Det er ikke servicespecifikationens formål, at beskrive den interne funktionalitet i TP løsningen. Fokus er udelukkende på system-til-system snitflader og den information, der gør det muligt at anvende de udstillede services. Dette dokument er generisk af natur og følger derfor ikke nødvendigvis versioneringen af services. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 8

9 1.1 Målgruppe Målgruppen for dette dokument er: Udviklere, der arbejder med udviklingen af TP-løsningen. System- og forretningsapplikations-udviklere hos de aktører, der ønsker at benytte TP s system-tilsystem-grænseflade. Projektdeltagere hos Socialstyrelsen. Projektdeltagere hos eksterne leverandører for Socialstyrelsen herunder IT Arkitekterne. 1.2 Dokumentets disposition Udover nærværende kapitel, er servicekataloget organiseret i følgende kapitler: Kapitel 1 og 2 beskriver de principper der ligger til grund for web services og web service ressourcer, som er beskrevet i servicespecifikationen. Kapitel 3 og 4 indeholder en tabel oversigt over web services og web service operationer, som TP-løsningen udstiller. Kapitel 5 beskriver den sikkerhed, som TP-løsningen baserer sig på. Kapitel 6 indeholder fejlsituationer, som kan opstå i TP-løsningen. Kapitel 7 indeholder en FAQ oftest stillede spørgsmål. Kapitel 8 indeholder en oversigt over entiteter og deres tilhørende attributter. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 9

10 1.3 Forvaltningsprincipper Principper er generelle regler og vejledninger, som har en blivende værdi og som sjældent ændres. Her informerer principperne om hvordan TP-løsningens services bedst understøtter Socialstyrelsens mission og mål med TP-projektet. De principper der angives her sætter rammen for de services, der udvikles til TP løsningen. Principperne gælder alle services der udstilles i servicekataloget og som anvendes af den interne og eksterne portal samt de professionelle aktører. Der kan f. eks. være principper for navngivning, servicegranularitet osv. Principper kan understøttes af konkrete standarder og uddybende vejledninger Integrationsaftale Inden snitflader kan benyttes skal der indgås en integrationsaftale mellem Socialstyrelsen og den eksterne aktør. Se mere her: Services udstilles i et servicekatalog Services er udstillet i Socialstyrelsens servicespecifikation, forankret i Socialstyrelsens begrebsmodel, med servicekvalitet og vilkår for anvendelse Versionering Versionering af Tilbudsportalen følger versionering af Tilbudsportalens indberetning. Lovgivningsmæssige ændringer kan træde i kraft en given dato. Hvis lovændringen berører systemets snitflader, er der ikke mulighed for at have mere end en version af snitfladen tilgængelig i drift. Der findes derfor altid kun én gældende version af TP services. Ved ændringer i TP services gælder følgende: a) Mindre ændringer er bagud kompatible. Dette er f.eks. tilfældet ved tilføjelse af et optionelt element i en REST service. b) Større ændringer giver migration til ny version (gammel version kan herefter ikke anvendes) Ændringer er altid gældende pr. en given dato. Dette gælder uanset om det er større eller mindre ændringer. Det er aktørernes eget ansvar, at deres systemer er opdateret i forhold til den gældende version. En gældende version vil inkludere: a) Begreber b) Datamodel c) URI er d) Forretningsregler e) Valideringsregler Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 10

11 Der vil dog ikke altid være ændringer til alle dele og eksterne TP service-klienter forventes at kunne køre uændret videre for en række standard ændringsscenarier eksempelvis tilføjelse af en ikke krævet attribut. Mindre versioner ændrer (pr. definition) ikke på eksempelvis gyldigheden af eksisterende indberetninger. De er bagud- og forudkompatible. Større versioner kan kræve omvendt opgradering og migrering. Valideringer i systemet vil altid kun eksistere i aktuel version. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 11

12 2 Opbygning af servicekataloget Dette afsnit beskriver skabeloner for beskrivelser til REST-services som TP-løsningen udstiller. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 12

13 2.1 Læsevejledning Formen af beskrivelse af web services og -operationer Beskrivelsen af hver service og deres operationer følger nedenstående skabelon. Service - ressource Beskrivelse <Beskrivelse i forretningstermer af hvad formålet med servicen er > Roller Responsible: Accountable: Consulted: Informed: Operation - <operationsnavn> Beskrivelse Input <Beskrivelse i forretningstermer af hvad formål med operationen er og hvad den producerer> <parameternavn> <Beskrivelse i forretningsmæssige termer af parameteren og dens betydning> Output <parameternavn> eller N/A hvis operationen ikke har et output. <Beskrivelse i forretningsmæssige termer af parameteren og dens betydning> Hvis der angives et output, er der tale om en synkron operation. Fejlhåndtering Sikkerhed Interaktionsmønster Kaldeeffekt <Angivelse af relevante fejlhåndteringsmønster> <Angivelse af fx: Reliable operation <Angivelse af hvilken type forretningsmæssigt interaktionsmønster operationen indgår i - se afsnit <Angivelse af hvilke kategori operationen tilhører mht. hvad effekten er af Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 13

14 at kalde den - se afsnit POST Eksempel Figur 3: Skabelon for beskrivelsen af web services og web service ressourcer Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 14

15 2.1.2 Roller og ansvar Som en del af beskrivelsen af den enkelte web service, er det angivet hvilken organisatorisk enhed, der varetager givne roller i forhold til den pågældende web service. Rollerne er angivet efter den såkaldte RACImodel, som er en metode til angivelse af roller og ansvar. RACI-modellen opererer med rollerne: Responsible Ansvarlig Accountable Ejer Consulted Afhængig af Informed Interessent Responsible Rollen responsible er ansvarlig for at implementere og vedligeholde servicen. I praksis vil det sige, at rollen er ansvarlig for at etablere de resources, der beskriver service interfacet, for at realisere ("kode" og "deployere") servicen, samt for at gøre den tilgængelig og drifte den. Der er mulighed for at der kan optræde flere, der er responsible. Eksempelvis kan responsible være ansvarlig for at realisere ( kode og deployere ) services, samt gøre dem tilgængelige og sørge for driften af dem. Responsible kan uddelegere ansvaret til andre roller fra RACI-modellen. Accountable Rollen accountable har som den forretningsmæssige ejer af servicen ansvar for: at service-specifikationen dækker de forretningsmæssige behov at service-specifikationen anvender de rigtige forretningsmæssige begreber i de beskeder, som servicen udveksler. Den accountable kan ikke uddelegere ansvaret. Som udgangspunkt vil Socialstyrelsen altid være accountable, da Socialstyrelsen er den naturlige ejer af alle services. Consulted Rollen consulted tildeles/varetages typisk af interessenter, som er afhængige af en given service. Disse parter er berettiget til at skulle høres i forbindelse med enhver ændring af de services, som de er interessenter i. De skal typisk afgive et høringssvar, hvor de giver udtryk for deres syn på den planlagte ændring eller udarbejder et ændringsforslag. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 15

16 Der er en række interessenter som er afhængige af de services TP udstiller. De anvender disse services i samspil med deres egne it-systemer, og baserer en del af deres forretning på TP s services. Informed Rolle informed tildeles/varetages af interessenter som blot skal orienteres om at der foretages ændringer. Det kan fx dreje sig om sektorer, forskellige råd, OIO eller statslige myndigheder. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 16

17 2.2 Generelle tekniske forhold REST Tilbudsportalens snitflader er implementeret som REST-services. Anvendelsen af REST til kommunikation med TP tager udgangspunkt i de regler og anbefalinger som findes i Roy Fieldings beskrivelse af REST (Representational State Transfer). Her under principperne for Identification of resources, Manipulation of resources through these representations, Self-descriptive messages samt Hypermedia as the engine of application state (HATEOAS). Se en detaljeret beskrivelsen af TP s REST-services her: Sikkerhed REST-services som Tilbudsportalen udstiller, baserer sig på simpel REST over https. Services i Tilbudsportalen tilgås via Basic Authentication og tiltænkt til realisering af kritiske web service resourcer, hvor forretningssemantikken fordrer sikker kommunikation med fuld sporbarhed. Yderligere detaljer findes i Basic Authentication dokumentationen hos w3.org ( Authentication af system-til-system (S2S) bruger Tilbudsportalen anvender en-vejs certifikat authentication i forbindelse med etablering af SSL forbindelse til en web service og anvender VOCES certifikater fra TDC CA ( Figur 4: System-til-system flow viser hvordan flowet er i forbindelse med kald til beskyttet TP service. 3.-Verificerer cer9fikat Relevant-CA CA-=-Cer9ficate-Authority Aktør Server 1.-Aktør-kalder-service 2.-TP-præsenterer SSL-cer9fikat 4.-Aktør-får-adgang 9l-service TP Server TP Keystore (SSL-Servercer9fikat) Figur 4: System-til-system flow HTTP-Headere Alle REST beskeder mellem aktører og TP skal følge http standarden. Ydermere skal der benyttes en proprietær attribut som en del af http-headerne. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 17

18 X-SIV-REST-identity skal indeholde information om brugeren i det kaldende 3. parts system. Følgende viser et eksempel på indholdet af TP http beskeder: GET 01T01:00:00+01:00 HTTP/1.1 Accept-Encoding: gzip,deflate Host: admin.tilbudsportalen.dk Connection: Keep-Alive User-Agent: Apache-HttpClient/4.1.1 (java 1.5) Authorization: Basic dxnlcm5hbwu6cgfzc3dvcmq= X-SIV-REST-identity: "name=hans Ernst Lassen; =hans.ernst.lassen@devoteam.com; phone= ; token=1087ebd8-aabf-45da-a871-4b08ab0d2853" Konkret overholdelse af standarder Internationale standarder HTTP 1.1 ( XML version 1.0 ( XML Schema 1.0 ( XML Signature (XML-DSIG) ( Tegnsæt Data der udveksles mellem Tilbudsportalen og eksterne systemer skal overholde UTF-8 tegnsæt-encoding Namespaces Ved udarbejdelsen af xml-filer er følgende namespace respekteret: Kaldeeffekt-kategorier Webservice operationer er kendetegnet ved, at de hver især tilhører én af følgende kategorier med hensyn til hvilken effekt kald af dem har Ufarlig operation En operation, som er kendetegnet ved, at den ikke ændrer på betydende dele af TP-systemets tilstand eller data. Alternativt at det af anden grund er uden betydning, om den aktiveres flere gange Idempotent operation En operation, som er kendetegnet ved, at det ikke gør nogen forskel om den aktiveres én eller flere gange, med de samme parametre - resulterende sideeffekter i TP-systemet, samt resultatværdier vil være de samme hver gang. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 18

19 Dubletafvisende operation En operation, der er kendetegnet ved, at den afviser at udføre den tiltænkte funktion, hvis den aktiveres med parameter-værdier, som er eksakt de samme, som den tidligere er blevet aktiveret med. En konsekvens heraf er, at kalderen uden risiko vil kunne gentage aktiveringen af operationen - med givne parameter-værdier - i fald der skulle være tvivl om, hvorvidt en eller flere tidligere aktiveringer er gennemført Sporbar operation En operation, som er kendetegnet ved, at den efterlader et veldefineret spor (fx i form af en specifik sideeffekt) i TP-systemet, respektive aktør-systemet, som det efterfølgende er muligt at verificere er til stede - fx ved forespørgsel via en anden operation Risikabel operation En operation, som er kendetegnet ved, at den ændrer på betydende dele af TP-systemets tilstand eller data, og at den hverken er idempotent, dubletafvisende eller sporbar. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 19

20 2.3 Tilbudsportalen Tilbud Forretningsmæssigt overblik Beskrivelse af services og ressourcer i dette afsnit relaterer sig primært til tilbudsdata. Eksempelvis services der giver mulighed for at indberette blanketter vedrørende tilbud, samt services der bidrager til simpel søgning efter blanketter og tilbudsdata. Servicen understøtter operationer til at læse, skrive og opdatere tilbudsdata Strukturen af data til et tilbud Figur 5: Struktur fra Tilbudsportalen illustrerer den overordnede, generiske struktur for tilbudsdata. Figur 5: Struktur fra Tilbudsportalen Elementerne der indgår i Figur 5: Struktur fra Tilbudsportalen er forklaret i de følgende afsnit. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 20

21 2.3.3 Organisation Generelt opfattes entiteten Organisation som et Tilbud. Organisationen kan have en relation til andre organisationer. Når dette er tilfældet er det et udtryk for et hierarki eks: Figur 6: Hierarki for organisation (tilbud) Figur 6: Hierarki for organisation (tilbud) viser hvordan hierarkiet kan se ud med Socialstyrelsen som organisation i øverste niveau. Niveau 2 indeholder tilsynsmyndighederne og niveau 3 er selve tilbuddene. Hver tilsynsmyndighed fører tilsyn med et tilbud. Fordeling af tilbud pr. tilsynsmyndighed sker efter postnummer på hovedafdelingen på tilbuddet. Bemærk at en tilsynsmyndighed ikke må føre tilsyn med egen kommunes tilbud/fam It-bruger Stamdata for brugere af Tilbudsportalens indberetning Personale Stamdata for personale på et tilbud. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 21

22 2.3.6 Målgruppepakke Sammensatte målgrupper et tilbud understøtter eks. psykisk funktionsnedsættelse, kommunikationsnedsættelse, alkoholmisbrug eller hørenedsættelse, sindslidelse, krigsveteran etc Indsats Stamdata for indsatsområder et tilbud kan tilbyde. eks. støtte til kontakt og samvær, støtte til uddannelse og beskæftigelse etc IndsatsTakst Stamdata for indsatstakster. En indsatstakst indeholder en eller flere ydelsestakster YdelsesTakst Stamdata for en ydelsestakst herunder navn og pris for ydelsen FagligTilgang Stamdata for hvilke faglige tilgange et tilbud har til en bestemt indsats Metode Stamdata for faglige tilgange et tilbud baserer socialfaglige indsatser på Stamoplysninger Stamoplysninger om tilbudet. Eks. juridisk grundlag, ejerform, driftsherre etc Barn Et tilbud kan også være en plejefamilie. I det tilfælde vil der være knyttet et eller flere børn til tilbuddet via stamoplysningerne BrugerBetalingType Stamdata for en type brugerbetaling. Eks navn og beskrivelse BrugerBetalingPris BrugerBetaling Stamdata for pris når en borger benytter et tilbud Pladser Stamdata for pladser på et tilbud. Eks. pladstype, total antal pladser og ledige pladser Medarbejder Stamdata på en medarbejder på et tilbud Adresse Stamdata for en adresse på et tilbud. Et tilbud kan have flere adresser tilknyttet Tilsynsblanket Indeholder informationer om tilsyn hos et tilbud Paabud Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 22

23 2.4 Audit - Indberetning Forretningsmæssigt overblik Services og ressourcer i denne gruppe relaterer sig udelukkende til indberetning af auditdata. Servicen indeholder operationer til at læse, skrive og opdatere der muliggør at aktører indberetter audit data til TP. Bemærk at Auditdata udstilles IKKE på Tilbudsportalen Find Tilbud men kun er tilgængelig Audit-gruppen i Socialstyrelsen Begrebsmodel til Audit Figur 7 Begrebsmodel til Audit data Tilsynsdata består af 2 grupper data - kvalitetsmodel og procesinformation Kvalitetsmodel Kvalitetsmodellen består at en række temaer. Hvert tema består et eller flere kriterier. Hvert kriterium består af en eller flere indikatorer. Tema Kriterium Indikator Uddannelse og beskæftigelse. Tilbuddet støtter borgerne i at udnytte deres fulde potentiale i forhold til uddannelse beskæftigelse. Tilbuddet opstiller i samarbejde med borgerne konkrete mål for borgernes skolegang, uddannelse eller beskæftigelse. Figur 8 - Eksempel på et tema fra kvalitetsmodellen Den fuldstændige kvalitetsmodel og varianter af denne kan findes her: Tilbud: Plejefamilier: Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 23

24 2.4.4 Procesinformation Indeholder stamdata for selve sagsbehandlingen af tilsynet eks relevante skæringsdatoer og baggrund for tilsyn Tilsyn Indeholder stamdata for dato for påbegyndt tilsyn, er tilsynet anmeldt, og om der er foretaget fysiske besøg på afdelingerne Foranledning Indeholder stamdata for hvilken foranledning der har været til tilsynet samt data for foranledningstypen. En foranledning kan indeholde en referense til et andet tilsyn der er førte til et påbud. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 24

25 3 REST Services - Tilbudsportalen Dette afsnit indeholder informationer til den operationelle del af TP-REST-services herunder adgang til REST-services samt overordnet beskrivelse af ressourcer i TP-REST-services. Test - Socialstyrelsen URI REST-beskrivelse Login Metadata Info Basic Authentication Preprod - Socialstyrelsen URI REST-beskrivelse Login Metadata Info preprod /rest/ Basic Authentication Produktionsmiljø - Socialstyrelsen Info URI REST-beskrivelse Login Metadata Basic Authentication Ressourcer Ressource Beskrivelse Revision /bruger Stamoplysninger for en bruger indberetningen 1, 2 og dennes relationer til roller og organisation(tilbud) /organisation Stamoplysninger for et Organisation eller Tilbud 1, 2 /rolle Roller til brugere af indberetningen 1, 2 /adresse_r2 Adresseoplysninger på et tilbud 2 /barn_r2 Et tilbud kan også være en plejefamilie. I det 2 Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 25

26 tilfælde vil der være knyttet eller flere børn til tilbuddet via stamoplysningerne. /brugerbetaling_r2 Stamdata for pris når en borger benytter et 2 tilbud. /brugerbetalingdetalje_r2 Stamdata for pris når en borger benytter et 2 tilbud. /brugerbetalingtype_r2 Stamdata for en type brugerbetaling. Eks navn 2 og beskrivelse. /fagligtilgang_r2 Stamdata for hvilke faglige tilgange et tilbud har 2 til en bestemt indsats. /indsats_r2 Indsatspakker 2 /indsatstakst_r2 Pris for indsatspakke 2 /maalgruppepakke_r2 Sammensatte målgruppepakker 2 /medarbejder_r2 Sammensatte målgrupper et tilbud understøtter 2 eks. Personlighedsforstyrrelse og Hjemløshed /metode_r2 Stamdata for faglige tilgange et tilbud baserer 2 socialfaglige indsatser på. /paabud_r2 2 /personale_r2 Stamdata for personale på et tilbud. 2 /pladser_r2 Stamdata for pladser på et tilbud. Eks pladstype, 2 total antal pladser og ledige pladser /stamoplysninger_r2 Stamoplysninger om tilbudet. Eks. juridisk 2 grundlag, ejerform, driftsherre etc. /tilsynsblanket_r2 Indeholder informationer om tilsyn hos et 2 tilbud. /ydelsetakst_r2 Stamdata for en ydelsestakst herunder navn og 2 pris for ydelsen. /kvalitetsmodel_a Stamdata for kvalitetsmodellen Audit /tilsyn_a Stamdata for tilsyn Audit /foranledning_a Stamdata for foranledning til tilsyn Audit I forbindelse med Tilsynsreformens ikrafttrædelse 1. jan 2014 sker der en migrering af data på Tilbudsportalen fra revision 1 af modellen til revision Metadata.xml Metadata.xml Indeholder en beskrivelse af alle entiteter, relationer mellem entiteter, attributter på entiteter og aktiveringsregler(validerings- og visningsregler). Metadata.xml afspejler modellen for Tilbudsportalens indberetning se afsnit og Audits indberetning se afsnit Entity/view.xml For hver entitet er der en view.xml der indeholder en blanketdefinition dvs. en komplet struktur over hvordan hjælpetekster, felter og sektioner er orkestreret. Dette bruges dels til genering af Tilbudsportalens indberetningsblanketter men også som skabelon til hvilke felter der skal post når der eksempelvis oprettes et nyt tilbud via REST-snitfladerne. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 26

27 3.4 Overblik Nedenstående indeholder et overblik over hvordan Tilbudsportalens indberetning fungerer. Indberetning Ud fra Metadata.xml og entity/view.xml genererer SIV-motoren blanketter til webbrugergrænsefladen samt REST-snitfladerne. Dette betyder at når der tilføjes/fjernes et felt i metadata.xml/entity/view.xml slår det igennem i webbrugergrænsefladen og REST-snitfladerne. 3.5 Unik identifikation Alle entiteter på Tilbudsportalen kan identificeres med unik nøgle. Nøglen der benyttes er ISO-standarden UUID ( Universal Unique Identifier). Alt computerudstyr, der er i stand til at kommunikere med andet hardware, har en unik hardwareadresse. En UUID skabes ved en kombination af denne hardwareadresse, det aktuelle klokkeslæt og tilfældighedsprincipper. UUID kan genereres automatisk af computeren. Det betyder, at der ikke skal være en central administrativ enhed, som skal tildele identifikatoren i modsætning til eksempelvis et CPR-nummer, som tildeles via CPR-registret. Alle pc er kan generere UUID er. Desuden findes der UUID-generatorer på internettet. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 27

28 Et eksempel på en UUID kan se således ud: 752C368D-9ED1-397B-57233AAB71E56A2B. Ved oprettelse af en entitet skal UUID tildeles af aktør serveren. Forsøg på oprettelse af en entitet med et UUID der allerede findes på TP vil bliver afvist med en fejlbesked at entiteten allerede eksisterer. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 28

29 Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 29

30 4 Use Cases I dette afsnit beskrives use cases der kan gennemføres ved brug af Tilbudsportalens REST-services. Hver use case er efterfulgt af en specifikation for den/de services der kan benyttes for at udføre use casen Use case: henttilbudsdetaljer En bruger af et eksternt system ønsker at se detaljer for et tilbud fra Tilbudsportalen. System henter oplysninger om alle tilbuddene eller det valgte tilbud. Figur 9: sekvensdiagram for henttilbud Figur 10: sekvensdiagram for henttilbudsdetaljer Use case: oprettilbud En bruger af et eksternt aktør system ønsker at oprette et nyt tilbud i Tilbudsportalen. Systemet opretter et nyt tilbud via Tilbudsportalen REST-services. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 30

31 Figur 11: sekvensdiagram for opretnyttilbud Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 31

32 REST service organisation Beskrivelse Servicen indeholder mulighed for at: Hente en liste over alle tilgængelige Tilbud Hente stamdata for et enkelt Tilbud Oprettelse af et nyt Tilbud Roller Responsible: Socialstyrelsen IT-drift Accountable: Tilbudsportalen Consulted: Informed: Tilsynssystem Eksterne leverandører Operation GET organisation/ Beskrivelse Returnerer en liste over alle tilgængelige Tilbud. Det er kun et begrænset attributter der vises pr. Tilbud Uri /organisation Input Output http-status: 200 XML med en liste indeholdende alle tilbuddene Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Sikkerhed Interaktionsmønster Kaldeeffekt Forespørgsel-svar Ufarlig operation Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 32

33 Operation GET organisation/{uuid} Beskrivelse Returnerer stamdata for et enkelt Tilbud. Stamdata består af attributter indeholdende tekstuel beskrivelse af tilbuddet. Endvidere indeholder stamdata også tilbuddets relationer til andre entiteter i Tilbudsportalens objektmodel. Uri Input /organisation/{uuid} UUID eks: 9b300db8-8efd-4acd-8f36-00b4927ae617 Output http-status: 200 XML med Stamdata for det valgte tilbud Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Sikkerhed Interaktionsmønster Kaldeeffekt Forespørgsel-svar Ufarlig operation Operation POST organisation Beskrivelse Uri Input Opretter en ny tilbuds-entitet /organisation/{uuid} Myndighed UUID Tilbud UUID Tilbuddets navn Tilbudstype Juridisk grundlag State: create Output http-status: 200 XML: <messages xmlns=" <status>ok</status> <message type="info">set attribute: [attribut]</message> Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 33

34 <operation type="create"> <entities> <entity uuid="63f35d30-2cf5-11e3-a65c c00021" handle="organisation" href=" state="partial"/> </entities> </operation> </messages> Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found 415 Unsupported media type Sikkerhed Kaldeeffekt Forespørgsel-svar Dubletafvisende operation(uuid), Sporbar operation XML- eksempel på POST Interaktionsmønster <entities xmlns=" <entity handle="organisation" uuid="63f35d30-2cf5-11e3-a65c c00021" state="create"> <attribute handle="navn"> <value>tilbudet Det evige eksempel</value> </attribute> <relation handle="organisation.hierarki" role="underorganisation" href=" 4d25-83e6-63eca7fbd565/overorganisation" state="full"><entity uuid="79012ac1-4a77-450d- 9b42-a6b00ed48dc9" handle="organisation" role="overorganisation" href=" state="partial"><attribute handle="navn"><value>socialstyrelsen</value></attribute></entity></relation> </entity> </entities> Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 34

35 4.2 Tilsynsblanket Use case: indberettilsynsblanket En bruger af et eksternt system har gennemført et tilsyn på et tilbud. Brugeren ønsker at overføre tilsynsblanketten til Tilbudsportalen. Når tilsynsblanketten er overført til Tilbudsportalen skal brugeren logge ind på Tilbudsportalen og verificere samt godkende informationerne for tilbuddet. Når brugeren har godkendt information bliver tilsynsblanketten tilgængelig på Tilbudsportalen Find Tilbud. Brugeren skal indberette en tilsynblanket pr. tilsyn inden data kan verificeres og godkendes på Tilbudsportalen. Figur 12: sekvensdiagram for indberetning af tilsynsblanket. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 35

36 Web service tilsynsblanket_r2 Beskrivelse Når der er foretaget et tilsyn hos et Tilbud skal informationerne fra tilsynet overføres fra et eksternt system til Tilbudsportalen. Oplysningerne fra tilsynet er ikke synlig på Tilbudsportalen Find Tilbud før alle informationerne er verificeret på Tilbudsportalen og der trykkes godkend. Roller Responsible: Socialstyrelsen IT-drift Accountable: Tilbudsportalen Consulted: Informed: Tilsynssystem Eksterne leverandører Operation POST tilsynsblanket_r2/ Beskrivelse Uri Input Efter endt tilsyn indberettes tilsynsblanketten på det pågældende tilbud. /tilsynsblanket_r2 Tilsynstype (godkendelse af nyt tilbud, godkendelse af eksisterende tilbud) Afgørelse (godkendt, godkendt med vilkår, ikke godkendt) Dato for godkendelse Godkendt med vilkår Indhold i vilkår Dato - frist for opfyldelse af vilkår Ikke godkendt Begrundelse Driftsorienteret tilsyn Status (Fortsat godkendt,fortsat godkendt med påbud, Fortsat godkendt med skærpet tilsyn,ikke godkendt) Dato for seneste anmeldte tilsynsbesøg Dato for seneste uanmeldte tilsynsbesøg Dato for seneste administrative tilsyn Dato for seneste ændring i status for godkendelsen Fortsat godkendelse med påbud og fortsat godkendelse med skærpet tilsyn Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 36

37 Påbuddets indhold Frist for opfyldelse af påbuddet Fortsat godkendelse med skærpet tilsyn Begrundelsen for det skærpede tilsyn Udløbsdato for skærpet tilsyn Ikke godkendt Begrundelse for afgørelse om ophør af godkendelse Dato for ophør Konklusionen for tilsynet på det samlede tilbud Konklusionen Udannelse og beskæftigelse Konklusionen Selvstændighed og sociale relationer Konklusionen Målgruppe, metoder og resultater Konklusionen Organisation og ledelse Konklusionen Kompetencer Konklusionen Økonomi Konklusionen Fysiske rammer State: create Se afsnit 8 Entiteter og attributter for komplet liste af attributter. Output HTTP-status: 200 XML: <messages xmlns=" <status>ok</status> <message type="info">set attribute: [attribut]</message> <operation type="create"> <entities> <entity uuid="63f35d30-2cf5-11e3-a65c c00021" handle="organisation" href=" state="partial"/> </entities> </operation> </messages> Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 37

38 415 Unsupported media type Sikkerhed Kaldeeffekt Forespørgsel-svar Dubletafvisende operation(uuid), Sporbar operation Operation GET tilsynsblanket_r2/ Beskrivelse Uri Returnerer en liste over alle tilgængelige tilsynsblanketter. /tilsynsblanket_r2 Input Output http-status: 200 XML: Liste over alle indsendte tilsynsblanketter Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Sikkerhed Interaktionsmønster Interaktionsmønster Kaldeeffekt Forespørgsel-svar Ufarlig operation Operation GET tilsynsblanket_r2/{uuid} Beskrivelse Returnerer stamdata for en enkelt tilsynsblanket. Stamdata består af attributter indeholdende tekstuel beskrivelse af tilsynsblanketten. Endvidere indeholder stamdata også tilsynsblankettens relationer til andre entiteter i Tilbudsportalens objektmodel. Uri Input /tilsynsblanket_r2/{uuid} UUID Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 38

39 Output http-status: 200 XML: information vedr. den ønskede tilsynsblanket. Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Sikkerhed Interaktionsmønster Kaldeeffekt Forespørgsel-svar Ufarlig operation Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 39

40 4.3 Audit data Use case: indberetauditdata En bruger af Tilsynssystemet har gennemført et tilsyn på et tilbud. Brugeren ønsker at overføre auditdata vedr. tilsynet på et tilbud til Tilbudsportalen.Brugeren kan indsende audit data én gang og opdatere data mange gange pr. tilsyn. Bemærk at auditdata efterfølgende ikke er tilgængelig på Tilbudsportalen Find Tilbud. Figur 13: sekvensdiagram for indberetning af auditdata. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 40

41 REST service - auditdata Beskrivelse Når der er foretaget et tilsyn hos et Tilbud skal auditdata(kvalitetsmodel og procesinformation) fra tilsynet overføres til Tilbudsportalen. Auditdata fra tilsynet er IKKE synlig på Tilbudsportalen Find tilbud. Roller Responsible: Socialstyrelsen IT-drift Accountable: Tilbudsportalen Consulted: Tilsynssystem, Socialstyrelsen Databank, Socialstyrelsen - Audit Informed: Operation POST auditdata_r2/ Beskrivelse Uri /kvalitetsmodel_a /tilsyn_a /foranledning_a Input Kvalitetsmodel Processinformation State: create Se afsnit 8 Entiteter og attributter for komplet liste af attributter. Output http-status: 200 XML: <messages xmlns=" <status>ok</status> <message type="info">xyz xyz</message> </messages> Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 41

42 415 Unsupported media type Sikkerhed Interaktionsmønster Kaldeeffekt Forespørgsel-svar Idempotent operation Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 42

43 4.4 Filer Use case: henttilbudsfil En bruger af Tilsynssystemet ønsker at hente stamdata på et Tilbud fra Tilbudsportalen herunder uploadede filer. Figur 14: sekvensdiagram til hent fil der er uploadet som supplement til stamdata for et tilbud. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 43

44 REST service stamdata Beskrivelse Hvert Tilbud har stamdata tilknyttet. Stamoplysninger er tekstuel beskrivelse af tilbuddet. I indberetningen er det muligt at uploade en fil med supplerende informationer der efterfølgende er tilgængelig som binært data på stamdata. Roller Responsible: Socialstyrelsen IT-drift Accountable: Tilbudsportalen Consulted: Tilsynssystem Informed: Operation GET stamoplysninger/{uuid} Beskrivelse Uri Input Returnerer stamdata for et tilbud. Tekstuelle beskrivelser og evt. referencer til uploadede filer. / stamoplysninger UUID Output http-status: 200 XML en eller flere attribut elementer indeholdende en URI til en uploadet fil. Eks: <attachment name="tilsynsrapport Køge Lænke-ambulatorium - marts 2010.pdf" uuid="d55aabab-dde6-4c1d-8278-e88dc3ce8c5c" size="96786" contenttype="application/pdf" href=" admin/rest/v1/stamoplysninger/1f38db5c a75- b060a1cfd670/s1155/d55aabab-dde6-4c1d-8278-e88dc3ce8c5c"/> Fejlhåndtering 400 Bad request 401 Unauthorized 404 Not found Sikkerhed Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 44

45 Interaktionsmønster Kaldeeffekt Operation GET stamoplysninger/{uuid}/{bilagstype}/{bilag-uuid} Beskrivelse Uri Input Returnerer stamdata for et tilbud. Tekstuelle beskrivelser og evt. referencer til uploadede filer. stamoplysninger/{uuid}/{bilagstype}/{bilag-uuid} UUID på stamdata Bilagstype: s31 s63 s115 s140 s142 s5533 s1491 s15104 s15105 s15106 s15107 s15109 s1155 Samarbejdsrelationer Vedtægter for bestyrelsen Revisionspåtegning Effektevaluering Brugerevaluering Samarbejdsrelationer Plantegning Procesevaluering Effektevaluering Brugerevalueringer Tilsynsrapport Revisionspåtegning Øvrig dokumentation UUID på bilag Output http-status: 200 Binært data Fejlhåndtering 400 Bad request 401 Unauthorized 500 Internal Server Error <messages xmlns=" <status>error</status> <message type="error">failed to load binary attachment</message></messages> Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 45

46 Sikkerhed Interaktionsmønster Kaldeeffekt Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 46

47 5 Sikkerhed 5.1 Definitioner Autentifikation: brugervalidering og dækker over processen med at logge brugeren ind eller indsamle den information, der skal til for at identificere brugeren entydigt. Autorisation: brugerens rettigheder - hvem har lov til hvad. 5.2 System-til-System autentifikation med Basic Authentication og SSL Kommunikation mellem en Aktør og TP foregår i et trust mellem serverne hos Aktøren og TP. TP autentificeres ved hjælp af et server-side certifikat, som beskrevet ovenfor. Eksterne aktørers servere autentificeres overfor TP ved hjælp af username / password med Basic Authentication. Alle forespørgsler skal derfor have et http header felt på følgende form, hvor brugernavn og adgangskode er base64 encoded: Authorization: Base64Encode(username:password) Ydermere skal der sendes info om den bruger der tilgår data. TP er forpligtiget til at logge al aktivitet i tilbudsdata og henføre denne aktivitet til én specifik bruger. Eksterne aktører skal derfor knytte et unikt brugerid, en adresse samt et brugernavn på den aktive bruger i system det kaldende system. Disse data sendes i http headeren på følgende form: X-SIV-REST-identity: "name=fulde Navn; = Adresse; phone=telefon Nummer; token=uuid Fra Aktør System" 5.3 Single-signon En it-bruger i systemet har et antal organisationstilknytninger (mindst een) og it-brugeren benyttes til at autorisere operationer (ved hjælp af de roller og organisationstilknytninger den har). IT-BRUGER <-> ORGANISATION 1. FInd UID på den ORGANISATION man vil logge brugeren ind med som default (opslag på PNR eller MYNDIGHEDSKODE). 2. Find UID på den BRUGER man vil logge ind som 3. Kald nedenstående ticket service. 4. redirect brugeren til ticket-service URL'en. Eksempel: ORGANISATION=Fåborg-Midtfyn/Tilsynskommune: b78946e d25-83e6-63eca7fbd565 BRUGER=Tilsynssystem/Administrator: 78069e83-b9a6-43c5-8c1a-3a c8 Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 47

48 som returnerer: <status result="ok" expire=" t13:45:45+02:00" href=" <message> created ticket for 78069e83-b9a6-43c5-8c1a-3a c8, organisation=b78946e d25-83e6-63eca7fbd565 </message> </status> Man sender herefter en redirect attributten. En ticket udløber efter 1 minut. Man kan angive Organisations UUID'ere som it-brugeren er direkte tilknyttet og Underorganisationer til disse X-REST-identity header Det er muligt at FLERE eksterne brugere benytter det samme it-bruger objekt på serveren, understøtter Tilbudsportalen en mekanisme, så kan man i kaldet til ticket servicen (urlen.../ticket) angiver yderligere oplysninger om den specifikke bruger ved at sætte følgende special-header: X-REST-identity: "name=hans Ernst Lassen; =hans.ernst.lassen@devoteam.com; phone= ; token=1087ebd8-aabf-45da-a871-4b08ab023453" Informationerne bliver så bundet til ticket'en som en ekstraoplysning der kan tilgår når der redirigeres til selve ticket urlen (fra <status/> resultat xml'en). Navn, og token er mandatory phone er optionelt. Man kan tilføje ekstra felter efter behov (de gemmes som key/value i SIV'en til senere fremsøgning). token skal indeholde en oplysning som gør at man kan genfinde brugeren i det kaldende system (f.eks. et brugerid eller lignende). Hvis der bliver behov for at spore tilbage til hvilken bruger der faktisk har udført en operation er det token vi bruger som nøgle. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 48

49 6 Fejlhåndtering Med begrebet fejlhåndtering menes systemmæssig fejlhåndtering i form af fejlrapportering fra TP til aktørerne og aktørerne til TP. Den driftsmæssige og dermed manuelle aktioner ved håndtering af fejlsituationer er ikke indeholdt i dette dokument Overordnet om fejlsituationer Registrering af information om opståede fejlsituationer Alle eksterne aktører der benytter TP-snitfladerne skal registrere information om de fejlsituationer der måtte opstå. Informationen skal registreres af hensyn til den kortsigtede udredning og udbedring af konkret opståede fejlsituationer, såvel som af hensyn til den eventuelle langsigtede korrektion af de forhold, som får den konkrete type af fejlsituationer til at opstå. Af hensyn til effektiv udredning skal alle parter registrere information, som så vidt muligt indeholder tværgående korrelationsinformation Udveksling af information om fejlsituationer Alle parters it-systemer skal indrettes til, at udveksling af information om fejlsituationer, skal foregå efter de fælles aftalte retningslinjer Kommunikationsscenarier I Tilbudsportalens snitflader understøtter kun synkron kommunikation. Når der opstår en fejl i TP i forbindelse med synkron system-system kald, dannes en HTTP Error besked som resultat til det kaldende system Fejlhåndtering ved synkron kommunikation Opstår der en fejl ved modtagelse eller behandling af forsendelse som kræver et synkront svar, skal fejlen rapporteres af den synkrone svar-kanal. Der benyttes HTTP fejlrapporteringsmodel. Dette er vist på nedenstående figur, hvor en aktør kalder TP og modtager en HTTP Error. Aktør TP WS-operation Figur 15: fejlrapporteringmodel Konkrete fejlsituationer Dette afsnit indeholder en uddybning af den beskrivelse af fejlmuligheder, der er ved modtagelse af anmeldelser i TP. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 49

50 6.1.5 Konkrete fejlbeskeder Generelle fejlbeskeder på tværs af services http status Fejltekst Bemærkning 400 Bad request Indeholder en XML-blok: <messages xmlns =" <status>error</status> <message type="error">error msg</message> </messages> 401 Unauthorized Indeholder en XML-blok: <data contenttype="application/xml; charset=utf-8" contentlength="39"><![cdata[authentication credentials are required]]></data> 404 Not found Indeholder en XML-blok: <messages xmlns =" <status>error</status> <message type="error">error msg</message> </messages> 415 Unsupported media type Indeholder en HTML-blok returneres fejlbesked. Eks.: 415 Unsupported Media Type ved POST af ukendt media type Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 50

51 Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 51

52 7 FAQ 7.1 Spørgsmål: Stamoplysninger vs stamoplysninger_r2 Entiteten organisation har en relation til entiteten stamoplysninger og en relation til entiteten stamoplysning_r2. Det lader til at hver organisation har enten en stamoplysninger eller en stamoplysning_r2. Jeg vil gerne vide hvad forskellen er på de to. Hvorfor bruges de begge? Når jeg spørger om forskellen, så mener jeg ikke bare forskellen i hvilke metadata der ligger på den. Det kan jeg slå op i metadata-servicen. Det jeg gerne vil vide er meningen med entiteterne. Hvornår bruges stamoplysninger og hvornår bruges stamoplysning_r2? Svar: Med undtagelse af entiteten "Organisation", så skal du arbejde med entiteter der hedder noget med _r2. I relation til tilsynsreformen ændrer vi datamodellen og i den sammenhæng går vi fra f.eks. stamoplysninger til stamoplysninger_r Spørgsmål: Målgruppekategorier I dokumentationen ses en liste af målgruppekategorier ( demens, hjerneskade, udviklingshæmning mm.). Denne liste er rent visuelt sat op så den ligner en træstruktur fx antydes det at hjerneskade har underkategorierne erhvervet hjerneskade og medfødt hjerneskade. Men når jeg kigger i metadataene for feltet maalgruppe på entiteten maalgruppepakke_r2 kan jeg ikke se nogen træstruktur, kun en flad liste af kategorier. Er den træstruktur som dokumentationen antyder faktisk noget som findes i datamodellen og kan trækkes ud? Og i så fald hvordan? Svar: Målgruppepakker kan findes via to relationer, hhv. på Organisation og på Indsats_r2. De målgrupperpakker der findes på Organisation er bruttolisten af mulgruppepakker der vedrører en Organisation f.eks.: De målgruppepakker der er knyttet til en indsats er en delmængde af de målgruppepakker der er knyttet til Organisation. De enkelte målgrupper kan findes på målgruppepakken under: <attribute handle ="maalgruppe" > <!--personfarlig kriminalitet--> <category handle ="88" /> <!--alkoholmisbrug--> <category handle ="91" /> </attribute > Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 52

53 7.3 Spørgsmål: Indberetter på et tilbud I dokumentationen kan jeg se en sektion med overskriften Skriv navn og mailadresse på den person, der skal indberette for tilbuddet og med fire felter (Fornavn, Mellemnavn, Efternavn, Mailadresse). Disse felter kan jeg ikke finde i metadataene. Svar: Tilbudsportalen gemmer ikke oplysninger om, hvem der har indsendt indberetningsblanketten.. De felter der nævner gemmes i "IT bruger" entiteten. Men som sagt vil du ikke kunne finde den aktuelle indberetter for et tilbud. Du kan kun se potentielle indberettere for et tilbud. 7.4 Spørgsmål: Sygefravær på tilbuddet Vi vil gerne finde et felt Sygefravær på tilbud. I dokumentationen kan man se et felt med titlen Hvad er sygefraværet på tilbuddet. Dette felt kan jeg ikke finde i metadataene? Svar: Dette felt har handle s126 i metadata.xml. 7.5 Spørgsmål: Recursive = 1 Hvis man prøver at kalde Tilbudsportal-webservicen og hente organisation en for Socialstyrelsen (ID: 79012ac1-4a77-450d-9b42-a6b00ed48dc9) med recursive=1, så går webservicen ned. De næste par minutter er webservicen utilgængelig og kaster HTTP 503, antageligt fordi den er overbelastet. Det sker også selv om man prøver at afbryde mit webservicekald. Det er forståeligt hvis webservicen nægter at returnere alle organisationer og deres relationer i ét kald (hvilket er hvad jeg prøver på), men det er ret uheldigt at webservicen går ned når man prøver. Svar: Man må IKKE trække data ud fra rod-organisationen. Test serverne og applikationen er ikke gearet til dette. I skal hente fra et lavere niveau (f.eks. et tilsyn eller et tilbud) med recursive. Socialstyrelsen Tilbudsportalen Servicespecifikation Version 1.0 Side 53