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. Om anropet inte gick bra redovisas felorsak. Felorsaker anges som Timeout eller Serverfel (detaljer från felet rapporteras vid Serverfel).
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.
9. Hantering av två (eller fler) huvudversioner av ett tjänstekontrakt	När det finns flera versioner av kontrakt med aggregering uppstår ett “randfall” som det är viktigt att logiken i aggregerande tjänster kan hantera. Beskrivning av “randfall”: Det finns två (eller fler) huvudversioner av ett kontrakt i bruk Kontraktet har aggregering i tjänsteplattformen Det finns tjänsteproducenter som stödjer båda versionerna av kontraktet eftersom det finns tjänstekonsumenter som förlitar sig på gamla versionen samtidigt som det finns tjänstekonsumenter som förlitar sig på den nya versionen (eller på båda för att få med alla producenter oavsett version) Posterna i Engagemangsindex anger inte version (detta vill vi inte ändra på) av kontrakt Krav vid randfall enligt ovan: En tjänstekonsument som anropar en aggregerande tjänst ska INTE få fel-rapporter (i aggregeringsheadern) från de källsystem som bara har stöd för den andra versionen. En tjänstekonsument som anropar en aggregerande tjänst ska INTE orsaka att anrop förmedlas vidare till tjänsteproducenter som bara stödjer den andra versionen. Tankar kring lösning: Att Aggregerande tjänster - efter svar från EI - via TAK-info matchar källsystemet OCH kontraktsversion innan anrop sker, så att EI-poster som logiskt pekar ut producent som - enligt TAK - saknar stöd för den version som aggregerande tjänsten är.

Förtydligande av vad krav #8 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.

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 enligt krav #8.

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).

Det innebär att om anropet till en aggregerande tjänst kommer in via en annan tjänsteplattform så kan bara den aggregerande tjänsten uppfylla krav #8 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 ursprungliga konsumenten har behörighet att anrop tjänsteproducenterna.

Webbläsaren stöds inte