Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Table of Contents |
|---|
Introduktion
Formål
Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af servicen.
Driftsvejledningen indeholder information om Min Spærring Samtykkeservicen komponenterne med hensyn til eksterne afhængigheder, standardplacering af logfiler og konfigurationsfiler, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.
I afsnit 2 er beskrevet hvilke komponenter der indgår i Min Spærring services Samtykkeservicen og deres forventede placering med hensyn til platform.
Afsnit 4 beskriver aktuelle konfigurationsparametre for Min Spærring servicesSamtykkeservicen, samt eksempler på konfigurationsparameterfiler.
Afsnit 5.1, 5.2 og 5.3 beskriver hvorledes Min Spærring komponenterne Samtykkeservicen overvåges.
I afsnit 5.4 er Min Spærring service Samtykkeservicen relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.
...
Specielle krav til backup er beskrevet i afsnit 7, ligesom procedure ved reetablering af komponenten ud fra backup beskrives.
Læsevejledning
Læseren forventes at have kendskab til Sundhedsdatastyrelsens platform NSP, samt generelt kendskab til WildFly applikation server, Docker, Docker Compose samt Ubuntu Linux operativ system
Dokumenthistorik
| Version | Dato | Ansvarlig | Beskrivelse |
|---|---|---|---|
1.0 | 29.06.2012 | Systematic | Initiel udgave |
1.1 | 18.09.2012 | Systematic | Http statuscheck opdateret |
1.2 | 11.09.2014 | Systematic | URL for service-check rettet. |
1.3 | 20.11.2014 | Systematic | Konfiguration af organisationsnavn tilføjet |
1.4 | 14.03.2016 | Systematic | ServiceChecker konfiguration opdateret Opgradering til WildFly Beskrivelse af legacy properties |
1.5 | 02.09.2016 | Systematic | XA-transaktioner fjernet fra afsnit 4.3.3. Beskrivelse af DCC Konfigurations Service (DKS) tilføjet. |
1.6 | 17.12.2016 | Systematic | Versionsnummer kan nu hentes som beskrevet i afsnit 4.2.5. Udpegning af id-kort properties som ikke længere benyttes i afsnit 4.1.1. Generel servicecheck komponent erstattet af Samtykke-specifik servicecheck (afsnit 4 og 5) Navn på SLA properties ændret. Ny timeout property tilføjet i afsnit 4.1.1. |
1.7 | 04.04.2017 | Systematic | Status-snitflade tilføjet som beskrevet i afsnit 2, 4 og 5. Ubrugte certifikatproperties fjernet fra afsnit 4.1 og 4.2. |
1.8 | 13.06.2018 | Systematic | Migreret til NSPOP SVN |
| 22.10.2018 | KIT | Dokument flyttet fra Word til Confluence. Original dokument navn var: OHB0002 Driftsvejledning Samtykke Services.docx | |
| 19.03.2020 | KIT | Opdateret i forhold til docker. | |
| 22.06.2020 | KIT | Opdateret i forbindelse med etablering af IDWS i administrationssnitfladen. | |
| 22.10.2020 | KIT | SDS-3875 A new version of the interface has been added. This interface matches the underlying validations. | |
| 09.11.2020 | KIT | SDS-3685: Min Spærring skal anvende SORES til SOR-SHAK opslag | |
| 06.05.2021 | KIT | SDS-2416: Samtykkeservicen skal ændres til at kalde minlog2 | |
| 26.11.2021 | KIT | Tilføjet property. |
Definitioner og referencer
| Definition | Beskrivelse |
|---|---|
DCC | Dekoblingskomponenten på NSP |
DKS | DCC Konfigurations Service |
NSI | National Sundheds-IT |
NSP | Den nationale service platform (inden for sundheds-IT) |
SHAK | Sygehusafdelingsklassifikation |
SOR | Sundhedsvæsenets organisationsregister |
STS | Security Token Service |
| Alias | Beskrivelse |
|---|---|
DKS-beskrivelse | https://www.nspop.dk/display/web/DKS+--+DCC+Konfiguration+Service, hentet 02.09.2016. |
Komponenter
Dette dokument dækker følgende komponenter på NSP:
NSP komponenter
Consent-verification
Type: Webservice
Filnavn: consent-verification.ear
Url: <serverurl>/consent-verification/serviceServicecheckurl: <serverurl>/consent-verification/info/servicecheck
- StatusUrl: <serverurl>/consent-verification/info/status
Versionsurl: <serverurl>/consent-verification/info/version
DKS-konfiguration: <serverurl>/consent-verification/dccconfig/dks
DoDi – Dataopdateringkomponenter
Consent-administration
Type: Webservice
Filnavn: consent-administration.ear
Url: <serverurl>/consent-administration/service
- Url: <serverurl>/consent-administration/servicev2
- ServicecheckurlStatusUrl: <serverurl>/consent- administration/info/servicecheckstatus
StatusUrlVersionsurl: <serverurl>/consent-administration/info/statusVersionsurl: <serverurl>/consent-administration/info/version
DKS-konfiguration: <serverurl>/consent-administration/dccconfig/dks
Consent-administration komponenten anvender desuden Min-log-registreringsservicen, som skal være tilgængelig på DoDi’en.
Daglig drift
Dette afsnit beskriver den daglige drift af systemet.
Synkronisering af consent database fra
...
Samtykkeservicen administrationsservice til NSP
Min Spærring Samtykkeservicen administration er en central service, der opbevarer borgeres registrerede samtykker/spærringer i consent databasen.
Der skal sikres at borgernes opdateringer af registrerede samtykker/spærringer i den centrale consent database replikeres til den enkelte NSP.
Konfiguration
...
Samtykkeservicen administration
Servicekonfiguration
Grundlæggende konfiguration foregår ved redigering i filen ConsentAdministration.properties, der placeres i følgende WildFly modul:
...
I denne skal følgende properties være definerede:
Property | Beskrivelse |
|---|---|
idcard.version | Servicen afviser kald, hvor ID-kort i Security-header ikke har versionsnummer opgivet som værdien af denne property. Angives til 1.0.1 |
sts.test.mode | Angiver med værdien true at servicen benytter test-STS. Værdien skal være ’false’ i drift, hvorved den rigtige SOSI-STS anvendes. |
log.config.file | Angiver placering af log4j properties |
databasecheck.statement.consent | Se databasemonitorering beskrevet i afsnit 4.3.1.2. |
databasecheck.statement.what | |
databasecheck.statement.who | |
whitelistds.statement | |
servicestatuscheck.database.failurethreshold | Antal kald til lokal database der må fejle før der meldes 500 på statussnitfladen |
wsdl.app.endpoint | Det endpoint, hvor servicen bor. Dette anvendes af wsdl servlet til at returnere en korrekt service location. |
dk.nsi.consent.valid.from.allowed.skew.seconds | Angiver i sekunder, hvor langt tilbage i tide validFrom-tidsstemplet må ligge i forhold til 'nu'. |
| nas.notification.endpoint | Angiver det endpoint, som Cprindlæseren skal kalde NAS notification service på. |
| nas.topic | Angiver det Topic, som skal anvendes, når der sendes notifications til NAS. |
| client.minlog.properties | Angiver placering af properties til kald af |
I den properties-fil, der udpeges af propertien ”client.minlog.properties”, skal følgende properties defineres:
...
registration.wsdl.location
...
Angiver service endpoint for MinLogRegistration-service
...
registration.invoker.timeout
...
Angiver hvor lang tid kaldet til minlog registration kan hænge før invokeren opgiver og melder timeout fejl
...
registration.log.organisation_name
...
Angiver standard organisationsnavnet, der bliver sendt til MinLog Registreringsservicen.
...
servicestatuscheck.minlog.failurethreshold
...
Antal kald til MinLog der må fejle før der meldes 500 på statussnitfladen
...
servicestatuscheck.database.failurethreshold
...
Antal kald til lokal database der må fejle før der meldes 500 på statussnitfladen
...
Kafka topic som anvendes i forbindelse med kald til minlog2
| MinLog2 | |
| default.creating.system.name | I IDWS tilfældet er det dette navn der bliver brugt på spærringerne som oprettene system. |
| dk.nsp.minspaerring.administration.national.rolle | Den nationale rolle, der er krævet for at en sundhedsfaglig kan anvende admin-snitfladen |
| dk.nsp.minspaerring.administration.rediger.minlog.tekst | Den tekst, der skrives i minlog, når en sundhedsfaglig redigerer en spærring på vegne af en ikke digital borger |
| dk.nsp.minspaerring.administration.tilfoj.minlog.tekst | Den tekst, der skrives i minlog, når en sundhedsfaglig tilføjer en spærring på vegne af en ikke digital borger |
| dk.nsp.minspaerring.administration.ophaev.minlog.tekst | Den tekst, der skrives i minlog, når en sundhedsfaglig ophæver en spærring på vegne af en ikke digital borger |
| dk.nsp.minspaerring.administration.hent.minlog.tekst | Den tekst, der skrives i minlog, når en sundhedsfaglig indhenter oplysninger om spærringer på vegne af en ikke digital borger |
I den properties-fil, der udpeges af propertien ”client.minlog.properties”, skal følgende properties defineres:
registration.log.organisation_name | Angiver standard organisationsnavnet, der bliver sendt til MinLog Registreringsservicen. |
| kafka.producer.bootstrap.servers | Kafka endpoint, som anvendes i forbindelse med kald til MinLog2 |
| kafka.producer.client.id | Navnet som Samtykkeservicen vil fremgå med i listen af Producers på et Kafka Cluster. |
| kafka.producer.key.serializer | Serializer key for Kafka producer |
| kafka.producer.key.value.serializer | Serializer value for Kafka producer |
| kafka.topic | Kafka topic som anvendes i forbindelse med kald til MinLog2 |
Følgende properties skal være defineret, for at starte servicen op med DGWS-sikkerhed i forbindelse med adviseringer til NAS:
| idcard.subject.id.type | Subjecttype for IDKortet |
| idcard.subject.id | Subjectid for IDKortet |
| idcard.subject.name | Subjectnavn for IDKortet |
| idcard.level | Sikkerhedsniveau for IDkortet |
| idcard.system.name | Systemnavn i IDkortet |
| sts.endpoint | Endpointet, hvor Samtykkeservicen skal trække sit SOSI IDkort på baggrund af sts.keystore |
| sts.keystore | Keystore, der indeholder DDS Repository funktionscertifikat |
| sts.keystore.password | Password til sts.keystore |
Følgende properties skal være defineret når Samtykkeservicen skal kalde SAES, SORES og SYES ifm. parametervalidering:
dk.nsi.app.name | Navn på system til SLA-logning. |
dk.nsi.app.shortName | Kort navn på system til SLA-logning |
Følgende properties skal være defineret, for at starte servicen op med DGWS-sikkerhed i forbindelse med adviseringer til NAS:
...
Følgende properties skal være defineret når Minspærring skal kalde SAES, SORES og SYES ifm. parametervalidering:
dk.nsi.app.name | Navn på system til SLA-logning. | ||||
dk.nsi.app.shortName | Kort navn på system til SLA-logning. | ||||
dk.nsi.consent.sor.service.url | SORES endpoint. | ||||
dk.nsi.consent.validate.healthcare.professional.cpr | Flag der angiver om cpr-nummer på sundhedsfaglige personer skal valideres ved kald til SAES, når der oprettes eller ændres spærringer. | ||||
dk.nsi.consent.validate.organization | Flag der angiver om organisationsnumre (SOR-, SHAK- og ydernummer) skal valideres ved kald til SORES og SYES, når der oprettes eller ændres spærringer. | ||||
dk.nsi.consent.sor. | failservice. | thresholdurl | Grænse for hvor mange gange SORES-kald må fejle i træk, før SORES opfattes som usundSORES endpoint. | ||
dk.nsi.consent. | sorvalidate. | maxhealthcare. | totalprofessional. | connectionsMaksimalt antal samtidige SORES-forbindelsercpr | Flag der angiver om cpr-nummer på sundhedsfaglige personer skal valideres ved kald til SAES, når der oprettes eller ændres spærringer. |
dk.nsi.consent.sor.default.max.connections.per.routeMaksimalt antal SORES-forbindelser per rutevalidate.organization | Flag der angiver om organisationsnumre (SOR-, SHAK- og ydernummer) skal valideres ved kald til SORES og SYES, når der oprettes eller ændres spærringer. | ||||
dk.nsi.consent.saessor.fail.threshold | Grænse for hvor mange gange SAESSORES-kald må fejle i træk, før SAES SORES opfattes som usund. | ||||
dk.nsi.consent.saessor.connectmax.timeouttotal.millisconnections | Maksimalt antal samtidige SORES-forbindelserGrænse for hvor tid det må tage at oprette forbindelse til SAES (i ms.). | ||||
dk.nsi.consent.sor.saesdefault.max.readconnections.timeoutper.millisroute | Maksimalt antal SORES-forbindelser per ruteGrænse for hvor tid det må tage at modtage svar fra SAES (i ms.). | ||||
dk.nsi.consent.saes.servicefail.urlthreshold | SAES endpoint. | dk.nsi.consent.syes.fail.threshold | Grænse for hvor mange gange SYESGrænse for hvor mange gange SAES-kald må fejle i træk, før SYES SAES opfattes som usund. | ||
dk.nsi.consent.syessaes.connect.timeout.millis | Grænse for hvor tid det må tage at oprette forbindelse til SYES SAES (i ms.). | ||||
dk.nsi.consent.syessaes.read.timeout.millis | Grænse for hvor tid det må tage at modtage svar fra SYES SAES (i ms.). | ||||
dk.nsi.consent.syessaes.service.url | SYES SAES endpoint. |
Eksempel på ”ConsentAdministration.properties” fil (bemærk at ”client.minlog.properties” udpeger filen selv, og at Min-log-klient properties derfor er defineret i samme fil):
| Code Block |
|---|
idcard.version = 1.0.1
sts.test.mode = false
log.config.file=consentadministration.log4j.properties
client.minlog.properties = ConsentAdministration.properties
registration.wsdl.location = http://localhost:8080/minlog-registration/service?wsdl
registration.invoker.timeout = 30000
registration.log.organisation_name=(organisationsnavn blev ikke udfyldt på registreringstidspunktet)
databasecheck.statement.consent=SELECT * FROM consent.consentitem LIMIT 1;
databasecheck.statement.what=SELECT * FROM consent.whatitem LIMIT 1;
databasecheck.statement.who=SELECT * FROM consent.whoitem LIMIT 1;
whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1;
servicestatuscheck.minlog.failurethreshold = 1
servicestatuscheck.database.failurethreshold = 1
idcard.subject.id.type = medcom:cvrnumber
idcard.subject.id = 46837428
idcard.subject.name = NETS DANID A/S - TU VOCES gyldig
idcard.level = 3
idcard.system.name = MinSpærring
sts.endpoint = http://test1-cnsp.ekstern-test.nspop.dk:8080/sts/services/SecurityTokenService
sts.keystore = Statens_Serum_Institut_VOCES.jks
sts.keystore.password = Test1234 |
log4j konfiguration
Log4j konfiguration findes i (hvis ovenstående format anvendes) consentadministration.log4j.properties filen.
Se yderligere opsætning i installationsvejledningen.
SLA-log konfiguration
Konfiguration af SLA-log findes i filen nspslalog-consentadministration.properties.
DKS konfiguration
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses af DDS Registry fra filen:
| Code Block |
|---|
/pack/wildfly8/modules/nsi/consentadministration/config/main/dksConfiguration.xml |
Filen skal overholde DKS XML-skemaet og beskriver de webservice-operationer Min Spærring administrationsservicen udstiller jf. [DKS-beskrivelse].
Test af DKS
Efter konfiguration og deployering af Min Spærring administrationsservicen, kan DKS-snitfladen testes med:
| Code Block |
|---|
curl –i localhost:8081/consent-administration/dccconfig/dks |
Succesfuldt svar giver indholdet svarende til dksConfiguration.xml nævnt ovenfor.
Test af versionsnummer
Efter konfiguration og deploy af Min Spærring administrationsservicen kan versionsnummeret hentes via en HTTP-snitflade.
| Code Block |
|---|
curl –i http://localhost:8081/consent-administration/info/version |
hvilket giver output I stil med:
| Code Block |
|---|
version 1.1.2 |
I eksemplet kørte servicen på en local maskine konfigureret til port 9090.
Min Spærring verifikation
Service konfiguration
Grundlæggende konfiguration foregår ved redigering i filen ConsentVerification.properties, der placeres i følgende WildFly modul:
| Code Block |
|---|
/pack/wildfly8/modules/nsi/consentverification/config/main/ |
I denne skal følgende properties være definerede:
...
Property
...
Beskrivelse
...
idcard.version
...
Servicen afviser kald, hvor ID-kort i Security-header ikke har versionsnummer opgivet som værdien af denne property. Angives til 1.0.1
...
sts.test.mode
...
Angiver med værdien true at servicen benytter test-STS. Værdien skal være ’false’ i drift, hvorved den rigtige SOSI-STS anvendes.
...
log.config.file
...
Angiver placering af log4j properties.
...
databasecheck.statement.consent
...
Se databasemonitorering beskrevet i afsnit 4.3.1.2.
...
databasecheck.statement.what
...
databasecheck.statement.who
...
whitelistds.statement
...
servicestatuscheck.database.failurethreshold
...
Antal kald til lokal database der må fejle før der meldes 500 på statussnitfladen
...
dk.nsi.app.name
...
Navn på system til SLA-logning.
...
dk.nsi.app.shortName
...
Kort navn på system til SLA-logning.
...
dk.nsi.consent.sor.service.url
...
SORES endpoint.
...
dk.nsi.consent.sor.fail.threshold
...
Grænse for hvor mange gange SORES-kald må fejle i træk, før SORES opfattes som usund.
...
dk.nsi.consent.sor.max.total.connections
...
dk.nsi.consent.sor.default.max.connections.per.route
...
dk.nsi.consent.syes.fail.threshold | Grænse for hvor mange gange SYES-kald må fejle i træk, før SYES opfattes som usund. |
dk.nsi.consent.syes.connect.timeout.millis | Grænse for hvor tid det må tage at oprette forbindelse til SYES (i ms.). |
dk.nsi.consent.syes.read.timeout.millis | Grænse for hvor tid det må tage at modtage svar fra SYES (i ms.). |
dk.nsi.consent.syes.service.url | SYES endpoint. |
Følgende properties skal være defineret når Samtykkeservicen skal kalde cpexists ifm. validering af borgerens cpr-nummer:
dk.nsi.consent.validate.citizen.cpr.url | cprexists endpoint. |
dk.nsi.consent.validate.citizen.cpr.dgws.validation.level | Værdi der angiver om cpr-validering er slået til i dgws-snitfladerne. Skal være enten OFF, WARNING eller REJECT. OFF betyder at der ikke foretages nogen validering. WARNING betyder at der foretages validering, og skrives til audit-loggen hvis cpr-nummeret ikke er gyldigt, men kaldet fortsætter (key i audit-loggen: dk.nsp.cpr.exists.false). REJECT betyder at udførslen af kaldet fejler. |
dk.nsi.consent.validate.citizen.cpr.idws.validation.level | Værdi der angiver om cpr-validering er slået til i idws-snitfladerne. Skal være enten OFF, WARNING eller REJECT. OFF betyder at der ikke foretages nogen validering. WARNING betyder at der foretages validering, og skrives til audit-loggen hvis cpr-nummeret ikke er gyldigt, men kaldet fortsætter (key i audit-loggen: dk.nsp.cpr.exists.false). REJECT betyder at udførslen af kaldet fejler. |
dk.nsi.consent.validate.citizen.cpr.max.total.connections | Maksimalt antal samtidige cprexists-forbindelser. |
dk.nsi.consent.validate.citizen.cpr.default.max.connections.per.route | Maksimalt antal cprexists-forbindelser per rute. |
Eksempel på ”ConsentAdministration.properties” fil (bemærk at ”client.minlog.properties” udpeger filen selv, og at Min-log-klient properties derfor er defineret i samme fil):
| Code Block |
|---|
idcard.version = 1.0.1
sts.test.mode = false
log.config.file=consentadministration.log4j.properties
client.minlog.properties = ConsentAdministration.properties
registration.wsdl.location = http://localhost:8080/minlog-registration/service?wsdl
registration.invoker.timeout = 30000
registration.log.organisation_name=(organisationsnavn blev ikke udfyldt på registreringstidspunktet)
databasecheck.statement.consent=SELECT * FROM consent.consentitem LIMIT 1;
databasecheck.statement.what=SELECT * FROM consent.whatitem LIMIT 1;
databasecheck.statement.who=SELECT * FROM consent.whoitem LIMIT 1;
whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1;
servicestatuscheck.database.failurethreshold = 1
wsdl.app.endpoint = http://localhost:8080/consent-verification/
idcard.subject.id.type = medcom:cvrnumber
idcard.subject.id = 46837428
idcard.subject.name = NETS DANID A/S - TU VOCES gyldig
idcard.level = 3
idcard.system.name = Samtykkeservicen sts.endpoint = http://test1-cnsp.ekstern-test.nspop.dk:8080/sts/services/SecurityTokenService
sts.keystore = Statens_Serum_Institut_VOCES.jks
sts.keystore.password = Test1234
# Kafka
kafka.producer.bootstrap.servers=kafka:9092
kafka.producer.client.id=MinSpaerringMinLog2-producer
kafka.producer.key.serializer=org.apache.kafka.common.serialization.StringSerializer
kafka.producer.value.serializer=org.apache.kafka.common.serialization.StringSerializer
kafka.topic=MIT_TOPIC
# Ikke digitale
dk.nsp.minspaerring.administration.national.rolle=urn:dk:healthcare:national-federation-role:code:41001:value:SundAssistR1
dk.nsp.minspaerring.administration.rediger.minlog.tekst=Sundhedsperson har redigeret spærringer for en borger
dk.nsp.minspaerring.administration.tilfoj.minlog.tekst=Sundhedsperson har tilføjet spærringer for en borger
dk.nsp.minspaerring.administration.ophaev.minlog.tekst=Sundhedsperson har ophævet spærringer for en borger
dk.nsp.minspaerring.administration.hent.minlog.tekst=Sundhedsperson har indhentet oplysninger om spærringer for en borger |
log4j
Eksempel på properties fil:
| Code Block |
|---|
idcard.version = 1.0.1
sts.test.mode = false
log.config.file=consentverification.log4j.properties
databasecheck.statement.consent=SELECT * FROM consent.consentitem LIMIT 1;
databasecheck.statement.what=SELECT * FROM consent.whatitem LIMIT 1;
databasecheck.statement.who=SELECT * FROM consent.whoitem LIMIT 1;
whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1;
servicestatuscheck.database.failurethreshold = 1 |
...
konfiguration
Log4j konfiguration findes i (hvis ovenstående format anvendes) consentverificationconsentadministration.log4j.properties filen.
Se yderligere opsætning i installationsvejledningen.
SLA-log konfiguration
Konfiguration af SLA-log findes i filen nspslalog-consentverificationconsentadministration.properties.
DKS konfiguration
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses af Min Spærring verifikationsservicen DDS Registry fra filen:
| Code Block |
|---|
/pack/wildfly8/modules/nsi/consentverificationconsentadministration/config/main/dksConfiguration.xml |
Filen skal overholde DKS XML-skemaet og beskriver de webservice-operationer Min Spærring verifikationsservicen Samtykkeservicen administrationsservicen udstiller jf. [DKS-beskrivelse].
Test af DKS
Efter konfiguration og deployering af Min Spærring verifikationsservicenSamtykkeservicen administrationsservicen, kan DKS-snitfladen testes med:
| Code Block |
|---|
curl –i localhost:80808081/consent-verificationadministration/dccconfig/dks |
Succesfuldt svar giver indholdet svarende til dksConfiguration.xml nævnt ovenfor.
Test af versionsnummer
Efter konfiguration og deploy af Min Spærring verifikationsservicen Samtykkeservicen administrationsservicen kan versionsnummeret hentes via en HTTP-snitflade:.
| Code Block |
|---|
curl –i http://localhost:80808081/consent-verificationadministration/info/version |
hvilket giver output I stil med:
| Code Block |
|---|
Versionversion 1.1.2 |
I eksemplet kørte servicen på en lokal local maskine konfigureret til port 9090.
Monitoreringssnitflader på Min Spærring services
Til monitorering af Min Spærring services findes to servicespecifikke sniflader: servicecheck og status, beskrevet i det følgende.
Servicecheck-snitfladen
Servicecheck-snitflade for Min Spærring servicen, der kaldes under opstart af servicen, kontrollerer tilgængelighed (og i et vist omfang indhold) af property-filer og afprøver aktivt forbindelsen til databaser.
Specielt vedrørende testConnection på JBoss
På grund af en kendt fejl i JBoss 6, logges en række exceptions i server loggen, hvis følgende filer ikke findes (de må gerne være tomme):
| Code Block |
|---|
/pack/jboss/server/default/conf/props/roles.properties
/pack/jboss/server/default/conf/props/users.properties |
Konfiguration af databasemonitorering
Databasemonitoreringen fungerer ved at lave en simpel query mod Min Spærring databasens tabeller. Der laves en query mod hver tabel. Disse queries er justerbare og kan ændres i hhv. ConsentAdministration.properties og ConsentVerification.properties.
| Code Block |
|---|
databasecheck.statement.consent=SELECT * FROM consent.consentitem LIMIT 1;
databasecheck.statement.what=SELECT * FROM consent.whatitem LIMIT 1;
databasecheck.statement.who=SELECT * FROM consent.whoitem LIMIT 1;
whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1; |
Test af Servicecheck-snitfladen
Til Servicecheck-snitfladen findes en servlet i Min Spærring services.
Efter konfiguration og deploy af Min Spærring servicen, kan den testes med:
| Code Block |
|---|
curl –i localhost:8081/consent-administration/info/servicecheck
curl –i localhost:8080/consent-verification/info/servicecheck |
Servicen returnerer følgende http koder:
Der returneres http kode 200 ved normal situation.
http fejlkode 404 returneres hvis servicen ikke er deployeret
Hvis databasen ikke er tilgængelig eller ved intern fejl i WildFly returneres kode 500. Fejlbeskeden vil kunne ses i consentadministration-servicecheck.log eller consentverification-servicecheck.log alt efter hvilken service der er kaldt. Såfremt der ikke er nogen fejlbeskeder i loggen bør property-filen undersøges som det første, da det er herigennem logindstillingerne bestemmes.
Status-snitfladen
Status-snitfladen laver passiv opsamling af resultater ved kald af database hhv. Min Spærring administrationsservicens kald af MinLog-servicen. Status-snitfladen opsamler data på hvor mange kald til database og MinLog-service, der er fejlet, og melder fejl hvis det overstiger de threshold-værdier, der er defineret i property-filen for hhv. Min Spærring administrationsservicen og Min Spærring verifikationsservicen.
Test af monitorering af status
Efter konfiguration og deploy af Min Spærring services, kan den testes med:
| Code Block |
|---|
curl –i localhost:8081/consent-administration/info/status
curl –i localhost:8080/consent-verification/info/status |
Servicen returnerer følgende http koder:
...
Der returneres http kode 200 ved normal situation.
...
http fejlkode 404 returneres hvis servicen ikke er deployeret
...
Samtykkeservicen verifikation
Service konfiguration
Grundlæggende konfiguration foregår ved redigering i filen ConsentVerification.properties, der placeres i følgende WildFly modul:
| Code Block |
|---|
/pack/wildfly8/modules/nsi/consentverification/config/main/ |
I denne skal følgende properties være definerede:
Property | Beskrivelse |
|---|---|
idcard.version | Servicen afviser kald, hvor ID-kort i Security-header ikke har versionsnummer opgivet som værdien af denne property. Angives til 1.0.1 |
sts.test.mode | Angiver med værdien true at servicen benytter test-STS. Værdien skal være ’false’ i drift, hvorved den rigtige SOSI-STS anvendes. |
log.config.file | Angiver placering af log4j properties. |
databasecheck.statement.consent | Se databasemonitorering beskrevet i afsnit 4.3.1.2. |
databasecheck.statement.what | |
databasecheck.statement.who | |
whitelistds.statement | |
servicestatuscheck.database.failurethreshold | Antal kald til lokal database der må fejle før der meldes 500 på statussnitfladen |
wsdl.app.endpoint | Det endpoint, hvor servicen bor. Dette anvendes af wsdl servlet til at returnere en korrekt service location. |
dk.nsi.app.name | Navn på system til SLA-logning. |
dk.nsi.app.shortName | Kort navn på system til SLA-logning. |
dk.nsi.consent.sor.service.url | SORES endpoint. |
dk.nsi.consent.sor.fail.threshold | Grænse for hvor mange gange SORES-kald må fejle i træk, før SORES opfattes som usund. |
dk.nsi.consent.sor.max.total.connections | Maksimalt antal samtidige SORES-forbindelser. |
dk.nsi.consent.sor.default.max.connections.per.route | Maksimalt antal SORES-forbindelser per rute. |
Eksempel på properties fil:
| Code Block |
|---|
idcard.version = 1.0.1
sts.test.mode = false
log.config.file=consentverification.log4j.properties
databasecheck.statement.consent=SELECT * FROM consent.consentitem LIMIT 1;
databasecheck.statement.what=SELECT * FROM consent.whatitem LIMIT 1;
databasecheck.statement.who=SELECT * FROM consent.whoitem LIMIT 1;
whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1;
servicestatuscheck.database.failurethreshold = 1
wsdl.app.endpoint=http://localhost:8081/consent-administration/ |
Log4j konfiguration
Log4j konfiguration findes i (hvis ovenstående format anvendes) consentverification.log4j.properties filen.
Se yderligere opsætning i installationsvejledningen.
SLA-log konfiguration
Konfiguration af SLA-log findes i filen nspslalog-consentverification.properties.
DKS konfiguration
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses af Samtykkeservicen verifikationsservicen fra filen:
| Code Block |
|---|
/pack/wildfly8/modules/nsi/consentverification/config/main/dksConfiguration.xml |
Filen skal overholde DKS XML-skemaet og beskriver de webservice-operationer Samtykkeservicen verifikationsservicen udstiller jf. [DKS-beskrivelse].
Test af DKS
Efter konfiguration og deployering af Samtykkeservicen verifikationsservicen, kan DKS-snitfladen testes med:
| Code Block |
|---|
curl –i localhost:8080/consent-verification/dccconfig/dks |
Succesfuldt svar giver indholdet svarende til dksConfiguration.xml nævnt ovenfor.
Test af versionsnummer
Efter konfiguration og deploy af Samtykkeservicen verifikationsservicen kan versionsnummeret hentes via en HTTP-snitflade:
| Code Block |
|---|
curl http://localhost:8080/consent-verification/info/version |
hvilket giver output I stil med:
| Code Block |
|---|
Version 1.1.2 |
I eksemplet kørte servicen på en lokal maskine konfigureret til port 9090.
Monitoreringssnitflader på Samtykkeservicen
Til monitorering af Samtykkeservicen findes en servicespecifik status-sniflade. Med servicespecifik menes, at der findes en udgave for hhv. administration- og verification-servicen. Snitfladen beskrives i det følgende.
Status-snitfladen
Status-snitfladen kaldes under opstart af servicen, kontrollerer tilgængelighed (og i et vist omfang indhold) af property-filer og afprøver aktivt forbindelsen til databaser. Snitfladen laver endvidere passiv opsamling af resultater ved kald af database. Status-snitfladen opsamler data på hvor mange kald til database, der er fejlet, og melder fejl hvis det overstiger de threshold-værdier, der er defineret i property-filen for hhv. Samtykkeservicen administrationsservicen og Samtykkeservicen verifikationsservicen.
Konfiguration af databasemonitorering
Databasemonitoreringen fungerer ved at lave en simpel query mod Samtykkeservicen databasens tabeller. Der laves en query mod hver tabel. Disse queries er justerbare og kan ændres i hhv. ConsentAdministration.properties og ConsentVerification.properties.
| Code Block |
|---|
databasecheck.statement.consent=SELECT * FROM consent.consentitem LIMIT 1;
databasecheck.statement.what=SELECT * FROM consent.whatitem LIMIT 1;
databasecheck.statement.who=SELECT * FROM consent.whoitem LIMIT 1;
whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1; |
Test af monitorering af status
Efter konfiguration og deploy af Samtykkeservicen services, kan den testes med:
| Code Block |
|---|
curl –i localhost:8081/consent-administration/info/status
curl –i localhost:8080/consent-verification/info/status |
Servicen returnerer følgende http koder:
Der returneres http kode 200 ved normal situation.
http fejlkode 404 returneres hvis servicen ikke er deployeret
Hvis en eller flere af afhængighederne mangler eller ved intern fejl i WildFly returneres kode 500.
Svaret indeholder information om, hvilke tjek der er udført, og om de gik godt eller dårligt. Nedenfor vises et eksempel på et sådan svar, ved kørsel af curl -i http://localhost:8080/consent-verification/info/status:
| Code Block |
|---|
HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/8
Transfer-Encoding: chunked
Content-Type: text/plain;charset=ISO-8859-1
Date: Fri, 15 Jul 2022 08:59:48 GMT
200 OK
Component: consent-verification-service
Test run: Fri Jul 15 10:59:48 CEST 2022
Deployed: Fri Jul 15 10:57:11 CEST 2022
Properties check: All expected properties located in property file.
Datasource health check: All expected datasources available.
Datasource stability check: OK
Certikatudløbsdato: 2025-04-29
SOR liveness check: OK. |
Resultatet af de udførte tjek bliver også skrevet til en af filerne consentadministration-status.log og consentverification-status.log. Såfremt der ikke er
...
nogle fejlbeskeder i loggen bør property-filen undersøges som det første, da det er herigennem logindstillingerne bestemmes.
Overvågning
Min Spærring Samtykkeservicen verifikations- og administrationsservices overvåges af en servicespecifik servicechecksnitflade samt en statussnitflade. Disse snitfladers url’er kan aflæses i afsnit 2.
Placering af HTML overvågningsside
Under listen af komponenter først i dette dokument, er der henvisninger til overvågningssiderne.
Fortolkning af HTML overvågningsside
Alle overvågningssider returnerer enten status 200 hvis de i øjeblikket kører fint, status 404 hvis service ikke er deployed og status 500, hvis der er opstået en fejl, og komponenten derfor ikke virker korrekt.
Overvågningstype
Simpel webside deployeret på serveren. Som udgangspunkt overvåges følgende:
Tilstedeværelse og indhold af propertyfil
Forbindelse til datasources via JNDI opslag
Logfiler og fortolkning af disse
Alle logfiler er at finde i log/ under WildFly. Herunder findes en liste over alle logfiler med en beskrivelse af hvilke komponenter der skriver til dem.
Logfilnavn | Komponenter der skriver til denne |
|---|---|
consentadministration.log | consent-administration |
consent-audit.log | consent-administration |
nsputil-sla-consentadministration.logconsent-administrationconsentadministration-servicecheck.log | consent-administration |
consentadministration-status.log | consent-administration |
consentverification.log | consent-verification |
consent-audit.log | consent-verification |
nsputil-sla-consentverification.logconsent-verificationconsentverification-servicecheck.log | consent-verification |
consentverification-status.log | consent-verification |
For alle webservices er der en tilhørende SLA-log, der sørger for at logge udvalgte elementer fra requests til webservicen. For Min Spærring Samtykkeservicen Services logges alle kald til ConsentAdministrationBean og ConsentVerificationBean til hver deres log. Loggen indeholder informationer om de kald der er lavet til webservicen, herunder hvilken serviceoperation der er kaldt og behandlingstid for kaldet.
SLA-logpunkter for indkommende kald til Min Spærring Samtykkeservicen administration:
ConsentRegistrationsGet
ConsentAdd
ConsentModify
ConsentRevoke
SLA-logpunkter for udgående kald fra Min Spærring administration:
...
Kaldte service
...
LogPoint
...
TargetSOAPOperation
...
MinLog
...
...
LogDataAdd
SLA-logpunkter for indkommende kald til Min Spærring Samtykkeservicen verificering:
ConsentForUserCheck
ConsentForDataCheck
ConsentForForeignersCheck
Auditlogning is done using the official NSP Audit Log modul.
De forskellige håndtag logges på følgende måde.
...
Samtykkeservicen verificering Audit data
| Komponent | Kontekst | Type | Nøgle | Information | consentConsentForUserCheck | Personlige | patient-cpr | CPR nummer på patient om hvem samtykke unsersøges |
|---|---|---|---|---|---|---|---|---|
| bruger-cpr | CPR nummer på brugeren der kalder services | |||||||
| consent | ConsentForUserCheck | Personlige | on-behalf-of-cpr | CPR nummer på sundhedsfaglig servicen kaldes på vegne afvirksomhed-id | Identifikation af brugerens organisation | |||
| virksomhed-id-type | Typen på identifikationen af brugerens organisation | |||||||
| Ikke personlige | CVR | CVR på brugerens organisation | ||||||
| FlowId | Identifikation af aktuelt flow | |||||||
| Følsomme | samtykke-indikator | Værdien af samtykke check; POSITIVE, NEGATIVE eller DATA_SPECIFIC_CONSENT | ConsentForDataCheckPersonlige | patient-cpr | CPR nummer på patient om hvem samtykke unsersøges | |||
| bruger-cpr | CPR nummer på brugeren der kalder services | |||||||
| on-behalf-of-cprCPR nummer på sundhedsfaglig servicen kaldes på vegne af-cpr | CPR nummer på sundhedsfaglig servicen kaldes på vegne af | |||||||
| samtykke-indikator | Værdien af samtykke check; POSITIVE, NEGATIVE eller DATA_SPECIFIC_CONSENT | |||||||
| ConsentForDataCheck | Personlige | virksomhed-id | Identifikation af brugerens organisation | |||||
| virksomhed-id-type | Typen på identifikationen af brugerens organisation | |||||||
| Ikke personlige | queryDataRegistration.[0..n].id | Data hvor der skal checkes for data specifikt samtykke. Der kan forespørges på flere data typer ad gangem, så nøglen har en fortløbende værdi indlejret. | ||||||
| queryDataRegistration.[0..n].virksomhed-id | ||||||||
| queryDataRegistration.[0..n].virksomhed-id-type | ||||||||
| queryDataRegistration.[0..n].oprettet-dato-tid | ||||||||
| CVR | CVR på brugerens organisation | |||||||
| FlowId | Identifikation af aktuelt flow | |||||||
| Følsomme | patient-cpr | CPR nummer på patient om hvem samtykke unsersøges | ||||||
| bruger-cpr | CPR nummer på brugeren der kalder services | |||||||
| on-behalf-of-cpr | CPR nummer på sundhedsfaglig servicen kaldes på vegne af | |||||||
| positiv-samtykke-id-liste | En liste af identer på data typer | , som har positivt samtykke., som har positivt samtykke. | ||||||
| ConsentForForeignersCheck | Personlige | |||||||
| Ikke personlige | CVR | CVR på brugerens organisation | ||||||
| FlowId | Identifikation af aktuelt flow | |||||||
| Følsomme | ConsentForForeignersCheck | Personligepatient-cpr | CPR nummer på patient om hvem samtykke unsersøges | |||||
| bruger-cpr | CPR nummer på brugeren der kalder services | |||||||
| Ikke personlige | CVR | CVR på brugerens organisation | ||||||
| FlowId | Identifikation af aktuelt flow | |||||||
| samtykke-til-udenlandsk-sundhedsperson | Værdien af check for samtykke til udenlandsk sundhedsperson; POSITIVE eller NEGATIVE |
Type mapning mellem ovenstående tabel og faktisk data i fil: Personlig = RegularPersonalInformation/RPI, Ikke personlig = NonPersonalInformation/NPI og Følsomme = SensitivePersonalInformation/SPI
Standard fejlsøgning
Ved problemer med indlæsning af servicens konfigurationsfil (ConsentVerification.properties eller ConsentAdministration.properties) bør man verificere at filen ligger korrekt i modul folderen. Vær opmærksom på at filen ikke læses, hvis den ikke er til stede ved opstart af WildFly serveren.
Ved manglende logning hvor der forventes fejlbeskeder bør konfigurationsfiler (ConsentVerification.properties, ConsentAdministration.properties) checkes, da logindstillingerne sættes herigennem.
Servicen kan genstartes ved at genstarte den docker container som servicen kører i.
Krav til backup m.m.
Databasen til Min Spærring Samtykkeservicen administration skal sikres med backup.
Derudover anbefales sikring af aktuelle konfigurationsfiler til Min Spærring Samtykkeservicen services.