Indhold
1 Introduktion
1.1 Formål
1.2 Læsevejledning
1.3 Dokumenthistorik
1.4 Definitioner og referencer
2 Komponenter
3 Daglig drift
3.1 Relaterede services
4 Konfiguration
4.1 Konfiguration af Svareksponeringsservice XDS Registry Adapter
4.1.1 Konfiguration af dokument-metadata
4.1.2 Konfiguration af filter på dokument-metadata-forespørgsel
4.1.3 Konfiguration af mapning til specialer
4.1.4 Udpegning af log4j-konfigurationfil
4.1.5 Konfiguration af log4j
4.1.6 Udpegning af SLA-log konfiguration
4.1.7 Konfiguration af SLA-log
4.2 Konfiguration af Svareksponeringsservice XDS Repository Adapter
4.2.1 Konfiguration af Svareksponeringsservice kalder
4.2.2 Konfiguration af dokumentdelings-id
4.2.3 Konfiguration af mapning til specialer
4.2.4 Udpegning af log4j-konfigurationfil
4.2.5 Konfiguration af log4j
4.2.6 Udpegning af SLA-log konfiguration
4.2.7 Konfiguration af SLA-log

4.2.8 SES auditlogning
4.3 HTTP Statuscheck på komponenter i Svareksponeringsservice XDS-adaptere
4.3.1 ServiceCheck.properties
4.3.2 JMX-Console sikkerhedsopsætning
4.3.3 service-check.xml
4.3.4 Test af Service-check konfiguration
4.4 HTTP Versionsnummer-information på Svareksponeringsservice XDS-adaptere
4.4.1 Test af versionsnummer
5 Overvågning
5.1 Placering af HTML overvågningsside
5.2 Fortolkning af HTML overvågningsside
5.3 Overvågningstype
5.4 Logfiler og fortolkning af disse
6 Standard fejlsøgning
7 Krav til backup m.m.

Introduktion

Formål

Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenterne fra Svareksponeringsservice XDS-adaptere.
Driftsvejledningen indeholder information om komponenterne 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 2 er beskrevet hvilke komponenter, der indgår i Svareksponeringsservice XDS-adaptere og deres forventede placering med hensyn til platform.
Afsnit 4 beskriver aktuelle konfigurationsparametre for komponenterne i Svareksponeringsservice XDS-adaptere, samt eksempler på konfigurationsparameter-filer.
I afsnit 5 beskrives hvorledes Svareksponeringsservice XDS-adapter-komponenterne overvåges.
Beskrivelse af standard fejlsøgning og vejledning for start/stop af komponenterne er beskrevet i afsnit 6.
Specielle krav til backup er beskrevet i afsnit 7, ligesom procedure ved reetablering af komponenterne 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

Version	Dato	Ansvarlig	Beskrivelse
1.0	21.09.2016	Systematic	Første udgave.

Definitioner og referencer

Definition	Beskrivelse
DDS	Dokumentdelingsservices
NSI	National Sundheds-IT
NSP	Den nationale service platform (inden for sundheds-IT)
STS	Security Token Service
XDS	Cross-Enterprise Document Sharing

Komponenter

Svareksponeringsservice XDS-adaptere er implementeret gennem følgende komponenter:

Svareksponeringsservice XDS Registry Adapter
Type: Webservice
Filnavn: sxa-documentmetadataprovider.war
Url: <serverurl>/sxa-documentmetadataprovider
Statusurl: <serverurl>/service-check/service?servicename=sxa-documentmetadataprovider
Svareksponeringsservice XDS Repository Adapter
Type: Webservice
Filnavn: sxa-documentprovider.war
Url: <serverurl>/sxa-documentprovider
Statusurl: <serverurl>/service-check/service?servicename=sxa-documentprovider

Brug af service-check forudsætter følgende komponent på NSP:

Service-check
Type: Webservice
Filnavn: service-check.war
Url: <serverurl>/service-check/service

Daglig drift

Dette afsnit beskriver den daglige drift af systemet.

Relaterede services

Svareksponeringsservice XDS Repository Adapter afhænger af den eksterne service:

Svareksponeringsservice hos Laboratoriedatabanken

Ved fejl i denne vil Svareksponeringsservice XDS Repository Adapter returnere svar til anvendere, hvoraf det fremgår, at der er fejl.

Konfiguration

Konfiguration af Svareksponeringsservice XDS Registry Adapter

Konfiguration af Svareksponeringsservice kalder

Opsætningen for kalderen af Svareksponeringsservice konfigureres i SXAConfig.properties.
Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

Et eksempel på sådan konfiguration er:

sxa.labservice.credential.header=X-Labsvar-Credential
sxa.labservice.credential=00000000-0000-0000-0000-000000000000

Properties beskrives ifølge tabel.

Property	Beskrivelse
sxa.labservice.credential.header	Navn på http-header, der indeholder servicenøgle fra klienten. Skal være udfyldt, hvis sxa.labservice.credential er udfyldt. Hvis ikke udfyldt, udføres der ikke validering af nøgler.
sxa.labservice.credential	Serverens servicenøgle. Bruges ifm. Samblik pilotafprøvning til at begrænse adgang til SXA. Skal være udfyldt, hvis sxa.labservice.credential.header er udfyldt. Hvis ikke udfyldt, udføres der ikke validering af nøgler.

Konfiguration af dokument-metadata

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

sxametadataconfiguration.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentmetadataprovider/config/main/

Et eksempel på indhold i sxametadataconfiguration.xml:

<metadata>
  <classCode class="codedValue">
    <code>001</code>
    <codeSystem>2.16.840.1.113883.3.4208.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>urn:ad:dk:medcom:labreports:svareksponeringsservice</code>
    <codeSystem>1.2.208.184.100.10</codeSystem>
    <description>Laboratoriesvar (samling af svar)</description>
  </formatCode>
  <languageCode>da-DK</languageCode>
  <mimeType>text/xml</mimeType>
  <practiceSettingCode class="codedValue">
    <code></code>
    <codeSystem></codeSystem>
    <description></description>
  </practiceSettingCode>
  <typeCode class="codedValue">
    <code>11502-2</code>
    <codeSystem>2.16.840.1.113883.6.1</codeSystem>
    <description>LABORATORY REPORT.TOTAL</description>
  </typeCode>
  <homeCommunityId>1.2.3.5.6</homeCommunityId>
  <repositoryUniqueId>1.2.3.4.55.66</repositoryUniqueId>
  <uniqueIdRoot>1.2.3.4.55.66</uniqueIdRoot>
  <healthcareFacilityTypeCode class="codedValue">
    <code></code>
    <codeSystem>2.16.840.1.113883.6.96</codeSystem>
    <description></description>
  </healthcareFacilityTypeCode>
  <authorInstitution
    class="dk.nsi.documentsharing.core.metadata.model.OrganisationImpl">
    <name>Region Test</name>
    <id class="valueWithAssigningAuthority">
      <value>291000016008</value>
      <assigningAuthority>1.2.208.176.1.1</assigningAuthority>
    </id>
  </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. Svareksponeringsservice XDS Registry Adapter har logik, der er afhængig af konkrete søge-parametre og konfigureret filter (beskrevet her), fastlægger hvilket svar, der skal returneres.
Filteret konfigureres i følgende fil:

sxafilterconfiguration.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentmetadataprovider/config/main/

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

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

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

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

Filterets classCodes, typeCodes, eventCodes, confidentialityCodes, formatCodes og practiceSettingCodes modsvarer lignende navne i søge-parametre, der kan være anført ved kald af Svareksponeringsservice 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:

Filterets eventCodes ikke er tomt, og
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>11502-2</code>
      <codeSystem>2.16.840.1.113883.6.1</codeSystem>
      <description>LABORATORY REPORT.TOTAL</description>
    </codedValue>
  </typeCodes>
  <eventCodes/>
  <confidentialityCodes>
    <codedValue>
      <code>N</code>
      <codeSystem>2.16.840.1.113883.5.25</codeSystem>
      <description>Normal</description>
    </codedValue>
  </confidentialityCodes>
  <formatCodes>
    <codedValue>
      <code>urn:ad:dk:medcom:labreports:svareksponeringsservice</code>
      <codeSystem>1.2.208.184.100.10</codeSystem>
      <description>Laboratoriesvar (samling af svar)</description>
    </codedValue>
  </formatCodes>
  <practiceSettingCodes>
     <codedValue>
      <code>408454008</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>klinisk mikrobiologi</description>
    </codedValue>
    <codedValue>
      <code>394596001</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>klinisk biokemi</description>
    </codedValue>
    <codedValue>
      <code>394915009</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>patologi anatomi og cytologi</description>
    </codedValue>	  
  </practiceSettingCodes>
</filter>

Konfiguration af mapning til specialer

Ved opslag på en patient kan der anføres en række søge-parametre. Svareksponeringsservice XDS Registry Adapter har logik, der er afhængig af konkrete søge-parametre foretager encoding i dokumentid, der er del af returnerede metadata.
Mapning til specialer konfigureres i følgende fil:

sxapracticesettingcodes.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentmetadataprovider/config/main/

I konfiguration specificeres specialer således:

<filter>
  <practiceSettingCodes>
    <mappedCodedValue>
      <code>408454008</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>klinisk mikrobiologi</description>
      <mappedValue>Mikrobiologi</mappedValue>
    </mappedCodedValue>
    <mappedCodedValue>
      <code>394596001</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>klinisk biokemi</description>
      <mappedValue>KliniskBiokemi</mappedValue>
    </mappedCodedValue>
    <mappedCodedValue>
      <code>394915009</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>patologisk anatomi og cytologi</description>
      <mappedValue>Patologi</mappedValue>
    </mappedCodedValue>
  </practiceSettingCodes>
</filter>

Det er vigtigt, at den tilsvarende fil for documentprovider er konfigureret fuldstændigt identisk.

Udpegning af log4j-konfigurationfil

Følgende fil, der findes under roden i war-filen sxa-documentmetadataprovider.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-sxa-documentmetadataprovider-ws.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentmetadataprovider/config/main/

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-sxa-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 sxa-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-sxa-documentmetadataprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentmetadataprovider/config/main/

Per default udpeges konfigurationsfilen beskrevet i næste afsnit.

Konfiguration af SLA-log

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

log4j-nspslalog-sxa-documentmetadataprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentmetadataprovider/config/main/

Konfiguration af Svareksponeringsservice XDS Repository Adapter

Konfiguration af Svareksponeringsservice kalder

Opsætningen for kalderen af Svareksponeringsservice konfigureres i SXAConfig.properties.
Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

Et eksempel på sådan konfiguration er:

sxa.labservice.request.timeout.seconds = 120
sxa.labservice.request.username = username
sxa.labservice.request.password = password
sxa.labservice.endpoint = 
http://localhost:9090/sxa-labreportservicestub/SvarEksponering
sxa.document.unique.root.id = 1.2.3.4.55.66
sxa.labservice.request.samtykkekode = _ 
sxa.labservice.request.samtykketekst = _ 
sxa.labservice.request.slutbruger.identifikation = _ 
sxa.labservice.request.slutbruger.organisation = _ 
sxa.labservice.request.slutbruger.cpr = _ 
sxa.labservice.request.slutbruger.fornavn = _ 
sxa.labservice.request.slutbruger.efternavn = _ 
sxa.labservice.request.slutbruger.stilling = _ 
sxa.labservice.request.slutbruger.email = _ 
sxa.labservice.request.slutbruger.rolle = _ 
sxa.labservice.request.slutbruger.autorisationskode = _

sxa.labservice.servicecheck.failurethreshold = 5

sxa.labservice.headers = _

sxa.labservice.logrecord.inbound.header.name = _
sxa.labservice.logrecord.outbound.header.name = _

sxa.labservice.credential.header=X-Labsvar-Credential
sxa.labservice.credential=00000000-0000-0000-0000-000000000000

Properties beskrives ifølge tabel.

Property	Beskrivelse
sxa.labservice.request.timeout.seconds	Antal sekunder for hvor lang tid et request mod laboratoriebanken maximalt må tage før forsøget meldes som mislykket.
sxa.labservice.request.username	Brugernavnet der anvendes ved kald til Laboratoriedatabanken
sxa.labservice.request.password	Kodeordet der anvendes ved kald til Laboratoriedatabanken
sxa.labservice.endpoint	Url'en til Laboratoriedatabankens service
sxa.document.unique.id.root	Root id for det generede dokument
sxa.labservice.request.samtykkekode
sxa.labservice.request.samtykketekst
sxa.labservice.slutbruger.identifikation	Slutbrugerns brugerid eller en fast identitet på det kaldende system, såfremt det selv logger
sxa.labservice.slutbruger.organisation	Navnet på organisationen som slutbrugeren eller det kaldende system stammer fra
sxa.labservice.slutbruger.cpr	Slutbrugerens cpr-nummer
sxa.labservice.slutbruger.fornavn	Slutbrugerens fornavn
sxa.labservice.slutbruger.efternavn	Slutbrugerens efternavn
sxa.labservice.slutbruger.stilling	Slutbrugerens stillingsbetegnelse
sxa.labservice.slutbruger.email	Slutbrugerens email
sxa.labservice.slutbruger.rolle	Slutbrugerens rolle
sxa.labservice.slutbruger.autorisationskode	Slutbrugerens autorisationskode
sxa.labservice.servicecheck.failurethreshold	Hvor mange gange et kald til Laboratoriedatabanken skal forsøges igen, før det opfattes som fejlet.
sxa.labservice.headers	Styrer hvilke indkommende HTTP-headers, der skal videresendes til Laboratoriedatabanken. Angives som en komma-separeret liste. I indkommende requests ledes efter HTTP-headers, hvis navn forekommer i listen, og hvis de findes, sendes de med videre.
sxa.labservice.logrecord.inbound.header.name	Navn på indkommende HTTP-header, som indeholder LogRecord-parameter fra det kaldende system. Hvis headeren findes, så bruges den i beregningen af den LogRecord, der sendes med i kald til Svareksponeringsservicen.
sxa.labservice.logrecord.outbound.header.name	Navn på den HTTP-header, som indeholder LogRecord-parameter i kald til Svareksponeringsservicen. Beregningen af headeren er beskrevet i afsnittet 'SES Auditlogning'.
sxa.labservice.credential.header	Navn på http-header, der indeholder servicenøgle fra klienten. Skal være udfyldt, hvis sxa.labservice.credential er udfyldt. Hvis ikke udfyldt, udføres der ikke validering af nøgler.
sxa.labservice.credential	Serverens servicenøgle. Bruges ifm. Samblik pilotafprøvning til at begrænse adgang til SXA. Skal være udfyldt, hvis sxa.labservice.credential.header er udfyldt. Hvis ikke udfyldt, udføres der ikke validering af nøgler.

Konfiguration af dokumentdelings-id

Konfiguration af hvilket homeCommunityId og repositoryUniqueId, Svareksponeringsservice XDS Repository Adapter'en skal reagere på ved request for indhentning af dokument, er konfigureret i følgende fil:

sxaproviderconfiguration.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

Et eksempel på sådan konfiguration er:

<ProviderConfiguration>
  <homeCommunityId>1.2.3.5.6</homeCommunityId>
  <repositoryUniqueId>1.2.3.4.55.66</repositoryUniqueId>
  <uniqueIdRoot>1.2.3.4.55.66</uniqueIdRoot>
</ProviderConfiguration>

Bemærk, at de konkrete værdier skal være afstemt med homeCommunityId og repositoryUniqueId i de dokumentmetadata, der er konfigureret som beskrevet i afsnit 4.1.1. Er der ikke overensstemmelse, vil kald til Svareksponeringsservice XDS Repository give anledning til svar, der påpeger uoverenstemmelsen.

Konfiguration af mapning til specialer

Ved opslag på en patient kan der anføres en række søge-parametre. Svareksponeringsservice XDS Registry Adapter har logik, der er afhængig af konkrete søge-parametre foretager encoding i dokumentid, der er del af returnerede metadata. Ved indhentning af dokument foretages decoding og mapning til speciale-parametre anvendt i kaldet til Svareksponeringsservicen.
Mapning til specialer konfigureres i følgende fil:

sxapracticesettingcodes.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

I konfiguration specificeres specialer således:

<filter>
  <practiceSettingCodes>
    <mappedCodedValue>
      <code>408454008</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>klinisk mikrobiologi</description>
      <mappedValue>Mikrobiologi</mappedValue>
    </mappedCodedValue>
    <mappedCodedValue>
      <code>394596001</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>klinisk biokemi</description>
      <mappedValue>KliniskBiokemi</mappedValue>
    </mappedCodedValue>
    <mappedCodedValue>
      <code>394915009</code>
      <codeSystem>2.16.840.1.113883.6.96</codeSystem>
      <description>patologisk anatomi og cytologi</description>
      <mappedValue>Patologi</mappedValue>
    </mappedCodedValue>
  </practiceSettingCodes>
</filter>

Det er vigtigt, at den tilsvarende fil for documentmetadataprovider er konfigureret fuldstændigt identisk.

Udpegning af log4j-konfigurationfil

Følgende fil, der findes under roden i war-filen sxa-documentprovider.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-sxa-documentprovider-ws.xml

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

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-sxa-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 sxa-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-sxa-documentprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

Per default udpeges konfigurationsfilen beskrevet i næste afsnit.

Konfiguration af SLA-log

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

log4j-nspslalog-sxa-documentprovider.properties

Denne indlæses fra WildFly modulet:

/pack/wildfly8/modules/nsi/ddsprojects/sxa/documentprovider/config/main/

SES Auditlogning

Ved kald til Svareksponeringsservicen medsendes der en header, som indeholder information til auditlogning. Headeren indeholder en LogRecord xml-struktur, hvis indhold beskrives nærmere i dette afsnit.

Indholdet af headeren er nærmere beskrevet i og det tilhørende analysedokument. Ved requests til XDS Repository Adapteren bliver der konstrueret en LogRecord-header SXA konstruerer LogRecord-strukturen ud fra følgende informationer i requestet:

Hsuid-header. Påkrævet
Medcom-header. Påkrævet
LogRecord-header. Frivillig.
Request body. Påkrævet.

Eksempel på header:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<LogRecord xmlns="healthcare.loginfo/2017-03-01">
  <TraceInfo>
    <RequestTime>2020-10-23T14:15:54.138+02:00</RequestTime>
    <SessionId>00000000-0000-0000-0000-000000000000</SessionId>
    <RequestId>11111111-1111-1111-1111-111111111111</RequestId>
    <Route>
      <ViaSystem id="1">Dokumentdelingsservice</ViaSystem>
    </Route>
  </TraceInfo>
  <RequestingClient>
    <ClientIdentification ClientIdentificationType="CPR nummer">098765-4321</ClientIdentification>
    <ClinicName/>
    <ClinicDepartment/>
    <UserCprNumber>098765-4321</UserCprNumber>
    <UserName/>
    <UserInitials/>
    <LookUpType>Borger</LookUpType>
    <TaskType>Opslag Dokumentdelingsservice</TaskType>
  </RequestingClient>
  <Patient>
    <CprNumber>121212-1212</CprNumber>
    <Name/>
  </Patient>
  <Consent>
    <Code>1</Code>
    <Text/>
    <PrivacyOverrideCode>0</PrivacyOverrideCode>
  </Consent>
  <ExtendedRequestInfo Format="Text">{HomeCommunityId: 1.2.3.5.6, RepositoryUniqueId: 1.2.3.4.55.66, DocumentUniqueId: 1.2.3.4.55.66.12172240491026.20201023121554.20201023121654.0}</ExtendedRequestInfo>
</LogRecord>

I nedenstående tabel beskrives mere præcist, hvordan headeren udfyldes.

Header-element	Indhold
TraceInfo.RequestTime	Tidspunktet hvor headeren dannes.
TraceInfo.SessionId	FlowID fra Medcom-headeren, hvis det er angivet. Ellers et tilfældigt uuid.
TraceInfo.RequestId	Tilfældigt uuid. For at kunne korrelere MessageID fra Medcom-headeren med det tilfældige uuid, logges en linje på følgende form på INFO-niveau i applikationsloggen: LogRecord generated. MessageID: <messageID>, RequestId: <requestId> Eksempel: LogRecord generated. MessageID: AAABeBX9pFBxz1Ul3Nwf/lNPU0k=, RequestId: 863faf0f-dc2a-4c48-b4ec-897ec90a9890
TraceInfo.Route	En sekvens af ViaSystem-elementer. Hvis requestet indeholder en LogRecord-header, så kopieres sekvensen herfra, og udvides med et element med værdien 'Dokumentdelingsservice'. Ellers kun 'Dokumentdelingsservice'-elementet.
RequestingClient.ClientIdentification	Bestemmes ud fra Hsuid-headerens UserType-attribut. Hvis UserType-attributten er 'nsi:Citizen', så sættes ClientIdentificationType til 'CPR_NUMMER', og værdien sættes til indholdet af ActingUserCivilRegistrationNumber-attributten. Hvis UserType-attributten er 'nsi:HealthcareProfessional', så bestemmes ClientIdentificationType ud fra OrgUsingID-attributtens NameFormat, og værdien sættes til indholdet af OrgUsingID-attributten.
RequestingClient.ClinicName	Tom streng.
RequestingClient.ClinicDepartment	Tom streng.
RequestingClient.UserCprNumber	Sættes til indholdet af ActingUserCivilRegistrationNumber-attributten.
RequestingClient.UserName	Tom streng.
RequestingClient.UserInitials	Tom streng.
RequestingClient.BehalfOfCprNumber	Sættes til indholdet af ResponsibleUserCivilRegistrationNumber-attributten, hvis denne er udfyldt.
RequestingClient.LookUpType	Bestemmes ud fra Hsuid-headerens UserType-attribut. Hvis UserType-attributten er 'nsi:Citizen', så tjekkes om borgeren slår op på egne data (ved at tjekke om ResponsibleUserCivilRegistrationNumber-attributten er udfyldt). Hvis ja, så sættes LookupType til 'Borger'. Hvis nej, så bestemmes LookupType ud fra CitizenUserRelation-attributten som følger: Citizen → Borger ChildCustodyHolder → Forælder Guardian → Værge ProxyHolder → Fuldmagtshaver Hvis UserType-attributten er 'nsi:HealthcareProfessional', så tjekkes om ResponsibleUserAuthorizationCode-attributten er udfyldt. Hvis ja, så sættes LookupType til 'Kliniker'. Hvis nej, så sættes LookupType til 'Kliniker'. (ikke helt afgjort pt. om det skal være sådan.)
RequestingClient.TaskType	Sættes til 'Opslag Dokumentdelingsservice'.
Patient.CprNumber	Beregnes ved at decode DocumentUniqueId'et fra request bodyen.
Patient.Name	Tom streng
Consent.Code	Hvis HSUID-attributten ConsentOverride ikke er angivet, eller er angivet til 'false', så 1 (patienten har givet samtykke). Ellers 3 (opslaget er foretaget som en del af behandlingen).
Consent.Text	Hvis HSUID-attributten ConsentOverride ikke er angivet, eller er angivet til 'false', så tom streng, ellers 'Opslag foretages pga. værdispring'.
Consent.PrivacyOverrideCode	PrivacyOverrideCode - Hvis HSUID-attributten ConsentOverride ikke er angivet, eller er angivet til 'false', så 0, ellers 1.
ExtendedRequestInfo	Tekstuel repræsentation af request body'en

HTTP Statuscheck på komponenter i Svareksponeringsservice XDS-adaptere

Det er muligt at lave servicetjek på Svareksponeringsservice XDS-adaptere 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 svareksponeringsservice XDS-adaptere. 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 Svareksponeringsservice XDS Adapteres service check, der omfatter:

Check i WildFly at servicen er registreret og aktiv

<service name="sxa-documentmetadataprovider">
    <assertions resultCode="200">
        <mBeanCheck>
            <ObjectName>jboss.as:deployment=sxa-documentmetadataprovider.war,subsystem=undertow,servlet=MetadataProviderWS</ObjectName>
        </mBeanCheck>
    </assertions>
    <assertions resultCode="404">
        <mBeanCheck>
            <ObjectName>jboss.as:deployment=sxa-documentmetadataprovider.war,subsystem=undertow,servlet=MetadataProviderWS</ObjectName>
            <isRegistered>false</isRegistered>
        </mBeanCheck>
    </assertions>
</service>
<service name="sxa-documentprovider">
    <assertions resultCode="200">
        <mBeanCheck>
            <ObjectName>jboss.as:deployment=sxa-documentprovider.war,subsystem=undertow,servlet=DocumentProviderWS</ObjectName>
        </mBeanCheck>
    </assertions>
    <assertions resultCode="404">
        <mBeanCheck>
            <ObjectName>jboss.as:deployment=sxa-documentprovider.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 Svareksponeringsservice XDS Adaptere servicecheck testes med følgende kommandoer:

curl –i localhost:9090/service-check/service?servicename=sxa-documentmetadataprovider 
curl –i localhost:9090/service-check/service?servicename=sxa-documentprovider

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å Svareksponeringsservice XDS-adaptere

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

Komponent i Svareksponeringsservice XDS-adaptere	Endpoint for versionsnummer-information
Svareksponeringsservice XDS Registry Adapter	http://<host:port>/sxa-documentmetadataprovider/version
Svareksponeringsservice XDS Repository Adapter	http://<host:port>/sxa-documentprovider/version

Tabel 1 Versionsnummer for kørende service
Versionsnummeret hentes fra Mavens pom.properties indlejret i jar-filen for fællesartefaktet sxa-provider-common.

Test af versionsnummer

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

curl localhost:9090/sxa-documentmetadataprovider/version

hvilket giver output i stil med:

Version: 1.0.0

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

Overvågning

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

Logfilnavn	Komponenter der skriver til denne
sxa-documentmetadataprovider-ws.log	Svareksponeringsservice XDS Registry Adapter
nsputil-sla-sxa-documentmetadataprovider.log	Svareksponeringsservice XDS Registry Adapter
sxa-documentmetadataprovider-ws-performance.log	Svareksponeringsservice XDS Registry Adapter
sxa-documentprovider-ws.log	Svareksponeringsservice XDS Repository Adapter
nsputil-sla-sxa-documentprovider.log	Svareksponeringsservice XDS Repository Adapter
sxa-documentprovider-ws-performance.log	Svareksponeringsservice XDS Repository Adapter
service-check.log	service-check

For alle webservices er der en tilhørende SLA-log, der sørger for at logge udvalgte elementer fra requests til webservicen.
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 m.m.

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