Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Support ansvarlig: Trifork
NSP: https://www.nspop.dk/pages/releaseview.action?pageId=12226734 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: https://www.nspop.dk/pages/releaseview.action?pageId=28872117 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.

...

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.

Support ansvarlig: Trifork
NSP beskrivelse: 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.

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

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

^^Tilbage til toppen^^

Register properties:

Image RemovedImage Added

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
- (desuden styres whitelisting af Stamdata CPR & Autorisation Enkeltopslag servicene (SAES+SCES+SYES (whitelist_config) , men det har ingen betydning for selve SKRS servicen).-- 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).

Image AddedImage Removed

Entitetsbeskrivelser

...

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) og , SCES (CPR) og SYES (Yderregister) enkeltopslag servicenservicene
(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 : SAES (Autorisation) og SCES (CPR) enkeltopslag servicen
-- SDMwithConsent -- SAES (Autorisation) og SCES (CPR) 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

...

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^^

...