Introduktion

Formål

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

...

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 National Sundheds-IT’s platform NSP, samt generelt kendskab til WildFly applikationsserver samt Ubuntu Linux operativ system.

Dokumenthistorik

Dette dokument er oprettet i forbindelse med den initielle udviklings af komponenten.

Definitioner og referencer

Komponenten

FSK Registry Adapter komponenten kan beskrives som følger:

• FSK Registry Adapter

• Type: Webservice

• Filnavn: fskregistry.war

• Url: <serverurl>/fskregistry

• Helbredsurl: <serverurl>/fskregistry/health

Daglig drift

Dette afsnit beskriver den daglige drift af systemet.

Database

FSK Registry Adapter anvender en database til persistering og afhentning af metadata. Denne database ejes imidlertid af en anden komponten: FSK Repository. Det er FSK Repository komponentens ansvar at beskrive backupprocedurer for databasen.

Relaterede services

FSK Registry Adapter afhænger af:

...

Ved fejl i forbindelse til denne denne vil FSK Registry Adapter returnere svar til anvendere, hvoraf det fremgår, at der er fejl.

Konfiguration

Opsætningen for kalderen af bookplan servicen konfigueres i AODocumentProvider.properties.

Denne indlæses fra WildFly modulet:

Hvis FSK registry startes vha. docker-compose, så bliver konfigurationsfilerne automatisk flyttet til de foldere, som er angivet docker-compose opskriften.

...

Den primære folder, hvor flest konfigurationsfiler, som skal bruges af FSK registry er:

/pack/wildfly8/modules

...

/sds/fskregistry/configuration/main/

Desuden bruges følgende til deploy af datasource konfigurationer:
/pack/wildfly8/standalone/deployments/

Og til konfiguration af AccessHandler bruges:
/pack/wildfly8/modules/system/layers/base/dk/sds/nsp/accesshandler/main/

Konfiguration af FSK Resgitry

Opsætningen for FSK Registry Adapter sker i propertyfilen fskreg.properties.

Et eksempel på sådan konfiguration er:

cprexists.validationlevel=WARNING
cprexists.url=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-cprexists

documentEntry.title=Fælles stamkort

documentEntry.mimeType=text/xml
documentEntry.languageCode=da-DK

documentEntry.patient.assigningAuthority.root=1.2.208.176.1.2
documentEntry.organisation.assigningAuthority.root

Et eksempel på sådan konfiguration er:

ao.appointmentservice.request.timeout.seconds=120
ao.appointmentservice.request.username=username
ao.appointmentservice.request.password=password
ao.appointmentservice.connection.poolsize=10
ao.appointmentservice.endpoint=http://localhost:9090/appointmentsstub/search/appointments/V1
ao.document.assigning.authority.name=Region Nordjylland Aftaleoversigt
ao.document.root.id=1.2.208.176.99.179.99.98.1.1

Properties beskrives ifølge tabel.

...

ao.appointmentservice.request.timeout.seconds

...

Antal sekunder for hvor lang tid et request mod Bookplan servicen maximalt må tage før forsøget meldes som mislykket.

...

ao.appointmentservice.request.username

...

Brugernavnet der anvendes ved kald til Bookplan

...

ao.appointmentservice.request.password

...

Kodeordet der anvendes ved kald til Bookplan

...

ao.appointmentservice.connection.poolsize

...

Maksimalt antal samtidige kald mod Bookplan servicen.

...

ao.appointmentservice.endpoint

...

Url’en til Bookplan servicen

...

Navnet på oprindelssted for Bookplan data.

...

ao.document.root.id

...

OID for oprindelssted af Bookplan data

Konfiguration af CDA Skabelon

Aftaleoversigt XDS Registry bruger en CDA skabelon til at transformere Bookplan svaret til en række af CDA dokumenter.

Der er i skabelonen indsat placeholdere for genererede værdier. Disse starter og slutter med tegnet ’¤’, som f.eks. ”¤AUTHOR_ADDRESS_STREET¤”. Placeholdere må ikke ændres.

Skabelonen indlæses fra:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/cda_document_template.xml

Konfiguration af dokument-metadata

Dokument-metadata anvendt af Aftaleoversigt XDS Registry Adapter, når der laves opslag på en patient, er defineret i følgende fil:

• aometadataconfiguration.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/

Et eksempel på indhold i aometadataconfiguration.xml:

<metadata>
	<classCode class="codedValue">
 		<code>001</code>
 		<codeSystem>21.1

documentEntry.homeCommunityId=1.2.208.176.8.1.12
documentEntry.repositoryUniqueId=1.2.208.176.43210.8.10.12

documentEntry.healthcareFacilityTypeCode.code=554041000005106
documentEntry.healthcareFacilityTypeCode.schemeName=2.16.840.1.113883.6.96
documentEntry.healthcareFacilityTypeCode.name=sundhedsforvaltning

documentEntry.classCode.code=001
documentEntry.classCode.schemeName=1.2.208.184.100.9
documentEntry.classCode.name=Klinisk rapport

documentEntry.author.organisation.id=1126211000016009
documentEntry.author.organisation.name=Fælles Stamkort udstedelse

documentEntry.practiceSettingCode.code=408443003
documentEntry.practiceSettingCode.schemeName=2.16.840.1.113883.6.96
documentEntry.practiceSettingCode.name=almen medicin

documentEntry.confidentialityCode.code=N
documentEntry.confidentialityCode.schemeName=2.16.840.1.113883.35.420825
documentEntry.100.9</codeSystem>
 		<description>Klinisk rapport</description>
 	</classCode>
 	<confidentialityCode class="codedValue">
 		<code>N</code>
 		<codeSystem>2.16.840.1.113883.5.25</codeSystem>
 		<description>Normal</description>
 	</confidentialityCode>
 	<formatCode class="codedValue">
 		<code>urnconfidentialityCode.name=normal

# formatCodeCode og typeCode par i tabel. Hver par har eget løbenummer
documentEntry.metadata.metadataEntry[0].formatCodeCode=urn:ad:dk:medcom:pdc-v2.0:full
documentEntry.metadata.metadataEntry[0].formatCodeScheme=1.2.208.184.100.10
documentEntry.metadata.metadataEntry[0].formatCodeName=DK PDC schema
documentEntry.metadata.metadataEntry[0].typeCodeCode=PDC
documentEntry.metadata.metadataEntry[0].typeCodeScheme=1.2.208.184.100.1
documentEntry.metadata.metadataEntry[0].typeCodeName=Stamkort

documentEntry.metadata.metadataEntry[1].formatCodeCode=urn:ad:dk:medcom:appointmentsummary:full</code>
 		<codeSystem>2.16.840.1.113883.3.4208.100.10</codeSystem>
 		<description>DK Appointment Summary Document schema</description>
 	</formatCode>
 	<languageCode>da-DK</languageCode>
 	<mimeType>text/xml</mimeType>
 	<practiceSettingCode class="codedValue">
 		<code>Unknown</code>
 		<codeSystem>2.16.840.1.113883.11.10612</codeSystem>
 		<description>Unknown</description>
 	</practiceSettingCode>
 	<typeCode class="codedValue">
 		<code>39289-4</code>
 		<codeSystem>2.16.840.1.113883.6.1</codeSystem>
 		<description>Dato og tidspunkt for møde mellem patient og sundhedsperson</description>
 	</typeCode>
 	<homeCommunityId>1.2.208.176.99.179.99.98</homeCommunityId>
 	<repositoryUniqueId>1.2.208.176.99.179.99.98.1</repositoryUniqueId>
 	<uniqueIdRoot>1.2.208.176.99.179.99.98.1.1</uniqueIdRoot>
 	<healthcareFacilityTypeCode class="codedValue">
 		<code>22232009</code>
 		<codeSystem>1.2.208.176.1.1.2</codeSystem>
 		<description>hospital</description>
 	</healthcareFacilityTypeCode>
 	<authorInstitution class="dk.nsi.documentsharing.core.metadata.model.OrganisationImpl">
 		<name>Region Nordjylland</name>
 		<id class="valueWithAssigningAuthority">
 			<value>6071000016008</value>
 			<assigningAuthority>1.2.208.176.1.1</assigningAuthority>
 		</id>
 		<address class="dk.nsi.documentsharing.core.metadata.model.AddressImpl">
 			<street>Niels Bohrs Vej 20</street>
 			<postalCode>9220</postalCode>
 			<city>Aalborg Øst</city>
 		</address>
 		<telecom class="dk.nsi.documentsharing.core.metadata.model.TelecomImpl">
 			<telecom>97 64 80 00</telecom>
 		</telecom>
 	</authorInstitution>
</metadata>

Konfiguration af filter på dokument-metadata-forespørgsel

Ved opslag på en patient kan der anføres en række søge-parametre. Aftaleoversigt XDS Registry Adapter har logik, der er afhængig af konkrete søge-parametre og konfigureret filter (beskrevet her), fastlægger om den bagvedliggende bookplan service skal kaldes.

Filteret konfigureres i følgende fil:

• aofilterconfiguration.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/

I konfiguration specificeres 0, 1 eller flere kode-sæt i hhv. classCodes, typeCodes, eventCodes, confidentialityCodes og formatCodes.

<filter>
 	<classCodes>
 	</classCodes>
 	<typeCodes>
 	</typeCodes>
 	<eventCodes>
 	</eventCodes>
 	<confidentialityCodes>
 	</confidentialityCodes>
 	<formatCodes>
 	</formatCodes>
</filter>

Hver kode-sæt, består af:

<codedValue>
 	<code>kode-værdi</code>
 	<codeSystem>kode-system</codeSystem>
 	<description>menneskelæselig beskrivelse af kodeværdi</description>
</codedValue>

Filterets classCodes, typeCodes, eventCodes, confidentialityCodes og formatCodes modsvarer lignende navne i søge-parametre, der kan være anført ved kald af Aftaleoversigt XDS Registry Adapter opslag. Er et kodesæt anført i søge-parametre for fx eventCodes, da bevirker filteret et tomt svar, når:

1. Filterets eventCodes ikke er tomt, og

2. Ingen af evt. flere eventCodes fra søge-parametre findes i filterets eventCodes-liste

Tilsvarende logik er gældende de øvrige koder i filteret.

Følgende er et eksempel på konfiguration af filteret:

<filter>
 	<classCodes/>
 	<typeCodes>
 		<codedValue>
 			<code>39289-4</code>
 			<codeSystem>2.16.840.1.113883.6.1</codeSystem>
 			<description>Dato og tidspunkt for møde mellem patient og sundhedsperson</description>
 		</codedValue>
 	</typeCodes>
 	<eventCodes/>
 	<confidentialityCodes>
 		<codedValue>
 			<code>N</code>
 			<codeSystem>2.16.840.1.113883.5.25</codeSystem>
 			<description>Normal</description>
 		</codedValue>
 	</confidentialityCodes>
</filter>

Udpegning af log4j-konfiguration

Følgende fil, der findes under roden i war-filen ao-documentmetadataprovider-<profil-navn>.war, udpeger den fil, der anvendes til konfiguration af log4j:

• documentsharing.log4j.properties

Bemærk, at denne fil (om nødvendigt) skal tilpasses direkte i war-filen og ikke findes i WildFly modulet.

Konfiguration af log4j

Log4j konfiguration findes i følgende fil:

• log4j-ao-documentmetadataprovider-ws.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/

I konfigurationen er det muligt at aktivere performanceloggeren, der udvalgte steder i adapteren, vil skrive tidsvarighed af kald igennem systemet. Performanceloggeren aktiveres ved at ændre level værdien fra ”OFF” til ”DEBUG”. Eftersom konfigurationen kun indlæses ved opstart af servicen, er det nødvendigt at genstarte servicen efter endt redigering af log4j-ao-documentmetadataprovider-ws.xml filen.

Eksempel på konfiguration af performanceloggeren, hvor level værdien er sat til ”OFF”:

<logger name="performancelogger" additivity="false">
 	<level value="OFF" />
 	<appender-ref ref="PerformanceFile" />
</logger>

Som standard skriver performanceloggeren til ao-documentmetadataprovider-ws-performance.log i WildFly’ log-folder.

Se yderligere opsætning i installationsvejledningen.

Udpegning af SLA-log konfiguration

Følgende fil udpeger hvilken fil, der indeholder konfigurationen af SLA-logning:

• nspslalog-ao-documentmetadataprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/

Per default udpeges konfigurationsfilen beskrevet i næste afsnit.

Konfiguration af SLA-log

Per default indlæses konfigurationen af Aftaleoversigt XDS Registry Adapters SLA-logning fra følgende fil:

• log4j-nspslalog-ao-documentmetadataprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/

Konfiguration af Aftaleoversigt XDS Repository Adapter

Konfiguration af dokumentprovider

XDS Repository Adapter konfigureres i følgende fil:

• aoproviderconfiguration.xmll

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentprovider/config/<profil-navn>/

Et eksempel på indhold i aoproviderconfiguration.xml:

<ProviderConfiguration>
     <homeCommunityId>1.2.3.7.8</homeCommunityId>
     <repositoryUniqueId>1.2.3.4.77.88</repositoryUniqueId>
</ProviderConfiguration>

Udpegning af log4j-konfigurationsfil

Følgende fil, der findes under roden i war-filen ao-documentprovider-<profil-navn>.war, udpeger den fil, der anvendes til konfiguration af log4j:

• documentsharing.log4j.properties

Bemærk, at denne fil (om nødvendigt) skal tilpasses direkte i war-filen og ikke findes i WildFly modulet.

Konfiguration af log4j

Log4j konfiguration findes i følgende fil:

• log4j-ao-documentprovider-ws.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentprovider/config/<profil-navn>/

I konfigurationen er det muligt at aktivere performanceloggeren, der udvalgte steder i adapteren, vil skrive tidsvarighed af kald igennem systemet. Performanceloggeren aktiveres ved at ændre level værdien fra ”OFF” til ”DEBUG”. Eftersom konfigurationen kun indlæses ved opstart af servicen, er det nødvendigt at genstarte servicen efter endt redigering af log4j-ao-documentprovider-ws.xml filen.

Eksempel på konfiguration af performanceloggeren, hvor level værdien er sat til ”OFF”:

<logger name="performancelogger" additivity="false">
	<level value="OFF" />
	<appender-ref ref="PerformanceFile" />
</logger>

Som standard skriver performanceloggeren til ao-<profil-navn>-documentprovider-ws-performance.log i WildFly’ log-folder.

Se yderligere opsætning i installationsvejledningen.

Udpegning af SLA-log konfiguration

Følgende fil udpeger hvilken fil, der indeholder konfigurationen af SLA-logning:

• nspslalog-ao-documentprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentprovider/config/<profil-navn>/

Per default udpeges konfigurationsfilen beskrevet i næste afsnit.

Konfiguration af SLA-log

Per default indlæses konfigurationen af Aftaleoversigt XDS Repository Adapters SLA-logning fra følgende fil:

• log4j-nspslalog-ao-documentprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/ao/documentprovider/config/<profil-navn>/

HTTP Statuscheck på komponenter i Aftaleoversigt XDS-adaptere

Det er muligt at lave servicetjek på Aftaleoversigtsadaptere ved brug af den generelle service servicecheck.

For at understøtte servicetjek kræves konfiguration af servicecheck servicen, der er både generel og specifikt for aftaleoversigtsadaptere.

Følgende underafsnit beskriver den nødvendige konfiguration.

ServiceCheck.properties

Grundlæggende konfiguration af service-check sker ved tilretning af properties i ServiceCheck.properties filen.

Eksempel på ServiceCheck.properties

jmx.url=service:jmx:rmi://localhost/jndi/rmi://localhost:1090/jmxconnector
jmx.username=nisse
jmx.password=ngyffe
service.config.path=service-check.xml
log4j.path=servicecheck.log4j.properties

Konfiguration af log4j sker ved tilretning af properties i filen servicecheck.log4j.properties:

log4j.logger.service-check=INFO,sclog
log4j.appender.sclog=org.apache.log4j.RollingFileAppender
log4j.appender.sclog.File=${jboss.server.log.dir}/service-check.log
log4j.appender.sclog.layout=org.apache.log4j.PatternLayout
log4j.appender.sclog.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

JMX-Console sikkerhedsopsætning

WildFly

Følgende script afvikles for at tilføje en ny JMX bruger på wildfly:

wildfly\bin\add-user.sh

Under opsætning af brugeren vælges typen ’Management User’ og muligheden for kommunikation på tværs af applikationsservere kræves ikke rettigheder til.

Når brugeren er oprettet med navn og kodeord ændres ServicesCheck.properties, så properties stemmer overens med det indtastede i add-user.sh scriptet.

Se afsnit 4.3.1 for et eksempel på konfiguration af jmx.username og jmx.password.

service-check.xml

Konfiguration af de enkelte checks for en service foretages ved tilretning af settings i service-check.xml filen. Nedenfor ses eksempel på konfiguration af Aftaleoversigt XDS Adapteres service check, der omfatter:

• Check i WildFly at servicen er registreret og aktiv

<service name="ao-documentmetadataprovider-<profil-navn>">
    <assertions resultCode="200">
        <mBeanCheck>         
			<ObjectName>jboss.as:deployment=ao-documentmetadataprovider-<profil-navn>.war,subsystem=undertow,servlet=MetadataProviderWS</ObjectName>
        </mBeanCheck>
    </assertions>
    <assertions resultCode="404">
        <mBeanCheck> 	         
			<ObjectName>jboss.as:deployment=ao-documentmetadataprovider-<profil-navn>.war,subsystem=undertow,servlet=MetadataProviderWS</ObjectName>
            <isRegistered>false</isRegistered>
        </mBeanCheck>
    </assertions>
</service>

<service name="ao-documentprovider-<profil-navn>">
    <assertions resultCode="200">
        <mBeanCheck> 	          
			<ObjectName>jboss.as:deployment=ao-documentprovider-<profil-navn>.war,subsystem=undertow,servlet=DocumentProviderWS</ObjectName>
        </mBeanCheck>
    </assertions>
    <assertions resultCode="404">
        <mBeanCheck> 	         
			<ObjectName>jboss.as:deployment=ao-documentprovider-<profil-navn>.war,subsystem=undertow,servlet=DocumentProviderWS</ObjectName>
            <isRegistered>false</isRegistered>
        </mBeanCheck>
    </assertions>
</service>

Test af service-check konfiguration

Efter konfiguration og deploy af ServiceCheck servicen, kan Aftaleoversigt XDS Adaptere servicecheck testes med følgende kommandoer:

curl –i localhost:9090/service-check/service?servicename=ao-documentmetadataprovider-<profil-navn>
curl –i localhost:9090/service-check/service?servicename=ao-documentprovider-<profil-navn>

Servicen returnerer følgende http koder:

• 200 ved normal situation.

• 404 hvis servicen ikke er deployed

• 405 ved fejlkonfiguration af url til check af service-check funktionen (for at lette fejlsøgning)

• 500 ved anden intern fejl ved forespørgsel i WildFly på den overvågede service

HTTP Versionsnummer-information på Aftaleoversigt XDS-adaptere

Der kan hentes versionsnummer fra kørende Aftaleoversigt XDS adaptere som givet i nedenstående tabel.

...

Aftaleoversigt XDS Repository Adapter

...

pdc-v3.0:full
documentEntry.metadata.metadataEntry[1].formatCodeScheme=1.2.208.184.100.10
documentEntry.metadata.metadataEntry[1].formatCodeName=DK PDC schema
documentEntry.metadata.metadataEntry[1].typeCodeCode=PDC
documentEntry.metadata.metadataEntry[1].typeCodeScheme=1.2.208.184.100.1
documentEntry.metadata.metadataEntry[1].typeCodeName=Stamkort

Properties beskrives ifølge tabel: 

documentEntry.title

documentEntry.mimeType

documentEntry.languageCode

documentEntry.patient.assigningAuthority.root

documentEntry.organisation.assigningAuthority.root

documentEntry.homeCommunityId

documentEntry.repositoryUniqueId

documentEntry.healthcareFacilityTypeCode.code, schemaName, name

documentEntry.author.organisation.id

documentEntry.author.organisation.name

Som det fremgår af navnene ovenfor anvendes disse properties til at udfylde DocumentEntries ved søgninger mod FSK Registry. DocumentEntry metadata værdierne bør koordineres og opsættes, så de passer med CDA værdierne, der returneres i dokumenterne fra FSK Repository.

Den eneste property, der varierer fra miljø til miljø er angivelsen af repositoryUniqueId - resten er de samme henover miljøer.

Derudover anvendes parametrene til at afgøre, om FSK Registry skal returnere data ved forspørgsler eller ej. 

Hvis der f.eks. medsendes et søgeparameter i søgningen (ITI-18) på eventCode, så skal søgeværdien matche med værdien documentEntry.eventCode.code for, at der returneres en DocumentEntry for den pågældende borger.

Der filtreres på healthcarefacility, formatCodes og typeCodes modsvarer lignende navne i søge-parametre efter følgende opskrift:

1. Filterets code ikke er tomt, og

2. Ingen af evt. flere koder fra søge-parametre findes i filterets 

Tilsvarende logik er gældende de øvrige koder i filteret.

Konfiguration af log4j

Log4j konfiguration findes i følgende fil:

• log4j.properties

Eksempel på konfiguration:

log4j.rootCategory=INFO, FILE
log4j.logger.dk.sds=DEBUG

log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=${jboss.server.log.dir}/fsk-registry.log
log4j.appender.FILE.Append=true
log4j.appender.FILE.MaxFileSize=${dk.nsp.log.MaxFileSize}
log4j.appender.FILE.MaxBackupIndex=${dk.nsp.log.MaxBackupIndex}
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d [%-2p] %c - %m%n

Udpegning af SLA-log konfiguration

Følgende fil udpeger hvilken fil, der indeholder konfigurationen af SLA-logning:

• log4j-nspslalog-fskreg.properties

Per default udpeges konfigurationsfilen beskrevet i næste afsnit.

Konfiguration af SLA-log

Per default indlæses konfigurationen af FSK Registry SLA-logning fra følgende fil:

• nspslalog-fskreg.properties

Auditlog

Hvis CPR validering kører i WARNING mode, så vil ugyldige (ifølge CPRExits service) CPR numre give anledning til en linje i auditloggen. Logninger af denne type ser således ud:

{"time":"2021-08-09T12:34:34.387Z","category":"dk.sds.nsp.audit.log.fskregistry","audit":{"timestamp":"2021-08-09T14:34:34.325+02:00","components":[{"component":"FskRegistry","contexts":[{"context":"iti-18","information":[{"key":"dk.nsp.cpr.exists.false","type":"SPI","value":"9932000000"},{"key":"dk.nsp.cpr.exists.false","type":"SPI","value":"9932000000"}]}]}]},"access":{"code":200,"duration":57,"httpHeaders":{"Content-Type":"application/soap+xml; charset=UTF-8"},"httpHost":"localhost","method":"POST","path":"/fskregistry/iti18","query":"","port":8060,"protocol":"http","reqSize":1569,"resSize":10307,"soapHeaders":{"w3Action":"urn:ihe:iti:2007:RegistryStoredQuery","w3MessageID":"urn:uuid:6b459c84-ddc1-43d2-84e4-e7e427fa9b7a","w3To":"http://localhost:8060/fskregistry/iti18"},"threadId":"default task-6","time":"2021-08-09T14:34:34.325+02:00","stats":{"handlerDuration":3,"RequestContentDuration":1,"ResponseContentDuration":0,"SecurityProtocolRequestDuration":0,"SecurityProtocolResponseDuration":0,"bufferAllocated":false,"usedBuffers":1,"activeBuffersInPool":1,"idleBuffersInPool":1}}}

HTTP Status- og versionscheck på FSK Registry Adapter

HTTP Statuscheck er i FSK Registry Adapter lagt sammen med HTTP Versionsnummerinformation. 

Ved HTTP Statuscheck oplyses også status på forbindelsen til databasen. 

Efter konfiguration og opstart af FSK Registry Adapter kan versionsnummer hentes med (Eksempel er ved opstart vha. docker-compose fra development):

curl localhost:8060/fskregistry/health

hvilket giver output i stil med:

{ version: "1.2.6-SNAPSHOT", Database: "OK", CprExistsServiceClient : "0 fejl"}

Kaldet til HealthServlet giver en statuskode 200 tilbage, hvis både databasen og forbindelsen til CprExistsService er sund.

Hvis forbindelsen til databasen er i stykker, så vil HealthServlet returnere kode 500.

Hvis kaldene (de sidste 50) til CprExists er fejlede, så vil HealthServlet returnere kode 204.

Overvågning

FSK Registry overvåges af Status og versionstjek URL

Versionsnummeret hentes fra Mavens pom.properties indlejret i jar-filen for fællesartefaktet ao-provider-common.

Test af versionsnummer

Efter konfiguration og deploy af Aftaleoversigt XDS-adaptere kan versionsnummeret for fx Aftaleoversigt XDS Registry Adapter hentes med:

curl localhost:9090/ao-documentmetadataprovider-<profil-navn>/version

hvilket giver output i stil med:

Version: 1.0.0

Tilsvarende hentes versionsnummeret for Aftaleoversigt XDS Repository Adapter blot ved at anvende det andet endpoint i tabellen.

Overvågning

Aftaleoversigt XDS-adaptere overvåges af service-check overvågningsside, hvis url 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 WEB side der anvender JMX til at indhente oplysninger om Web services deployed på serveren. Som udgangspunkt overvåges følgende:

• Verificer service er registreret og aktiveret i WildFly

Det muligt at udvide overvågning med yderligere checks ved at tilføje nye objekter i service-check.xml, se eksempler i afsnit 4.3.2.

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.

...

ao-<profil-navn>-documentmetadataprovider-ws.log

...

For alle webservices er der en tilhørende SLA-log, der sørger for at logge udvalgte elementer fra requests til webservicen.

For Aftaleoversigt XDS-adaptere logges indgående kald, samt udgående kald til Svareksponeringsservicen.
For indgående kald logges ved følgende logpunkter:

...

DocumentRepository_RetrieveDocumentSet

For udgående kald logges ved følgende logpunkter:

...

ao-documentprovider-<profil-navn>

...

DocumentRepository_RetrieveDocumentSet.AppointmentInvoker.invokeAppointment

...

search/appointments

Performance logs forekommer kun ved aktivering af performanceloggeren i komponenternes log4j konfiguration.

Standard fejlsøgning

Fejlsøgning kan ske ved at undersøge de logfiler, der er beskrevet i forudgående afsnit.

Krav til backup

Det anbefales, at aktuelle konfigurationsfiler til Aftaleoversigt XDS-adaptere FSK Registry holdes under versionskontrol og back-up.

Det er ikke nødvendigt at tage backup af databasen, da data heri ikke skal gemmes ("requestscope"Backup af databasen sorterer under FSK Repository (andet system)