Jämförda versioner

Gammal version 6

changes.mady.by.user Magnus Larsson

Sparat den

jämfört med

Ny version 7

changes.mady.by.user Magnus Larsson

Sparat den

Nyckel

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

Innehållsförteckning

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

...

  • Använder en collection-aggregator för att samla in de parallellt framställda svaren till en aggregerat svar.
  • När alla svaren kommit eller timeout som styrs av parametern AGGREGATE_TIMEOUT_MS inträffar så skickas det sammansatta svar som samlats in så långt till vm-kön "reply", dvs till request-reply-flodet beskrivet ovan.

Note:

Konfiguration

 Konfiguration två mekanismer är av central betydelse för att en aggregerande tjänst skall fungera bra i en produktionsmiljö med både hög last och där fel inträffar pga kommunikationsproblem och/eller långa svarstider.

Timeouter

För att den timeout-hanteringen skall fungera och den aggregerande tjänsten skall kunna ge så meningsfull information felinformation som möjlig tillbaka till anropande tjänsteproducent vid timeout-relaterade fel så är det viktigt att: 

AGGREGATED_SERVICE_TIMEOUT_MS > AGGREGATE_TIMEOUT_MS > SERVICE> SERVICE_TIMEOUT_MS

 

  • process-notification-service

Image Removed

  • Mekanismer

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

 

Exempel på konfiguration:

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

Trådpool

För att en aggregerande tjänst skall kunna bibehålla låga svarstider vid uppskakad last är det av central betydelse att det finns tillräckligt med trådar konfigurerade för att kunna hantera alla parallella anrop. Samtidigt 

Varje aggregerande tjänst kan konfigureras individuellt baserat på följande parametrar för en default tråd pool:

Kodblock
languagexml
<default-threading-profile poolExhaustedAction="ABORT" maxThreadsActive="${AGP_DEFAULT_MAX_THREADS_ACTIVE}" maxThreadsIdle="${AGP_DEFAULT_MAX_THREADS_IDLE}" threadTTL="${AGP_DEFAULT_MAX_THREADS_TTL}"/>

 

 

# Cache properties
CACHEExempel på konfiguration:

 

# Default thread pool configration
 AGP_DEFAULT_MAX_
ENTRIES
THREADS_ACTIVE=
1000
CACHE_TTL_MS=5000
CACHE_EXPIRATION_INTERVAL_MS=1000
100
 AGP_DEFAULT_MAX_THREADS_IDLE=1

 AGP_DEFAULT_MAX_THREADS_TTL=10000

 

 

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:

  • Mappning AggregatedGetSubjectOfCareSchedule-request till FindContent-request
  • Mappning FindContent-response till GetSubjectOfCareSchedule-request
  • Mappning GetSubjectOfCareSchedule-response till AggregatedGetSubjectOfCareSchedule-response

...

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