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.
En användare skapar en beställning i NBS och skickar in.
Beställningen granskas och godkänns av behörig person inom domän- eller plattformsförvaltningen
Beställningen granskas av TAK-administratör
TAK-administratör initierar program (script) för backup och automatisk uppdatering.
Applikationen visar information om ändringar som beställningen kommer att medföra i TAK-en.
TAK-administratör bekräftar genomförande av ändringarna
Ändringarna genomförs i TAK-en.
Applikationen visar information om ändringar som genomförts.
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:
Tar en backup på TAK-en
Bekräftar att backup genomförts OK.
Läser in JSON-datat med informationen
Flyttar över datat till en intern representation i programmet.
Jämför beställning med faktiskt innehåll i TAK-en.
Visar information till användaren vilka uppdateringar som kommer att genomföras
Låter användare avgöra (bekräfta/avbryt) om dessa skall appliceras.
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:
Applicera extrude-data
elementen först.
För varje vagval
Tag bort raden ur tabellen
För varje anropsbehorighet
Tag bort raden ur tabellen
För varje logiskadress
Verifiera att inget vagval eller anropsbehorighet i TAK använder den logiska adressen
Tag bort adressen
För varje tjanstekontrakt
Verifiera att inget vagval eller anropsbehorighet i TAK använder tjänstekontraktet
Tag bort tjänstekontraktet
För varje tjanstekomponent
Verifiera att inget vagval eller anropsbehorighet i TAK använder tjänstekomponenten
Tag bort tjänstekomponenten
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.