Versions Compared

Old Version 9

changes.mady.by.user Unknown User (jeh)

Saved on

compared with

New Version Current

changes.mady.by.user Kristian Dorland

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Driftsvejledningen indeholder information der er relevant for driften af Det Fælles Stamkort 1.5-servicen (FSK), herunder oplysninger om standard placering af log- og konfigurationsfiler, eksterne afhængigheder , start/stop/genstart og fejlfinding.

I produktion består Det Fælles Stamkort servicen af én komponent fsk-service web (war-arkiv), der er deployet på en Wildfly applikationsserver.

Servicen har følgende afhængigheder:

  • Der kræves adgang til 2 to MariaDB datasources.Kald til (skrivning til) MinLog-servicen.
  • Kald til (læsning fra) CPR-Enkeltopslag (SCES)
  • Kald til (læsning fra) Organdonorregister-servicen (ODR)
  • Kald til (læsning fra) Livstestamenteregister-servicen (LTR)
  • Kald til (læsning fra) Behandlingstestamenteregister-servicen (BTR)
  • Kald til (læsning fra) Stamkortregister-servicen . (SKR)
  • Kald til (både læsning fra og skrivning til ) Dokumentdelingsservicen og det underliggende registry (DDS).

Ændringslog

...

Version

...

Dato

...

Ændring

...

Ansvarlig

...

2.0.0

...

2018-08-27

...

Initialt dokument

...

Trifork

...

  • ) Fravalg af Genoplivningsforsøg ved Hjertestop Register (FGVHR)

Funktionalitet

Servicen udstiller data som beskrevet i anvenderguiden. Komponenten kaldes alene af Dokumentdelingsservicen (DDS). Servicen udstiller derudover en række administrative og konfigurationsrelaterede funktionaliteter. Servicen har et slettejob, som er beskrevet længere nede i dokumentet.

Direkte kald på service-komponenten

URL

Funktionalitet

<server>/fsk/isAlive

Status-side for FSK servicen. Viser om servicen fungerer korrekt, se afsnittet Overvågning.

<server slettejob>/fsk-operations/fsk-cleanup/status
Returnerer statuskoden for den seneste kørsel af slettejobbet
<server slettejob>/fsk-operations/fsk-cleanup/start
Starter fsk slette jobbet, som sletter stamkort, for personer, der har været afdøde et år
<server slettejob>/fsk-operations/health
Status-side for slettejobbet

Funktionalitet

Servicen udstiller data som beskrevet i anvenderguiden. Komponenten kaldes alene af Dokumentdelingsservicen (DDS). Servicen udstiller derudover en række administrative og konfigurationsrelaterede funktionaliteter.

Direkte kald på service-komponenten

Status-side

URL

Funktionalitet

<server>/fsk/actuator/info

Status-side. Se afsnittet versionsinformation.

<server>/fsk/actuator/health
. Viser om servicen fungerer korrekt, se afsnittet Overvågning.

Daglig drift

Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.

Alt data for en borger fjernes 1 år efter borgerens død ved hjælp af et integreret job kaldet SyncJob. Dette job fjerner både data fra servicens primære database samt fra DDS registry.

Versionsinformation

Servicen udstiller en statusside med versionsinformation. Der returneres en body med JSON-data.
"$.build" indeholder oplysninger om versionen, og hvornår den blev bygget.
"$.time" indeholder oplysninger om det aktuelle tidspunkt, og tidspunktet for hvornår servicen blev deployed.

Eksempel:

Code Block
languagetext
{
    "build": {
        "version": "2.0.8",
        "artifact": "fsk-service",
        "name": "fsk-service",
        "group": "dk.sundhedsdatastyrelsen.stamkort",
        "time": "2019-07-30T07:30:22.496Z"
    },
    "time": {
        "currentTime": "2019-07-30T13:16:18.761Z",
        "deployed": "2019-07-30T13:16:10.382Z"
    }
}

Overvågning

De følgende afsnit beskriver emner i servicen, der kræver opmærksomhed ift. driften.

Health-statusside

Servicen udstiller en Health-statusside (også typisk kendt som isAlive), der viser om applikationen er sund, eller om noget kræver indgriben. Health-statussiden returnerer en body med JSON-data, der beskriver sundhedsstatus for forskellig funktionalitet i applikationen.

Health-statussiden er opbygget vha. Spring Boot Actuator, som er konfigureret med nogle specialfremstillede HealthIndicators.

Actuator beregner en overordnet status for applikationens tilstand, som baseres på den HealthIndicator, der returnerer den mest fatale status. Denne overordnede status vises i JSON-property'en "$.status". Se eksempler længere nede.

Der er udover standard Actuator statusser defineret en specielfremstillet status (NEEDS_ATTENTION). Den følgende tabel viser alle statusser i rækkefølge fra sund til fatal. Tabellen viser også den HTTP statuskode, som Health-statussiden vil returnere til en given overordnet status:

...

Applikationen/funktionen er deaktiveret.

Denne status anvendes pt. ikke.

...

Opførsel for forskellige HealthIndicators

Nogle HealthIndicators anvender ikke nødvendigvis alle statusser men kun udvalgte. Følgende tabel viser, hvad de enkelte HealthIndicators tjekker, og hvornår de returnerer en specifik status.

Bemærk, at det kun er "db"-HealthIndicator'en der kan returnere statussen "DOWN" og dermed udløse HTTP statuskoden "500 Internal Server Error".

...

Tjekker om konfigurede certifikater er tæt på udløb. Der tjekkes alle certifikater i de to keystores der er angivet i property'erne application.properties:"client.keystore.filesystem.path" og i minlogclient.properties:"sts.keystore". Derudover vises detaljer om udløbsdato for alle certifikater (dvs. hvis en keystore indeholder flere certifikater, så vises detaljer for alle).

UP: OK
NEEDS_ATTENTION: Der er et certifikat, som udløber om mindre end det antal dage, der er konfigureret i property'en "health.certificate-expires-warning".

...

$.details.organDonorClient
$.details.livingWillClient
$.details.treatmentWillClient
$.details.personalDataCardRegisterClient
$.details.scesClient
$.details.minLogClient

...

Tjekker om det seneste kald med den pågældende integration var succesfuldt. Hvis det ikke var succesfuldt, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor et kald blev forsøgt (uanset om det var successfuldt eller ikke-successfuldt).

UP: OK
UNKNOWN: Der er ikke udført nogen kald med den pågældende integration, siden applikationen blev deployed.
NEEDS_ATTENTION: Der opstod en fejl under seneste forsøg på at kalde med den pågældende integration.

...

Tjekker om den seneste afvikling af jobbet var successfuld. Hvis den ikke var succesfuld, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor jobbet blev forsøgt afviklet.

UP: OK
UNKNOWN: Der er ikke udført nogen kørsel af jobbet, siden applikationen blev deployed.
NEEDS_ATTENTION: Der opstod en fejl under seneste forsøg på at afvikle jobbet.

...

Er baseret på Actuator's indbyggede DataSourceHealthIndicator og tjekker, at der kan udføres en "SELECT 1" query på alle applikationens datasources. Query'en udføres i det øjeblik Health-statussiden forespørges. Der vises detaljer om status for de enkelte datasources.

UP: OK
DOWN: Der opstod en fejl under forsøget på at udføre test-query'en på en af applikationens datasources.

Opsætning

I application.properties kan der indstilles forkellige ting. Her følger et eksempel:

Code Block
author.institution.root=1.2.208.176.1.1
author.institution.extension=1126211000016009
author.institution.assigningAuthorityName=SOR
author.institution.name=Sundhedsdatastyrelsen

health.certificate-expires-warning=30

# JNDI datasource properties
datasource-fsk.jndi-name=java:jboss/datasources/FSK-DS
datasource-stm.jndi-name=java:jboss/datasources/STM-DS

sts.endpoint=http://test1.ekstern-test.nspop.dk:8080/sts/services/NewSecurityTokenService

# SCES
sces.enable=true
sces.endpoint=http://test1.ekstern-test.nspop.dk:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4
sces.connect.timeout.millis=2000
sces.read.timeout.millis=7000

# ODR
odr.enable=true
odr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/odr/odr
odr.connect.timeout.millis=2000
odr.read.timeout.millis=7000

# LTR
ltr.enable=true
ltr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/btr/ltr
ltr.connect.timeout.millis=2000
ltr.read.timeout.millis=7000

# BTR
btr.startdatetime=2019-01-01 00:00:00
btr.enable=true
btr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/btr/btr
btr.connect.timeout.millis=2000
btr.read.timeout.millis=7000

# SKR
skr.enable=true
skr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/skr/skr
skr.connect.timeout.millis=2000
skr.read.timeout.millis=7000

# SYES
syes.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-yder-lookup-ws/service/YderService
syes.connect.timeout.millis=2000
syes.read.timeout.millis=7000

# FGVHR - De andre services genbruger ID-kort og HSUID-header som FSK modtager, til at kalde videre. Det gør FGVHR ikke, derfor skal certifikat og ID-kort konfigureres:
fgvhr.enable=true
fgvhr.endpoint=http://test1-cnsp.ekstern-test.nspop.dk:8080/fgvhr/20230601/hasNoResuscitation
fgvhr.connect.timeout.millis=2000
fgvhr.read.timeout.millis=7000
fgvhr.sts.keystore=NSP_Test_Service_Consumer_sds.p12 # skal mappes ind i containeren på følgende sti, så navnet på keystore stemmer overens: /pack/wildfly/modules/dk/sundhedsdatastyrelsen/fsk/main/NSP_Test_Service_Consumer_sds.p12
fgvhr.sts.keystore.password=Test1234
fgvhr.idcard.subject.name=Sundhedsdatastyrelsen
fgvhr.idcard.subject.id=33257872
fgvhr.idcard.system.name=FSK

# Cleanup
deletion.fsk.batchsize=1000
desired.execution.duration=PT20S
deletion.save.deceased=12M

# PersonInformation
personinformation.url=http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-personinformation/v1
personinformation.errorcount.duration=PT10M
personinformation.error.tolerance=0
fsk.httpclient.pooling.totalconnections=200
fsk.httpclient.pooling.maxconnections.pr.route=20

Daglig drift

Servicen kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.

Alt data (inkl. historiske data) for en borger fjernes 1 år efter borgerens død ved hjælp af slettejobbet.

Overvågning

De følgende afsnit beskriver emner i servicen, der kræver opmærksomhed ift. driften.

Health-statusside

FSK Servicen udstiller en Health-statusside (også typisk kendt som isAlive), der viser om applikationen er sund, eller om noget kræver indgriben. Health-statussiden returnerer en body med data, der beskriver sundhedsstatus for forskellig funktionalitet i applikationen.

Ud over status, indholder siden også data omkring byg, installation, version mm. Se eksemplet nedenfor.

Health-statussiden er opbygget vha nogle specialfremstillede HealthIndicators.

Der beregnes en overordnet status for applikationens tilstand, som baseres på den HealthIndicator, der returnerer den mest fatale status. 

Denne status returneres som http  status kode, men indgår også i selve indholdet, med information omkring, hvilken healthindicator, som kræver opmærksomhed (kun den første, hvis flere med samme kritikalitet)

Tabellen viser den HTTP statuskode, som Health-statussiden vil returnere. Fra sund til fatal.

HTTP statuskodeBeskrivelse
200 OKIngen fejl.
203 Non authoratative informationEn fejl kræver måske indgriben, men applikationen fungerer fortsat med nedsat funktion.
500 Internal Server ErrorApplikationen/funktionen er nede og kræver øjeblikkelig indgriben.

Opførsel for forskellige HealthIndicators

Nogle HealthIndicators anvender ikke nødvendigvis alle statusser men kun udvalgte. Følgende tabel viser, hvad de enkelte HealthIndicators tjekker, og hvornår de returnerer en specifik status.

Navn i responseBeskrivelse

organDonorClient
livingWillClient
treatmentWillClient
personalDataCardRegisterClient
yderClient
scesClient
FgvhrClient

Tjekker om det seneste kald med den pågældende integration var succesfuldt. Hvis det ikke var succesfuldt, så viser "error" en toString() på den exception der opstod. Der vises eventuelt "timeOfLastExecution", som angiver det seneste tidspunkt, hvor et kald blev forsøgt (uanset om det var successfuldt eller ikke-successfuldt).

Statuskode 200: OK
Statuskode 203: Der opstod en fejl under seneste forsøg på at kalde med den pågældende integration.

fsk database
stm database

Tjekker, at der kan udføres en "SELECT 1" query på alle applikationens datasources. Query'en udføres i det øjeblik Health-statussiden forespørges. Der vises detaljer om status for de enkelte datasources.

Statuskode 200: OK
Statuskode 500: Der opstod en fejl under forsøget på at udføre test-query'en på en af applikationens datasources.

Eksempel på response, når applikationen er sund

HTTP statuskode: 200 OK

Code Block
languagetext
Title: fsk-web
Deployed: 2024-08-05T12:28:04.506Z
Build-Date: 2024-08-05T12:26:14Z
Build-Version: 2.2.1
Builder: lene
Display time: 2024-08-05T12:54:07.418Z

200 OK
organDonorClient : "timeOfLastExecution: 2024-08-05T12:53:38.116Z"
livingWillClient : "timeOfLastExecution: 2024-08-05T12:53:38.114Z"
treatmentWillClient : "timeOfLastExecution: 2024-08-05T12:53:38.114Z"
personalDataCardRegisterClient : "timeOfLastExecution: 2024-08-05T12:53:38.204Z"
yderClient : "timeOfLastExecution: 2024-08-05T12:53:38.251Z"
scesClient : "timeOfLastExecution: 2024-08-05T12:53:38.115Z"
FgvhrClient : "timeOfLastExecution: 2024-08-05T12:53:38.114Z"
fsk database : "Forbindelse til database fsk ok"
stm database : "Forbindelse til database stm ok"

Eksempel på response, når noget i applikationen kræver indgriben

HTTP statuskode: 203 Non Authoritative Information

Code Block
languagetext
Title: fsk-web
Deployed: 2024-08-05T12:57:50.776Z
Build-Date: 2024-08-05T12:26:14Z
Build-Version: 2.2.1
Builder: lene
Display time: 2024-08-05T12:58:40.406Z

203 Non Authoritative Information from:organDonorClient
organDonorClient : "timeOfLastExecution: 2024-08-05T12:58:35.228Z"
livingWillClient : "timeOfLastExecution: 2024-08-05T12:58:35.325Z"
treatmentWillClient : "timeOfLastExecution: 2024-08-05T12:58:35.309Z"
personalDataCardRegisterClient : "timeOfLastExecution: 2024-08-05T12:58:35.408Z"
yderClient : "timeOfLastExecution: 2024-08-05T12:58:35.457Z"
scesClient : "timeOfLastExecution: 2024-08-05T12:58:35.294Z"
FgvhrClient : "timeOfLastExecution: 2024-08-05T12:58:35.274Z"
fsk database : "Forbindelse til database fsk ok"
stm database : "Forbindelse til database stm ok"

Slettejobbet status endpoints

Slettejobbet har sine egne status endpoints

<server slettejob>/fsk-operations/fsk-cleanup/status: fortæller med en http kode, hvordan den seneste sletning gik.

<server slettejob>/fsk-operations/health: fortæller status til eksterne services og database. Hvis de melder fejl så tjek log filerne.

Eksempel på svar fra health endpointet:

Code Block
languagetext
{
   "DB":"OK",
   "PersonInformation":"OK"
}

Fejlfinding

Servicens logfiler bør løbende tjekkes for ERROR-logninger.

Logfiler og fortolkning af disse

Alle logfiler er at finde i ”log” under Wildfly. Herunder findes en liste over logfiler, med en beskrivelse af hvilke komponenter der skriver til dem.

Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.

Logfilnavn

Indhold

fsk_service.log

Applikationslog fra FSKservicen, som indeholder de vigtigste systemhændelser (INFO), fejl (ERROR) og advarsler (WARN).

fsk_audit.log

Auditlog fra FSK-servicen, som indeholder logning af, hvilken service der blev kaldt, hvordan der blev kaldt, hvornår der blev kaldt samt kaldets varighed. Bemærk, Da FSK-servicen kun udstiller én webservice, som er on-demand servicen til kald fra DDS og SFSK, vil mange oplysninger være éns fra kald til kald.

Auditlog

Følgende tabel viser hvad der audit logges ved successfulde kald til fsk.

KomponentKontekstTypeNøgleInformation
FSKretrieveDocumentSetIkke Personligdocument-idID på hentet dokument
FSKretrieveDocumentSetFølsommecprCPR på borgeren

Krav til backup m.m.

Servicen indeholder ikke nogen backup-mekanismer, og dette skal derfor konfigureres på database-niveau. Der bør foretages backup af data på en forsvarlig måde, i tilfælde af behov for en genetablering af data. Disse data skal opbevares på en forsvarlig måde, jfr. regler om personhenførbare data.

Slette job

Detaljer omkring de forskellige trin slettejobbet har, kan findes i FSK Design og arkitektur dokumentet.

Servicens slettejob bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald. 

Driften vedligeholder en cron, som kalder slettejobbets url i et fast mønster vha. curl.

Man kan ændre styring af slettejobbet ved at ændre følgende parametre:

  • desired.execution.duration=PT20S
    Det er en max grænse for hvor lang tid jobbet må køre pr. gang. Når jobbet har kørt den tid der er angivet, så stopper udførslen. Her efter kan jobbet kaldes igen og den vil fortsætte med processeringen hvor jobbet stoppede sidst.
    Parameteren angives som en Duration i ISO-8601 format. Dvs. eksemplet viser 20 sekunder.
  • deletion.fsk.batchsize=1000
    Det er en max grænse for, hvor mange cpr numre, der håndteres af gangen. Blandt andet i forbindelse med kald til PersonInformation deceased og den videre sletning af stamkort.
  • deletion.save.deceased=12M
    Angiver hvor lang tid en person skal være død for at stamdata bliver slettet

Kommando til kald af slettejob: <server>/fsk-operations/fsk-cleanup/start

Eksempel på response, når applikationen er sund

HTTP statuskode: 200 OK

Code Block
languagetext
{
    "status": "UP",
    "details": {
        "certificateExpiry": {
            "status": "UP",
            "details": {
                "certificates": [
                    {
                        "file": "test1/FMK-KRS-TEST.jks",
                        "alias": "sosi:alias_system",
                        "validFrom": "2017-04-04T13:39:50Z",
                        "validUntil": "2020-04-04T13:39:27Z"
                    },
                    {
                        "file": "test1/FMK-KRS-TEST.jks",
                        "alias": "sosi:alias_system",
                        "validFrom": "2017-04-04T13:39:50Z",
                        "validUntil": "2020-04-04T13:39:27Z"
                    }
                ]
            }
        },
        "organDonorClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.245Z"
            }
        },
        "livingWillClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        "treatmentWillClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.245Z"
            }
        },
        "personalDataCardRegisterClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        "scesClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.566Z"
            }
        },
        "minLogClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.569Z"
            }
        },
        "syncJob": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T18:00:05.321Z"
            }
        },
        "db": {
            "status": "UP",
            "details": {
                "primaryDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "MySQL",
                        "hello": 1
                    }
                },
                "stamdataDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "MySQL",
                        "hello": 1
                    }
                }
            }
        }
    }
}

Eksempel på response, når noget i applikationen kræver indgriben

HTTP statuskode: 202 Accepted

Code Block
languagetext
{
    "status": "NEEDS_ATTENTION",
    "details": {
        "certificateExpiry": {
            "status": "UP",
            "details": {
                "certificates": [
                    {
                        "file": "test1/FMK-KRS-TEST.jks",
                        "alias": "sosi:alias_system",
                        "validFrom": "2017-04-04T13:39:50Z",
                        "validUntil": "2020-04-04T13:39:27Z"
                    },
                    {
                        "file": "test1/FMK-KRS-TEST.jks",
                        "alias": "sosi:alias_system",
                        "validFrom": "2017-04-04T13:39:50Z",
                        "validUntil": "2020-04-04T13:39:27Z"
                    }
                ]
            }
        },
        "organDonorClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.245Z"
            }
        },
        "livingWillClient": {
            "status": "NEEDS_ATTENTION",
            "details": {
                "error": "java.io.IOException: HTTP POST failed (404): Not Found",
                "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        "treatmentWillClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.245Z"
            }
        },
        "personalDataCardRegisterClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.246Z"
            }
        },
        "scesClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.566Z"
            }
        },
        "minLogClient": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T17:31:13.569Z"
            }
        },
        "syncJob": {
            "status": "UP",
            "details": {
                "timeOfLastExecution": "2019-07-30T18:00:05.321Z"
            }
        },
        "db": {
            "status": "UP",
            "details": {
                "primaryDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "MySQL",
                        "hello": 1
                    }
                },
                "stamdataDataSource": {
                    "status": "UP",
                    "details": {
                        "database": "MySQL",
                        "hello": 1
                    }
                }
            }
        }
    }
}

Fejlfinding

Servicens logfiler bør løbende tjekkes for ERROR-logninger.

En service eller et job kan genstartes ved at kalde touch på den tilsvarende war-fil. I yderste konsekvens kan Wildfly genstartes.

SyncJob

Jobbet sørger for oprettelse/nedlæggelse af metadata i DDS registry i takt med ændringer i CPR-registeret (fødsler/dødsfald). Ifm. midlertidige fejl fra DDS, vil jobbet standse og forsøge igen senere (afhængigt af CRON-udtrykket i "jobs.ddssync.schedule" i application.properties). Det er dog også tænkeligt at DDS returnerer en logisk fejl, hvor det ikke giver mening at forsøge igen senere. Derfor er FSK udstyret med en property "jobs.ddssync.max.errors", hvor det er muligt at angive hvor mange fejl jobbet accepterer før det standser. Normalt bør værdien være '0', hvilket betyder at man ikke accepterer fejl, og at jobbet derfor vil forsøge igen med den samme besked. For at tillade jobbet at ignorere den ene fejl, kan værdien sættes til '1', og så bør der kigges nærmere på hvad der gemmer sig bag fejlen, så der kan ske manuelt data-opret.

Følgende logning kan ses hvis SyncJob støder på et midlertidigt problem, og derfor opgiver videre behandling før CRON-udtrykket tillader det:

Code Block
2018-08-27 15:14:18.627 [main] WARN dk.stamkort.integrations.dds.SyncJob [] - CPR -> DDS synchronization job stopped due to temporary error. Sync will pause and retry later
dk.stamkort.dao.exceptions.DDSTemporaryException: 
 at dk.stamkort.integrations.dds.SyncJob.createDDRegistryEntry(SyncJob.java:245) ~[classes/:?]
 at dk.stamkort.integrations.dds.SyncJob.runSyncPersonIds(SyncJob.java:144) [classes/:?]
 at dk.stamkort.integrations.dds.SyncJobTest.runSynchronizationJob(SyncJobTest.java:329) [test-classes/:?]
 at dk.stamkort.integrations.dds.SyncJobTest.testJobErrorHandlingForTemporaryError(SyncJobTest.java:282) [test-classes/:?]
 at ...

Nedenstånde logning ses hvis antallet af logiske fejl overskrides, så jobbet opgiver videre behandling:

Code Block
2018-08-27 15:14:14.495 [main] WARN dk.stamkort.integrations.dds.SyncJob [] - DDS logical error for documentId=urn:sds:fsk:stamkort:3ed5c350-f71d-4337-9d20-1d7d3911f461

dk.stamkort.dao.exceptions.DDSPermanentException: 
 at dk.stamkort.integrations.dds.SyncJob.createDDRegistryEntry(SyncJob.java:245) ~[classes/:?]
 at dk.stamkort.integrations.dds.SyncJob.runSyncPersonIds(SyncJob.java:144) [classes/:?]
 at dk.stamkort.integrations.dds.SyncJobTest.runSynchronizationJob(SyncJobTest.java:329) [test-classes/:?]
 at dk.stamkort.integrations.dds.SyncJobTest.testJobErrorHandlingForPermanentError(SyncJobTest.java:304) [test-classes/:?]
 at ...
2018-08-27 15:14:14.496 [main] ERROR dk.stamkort.integrations.dds.SyncJob [] - Max number of errors (2) exceeded for SyncJob (max allowed is 1)

...

Alle logfiler er at finde i ”log” under Wildfly. Herunder findes en liste over logfiler, med en beskrivelse af hvilke komponenter der skriver til dem. Log konfigurationen for servicen er konfigureret i modules/dk/sundhedsdatastyrelsen/fsk/main/resources/log4j2.xml som der også er vist et eksempel på i  Installationsvejledning (FSK) . 

Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet, der ikke er præsenteret i nedenstående.

...

Logfilnavn

...

Indhold

...

fsk_service.log

...

Applikationslog fra FSKservicen, som indeholder de vigtigste systemhændelser (INFO), fejl (ERROR) og advarsler (WARN).

...

fsk_audit.log

...

Krav til backup m.m.

...