Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenterne fra Aftaleoversigt 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 Aftaleoversigt XDS-adaptere og deres forventede placering med hensyn til platform.
Afsnit 4 beskriver aktuelle konfigurationsparametre for komponenterne i Aftaleoversigt XDS-adaptere, samt eksempler på konfigurationsparameter-filer.
I afsnit 5 beskrives hvorledes Aftaleoversigt 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æseren forventes at have kendskab til National Sundheds-IT’s platform NSP, samt generelt kendskab til WildFly applikationsserver samt Ubuntu Linux operativ system.
Dette dokument er oprettet med udgangspunkt i dokumentet OHB0016 Driftsvejledning Aftaleoversigt XDS-adaptere.docx
Definition | Beskrivelse |
---|---|
DDS | Dokumentdelingsservice |
NSI | National Sundheds-IT |
NSP | Den nationale service platform (inden for sundheds-IT) |
STS | Security Token Service |
XDS | Cross-Enterprise Document Sharing |
Flere konfigurationer af Aftaleoversigt XDS-adaptere kan være deployeret på samme Wildfly applikationsserver. Se beskrivelse af profiler og profil-navne i indledningen af afsnit 4.
Aftaleoversigt XDS-adaptere er implementeret gennem følgende komponenter:
Aftaleoversigt XDS Registry Adapter
Type: Webservice
Filnavn: ao-documentmetadataprovider-<profil-navn>.war
Url: <serverurl>/ao-documentmetadataprovider-<profil-navn>
Statusurl: <serverurl>/service-check/service?servicename=ao-documentmetadataprovider-<profil-navn>
Aftaleoversigt XDS Repository Adapter
Type: Webservice
Filnavn: ao-documentprovider-<profil-navn>.war
Url: <serverurl>/ao-documentprovider-<profil-navn>
Statusurl: <serverurl>/service-check/service?servicename=ao-documentprovider-<profil-navn>
Brug af service-check forudsætter følgende komponent på NSP:
Service-check
Type: Webservice
Filnavn: service-check.war
Url: <serverurl>/service-check/service
Dette afsnit beskriver den daglige drift af systemet.
Aftaleoversigt XDS Registry og Repository anvender en database til persistering og afhentning af bookplan dokumenter. Denne database er at betragte som en "sessioncache". De persisterede data kan derfor til enhver tid slettes. Det er derfor ikke nødvendigt at tage backup af databasen.
Da databasen over tid vil vokse, giver det mening at rydde op i denne (f.eks i natligt/ugenligt job).
Oprydningsproceduren er udstillet på en servlet for Aftaleoversigt XDS Repository med adressen: <serverurl>/ao-documentprovider-<profil-navn>/clearDbCache?age=300
age er alder (i timer) der angiver, hvor gamle dokumenter skal være, før de slettes. Defaultværdien for age er 24 (dvs. et døgn).
Der kan sættes et eksternt job op (f.eks. cron job, der kalder dette endpoint).
Aftaleoversigt XDS Registry Adapter afhænger af den eksterne service:
Bookplans RESTful aftalesnitflade
Ved fejl i denne vil Aftaleoversigt XDS Registry Adapter returnere svar til anvendere, hvoraf det fremgår, at der er fejl.
Byg og deployering af Aftaleoversigt XDS-adaptere er forberedt, så flere instanser kan fungere på samme Wildfly applikationsserver på samme tid. Derved kan opsættes Aftaleoversigt XDS-adaptere til forskellige regioner eller forskellige instanser inden for samme region. Hver instans bygges og deployeres ved brug af en profil, som beskrevet herunder.
Hver profil er blevet udviddet, så de indeholder 2 version af f.eks. cda_document_template.xml. Hver profil kan dog ikke afvikle begge version i samme Wildfly. Så indtil den eksisterende version udgår, så skal der være en wildfly pr. version, spm indeholder instanser svarende til profiler.
I nuværende kode-base er følgende profiler forberedt:
Profilnavn | Profildefinitioner | Deployeringssti |
---|---|---|
rm | **/rm/* | ddsprojects/ao/*/config/rm |
Versionerne har kun imdflydelse på, hvor eksempel filer skal hentes fra. De skal stadig deployes til hver Wildfly, som angivet ovenover.
Version | Kode |
---|---|
Version 2.0.1 | v20 |
NB! Deployeringsstien er relativ til <Wildfly>/modules/nsi.
Opsætningen for kalderen af bookplan servicen konfigueres i AODocumentProvider.properties.
Denne indlæses fra WildFly modulet:
/pack/wildfly8/modules/nsi/ddsprojects/ao/documentmetadataprovider/config/<profil-navn>/ |
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.
Property | Beskrivelse |
---|---|
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 |
ao.document.assigning.authority.name | Navnet på oprindelssted for Bookplan data. |
ao.document.root.id | OID for oprindelssted af Bookplan data |
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 |
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>1.2.208.184.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:apd-v2.0.1:full</code> <codeSystem>1.2.208.184.100.10</codeSystem> <description>DK APD schema</description> </formatCode> <languageCode>da-DK</languageCode> <mimeType>text/xml</mimeType> <practiceSettingCode class="codedValue"> <code>408443003</code> <codeSystem>2.16.840.1.113883.6.96</codeSystem> <description>almen medicin</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.180.99.98</homeCommunityId> <repositoryUniqueId>1.2.208.176.99.180.99.98.1</repositoryUniqueId> <uniqueIdRoot>1.2.208.176.99.180.99.98.1</uniqueIdRoot> <healthcareFacilityTypeCode class="codedValue"> <code>22232009</code> <codeSystem>2.16.840.1.113883.6.96</codeSystem> <description>hospital</description> </healthcareFacilityTypeCode> <authorInstitution class="dk.nsi.dds.core.metadata.model.OrganisationImpl"> <name>Region Midtjylland</name> <id class="valueWithAssigningAuthority"> <value>6081000016005</value> <assigningAuthority>1.2.208.176.1.1</assigningAuthority> </id> <address class="dk.nsi.dds.core.metadata.model.AddressImpl"> <street>Skottenborg 26</street> <postalCode>8800</postalCode> <city>Viborg</city> </address> <telecom class="dk.nsi.dds.core.metadata.model.TelecomImpl"> <telecom>87285000</telecom> </telecom> </authorInstitution> </metadata> |
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:
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>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> |
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.
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.
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.
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>/ |
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> |
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.
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.
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.
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>/ |
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.
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 |
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.
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> |
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
Der kan hentes versionsnummer fra kørende Aftaleoversigt XDS adaptere som givet i nedenstående tabel.
Komponent i Aftaleoversigt XDS-adaptere | Endpoint for versionsnummer-information |
---|---|
Aftaleoversigt XDS Registry Adapter | http://<host:port>/ao-documentmetadataprovider-<profil-navn>/version |
Aftaleoversigt XDS Repository Adapter | http://<host:port>/ao-documentprovider-<profil-navn>/version |
Versionsnummeret hentes fra Mavens pom.properties indlejret i jar-filen for fællesartefaktet ao-provider-common.
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.
Aftaleoversigt XDS-adaptere overvåges af service-check overvågningsside, hvis url kan aflæses i afsnit 2.
Under listen af komponenter først i dette dokument, er der henvisninger til overvågningssiderne.
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.
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.
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 |
---|---|
ao-<profil-navn>-documentmetadataprovider-ws.log | Aftaleoversigt XDS Registry Adapter |
nsputil-sla-ao-<profil-navn>-documentmetadataprovider.log | Aftaleoversigt XDS Registry Adapter |
ao-<profil-navn>-documentmetadataprovider-ws-performance.log | Aftaleoversigt XDS Registry Adapter |
ao-<profil-navn>-documentprovider-ws.log | Aftaleoversigt XDS Repository Adapter |
nsputil-sla-ao-<profil-navn>-documentprovider.log | Aftaleoversigt XDS Repository Adapter |
ao-<profil-navn>-documentprovider-ws-performance.log | Aftaleoversigt 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.
For Aftaleoversigt XDS-adaptere logges indgående kald, samt udgående kald til Svareksponeringsservicen.
For indgående kald logges ved følgende logpunkter:
Kaldte service | LogPoint |
---|---|
ao-documentmetadataprovider-<profil-navn> | DocumentRegistry_RegistryStoredQuery |
ao-documentprovider-<profil-navn> | DocumentRepository_RetrieveDocumentSet |
For udgående kald logges ved følgende logpunkter:
Kaldte service | LogPoint | TargetSOAPOperation |
---|---|---|
ao-documentprovider-<profil-navn> | DocumentRepository_RetrieveDocumentSet.AppointmentInvoker.invokeAppointment | search/appointments |
Performance logs forekommer kun ved aktivering af performanceloggeren i komponenternes log4j konfiguration.
Logning foretages udfra følgende principper i forhold til loglevels og brug af stacktraces:
Nedenfor gennemgås, hvilke fejlscenarier, der kan opstå i Aftaleoversigten. Tabellerne indeholder logpattern dvs. hvilken tekst driften kan forvente at finde i applikationsloggen. Tilhørende er en fejlbeskrivelse og mulige løsninger beskrevet.
I det følgende gennemgåes de typiske fejlscenarier med ERROR:
Log pattern | Fejlbeskrivelse (og mulige løsninger) |
---|---|
Missing configuration file: <filename> | Sker ved opstarten af Aftaleoversigt XDS Adapter. Filename identificerer den manglende logfil - se Installationsvejledning Aftaleoversigt XDS Adaptere for beskrivelser af logfiler. |
Creating messagedigest instance for SHA-1 failed | SHA-1 understøttes ikke af den underliggende platform |
Error getting connection to datastore <exception> | Der er problemer med at få en connection til databasen, der bruges til caching af aftaledokumenter |
Error retrieving document from datastore. <exception> | Der er problemer med at læse fra databasen, der bruges til caching af aftaledokumenter |
Error deleting from datastore <exception> | Der er problemer med at slette (se oprydning) databasen, der bruges til caching af aftaledokumenter |
Error inserting into datastore <exception> | Der er problemer med at indsætte dokument i databasen, der bruges til caching af aftaledokumenter |
I det følgende gennemgåes de typiske fejlscenarier med WARN:
Log pattern | Fejlbeskrivelse |
---|---|
Bookplan server with url:<url> returned error:<error> | Bookplan serveren returnerede andet en HTTP statuskode OK. Statusinfo i <error> |
Bookplan server with url:<url> timed out. <stacktrace> | Bookplan timede ud. Inkluderer stacktrace. |
Calling Bookplan server with url:"+url+" caused exception. <stacktrace> | Ukendt/uspecificeret fejl i kommunikation med Bookplan. Inkluderer stacktrace. |
I det følgende gennemgåes de typiske fejlscenarier med INFO. Da disse skyldes anvender kan det i supportsituationer være en hjælp til fejlfinding:
Log pattern | Fejlbeskrivelse og forklaringer |
---|---|
Returnere tomt svar, da søgning ikke indbefattede APPROVED status. | Anvenderen har søgt på specifikke stati (og ikke APPROVED som en del af disse) |
Query is invalid due to the following: <grund> | Anvenderens søgeparametre ligger udenfor det, der er konfigureret for Aftaleoversigten. Grunden hertil er inkluderet. |
Fejlsøgning kan ske ved at undersøge de logfiler, der er beskrevet i forudgående afsnit.
Det anbefales, at aktuelle konfigurationsfiler til Aftaleoversigt XDS-adaptere holdes under versionskontrol og back-up.
Det er ikke nødvendigt at tage backup af databasen, da data heri ikke skal gemmes ("requestscope")