...

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:

I den/de properties-filer, der udpeges af de forskellige ”client.*.properties” properties skal flg. properties defineres:

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.

...

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

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 Log4j konfiguration findes i (hvis ovenstående format anvendes) compose/configuration/ddsrepository/ddsrepository.log4j.properties filen.

...

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 CVR-nummer til white-list databasen, bruges følgende For at tilføje et CVR-nummer til white-list databasen, bruges følgende SQL insert:

INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsrepository', '', 'some-cvr-number-here' );

...

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:

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:

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:

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,

• 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: [‘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:

...

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:

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:

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.

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:

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.

...