Page History
Navitabs | ||||||
---|---|---|---|---|---|---|
| ||||||
...
Formål
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.
Table of Contents |
---|
...
Omfattede komponenter
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.
2.1 Stamdata importer komponenter
2.1.1 Stamdata Data Importere
Hver stamdata importer ligger i sin egen WAR fil, hver importer har sin egen overvågnings URL, der enten fortæller om den enkelte importer er operationsdygtig (HTTP 200 OK), eller om der er fejl i importeren (HTTP 500 ERROR), Overvågningssiden vil give et bud på hvad fejlen er, dog bør man kigge i log-filen for at få alle detaljer med.
Type: Batch
- Status Url: http://<hostname>:<port>/<komponent-navn>/
- Filnavn: <komponent>.war
...
NSP komponenter
Stamdata Kopi-Register Service
- Type: Webservice
- Status Url: <serverurl>/stamdata-batch-copy-ws/status
- Filnavn: stamdata-batch-copy-ws.war
- Type: Webservice
- Status Url: <serverurl>/stamdata-authorization-lookup-ws/status
- Filnavn: stamdata-authorization-lookup-ws.war
- Type: Webservice
- Status Url: <serverurl>/stamdata-cpr-ws/status
- Filnavn: stamdata-cpr-ws.war
- Type: Webservice
- Status Url: <serverurl>/stamdata-yder-lookup-ws/status
- Filnavn: stamdata-yder-lookup-ws.war
- Type: REST service
- Status Url: <serverurl>/stamdata-personinformation/status
- Filnavn: stamdata-personinformation.war
Stamdata AutorisationsregisteretEnkeltopslag
Stamdata CPREnkeltopslag
Stamdata YderregisterEnkeltopslag
Opdatering til nye versioner
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.
...
...
Daglig Drift
4.1 Stamdata Importere
Stamdataimporterne er en gruppe filparsere og batch jobs som indlæser og vedligeholder data fra forskellige registre og gemmer dem i en MySQL database. Hver importer har sin egen inbox-mappe som automatisk oprettes når servicen startes. Roden for disse inboxmapper er:
<JBOSS_HOME>/domain/data/sdm4/
Komponenten kigger i sin inboxmappe for at se om der kommer nye filer til import. Det er driftens opgave at placere filer i inboxmapperne når tiden er inde for en opdatering. Hvilke filer der skal bruges og hvor ofte registrene skal opdateres er beskrevet i slutningen af dokumentet. Hver inbox er logisk navngivet efter den tilhørende importer. Se afsnittet om overvågning for monitorering af servicen
4.1.1 Fremgangsmåde for indlæsning af nye data
Parserne forventer data at blive lagt i undermapper af deres rod-mappe, f.eks.:
<JBOSS_HOME>/domain/data/sdm4/<importer>/20120822T201121S231/<file.txt>
<JBOSS_HOME>/domain/data/sdm4/<importer>/20120822T201121S231/<file2.txt>
Undermappernes navne er underordnede. De importeres i leksikografisk orden, og det vil derfor være oplagt at lægge dem så undermappernes navne er tidsstempler som vist i eksemplet.
Skulle der ske en fejl under import, vil der blive lagt en fil ved navn
"LOCKED" i parserens inbox, f.eks.:
<JBOSS_HOME>/domain/data/sdm4/<importer>/LOCKED
Parseren vil ikke forsætte før denne fil er slettet manuelt. Fejl-beskeden kan findes i loggen.
4.1.2 Eksempel for import af nye CPR-data
Her en et eksempel på strukturen for en parsers filsystem. I dette tilfælde er det CPR-parseren:
<JBOSS_HOME>/domain/data/sdm4/cprimporter/
Placeres filen ’D100312.L431101’ (som er en typisk CPR Person fil) i inputmappen begynder parseren at stabilisere data. Man kan gå ind på komponentens monitoreringsside for at se status for import:
http://<hostname>:<port>/cprimporter/status
Her vil man kunne se om CPRimporteren kører, hvornår CPRimporteren sidst har kørt, og hvilken status den har.
4.1.3 Konfiguration af Stamdata importere
Hver importer har en default konfigurationsfil (default-config.properties) der er indlejret i war filen, de eneklte konfigurationsindstillinger kan overstyres ved af en miljø specifik konfigurationsfil (config.properties), der ligger i filsystemet på følgende lokation:
<JBOSS_HOME>/modules/sdm4/config/<komponent>/main/config.properties
Properties
Wildfly jndi datasource
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.
Stamdata Autorisation Enkeltopslag
Konfiguration af Autorisation Enkeltopslag
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.stamdata.security.allowed.actors | Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser |
allowed.idws.audience | Skal være tom (Borgerkald ikke tilladt) |
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.
Stamdata Yderregister Enkeltopslag
Konfiguration af Yderregister Enkeltopslag
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.stamdata.security.allowed.actors | Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser,HealthCareProfessional |
allowed.idws.audience | Skal være tom (Borgerkald ikke tilladt) |
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.
Stamdata Kopi-Register-Service og Stamdataregister Fleropslagsservice
Konfiguration
Konfigurationsfiler kan findes på https://svn.nspop.dk/svn/components/sdm/trunk/ under /compose/configuration. Der anvendes følgende konfigurationsfiler:
- SKRS: stamdata-batch-copy-ws-krs.properties
- SRFS: stamdata-batch-copy-ws-rfs.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: |
dk.nsi.stamdata.security.allowed.actors | Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser |
allowed.idws.audience | Skal være tom (Borgerkald ikke tilladt) |
Rettighedsstyring
I kopi-register servicen (KRS) og fleropslagsservicen (RFS) 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.
- Whitelist til alle datatyper, i alle versioner af registret: <register>/
- Whitelist til alle versioner for specifik datatype: <register>/<datatype>/
- Whitelist til specifik version: <register>/<datatype>/<version>
- Whitelist til alle datatyper i specifik version af registret: <register>/<registerversion>
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
Konfiguration af opslagskolonner i SRFS
SRFS-tjenesten gør det muligt at lave opslag i stamdata ud fra en liste af id'er. For at sådanne opslag kan laves, skal det være angivet i SKRSColumns-tabellen hvilken kolonne der skal anvendes som nøgle for en tabel. Til dette formål bruges kolonnen isLookupColumn. Kolonnen indeholder en boolsk værdi, som angiver at tableColumnName skal bruges som nøgle ved SRFS-opslag. Hvis man f.eks. ønsker at tilbyde opslag på Person-objekter i CPR-registret, skal det angives at kolonnen CPR i tabellen Person skal bruges som nøgle. Bemærk at der kun er understøttelse for at angive én nøglekolonne per tabel.
For at kunne konfigurere SRFS-opslag for en datatype, skal man kende følgende:
- Id på det ViewMap, der skal tilbydes opslag på.
- Navn på den tabelkolonne, der skal bruges som nøglekolonne.
For at finde ViewMap-id'et skal man kende følgende:
- Hvilket register datatypen befinder sig i. (Fremgår af SKRSViewMapping.register)
- Hvad datatypen hedder (Fremgår af SKRSViewMapping.datatype)
- Hvilken version og registerversion af datatypen der skal tilbydes opslag på (Fremgår af SKRSViewMapping.version og SKRSViewMapping.registerVersion)
For at finde navnet på nøglekolonnen, inspiceres tabeldefinitionen for den tabel der skal tilbydes opslag i.
Nedenfor er vist to eksempler på, hvordan man konfigurerer en kolonne som nøglekolonne.
Code Block | ||
---|---|---|
| ||
UPDATE SKRSColumns set isLookupColumn = 1 where viewMap = (SELECT idSKRSViewMapping FROM SKRSViewMapping WHERE register = 'cpr' AND datatype = 'person' and version = 1 and registerVersion = 1) AND tableColumnName = 'CPR';
UPDATE SKRSColumns set isLookupColumn = 1 where viewMap = (SELECT idSKRSViewMapping FROM SKRSViewMapping WHERE register = 'yderregister' AND datatype = 'yder' and version = 3 and registerVersion = 1) AND tableColumnName = 'YdernrYder'; |
I eksemplet opsættes opslag i CPR-registrets Person-tabel ud fra kolonnen 'CPR', samt opslag i yderregistrets Yder-tabel ud fra kolonnen 'YdernrYder'. Versionsnumrene passer til det lokale udviklingsmiljø. Der kan være andre versionsnumre i test og produktion.
CPR-Services
Denne komponent skal deployes på NSP’erne.
Konfiguration
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.stamdata.security.allowed.actors | Kommasepararet liste af brugertyper som kan tilgå |
jdbc.JNDIName
JNDI navn for datasourcen, der er konfigureret i JBOSS serveren, default: java:/SDMDS
sdm.dataDir
Folder navn hvor importeren kan finde datafilerne default: /pack/jboss/domain/data/sdm4
spooler.max.days.between.runs
Parameter til overvågning af om en importer har modtaget data indenfor et forventet interval. Hvis denne frist overskrides vil overvågningen rapportere fejl.
dk.nsi.dgws.sosi.dgwsLevels
denne service. F.eks dk.nsi.stamdata. |
security. |
allowed. |
actors= |
Citizen,SystemUser, |
Default: 3
4.2 Database
De enkelte stamdata importere er testet på en MariaDB database.
4.2.1 Skema til stamdata importere
Skema til stamdata importere opdateres automatisk af de enkelte importere, via det indbyggede migrerings framework.
Det skal dog understreges at så lang tid de enkelte NSP services er direkte afhængige af tabel layoutet for stamdata importerne, og der samtidig skal være bagud kompatibilitet vil tabel layoutet ikke ændre sige for stamdata importerne – men kun være splittet ud i importer war filerne.
4.2.2 Databaseopsætning
Følgende indstillinger bør sættes specielt i databasen, disse indstillinger konfigureres i mysql’s konfigurationsfil.
...
Indstilling
...
Værdi
...
Beskrivelse
...
Max_allowed_packet
...
16M
...
CPR opslagsservices kan returnere en pæn mængde data, derfor er max_allowed_packet default værdien på 1M for lidt - det anbefales at sætte den til 16M.
HealthCareProfessional | |
allowed.idws.audience | Det tilladte audience på indkommende idws requests f.eks.: https://fsk |
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 |
Statsborgerskabs mapning
Statsborgerskabsland for grænsegængere kan ske kun at være udfyldt med kode. Landet mappes i det tilfælde fra en liste, som indeholder landekode=landenavn. Listen findes default i filen country-mapper-internal.properties, som er bygges ind i komponenten.
Filen (UTF-8) er skabt 11. august 2022 med data fra siden https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes, søjlerne "country name" og "alfa-2 code".
Der er muligt at overstyre denne fil, med en anden: country-mapper-external.properties
country-mapper-external.properties skal findes på (oprettet i driften):
$JBOSS_HOME/standalone/configuration/country-mapper-external.properties
Eksempel på country-mapper-internal.properties indhold (start af filen):
Code Block |
---|
AD=Andorra
AE=United Arab Emirates (the)
AF=Afghanistan
AG=Antigua and Barbuda
AI=Anguilla
AL=Albania
AM=Armenia
AO=Angola |
Rettighedsstyring
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. For SCES er mulige component_name-værdier beskrevet i anvenderguidens afsnit 5.4.2.
PersonInformation
Denne komponent skal deployes på NSP’erne.
Konfiguration
Konfigurationsfil kan finde på https://svn.nspop.dk/svn/components/sdm/trunk/compose/configuration/stamdata-personinformation.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: |
service.endpoint | Endpoint for servicen. Anvendes som del af URL i openapi dokumentationen. F.eks. http://localhost:8080 |
Backup
...
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.
5.1 Backup af Data Manager input-filer
Alle filer fra dataset som lægges ind i Stamdata indbakker skal der laves backup af. Det vil sige at hver gang der f.eks. ankommer en ny fil fra CPR-registeret skal filen ligges i den pågældende parsers indbakke og samtidigt arkiveres. Hvordan filen arkiveres er op til driften, men filnavnet og dato for ankomst skal kunne spores.
6 Overvågning
6.1 Statussider
Overvågning
Statussider
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.
...
Speciel overvågning af SOR og SOR-Relationer importerne
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.
...
Logning
Stamdata importerne på BackOffice bruger ikke JBOSS logging, men har hver deres egen log konfiguration som placeres følgende:
<JBOSS_HOME>/modules/sdm4/config/<Importer navn>/main/
Her ligges en log4j.properties, der beskriver hvorledes importeren skal logge, samt konfiguration for SLA logging for netop denne komponent
6.2.1 SLA-Log punkter
For at sikre en struktureret logning på tværs af de forskellige services, benyttes nsp-util også til SLA-Logning fra sdm4 importerne.
Der logges fra 2 logpunkter pr. importer ét punkt fra sdm4-core og ét fra selve importeren, sdm4-core er delt for alle importere og der dannes én linje for hver gang en importer startes.
En log fra sdm4-core ser ud som nedenfor:
03-06-2013 13:34:46,752 [pool-10-thread-1] INFO dk.sdsd.nsp.slalogdata - LogPoint="<importernavn>.ParserExecutor" LogPointUniqId="SDM4CORE_ENTRY" StartTime="2013-06-03 13:34:45.650" EndTime="2013-06-03 13:34:46.752" Duration="1101893 microseconds" MessageId="vitaminimporter-1370259285650" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="<empty>" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(0)= { }
Fra de enkelte importere logges følgene pr datasæt:
03-06-2013 13:34:46,750 [pool-10-thread-1] INFO dk.sdsd.nsp.slalogdata - LogPoint="<importernavn>.process" LogPointUniqId="SDM4. <importernavn>.process" StartTime="2013-06-03 13:34:45.782" EndTime="2013-06-03 13:34:46.750" Duration="967593 microseconds" MessageId="vitaminimporter-1370259285650" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="<empty>" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(2)= { ("input","/pack/jboss/domain/data/sdm4/vitaminimporter/vitaminer") , ("processed_records","634") }
GenericCallParms indeholder altid ”input” som peger på input folderen samt ”processed_records” som indeholder antal indsatte eller ændrede records i databasen.
MessageID indeholder en unik id for kørslen således man kan kæde sdm4-core loggen sdm4-importeren sammen pr. kørsel.
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
Fejlsøgning
...
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.
...
Liste af Registre
Hvert register har sin egen registerspecifikations fil som ligger i register mappen sammen med dokumentationen.
8 Ændringslog
Kilden til dette dokument kan findes på:
Stamdata Filter Management Service (SFMS)
Konfiguration
Konfigurationsfiler kan findes på https://svn.nspop.dk/svn/
...
...
sdm/trunk/ under /compose/
...
...
Version
...
Dato
...
Ændring
...
Ansvarlig
...
1.0
...
2011-04-28
...
Initielt Dokument
...
Trifork
...
1.1
...
2011-09-12
...
Opdateret med CPR services
...
Trifork
...
1.2
...
2012-06-18
...
Tilføjet informationer om schema opdateringer, samt mysql settings og v2 parsere
...
Trifork
...
1.3
...
2012-08-22
...
Opdateret med opsplitning af stamdata importere i moduler, samt JBOSS 7 konfiguration på DoDi
...
Trifork
...
1.4
...
2012-08-24
...
Fjernet al dokumentation der ikke er Importer specifik
...
Trifork
...
1.5
...
2013-06-03
...
Tilføjet afsnit om sla-log
...
Trifork
...
1.6
...
2014-01-09
...
Opdateret kilde link
...
Trifork KPN
...
1.7
...
2019-09-20
...
Ajourført (Backoffice og MariaDB) Udstilling kun på NSPOP
...
NSP Operatør
configuration/filter-management-ws-sfm.properties.
Properties
dk.nsi.stamdata.security.allowed.actors | Kommasepararet liste af brugertyper som kan tilgå denne service. F.eks dk.nsi.stamdata.security.allowed.actors=SystemUser |
allowed.idws.audience | Skal være tom |
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 | java:jboss/datasources/SDMDS |
service.endpointPersonInformation |
...