Jämförda versioner

Nyckel

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

...

Den aggregerande tjänsten är uppbyggd av ett antal logiska komponenter. De beskrivs av nedanstående komponentmodell samt efterföljande textuella beskrivning av respektive komponent. Not: I komponentmodellen nedan är NTjP's Virtualiseringplattform bortabstraherad i syfte att öka bildens läsbarhet men den används i samtliga externa samband, dvs i anrop mellan den aggregerande tjänsten och konsumenter, engagemangsindex och källsystem.
Image Removed
Komponenter i den aggregerande tjänsten:

  • Cache-flöde, cache-flow
    Synkront Mule flöde som ansvarar för att exponera tidbokningstjänsten.Söker i cache efter information och returnerar den om den finns. Saknas information i cache anropas main-flow.
  • Cache
    Mule ESB EE komponent (v3.3 eller senare), delvis specialiserad för att möta specifika behov som den aggregerande tjänsten har. Lagrar bokningsinformation per patient då den efterfrågas första gången. Håller bokningsinformationen per patient i upp till 30 dagar sedan den senast uppdaterats eller efterfrågats.
  • Huvud flöde, main-flow
    Synkront Mule flöde som hämtar index-information från engagemangsindex och splitterkomponenten anropas varefter flödet ställer sig och väntar på svar från aggregeringskomponenten innan svar returneras till anropande konsument. Svar från aggregerings-komponenten måste komma inom en konfigurerbar timeout-tid annars returnerar flödet ett timeout-fel tillbaka till konsumenten.

...

  • Aggregeringskomponent, aggregator-flow
    Samlar in svar från de olika worker-flow instanserna, gruppera svaren per correlationId (satt av splitterkomponenenten) och skickar ett aggregerat svar tillbaka till tidboknings- komponenten när alla svar kommit in eller en konfigurerbar timeout-tid uppnåtts.
  • Notifieringstjänst, process-notification-flow
    Synkront Mule flöde som ansvarar för att exponera processNotification-tjänsten och genom den ta emot uppdateringar från engagemangsindex enligt användningsfallet "Engagemangsindex uppdaterar aggregerande tjänst".

...

Komponenterna i aggregeringsplattformen implementeras som olika Apache-camel flöden (flödena kallas "routes" i Apache-camel).


Image Added

{service}-in-route

Det genereras upp en {service}-in-route per aggregerad tjänst utifrån konfigurationen för den aggregerade tjänsten.

{service}-in-route exponerar en http endpoint för den tjänsten, skapar ett java objekt av inkommande SOAP anrop och skickar vidare till agp-service-route.

agp-service-route

  • Anropar EI för att se vilka producenter som ska anropas.
  • Filtrerar bor producenter som inte konsumenten har behörighet att anropa (via TAKCache).
  • Anropar producenter parallellt genom att anropa {service}-out-route för tjänsten.
  • Aggregerar alla svar från {service}-out-route som sedan returneras till anropande konsument.

{service}-agp-service-route

Det genereras upp en {service}-out-route per aggregerad tjänst utifrån konfigurationen för den aggregerade tjänsten.

{service}-out-route skapar ett Soap meddelande utifrån java objektet och anropar producenten av tjänsten.

reset-tak-cache-route

Exponerar en REST endpoint som kan anropas av adminstrativ personal.

Denna uppdaterar den interna TAK cachen genom att hämta nytt data från TAK.

get-status

Exponerar en REST endpoint som kan anropas av adminstrativ personal.

Denna endpoint returnar status för aggregeringsplattformen, ex:

  • Tidpunkt för uppstart
  • Versionsinformation
  • Minnesförbrukning
  • Status för TAK cache
  • Vilka tjänster finns installerade och dess endpoints