Dokument målrettet systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.
Driftsvejledningen skal indeholde information om komponentens version, standard placering af logfiler og konfigurationsfiler, eksterne afhængigheder, og evt. krav til genstart af applikationer hvis komponenten bliver ikke-responsiv.
Start/stop vejledning for komponenten beskrives, herunder hvilke andre applikationer der evt. skal genstartes.
Kendte fejlkoder som skrives i logfiler dokumenteres, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning. En generel læsevejledning til logfiler vedlægges.
Det bør angives hvorledes komponenten bedst lader sig overvåge, dvs. en generisk beskrivelse af overvågningen, der ikke er værktøjsafhængig.
Evt. specielle krav til backup beskrives, ligesom procedure ved reetablering af komponenten ud fra backup beskrives.
Dette dokument omfatter driften af alle Stamdata komponenterne i FMKi projektet.
Listen herunder beskriver hver komponent med type status URL og navnet på filen som skal deployes. Status URL’en kan løbende polles for at checke komponentens status. Status sider er beskrevet mere detaljeret senere i dokumentet.
Når nye versioner af Stamdata komponenterne udkommer, vil der medfølge release notes som forklarer database-migrering, rollback-procedure, service vinduer mv. Til installation af første version af stamdata komponenterne henvises til installationsguiden.
Wildlfy skal være opsat med en jndi datasource til mysql, den kan fx se ud som nedenfor:
wildfly/standalone/configuration/standalone.xml |
<datasources> <datasource jndi-name="java:jboss/datasources/SDMDS" pool-name="SDMDS" enabled="true" use-java-context="true"> <connection-url>jdbc:mysql://localhost:3306/sdm_warehouse</connection-url> <driver>mysql</driver> <pool> <min-pool-size>10</min-pool-size> <initial-pool-size>10</initial-pool-size> <max-pool-size>100</max-pool-size> <allow-multiple-users>true</allow-multiple-users> </pool> <validation> <check-valid-connection-sql>select 1</check-valid-connection-sql> <validate-on-match>false</validate-on-match> <background-validation>false</background-validation> </validation> <security> <user-name>sdm</user-name> <password>papkasse</password> </security> <timeout> <idle-timeout-minutes>1</idle-timeout-minutes> </timeout> </datasource> <drivers> <driver name="mysql" module="com.mysql"> <driver-class>com.mysql.jdbc.Driver</driver-class> </driver> </drivers> </datasources> |
Jndi navnet indsættes i de enkelte komponeneters sdm.JNDIName.
Konfigurationsfil kan finde på (oprettet i driften):
$JBOSS_HOME/server/default/conf/stamdata-authorization-lookup-ws.properties
Properties
db.connection.jdbcUrl | Udgået - Skal være tom |
db.connection.username | Udgået - Skal være tom |
db.connection.password | Udgået - Skal være tom |
sdm.JNDIName | VIGTIG Denne skal være sat Jndi datasource navn fx: |
security | Enten dgws eller dgwsTest. Hvis dgwsTest anvendes accepterer servicen id kort underskrevet af Test STS’. Dette kan bruges til f.eks. Load Test. (dgws) |
dk.nsi.dgws.sosi.dgwsLevels | Kommasepararet liste af DGWS niveauer som kan bruges når man tilgår denne service. F.eks dk.nsi.dgws.sosi.dgwsLevels=3,4 Default: 3 |
Til rettighedsstyring benyttes tabellen whitelist_config i Stamdata databasen. For hver klient der skal have adgang laves en ny række med component_name 'SDM' og klientens CVR i cvr kolonnen. (Dette har tidligere været en kommasepareret liste af SSN i stamdata-authorization-lookup-ws.properties så hvis der findes en eksisterende liste konfigureret i driften skal denne liste migreres til rækker i whitelist_config tabellen.
Konfigurationsfil kan finde på (oprettet i driften):
$JBOSS_HOME/server/default/conf/stamdata-yder-lookup-ws.properties
Properties
db.connection.jdbcUrl | Udgået - Skal være tom |
db.connection.username | Udgået - Skal være tom |
db.connection.password | Udgået - Skal være tom |
sdm.JNDIName | VIGTIG Denne skal være sat Jndi datasource navn fx: |
security | Enten dgws eller dgwsTest. Hvis dgwsTest anvendes accepterer servicen id kort underskrevet af Test STS’. Dette kan bruges til f.eks. Load Test. (dgws) |
dk.nsi.dgws.sosi.dgwsLevels | Kommasepararet liste af DGWS niveauer som kan bruges når man tilgår denne service. F.eks dk.nsi.dgws.sosi.dgwsLevels=3,4 Default: 3 |
Til rettighedsstyring benyttes tabellen whitelist_config i Stamdata databasen. For hver klient der skal have adgang laves en ny række med component_name 'SDM' og klientens CVR i cvr kolonnen. (Dette har tidligere været en kommasepareret liste af SSN i stamdata-authorization-lookup-ws.properties så hvis der findes en eksisterende liste konfigureret i driften skal denne liste migreres til rækker i whitelist_config tabellen.
Konfigurationsfil kan findes på (oprettet i driften):
$JBOSS_HOME/server/default/conf/stamdata-authorization-lookup-ws.properties
Properties
db.connection.jdbcUrl | Udgået - Skal være tom |
db.connection.username | Udgået - Skal være tom |
db.connection.password | Udgået - Skal være tom |
sdm.JNDIName | VIGTIG Denne skal være sat Jndi datasource navn fx: |
I kopi-register servicen (KRS) kan alle stamdatas registre kopieres via en webservice. Det er derfor vigtigt at kunne styre meget nøjagtigt hvilke data en klient har adgang til.
NB. Rettighedsstyring i KRS ligger i databasen og er besværligt at styre manuelt. Oprindeligt havde KRS en tilhørende GUI til rettighedsstyring. GUI’en eksisterer ikke længere, og pga. den fint kornede rettighedsstyring er det lidt akavet. Der findes pt. ikke nogen måde at enkelt give en klient adgang til alle datatyper i et register eller en datatype i flere versioner.
Opretning af ny bruger
Log ind i stamdatas database og derefter:
INSERT INTO Client (name, subjectSerialNumber) VALUES (’<NAVN>’, ’CVR:12345678-UID:1234’);
SubjectSerialNumber feltet skal indeholde et subject serial number som vist i eksemplet herover. Det er underordenet hvilken UID der står i feltet, brugere identifiseres udelukkende på CVR nummeret. Dette felt er udelukkende af et subject serial number af historiske årsager.
Ændring af en brugers rettigheder
Noter id fra den nye bruger. Id’et skal bruges til at bestemme brugerens rettigheder:
SELECT id FROM Client WHERE name = ’<NAVN>’;
INSERT INTO Client_permissions (client_id, permissions) VALUES (<ID>, ’<RETTIGHED>’);
En <RETTIGHED> består af fire komponenter: register, registerversion, datatype og datatypeversion. Registerversion er valgfri af hensyn il bagudkompatibilitet. Indholdet af <RETTIGHED> er på formen <register>(/<registerversion>)?/<datatype>/<version>, hvor registerversion som sagt er valgfri.
Eksempel på en liste af rettigheder
Feltet <RETTIGHED> skal indeholde en streng der beskriver datatypen der skal whitelistes, for cpr register person tabellen vil det være:
’cpr/person/v1’ - Dette vil give klienten ret til at hente datatypen Person i version1.
’cpr/person/’ - Dette vil give klienten ret til at hente datatypen Person i alle kendte version.
’cpr/’ - Dette vil give klienten ret til at hente alle kendte datatypen i alle kendte version i cpr regisret
'cpr/v2/person/v2' - Dette vil give klienten ret til at hente datatypen Person i version 2 i version 2 af cpr-registret.
Se dokumentationen for registerspecifikationer for navne på de respektive data type navne.
Denne komponent skal deployes på NSP’erne.
Konfigurationsfil kan finde på (oprettet i driften):
$JBOSS_HOME/server/default/conf/stamdata-cpr-ws.properties
db.connection.jdbcUrl | Udgået - Skal være tom |
db.connection.username | Udgået - Skal være tom |
db.connection.password | Udgået - Skal være tom |
sdm.JNDIName | VIGTIG Denne skal være sat Jndi datasource navn fx: |
dk.nsi.dgws.sosi.dgwsLevels | Kommasepararet liste af DGWS niveauer som kan bruges når man tilgår denne service. F.eks dk.nsi.dgws.sosi.dgwsLevels=3,4 Default: 3 |
field.default.<felt> | Default værdier for felter der er markeret som "unreliable" Formatet for datoer er 'yyyy-MM-dd HH:mm:ss' Indsættes værdien <trhow> vil anvenderen få en fejl retur såfremt feltet er markeret som unreliable. Der skal være en default værdi for alle følgende felter: fornavn, mellemnavn, efternavn, coNavn, lokalitet, vejnavn, bygningsnummer, husnummer, etage, sideDoerNummer, bynavn, postnummer, postdistrikt, status, statusDato, gaeldendeCPR, stilling, vejKode, kommuneKode, navnebeskyttelseslettedato, navnebeskyttelsestartdato, navnTilAdressering, vejnavnTilAdressering, foedselsdatoMarkering, foedselsdato |
Offentlige myndigheder skal whitelistes for at kunne hente data uden adresse og navnebeskyttelse.
Rettighedsstyring foregår ved at tilføje myndighedens CVR nummer til database tabellen whitelist_config.
Så for at whiteliste myndighed med CVR 12345678 køres følgene SQL op i mod databasen:
INSERT INTO whitelist_config(component_name, cvr) VALUES('SDM','12342678');
Bemærk værdien af component_name skal være ’SDM’ pånær for AuthorizationCodeLookup hvor den er SDMAuthorizationCode.
Alle tabeller i stamdatas database skal have daglig backup. Backup må ikke gemmes længere end 2 år pga. lovkrav.
Da der er tale om store mængder data er det vigtigt at holde for øje at det kan tage meget lang tid at genetablere et database image for stamdata.
For hver komponent er der en status-side som periodisk kan kaldes for at tjekke om servicen kører. Hvis en service ikke kan overvåges via en simple status side vil det fremgå af dens driftsdokumentation.
Status sider fungerer over HTTP, og har følgende statuskoder:
200 | Alt er OK. |
500 | Der er opstået en fejl, og driften bør undersøge komponentens log for fejlmeddelelser. Kan fejlen ikke opklares simpelt, bør driften kontakte support. |
URL’s for status sider kan findes tidligere i dette dokument.
Da SOR behandles af to forskellige importere, er det et problem for datakonsistensen, hvis den ene af disse to parsere fejler på et datasæt som den anden parser ikke fejler på.
Skulle en af de to parsere afvise en import, er det en hastesag at få rettet den fejl der resulterer i afvisningen i den anden parser, så de to registre kan komme i sync så hurtigt som muligt.
Alle Stamdata komponenter logger vha. JBoss’s logging api. Da logging API’en i JBoss 6.0.Final er defekt har komponenterne ikke hver sin logfil. Alle log entries bliver logget til:
$JBOSS_HOME/server/default/log/server.log
Opstår der en fejlsituation i en komponent, skal driften undersøge den pågældende komponents logfil for loghændelser på ERROR-niveau. F.eks. i tilfælde af at komponenten ikke kan forbinde til databasen. Visse andre fejl er ikke-kritiske. Det vil sige at komponenten kan forsætte med at fungere. De bliver også logget på ERROR-niveau da der hændelsen bør undersøges. Komponenterne vil i så vid udstrækning som muligt forsøge at forsætte på trods af fejl.
Anvendes Splunk til indeksere logfiler bør alle de konfigurerede filer indekseres. Der kan opsættes alarmer i Splunk som aktiveres hvis en hændelse med ERROR-niveau logges. Dette niveau anvendes udelukkende ved alvorlige fejl. Der udover er også hændelser på WARN-niveau interessante da de f.eks. fortæller om folk forsøger at tilgå servicen uden tilladelse ol.
Hvert register har sin egen registerspecifikations fil som ligger i register mappen sammen med dokumentationen.