Jämförda versioner

Nyckel

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

...

Begrepp och förkortningar

Ord/förkortning

Förklaring

TAK / TAKning

TjänsteAdressKatalogen är en applikation för att styra NTjPs hantering av inkommande förfrågningar. TAKning är när man lägger till nya vägval och anropsbehörigheter.

Vägval

Sammanlänkning av ”logisk adress” (la) och ”tjänstekontrakt” (tk) i TAK som VP använder för att skicka ett anrop vidare till ”anropsadress” (aa), alla tre (la, tk och aa) behöver anges i ett vägval. Anrop som inkommer med en kombination av la och tk som inte matchas av ett vägval i TAK returnerar felkod VP004

Anropsbehörighet

Ger en anropande konsument behörighet till ett vägval. Anrop som görs mot ett vägval där behörighet saknas returnerar felkod VP007

Logisk adress

Ett namn, oftast HSA-id, som när det kopplas med en tjänsteproducent.

Anropsadress

En fysisk adress (URL) till en tjänst.

Tjänstekontrakt

En teknisk beskrivning av en tjänst, styr hur en fråga respektive ett svar skall utformas. Kontrakten delas in i olika domäner och får en namn som motsvaras av sitt SOAP-namnrymd. I TAK så är det *Responder-delen som anges.

Bakgrund och samband

För att kunna testa anslutningar inför en takning så tänkte vi ta fram en enkel webbapplikation för att testa att VP:n kan ansluta till anropsadresser i beställningar

...

Före bytet av skltp’s driftsmiljö så togs det fram en rutin för att kontrollelera kontrollera att inkomnna beställningar innehöll korrekta anropsadresser, detta utfördes med hjälp av curl (eller liknande cli-webbläsare) över en proxy som var uppsatt på respektive målmiljö. Nu när vi har en ny driftsmiljö så har möjligheten att göra en sån här verifiering tagits bort. Den är dessutom lite svår att förstå sig på för en som inte är van vid skal-kommandon.

...

Tanken är att man skall kunna besöka en webbapplikation och där få ett fält presenterat där man kan skriva in en eller flera URL:er som sedan skall anropas från en (eller flera) VP-nod, medelst curl eller liknande. Svaret presenteras sedan för användaren.

Funktionella Krav

KravID

Beskrivning

Funktionstyp

FK #1

Applikationen skall ha ett grafiskt gränssnitt i form av en webbapplikation.

GUI

FK #2

Gränssnittet skall ha ett fält för att ange en eller flera URL:er som skall testas. Man skall kunna klistra in en url per rad och anslutningetesterna skall sedan utföras och redovisas en och en.

GUI

FK #3

Samtliga funktioner skall kunna nås m.h.a ett rest-api. GUI:t kan med fördel använda rest-api:et. Detta ökar möjligheten att scripta uppgifter samt testa funktionaliteten i applikationen.

Tillgänglighet/
skalbarhet

FK #4

För att kunna använda rest-api:et (#3) så skall användaren kunna presentera någon form av token, cookie eller api-nyckel som bara kan erhållas genom inloggning.

Säkerhet / Spårbarhet

FK #5

Man skall kunna testa att göra anrop direkt mot en URL från vp-servern och få svaret från curl eller liknande tillbaka.

Grundläggande

FK #6

Anslutningarna skall göras från en på ett sånt sätt att den för de testade tjänsterna upplevs komma från tjänsteplattformen, dvs samma IP, certifikat, m.m. skall stämma med VP’ns för att kunna testa att denna maskinen verkligen kan nå angiven adress.

Grundläggande

FK #7

Det skall genereras någon form av log för testerna som görs där request och dess svar hamnar tillsammans med användarnamnet på utföraren. Loggen skall hanteras med ELK

Spårbarhet / Felsökning

FK #8

Det skall finnas en inloggning till verktyget där användare och lösenord matchas mot tak-databasens dito

Säkerhet / Spårbarhet

Backlog/Framtidsvisioner (Nice to have)

NR

Beskrivning

BL #1

Som användare vill jag ha möjlighet att testa en ”hel TAKning” genom att ange en logisk adress och ett tjänstekontraktsnamn, detta anrop görs med http-anrop mot vp där senderId, reciverId och kontrakt anges så som lastbalanserare/rev-proxy gör för inkommande anrop.
Syftet med detta skulle vara att undersöka att en nyss genomförd TAKning fungerar som den är tänkt. Funktionen är även användbar för att felsökning.

BL #2

Som användare skulle jag vilja få en lista över vägval att testa ovanstående TAKning genom, listan genereras från databasen. Man skall gärna kunna välja på om man vill sortera listan efter genomförandetidpunkt, anropsadress, logiska adress eller avsändarens tjänstekomponent (kräver att man även bakar in anropsbehörigheter). Det skall också gå att filtrera listan på samma kolumner. Detta skulle underlätta för vägvalstest eftersom man inte behöver plocka fram alla uppgifter för varje test. Man kan testa de tre senaste eller alla till eller från en viss vårdgivare.

BL #3

Som Användare vill jag kunna välja en eller flera anropsadresser att anslutningstesta från en lista som hämtas ur databasen, även (eller kanske i synnerhet) de som inte ännu är publicerade. Listan bör kunna sorteras och filteras på tjänstekomponent, adress eller genomförandetidpunkt.

BL #4

Som Användare av TAK-WEB-gränssnittet så skulle det vara fint att i granskningen en beställning kunna testa anslutningen till anropsadresser eller ett vägval genom att det finns ett javascript som kan använda rest-api:et ifrån taktestwebbappen. Detta kan läggas in i koden för TAK-WEB eller som ett plugin i webbläsaren eller kanske allra enklast i form av ett ”userscript” (https://en.wikipedia.org/wiki/Userscript).