Jämförda versioner

Nyckel

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

...

Krav IdBeskrivningTyp
K-1Införandet av en virtuell tjänst i samverkan mellan tjänstekonsument och tjänsteproducent ska maximalt tillföra 40 millisekunder i exekveringstid, i förhållande till ett anrop utan mellanhand.Prestanda
K-2Virtualiseringsplattformen ska stödja gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer.Skalbarhet
K-3All kommunikation ska säkras enligt RIV Tekniska Anvisningar Basic Profile 2.0 (https med ömsesidig autentisering). Detta innebär att båda parter skall presentera giltiga certifikat vid upprättandet av en säker förbindelse (sk SSL-handshake).Säkerhet
K-4VP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler.Utökningsbarhet
K-5

VP ska kunna driftsättas på alla plattformar där finns Java. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner.

jAFlexibilitet
K-6Virtualiseringsplattformen ska ha stöd för teknisk monitorering. Detta innebär också riktat stöd för monitorering av svarstider hos tjänsteproducenter och att VP loggar på loggformat lämpliga för övervakning av gängse övervakningsverktyg.Monitorering
K-7Tjänster är tillståndslösa mellan anrop, vilket gör att s.k. fail-over inte behöver införas för att uppnå hög tillgänglighet. Hög tillgänglighet bedöms kunna uppnås genom klustring.Tillgänglighet
K-8Virtualiseringsplattformen (VP) ska inte vara beroende av att Tjänstekatalogens (TAK) tjänster för att hämta behörighet och routing är tillgänglig online, vilket medför att VP ska kunna utföra sitt uppdrag även när TAK inte är tillgänglig.Tillgänglighet
K-9

 VP ska levereras som öppen källkod under licensen LGPL.

 Flexibilitet
K-10

VP ska levereras med automatiserade last- och robusthets-tester. Plattformen kommer - även om den är distribuerad - att vara förknippad med höga SLA-krav. Robust exekvering av inkomna meddelanden med minimal overhead, timme ut och timme in, är avgörande för att plattformen ska anses tillförlitlig.

 Prestanda
K-11

All utveckling av VP ska baseras på portabla, komponentbaserade byggen enligt en väl beskriven produktstruktur.

 Flexibilitet
K-12Virtualiseringar ska kunna skapas mha en enkel instruktion. Detta utifrån en kanonisk, abstrakt WSDL med tillhörande scheman för ett tjänstekontrakt och därefter kunna skapa paketeringar per tjänstekontrakt som kan slutkonfigureras och driftsättas i olika instanser av virtualiseringsplattformen.

...

Krav IdBeskrivningTyp
FK-1Autentisering för HTTPS ska ske via "mutual authentication" i två led eller fler led för Virtualiseringsplattformen enligt RIV Tekniska Anvisningar.Säkerhet
FK-2Auktorisation för HTTPS ska ske via det HSA-id ett anropande system presenterar i certifikatets "subject"Säkerhet
FK-3Autentisering och Auktorisation för HTTP ska ske genom användning av information i HTTP-headers.Säkerhet
FK-4All intern kommunikation mellan SKLTP-komponenter ska gå via HTTP med extra verifiering av anslutande part enligt FK-3.Säkerhet
FK-5VP ska stödja "RIV-TAs frivilliga anvisning angående HTTP Header för att ange ursprunglig avsändare".
FK-6

VP ska hantera olika versioner av RIV-TA profiler, dvs en översättning mellan olika RIV TA-profiler (transformering mellan olika kuverterings- och säkerhetsmodeller).


FK-7

Felmeddelande som orsakas i virtualiseringsplattformen ska rapporteras som SOAPFault till tjänstekonsumenten med tillhörande HTTP Status kod (500), samt loggas. ID i SOAPFault ska finnas för korrelering mot en loggfil.

Felhantering
FK-8Felsituationer som är förutsägbara baserade på inkonsistens mellan metadata i meddelandetrafik och innehåll i tjänstekatalog, ska redovisas i SOAPFaults med mycket stor tydlighet, så att det inte råder något tvivel om orsaken och vad som behöver göras (se standardiserade felkoder nedan).Felhantering
FK-9

Alla former av fel ska kunna spåras i efterhand då dessa loggas persistent. Loggnivån ska vara konfigurerbar för att kunna spara extra mycket spårningsinformation.

Felhantering
FK-10VP ska redovisa svarstider mot bakomliggande tjänsteproducenter dels i interna loggar och dels till anropande system.Monitorering 
FK-11

VP ska under drift kunna hämta och uppdatera sin konfiguration från en Tjänstekatalog (TAK). Detta innebär att VP behöver ha en cache med TAK konfiguration om en sådan läsning misslyckas för att säkerställa VPs driftsfunktionalitet. Denna cache uppdateras vid ett lyckat anrop.


FK-12

VP ska under drift kunna hämta och uppdatera sin HSA konfiguration från en lokalt inläst HSA-fil. Detta innebär att VP behöver ha en cache med HSA konfiguration om en sådan läsning misslyckas för att säkerställa VPs driftsfunktionalitet. Denna cache uppdateras vid ett lyckat anrop.


FK-13VP ska per tjänst kunna konfigurera ett separat time-out värde. Är inget time-out värde angivet skall ett defaultvärde användas(konfigurerbart).
FK-14VP ska per tjänst kunna konfigurera om keep-alive skall användas i kommunikationen.
FK-15VP ska stödja "RIV-TAs frivilliga anvisning angående status för anrop till aggregerande tjänster".
FK-16VP ska per tjänst kunna besvara ett tjänsteanrop med ?wsdl. Detta så att tjänstekonsumenter alltid kan få tillbaka aktuell wsdl och scheman för tjänsten. Detta skall gälla även om det finns en reverse-proxy/lastbalanserare framför VP.Tillgänglighet
FK-17

Såväl vägval som behörigheter ska kunna registreras högre upp i HSA-s organisationsträd än på vårdgivarnivå. För vägval kan registrering typiskt ske på den nivå som det tjänsteproducerande systemet stöttar respektive organisation och för behörighet på den nivå i organisationen som konsumenten skall ha access.

Säkerhet
FK-18

Logisk adress kan anges som VG#VE där VG är vårdgivares HSAID och VE vårdenhets HSAID.

Not: Denna adressering får endast användas efter godkännande från Inera. Detta krav har lagts till här då det är en existerande funktion i SKLTP. Funktionen kan dock komma att avvecklas. Se FK-17 som är en generellt krav för klättring i HSAID-trädet.

Säkerhet
 FK-19 VP ska kunna göra ett nytt försök att anropa producent efter ett misslyckat anrop. Tiden mellan anropen ska vara konfigurerbar och funktionen ska även kunna stängas av. Stabilitet
 FK-20 VP ska kunna hantera och exponera ett korrelations-id (x-skltp-correlation-id) som används som en gemensam identitet vid kommunikation över flera system och vid loggning. Om korrelations-id saknas ska ett sådant kunna genereras av VP.Monitorering FK-21VP ska kunna logga till en annan applikation via socket.

Standardiserade felkoder
Ankare
VP-felkoder
VP-felkoder

...

FelkodFeltextKommentar
VP001

Riv-version inte konfigurerad för den anslutningspunkt som den virtualiserade tjänsten publicerar.


VP002

SERIALNUMBER ej tillgängligt i konsumentens certifikat i namn-attributet.


VP003

ReceiverId ej ifylld i RivHeadern i inkommande meddelande.


VP004

Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som matchar ReceiverId, Tjänstekontrakt och dagens datum.


VP005

Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som matchar Riv-version, konvertering mellan rivversioner inte implementerat.


VP006

Det finns mer än 1 tjänsteproducent definierad i Tjänstekatalogen som matchar ReceiverId, Tjänstekontrakt och dagens datum. Tyder på att Tjänstekatalogen är felkonfigurerad.


VP007

Den finns ingen behörighet för den tjänstekomponent som anropar att samverka med tjänsteproducenten. Avser behörigheter definierade i tjänstekatalogen.


VP008

Ingen kontakt med tjänstekatalogen. Innebär att vägvalsagenten inte kunnat hämta vägvalsinformation varken vid uppstart eller vid något efterföljande anrop.


VP009

Fel vid kontakt med tjänsteproducenten.


VP010

Ingen adress angiven i tjänsteproducenten


VP011Anropande konsument är inte betrodd att göra http-anrop till VPAnropande konsument kan tex vara en annan SKLTP komponent,
en lastdelare eller tex en reverse proxy. 
VP012Nödvändiga resurser för att VP skall fungera saknas.Virtualiseringsplattformen saknar någon av de resurser som krävs för att den skall kunna fullfölja
sitt uppdrag att hantera routing och behörighet.
VP013

Sender is not approved to set header x-rivta-original-serviceconsumer-hsaid.


Förtydligande av specifika krav

...