INDHOLD

Beskrivelse

Stamdata Kopi Register Service (SKRS) giver mulighed for at hente komplette kopier af stamdata-registre. Dette giver anvendere mulighed for at ajourføre en lokal kopi af et stamdata-register.

Support ansvarlig: Kvalitets-IT
NSP: Stamdatamodul (SDM)Stamdata KopiRegister Service (SKRS) er en identitetsbaseret DGWS webservice udstillet på NSP-platformen, som giver adgang til relevante nationale stamdataregistre opsamlet af NSP fra forskellige myndigheder og dataansvarlige enheder.
Kopiregisterservicen giver dels mulighed for etableringsudtræk, hvor det komplette register leveres, dels såkaldte ”delta-opdateringer”, hvor ændringer i registret siden sidste udtræk leveres. De to typer udtræk er varianter af samme kald, hvor et etableringsudtræk leverer summen af samtlige ændringer i det pågældende registers levetid, og hvor et deltaudtræk leverer summen af ændringer siden sidste kald.

Adgangen er begrænset af den aftale der indgås med NSP-operatøren; servicen er underlagt whitelistningbegrænsning. Denne whitelistning er baseret på CVR-nummeret, der er indeholdt i anvendte ID-kort kombineret med et registernavn, datatypenavn og version.
Servicen udstiller stamdata registre via en mapping af kolonner og understøtter flere versioner og historiske data. Mulige stamdata registre er beskrevet her: Stamdataregistre og tilhørende datatyper

SKRS er tilgængelig på alle NSP-installationer. Alle kald til servicen logges.

Forretningsanvendelse

^^Tilbage til toppen^^

Anvendelse af Stamdata Kopi Register Service (SKRS): SDM - Guide til anvendere

Arkitekturbeskrivelser af stamdata importere:  Stamdata

Register beskrivelser:  Dokumentation af stamdataregistre.

Mulige stamdata registre er beskrevet her:  Datasamlinger.

Relaterede registre og services:

Applikationsbeskrivelse


^^Tilbage til toppen^^

Stamdata KopiRegister Service (SKRS) er en identitetsbaseret DGWS webservice udstillet på NSP-platformen, som giver adgang til relevante nationale stamdataregistre opsamlet af NSP fra forskellige myndigheder og dataansvarlige enheder.
Kopiregisterservicen giver dels mulighed for etableringsudtræk, hvor det komplette register leveres, dels såkaldte ”delta-opdateringer”, hvor ændringer i registret siden sidste udtræk leveres. De to typer udtræk er varianter af samme kald, hvor et etableringsudtræk leverer summen af samtlige ændringer i det pågældende registers levetid, og hvor et deltaudtræk leverer summen af ændringer siden sidste kald.

Support ansvarlig: KvalitetsIT
NSP: Stamdatamodul (SDM)

Stamdata Kopi Register Service (SKRS) giver mulighed for at hente komplette kopier af stamdata-registre. Dette giver anvendere mulighed for at ajourføre en lokal kopi af et stamdata-register.
Adgangen er begrænset af den aftale der indgås med NSP-operatøren; servicen er underlagt whitelistningbegrænsning. Denne whitelistning er baseret på CVR-nummeret, der er indeholdt i anvendte ID-kort kombineret med et registernavn, datatypenavn og version.
Servicen udstiller stamdata registre via en mapping af kolonner og understøtter flere versioner og historiske data. Mulige stamdata registre er beskrevet her: Stamdataregistre og tilhørende datatyper

SKRS er tilgængelig på alle NSP-installationer. Servicen er udstillet som en DGWS-service. Alle kald til servicen logges.

Whitelisting skal registreres før adgang tillades: SKRS.Client / Client_permissions, med angivelse af client (firma/cvr) samt registre/tabeller der kan hentes.
Der findes et enkelt endpoint til denne service: http://[host]:[port]/stamdata-batch-copy-ws/service/StamdataReplication
Kaldet til Kopiregisterservicen er formelt specificeret i WSDL’en stamdata_krs.wsdl https://wsdl.nspop.dk/stamdata-batch-copy-ws/service/StamdataReplication?wsdl

Operation replicate
---------------------
Denne operation bruges til at sende replikerings-requestet til SKRS. Svaret er SOAP, hvori der findes et ATOM-feed, som har det reelle indhold, der ønskes kopieret. De til enhver tid mulige felter i det reelle indhold er defineret ved en række XML-skemaer. Der kan angives en række værdier til parametre i requestet:
- register -- Registernavnet der ønskes udtræk fra, som bekrevet på tidligere nævnte oversigt.
- datatype --Datatypen som bekrevet på tidligere nævnte oversigt.
- version -- Af hensyn til bagudkompabilitet versioneres udtræksfunktionaliteten for hvert enkelt register. Seneste tilgængelige version er bekrevet på tidligere nævnte oversigt.
- offset -- En parameter, der angiver hvorfra i servicens udtræk af ændrede data svaret skal påbegyndes. Fra begyndelsen angives med '0' (nul). I hvert svar fra SKRS findes et revisionsnummer på en entitet, eksempelvis <atom:id>tag:nsi.dk,2011:cpr/person/v1/13667186340000000001</atom:id>, hvor sidste del, navnlig 13667186340000000001 angiver hvilket offset entiteten har. Denne værdi kan bruges som offset ifbm. paginering.
- maxRecords -- Bruges til at begrænse antallet af entitieter, som returneres i hvert svar. Der eksisterer en øvre grænse defineret af servicen, som ikke kan overstyres af anvendere.

Datastruktur, Intern register: SKRS whitelist

^^Tilbage til toppen^^

Register properties:

Stamdata Kopi Register Service registeret understøtter SKRS servicen.
database: stamdata

Whitelisting skal registreres før adgang tillades:
- SKRS brug (Client / Client_permissions), med angivelse af client (firma/cvr) samt registre/tabeller der kan hentes
- SAES+SCES+SYES (whitelist_config) -- Enkeltopslag Autorisation, CPR og Yderregister

Dynamisk SKRS med styring af udstillede kolonner som implementeret igennem SKRSViewMapping og SKRSColumns giver mulighed for at release en importer uafhængigt af kopi register servicen, dette er en stor gevinst i forhold til tiden det tager fra man sætter en importer i produktion til man kan hente data igennem kopi register servicen. Derudover er importeren nu det eneste sted man skal kigge når man leder efter en fejl og eneste sted det skal rettes.
Når man forespørger SKRS medsender man altid en viewpath som indeholder register, datatype og version og SKRS kan derefter kigge i SKRSViewMapping om den har beskrivelse af registeret.

Desuden fælles styring af skema-versioner, som alle importerer benytter til at holde styr på hvilke scripts der er afviklet, så hvert script kun afvikles én gang. (db_migrations).

Entitetsbeskrivelser

Client

^^Tilbage til toppen^^

Objektet indeholder de brugere (cvr) som er whitelisted som bruger af SKRS servicen

Objektet indeholder informationen:
---------------------------------------
id -- PRIMARY KEY
name -- Firmanavn
subjectSerialNumber -- CVR:12345678-UID:1234
comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting

Client_permissions

^^Tilbage til toppen^^

Whitelisting for hver bruger (cvr) til at udhente de forskellige registre, tabeller og versioner

Objektet indeholder informationen:
---------------------------------------
id -- PRIMARY KEY
client_id -- reference til Client tabellen
permissions -- tilladelse angives for hver "register/tabel/version"
comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting

SKRSViewMapping

^^Tilbage til toppen^^

Når man forespørger SKRS medsender man altid en viewpath som indeholder register, datatype og version og SKRS kan derefter kigge i SKRSViewMapping om den har beskrivelse af registeret.
Dynamisk SKRS som implementeret herigennem (samt SKRSColumns) giver mulighed for at release en importer uafhængigt af kopi register servicen, dette er en stor gevinst i forhold til tiden det tager fra man sætter en importer i produktion til man kan hente data igennem kopi register servicen. Derudover er importeren nu det eneste sted man skal kigge når man leder efter en fejl og eneste sted det skal rettes.

Objektet indeholder informationen:
---------------------------------------
`idSKRSViewMapping` -- primary key
`register` -- stamdata registernavn
`datatype` -- datatype tabelnavn
`version` -- version af registered (v1, v2, ..)
`tableName` -- tabelnavn med foranstillet registernavn
`createdDate` --

SKRSColumns

^^Tilbage til toppen^^

Dette objekt indeholder en beskrivelse af hver enkel tabel kolonne i et bestemt view

Objektet indeholder informationen:
---------------------------------------
`idSKRSColumns` -- primary key
`viewMap -- reference til SKRSViewMapping
`isPID` -- skal være 1 hvis kolonnen er primary key 0 ellers, bemærk kolonnen ikke bliver mappet til atom feeded hvis isPID er sat
`tableColumnName` -- kolonne navnet i database tabellen
`feedColumnName` -- kolonne navnet i atom feeded, vil somregel være det sammen som tableColumnName
`feedPosition` -- hvis kolonnen skal optræde et bestemt sted i feeded kan der sættes en værdi her, jo højere værdi jo senere bliver den sat ind i feeded
`dataType` -- hvilken type er data, denne værdi er en int som skal svare til en java.sql.Types
`maxLength` -- hvis der er en begrænsning på længden

whitelist_config (SAES+SCES+SYES)

^^Tilbage til toppen^^

Objektet indeholder de CVR som er whitelisted til SAES (Autorisation), SCES (CPR) og SYES (Yderregister) enkeltopslag servicene
(Bemærk: Whitelisting af SKRS (stamdata kopi register service) foretages i stamdata.client og stamdata.client_permissions)
Database: stamdata

Objektet indeholder informationen:
---------------------------------------
component_name -- angiver om registerdata for denne cvr skal samtykke bekyttes eller ej
-- SDM : enkeltopslag servicen
-- SDMwithConsent -- enkeltopslag servicen, samtykkebeskyttet
cvr -- CVR nummer
comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting

db_migrations

^^Tilbage til toppen^^

Fælles styring af skema-versioner, som alle importerer benytter til at holde styr på hvilke scripts der er afviklet, så hvert script kun afvikles én gang.

Opgradering af importer databasen sker automatisk ved serverstart, og fungerer på den måde at sql scripts med navne formatet "Vyyyymmdd_hhmm_description.sql" afvikles på databasen. Script filerne placeres under resources\db\migration" og inkluderes dermed automatisk i den deployede applikation.
Bemærk at sql filerne afvikles i navne orden, og da dato og tid indgår i navnet, kan man styre hvilke scripts der skal afvikles først.


Objektet indeholder informationen:
---------------------------------------
`version` -- Vyyyymmdd_hhmm
`description` -- taget fra sql-script-navnet, "description" delen, <importernavn_beskrivelse>, eksempel: "Apotekereimporter_rel2"
`installed_by` -- importernavn
`installed_on` -- current timestamp

Tabelbeskrivelser

Tabel: Client

^^Tilbage til toppen^^

-- ADMINISTRATION TABLES (USERS ETC.)

CREATE TABLE Client (
id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(200) NOT NULL,
subjectSerialNumber CHAR(200) NOT NULL,
comment VARCHAR(100) NULL
) ENGINE=InnoDB COLLATE=utf8_bin;

Tabel: Client_permissions

^^Tilbage til toppen^^

-- ADMINISTRATION TABLES (USERS ETC.)

CREATE TABLE Client_permissions (
id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
client_id BIGINT NOT NULL,
permissions TEXT NOT NULL,
comment VARCHAR(100) NULL,
FOREIGN KEY (client_id) REFERENCES Client(id) ON DELETE CASCADE
) ENGINE=InnoDB COLLATE=utf8_bin;

Tabel: SKRSViewMapping

^^Tilbage til toppen^^

CREATE TABLE IF NOT EXISTS `SKRSViewMapping` (
`idSKRSViewMapping` BIGINT(15) NOT NULL AUTO_INCREMENT ,
`register` VARCHAR(255) NOT NULL ,
`datatype` VARCHAR(255) NOT NULL ,
`version` INT NOT NULL ,
`tableName` VARCHAR(255) NOT NULL ,
`createdDate` TIMESTAMP NOT NULL ,
PRIMARY KEY (`idSKRSViewMapping`) ,
INDEX `idx` (`register` ASC, `datatype` ASC, `version` ASC) ,
UNIQUE INDEX `unique` (`register` ASC, `datatype` ASC, `version` ASC) )
ENGINE = InnoDB;

Tabel: SKRSColumns

^^Tilbage til toppen^^

CREATE TABLE IF NOT EXISTS `SKRSColumns` (
`idSKRSColumns` BIGINT(15) NOT NULL AUTO_INCREMENT ,
`viewMap` BIGINT(15) NOT NULL ,
`isPID` TINYINT NOT NULL ,
`tableColumnName` VARCHAR(255) NOT NULL ,
`feedColumnName` VARCHAR(255) NULL ,
`feedPosition` INT NOT NULL ,
`dataType` INT NOT NULL ,
`maxLength` INT NULL ,
PRIMARY KEY (`idSKRSColumns`) ,
INDEX `viewMap_idx` (`viewMap` ASC) ,
UNIQUE INDEX `viewColumn` (`tableColumnName` ASC, `viewMap` ASC) ,
CONSTRAINT `viewMap`
FOREIGN KEY (`viewMap` )
REFERENCES `SKRSViewMapping` (`idSKRSViewMapping` )
ON DELETE CASCADE
ON UPDATE NO ACTION)
ENGINE = InnoDB;

Tabel: whitelist_config (kun til brug for SAES+SCES+SYES)

^^Tilbage til toppen^^

CREATE TABLE whitelist_config (
component_name VARCHAR(50) NOT NULL,
cvr CHAR(8) NOT NULL,
comment VARCHAR(100) NULL,
PRIMARY KEY (component_name, cvr)
) ENGINE=InnoDB COLLATE=utf8_bin;

Tabel: db_migrations

^^Tilbage til toppen^^

CREATE TABLE `db_migrations` (
`version` varchar(20) NOT NULL,
`description` varchar(100) DEFAULT NULL,
`installed_by` varchar(30) NOT NULL,
`installed_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`version`),
UNIQUE KEY `version` (`version`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Teknologibeskrivelse

^^Tilbage til toppen^^

Refereres fra

^^Tilbage til toppen^^





  • No labels