Version 2.3, 2019-08-19
Indholdsfortegnelse
Indholdsfortegnelse
1 Formål
2 Komponenter og funktionalitet
3 Daglig drift
4 Konfiguration
4.1 Tilføjelse af CVR-numre og typer
5 Overvågning
5.1 Fortolkning af HTML overvågningsside
5.2 Overvågningstyper
5.3 Logfiler og fortolkning af disse
5.4 Konfiguration af overvågning
5.5 Eksempler på status-sider
6 Standard fejlsøgning
7 Krav til backup m.m.
8 Ændringslog
Dokument målrettet systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.
Driftsvejledningen indeholder information om komponentens version, standard placering af logfiler og konfigurationsfiler, eksterne afhængigheder, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.
Start/stop vejledning for komponenten beskrives, herunder hvilke andre applikationer der evt. skal genstartes. En generel læsevejledning til logfiler vedlægges.
Dette dokument dækker følgende komponenter på NSP og Backoffice:
Komponenterne og deres funktionalitet ses vist i nedenstående diagram:
BRS kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
Al konfiguration på hhv. NSP og Backoffice foregår ved redigering i hhv. brs-frontend.properties og brs-backend.properties. Disse filer er volume-mounted ind, , der placeres i "configuration"-folderen under Wildfly.
Bemærk at brs-frontend.properties og brs-backend.properties i visse situationer "overlapper", dvs. indeholder ens properties. Det skyldes fx at man forsøger at skabe evidens både i frontend og backend.
Nedenstående tabel giver en beskrivelse af hver property der kan sættes i filerne og dens default værdier.
Property | Beskrivelse | Default |
---|---|---|
dk.nsi.db.type | Angiver hvilken type database der bruges, værdier kan være "hsqldb" til udvikling og "mysqldb" til test og produktion. | hsqldb |
dk.nsi.validation.mode | Bruges til at bestemme hvordan SAML ID kort skal valideres, kan have 3 værdier "devel", "test" og "prod". bruges "devel" og "test" vil ID kort blive valideret mod seals SosiTestFactory, bruges "prod" vil ID kort blive valideret imod SOSI STS'en | devel |
dk.nsi.auth.whitelistservice.type | Hvilken whitelistservice bruges der. Kan enten være "property" eller "database" | property |
dk.nsi.auth.create.type.cvr.list | Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property" | <tom> |
dk.nsi.auth.query.type.type.cvr.list | Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property" | <tom> |
dk.nsi.auth.brs.cvr.list | Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property" | |
dk.nsi.db.{navn}.url | Database URL - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.{navn}.driverclass | Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.{navn}.user | Database brugernavn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.{navn}.pwd | Database adgangskode - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.{navn}.database | Database navn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.replicationjob.enabled | Angiver om jobbet er enablet. Er obligatorisk | |
dk.nsi.replicationjob.schedule | CRON-udtryk der afgør hvornår jobbet kører. Se evt. denne beskrivelse. Er obligatorisk. | |
dk.nsi.replicationjob.wsdlurl | Bruges af ReplicationJob til at replikere opfølgninger til backendens replication service. | |
dk.nsi.replicationjob.transferWindow | Definerer det maksimale antal opfølgninger der må sendes ad gangen til backend. | 1000 |
dk.nsi.replicationjob.maxtime | Max tid i minutter en replikering må tage før der laves en alarm. | 120 |
dk.nsi.followupjob.enabled | Angiver om jobbet er enablet. Er obligatorisk | |
dk.nsi.followupjob.schedule | CRON-udtryk der afgør hvornår jobbet kører. Se evt. denne beskrivelse. Er obligatorisk. | |
dk.nsi.followupjob.processingWindow | Definerer antallet af opfølgninger som behandles af gangen i én transaktion | 1000 |
dk.nsi.followupjob.maxtime | Max tid i minutter en behandling af opfølgninger må tage før der laves en alarm. Det er tiden for een batchbehandling der måles imod og ikke den fulde kørsel. | 120 |
dk.nsi.days.to.postpone.next.check | Bruges af FollowupJob: definerer tidsrummet for hvornår næste check af en opfølgning skal laves. Værdien er defineret i dage | 2 |
dk.nsi.notificationcleanupjob.enabled | Angiver om jobbet er enablet. Er obligatorisk | |
dk.nsi.notificationcleanupjob.schedule | CRON-udtryk der afgør hvornår jobbet kører. Se evt. denne beskrivelse. Er obligatorisk. | |
dk.nsi.notificationcleanupjob.olderThanDays | Fjern alarmer som er ældre end denne værdi. Værdien er defineret i dage | 75 |
dk.nsi.notificationcleanupjob.maxtime | Max tid i minutter en oprydning må tage før der laves en alarm. | 120 |
dk.nsi.relation.assigneddoctor.update.frequency | Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge. | 10 |
dk.nsi.relation.refhost.update.frequency | Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge. | 2 |
dk.nsi.relation.ssr.update.frequency | Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge. | 62 |
dk.nsi.app.name | Angiver navnet på applikationen. Bruges til at oprette SlaLogInput, som bruges til SLA logninger i facaden mod SORLS. | Behandlingsrelationsservice |
dk.nsi.app.shortName | Angiver navnet på applikationen i kort form. Bruges til at oprette SlaLogInput, som bruges til SLA logninger i facaden mod SORLS. | BRS |
dk.nsi.brs.relayer.sor.all.enabled | Denne variable bruges til at styre om det skal være ny kode der skal bruges. Den "gamle" kode er dog opdateret, så den bruges SOR servicen til at mappe fra Shak til Sor. | true |
dk.nsi.brs.sor.url | Der peges på den SORES service man vil kalde op imod. Hvis man har en lokal udgave kørende af SORES servicen, så kan man med fordel ændre url'en til http://localhost:8080/sores | http://test1-cnsp.ekstern-test.nspop.dk:8080/sores/ |
dk.nsi.brs.sor.fail.threshold | Denne værdi bruges i IsAlive fra MSBUtil. Den angiver hvor mange tidligere kald til servicen, hvor vi holder styr på status. Så hvis værdien er 10, så gemmes status for de sidste 10 kald og hvis blot en af dem har været gennemført uden fejl, så antages servicen at være tilgængelig. | 10 |
Følgende databaser kan refereres via {navn} ovenfor:
Miljø | Navn | Beskrivelse |
---|---|---|
BRS-Frontend | stamdata | AssignedDoctor-stamdata |
followup | Data der afventer afsendelse til BRS-Backend | |
register_notifications | Notifikationer til klienter samt SSR/LPR/REFHOST-stamdata. MySQL-replikeres fra backend | |
BRS-Backend | stamdata | AssignedDoctor-stamdata |
register_notifications | Notifikationer til klienter samt SSR/LPR/REFHOST-stamdata. MySQL-replikeres til frontends | |
treatment_releation_followup | Data der modtages fra frontends |
Tilføjelse af CVR numre og typer på NSP'erne foregår i MySQL i tabellen whitelist_config i databasen register_notification. Når en ny af disse tilføjes replikeres opsætningen ud til de øvrige NSP'er automatisk. Der kræves ingen opdatering af brs-frontend/brs-backend.properties i den forbindelse.
BRS-frontend og BRS-backend udstiller overvågningssider, som findes i listen af komponenter i afsnit 2.
På overvågningssiderne fremgår komponentens version og build-dato, opstartstidspunkt samt tidspunkt for testudførsel. Desuden vises udvalgte metrikker angående kaldmængder/antal processeringer (se eksempler i afsnit 5.5).
BRS-overvågningssider returnerer enten:
Grunden til at der returneres HTTP 202 hvis der ikke er forbindelse til backend er, at BRS-frontend stadig kan modtage data, og derfor ikke skal tages ud af load-balanceren. Dog kan fejlen ikke ignoreres på længere sigt.
Der overvåges databaseadgang for de enkelte datasources ved et simpelt "SELECT 1" statement.
For batchjob overvåges der seneste succesfulde kørsel. Hvis denne ikke er udført inden for det forventede tidsrum giver dette anledning til en fejl.
Enhver tilgang til en overvågningsside giver anledning til en mere detaljeret log-indgang hvis den giver fejl.
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. De enkelte filnavne er konfigureret i logging-profiles i configuration/standalone.xml. Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet (fx brs-frontend.log.1) der ikke er præsenteret i nedenstående liste.
Logfilnavn | Komponenter der skriver til denne |
---|---|
brs-frontend.log | brs-frontend.war. Diverse logninger af komponentens opførsel, inklusiv fejllogninger. |
audit.log | brs-frontend.war, audit-logning af requests vha. Audit-api |
brs-metrics.log | Indeholder udvalgte logninger om svartider, antal behandlede records osv. Skrives både af frontend og backend. |
brs-backend.log | brs-backend.war. Diverse logninger af komponentens opførsel, inklusiv fejllogninger. |
Ved en fejl på en overvågningsside skrives der til den relevante brs-frontend/brs-backend.log. Alle logs indekseres med Splunk.
I forbindelse med at LPR3 gør brug af SORLS, som kilde til bl.a. mapning fra Shak til Sor, så er der også indført en mere detaljeret logning af de tjeks der udføres, når klassifikation skal findes for LPR3.
For alle rækker i en Evidens log findes værdierne:
1786 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Start, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3 1806 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Key=Opslagsdata, Data=CheckedRelationRelayerData[doctorOrganisationIdentifier:<null>,hospitalOrganisationIdentifier:730014,ean:<null>,sorIdentifier:<null>,patientCpr:F12215675B5AE9A7DF1741D7A05DA0D244874A4A,healthProfessionalCpr:<null>,relationLookupTimeInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000] 1806 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Execute, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Action=Executing with SHAK, Active=yes 1806 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Collect identifier=D1, From=SorlsServiceDao.getShakSorMap, Into=SOR(sundhedsprof), ShakIdentifier=730014 1806 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Collect identifier=D1, From=SorlsServiceDao.getShakSorMap, Into=SOR(sundhedsprof, sygehus), ShakIdentifier=730014 1807 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Collect identifier=D2, From=SorlsServiceDao.searchAllChildren, Into=SOR(sundhedsprof), SOR(sundhedsprof)=[439061000016004] 1807 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Key=SOR(sundhedsprof), Data=[439061000016004] 1807 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Key=SOR(sundhedsprof, sygehus), Data=[] 1815 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Key=LPR3 data, Data=[LPR3[patientCpr:F12215675B5AE9A7DF1741D7A05DA0D244874A4A,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111114,relationType:RESULTATINDBERETNING,sorIdentifier:439061000016004]] 1815 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Check identifier=C1, Question=Findes LPR3 data for patienten på præcis SOR(sundhedsprof) eller på en SOR kode der ligger under SOR(sundhedsprof) i SOR hierarkiet?, Answer=yes 1815 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Check identifier=C2, Question=Er der overlap mellem dato-interval for LPR3 registreringer og input tidsintervallet?, Answer=yes 1816 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Check identifier=C3, Question=Hvilken type har de matchende LPR3 registreringer?, Answer=resultatindberetning eller opholdsadresse 1816 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Check identifier=C6, Question=Tjekke SOR(sundhedsprof, sygehus) og beregne "max", Answer=yes 1816 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Execute, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Action=Executing Tjek SOR(sundhedsprof, sygehus), Active=yes 1875 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Key=LPR3 data, Data=[LPR3[patientCpr:F12215675B5AE9A7DF1741D7A05DA0D244874A4A,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111111,relationType:FORLOEBSELEMENT,sorIdentifier:439061000016001]] 1875 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Check identifier=C4, Question=Findes LPR3 data for patienten med overlap på input tidsinterval og med typerne relationstyperne forløbslement, kontakt, procedure, intitiel henvisning eller henvisning?, Answer=yes 1876 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Collect identifier=D3, From=SorlsServiceDao.getSorEntity, Into=SOR(sundhedsprof), LPR3 data=[LPR3[patientCpr:F12215675B5AE9A7DF1741D7A05DA0D244874A4A,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111111,relationType:FORLOEBSELEMENT,sorIdentifier:439061000016001]] 1877 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Key=SOR sygehuskode, Data=-9223372036854775808 1877 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Stop, securityLevel=3, flowID=0cc89090-0617-4145-a5a3-e202b36e3720, messageID=test, Type=LPR3, Classification Result=B |
Auditlogning foretages med det officielle NSP Audit Log modul.
Kald af metoden treatmentRelation på webservicen BRSFacade logges følgende oplysninger:
Komponent | Kontekst | Type | Nøgle | Information |
---|---|---|---|---|
BRS | TreatmentRelationRequest | Personlig | cvrFromHeader | CVR nummeret for den kaldende organisation |
BRS | TreatmentRelationRequest | Ikke Personlig | queryableCvr | CVR nummer der skal have adgang til en eventuel efterfølgende notifikation. |
BRS | TreatmentRelationRequest | Personlig | healthProfessionalIdentifierCpr | Behandlers cpr-nummer. |
BRS | TreatmentRelationRequest | Ikke Personlig | healthProfessionalIdentifierValidityStart | Starttidspunkt for hvilket behandleren har foretaget opslaget. |
BRS | TreatmentRelationRequest | Ikke Personlig | healthProfessionalIdentifierValidityEnd | Sluttidspunkt for hvilket behandleren har foretaget opslaget. |
BRS | TreatmentRelationRequest | Ikke Personlig | acceptableRelations | En liste af acceptable relationer |
BRS | TreatmentRelationRequest | Personlig | authorisationIdentifier | Autorisationskode for den behandleren. |
BRS | TreatmentRelationRequest | Ikke Personlig | followupRelations | En liste af relationer der, i tilfælde af at ingen acceptable relationer forefindes, vil give anledning til en opfølgning |
BRS | TreatmentRelationRequest | Personlig | doctorOrganisationIdentifier | Organisationen inden for hvilken relationen skal findes |
BRS | TreatmentRelationRequest | Personlig | ean | Organisationen inden for hvilken relationen skal findes |
BRS | TreatmentRelationRequest | Personlig | hospitalOrganisationIdentifier | Organisationen inden for hvilken relationen skal findes |
BRS | TreatmentRelationRequest | Personlig | sor | Organisationen inden for hvilken relationen skal findes |
BRS | TreatmentRelationRequest | Personlig | patientCpr | Patientens cpr-nummer. |
BRS | TreatmentRelationRequest | Ikke Personlig | timeLimit | Udløbstidspunkt for opfølgningen efter hvilket der skal oprettes en notifikation, hvis de angivne kriterier ikke er opfyldt |
BRS | TreatmentRelationRequest | Ikke Personlig | serviceProviderVendor | Udvikler af klient |
BRS | TreatmentRelationRequest | Ikke Personlig | serviceProviderName | Navn på serviceudbyderen/klienten |
BRS | TreatmentRelationRequest | Ikke Personlig | serviceProviderVersion | Version af klient |
BRS | TreatmentRelationRequest | Ikke Personlig | didCallerSpecifyExternalReferenceId | Var ekstern reference identifikation angivet i request |
BRS | TreatmentRelationRequest | Ikke Personlig | externalReferenceId | Et id der vil blive brugt ved returnering af en eventuel notifikation. |
BRS | TreatmentRelationRequest | Ikke Personlig | uid | Genereret unik identifikation |
BRS | TreatmentRelationRequest | Ikke Personlig | uniqueReferenceId | Unik identifikation angivet i svaret Samme som uid |
BRS | TreatmentRelationRequest | Følsomme | actualRelations | Aktuelle forbindelser |
Eksempel på auditlogningen:
{ "time": "2019-08-19T03:05:02.071Z", "category": "dk.sds.nsp.audit.log.brs", "audit": { "timestamp": "2019-08-19T05:05:02.028+02:00", "components": [ { "component": "BRS", "contexts": [ { "context": "TreatmentRelationRequest", "information": [ { "key": "cvrFromHeader", "type": "RPI", "value": "46837428" }, { "key": "queryableCvr", "type": "NPI", "value": "46837428" }, { "key": "healthProfessionalIdentifierCpr", "type": "RPI", "value": "1007707419" }, { "key": "healthProfessionalIdentifierValidityStart", "type": "NPI", "value": "2019-01-01T05:05:01.000+01:00" }, { "key": "healthProfessionalIdentifierValidityEnd", "type": "NPI", "value": "2020-01-01T05:05:01.000+01:00" }, { "key": "acceptableRelations", "type": "NPI", "values": [ "C" ] }, { "key": "authorisationIdentifier", "type": "RPI", "value": "" }, { "key": "followupRelations", "type": "NPI", "value": "ALL" }, { "key": "doctorOrganisationIdentifier", "type": "RPI", "value": "" }, { "key": "ean", "type": "RPI", "value": "1234567890123" }, { "key": "hospitalOrganisationIdentifier", "type": "RPI", "value": "" }, { "key": "sor", "type": "RPI", "value": "null" }, { "key": "patientCpr", "type": "RPI", "value": "3112910017" }, { "key": "timeLimit", "type": "NPI", "value": "2016-01-01T05:05:01.000+01:00" }, { "key": "serviceProviderVendor", "type": "NPI", "value": "arosii" }, { "key": "serviceProviderName", "type": "NPI", "value": "service" }, { "key": "serviceProviderVersion", "type": "NPI", "value": "snapshot" }, { "key": "didCallerSpecifyExternalReferenceId", "type": "NPI", "value": "no" }, { "key": "externalReferenceId", "type": "NPI", "value": "7412a3ec-953e-4792-a3bf-d512088571fb" }, { "key": "uid", "type": "NPI", "value": "f25d011b-fba1-42fa-a0a7-5ee327b50e44" }, { "key": "uniqueReferenceId", "type": "NPI", "value": "f25d011b-fba1-42fa-a0a7-5ee327b50e44" }, { "key": "actualRelations", "type": "SPI", "values": [ "D" ] } ] } ] } ] }, "access": { "code": 200, "duration": 33, "httpHeaders": { "Content-Type": "text/xml; charset=utf-8", "SOAPAction": "\"\"" }, "httpHost": "localhost", "idCardAttributes": { "medcom:CareProviderID": "46837428", "medcom:CareProviderName": "Statens Serum Institut", "medcom:ITSystemName": "it system", "sosi:AuthenticationLevel": "3", "sosi:IDCardID": "JqjzhVMxTrwrm3jCVoj8nw==", "sosi:IDCardType": "system", "sosi:IDCardVersion": "1.0.1" }, "method": "POST", "path": "/brs-nsp/service/brs", "query": "wsdl", "port": 9090, "protocol": "http", "reqSize": 8484, "resSize": 2469, "soapHeaders": { "Issuer": "TEST1-NSP-STS", "MessageID": "AAABbKfVyyx0S3W3tl49ilNPU0k=", "NameID": "SubjectDN={SERIALNUMBER=CVR:46837428-FID:92421325 + CN=Funktionssignatur til testmiljø (funktionscertifikat), O=Statens Serum Institut // CVR:46837428, C=DK},IssuerDN={CN=TRUST2408 Systemtest XXII CA, O=TRUST2408, C=DK},CertSerial={1495058032}" }, "threadId": "default task-59", "time": "2019-08-19T05:05:02.027+02:00", "stats": { "handlerDuration": 6, "bufferAllocated": false, "usedBuffers": 2, "activeBuffersInPool": 2, "idleBuffersInPool": 0 } } } |
Følgende settings påvirker overvågningssnitfladen
dk.nsi.followupjob.maxtime=120
dk.nsi.notificationcleanupjob.maxtime=120
dk.nsi.replicationjob.maxtime=120
Her angiver man i minutter hvor langt tid de enkelte jobs max må tage at udføre inden overvågningssnitfladen vil begynde at returnerer HTTP 500.
BRS-frontend OK:
BRS-frontend med warning om manglende forbindelse til backend (HTTP 202):
BRS-backend OK:
BRS-backend med fejl pga. MySQL (HTTP 500):
BRS-backend med fejl pga. at behandlingstiden for en opfølgning er for lang. Fejlen opstår når et batch til opfølgning tager for lang tid. Og status viser både hvorhvornår en kørsel er kørt helt færdig (lastSuccessfullAllBatches), og hvornår et batch er blevet kørt færdig (lastSuccessfulRun). Er lastSuccessfullAllBatches blank, betyder det, at der er tale om den første batchkørsel siden start af servicen, og den endnu ikke er afsluttet.
Status-siderne er også i stand til at trække yderligere informationer om køstørrelser osv. fra MySQL. Disse oplysninger inkluderes dog ikke i de normalt responses, da de genererer et vist load på MySQL, men de kan trækkes ved at tilføje en "?detailed"-parameter på URLen til status-siden (fx http://host:port/brs-nsp/status?detailed).
Nedenfor ses eksempler på hvilke oplysninger der inkluderes på hhv. frontend og backend. På frontend ses det at der ligger 5 records der afventer overførsel til backend, samt 1 notification der kan hentes af klienter:
På backend rapporteres det, at followup-jobbet har 5 records der afventer behandling, 85 records der er udsat til senere check, samt en notifikation der kan hentes af klienter:
Data fra eksterne registre vil løbende blive slettet. Der bør derfor foretages backup af indkomne registerdata på en forsvarlig måde, i tilfælde af behovet for en genetablering af data på register_alarm i tilfælde af nedbrud. Disse skal opbevares på en forsvarlig måde da der er tale om personhenførbare data.
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
0.1 | 2011-06-15 | Initielt Dokument | Trifork |
0.2 | 2011-07-27 | Opdatering af dokumentation jf. implementation af generelle notifikationer | Trifork |
0.3 | 2011-08-10 | Opsplitning af dokumentation jf. opsplitning af BRS og GOS | Trifork |
0.4 | 2011-10-05 | Mindre tilretninger jf. Stamdatas replikering af Sikrede data | Trifork |
1.0 | 2012-06-08 | Tilføjet SQL til oprydning på BRS tabeller | Trifork |
1.1 | 2013-10-21 | Opdateret SVN link | Trifork |
2.0 | 2017-03-10 | Diverse opdateringer ifm. BRS2 | Trifork |
2.1 | 2019-07-12 | Indsat status eksempel på behandlingstid for opfølgning er for lang | KvalitetsIT |
2.2 | 2019-08-19 | Indsat beskrivelse af auditlogning via Audit-api | KvalitetsIT |
2.3 | 2019-08-26 | Opdateret status eksempel på behandlingstid for opfølgning er for lang | KvalitetsIT |
2.4 | 2019-11-08 | Tilføjet nye properties til konfiguration ifm. brugen af SORLS i LPR3Relayer | KvalitetsIT |