Jämförda versioner

Gammal version 3

changes.mady.by.user Magnus Larsson

Sparat den

jämfört med

Ny version 4

changes.mady.by.user Magnus Larsson

Sparat den

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Innehåll

Innehållsförteckning
maxLevel3
outlinetrue
stylenone

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

...

  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.

  5. Deploymentvy
    Beskriver hur lösningen skall driftsättas i QA och produktionsmiljöer.

  6. Testvy
    Beskriver integrationstester som behövs för att säkerställa den totala lösningens funktionalitet.
    Deploymentvy

  7. Beskriver hur lösningen skall driftsättas i QA och produktionsmiljöer.
    Implementationsvy
    Beskriver centrala delar av implementationen.

...

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:

...

Test vy

Mule flödena är implementerade mha Mule Studio och återges nedan som skärmdumpar från verktyget:
TODO:Uppdatera map införande av aggregeringsplattform

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


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

Implementations vy

TODO: Uppdatera map införande av aggregeringsplattform

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



Mekanismer

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

Kodblock
# 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

 

...

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!
...
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
...
  • 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, 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
...
  • 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
Referenser
  1. T-boken (REV B) - http://www.cehis.se/arkitektur_regelverk/teknisk_arkitektur/