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. Dock är implementationen designad för att kunna införa cachning i en framtida version på ett kostnadseffektivt sätt.

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. Den kan anpassas för specifika aggregerande tjänsters behovs på tre ställen:

...

Image Removed

process-notification-service

Image Removed

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:

1. Mappning AggregatedGetSubjectOfCareSchedule-request till FindContent-request
2. Mappning FindContent-response till GetSubjectOfCareSchedule-request
3. Mappning GetSubjectOfCareSchedule-response till AggregatedGetSubjectOfCareSchedule-response

...

1. se.skl.tp.at.tidbokning.engagemangsindex.FindContentRequestTransformer
2. se.skl.tp.at.tidbokning.tidbokning.TidbokningRequestTransformer
3. 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

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:

...

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

...

...

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

Produktval

Som ramverk för aggregeringsplattformen har Spring Boot + Apache-Camel valts.
Apache-Camel är ett moget ramverk med stöd för de funktioner som krävs för att realisera en aggregeringsplattform.

Apache-Camel är öppen källkod som distribueras under Apache 2.0 license.

Struktur

Implementationen är uppdelad i:

• Aggregeringsplattformen - Körbar applikation som innehåller huvud funktionalitet samt laddar in tjänsteimplementationer.
• Tjänsteimplementationer - Pluginer till aggregeringplattformen som innehåller tjänstespecifika konfigureringar och funktionalitet.

Aggregeringsplattformen laddar in alla tjänsteimplementationer som den hittar i sin classpath.

Struktur aggregeringsplattformen

Aggregeringsplattformen är uppdelad i ett antal java moduler:

• agp-application - Implementation av den körbara aggregeringsplattformen. 
• agp-core - Innehåller de inteface som tjänsteimplementationerna måste implementera samt hjälpfunktioner.
• agp-schemas - Innehåller de scheman aggregeringsplattformen behöver för att anropa EI och TAK.
• agp-test-core - Gemmensam testfunktionalitet
• agp-test-service - En test implementation av en tjänst för integrationtester.
• agp-test-stub - En bas för stubbning av EI, TAK samt för tjänster.

Struktur tjänsteimplementation

En tjänsteimplementation behöver:

• Innehålla wsdl:er för den specifika tjänsten
• Implementera interfacet AgpServiceConfiguration för den tjänstespecifika konfigureringen
• Implementera interfacet AgpServiceFactory för den tjänstespecifika funktionaliteten.

Källkod

Se AgP - Instruktioner för utvecklare

Exceptions

Fel från producenter rapporteras i  SOAP headern "ProcessingStatus" men skapar inga interna exceptions eller SoapFaults. 

Interna fel som kastar exceptions eller fel mot EI/FindContent genererar ett SoapFualt tillbaka till anropande konsument.

Monitorering

Statustjänst 

AGP exponerar en status-tjänst som returnerar information om plattformen. Genom anrop av denna tjänst kan man på ett enkelt sätt kontrollera att aggregeringsplattformen är igång och vilka tjänster den laddat in.
Se: AGP - Status tjänst

Hawtio

Hawtio använd för monitorering och som "manager" verktyg.

Det finns möjlighet att ändra loggnivåer under drift, få systeminformation som processorutnyttjande, minne, diskutrymme, javaversion, java classpath, threads etc.

Loggning

För loggning används log4j2. Meddelanden genom plattformen loggas i ett format som gör det enkelt att ta in och monitorera med Kibana.
Se: AGP - Loggning

TAK cache

VP har sin egen kopia av TAK data i en cache implementerad i en fristående komponent https://github.com/skltp/takcache som innehåller vägval och anropsbehörigeter.

Denna används för:

• Kontrollera att det finns ett vägval till producenten och att konsumenten har behörighet för denna. Se Arkitektuella krav #8. 

Man kan göra en uppdatering av TAK cache komponenten via ett REST anrop.