...
...
Innehåll
| Ankaretoc | h.13bcppp9in1x | h.13bcppp9in1x |
|---|
| Ankare | _GoBack | _GoBack |
Med exempel på aggregerande tjänst för tidbokning
|
Inledning
Aggregerande tjänster beskrivs i T-boken (REV B). Denna SAD syftar till att beskriva ett generellt realiseringsmönster för aggregerande tjänster, enligt T-bokens definition.
I nuvarande version är dokumentet inriktat mot realisering av en aggregerande tjänst för tidbokningar. Men detta dokument har också ett långsiktigt syfte att vara grund för en design av ett generellt mönster för aggregerande tjänster, dvs. när designen är prövad för tidbokning i verkligheten kan designen generaliseras till att vara allmängiltig för alla aggregerande tjänster i form av en aggregeringsplattform (SKLTP AGP) på ett liknande sätt som SKLTP idag stöttar framtagning av virtuella tjänster (se T-boken) med sin virtualiseringsplattform, (SKLTP VP). 
Figure 1, Översikt, informationssystemvy från T-boken (REV B)
Implementationsnära delar av detta designdokument är baserade på att Mule ESB CE (v3.3.0 eller senare) används samt att tjänsten driftsätts antingen i den nationella tjänsteplattformen (NTjP) eller i en regional tjänsteplattform (RTjP).
Innehåll
Inledning
Översikt
Arkitekturella krav
Systemsamverkan
Användningsfall
Tjänstekonsument anropar aggregerande tjänst
Engagemangsindex notifierar aggregerande tjänst
Automatisk rensning av cache
Manuell rensning av cache
Logisk vy
Implementations vy
Meddelandemappningar
Konsument anropar aggregerande tjänst
Mappning AggregatedGetSubjectOfCareSchedule-request till FindContent-request
Mappning FindContent-response till GetSubjectOfCareSchedule-request
Mappning GetSubjectOfCareSchedule-response till AggregatedGetSubjectOfCareSchedule-response
Engagemangsindex uppdaterar aggregerande tjänst
Rensning av cache
Test vy
Deployment vy
ReferenserAnkare
Översikt
Dokumentet är indelat i följande delar:
- Arkitekturella krav
Beskriver de arkitekturella egenskaper som är gemensamma för aggregerande tjänster. - Systemsamverkan
Ger en översiktlig bild av vilka system som samverkar samt dess primära roller i denna samverkan - Användningsfall
Beskriver de användningsfall som har störst påverkan på designen. - Logisk vy
Beskriver designens logiska uppdelning. - ImplementationsvyBeskriver centrala delar av implementationen.
- TestvyBeskriver integrationstester som behövs för att säkerställa den totala lösningens funktionalitet.
- DeploymentvyDeploymentvy
Beskriver hur lösningen skall driftsättas i QA och produktionsmiljöer.
...
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. Mellanlagrar sökresultat
...
Aggregerande tjänster ska skydda källsystemen från last och minimera svarstider genom att mellanlagra (t.ex. i primärminnet) sökresultat. Det gör att endast den första sökningen på ett patientid kommer att resultera i att data hämtas från källsystemet. Därefter ligger resultatet i minnet / mellanlager. Mellanlager hålls aktuellt genom att en aggregerande tjänst prenumererar på händelser från engagemangsindex. Vid notifiering från engagemangsindex aktualiseras data för patienter som redan finns i mellanlagret, från de logiska adressater som notifieringen refererade. När en patients data inte efterfrågats eller uppdaterats på 30 dagar tas patienten bort från mellanlagret (cache) i syfte att hålla nere mängden data som mellanlagras.
Om en viss tjänsteproducent inte är tillgänglig när notifiering inkommer, bör den aggregerande tjänsten hantera omförsök periodiskt tills aktuella bokningar kunnat hämtas in till mellanlagret.
...
3. 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.
...
4. 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).
...
5. Eget tjänstekontrakt
...
Varje aggregerande tjänst har en egen tjänsteinteraktion ("WSDL"). Visserligen delar det tjänstekontrakt (payload-definition / XML-schema) med ett av de befintliga kontrakten, men den aggregerande tjänsten ska därutöver redovisa status från de olika logiska adresserna enligt beskrivning nedan (se "Redovisning av data om anropet"). Ev. kan det vara samma WSDL, där adresseringen avgör om det är aggergering över alla verksamheter eller hämta från en verksamhet.
...
6. Patientidentitet är obligatorisk sökparameter
...
Aggregerande tjänster kan bara användas för att hämta information om en patient. Även om det finns en cache som täcker flera patienter, får tjänsten inte användas för sammanställningar av data för flera patienter.
...
7. 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.
...
8. Redovisning av data om anropet
...
9. 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 vitruella 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.
...
Användningsfall
Tjänsten uppfyller följande användningsfall för att möta de arkitekturella kraven i referens [1]:
- Tjänstekonsument anropar aggregerande tjänst
- 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:
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 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.
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.
...
Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram:
Då information om en patient varken uppdaterats eller lästs under de senaste 30 dagarna så skall tjänsten automatiskt ta bort all information om patienten ur cachen.
...
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.
...
- Cache-flöde, cache-flow Synkront Mule flöde som ansvarar för att exponera tidbokningstjänsten.Söker i cache efter information och returnerar den om den finns. Saknas information i cache anropas main-flow.
- Cache Mule ESB EE komponent (v3.3 eller senare), delvis specialiserad för att möta specifika behov som den aggregerande tjänsten har. Lagrar bokningsinformation per patient då den efterfrågas första gången. Håller bokningsinformationen per patient i upp till 30 dagar sedan den senast uppdaterats eller efterfrågats.
- Huvud flöde, main-flow Synkront Mule flöde som hämtar index-information från engagemangsindex och splitterkomponenten anropas varefter flödet ställer sig och väntar på svar från aggregeringskomponenten innan svar returneras till anropande konsument. Svar från aggregerings-komponenten måste komma inom en konfigurerbar timeout-tid annars returnerar flödet ett timeout-fel tillbaka till konsumenten.
- Splitterkomponent, splitter-flow Asynkront Mule flöde som ansvarar för fördela anropen till källsystem på ett antal instanser av workerkomponenten som arbetar parallellt. Flödet ansvarar också för att märka meddelande till workerkomponenterna med ett och samma correlation-id så att aggregeringskomponenten kan gruppera inkommande svar till respektive väntande konsument (blir speciellt viktigt i de fall två eller fler konsumenter samtidigt söker efter patientinformation som inte finns i cachen). På meddelande till workerkomponenterna anges också antalet förväntade svar så att aggregeringskomponenten kan returnera ett svar så fort alla svar kommit in, dvs inte behöva vänta tills timeouten slår till.
- Workerkomponent, worker-flow Asynkront Mule flöde som anropar ett källsystem, väntar på svar och förmedlar det vidare till aggregeringskomponenten. Flödet väntar på svar från källsystemet upp till en konfigurerbar timeout-tid. Kommer inget svar inom den tiden skickar den vidare ett timout-svar till aggregeringskomponenten. Uppstår det något fel i samband med anropet till källsystemet så skickar flödet vidare ett svar med felinformation till aggregeringskomponenten.
- Aggregeringskomponent, aggregator-flow Samlar in svar från de olika worker-flow instanserna, gruppera svaren per correlationId (satt av splitterkomponenenten) och skickar ett aggregerat svar tillbaka till tidboknings- komponenten när alla svar kommit in eller en konfigurerbar timeout-tid uppnåtts.
- Notifieringstjänst, process-notification-flow Synkront Mule flöde som ansvarar för att exponera processNotification-tjänsten och genom den ta emot uppdateringar från engagemangsindex enligt användningsfallet "Engagemangsindex uppdaterar aggregerande tjänst".
- Administrationsapplikation, admin-appGör det möjligt en administratör att rensa hela eller delar av cachen.
...
TODO: Beskriv hantering timeouter och cachning samt konfigurerbara parametrer för detta:
...
- se.skl.tp.at.tidbokning.engagemangsindex.FindContentRequestTransformer
- se.skl.tp.at.tidbokning.tidbokning.TidbokningRequestTransformer
- se.skl.tp.at.tidbokning.tidbokning.TidbokningResponseTransformer
...
- at: Variabel för aggregeringstjänsten GetSubjectOfCareAggregatedSchedule
- ei: Variebel för engagemangsindex tjänsten FindContent
- ks: Variable för källsystemens tjänst GetSubjectOfCareSchedule
...
- se.skl.tp.at.tidbokning.engagemangsindex.FindContentRequestTransformerTest
- se.skl.tp.at.tidbokning.tidbokning.TidbokningRequestTransformerTest
- se.skl.tp.at.tidbokning.tidbokning.TidbokningResponseTransformerTest
...
...
- Testvy
Beskriver integrationstester som behövs för att säkerställa den totala lösningens funktionalitet.
...
- Implementationsvy
Beskriver centrala delar av implementationen.