SKLTP AgP SAD - Implementationsvy

Mule flödena är implementerade mha Mule Studio och återges nedan som skärmdumpar från verktyget.

Not: I gällande version av aggregeringplatttformen, v1.1.0, är cache-funktionalitet implementerad men inaktiverad. Dock är implementationen designad för att kunna införa cachning i en framtida version på ett kostnadseffektivt sätt om beslutet att ta bort cachning ändras igen..

Tillgång till källkoden

Se Instruktioner för utvecklare.

aggregating-service

aggregating-service är en generisk mönster-implementation av en aggregerande tjänst i aggregeringsplattformen. Den kan anpassas för specifika aggregerande tjänsters behovs på tre ställen:

1. Create Query Object
   Omvandlar inkommande tjänstespecifika anrop och skapar ett generiskt Query Object som resten av tjänsten använder sig av.
   
   
2. Request List Transformer
   Filtrerar och omvandlar svar från sökning i Engagemangs Index (via tjänsten findContent()) till anrop till underliggande källsystem via för tjänsten specifika tjänstekontrakt
   
   
3. Response List Transformer
   Sätter samman ett tjänstespecifikt aggregerat svar baserat på delsvaren som returnerats från källsystemen.

Implementationen är uppdelad i följande Mule flöden:

• cache-flow
• main-flow
• request-reply-flow
• splitter-flow
• worker-flow
• aggregation-flow

cache-flow

• Exponerar HTTP endpunkt för den aggregerande tjänsten.
• Sätter kommunikationsheadrar enligt krav från RIV-TA och VP.
• Anropar tjänstespecifik "Create Query Object" implementation för att läsa ut information från inkommande request. 
• Delegerar till bearbetningen till main-flow.

Note: Anledningen till såväl namnsättning på detta flöde samt delegeringen till ett main-flow är att det är i detta flöde som den inaktiverade cachningsfunktionen ligger. 

main-flow

• Preparerar ett anrop till EI's FindContent tjänst inklusive properagering av kommunikationsheadrar.
• Anropar EI EI's FindContent tjänst mah en Message Enhancer.
• Anropar tjänstespecifik "Request List Transformation" implementation för att skapa en lista med de anrop som skall göras till underliggande tjänsteproducenter. 
• Delegerar bearbetningen till request-reply-flow.
• I hanteringen av svaret, dvs i ett response-element, anropas en tjänstespecifik "Response List Transformation" implementation för att skapa det slutgiltiga aggregerade svaret baserat på de olika svar som kommit från de underliggande tjänsteproducenterna. 
•  

request-reply-flow

• Ansvarar för att brygga mellan den ytter synkrona bearbetningen i cache-flow och main-flow till den asynkrona och parallella bearbetningen i splitter-flow, worker-flow och aggregation-flow
• Skickar listan på request till vm-kön "splitter" och väntar synkront på ett asynkront aggregerat svar på vm-kön "reply".
• Timeout på väntan på svar styrs av parametern AGGREGATED_SERVICE_TIMEOUT_MS.

splitter-flow

• Använder en collection-splitter för att dela upp listan med request till separata request.
• Märker meddelanden med ett korrelerings-id.
• Lägger på en reply-to header som anger vm-kön "aggregate" dit svaren skickas för aggregering.

worker-flow

• Sätter upp kommunikationsheadrar enligt RIV-TA och anropar de utpekade tjänsteproducenterna via VP.
• Svar skickas mha reply-to-headern satt ovan till vm-kön "aggregate"
• Kommunikationsfel och timeout fångas upp per anrop av exception-handlern "Catch Exception Strategy" och fel-information skickas till vm-kön "aggregate" så att felet kan rapporteras enligt RIV-TA i processingStatus headern.

• Timeout på väntan på svar från tjänsteproducenten styrs av parametern SERVICE_TIMEOUT_MS

aggregation-flow

• Använder en collection-aggregator för att samla in de parallellt framställda svaren till en aggregerat svar.
• När alla svaren kommit eller timeout som styrs av parametern AGGREGATE_TIMEOUT_MS inträffar så skickas det sammansatta svar som samlats in så långt till vm-kön "reply", dvs till request-reply-flodet beskrivet ovan.

Note: För att den timeout-hanteringen skall fungera och den aggregerande tjänsten skall kunna ge så meningsfull information som möjlig tillbaka till anropande tjänsteproducent så är det viktigt att: 

AGGREGATED_SERVICE_TIMEOUT_MS > AGGREGATE_TIMEOUT_MS > SERVICE_TIMEOUT_MS

• process-notification-service

• Mekanismer

TODO: Beskriv hantering timeouter och cachning samt konfigurerbara parametrer för detta:

Tjänstespecifika implementationer anges enligt:

• Meddelandemappningar

I detta kapitel beskrivs de mappningar som behöver göras mellan meddelanden i respektive användningsfall.

TODO: Rensa upp och beskriv utgående från aggregeringsplattformen!

• Konsument anropar aggregerande tjänst

Tre mappningar behövar göras för detta användningsfall, se tillhörande sekvensdiagram för överblick:

• Mappning AggregatedGetSubjectOfCareSchedule-request till FindContent-request
• Mappning FindContent-response till GetSubjectOfCareSchedule-request
• Mappning GetSubjectOfCareSchedule-response till AggregatedGetSubjectOfCareSchedule-response

De tre mappningarna implementeras av respektive transformeringklass:

• se.skl.tp.at.tidbokning.engagemangsindex.FindContentRequestTransformer
• se.skl.tp.at.tidbokning.tidbokning.TidbokningRequestTransformer
• se.skl.tp.at.tidbokning.tidbokning.TidbokningResponseTransformer

Variabler som används i mappningarna nedan är prefixade med id'n för tillhörande tjänst:

• at: Variabel för aggregeringstjänsten GetSubjectOfCareAggregatedSchedule
• ei: Variebel för engagemangsindex tjänsten FindContent
• ks: Variable för källsystemens tjänst GetSubjectOfCareSchedule

• Mappning AggregatedGetSubjectOfCareSchedule-request till FindContent-request

GetSubjectOfCareAggregatedSchedule in-parametrar:

• at.in.logicalAdress = hsa-id för aggr tjänst
• at.in.actor = SUBJECT_OF_CARE eller SUBJECT_OF_CARE_AGENT
• at.in.subject_of_care = personnummer för patienten i fråga

FindContent in-parametrar mappas enligt: 

• ei.in.logicalAdress = hsa-id för nationellt EI
• ei.in.registeredResidentIdentification = at.in.subject_of_care

• ei.in.serviceDomain = "riv:crm:scheduling"

Not: Övriga element i FindContent requestet utelämnas och antas ge wildcard-funktionelitet, t ex Categorization och MostRecentChange

Kommentar av Johan Eltes:

Vi kanske skulle speca att en aggregerande tjänst kan parameteriseras (konfigureras) med ett datum för MostRecentChange och för antal dagar i cachen. Till exempel kanske tidbokningar i dåtid inte är intressant, mer än någon månad tillbaka...

Svar: Magnus Larsson:

Låter rimligt, låter kommentaren stå kvar så får vi se var den kommer in....

• Mappning FindContent-response till GetSubjectOfCareSchedule-request

FindContent ut-parametrar:

• ei.ut.engagement-list, ett element i listan per logical-address som har tidbokningsinfo för patienten i fråga
  
  Not: Istället för att anropa GetBookingDetail en gång per bokning så anropas GetSubjectOfCareSchedule en gång per logical-address.
  
  Finns det två eller fler bokningar för en patient på en och samma logical-address så innebär det färre anrop till källsystemet, dvs en prestandavinst och lägre last på källsystemen.

GetSubjectOfCareSchedule in-parametrar mappas enligt:

• ks.in.logicalAdress = ei.ut.engagement-list.row.logicalAddress
• ks.in.actor = at.in.actor
• ks.in.healthcare_facility = ei.ut.engagement-list.row.logicalAddress
• ks.in.subject_of_care = ei.ut.engagement-list.row.registeredResidentIdentification

• Mappning GetSubjectOfCareSchedule-response till AggregatedGetSubjectOfCareSchedule-response

GetSubjectOfCareSchedule ut-parametrar:

• ks.ut.timeSlotDetail-list, ett element in listan per bokning för avsedd logical-address för patienten i fråga
  
  Svaren från respektive logical-address läggs samman till ett aggregerat svar.
  

GetSubjectOfCareAggregatedSchedule ut-parametrar mappas enligt:

• ks.ut.timeSlotDetail-list, summan av alla inkomna svar från källsystemen.

• Engagemangsindex uppdaterar aggregerande tjänst

TBD

• Rensning av cache

TBD