Page History
...
Komponenten afvikles i et docker-compose setup, som ligger under https://svn.nspop.dk/svn/components/dds/trunk/compose.
...
I filen skal følgende properties være definerede:
Property | Beskrivelse | Værdi | |
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. | ||
client.documentrepository.properties | Angiver placering af properties til kald af dokumentkilder, hvor snitfladen til indhentning af dokument benytter Den Gode Webservice. | ||
client.consentverification.properties | Angiver placering af properties til kald af Samtykkeverifikationsservicen. | ||
client.minlogregistration.properties | Angiver placering af properties til kald af MinLog Registreringsservicen. | ||
client.treatment.relation.properties | Angiver placering af properties til kald af behandlingsrelationsservicen. | ||
treatment.relation.service.invoke | Angiver med værdien true, at behandlingsrelationsservicen skal kaldes. Værdien false bevirker, at behandlingsrelationsservicen ikke kaldes. | ||
minlog.retrieve.default | Teksten der sendes til MinLog registreringsservicen, når en sundhedsperson laver dataudtræk. | ||
minlog.retrieve.consentoverride | Teksten der sendes til MinLog registreringsservicen, når en sundhedsperson laver dataudtræk med tilsidesættelse af samtykketjek (værdispring). | ||
servicestatuscheck.consentverification.failurethreshold | Antal kald til samtykkeverifikationsservicen der må fejle før der meldes 500 på statussnitfladen. | ||
servicestatuscheck.treatmentrelation.failurethreshold | Antal kald til BRS der må fejle før der meldes 500 på statussnitfladen. | ||
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. | ||
servicestatuscheck.unlockdelay | Antal sekunder fra statussnitfladen melder 500 til at antal fejl kald nulstilles. | ||
repository.retrieve.documents.processing.timeout | Antal millisekunder, der afventes svar fra kaldt XDS Repository med henblik på at samle svar fra eventuelt flere kaldte XDS Repositories til videre processering. Dette er ikke en timeout på kaldet til XDS Repository, der i stedet er konfigureret i documentsource-tabellen i databasen jf. afsnit 4.1.5. | ||
retrieved.documents.processing.timeout | Antal millisekunder, der afventes færdiggørelse af efterprocessering af svar med henblik på at samle efterprocesserede svar i det samlede svar. Dette er ikke en timeout, der bevirker udelukkelse af svar. | ||
sts.keystore | Keystore, der indeholder DDS Repository funktionscertifikat | ||
sts.keystore.password | Password til sts.keystore | ||
sts.endpoint | Endpointet, hvor DDS Repository skal trække sit SOSI IDkort på baggrund af sts.keystore | ||
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 | ||
whitelisted.level3.cvrs | Liste Liste (kommasepareret) af whitelistede CVR numre og certifikater som DDS'en tillader | (kommasepareretkald med niveau 3 Idkort fra (se afsnit nedenfor vedr. whitelisting for detaljer vedr. format) | |
dds.citizen.powerofattorney.privileges | Det fuldmagtsprivilegie, der tillader at en borger tilgår en anden borgers data via DDS | ||
dds.minlog.on.idcard.level3.enabled | Angiver, om DDS skal minlogge, når der kaldes med SOSI Idkort niveau 3 | Skal sættes (true/false) |
I den/de properties-filer, der udpeges af de forskellige ”client.*.properties” properties skal flg. properties defineres:
verification.wsdl.location | Angiver service endpoint for Samtykkeverifikationsservicen |
registration.log.organisation_name | Angiver standard organisationsnavnet, der bliver sendt til MinLog Registreringsservicen. |
treatment.relation.wsdl.location | Angiver service endpoint for behandlingsrelationsservicen |
treatment.relation.service.timeout | Timeout givet i millisekunder anvendt ved kald til behandlingsrelationsservicen |
verification.invoker.timeout | Timeout givet i millisekunder anvendt ved kald til samtykke verifikationsservicen. |
minlog.producer.bootstrap.servers | Kafka bootstrap servers der anvendes til MinLog registrering. |
minlog.producer.client.id | Kafka klient id anvendt til MinLog registrering. |
minlog.producer.key.serializer | Kafka key serializer. Skal være "org.apache.kafka.common.serialization.StringSerializer" |
minlog.producer.value.serializer | Kafka value serializer. Skal være "org.apache.kafka.common.serialization.StringSerializer" |
minlog.topic | Kafka topic til MinLog registrering. |
personinformation.maxTotalConnections | Konfiguration af client pool til kald af CPRExists service |
personinformation.defaultMaxConnectionsPerRoute | Konfiguration af client pool til kald af CPRExists service |
personinformation.url | Peger på endpointet for PersonInformationServicen. |
Udover ovenstående skal følgende Udover ovenstående skal følgende angives i den properties fil, der er udpeget i propertien ”client.treatment.relation.properties”. Disse forholder sig til værdier i SOAP requesten til behandlingsrelationsservicen og de følgende beskrivelser refererer til elementer i denne.
...
Code Block |
---|
idcard.version = 1.0.1 sts.test.mode = true repository.service.name = Dokumentdelingsservicen log.config.file=ddsrepository.log4j.properties client.documentrepository.properties = DDSRepository.properties client.consentverification.properties = DDSRepository.properties client.minlog .properties = DDSRepository.properties client.treatment.relation.properties = DDSRepository.properties treatment.relation.service.invoke=true treatment.relation.service.invoke=true treatment.relation.service.timeout=3000 treatment.relation.wsdl.location = http://localhost:9090/ddsservices-brs-stub/BRSFacadeService/BRSFacadeStub?wsdl verification.wsdl.location=http://localhost:9090/consent-verification/service?wsdl verification.invoker.timeout=30000 treatment.relation.serviceprovider.vendor=vendor treatment.relation.serviceprovider.version=version treatment.relation.lookup.timeinterval.start.offset=-1 treatment.relation.lookup.timeinterval.end.offset=1 treatment.relation.timelimit.offset=90 treatment.relation.queryable.cvr=19343634 treatment.relation.external.reference.id= treatment.relation.acceptable.relations.hospital=A,B,C treatment.relation.followup.relations.hospital=All treatment.relation.acceptable.relations.doctor=C,D,E treatment.relation.followup.relations.doctor=All treatment.relation.acceptable.relations.organization=A,B,C treatment.relation.followup.relations.organization=All documentsourcesds.statement=SELECT * FROM documentsources.documentsource LIMIT 1; sords.statement=SELECT * FROM stamdata.SORRelationer LIMIT 1; authds.statement=SELECT * FROM stamdata.autreg LIMIT 1; whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1; servicestatuscheck.consentverification.failurethreshold = 1 servicestatuscheck.treatmentrelation.failurethreshold = 1 servicestatuscheck.minlog.failurethreshold = 1 servicestatuscheck.database.failurethreshold = 1 repository.retrieve.documents.processing.timeout = 200 retrieved.documents.processing.timeout = 200 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 = Dokumentdelingsservicen sts.endpoint = http://test1-cnsp.ekstern-test.nspop.dk:8080/sts/services/SecurityTokenService sts.keystore = Statens_Serum_Institut_VOCES.jks sts.keystore.password = Test1234 minlog.producer.bootstrap.servers=kafka:9092 minlog.producer.client.id=DdsMinLog2-producer minlog.producer.key.serializer=org.apache.kafka.common.serialization.StringSerializer minlog.producer.value.serializer=org.apache.kafka.common.serialization.StringSerializer minlog.topic=MINLOG_TOPIC |
Log4j Konfiguration
Log4j konfiguration findes i (hvis ovenstående format anvendes) compose/configuration/ddsrepository/ddsrepository.log4j.properties filen.
Se yderligere opsætning i installationsvejledningen.
SLA-log konfiguration
dds.minlog.on.idcard.level3.enabled=true
personinformation.maxTotalConnections=200
personinformation.defaultMaxConnectionsPerRoute=20
personinformation.url=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/v1 |
Log4j Konfiguration
Log4j konfiguration findes i (hvis ovenstående format anvendes) compose/configuration/ddsrepository/ddsrepository.log4j.properties filen.
Se yderligere opsætning i installationsvejledningen.
SLA-log konfiguration
SLA-SLA-logning på DDS Repository udføres vha SLALoggingInterceptor,
Konfiguration af SLA-log findes i filen compose/configuration/ddsrepository/nspslalog-ddsrepository.properties.
Whitelist konfiguration
Der foretages whitelisting på to niveauer. Først er der den whitelisting, der skal til for at anvende DDS Repository. Derudover findes en whitelisting, der afgør, hvorvidt en anvender må kalde DDS Repository med et niveua 3 Idkort. De to whitelisting-mekanismer beskrives i det følgende.
Whitelisting til anvendelse af DDS Repository
For at tilføje et For at tilføje et CVR-nummer til white-list databasen, bruges følgende SQL insert:
...
Code Block |
---|
INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.auth.brs.cvr.list', '', 'some-cvr-number-here' ); INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.consent.verification', '', 'some-cvr-number-here' ); INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.minlog.registration', '', 'some-cvr-number-here' ); |
DocumentSources konfiguration
For at tilføje et kildesystem til documentsource databasen, bruges følgende SQL insert:
Code Block |
---|
INSERT INTO `documentsource` (`oid`, `type`, `service_endpoint`, `soap_version`, `timeout`, `failurethreshold`)
VALUES ('some_unique_id','[unique_id_type]','some_endpoint','[SOAP_version] ', '[timeout]', '[failure threshold]'); |
...
Whitelisting til kald med niveau 3 Idkort
Alle anvendere skal whitelistes som beskrevet ovenfor for at anvende DDS Repository. Derudover findes en ekstra whitelisting mekanisme, som gør det muligt for visse anvendere at kalde DDS Repository med et niveau 3 Idkort. Dette kræver en særlig whitelisting og kan sættes op ved at tilføje oplysninger om anvenderen i konfigurationsparameteren 'whitelisted.level3.cvrs'. På trods af navnet kan whitelisting til niveau 3 sættes op på to niveauer: CVR nummer eller et specifikt certifikat.
Værdien er en kommasepereret liste som vist i følgende eksempel:
Code Block | ||
---|---|---|
| ||
whitelisted.level3.cvrs=31908574,CVR:46837428,CERT:CVR:33257872-FID:28250866 |
Eksemplet viser de tre formater, der kan anvendes:
- Værdi uden type: I eksempelt ovenfor fortolkes værdien '31908574' som et CVR nummer. Dette sikrer bagudkompatibilietet med tidligere opsætninger
- Værdier med typen CVR: I eksemplet ovenfor fortolkes 'CVR:46837428' som et CVR nummer med værdien 46837428
- Værdier med typen CERT: I eksemplet ovenfor fortolkes 'CERT:CVR:33257872-FID:28250866' som whitelisting af certificatet med Subject Serial Number CVR:33257872-FID:28250866.
I forhold til anvenderne, så tjekkes det, om der er en whitelisting af anvenderens CVR nummer og hvis dette ikke er tilfældet, så tjekkes, om det specifikke certifikat, der anvendes er whitelistet. Alle andre forsøg på adgang med niveau 3 Idkort afvises.
DocumentSources konfiguration
For at tilføje et kildesystem til documentsource databasen, bruges følgende SQL insert:
Code Block |
---|
INSERT INTO `documentsource` (`oid`, `type`, `service_endpoint`, `soap_version`, `timeout`, `failurethreshold`)
VALUES ('some_unique_id','[unique_id_type]','some_endpoint','[SOAP_version] ', '[timeout]', '[failure threshold]'); |
oid: OID værdien som for den pågældende XDS dokument kilde, som kan være at typen ’repository_unique_id’ eller’home_community_id’
type: Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier: [‘repository_unique_id’|’home_community_id’]
service_endpoint: Angiver URL til XDS dokument kilde
soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:
Værdi | Benytter HSUID udgående | Benytter DGWS udgående |
1.1 | + | ÷ |
1.2 | + | ÷ |
1.1_NO_HSUID | ÷ | ÷ |
1.2_NO_HSUID | ÷ | ÷ |
1.2_DGWS | + | + |
1.2_DGWS_NO_HSUID | ÷ | + |
1.2_DGWS_NO_ADDR | + | + |
1.2_MEDCOM_NO_HSUID | ÷ | (+) Kun Medcom-header |
Værdien 1.2_DGWS_NO_ADDR benyttes, når WS-Addressing ikke ønskes anvendt.
timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.
failurethreshold: Angiver grænseværdi for hvor mange kald mod repositoriet der må fejle før monitoreringssnitfladen melder fejl. Angives som heltal.
Kombinationen oid og unique_id_type skal være unik.
DKS Konfiguration
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses af DDS Repository fra filen:
Code Block |
---|
/pack/wildfly8/modules/nsi/ddsrepository/config/main/dksConfiguration.xml |
Filen skal overholde DKS XML-skemaet og beskriver de webservice-operationer DDS Repository udstiller jf. [DKS-beskrivelse].
Test af DKS
Efter konfiguration og deployering af DDS Repository servicen, kan DKS-snitfladen testes med:
Code Block |
---|
curl –i localhost:9090/ddsrepository/dccconfig/dks |
Succesfuldt svar giver indholdet svarende til dksConfiguration.xml nævnt ovenfor.
Header konfiguration
Det er muligt at konfigurere repository'et til at lede efter HTTP- og SOAP-headere, og videresende dem til bagvedliggende registries. Videresendelse styres af databasetabellen documentsources.documentsource_forwarded_header. Indholdet af tabellen er som følger:
Feltnavn | Indhold |
---|---|
headername | Navn på header, der ledes efter. Hvis headertype er 'HTTP', ledes i HTTP-headers i requestet. Hvis headertype er 'SOAP', ledes i headere i SOAP-envelopen i requestet. |
headertype | Typen af header der ledes efter. Kan være 'HTTP' eller 'SOAP', skrevet med store bogstaver. |
oid | oid på repository, som header ønskes videresendt til. Der er opsat en foreign key-constraint, der sikrer at der refereres til et registry i documentsource-tabellen. |
Monitorering af DDSRepository
Til statuscheck af DDSRepository findes en servicecheck servlet der kalder servicens afhængigheder, samt en statuscheck servlet der monitorerer de kald der foretages fra DDSRepository. Begge servlets udstiller http-snitflader som melder 500 ved fejl.
Test af versionsnummer
Efter konfiguration og deploy af DDS Repository kan versionsnummeret hentes med følgende kommando:
Code Block |
---|
curl localhost:9090/ddsrepository/version |
hvilket giver output i stil med:
Code Block |
---|
Version: 2.0.0 |
I eksemplet kørte servicen på en lokal maskine konfigureret til port 9090.
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/ |
type: Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier: [‘repository_unique_id’|’home_community_id’]
service_endpoint: Angiver URL til XDS dokument kilde
soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:
...
Værdi
...
Benytter HSUID udgående
...
Benytter DGWS udgående
...
1.1
...
+
...
÷
...
1.2
...
+
...
÷
...
1.1_NO_HSUID
...
÷
...
÷
...
1.2_NO_HSUID
...
÷
...
÷
...
1.2_DGWS
...
+
...
+
...
1.2_DGWS_NO_HSUID
...
÷
...
+
...
1.2_DGWS_NO_ADDR
...
+
...
+
...
1.2_MEDCOM_NO_HSUID
...
÷
...
(+)
Kun Medcom-header
Værdien 1.2_DGWS_NO_ADDR benyttes, når WS-Addressing ikke ønskes anvendt.
timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.
failurethreshold: Angiver grænseværdi for hvor mange kald mod repositoriet der må fejle før monitoreringssnitfladen melder fejl. Angives som heltal.
Kombinationen oid og unique_id_type skal være unik.
DKS Konfiguration
Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses af DDS Repository fra filen:
Code Block |
---|
/pack/wildfly8/modules/nsi/ddsrepository/config/main/dksConfiguration.xml |
Filen skal overholde DKS XML-skemaet og beskriver de webservice-operationer DDS Repository udstiller jf. [DKS-beskrivelse].
Test af DKS
Efter konfiguration og deployering af DDS Repository servicen, kan DKS-snitfladen testes med:
Code Block |
---|
curl –i localhost:9090/ddsrepository/dccconfig/dks |
Succesfuldt svar giver indholdet svarende til dksConfiguration.xml nævnt ovenfor.
Header konfiguration
Det er muligt at konfigurere repository'et til at lede efter HTTP- og SOAP-headere, og videresende dem til bagvedliggende registries. Videresendelse styres af databasetabellen documentsources.documentsource_forwarded_header. Indholdet af tabellen er som følger:
...
Monitorering af DDSRepository
Til statuscheck af DDSRepository findes en servicecheck servlet der kalder servicens afhængigheder, samt en statuscheck servlet der monitorerer de kald der foretages fra DDSRepository. Begge servlets udstiller http-snitflader som melder 500 ved fejl.
Test af versionsnummer
Efter konfiguration og deploy af DDS Repository kan versionsnummeret hentes med følgende kommando:
Code Block |
---|
curl localhost:9090/ddsrepository/version |
hvilket giver output i stil med:
Code Block |
---|
Version: 2.0.0 |
I eksemplet kørte servicen på en lokal maskine konfigureret til port 9090.
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 |
...
Code Block |
---|
documentsourcesds.statement=SELECT * FROM documentsources. documentsource LIMIT 1; sords.statement=SELECT * FROM stamdata.sorrelationer LIMIT 1; authds.statement=SELECT * FROM stamdata.autreg LIMIT 1; whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1; FROM stamdata.autreg LIMIT 1; whitelistds.statement=SELECT * FROM whitelist.whitelist_config LIMIT 1; |
Test af monitorering af afhængigheder
Til Monitorering af afhængigheder til egen propertyfil, og trådmanager og egen database findes en servlet i DDSRepository.
Efter konfiguration og deploy af DDSRepository, kan den testes med:
Code Block |
---|
curl –i localhost:9090/ddsrepository/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 en eller flere af afhængighederne mangler eller ved intern fejl i WildFly returneres kode 500. Fejlbeskeden vil kunne ses i ddsrepository-servicecheck.log. 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.
Test af monitorering af
...
status
Til Monitorering af afhængigheder til egen propertyfil, og trådmanager og egen database findes en servlet i DDSRepositoryforbindelser til BRS, MinLog, SamtykkeVerifikationsservice, PersonInformation, repositories og egen database findes en servlet i DDSRepository. Denne service opsamler data på hvor mange kald til de forskellige andre services der er fejlet, og melder fejl hvis det overstiger de threshold-værdier der er defineret i property-filen.
Efter konfiguration og deploy af DDSRepository, kan den testes med:
Code Block |
---|
curl –i localhost:9090/ddsrepository/servicecheckstatus |
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. Fejlbeskeden interne afhængighederne har fejlet nok gange til at nå deres grænseværdi returneres kode 203.
Hvis en eller flere af ekserne afhængighederne (minlog osv) har fejlet nok gange til at nå deres grænseværdi returneres kode 500.
Bemærk at DDSRepository anvender ”service_endpoint”til identifikation af de forskellige repositories.
Fejlbeskeder vil kunne ses i
...
ddsregistry-
...
status.log.
...
Opsamlingen af kald til en service der fejler nulstilles automatisk efter et antal sekunder. Dette styrres med en properti, servicestatuscheck.unlockdelay.
Nulstilling af opsamling af kald
Opsamlingen af kald der benyttes til monitoring af status kan nustilles. Servicen resetstatuscounters nulstiller alle de opsamlede data omkring fejlkald der har været siden sidste nulstilling.
Der skrives i statusloggen når denne service har været brugt.
Code Block | ||
---|---|---|
| ||
curl -i http:// |
Test af monitorering af status
Til Monitorering af forbindelser til BRS, MinLog, SamtykkeVerifikationsservice, repositories og egen database findes en servlet i DDSRepository. Denne service opsamler data på hvor mange kald til de forskellige andre services der er fejlet, og melder fejl hvis det overstiger de threshold-værdier der er defineret i property-filen.
Efter konfiguration og deploy af DDSRepository, kan den testes med:
Code Block |
---|
curl –i localhost:9090/ddsrepository/statusresetstatuscounters |
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 har fejlet nok gange til at nå deres grænseværdi returneres kode 500. Fejlbeskeden vil kunne ses i ddsrepository-status.log. Såfremt et repository i en fejlende tilstand fjernes fra konfigurationen, vil det vedblive med at forårsage status kode 500. Dette kan afhjælpes ved at gendeployere servicen.
- Bemærk at DDSRepository anvender ”service_endpoint”til identifikation af de forskellige repositories.
Overvågning
DDS Repository overvåges af en servicespecifik servicechecksnitflade, samt en statussnitflade. Disse to snitfladers url’er kan aflæses i afsnit 2.
...