Gå till slutet av bannern
Gå till början av bannern

SKLTP EI SAD - Implementationsvy

Hoppa till slutet på meta-data
Gå till början av metadata

Du visar en gammal version av den här sidan. Visa nuvarande version.

Jämför med nuvarande Visa sidhistorik

« Föregående Version 3 Nästa »

Implementations vy

Implementationen av engagemangsindex följer en traditionell lagerindelning:

  • Integrationslager
    Hanterar all extern och intern kommunikation inklusive hantering av transaktioner, loggning fel och omsändning.
    Detta lager har beroenden till Mule CE som ESB och Apache ActiveMQ som JMS provider.

  • Verksamhetslager
    Innehåller regelverk som följer regler i tjänstekontraktet för engagemangsindex.
    Detta lager är implementerat som rena Java klasser (POJO's) och använder Spring Framework för att hantering av beroenden i runtime (DI).

  • Persistenslager
    Hanterar lagring och sökning av engagemangsindex-information i databasen.
    Detta lager är beroende av JPA 2.0 samt Spring Data. För lokala tester används en HSQL in-memory databas och för externa tester används MySQL.
    Persistenslagret kan konfigureras för att använda andra databaser som MS SQL Server, IBM D2 eller Oracle.

Implementations källkodstruktur följer VGR's referensarkitektur inom ramen för Öppna Program, se http://code.google.com/p/oppna-program/wiki/Anvisningar_Kallkodstruktur

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

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:

  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.

process-notification-service

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

 

Tjänstespecifika implementationer anges enligt:

# POJO implementations of the agp-api
QUERY_OBJECT_FACTORY_IMPL=se.skltp.aggregatingservices.riv.crm.requeststatus.getrequestactivities.QueryObjectFactoryImpl
REQUEST_LIST_FACTORY_IMPL=se.skltp.aggregatingservices.riv.crm.requeststatus.getrequestactivities.RequestListFactoryImpl
RESPONSE_LIST_FACTORY_IMPL=se.skltp.aggregatingservices.riv.crm.requeststatus.getrequestactivities.ResponseListFactoryImpl

 

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


De tre mappningarna implementeras av respektive transformeringklass:

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

  • Inga etiketter