Innehåll

...

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).

...

1. Arkitekturella krav
   Beskriver de arkitekturella egenskaper som är gemensamma för aggregerande tjänster.
   
   
2. Systemsamverkan
   Ger en översiktlig bild av vilka system som samverkar samt dess primära roller i denna samverkan
   
   
3. Användningsfall
   Beskriver de användningsfall som har störst påverkan på designen.
   
   
4. Logisk vy
   Beskriver designens logiska uppdelning.
   Implementationsvy
   Beskriver centrala delar av implementationen.
   
   
5. Testvy
   Beskriver integrationstester som behövs för att säkerställa den totala lösningens funktionalitet.
   
   
6. Deploymentvy
   Beskriver hur lösningen skall driftsättas i QA och produktionsmiljöer.
   

...

1. 
   
2. Implementationsvy
   Beskriver centrala delar av implementationen.
   
   

Aggregerande tjänster delar en rad egenskaper:

...

• Administrationsapplikation, admin-app
  Gör det möjligt en administratör att rensa hela eller delar av cachen.

...

Deployment vy

...

Mekanismer

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

...

Tjänsten skall driftsättas i befintlig infrastruktur för den nationella tjänsteplattformen, NTjP.Tjänsten paketeras och deployas som en standard Mule applikation på samma Mule instans som Virtualiseringsplattformen (VP) exekverar på.

Not: I dagsläget stöttar VP bara den gamla Mule 2 deploymodellen och inte Mule 3's nya Mule Applikations koncept, dvs utan möjlighet att deploya och omdeploya enskilda Mule applikationer (t ex nationella tjänster). Detta måste åtgärdas för att denna tjänst skall kunna driftsättas i NTjP's miljö.

Översiktbil av NTjP's QA och produktionsmiljö med aggregerande tjänst för tidbokning driftsatt:

Image Added

Implementations vy

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

Image Added

Image Added

Mekanismer

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

# Default timeout for synchronous services
SERVICE_TIMEOUT_MS=4000
AGGREGATE_TIMEOUT_MS=4500
AGGREGATED_SERVICE_TIMEOUT_MS=5000

# Cache properties
CACHE_MAX_ENTRIES=1000
CACHE_TTL_MS=5000
CACHE_EXPIRATION_INTERVAL_MS=1000

...

• 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
  
  

  Test vy

  De tre mappningarna testas av respektive unit-tester-klasser:

1. se.skl.tp.at.tidbokning.engagemangsindex.FindContentRequestTransformerTest
2. se.skl.tp.at.tidbokning.tidbokning.TidbokningRequestTransformerTest
3. se.skl.tp.at.tidbokning.tidbokning.TidbokningResponseTransformerTest

...

Deployment vy

Tjänsten skall driftsättas i befintlig infrastruktur för den nationella tjänsteplattformen, NTjP.Tjänsten paketeras och deployas som en standard Mule applikation på samma Mule instans som Virtualiseringsplattformen (VP) exekverar på.

...

1. engagemangsindex.FindContentRequestTransformerTest
2. se.skl.tp.at.tidbokning.tidbokning.TidbokningRequestTransformerTest
3. se.skl.tp.at.tidbokning.tidbokning.TidbokningResponseTransformerTest

Integrationstester skall realiseras såväl som automatiska integrationstester som vara körbara i en test/qa miljö mot skarpa samverkande testsystem.
Följande integrationstester behövs för att säkerställa den totala lösningens funktionalitet.
TBD

Referenser

1. T-boken (REV B) - http://www.cehis.se/arkitektur_regelverk/teknisk_arkitektur/