| Innehållsförteckning |
|---|
Användningsfall
Tjänsten uppfyller följande användningsfall för att möta de arkitekturella kraven i referens [1Arkitekturella krav]:
...
...
Tjänstekonsument anropar aggregerande tjänst
Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram. Som belysande exempel i texten används tjänstekontraktet för att hämta tidbokningar, GetSubjectOfCareSchedule, samt den nationella tjänsteplattformen, NTjP, som SKLTP instans.
Då en tjänstekonsument anropar den aggregerande tjänsten för tidbokningar så söker den först i cachen på angivet patientId och returnerar informationen från cachen om sådan finns. Annars anropar tjänsten engagemangsindexet för att få redan reda på var nuvarande bokningar för angivet patientId finns, dvs hos vilka mottagningar. Därefter anropas respektive källsystem parallellt (för att minimera svarstiden) och ett aggregerat svars sätts samman. Det aggregerade svaret sparas i cachen samt returneras till tjänstekonsumenten. Cachen uppdateras också i de fall anrop misslyckats med relevant fel-information.
Respons SOAP headern "ProcessingStatus"
Teknisk information om bearbetningen sammanställs i svaret tillbaka till tjänstekonsumenten i en SOAP header med namnet "ProcessingStatus".
SOAP SOAP headern "ProcessingStatus" innehåller en lista med en rad per anropat källsystem och ger per källsystem information huruvida anropet gick bra , svaret kom dirket från cache, hur gammal den cachade informationen äreller om ett fel uppstod i anropet. Se interoperability_headers_1.01.xsd för för detaljer.
Notera att SOAP headern "ProcessingStatus" inte beskrivs i de tjänsteinteraktioner (WSDL-filer) som en aggregerande tjänst följer, detta för att kunna använda samma tjänsteinteraktioner som de underliggande tjänsteproducenterna använder. Det innebär att SOAP headern "ProcessingStatus" behöver beskrivas vid sidan av tjänsteinteraktionerna, förslagsvis som ett appendix till gällande RIV-TA version.
Not: I sekvensdiagrammet nedan är NTjP's Virtualiseringplattform bortabstraherad i syfte att öka diagrammets läsbarhet men den används i samtliga externa samband, dvs i anrop mellan den aggregerande tjänsten och konsumenter, engagemangsindex och källsystem. 
Engagemangsindex notifierar aggregerande tjänst
...
Automatisk rensning av cache
...
Manuell rensning av cache
Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.
Vid behov kan en administratör manuellt rensa hela eller delar av cachen. Partiell rensning kan göras för ett patientId eller en vårdmottagnings logicalAddress.
Hantering av flera huvudversion av ett tjänstekontrakt
För att möta kravet "#9: Hantering av två (eller fler) huvudversioner av ett tjänstekontrakt" i de arkitekturella kraven på aggregeringsplattformen så finns det en integration mot TAK som används i de fall aggregeringsplattformen behöver stödja olika huvudversioner av samma tjänstekontrakt.
Detta görs genom en integration med TAK som håller vilken version av tjänstkontraktet en viss logisk-address exponerar.
Aggregeringsplattformen håller denna information i lokal cache som även persisteras på disk för att minska risken för störningar ifall TAK applikationen är nere.
Den lokala cachen ska uppdateras vid omstart av aggregeringsplattformen samt på kommando via ett rest anrop som kan utföras av exempelvis servicedeskpersonal.