Arkitekturella krav
Aggregerande tjänster delar en rad egenskaper:
Egenskap | Beskrivning |
1. En per tjänstedomän | Typfallet är att det finns en aggregerande tjänst per tjänstedomän och att den aggregande tjänstens payload är definierad av ett befintligt tjänstekontrakt i tjänstedomänen. Ett exempel kan vara tjänstedomänen för invånarens tidbokning. Den aggregerande tjänstens resultatmeddelande består av en lista av poster vars struktur definieras av tjänstekontraktet GetSubjectOfCareShedule. Det är också det tjänstekontrakt som den aggregerande tjänsten använder för att hämta data från källsystemen. |
2. Söker i Engagemangsindex | Aggregerande tjänster använder engagemangsindex för att veta vilka logiska adresser som håller data av aktuellt slag om patienten. När data om en patient/invånare efterfrågas och patienten inte finns i mellanlagret, konsulteras EI för information om vilka logiska adressater (vårdmottagningar) som håller information. |
3. Nationell omfattning | Aggregerande tjänster syftar till att sammanställa data från alla källsystemen i Sverige som stödjer tjänstedomänen (genom att ha tjänsteproducenter enligt domänens tjänstekontrakt). Att stödja en tjänstedomän som har en aggregerande tjänst omfattar oftast även krav på att uppdatera engagemangsindex. Det är sådana aggregerande tjänster som kravställs här, även om lösningen också ska kunna tillämpas regionalt (i en regional tjänsteplattform). |
4. Gemensamt tjänstekontrakt | Aggregerande tjänster stödjer samma tjänstekontrakt som en vanlig virtuell tjänst. Det gäller även tjänsteinteraktionen (WSDL:en). Skillnaden ur konsumentens perspektiv är hur man adresserar. Man adresserar med ineras eller regions HSA-id för att hitta nationell eller regional (för regionala konsumenter) aggregerande tjänst. För att “adressera sig förbi” aggregerande tjänst (dvs gå direkt mot en enskild tjänsteproducent) används som vanligt tjänstedomänens adresseringsvärde (ex. mottagningens HSA-id för tidbokningsdomänen). Dock finns en skillnad i payload för responsen: En aggregerande tjänst tillför en aggregeringsrapport i form av en header-struktur som redovisar utfallet av aggregeringen (metadata om aggregeringen). |
5. Patientidentitet är obligatorisk sökparameter | Aggregerande tjänster skall bara användas för att hämta information om en patient. |
6. Samtidig hämtning av data | Aggregerande tjänster hämtar data från flera logiska adresser (beroende av patientens engagemang). För att ge så bra svarstider som möjligt, måste logiska adressater anropas parallellt. |
7. Redovisning av data om anropet | Tjänstekontraktet redovisar anropsstatus för varje logisk adressat. Anropsstatus anger om data kunnat levereras eller inte. |
8. Behörighetskontroll | Den aggregerande tjänsten ingår i Tjänsteplattformen. Därför ska den inte ses som en tjänstekonsument med avseende på behörighetskontroll. När den aggregerande tjänsten anropar virtuella tjänster för att hämta data från källsystemen, är det därför HSA-id från den aggregerande tjänstens tjänstekonsument som den virtuella tjänsten ska använda vid behörighetskontroll mot tjänsteadresseringskatalogen. |
Förtydligande av vad krav #9 på behörighetskontroll leder till
När en aggregerande tjänst anropar Engagemangsindex tjänst findContent() för att få reda på var den eftersökta information finns så skall den göra det i rollen som en tjänsteplattformskomponent, dvs så att anropande konsument inte behöver etablera samverkan med Engagemangsindex. Detta illustreras av följande bild:
När sedan den aggregerande tjänsten anropar de tjänsteproducenter som enligt Engagemangsindex har eftersökt information så skall den göra det i rollen som anropande konsument:
Här är det dock viktigt att komma ihåg att VP bara gör behörighetskontroll på närmaste komponenten i en anropskedja (som den har "trust" till), se VP SAD - Arkitekturella krav - Ursprunglig avsändare.
Det innebär att om anropet till en aggregerande tjänst kommer in vi en annan tjänsteplattform så kan bara den aggregerande tjänsten uppfylla krav #9 ovan i betydelsen att den kan säkerställa att den angränsande tjänsteplattformen har behörighet att anropa de tjänsteproducenter som den aggregerande tjänsten slagit upp i Engagemangsindex. Den kan således inte verifiera huruvida den ursprunglige konsumenten har behörighet att anrop tjänsteproducenterna. I bilden nedan exemplifieras detta genom en aggregerande tjäsnt i NTjP som via en regional tjäsnteplattform (RTjP) får in ett anrop från en tjänstekonsument. Behörighetskontroll i NTjP för att få anropa underliggande tjänsteproducenter kommer att göras mot RTjP'n och inte den ursprunglige tjänstekonsumenten.
