Json format beskrivning

Bakgrund

Idag sker uppdateringen av TAK-en manuellt. Det är baserat på konfigurationsbeställningar från blanketter eller från verktyget Nationella Beställningsstödet (NBS). Den manuella hanteringen innebär risk för felaktiga uppdateringar.

Det finns ett behov av att automatisera uppdateringen av TAK-en. En sådan funktion skulle kunna användas för att integrera NBS till TAK-en, men även potentiellt för andra framtida användningsfall.

Användningsfall

Användningsfall 1 - TAK-uppdatering baserat på beställning från NBS

Automatisering av beställning från NBS.

  1. En användare skapar en beställning i NBS och skickar in.

  2. Beställningen granskas och godkänns av behörig person inom domän- eller plattformsförvaltningen

  3. Beställningen granskas av TAK-administratör

  4. TAK-administratör initierar program (script) för backup och automatisk uppdatering.

  5. Applikationen visar information om ändringar som beställningen kommer att medföra i TAK-en.

  6. TAK-administratör bekräftar genomförande av ändringarna

  7. Ändringarna genomförs i TAK-en.

  8. Applikationen visar information om ändringar som genomförts.

  9. Applikationen visar information om något i uppdateringen har gått fel. KOMPLETTERA BILD med punkt 8 och 9.

 

Komponenter i lösningen

Format på beställningsinformation

För denna applikation finns behov av ett standardiserat format som kan representera information i en TAK. Observa att formatet beskriver målet för hur TAK-en skall vara konfiguerad, den beskriver inte en förändring.

Det format som valts är ett subset av det som definierats och används när TAK-data exporteras och skickas till TAK-apit. Det formatet ser ut så här. Det som förändrats är:

  • data - informationen som i exportfilen ligger i data har duplicerats till ensure-data and extrude-data

  • filter - tagits bort

  • filtercategorization - tagits bort

  • rivtaprofil - tagits bort

  • integrationsavtal - tagits bort

  • pubversion (samtliga förekomster) - tagits bort

  • anropsadress - denna information läggs in i vagval

  • relationships - anropsbehorighet och vagval förenklas till att enbart innehålla en tripel per item

  • id - tagit bort samtliga förekomster där det representerar ett TAK-internt id. Istället för att nyckla och knyta samman informationen baserat på interna id-begrepp (som i exportfilen) används de naturliga nyckelbegreppen för varje informationsmängd.

{ "plattform": <namn-på-tjänsteplattform>, "formatVersion": "<version av detta format>", "version": "<int>", "bestallningsTidpunkt": "<YYYY-MM-DDThh:mm:ss+XXXX>", "genomforandeTidpunkt": "<YYYY-MM-DDThh:mm:ss+XXXX>", "utforare": "<Namn>", "kommentar": "<text som beskriver denna uppdatering>", "inkludera": { "tjanstekontrakt": [ { "namnrymd": "<text>", "beskrivning": "<text>", "majorVersion": <integer> } ], "logiskadresser": [ { "hsaId": "<text>", "beskrivning": "<text>" } ], "tjanstekomponenter": [ { "hsaId": "<text>", "beskrivning": "<text>" } ], "anropsbehorigheter": [ { "logiskAdress": <hsaId>, "tjanstekonsument": <hsaId>, "tjanstekontrakt": <namnrymd> } ], "vagval": [ { "adress": "<URL>", "logiskadress": <hsaId>, "tjanstekontrakt": <namnrymd>, "rivtaprofil": "<text>", "tjanstekomponent": <hsaId> } ] } "exkludera": { "anropsbehorigheter": [ { "logiskAdress": <hsaId>, "tjanstekonsument": <hsaId>, "tjanstekontrakt": <namnrymd> } ], "vagval": [ { "adress": "<URL>", "logiskadress": <hsaId>, "tjanstekontrakt": <namnrymd>, "rivtaprofil": "<text>", "tjanstekomponent": <hsaId> } ] } }

OBS - förändringar införda 2018-10-08:

  • Formatet för timestamps nu enhetligt enligt "<YYYY-MM-DDThh:mm:ss+XXXX>"

  • Borttag av fromTidpunkt och tomTidpunkt under extrudeData

  • Borttag av fromTidpunkt och tomTidpunkt under ensureData

  • Döper om "tidpunkt" till "bestallningsTidpunkt"

  • Adderar "genomforandeTidpunkt" (som visar när alla delar av beställningen skall börja gälla)

  • Tar bor tjanstekontrakt, logiskadress och tjanstekomponent från extrude-data

  • Ändra till plural för; logiskaadresser, tjanstekomponenter och anropsbehorigheter där det representerar listor

  • Döper om "ensure-data" till "inkludera"

  • Döper om "extrude-data" till "exkludera"

Informationen i ensure_data

  • objektet skall finnas i TAK-en efter uppdateringen. Uppdateringsscriptet får kontrollera om informationen redan finns på plats, om inte skall den läggas till.

Motsatsen gäller för extrude-data. Denna information skall inte finnas i TAK-en, och därför tas bort om den existerar. Ett alternativ är att bara göra extrude på vagval och anropsbehorighet. Uppdateringsprogrammet skulle (eventuellt) sedan få ansvara för att ta bort tjanstekontrakt, tjanskekomponenter och logiska adresser som inte längre nyttjas.

Angående fältet "plattform". Förslaget är en kombination av "organisation" och "miljö". Ex:

  • NTJP-PROD

  • NTJP-QA

  • NTJP-TEST

  • SLL-PROD

  • SLL-QA

  • LD-PROD

  • NMT-TEST

  • ...

Uppdateringsscriptet:

  1. Tar en backup på TAK-en

  2. Bekräftar att backup genomförts OK.

  3. Läser in JSON-datat med informationen

  4. Flyttar över datat till en intern representation i programmet.

  5. Jämför beställning med faktiskt innehåll i TAK-en.

  6. Visar information till användaren vilka uppdateringar som kommer att genomföras

  7. Låter användare avgöra (bekräfta/avbryt) om dessa skall appliceras.

  8. Om användaren bekräftar - genomför förändringarna och genererar en log.

Ordningen på elementen/subelementen i JSON-strukturen är inte viktig. Uppdateringsscriptet ansvarar för att genomföra ändringarna i rätt turordning. Det är:

  1. Applicera extrude-data

    • elementen först.

    1. För varje vagval

      • Tag bort raden ur tabellen

    2. För varje anropsbehorighet

      • Tag bort raden ur tabellen

    3. För varje logiskadress

      1. Verifiera att inget vagval eller anropsbehorighet i TAK använder den logiska adressen

      2. Tag bort adressen

    4. För varje tjanstekontrakt

      1. Verifiera att inget vagval eller anropsbehorighet i TAK använder tjänstekontraktet

      2. Tag bort tjänstekontraktet

    5. För varje tjanstekomponent

      1. Verifiera att inget vagval eller anropsbehorighet i TAK använder tjänstekomponenten

      2. Tag bort tjänstekomponenten

  2. Applicera ensure-data

    • elementen

    • Om elementet inte finns i TAK (dvs nyckelid inte finns) läggs det till

    • Om nyckelid finns så uppdateras övriga fält enligt beställningen om något fält inte matchar beställningen.

    • Om elementet redan finns sker ingen uppdatering

    • Återkoppling från applikationen i alla ovanstående fall

Övrigt: Returkoder skall alltid returneras. Alla förändringar loggas, inkl timestamp. Det sker ev i form av de SQL-satser som exekveras.

 

Tjänsteadresseringskatalog - TAK

Schemat för TAK-databasen ser ut som:

Överföring mellan NBS och TAK-administratör

Överförs med en länk som bifogas i det utgående mailet till respektive ärendehanteringssystem.