Jämförda versioner

Nyckel

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

Note: Denna funktion är under utveckling, följ utvecklingen i JIRA!

...

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. 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. Ett generellt möster för aggregerande tjänster kan relaiseras i en aggregeringsplattform (SKLTP AGP) på ett liknande sätt som SKLTP idag förenklar 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).

...

Användningsfallet beskrivs av följande löptext och tillhörande sekvensdiagram.

Då en tjänstekonsument anropar den aggregerande tjänsten för tidbokningar så söker den först i cachen på angivet patientId och returnerar informationen från cachen om sådan finns. Annars anropar tjänsten engagemangsindexet för att få redan på var nuvarande bokningar för angivet patientId finns, dvs hos vilka mottagningar. Därefter anropas respektive källsystem parallellt (för att minimera svarstiden) och ett aggregerat svars sätts samman. Det aggregerade svaret sparas i cachen samt returneras till tjänstekonsumenten. Cachen uppdateras också i de fall anrop misslyckats med relevant fel-information.

Respons SOAP headern "ProcessingStatus"

Teknisk information om bearbetningen sammanställs i svaret tillbaka till tjänstekonsumenten i en SOAP header med namnet "ProcessingStatus".
SOAP headern "ProcessingStatus" innehåller en lista med en rad per anropat källsystem och ger per källsystem information huruvida anropet gick bra, svaret kom dirket från cache, hur gammal den cachade informationen är. Se interoperability_headers_1.0.xsd för detaljer.

Notera att SOAP headern "ProcessingStatus" inte beskrivs i de tjänsteinteraktioner (WSDL-filer) som en aggregerande tjänst följer, detta för att kunna använda samma tjänsteinteraktioner som de underliggande tjänsteproducenterna använder. Det innebär att SOAP headern "ProcessingStatus" behöver beskrivas vid sidan av tjänsteinteraktionerna, förslagsvis som ett appendix till gällande RIV-TA version.


Not: I sekvensdiagrammet nedan är NTjP's Virtualiseringplattform bortabstraherad i syfte att öka diagrammets läsbarhet men den används i samtliga externa samband, dvs i anrop mellan den aggregerande tjänsten och konsumenter, engagemangsindex och källsystem.

...