Indholdsfortegnelse

Introduktion

Formål

Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.

Driftsvejledningen indeholder information om GM-BFF med hensyn til eksterne afhængigheder, standard placering af logfiler og konfigurationsfiler, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.

I afsnit 3 (Komponenter) er beskrevet hvilke komponenter, der indgår i GM-BFF og deres forventede placering med hensyn til platform.

Afsnit 5 (Konfiguration) beskriver aktuelle konfigurationsparametre for GM-BFF henholdsvis Repository, samt eksempler på konfigurationsparameter-filer.

Afsnit 6.1, 6.2 og 6.3 (Overvågning) beskriver hvorledes GM-BFF komponenterne overvåges.

I afsnit 6.4 er GM-BFF-relaterede logfiler beskrevet, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning.

Beskrivelse af standard fejlsøgning og start/stop vejledning for komponenterne er beskrevet i afsnit 7 (Standard fejlsøgning).

Specielle krav til backup er beskrevet i afsnit 8 (Krav til backup m.m.), ligesom procedure ved reetablering af komponenten ud fra backup beskrives.

Læsevejledning

Læseren forventes at have kendskab til ....

Definitioner og referencer

Definition	Beskrivelse
NSP	Den nationale service platform
SDS	Sundhedsdatastyrelsen

Komponenter

Dette dokument dækker følgende komponenter:

Daglig drift

Dette afsnit beskriver den daglige drift af systemet.

Relaterede services

Konfiguration

Komponenterne afvikles i et ??? setup, som ligger under ???

log4j konfiguration

Log4j konfiguration findes i (hvis ovenstående format anvendes):

For DDS registry: compose/configuration/ddsregistry/ddsregistry.log4j.properties filen.
For DDS repository: compose/configuration/ddsrepository/ddsrepository.log4j.properties filen

Se yderligere opsætning i installationsvejledningen.

SLA-log konfiguration

SLA-logning på DDS Registry og Repository udføres vha SLALoggingInterceptor. Konfiguration af SLA-log findes i filen:

For DDS registry: compose/configuration/ddsregistry/nspslalog-ddsregistry.properties.
For DDS repository: 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 Registry og Repository. Derudover findes en whitelisting, der afgør, hvorvidt en anvender må kalde DDS med et niveua 3 Idkort. De to whitelisting-mekanismer beskrives i det følgende.

Whitelisting til anvendelse af DDS Registry og Repository

For at tilføje et CVR-nummer til white-list databasen, bruges følgende SQL insert:

For DDS registry:

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

For DDS repository:

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

Da DDS Registry og Repository sender Id-kortet videre til samtykkeservice, behandlingsrelationsservice og minlog-registrationservice skal whitelisten også opdateres med følgende værdier:

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' );

Whitelisting til kald med niveau 3 Idkort

Alle anvendere skal whitelistes som beskrevet ovenfor for at anvende DDS Registry og Repository. Derudover findes en ekstra whitelisting mekanisme, som gør det muligt for visse anvendere at kalde DDS Registry og 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:

Opsætning af niveau 3 whitelisting

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.

Dokumenttype konfiguration af registry

For at konfigurere hvilke dokumenttyper, der er relevante for et givet registry, skal dette konfigureres manuelt af driften i documenttype_configuration databasen:

INSERT INTO documentsources.documenttype_configuration (documentregistryid, typecode_codename, typecode_schemename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"), "39289-4", "2.16.840.1.113883.6.1");

Hvis ikke man har angivet en unik documentregistryfriendlyname værdi i documentregistry, må man manuelt finde det givne documentregistryid man ønsker at konfigurere en dokumenttype for.

Hvis et givet documentregistry ikke har en opsætning i documenttype_configuration tabellen, er alle dokumenttyper tilladte.

Servicen skal genstartes for at ændringen træder i kraft, da data indlæses ved opstart.

Feature konfiguration af registry

For at konfigurere hvilke feature, der er relevante for et givet registry, skal dette konfigureres manuelt af driften i feature_configuration databasen:

INSERT INTO documentsources.feature_configuration (documentregistryid, featurename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"), "GET_DOCUMENTS_QRY"); INSERT INTO documentsources.feature_configuration (documentregistryid, featurename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"), "FIND_DOCUMENTS_QRY"); INSERT INTO documentsources.feature_configuration (documentregistryid, featurename) VALUES ((select documentregistryid from documentsources.documentregistry where documentregistryfriendlyname = "DDS"), "FIND_DOCUMENTS_BY_REFERENCE_QRY");

Hvis ikke man har angivet en unik documentregistryfriendlyname værdi i documentregistry, må man manuelt finde det givne documentregistryid man ønsker at konfigurere en feature for.

Pt er ovenstående 3 features mulige. De anvendes, når der laves en ITI-18 søgning (Registry Stored Query). Hvis det indkomne request ikke matcher opsætningen for et givet registry, søges der ikke ned i dette registry. Dvs. at har et registry ingen opsætning af query types, bliver det aldrig kaldt.

Servicen skal genstartes for at ændringen træder i kraft, da data indlæses ved opstart.

Metadata konfiguration af dokument filtrering

For at konfigurere, hvordan dokumenternes metadata skal filtreres for den sundhedsfaglige, skal det konfigureres manuelt af driften i en række whitelist tabeller i databasen:

insert into whitelist.whitelist_config_documentmetadata (cvr, system_name) values ('12345602', 'Service Consumer Test');

insert into whitelist.whitelist_config_documentmetadata_typecode (whitelist_id, typecode_codename, typecode_schemename) values ( (select id from whitelist.whitelist_config_documentmetadata where cvr = '12345602' and system_name = 'Service Consumer Test'), '39289-4', '2.16.840.1.113883.6.1');

insert into whitelist.whitelist_config_documentmetadata_eventcode (whitelist_id, eventcode_name, eventcode_schemename)values ( (select id from whitelist.whitelist_config_documentmetadata where cvr = '12345602' and system_name = 'Service Consumer Test'), 'eventCode1', '1.2.208.176.2.1');

insert into whitelist.whitelist_config_documentmetadata_practicesettingcode (whitelist_id, practicesettingcode_codename, practicesettingcode_schemename)values ( (select id from whitelist.whitelist_config_documentmetadata where cvr = '12345602' and system_name = 'Service Consumer Test'), '408443003', '2.16.840.1.113883.6.96');

Ovenstående er eksempler på sql. Udskift værdierne med relevante værdier for at aktuelle miljø.

Som minimum skal der åbnes op for typecode i whitelist_config_documentmetadata_typecode tabellen. Derudover kan dokumenter returnering indsnævres ved yderligere at angive eventcode og practicesettingcode. Er der for et cvr/system angivet bare een værdi for eventcode, skal dokumentes metadata indeholde denne kode. Tilsvarerende for practicesettingcode. Ellers filtreres metadata fra, og anvenderen får en fejl i svaret.

Der filtreres kun, hvis funktionaliteten er aktiveret. Den kan slåes fra med property whitelisted.document.metadata.active.

Konfigurationen indlæses automatisk peridisk, som angivet i property whitelisted.document.metadata.refresh.duration.

Actor Query Parameter validering konfiguration

Nogle actors har ikke love til at lave søgninger (ITI-18) på alle værdier i query parametrene. Dette konfigureret i manuelt af driften i en tabel i databasen.

INSERT INTO documentsources.actor_query_parameter_configuration (actorquerytype, typecode_codename, typecode_schemename, formatcode_codename, formatcode_schemename, privilege)

VALUES ("CitizenUserOnBehalfAsProxyHolder","39289-4", "2.16.840.1.113883.6.1", "urn:ad:dk:medcom:appointment", "1.2.208.184.100.10", "urn:dk:nspop:sts:dds:read");

Ovenstående er eksempler på sql. Udskift værdierne med relevante værdier for at aktuelle miljø og anvendere.

For nuværende drejer det sig om følgende brugertyper og de skal konfigureres på følgende måde:

Borger med fuldmagt vha. fuldmagtsstrenge og konfiguration for åbning at tilladelse til fremsøgning indsættes i databasen med
- actorquerytype: skal være CitizenUserOnBehalfAsProxyHolder
- typecode_codename og typecode_schemename: typecode som reglen gælder for, begge felter skal udfyldes.
- formatcode_codename og formatcode_schemename: hvis der er krav til formatcode udfyldes begge felter. Blanke felter betyder alle format codes tillades
- privilege: angiv det fuldmagtsprivilege som borgeren skal have får at måtte fremsøge på typecode og formatcode angivet.

Minlog Tekst konfiguration ved søgning (iti-18)

Hvis man ønsker at anvende en mere detaljeret opsætning af tekster, der sendes til minlog, gøres det ved at manuelt at indsætte records i tabellerne minlog_text og minlog_usertype_text. Findes der ikke matchende data heri anvendes de default værdier, der er sat op i servicens property fil.

INSERT INTO minlog_text (typecode_codename, typecode_schemename, formatcode_codename, formatcode_schemename, classcode_codename, classcode_schemename, text) VALUES ('11502-2', '2.16.840.1.113883.6.1', 'urn:ad:dk:medcom:labreports:svareksponeringsservice', '1.2.208.184.100.10', '001', '1.2.208.184.100.9', 'Opslag på labsvar fra %s');

INSERT INTO minlog_usertype_text (usertype, text) VALUES ('professionalUser', 'sundhedsfaglig');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('professionalUserConsentOverride', 'Sundhedsfaglig hvor samtykker tilsidesættes');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('childCustodyHolder', 'forældremyndighedsindehaver');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('proxyHolder', 'fuldmagtshaver');
INSERT INTO minlog_usertype_text (usertype, text) VALUES ('citizen', 'borger');

For minlog_usertype_text skal de angivne usertype anvendes, da disse er kendt af komponenten.

En match ved søgning sker ved at kigge på typecode, classcode og formatcode fra requestet samt anvender rollen og med disse slå op i tabellerne. For en mere detaljeret beskrivelse af denne logik se dds design og arkitektur dokumentet.

Hvis der ikke kan findes en opsætning i databasen for en given typecode, classcode og formatcode kombination, skrives en warning til applikationsloggen, så man har mulighed for at holde øje med anvendte, men ikke konfigurerede kombinationer.

Ved hentning af dokumenter (iti-43) anvendes altid værdierne fra property filen.

Hvis den fremfundne minlog tekst overstiger den maksimale længde, som minlog kan modtage (pt 75 karakterer), afkortes teksten og en fejl skriver i applikationsloggen. For lange tekster fejlmeldes også i forbindelse med servicens status endpoint. Her vil det fremgå, hvis mindst en minlog tekst er for lang (kan være en kombinationer af tekst og den tilføjede brugertype tekst). Alle ugyldige tekster kan efter kald til status endpoint findes som fejl i applikationsloggen.

DKS konfiguration

Indholdet, der returneres ved kald af DCC Konfiguration Service-snitfladen (DKS), indlæses fra filen:

Fra DDS registry: /pack/wildfly8/modules/nsi/ddsregistry/config/main/dksConfiguration.xml
Fra DDS repository: /pack/wildfly8/modules/nsi/ddsrepository/config/main/dksConfiguration.xml

Filerne skal overholde DKS XML-skemaet og beskriver de webservice-operationer DDS Registry udstiller jf. [DKS-beskrivelse].

Test af DKS

Efter konfiguration og deployering af DDS Registry og Repository servicene, kan DKS-snitfladerne testes med:

curl –i localhost:9090/ddsregistry/dccconfig/dks
curl –i localhost:9090/ddsrepository/dccconfig/dks

Succesfuldt svar giver indholdet svarende til filerne nævnt ovenfor.

Header konfiguration

Det er muligt at konfigurere registry og repository til at lede efter HTTP- og SOAP-headere, og videresende dem til bagvedliggende registries.

Videresendelse styres af databasetabellerne

For DDS registry: documentsources.documentregistry_forwarded_header
For DDS repository: documentsources.documentsource_forwarded_header

Indholdet af tabel documentsources.documentregistry_forwarded_header 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.
documentregistryid	Id på documentregistry, som header ønskes videresendt til. Der er opsat en foreign key-constraint, der sikrer at der refereres til et registry i documentregistry-tabellen.

Indholdet af tabel documentsources.documentsource_forwarded_header 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.

DocumentSources konfiguration for DDS repository

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, 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.

Monitorering

Til statuscheck af DDS Registry og Repository findes til hver en servicecheck servlet der kalder servicens afhængigheder, samt en statuscheck servlet der monitorerer de kald der foretages fra DDS Registry og Repository. Alle servlets udstiller http-snitflader som melder 500 ved fejl.

Test af versionsnummer

Efter konfiguration og deploy af DDS Registry og Repository kan versionsnummeret hentes med følgende kommandoer:

curl localhost:9090/ddsregistry/version

curl localhost:9090/ddsrepository/version

hvilket hver giver output i stil med:

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):

/pack/jboss/server/default/conf/props/roles.properties 
/pack/jboss/server/default/conf/props/users.properties

Konfiguration af databasemonitorering

Databasemonitoreringen laver en simpel query mod databasen. Denne query er justbar og kan ændres i servicenes property filer.

DDSRegistry.properties:

documentsourcesds.statement=SELECT * FROM documentsources.documentregistry 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;

DDSRepository.properties:

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;

Test af monitorering af afhængigheder

Til Monitorering af afhængigheder til egen propertyfil, trådmanager, document registry (for DDS registry) og egen database findes en servlet i DDS Registry og Repository. Bemærk at denne snitflade laver kald til databasen og healthshare registry.Efter konfiguration og deploy af komponenterne kan det testes med:

curl –i localhost:9090/ddsregistry/servicecheck

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 ddsregistry-servicecheck.log eller 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 forbindelser til BRS, MinLog, SamtykkeVerifikationsservice, PersonInformation, registries (DDS registry), repositories (DDS Repository), egen database og længde på konfigurerede minlog tekster findes en servlet i DDS Registry og Repository. Disse services opsamler f.eks. 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 komponenterne, kan den testes med:

curl –i localhost:9090/ddsregistry/status

curl –i localhost:9090/ddsrepository/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 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
- DDS Registry anvender ”documentregistryfriendlyname” kombineret med ”documentregistryititransaction” (se afsnit 4.1.1.1) til identifikation af de forskellige indekser.
- DDS Repository anvender ”service_endpoint” til identifikation af de forskellige repositories.

Fejlbeskeder vil kunne ses i ddsregistry-status.log henholdsvis ddsrepository-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.

Nulstil status for DDS Registry:

curl -i http://localhost:9090/ddsregistry/resetstatuscounters

Nulstil status for DDS Repository:

curl -i http://localhost:9090/ddsrepository/resetstatuscounters

Servicen returnerer følgende http koder:

Der returneres http kode 200 ved normal situation.

Overvågning

DDS Registry og Repository overvåges hver af en servicespecifik servicechecksnitflade, samt en statussnitflade. Disse to 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 servicen ikke er deployeret, 203 mange fejl fra intern dds kald (DDS registry) 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
Forbindelse til document registry for DDS registry
Konfiguration af trådmanager

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. Hvorvidt der anvendes disse default-logfilnavne eller skrives til andre, er afhængig af servicens konfiguration af log4j.

DDS Registry:

Logfilnavn	Komponenter der skriver til logfilen	Beskrivelse
ddsregistry.log	DDS Registry	Generel applikationslog
dds-audit.log	DDS Registry	Auditlog for indkommende kald af servicens operationer
nsputil-sla-ddsregistry.log	DDS Registry	SLA-log
ddsregistry-consentoverride.log	DDS Registry	Log over anvendelse af værdispring ved kald af servicens operationer
ddsregistry-servicecheck.log	DDS Registry	Logfil for aktivt servicecheck
ddsregistry-status.log	DDS Registry	Logfil for passivt opsamlet status på webservice- og database-kald.
ddsregistry-xdserror.log	DDS Registry	Logfil for XDS-fejl indlejret i svar samt fejl ved kald af eksterne XDS-komponenter.

DDS Repository:

Logfilnavn	Komponenter der skriver til logfilen	Beskrivelse
ddsrepository.log	DDS Repository	Generel applikationslog
dds-audit.log	DDS Repository	Auditlog for indkommende kald af servicens operationer
nsputil-sla-ddsrepository.log	DDS Repository	SLA-log
ddsrepository-consentoverride.log	DDS Repository	Log over anvendelse af værdispring ved kald af servicens operationer
ddsrepository-servicecheck.log	DDS Repository	Logfil for aktivt servicecheck
ddsrepository-status.log	DDS Repository	Logfil for passivt opsamlet status på webservice- og database-kald.
ddsrepository-xdserror.log	DDS Repository	Logfil for XDS-fejl indlejret i svar samt fejl ved kald af eksterne XDS-komponenter.

SLA log

For alle webservices er der en tilhørende SLA-log, der sørger for at logge udvalgte elementer fra requests til webservicen. For DDS Registry og Repository logges alle kald til DDSRegistryWS henholdsvis DDSRepositoryWS, hvor loggen vil indeholde information om kald til webservicens forskellige serviceoperationer og behandlingstid for kaldet inklusiv kald til kontrolservices.

SLA-logpunkter for indkommende kald til DDS Registry:

DocumentRegistry_RegistryStoredQuery

SLA-logpunkter for udgående kald fra DDS Registry:

Kaldte service	LogPoint	TargetSOAPOperation
Behandlings-relations-service	DocumentRegistry_RegistryStoredQuery.TreatmentRelation	http://nsi.dk/fmki20110601#treatmentRelation
MinLog	DocumentRegistry_RegistryStoredQuery.Minlog.LogDataAdd	LogDataAdd
Samtykke	DocumentRegistry_RegistryStoredQuery.ConsentForUserCheck	urn:dk:nsi:consentservices:verification:service:1#ConsentForUserCheck
Samtykke	DocumentRegistry_RegistryStoredQuery.ConsentForDataCheck	urn:dk:nsi:consentservices:verification:service:1#ConsentForDataCheck
XDS Registry	DocumentRegistry_RegistryStoredQuery	urn:ihe:iti:2007:RegistryStoredQuery

For SLA-logning af udgående kald til XDS Registry:

logges i feltet GenericCallParms desuden det konfigurerede navn for XDS Registry under parameternavnet registryFriendlyName.
logges fejlet kald, på trods af succesfuldt kald, når en eller flere af følgende XDS-fejl/advarsler er indlejret i XDS-fejlstrukturen i svaret:
- XDSMissingHomeCommunityId
- XDSRegistryBusy
- XDSRegistryError, medmindre der er tale om advarsel om tilbageholdte oplysninger grundet samtykker
- XDSRegistryOutOfResources
- XDSUnavailableCommunity
- XDSUnknownCommunity

SLA-logpunkter for indkommende kald til DDS Repository:

DocumentRepository_RetrieveDocumentSet

SLA-logpunkter for udgående kald fra DDS Repository:

Kaldte service	LogPoint	TargetSOAPOperation
Behandlings-relations-service	DocumentRepository_RetrieveDocumentSet.TreatmentRelation	http://nsi.dk/fmki20110601#treatmentRelation
MinLog	DocumentRepository_RetrieveDocumentSet.Minlog.LogDataAdd	LogDataAdd
Samtykke	DocumentRepository_RetrieveDocumentSet.ConsentForUserCheck	urn:dk:nsi:consentservices:verification:service:1#ConsentForUserCheck
Samtykke	DocumentRepository_RetrieveDocumentSet.ConsentForDataCheck	urn:dk:nsi:consentservices:verification:service:1#ConsentForDataCheck
XDS Repository	DocumentRepository_RetrieveDocumentSet	urn:ihe:iti:2007:RetrieveDocumentSet

For SLA-logning af udgående kald til XDS Repository:

logges i feltet GenericCallParms desuden det kaldte XDS Repository’s repositoryUniqueId under parameternavnet repositoryUniqueId.
logges fejlet kald, på trods af succesfuldt kald, når en eller flere af følgende XDS-fejl/advarsler er indlejret i XDS-fejlstrukturen i svaret:
- XDSMissingHomeCommunityId
- XDSRepositoryBusy
- XDSRepositoryError, medmindre der er tale om advarsel om tilbageholdte oplysninger grundet samtykker
- XDSRepositoryOutOfResources
- XDSUnavailableCommunity
- XDSUnknownCommunity
- XDSUnknownRepositoryId

Audit log

Auditlogning foretages med det officielle NSP Audit Log modul.

De forskellige ITI-håndtag logges på følgende måde.

DDS Registry

ITI-18 søgninger logger patient-id, bruger-id, på-vegne-af-id og for hver DocumentEntry (DE) i returneret svar (der kan være frafiltreret metadata pga. samtykker): DE.uniqueId, DE.repositoryUniqueId, DE.homeCommunityId, DE.typeCode. Se eksempel nedenfor:

{ "time":"2024-08-08T09:04:08.341Z", "category":"dk.sds.nsp.audit.log.dds", "audit":{ "timestamp":"2024-08-08T11:04:08.054+02:00", "components":[ { "component":"DDS", "contexts":[ { "context":"documentRegistryAdhocQuery", "information":[ { "key":"patient-cpr", "type":"RPI", "value":"0405732615" }, { "key":"bruger-cpr", "type":"RPI", "value":"1208643298" }, { "key":"on-behalf-of-cpr", "type":"RPI", "value":"0405732615" }, { "key":"citizen-relation", "type":"RPI", "value":"proxyHolder" }, { "key":"queryTypecode", "type":"NPI", "value":"('39289-4^^2.16.840.1.113883.6.1')" }, { "key":"queryFormatcode", "type":"NPI", "value":"EMPTY" }, { "key":"queryEventCode", "type":"NPI", "value":"EMPTY" }, { "key":"queryStartTimeFrom", "type":"NPI", "value":"EMPTY" }, { "key":"queryStartTimeTo", "type":"NPI", "value":"EMPTY" }, { "key":"queryStopTimeFrom", "type":"NPI", "value":"EMPTY" }, { "key":"queryStopTimeTo", "type":"NPI", "value":"EMPTY" }, { "key":"queryAvailabilityStatus", "type":"NPI", "value":"('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')" },

{ "key":"queryDocumententryType", "type":"NPI", "value":"('ondemand'), ('stable')" },

{ "key":"queryReferenceIdList", "type":"NPI", "value":"('ref1_5619531150207761919.7052203964123326052.1537974544002^^^&2.16.840.1.113883.6.1&ISO^ddstest'), ('ref1_5619531150207761919.7052203964123326052.1537974544003^^^&2.16.840.1.113883.6.1&ISO^ddstest')" }, { "key":"document_entry.0.homecommunityid", "type":"SPI", "value":"" }, { "key":"document_entry.0.repositoryid", "type":"SPI", "value":"1.3.6.1.4.1.21367.2010.1.2.1125" }, { "key":"document_entry.0.documentid", "type":"SPI", "value":"0405732615.678401000016005.30001" }, { "key":"document_entry.0.typecode", "type":"SPI", "value":"39289-4" }, { "key":"document_entry.1.homecommunityid", "type":"SPI", "value":"" }, { "key":"document_entry.1.repositoryid", "type":"SPI", "value":"1.3.6.1.4.1.21367.2010.1.2.1125" }, { "key":"document_entry.1.documentid", "type":"SPI", "value":"0405732615.678401000016005.30001" }, { "key":"document_entry.1.typecode", "type":"SPI", "value":"39289-4" } ] } ] }, { "component":"MinLog2", "contexts":[ { "context":"addRegistrations", "information":[ { "key":"added", "type":"SPI", "values":[ "0405732615" ] }, { "key":"failed", "type":"SPI", "values":[ ] } ] } ] } ] }, "access":{ "code":200, "duration":251, "httpHeaders":{ "Content-Type":"text/xml;charset=UTF-8", "SOAPAction":"urn:ihe:iti:2007:RegistryStoredQuery" }, "httpHost":"localhost", "idCardAttributes":{ "medcom:CareProviderID":"33257872", "medcom:CareProviderName":"Sundhedsdatastyrelsen", "medcom:ITSystemName":"Service Consumer Test", "sosi:AuthenticationLevel":"3", "sosi:IDCardID":"yVQdP84H2Am56+nE4goXGA==", "sosi:IDCardType":"system", "sosi:IDCardVersion":"1.0.1" }, "method":"POST", "path":"/ddsregistry", "query":"", "port":9090, "protocol":"http", "reqSize":8854, "resSize":16429, "soapHeaders":{ "FlowID":"137f6e5a-9ed8-49be-b5cd-9122a450470d", "Issuer":"TEST1-NSP-STS", "MessageID":"AAABkTE7L29HtC19NnD1tFNPU0k=", "NameID":"SubjectDN={C=DK, OID.2.5.4.97=NTRDK-33257872, O=Sundhedsdatastyrelsen, SERIALNUMBER=UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6, CN=NSP Test Service Consumer},IssuerDN={C=DK, O=Den Danske Stat, OU=Test - cti, CN=Den Danske Stat OCES udstedende-CA 1},CertSerial={132335570455020580755596658041035235745819139305}" }, "threadId":"default task-5", "time":"2024-08-08T11:04:08.054+02:00", "stats":{ "handlerDuration":31, "RequestContentDuration":1, "ResponseContentDuration":0, "SecurityProtocolRequestDuration":24, "SecurityProtocolResponseDuration":0, "bufferAllocated":false, "usedBuffers":2, "activeBuffersInPool":2, "idleBuffersInPool":8 } } }

DDS Repository

De forskellige ITI-43 operationer logger patient-id, bruger-id, på-vegne-af-id og for hvert dokument i returneret svar (der kan være frafiltreret dokument(er) pga. samtykker, der kan være forespurgt dokumenter, der ikke er tilgængelige): requestens uniqueId, repositoryUniqueId, homeCommunityId.

Eksempel:

{
   "time": "2018-09-27T19:28:53.476Z",
   "category": "dk.sds.nsp.audit.log.dds",
   "audit": {
      "timestamp": "2018-09-27T21:28:52.996+02:00",
      "components": [
         {
            "component": "DDS",
            "contexts": [
               {
                  "context": "documentRepositoryRetrieveDocumentSet",
                  "information": [
                     {
                        "key": "patient-cpr",
                        "type": "SPI",
                        "value": "2110979420"
                     },
                     {
                        "key": "bruger-cpr",
                        "type": "SPI",
                        "value": "0101584160"
                     },
                     {
                        "key": "on-behalf-of-cpr",
                        "type": "SPI",
                        "value": "0101584160"
                     },
                     {
                        "key": "document_entry.0.homecommunityid",
                        "type": "NPI",
                        "value": "urn:oid:1.3.6.1.4.1.21367.2010.1.2.2045"
                     },
                     {
                        "key": "document_entry.0.repositoryid",
                        "type": "NPI",
                        "value": "1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key": "document_entry.0.documentid",
                        "type": "NPI",
                        "value": "8352061236760766124.2930903161888816635.1538046332405"
                     },
                     {
                        "key": "document_entry.1.homecommunityid",
                        "type": "NPI",
                        "value": "urn:oid:1.3.6.1.4.1.21367.2010.1.2.2045"
                     },
                     {
                        "key": "document_entry.1.repositoryid",
                        "type": "NPI",
                        "value": "1.3.6.1.4.1.21367.2010.1.2.1125"
                     },
                     {
                        "key": "document_entry.1.documentid",
                        "type": "NPI",
                        "value": "4869530052539485342.5952203964580776052.1537974946937"
                     }
                  ]
               }
            ]
         }
      ]
   },
   "access": {
      "code": 200,
      "duration": 390,
      "httpHeaders": {
         "Content-Type": "multipart/related; type=\"application/xop+xml\"; boundary=\"uuid:ff2230e6-7a7b-42b5-b8d7-448396803b2b\"; start=\"<root.message@cxf.apache.org>\"; start-info=\"application/soap+xml\""
      },
      "httpHost": "localhost",
      "idCardAttributes": {
         "medcom:CareProviderID": "30808460",
         "medcom:CareProviderName": "NETS DANID A/S",
         "medcom:ITSystemName": "TRUST2408 Systemtest XIX CA",
         "sosi:AuthenticationLevel": "3",
         "sosi:IDCardID": "PJBE7nBkFgG1DN6pvsHUhQ==",
         "sosi:IDCardType": "system",
         "sosi:IDCardVersion": "1.0.1"
      },
      "method": "POST",
      "path": "/ddsrepository/service",
      "query": "",
      "port": 9091,
      "protocol": "http",
      "reqSize": 8962,
      "resSize": 43188,
      "soapHeaders": {
         "Issuer": "TEST1-NSP-STS",
         "MessageID": "AAABZhyBSdBSTccik8TayVNPU0k=",
         "NameID": "SubjectDN={SERIALNUMBER=CVR:30808460-UID:25351738 + CN=NETS DANID A/S - TU VOCES gyldig, O=NETS DANID A/S // CVR:30808460, C=DK},IssuerDN={CN=TRUST2408 Systemtest XIX CA, O=TRUST2408, C=DK},CertSerial={1478025777}",
         "w3Action": "urn:ihe:iti:2007:RetrieveDocumentSet",
         "w3MessageID": "urn:uuid:cde2752b-23a0-4410-b1b7-fd3db1156b5b",
         "w3To": "http://localhost:9091/ddsrepository/service"
      },
      "threadId": "default task-2",
      "time": "2018-09-27T21:28:52.996+02:00",
      "stats": {
         "handlerDuration": 84,
         "bufferAllocated": false,
         "usedBuffers": 2,
         "activeBuffersInPool": 2,
         "idleBuffersInPool": 0
      }
   }
}

Standard fejlsøgning

Ved problemer med indlæsning af servicens konfigurationsfiler (DDSRegistry.properties og DDSRepository.properties) bør man verificere at filen er volume-mappet korrekt. 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 konfigurationsfilen (DDSRegistry.properties og DDSRepository.properties) checkes, da logindstillingerne sættes herigennem.
En service eller et job kan stoppes og startes gennem docker.

Krav til backup m.m.

Det anbefales at aktuelle konfigurationsfiler til DDS Registry og Repository er under versionskontrol og back up.

Dokument Historik

3/4 2025

Martin Henriksen/SDS

Etablering af dokumentation