Användningsfall

Tjänsten uppfyller följande användningsfall för att möta de arkitekturella kraven i referens [1]:

1. Tjänstekonsument anropar aggregerande tjänst

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å anropar tjänsten engagemangsindexet för att få redan 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.

Respons SOAP headern "ProcessingStatus"

Teknisk information om bearbetningen sammanställs i svaret tillbaka till tjänstekonsumenten i en SOAP header med namnet "ProcessingStatus". SOAP headern "ProcessingStatus" innehåller en lista med en rad per anropat källsystem och ger per källsystem information huruvida anropet gick bra eller om ett fel uppstod i anropet. Se interoperability_headers_1.0.xsd 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.

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 vis logisk-address exponerar.
Informationen om vilken version av tjänstkontraktet som är aktuellt finns i befintlig konfiguration av aktuell aggregerande-tjänst. 

Sync with TAK success

1. setContext. 
   När mule context sätts i singleton-bönan TakCacheBean triggas metoden updateCache asynkront.
2. updateCache.
   TakCacheBean anropar TAK-tjänsten hamtaAllaVirtualliseringar och sorterar ut de virtualliseringar som exponerar rätt version av tjänstekontraktet.
3. populateCache
   Metoden poppulerar cachen med den logiskaaddressat som finns i det filterarde sättet med virutalliseringar.
4. writeTakLocalCache
   Skriver sättet med logiskaddresser till specifierad fil.

Sync with TAK fail

1. setContext
   När mule context sätts i singleton-bönan TakCacheBean triggas metoden updateCache asynkront
2. updateCache.
   TakCacheBean anropar TAK-tjänsten hamtaAllaVirtualiseringar men misslyckas.
3. loadTakLocalCache
   TakCacheBean laddar specifierad fil ifrån filsystemet.
4. populateCache
   TakCachen populeras med värden från uppläst fil.