Sidjämförelse

TODO: Uppdatera map införande av aggregeringsplattform

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 inte 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 ä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. 

Image Added

main-flow

request-reply-flow

splitter-flow

worker-flow

aggregation-flow

• process-notification-service

• Mekanismer

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

...

• 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:

...

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:

...

• 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, summan av alla inkomna svar från källsystemen.

• Engagemangsindex uppdaterar aggregerande tjänst

TBD

• Rensning av cache

TBD