Sidjämförelse

...

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.

Image Removed

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:

# 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

...

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

Följande bild återger källkostrukturen ner på Maven modul och därmed Eclipse projekt nivå:

Image Added

Foldrarna innehåller följande projekt:

• applications
  • mule-backend-app
    Applikation avsedd att driftsättas på en Mule instans med alla komponenter förutom som som ligger i frontend app'en
    
    
  • mule-frontend-app
    Applikation avsedd att driftsättas på en Mule instans med komponenterna update-service och notification-service.
    Not: Så länge frontend-appen är uppe så kan EI ta emot uppdateringar även om backend-appen och dess databas är nere för t ex underhåll.
    
    
  • web-backend-app
    Motsvarande app som mule-backend-app fast avsedd för att driftsättas på en servlet-kontainer typ Tomcat som en war-fil.
    
    
  • web-frontend-app
    Motsvarande app som mule-frontend-app fast avsedd för att driftsättas på en servlet-kontainer typ Tomcat som en war-fil.
    
    
• composites
  • schema
    Innehåller de tjänstekontrakt som implementationen exponerar och/eller konsumerar.
    
    
  • svc
    Innehåller källkoden för verksamhetslagret samt persistenslagret.
    
    
• modules
  • intsvc
    Innehåller källkoden för integrationslagret.

Följande modell beskriver de mest centrala källkodsartefakterna samt var de finns placerade i källkodsträdet:

Image Added