...

Revisionshistorik

...

Detta dokument innehåller testinstruktioner för användarorganisationer som ska genomföra anslutningstester i SDK Testbädd (QA). Anslutningstesterna utgör underlag för ifyllnad av SDK Självdeklaration i enlighet med SDK Anslutningsprocess (se ref. R1).

...

1. Inledning

Detta dokument innehåller testinstruktioner för användarorganisationer som ska genomföra anslutningstester i SDK Testbädd (QA). Anslutningstesterna utgör underlag för ifyllnad av SDK Självdeklaration i enlighet med SDK Anslutningsprocess (se ref. R1).

Testinstruktionen förutsätter att användarorganisationens tjänst är ansluten till SDK Testbädd (QA) och att användarorganisationen har access till SDK Adressbok (se ref. R2) och SDK Testklient (se ref. R5).

...

1.1.1 Stödjande externa dokument

2. Testdata

2.1 Användarorganisationen i SDK Adressbok

...

Följande ska konfigureras upp i SDK Adressbok för att kunna genomföra anslutningstester (sedan finns många fler frivilliga fält där användarorganisationen styr hur dessa fylls i för att kunna genomföra verksamhetslika tester):

2.2 Inera i SDK Adressbok

...

En organisation som är upplagd i SDK Adressbok och som huvudsakligen används under testerna.

2.2.2 SDK Testbädd - Organisation#2 (ej kontaktbar)

En organisation som är upplagd i SDK Adressbok, men som är okontaktbar. Den EndpointURI som är kopplad till organisationen i SMP pekar på en felaktig URI.

2.2.3 SDK Testbädd - Organisation#3 (utgånget O2O-certifikat)

En organisation som är upplagd i SDK Adressbok, med ett publikt O2O-certifikatet i SMP som är utgånget.

2.2.4 SDK Testbädd - Organisation#4 (felaktigt AS4-certifikat)

En organisation som är upplagd i SDK Adressbok, med ett felaktigt AS4-certifikat i accesspunkten. Den EndpointURI som är kopplad till organisationen i SMP pekar mot en testaccesspunkt med ett AS4-certifikat för fel federation och som är utgånget.

2.2.5 SDK Testbädd - Organisation#5 (utgånget TLS-certifikat)

En organisation som är upplagd i SDK Adressbok, med ett utgånget TLS-certifikat på transportlagernivå. Den EndpointURI som är kopplad till organisationen i SMP pekar mot en extern server (http://expired.badssl.com ).

2.2.6 SDK Testbädd - Organisation#6 (felaktig CA i TLS-certifikat)

En organisation som är upplagd i SDK Adressbok, med ett TLS-certifikat med felaktig CA på transportlagernivå. Den EndpointURI som är kopplad till organisationen i SMP pekar mot en extern server (untrusted.badssl.com ).

3 Integrationstest

Anslutningstesterna består av integrationstester som genomförs innan systemtesterna. 

...

• Användarorganisationens AP-operatörs accesspunkt är ansluten till DIGGs SDK-QA

• Användarorganisationens AP-operatörs accesspunkt är följsam till DIGGs specifikationer (se ref. R8):

  • eDelivery - Kuverteringsprofil XHE

  • eDelivery - Transportmodell - Utökad Bas

  • eDelivery - Meddelandespecifikation - Meddelandekvittens

• Användarorganisationen är konfigurerad som deltagare i SMP (av användarorganisationens AP-operatör)

• Användarorganisationen har skickat in SDK anslutningsblankett till Inera för anslutning till SDK Testbädd (QA) (se ref. R1).

• Användarorganisationen har fått användare med rollen som organisationsadministratör och med behörighet till den egna användarorganisationen i SDK Adressbok
  (gör det möjligt för användarorganisationen att själva redigera organisationsuppgifter och registrera funktionsadresser under den egna användarorganisationen)

• Användarorganisationen har fått användare till SDK Testklient (se ref. R5)
  (gör det möjligt att skicka och ta emot meddelanden och meddelandekvittenser)

• Användarorganisationen har registrerat funktionsadresser för den egna användarorganisationen i SDK Adressbok (se ref. R2).

3.

...

2 Meddelandetjänst (meddelandelagret)

TF 2.0.1 - INTEGRATIONSTEST - Meddelandetjänsten tar del av meddelande från SDK Testklient

...

1. Skicka ett meddelande från SDK Testklient adresserat till en funktion i den egna användarorganisationen.

2. Användarorganisationens meddelandetjänst validerar meddelandet och genererar en meddelandekvittens automatiskt.

3. Meddelandeklienten tar del av meddelandet på ett korrekt sätt

4. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

5. Kontrollera att SDK Testklient tagit emot en meddelandekvittens

Kommentar

Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

Användarorganisationens meddelandetjänst förväntas validera utgående meddelandekvittenser.
SDK Testklient - Anslutningstest ‘TF 2.0.1 Normalt meddelande’

TF 2.0.2 - INTEGRATIONSTEST - Meddelandetjänsten skickar meddelande till SDK Testklient

...

Kontrollera att meddelandeklienten kan skicka meddelande via användarorganisationens meddelandetjänst till SDK Testklient och att att paketering av meddelandet genomförs på ett korrekt sätt.

...

Här har användarorganisationen stor frihet att bygga upp meddelanden på olika sätt som de skickar för att kunna forcera andra beteenden är det normala (utforskande testning).

3.

...

3 Meddelandeklient (verksamhetslagret)

TF 3.0.1 - INTEGRATIONSTEST - Meddelandeklienten tar del av meddelande från SDK Testklient

...

Kontrollera hur användarorganisationens meddelandeklienten meddelandeklient hanterar ett inkommande meddelande som är adresserat till en funktion i den egna användarorganisationen.

...

• Integrationstester genomförda för de lager som ska systemtestas.

4.

...

2 Meddelandetjänst (meddelandelagret)

TF 2.1.1 - Meddelandetjänsten tar del av meddelande från SDK Testklient (minimal)

...

1. Från SDK Testklient, skicka ett meddelande (minimal) adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

3. Meddelandeklienten tar del av meddelandet på ett korrekt sätt

4. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

5. Kontrollera att SDK Testklient tagit emot en meddelandekvittens

KommentarSDK

Testklient - Anslutningstest ‘TF 2.1.1 Inga frivilliga fält’Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.1.2 - Meddelandetjänsten tar del av meddelande från SDK Testklient (maximal)

...

1. Från SDK Testklient, skicka ett meddelande (maximal, små bilagor) adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

3. Meddelandeklienten tar del av meddelandet på ett korrekt sätt

4. Kontrollera att innehållet stämmer överens med vad som angivits i SDK Testklient

5. Kontrollera att SDK Testklient tagit emot en meddelandekvittens

Kommentar

Testfallet finns automatiserat i SDK Testklient - Anslutningstest ‘TF 2.1.3 Samtliga frivilliga fält’(skickar meddelande, kontrollerar meddelandekvittens).

TF 2.2.1 - Mottaget meddelande innehåller okänd referens till meddelande

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där 'RefToMessageId' refererar till ett meddelande ('messageId') som inte finns.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med 'Kvittenskod' ACCEPTED

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarSDK

Testklient - Anslutningstest ‘TF 2.2.1 Okänd referens till meddelande’Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.3.1 - Meddelande som ska skickas överskrider storleksbegränsning

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med felaktig datatyp i meddelandestrukturen.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

   2. Orsakskod: SV

   3. Detaljkod: structure

   4. Detaljtext: <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarSDK

Testklient - Anslutningstest ‘TF 2.4.1 Felaktig datatyp i meddelandestrukturen’Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.4.2 - Felhantering - Schematronvalidering på mottaget meddelande innehåller felaktigt kodverk för elementet 'senderId'

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där felaktigt kodverk används för 'senderId'.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. 'Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: invariant

      Detaljtext: <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarSDK

Testklient - Anslutningstest ‘TF 2.4.2 Felaktigt kodverk för elementet senderId’Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.4.3 - Felhantering - Schemavalidering på mottaget meddelande som innehåller felaktig datatyp i XHE

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med felaktig datatyp i XHE.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

   2. Orsakskod: SV

   3. Detaljkod: structure

   4. Detaljtext: <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarSDK

Testklient - Anslutningstest ‘TF 2.4.3 Felaktig datatyp i XHE’Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.4.4 - Felhantering - Mottagna meddelandets identitet är ej unikt

...

Kontrollera att användarorganisationens meddelandetjänst kan returnera REJECTED om ett mottaget meddelande i meddelandelagret inte är unikt ('messageId').

Teststeg

1. Förberedande: Från SDK Testklient, skicka Skicka ett meddelande adresserat till en funktion i den egna användarorganisationen och kontrollera att meddelandet hanteras korrekt

2. Från SDK Testklient, skicka Skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där 'messageId' är identiskt med tidigare meddelande

3. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: multiple-matches

      Detaljtext: <beskrivning av problemet>

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast SDK Testklient saknar stöd, lämpligast att utföra som en del av interna utvecklingstester.

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med felaktig funktionsadress (funktionsadressen är inte upplagd i SDK Adressbok)

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: not-found

      Detaljtext: <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarSDK

Testklient - Anslutningstest ‘TF 2.4.5 Felaktig funktionsadress’Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.4.6 - Felhantering - Mottaget meddelande kan inte dirigeras vidare

...

1. Förberedande: Säkerställ att meddelandeklienten inte är nåbar från användarorganisationens meddelandetjänst

2. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med funktionsadress som pekar på den ej nåbara meddelandeklienten

3. Användarorganisationens meddelandetjänst hanterar meddelandet på ett korrekt och förväntat sätt (beteende kan skilja sig åt mellan olika lösningar av MT beroende på hur och om meddelandet läggs i kö)Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

   Om meddelandekvittensen köas upp:
   Kvittenskod

   (kvittenskod: ACCEPTED

4. Annars:
   Kvittenskod: REJECTED

   Orsakskod: BV

   Detaljkod: exception

   Detaljtext: <beskrivning av problemet>

)

5. Användarorganisationens meddelandetjänst buffrar meddelandet i gränssnittet mot meddelandeklienten

6. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

7. Återställ: Återanslut meddelandeklienten till användarorganisationens meddelandetjänst 

8. Kontrollera loggar (om meddelandet buffrades, tar meddelandeklienten och att meddelandeklienten tar del av det tidigare buffrade meddelandet på ett korrekt sätt)

Kommentar

...

TF 2.4.8 - Felhantering - Mottaget meddelande överskrider storleksbegränsning

...

1. Från SDK Testklient, skicka ett SDK-meddelande adresserat till en funktion i den egna användarorganisationen där avsändande part i XHE-delen av meddelandet förändrats så att det inte överensstämmer med originalSender i AS4-delen av meddelandet.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV

      Detaljkod: security

      Detaljtext: Wrong or unknown sender-id <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarLämpligast att utföra som en del av interna utvecklingstester

Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.5.1 - Felhantering - Utgående meddelande kan inte skickas till deltagare med otillgänglig

...

accesspunkt

Syfte

Kontrollera att användarorganisationens meddelandetjänst hanterar meddelande som skickas till en okontaktbar organisation på ett korrekt sätt.

...

Se ref. R9 (Spåra och övervaka på meddelandenivå - REJECTED)
Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.2 - Felhantering - Meddelandekvittens REJECTED (maximal)

...

Se ref. R9 (Spåra och övervaka på meddelandenivå - REJECTED)Lämpligast att utföra som en del av interna utvecklingstester.

TF 2TF 2.6.3 - Felhantering - Meddelandekvittens saknas

...

Se ref. R9 (Spåra och övervaka på meddelandenivå - MESSAGE_EXCHANGE_ERROR)Lämpligast att utföra som en del av interna utvecklingstester.

TF 2.6.4 - Felhantering - Signatur på inkommande meddelande kan inte verifieras på grund av att cert-pub inte kan nås

...

Kontrollera felhanteringen i användarorganisations meddelandetjänst när publikt certifikat inte kan hämtas ifrån cert-pub tjänst

Teststeg

1. Förberedande: Konfigurera meddelandetjänstens SML zone för cert-pub tjänst till en onåbar URL.

2. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen.

3. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: SIG

      Detaljkod: security

      Detaljtext: Sender signature not validated, public key not found / cert-pub unreachable <beskrivning av problemet>

4. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

...

1. Återställ: Konfigurera meddelandetjänstens SML zone för cert-pub tjänst till korrekt URL

TF 2.6.5 - Felhantering - Signering på inkommande meddelande stämmer inte med publik nyckel

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen där signaturen inte är korrekt.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: SIG

      Detaljkod: security

      Detaljtext: Sender signature not validated <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarLämpligast att utföra som en del av interna utvecklingstester.

Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.6.6 - Felhantering av inkommande krypterat meddelande där meddelande inte kan dekrypteras:

...

Kontrollera felhanteringen i användarorganisations meddelandetjänst när meddelandets nyttolast är krypterat på ett sätt som gör att mottagaren inte kan dekryptera det på förväntat sätt

Teststeg

1. Från SDK Testklient, skicka Skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med en SDK payload som är förvanskad efter kryptering men signerad på ett korrekt sätt.

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   Kvittenskod: REJECTED

   Orsakskod: BV

   Detaljkod: security

   Detaljtext: Message could not be decrypted

   ska inte generera meddelandekvittens, vilket resulterar i en timeout i SDK Testklient

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

Kommentar

Lämpligast SDK Testklient saknar stöd, lämpligast att utföra som en del av interna utvecklingstester.

...

1. Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen med en SDK payload som är okrypterad och XHE attributet InstanceEncryptionIndicator satt till false

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt med:

   1. Kvittenskod: REJECTED

      Orsakskod: BV eller SIG

      Detaljkod: security

      Detaljtext: Unencrypted message not allowed <beskrivning av problemet>

3. Kontrollera att loggarna stämmer och är följsamma till SDKs krav på spårbarhet (se ref. R4)

KommentarLämpligast att utföra som en del av interna utvecklingstester

Testfallet finns automatiserat i SDK Testklient (skickar meddelande, kontrollerar meddelandekvittens).

TF 2.7.1 - Felhantering - Utgående meddelande kan inte skickas till deltagare med utgånget O2O-certifikat

...

Se ref. R9 (Spåra och övervaka på meddelandenivå - MESSAGE_EXCHANGE_ERROR)

4.

...

3 Meddelandeklient (verksamhetslagret)

TF 3.1.1 - Meddelandeklienten tar del av meddelande från SDK Testklient (minimal)

...

1. Från SDK Testklient, skicka ett meddelande (fråga) adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt.

3. Användare av meddelandeklienten tar del av mottaget meddelandet på ett korrekt sätt

4. Användare av meddelandeklienten besvarar mottaget meddelande ('conversionId' hämtas från mottaget meddelande)

5. SDK Testklient tar emot svaret, kontrollerar 'conversationId' och skickar en meddelandekvittens

6. Kontrollera i SDK Testklient att skickade frågan och mottagna svaret presenteras i samma konversion

7. Kontrollera att meddelandeklienten tagit emot en meddelandekvittens på det skickade svaret

...

Kommentar

Testfallet finns automatiserat i SDK Testklient (skickar meddelande (1), kontrollerar meddelandekvittens(2), kontrollerar svar (5 och 6), samt skickar meddelandekvittens på svar (7)). Användaren behöver i steg 4 skicka ett svar på meddelandet som skickades i steg 1 från egen systemlösning.

TF 3.2.2 - Meddelandeklienten tar del av besvarat meddelande

...

1. Från SDK Testklient, skicka ett meddelande (fråga) adresserat till en funktion i den egna användarorganisationen

2. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt

3. Från SDK Testklient, komplettera genom att använda komplettera-funktionen på det tidigare skickade meddelande i SDK Testklient

4. Användarorganisationens meddelandetjänst genererar en meddelandekvittens automatiskt på den mottagna kompletteringen

5. Användare av meddelandeklienten tar del av kompletteringen på ett korrekt sätt

6. Kontrollera i meddelandeklienten att mottagna frågan och mottagna kompletteringen presenteras i samma konversion

7. Kontrollera att SDK Testklient tagit emot en meddelandekvittens på den skickade kompletteringen

5 Systemtest - SDK API

Om systemlösningen har stöd för SDK API (se ref. 10) ska anslutningstesterna även inkludera tester som berör SDK API.

Det förutsätter att stöd för SDK API har implementerats i meddelandetjänsten och meddelandeklienten för att testerna ska kunna genomföras.

5.1 Förutsättningar

• Integrationstester genomförda för de lager som ska systemtestas

• Meddelandeklient(er) och meddelandetjänst är uppsatt att kommunicera genom SDK API

5.2 Meddelandetjänst (producent av SDK API)

TF 4.0.1 - Meddelandetjänsten hanterar inkommande meddelande

Syfte

Kontrollera att meddelandetjänstens SDK API hanterar ett inkommande meddelande enligt SDK API (se ref. R10).

Teststeg

1. Förberedande: Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen

2. Meddelandeklienten hämtar lista på nya mottagna meddelanden (filter[messagestatus]=NEW)

   1. Meddelandetjänsten returnerar lista på meddelanden i status NEW (ett meddelandeId) i respons (200 OK)

3. Meddelandeklienten hämtar meddelande per id

   1. Meddelandetjänsten returnerar meddelande i respons (200 ACCEPTED)

4. Meddelandeklienten raderar meddelande i meddelandetjänsten

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.0.2 - Meddelandetjänsten hanterar utgående meddelande

Syfte

Kontrollera att meddelandetjänstens SDK API hanterar ett utgående meddelande enligt SDK API (se ref. R10).

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till SDK Testklient, samt returnerar respons (201 CREATED)

   2. Kontrollera meddelandet i SDK Testklient

2. Meddelandeklienten hämtar status på meddelandeper id

   1. Meddelandetjänsten returnerar status (ACCEPTED) i respons (200 OK)

3. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.1.1 - Meddelandetjänsten hanterar utgående meddelande - minimalt innehåll

Syfte

Kontrollera att meddelandetjänstens SDK API hanterar och skickar ett minimalt meddelande enligt SDK API (se ref. R10).

Element som inte inkluderas:

• refToMessageId

• generatingSystem

• …/subOrganization/label

• …/person/label

• …/reference/label

• label (rubrik)

• contentText (däremot är contentFiles inkluderat)

Teststeg

1. Meddelandeklienten skickar ett meddelande där inga optionella fält används till SDK Testklient

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till SDK Testklient, samt returnerar respons (201 CREATED)

   2. Kontrollera meddelandet i SDK Testklient

2. Meddelandeklienten hämtar status på meddelande per id

   1. Meddelandetjänsten returnerar status (ACCEPTED) i respons (200 OK)

3. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.1.2 - Meddelandetjänsten hanterar utgående meddelande - maximalt innehåll

Syfte

Kontrollera att meddelandetjänstens SDK API hanterar och skickar ett maximalt meddelande enligt SDK API (se ref. R10).

Element som inkluderas:

• refToMessageId

• generatingSystem

• …/subOrganization/label

• …/person/label

• …/reference/label

• label (rubrik)

• Flera contentText element

• Flera contentFiles element

Teststeg

1. Meddelandeklienten skickar ett meddelande där samtliga optionella fält används till SDK Testklient

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till SDK Testklient, samt returnerar respons (201 CREATED)

   2. Kontrollera meddelandet i SDK Testklient

2. Meddelandeklienten hämtar status på meddelande per id

   1. Meddelandetjänsten returnerar status (ACCEPTED) i respons (200 OK)

3. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.2.1 - Behörighetshantering - hantera lista

Syfte

Kontrollera behörighetshanteringen i meddelandetjänstens SDK API för att hantera trafik mot flera meddelandeklienter enligt SDK API (se ref. R10) och där en meddelandeklient begär lista på meddelanden som meddelandeklienten behöver hämta.

Testfallet förutsätter att tre meddelandeklienter ansluts till meddelandetjänsten med funktionsadresser enligt nedan:

• mk1 (fa1)

• mk2 (fa2)

• mk3 (fa3, fa4, fa5)

Teststeg

1. Förberedande: Skicka meddelanden från SDK Testklient adresserat till funktioner i den egna användarorganisationen enligt nedan:

   1. mk1 (fa1) - 1 meddelande

   2. mk2 (fa2) - 3 meddelanden

   3. mk3 (fa3) - 1 meddelande

   4. mk3 (fa4) - 2 meddelanden

   5. mk3 (fa5) - 3 meddelanden

2. Förberedande: Skicka meddelanden från funktioner i den egna användarorganisationen till SDK Testklient enligt nedan:

   1. mk1 (fa1) - 1 meddelande

   2. mk2 (fa2) - 3 meddelanden

   3. mk3 (fa3) - 1 meddelande

   4. mk3 (fa4) - 2 meddelanden

   5. mk3 (fa5) - 3 meddelanden

3. Meddelandeklient (mk1) hämtar lista på nya mottagna meddelanden (filter[messagestatus]=NEW)

   1. Meddelandetjänsten returnerar lista på meddelanden i status NEW (ett meddelandeId) i respons (200 OK)

4. Meddelandeklient (mk1) hämtar mottaget meddelande per id

   1. Meddelandetjänsten returnerar meddelande i respons (200 OK)

5. Meddelandeklient (mk1) raderar mottaget meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

6. Meddelandeklient (mk1) hämtar lista på accepterade meddelanden (filter[messagestatus]=ACCEPTED)

   1. Meddelandetjänsten returnerar lista på meddelanden (ett meddelandeId) i respons (200 OK)

7. Meddelandeklient (mk1) raderar skickat meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

Kommentar

För info: SDK Testklient i SDK ÖTM har ett begränsat stöd för behörighetshantering där respektive meddelandeklient har endast en(1) funktionsadress.

TF 4.2.2 - Behörighetshantering - hantera lista med filter

Syfte

Kontrollera behörighetshanteringen i meddelandetjänstens SDK API för att hantera samtidig trafik mot flera meddelandeklienter enligt SDK API (se ref. R10) och där en meddelandeklient begär lista för aktuell dag på meddelanden som meddelandeklienten hanterat eller förväntas hantera.

Teststeg

1. Förberedande: TF 4.2.1

2. Meddelandeklient (mk2) hämtar lista på meddelanden som hanterats under dagen (filter[creationDateTimeStart]=<dagens datum>00:00, filter[creationDateTimeStop]=<dagens datum><aktuell tid>)

   1. Meddelandetjänsten returnerar lista på meddelanden utifrån filter på datum (sex meddelandeId) i respons (200 OK)

      1. 3 meddelanden i status NEW

      2. 3 meddelanden i status ACCEPTED

3. Meddelandeklient (mk2) hämtar mottagna meddelanden per id

   1. Meddelandetjänsten returnerar för varje anrop mottaget meddelande i respons (200 OK)

4. Meddelandeklient (mk2) raderar mottagna meddelanden per id

   1. Meddelandetjänsten raderar för varje anrop mottaget meddelande och returnerar respons (202 ACCEPTED)

5. Meddelandeklient (mk2) raderar skickade meddelanden per id

   1. Meddelandetjänsten raderar för varje anrop skickat meddelande och returnerar respons (202 ACCEPTED)

Kommentar

För info: SDK Testklient i SDK ÖTM har ett begränsat stöd för behörighetshantering där respektive meddelandeklient har endast en (1) funktionsadress.

TF 4.2.3 - Behörighetshantering - hantera lista för flera funktionsadresser

Syfte

Kontrollera behörighetshanteringen i meddelandetjänstens SDK API för att hantera samtidig trafik mot flera meddelandeklienter enligt SDK API (se ref. R10) och där en meddelandeklient (med flera funktionsadresser) begär lista på meddelanden som meddelandeklienten behöver hämta.

Teststeg

1. Förberedande: TF 4.2.2

2. Meddelandeklient (mk3) hämtar lista på nya mottagna meddelanden (filter[messagestatus]=NEW])

   1. Meddelandetjänsten returnerar lista på meddelanden i status NEW (sex meddelandeId) i respons (200 OK)

      1. 1 meddelande till mk3 (fa3)

      2. 2 meddelanden till mk3 (fa4)

      3. 3 meddelanden till mk3 (fa5)

3. Meddelandeklient (mk3) hämtar mottagna meddelanden per id

   1. Meddelandetjänsten returnerar för varje anrop mottaget meddelande i respons (200 OK)

4. Meddelandeklient (mk3) raderar mottagna meddelanden per id

   1. Meddelandetjänsten raderar för varje anrop mottaget meddelande och returnerar respons (202 ACCEPTED)

Kommentar

För info: SDK Testklient i SDK ÖTM har ett begränsat stöd för behörighetshantering där respektive meddelandeklient har endast en (1) funktionsadress.

TF 4.2.4 - Behörighetshantering - hantera lista för specifik funktionsadress

Syfte

Kontrollera behörighetshanteringen i meddelandetjänstens SDK API för att hantera samtidig trafik mot flera meddelandeklienter enligt SDK API (se ref. R10) och där en meddelandeklient (med flera funktionsadresser) begär lista på meddelanden som meddelandeklienten hanterat eller förväntas hantera för en specifik funktionsadress.

Teststeg

1. Förberedande: TF 4.2.3

2. Meddelandeklient (mk3) hämtar lista på meddelanden som hanteras av funktionsadress ‘fa4’ (filter[recipientAttention.subOrganization.extension]=fa4])

   1. Meddelandetjänsten returnerar lista på meddelanden utifrån filter på funktionsadress (två meddelandeId) i respons (200 OK)

      1. 2 meddelanden från mk3 (fa4)

3. Meddelandeklient (mk3) hämtar meddelanden per id

   1. Meddelandetjänsten returnerar för varje anrop meddelande i respons (200 OK)

4. Meddelandeklient (mk3) raderar meddelanden per id

   1. Meddelandetjänsten raderar för varje anrop meddelande och returnerar respons (202 ACCEPTED)

5. Meddelandeklient (mk3) hämtar lista på accepterade meddelanden (filter[messagestatus]=ACCEPTED])

   1. Meddelandetjänsten returnerar lista på meddelanden i status ACCEPTED (fyra meddelandeId) i respons (200 OK)

      1. 1 meddelande från mk3 (fa3)

      2. 3 meddelanden från mk3 (fa5)

6. Meddelandeklient (mk3) hämtar meddelanden per id

   1. Meddelandetjänsten returnerar för varje anrop meddelande i respons (200 OK)

7. Meddelandeklienten raderar meddelanden per id

   1. Meddelandetjänsten raderar för varje anrop meddelande och returnerar respons (202 ACCEPTED)

Kommentar

För info: SDK Testklient i SDK ÖTM har ett begränsat stöd för behörighetshantering där respektive meddelandeklient har endast en (1) funktionsadress.

TF 4.3.1 - Statushantering - meddelandekvittens saknas

Syfte

Kontrollera meddelandetjänstens statushantering per id och baserat på filter i SDK API (se ref. R10) för ett utgående meddelande där meddelandekvittens uteblir.

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient (organisation ‘SDK Testbädd - Inera AB’, Funktionsnamn#3)

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till SDK Testklient, samt returnerar respons (201 CREATED)

2. Meddelandetjänsten hämtar meddelande per id

   1. Meddelandetjänsten returnerar status WAITING_FOR_RECEIPT tillsammans med meddelande

3. Meddelandeklienten hämtar lista på meddelanden som saknar meddelandekvittens (filter[messagestatus]=WAITING_FOR_RECEIPT)

   1. Meddelandetjänsten returnerar lista på meddelanden i status WAITING_FOR_RECEIPT (ett meddelandeId) i respons (200 OK)

4. Meddelandeklienten hämtar lista på utgående meddelanden som inte levererats (filter[messagestatus]=MESSAGE_EXCHANGE_ERROR)

   1. Meddelandetjänsten returnerar lista på meddelanden i status MESSAGE_EXCHANGE_ERROR (tom lista) i respons (200 OK)

5. Meddelandetjänsten får timeout på meddelandekvittens

6. Meddelandetjänsten hämtar meddelande per id

   1. Meddelandetjänsten returnerar status MESSAGE_EXCHANGE_ERROR tillsammans med meddelande

7. Meddelandeklienten hämtar lista på meddelanden som saknar meddelandekvittens (filter[messagestatus]=WAITING_FOR_RECEIPT)

   1. Meddelandetjänsten returnerar lista på meddelanden i status WAITING_FOR_RECEIPT (tom lista) i respons (200 OK)

8. Meddelandeklienten hämtar lista på utgående meddelanden som inte levererats (filter[messagestatus]=MESSAGE_EXCHANGE_ERROR)

   1. Meddelandetjänsten returnerar lista på meddelanden i status MESSAGE_EXCHANGE_ERROR (ett meddelandeId) i respons (200 OK)

9. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.3.2 - Statushantering - transportkvittens saknas

Syfte

Kontrollera meddelandetjänstens statushantering i SDK API (se ref. R10) för ett utgående meddelande där transportkvittens uteblir.

Teststeg

1. Meddelandeklienten skickar meddelande till en okontaktbar organisation (Organisation#2)

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till okontaktbar organisation, samt returnerar respons (201 CREATED)

2. Meddelandetjänsten noterar timeout på transportkvittens

3. Meddelandeklienten hämtar lista på utgående meddelanden som inte levererats (filter[messagestatus]=MESSAGE_EXCHANGE_ERROR)

   1. Meddelandetjänsten returnerar lista på meddelanden i status MESSAGE_EXCHANGE_ERROR (ett meddelandeId) i respons (200 OK)

4. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.3.3 - Statushantering - meddelandet avvisat av mottagaren

Syfte

Kontrollera meddelandetjänstens statushantering i SDK API (se ref. R10) för ett utgående meddelande som avvisas av mottagaren (REJECTED).

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient (organisation ‘SDK Testbädd - Inera AB’, Funktionsnamn#1)

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till SDK Testklient, samt returnerar respons (201 CREATED)

2. Meddelandeklienten hämtar lista på utgående meddelanden som inte levererats (filter[messagestatus]=MESSAGE_EXCHANGE_ERROR)

   1. Meddelandetjänsten returnerar lista på meddelanden i status MESSAGE_EXCHANGE_ERROR (ett meddelandeId) i respons (200 OK)

3. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

TF 4.4.1 - Felhantering - utgående meddelande är felaktigt formaterat

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) för ett utgående meddelande som är felaktigt formaterat.

Teststeg

1. Meddelandeklienten skickar ett felaktigt formaterat meddelande där ‘messageStatus’ inkluderas med okänd statuskod (UNKNOWN)

   1. Meddelandetjänsten returnerar felmeddelande i respons (400 BAD REQUEST)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

TF 4.4.2 - Felhantering - begär meddelande som inte finns

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) där meddelandeklienten hämtar meddelande med okänt meddelandeId.

Teststeg

1. Meddelandeklienten hämtar okänt meddelande per id

   1. Meddelandetjänsten returnerar felmeddelande i respons (404 NOT FOUND)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

TF 4.4.3 - Felhantering - hantera mottaget meddelande där behörighet saknas

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) där meddelandeklienten försöker hantera mottaget meddelande (behörighet saknas) som ska hanteras av annan meddelandeklient.

Testfallet förutsätter att två meddelandeklienter ansluts till meddelandetjänsten med funktionsadresser enligt nedan:

• mk1 (fa1)

• mk2 (fa2)

Teststeg

1. Förberedande: Skicka meddelanden från SDK Testklient adresserat till funktion i den egna användarorganisationen enligt nedan:

   1. mk1 (fa1) - 1 meddelande

2. Förberedande: Notera meddelandeId på mottaget meddelande i meddelandetjänsten

3. Meddelandeklient (mk2) hämtar meddelande per id (messageId=<meddelandeId från steg 2>)

   1. Meddelandetjänsten returnerar felmeddelande i respons (401 UNAUTHORIZED)

4. Meddelandeklient (mk2) raderar meddelande per id (messageId=<meddelandeId från steg 2>)

   1. Meddelandetjänsten returnerar felmeddelande i respons (401 UNAUTHORIZED)

5. Meddelandeklient (mk1) hämtar lista på nya mottagna meddelanden (filter[messagestatus]=NEW])

   1. Meddelandetjänsten returnerar lista på meddelanden i status NEW (ett meddelandeId) i respons (200 OK)

6. Meddelandeklient (mk1) hämtar mottaget meddelanden per id

   1. Meddelandetjänsten returnerar mottaget meddelande i respons (200 OK)

7. Meddelandeklient (mk1) raderar mottaget meddelande per id

   1. Meddelandetjänsten raderar mottaget meddelande och returnerar respons (202 ACCEPTED)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

TF 4.4.4 - Felhantering - hantera utgående meddelande där behörighet saknas

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) där meddelandeklienten försöker hantera utgående meddelande (behörighet saknas) som hanteras av annan meddelandeklient.

Testfallet förutsätter att två meddelandeklienter ansluts till meddelandetjänsten med funktionsadresser enligt nedan:

• mk1 (fa1)

• mk2 (fa2)

Teststeg

1. Förberedande: Skicka meddelanden från funktion i den egna användarorganisationen till SDK Testklient enligt nedan:

   1. mk1 (fa1) - 1 meddelande

2. Förberedande: Notera meddelandeId på skickat meddelande i meddelandetjänsten

3. Meddelandeklient (mk2) raderar meddelande per id (messageId=<meddelandeId från steg 2>)

   1. Meddelandetjänsten returnerar felmeddelande i respons (401 UNAUTHORIZED)

4. Meddelandeklient (mk1) hämtar lista på accepterade meddelanden (filter[messagestatus]=ACCEPTED])

   1. Meddelandetjänsten returnerar lista på meddelanden i status ACCEPTED (ett meddelandeId) i respons (200 OK)

5. Meddelandeklient (mk1) raderar skickat meddelande per id

   1. Meddelandetjänsten raderar mottaget meddelande och returnerar respons (202 ACCEPTED)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

TF 4.4.5 - Felhantering - radera meddelande som inte finns

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) där meddelandeklienten raderar meddelande med okänt meddelandeId,

Teststeg

1. Meddelandeklienten raderar meddelande per id (messageId=<unknown>)

   1. Meddelandetjänsten returnerar felmeddelande i respons (404 NOT FOUND)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

TF 4.4.6 - Felhantering - radera meddelande som inte är i slutlig status

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) där meddelandeklienten raderar meddelande som ännu inte är i slutlig status.

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient (organisation ‘SDK Testbädd - Inera AB’, Funktionsnamn#3)

   1. Meddelandetjänsten tar del av meddelandet och skickar det vidare till SDK Testklient, samt returnerar respons (201 CREATED)

2. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten returnerar felmeddelande (401 UNAUTHORIZED)

3. Meddelandetjänsten får timeout på meddelandekvittens

4. Meddelandeklienten raderar meddelande per id

   1. Meddelandetjänsten raderar meddelandet och returnerar respons (202 ACCEPTED)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

TF 4.4.7 - Felhantering - utgående meddelande är felaktigt adresserat utifrån behörighet

Syfte

Kontrollera meddelandetjänstens felhantering i SDK API (se ref. R10) för ett utgående meddelande som är felaktigt i förhållande till vad konsumenten har behörighet till.

Teststeg

1. Meddelandeklienten skickar ett felaktigt formaterat meddelande där utifrån behörighetsstyrning ‘sender’ och/eller ‘senderAttention/subOrganization/extension’ inte stämmer överens med den auktoriserade konsumentens behörighetstyrande attribut (‘auth_id’)

   1. Meddelandetjänsten returnerar felmeddelande i respons (400 BAD REQUEST)

Kommentar

Genomförs förslagsvis som del av interna utvecklingstester

5.2 Meddelandeklient (konsument av SDK API)

TF 5.0.1 - Meddelandeklienten hanterar mottaget meddelande

Syfte

Kontrollera att meddelandeklienten hanterar ett inkommande meddelande enligt SDK API (se ref. R10).

Teststeg

1. Förberedande: Från SDK Testklient, skicka ett meddelande adresserat till en funktion i den egna användarorganisationen

2. Meddelandeklienten hämtar lista på mottagna meddelanden (filter[messagestatus]=NEW])

   1. Meddelandeklienten hanterar och presenterar listan på ett korrekt sätt (ett meddelandeId)

3. Meddelandeklienten hämtar meddelande per id

   1. Meddelandeklienten hanterar och presenterar meddelandet på ett korrekt sätt

4. Meddelandeklienten raderar meddelande per id

   1. Meddelandeklienten hanterar det raderade meddelandet på ett korrekt sätt

TF 5.0.2 - Meddelandeklienten hanterar utgående meddelande

Syfte

Kontrollera att meddelandeklienten hanterar ett utgående meddelande enligt SDK API (se ref. R10).

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient

   1. Meddelandeklienten hanterar och presenterar det skickade meddelandet på ett korrekt sätt

   2. Kontrollera meddelandet i SDK Testklient

2. Meddelandeklienten hämtar status på meddelande per id

   1. Meddelandeklienten hanterar och presenterar meddelandets status (ACCEPTED) på ett korrekt sätt

3. Meddelandeklienten raderar meddelande per id

   1. Meddelandeklienten hanterar det raderade meddelandet på ett korrekt sätt

TF 5.1.1 - Meddelandeklienten hanterar mottaget meddelande - minimalt

Syfte

Kontrollera att meddelandeklienten hanterar ett inkommande minimalt meddelande enligt SDK API (se ref. R10).

Element som inte inkluderas:

• refToMessageId

• generatingSystem

• …/subOrganization/label

• …/person/label

• …/reference/label

• label (rubrik)

• contentText (däremot är contentFiles inkluderat)

Teststeg

1. Förberedande: Från SDK Testklient, skicka ett minimalt meddelande adresserat till en funktion i den egna användarorganisationen

2. Meddelandeklienten hämtar lista på mottagna meddelanden (filter[messagestatus]=NEW])

   1. Meddelandeklienten hanterar och presenterar listan på ett korrekt sätt (ett meddelandeId)

3. Meddelandeklienten hämtar meddelande per id

   1. Meddelandeklienten hanterar och presenterar meddelandet på ett korrekt sätt

4. Meddelandeklienten raderar meddelande per id

   1. Meddelandeklienten hanterar det raderade meddelandet på ett korrekt sätt

TF 5.1.2 - Meddelandeklienten hanterar mottaget meddelande - maximalt

Syfte

Kontrollera att meddelandeklienten hanterar ett inkommande maximalt meddelande enligt SDK API (se ref. R10).

Element som inkluderas:

• refToMessageId

• generatingSystem

• …/subOrganization/label

• …/person/label

• …/reference/label

• label (rubrik)

• Flera contentText element

• Flera contentFiles element

Teststeg

1. Förberedande: Från SDK Testklient, skicka ett maximalt meddelande adresserat till en funktion i den egna användarorganisationen

2. Meddelandeklienten hämtar lista på mottagna meddelanden (filter[messagestatus]=NEW])

   1. Meddelandeklienten hanterar och presenterar listan med bilagor på ett korrekt sätt (ett meddelandeId)

3. Meddelandeklienten hämtar meddelande per id

   1. Meddelandeklienten hanterar och presenterar meddelandet på ett korrekt sätt

4. Meddelandeklienten raderar meddelande per id

   1. Meddelandeklienten hanterar det raderade meddelandet på ett korrekt sätt

TF 5.2.1 - Statushantering - meddelandekvittens saknas

Syfte

Kontrollera meddelandeklientens statushantering i SDK API (se ref. R10) för ett utgående meddelande där meddelandekvittens uteblir.

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient (organisation ‘SDK Testbädd - Inera AB’, Funktionsnamn#3)

2. Meddelandeklienten hämtar status på meddelande per id

   1. Meddelandeklienten hanterar och presenterar status (WAITING_FOR_RECEIPT) på ett korrekt sätt

3. Vänta in timeout på meddelandekvittens

4. Meddelandeklienten hämtar status på meddelande per id

   1. Meddelandeklienten hanterar och presenterar status (MESSAGE_EXCHANGE_ERROR) och felkoder på ett korrekt sätt

5. Meddelandeklienten raderar meddelande per id

   1. Meddelandeklienten hanterar det raderade meddelandet på ett korrekt sätt

TF 5.2.2 - Statushantering - meddelandekvittens avvisat av mottagaren

Syfte

Kontrollera meddelandeklientens statushantering i SDK API (se ref. R10) för ett utgående meddelande som avvisas av mottagaren (REJECTED).

Teststeg

1. Meddelandeklienten skickar meddelande till SDK Testklient (organisation ‘SDK Testbädd - Inera AB’, Funktionsnamn#1)

2. Meddelandeklienten hämtar status på meddelande per id

   1. Meddelandeklienten hanterar och presenterar status (MESSAGE_EXCHANGE_ERROR) och felkoder på ett korrekt sätt

3. Meddelandeklienten raderar meddelande per id

   1. Meddelandeklienten hanterar det raderade meddelandet på ett korrekt sätt