Jämförda versioner

Nyckel

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

Innehållsförteckning

Innehållsförteckning

Revisionshistorik

Version

Datum

Författare

Kommentar

0.9 RC1 (2021)

2021-06-11

Frank Grundin, Marco de Luca

Version som underlag för pilotverksamhet och som är anpassad enligt nya förutsättningar för 2021.

0.9.1 RC1 (2021)

2021-06-30

Malin Domeij

Smärre förtydliganden

0.9.2 RC1 (2021)

2021-12-14

Marco de Luca

Revidering

  • SDKs federationens egna komponenter borttagna. SLA för dessa ska regleras i andra dokument.

0.9.2 RC1 (2022)

2022-02-09

Marco de Luca

Revidering

  • Krav på omsändningar för Meddelandetjänst borttaget. Sändande part skall snabbar få återkoppling om meddelandeöverföring fungerade eller ej.

1.0 (2022)

2022-02-28

Marco de Luca

Beslutad version för Tjänsten Säker digital kommunikation.

1. Inledning

Detta dokument innehåller en övergripande beskrivning av tillgänglighetskrav som ställs på anslutna användarorganisationers komponenter respektive SDKs gemensamma komponenter inom infrastrukturen för Säker digital kommunikation (SDK).

Referenser

Styrande SDK-dokument

Ref

Dokument-id

Dokumentlänk

B1

Specifikation av validering, felhantering och kvittens

Specifikation av validering, felhantering och kvittens

2. SLA

Uppföljning av SLA-kraven:

  • Tillgänglighet hos användarorganisationernas anslutna komponenter följs ej upp centralt utan ska löpande bevakas av användarorganisationen, utöver att en central övervakningskomponent kontrollerar löpande vilka accesspunkter som är uppe och rapporterar avvikelser till SDK-federationsoperatör

  • SDK-federationsoperatör ska löpande bevaka SLA för gemensamma komponenter i infrastrukturen för SDK (SDK Adressbok och SDK Testklient)

2.1 Accesspunkt

Följande generella SLA-krav gäller användarorganisationer som tillhandahåller accesspunkt som är ansluten till infrastrukturen för SDK.

Kategori

Värde

Beskrivning

Kommentar

Svarstid

Inom 10 sekunder

Tiden för mottagande accesspunkt att skicka transportkvittens

Krav på max svarstid får inte överstiga konfigurerad/rekommenderad ‘retryTimeout’ vid omsändning.
Det bör också finnas en viss marginal med tid för transport mellan C2 och C3.

En kortare svarstid ställer högre krav på systemlösningen, vilket i sin tur ökar kostnaden för drift.

Tillgänglighet

24x7, 99,5%

Accesspunkten ska vara uppe oavsett om det är inom eller utanför AP-operatörens kontorstid, så att det finns möjlighet att ta emot och lagra inkommande meddelanden från andra användarorganisationer.

En Accesspunkt som inte är uppe kommer efter 4 omsändningsförsök rapporteras som nere (robusthet).

Kapacitet (mottagare)

Kapacitetetskrav är uppfyllda så länge 99,5% av mottagna meddelanden kan kvitteras inom SLA för svarstid

Kravet innebär att oavsett storlek på anslutna bakomliggande användarorganisationer, så behöver användarorganisationen säkerställa att Accesspunkten kan hantera inkommande trafik enligt SLA-krav.

Det här ställer också krav på att andra användarorganisationer inom SDK-federationen är tydliga med vilka behov verksamheten har av att skicka trafik.

Robusthet

Stöd för omsändning

Rekommenderad inställning för omsändningar:

  • Total omsändningsperiod: 12 minuter

  • Antal omsändningar under perioden: 4

Mottagna asynkrona felmeddelanden vidarebefordras till adresserad användarorganisations Meddelandetjänst.

  • Se Specifikation av validering, felhantering och kvittens (Ref B1) för regler och rekommendationer kring omsändning och svarstidsbevakning.

2.2 Meddelandetjänst

Följande generella SLA-krav gäller för alla Meddelandetjänster som är anslutna till infrastrukturen för SDK.

Kategori

Värde

Beskrivning

Kommentar

Svarstid

15 min

Tiden för mottagande Meddelandetjänst (meddelandeväxel) att skicka meddelandekvittens

Svarstidskravet ska vara högre än omsändningsperioden i underliggande Accesspunkt (AP). Om svarstiden är lägre kan det uppstå situationer där Meddelandetjänst (MT) forcerar Accesspunkten att hantera flera parallella omsändningsperioder av samma ursprungsmeddelande.

En kortare svarstid ställer högre krav på systemlösningen, vilket i sin tur ökar kostnaden för drift.

Meddelanden köas upp i gränssnittet mellan AP och MT, vilket är största anledningen till att meddelandekvittens tillåts dröja med flera minuter.

Hänsyn behöver också tas till schema- och schematronvalidering på större meddelanden med bilagor.

I verksamhetssystemet (Meddelandeklienten) är det viktigt att vara tydlig med att meddelandet är i state “SKICKAT”, för att inte ge användaren en förväntan om att vänta in meddelandekvittensen.

Ett lägre värde (t.ex. 1 min) innebär att verksamheten kan vänta in svar (troligen acceptabel fördröjning).

Ett högre värde innebär att sändande sida får vänta ytterligare tid på meddelandekvittens med besked om meddelandet accepterats eller ej.

Tillgänglighet

24x7, 99,5%

Meddelandetjänsten ska vara uppe oavsett om det är inom eller utanför verksamhetens kontorstid, så att det finns möjlighet att ta emot och eventuellt lagra inkommande meddelanden från andra användarorganisationer.

Om Meddelandetjänsten positioneras som meddelandeväxel är det troligt att Meddelandetjänsten inte används som lagringsplats. I det fallet kommer Meddelandeklienten behöva ha samma tillgänglighetskrav som Meddelandetjänsten.

Kapacitet (mottagare)

Kapacitetetskrav är uppfyllda så länge 99,5% av mottagna meddelanden kan kvitteras inom SLA för svarstid

Kravet innebär att oavsett storlek på organisationen så behöver användarorganisationen säkerställa att Meddelandetjänsten kan hantera inkommande trafik enligt SLA-krav.

Det här ställer också krav på att andra användarorganisationer inom SDK-federationen är tydliga med vilka behov verksamheten har av att skicka trafik.

2.3 Meddelandeklient

Följande generella SLA-krav gäller för alla Meddelandeklienter som är anslutna till infrastrukturen för SDK.

Kategori

Värde

Beskrivning

Kommentar

Tillgänglighet

24x7, 99,5%

Meddelandeklienten ska vara uppe oavsett om det är inom eller utanför verksamhetens kontorstid, så att det finns möjlighet att ta emot och lagra inkommande meddelanden.

Notera att SLA-kravet avser lagring i Meddelandeklientens funktionsbrevlåda och inte verksamhetens tillgänglighet. Meddelandeklienten måste alltid lagra meddelandet direkt, verksamheten kommer däremot behandla meddelanden enligt användarorganisationens rutiner och ev. svarstidskrav.