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-mappet, så de er tilgængelige på docker-hosten.
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.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.followupjob.enabled | Angiver om jobbet er enablet. Er obligatorisk | |
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.followup.processing.cooldown.duration | Periode der skal gå fra en followup-besked er blevet behandlet, til den kan behandles igen (hvis den er blevet sat til udførsel i fremtiden). Angives som en "Duration". | PT0S |
dk.nsi.followup.processing.increment.duration | Perioden cooldown forøges med når der ikke har været processeret nogen followup-beskeder. Angives som en "Duration". | PT0S |
dk.nsi.followup.processing.max.duration | Den maksimale perioden cooldown må have. Angives som en "Duration". | PT0S |
dk.nsi.followup.processing.consumer.pool.size | Antal consumere der er tigængelige til behandling af followup-beskeder. | 20 |
dk.nsi.followup.processing.thread.pool.size | Størrelsen på den thread pool som en consumer har til behandling af followup-beskeder. | 20 |
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 SORES. | 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 SORES. | 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 |
dk.nsi.brs.sor.max.total.connections | Maksimalt samtidigt antal kald til SORES | 200 |
dk.nsi.brs.sor.default.max.connections.per.route | Maksimalt samtidigt antal kald til samme SORES-operation. | 20 |
kafka.topic.dk.nsi.brs | Navn på det topic, som opfølgningsbestillinger skal sendes til og hentes fra. | followup-topic |
kafka.consumer.client.id | Id der anvendes af Kafka consumere i løsningen. | brs-backend-consumer |
kafka.producer.client.id | Id der anvendes af Kafka producere i løsningen. | brs-backend-producer / brs-frontend-producer |
kafka.consumer.group.id | Group-id der anvendes af Kafka consumere i løsningen. | BRS_GROUP_ID |
kafka.producer.bootstrap.servers | Url til Kafka bootstrap-server. | kafka:9092 |
kafka.consumer.enable.auto.commit | Om der skal anvendes auto-commit i kafka-consumere. | false |
kafka.consumer.auto.offset.reset | Offset der resettes til, f.eks. hvis en consumer ikke har committed sit offset. | earliest |
kafka.consumer.max.poll.records | Maksimalt antal beskeder en consumer kan hente fra Kafka ad gangen. Indstillingerne max.poll.records, max.partition.fetch.bytes og fetch.max.bytes bør justeres i sammenhæng. | 500 |
kafka.consumer.max.partition.fetch.bytes | Maksimalt antal bytes per partition, som en consumer kan hente fra Kafka ad gangen. Indstillingerne max.poll.records, max.partition.fetch.bytes og fetch.max.bytes bør justeres i sammenhæng. | 1048576 |
kafka.consumer.fetch.max.bytes | Maksimalt antal bytes en consumer kan hente fra Kafka ad gangen. Indstillingerne max.poll.records, max.partition.fetch.bytes og fetch.max.bytes bør justeres i sammenhæng. | 52428800 |
kafka.consumer.poll.timeout | Maksimale antal millisekunder Kafka consumeren skal foretage poll inden den timer ud. | 1000 |
kafka.consumer.max.wait.millis | Maksimale antal millisekunder Kafka consumeren venter hvis der kommer flere kald ind end der er Followup objekter i pool'en. | 1000 |
kafka.consumer.max.pool.size | Maksimale antal Followup objekter i pool'en. | 20 |
kafka.consumer.max.records | Maksimale antal beskeder Kafka consumeren kan processere ad gangen. | 50 |
kafka.consumer.max.processing.time | Den maksimale tid Kafka consumeren må bruge på at behandle beskeder fra consumeren. Angives som en "Duration". | PT10000S |
Følgende databaser kan refereres via {navn} ovenfor:
Miljø | Navn | Beskrivelse |
---|---|---|
BRS-Frontend | stamdata | AssignedDoctor-stamdata |
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 | |
Kafka-migration | treatment_releation_followup | Data der modtages fra frontends, og skal migreres til Kafka. |
Servicens job til behandling af opfølgningsbestillinger bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af jobbet i fler-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.
Driften vedligeholder en cron, som kalder jobbets url i et fast mønster vha. curl.
Indstillinger relateret til behandling af opfølgningsbestillinger er beskrevet i tabellen ovenfor.
Kommando til kald af slettejob:
curl <server>/brs-backend/followup
Kaldet vil returnere 200 OK hvis alt går godt, ellers 500 Internal Server Error.
Servicens job til oprydning bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af jobbet i fler-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.
Driften vedligeholder en cron, som kalder jobbets url i et fast mønster vha. curl.
Kommando til kald af oprydningsjob:
curl <server>/brs-backend/notificationcleanupjob
Kaldet vil returnere 200 OK hvis alt går godt, ellers 500 Internal Server Error.
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.
I forbindelse med udskiftning af et anvendercertifikat kan det være nødvendigt at duplikere data for et CVR-nummer, som beskrevet i anvenderguiden, afsnit 2.5. Hvis der er behov for dette, køres nedenstående SQL-script.
Inden scriptet køres, justeres variablerne old_cvr og new_cvr.
set @old_cvr = '46837428'; set @new_cvr = '12345678'; use followup; begin; -- Duplicate from BRS2_TreatmentRelationFollowup insert into BRS2_TreatmentRelationFollowup ( nextCheck, queryableCvr, externalReferenceId, uid, doctorOrganisation, hospitalOrganisation, ean, patientCpr, healthProfessionalCpr, relationLookupStart, relationLookupEnd, timeLimit, acceptableRelations, followupRelations, authorisationIdentifier, serviceProviderName, serviceProviderVersion, serviceProviderVendor, created, sor ) select nextCheck, @new_cvr, -- the new cvr externalReferenceId, uuid(), -- new uid doctorOrganisation, hospitalOrganisation, ean, patientCpr, healthProfessionalCpr, relationLookupStart, relationLookupEnd, timeLimit, acceptableRelations, followupRelations, authorisationIdentifier, serviceProviderName, serviceProviderVersion, serviceProviderVendor, created, sor from BRS2_TreatmentRelationFollowup where queryableCvr = @old_cvr; -- Duplicate from BRS2_Followup -- We need a relation between old and new serial numbers later on, when duplicating into the BRS2_Notification table, as that table refers into BRS2_Followup through the followupSerialNumber-column. -- We achieve this by creating a temp table of the followups that need to be duplicated, and generate fresh uid's there. The contents of the temp table are then inserted into BRS2_Followup. This allows us to relate serial numbers through the chain <old serial> <-> <old uid> <-> <new uid> <-> <new serial>. -- Create the temp table create temporary table BRS2_Followup_tmp select * from BRS2_Followup where queryableCvr = @old_cvr; alter table BRS2_Followup_tmp add column newUid varchar(36); update BRS2_Followup_tmp set newUid = uuid(); -- Insert into into BRS2_Followup (from the temp table) insert into BRS2_Followup ( queryableCvr, externalReferenceId, uid, -- The uid we just generated. doctorOrganisation, hospitalOrganisation, ean, patientCpr, healthProfessionalCpr, relationLookupStart, relationLookupEnd, timeLimit, acceptableRelations, followupRelations, authorisationIdentifier, serviceProviderName, serviceProviderVersion, serviceProviderVendor, created, errorCount, nextSync, sor ) select @new_cvr, -- the new cvr externalReferenceId, newUid, -- The new uid we just generated doctorOrganisation, hospitalOrganisation, ean, patientCpr, healthProfessionalCpr, relationLookupStart, relationLookupEnd, timeLimit, acceptableRelations, followupRelations, authorisationIdentifier, serviceProviderName, serviceProviderVersion, serviceProviderVendor, created, errorCount, nextSync, sor from BRS2_Followup_tmp; commit; use register_notifications; begin; -- Duplicate from BRS2_TreatmentRelationFollowup insert into BRS2_Notification ( externalReferenceId, queryableCvr, creationTimestamp, doctorOrganisation, hospitalOrganisation, ean, patientCpr, healthProfessionalCpr, relationLookupStart, relationLookupEnd, timeLimit, acceptableRelations, actualRelations, followupSerialNumber, followupRelations, authorisationIdentifier, serviceProviderName, serviceProviderVersion, serviceProviderVendor, uid, sor ) select n.externalReferenceId, @new_cvr, n.creationTimestamp, n.doctorOrganisation, n.hospitalOrganisation, n.ean, n.patientCpr, n.healthProfessionalCpr, n.relationLookupStart, n.relationLookupEnd, n.timeLimit, n.acceptableRelations, n.actualRelations, coalesce(f.pk, n.followupSerialNumber), n.followupRelations, n.authorisationIdentifier, n.serviceProviderName, n.serviceProviderVersion, n.serviceProviderVendor, uuid(), n.sor from BRS2_Notification n left join followup.BRS2_Followup_tmp ft on n.followupSerialNumber = ft.pk inner join followup.BRS2_Followup f on ft.newUid = f.uid where n.queryableCvr = @old_cvr; commit; |
Der anvendes security-api til validering af SAML ID-kort. Hvis miljøvariablen NSP_TEST_FEDERATION
er sat til true
, vil ID kort blive valideret mod test-føderationen, ellers mod prod-føderationen.
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 hhv. brs-backend-log4j.xml og brs-frontend-log4j.xml, og er volume-mappet ind, så de er tilgængelige på docker--hosten. 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. Diverse logninger af komponentens opførsel, inklusiv fejllogninger og audit-logninger 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. 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.
Det forventes at driften opsamler alle logninger fra dk.nsi.brs.common.audit.EvidenceLogger, da den udtømmende liste af logninger er forholdsvis stor. Den vil på sigt også kunne justeres, så der kommer ændrede logninger.
I forbindelse med at LPR3 gør brug af SORES, 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 hver af typerne LPR, LPR3, SIKREDE, REFHOST og SSR.
For alle rækker i en Evidens log findes værdierne:
1800 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Start, Type=LPR3 1820 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, Type=LPR3, Key=Opslagsdata, Data=CheckedRelationRelayerData[doctorOrganisationIdentifier:<null>,hospitalOrganisationIdentifier:730011,ean:<null>,sorIdentifier:<null>,patientCpr:65663455A743AC4B1E2A2E5F40F01183C6C4824E,healthProfessionalCpr:<null>,relationLookupTimeInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000] 1820 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Execute, Type=LPR3, Action=Executing with SHAK, Active=yes 1820 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Execute, Type=LPR3, Action=Executing with SOR, Active=no 1821 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, Type=LPR3, Collect identifier=D1, From=SorServiceDao.getShakSorMap, Into=SOR(sundhedsprof), ShakIdentifier=730011 1821 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, Type=LPR3, Collect identifier=D1, From=SorServiceDao.getShakSorMap, Into=SOR(sundhedsprof, sygehus), ShakIdentifier=730011 1821 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Collect, Type=LPR3, Collect identifier=D2, From=SorServiceDao.searchAllChildren, Into=SOR(sundhedsprof), SOR(sundhedsprof)=[439061000016001] 1821 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, Type=LPR3, Key=SOR(sundhedsprof), Data=[439061000016001] 1821 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, Type=LPR3, Key=SOR(sundhedsprof, sygehus), Data=[] 1827 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Input, Type=LPR3, Key=LPR3 data, Data=[LPR3[patientCpr:65663455A743AC4B1E2A2E5F40F01183C6C4824E,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111111,relationType:FORLOEBSELEMENT,sorIdentifier:439061000016001]] 1827 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, 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 1827 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, Type=LPR3, Check identifier=C2, Question=Er der overlap mellem dato-interval for LPR3 registreringer og input tidsintervallet?, Answer=yes 1828 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Suggest, Type=LPR3, Suggestion=A, Current=E 1828 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Check, Type=LPR3, Check identifier=C3, Question=Hvilken type har de matchende LPR3 registreringer?, Answer=forløbslement, kontakt, procedure, intitiel henvisning eller henvisning 1828 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Execute, Type=LPR3, Action=Executing Tjek SOR(sundhedsprof, sygehus), Active=no 1828 [main] INFO dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog - msg=Stop, Type=LPR3, Classification Result=A |
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.
I release 2.1.0 er BRS ændret, så Kafka anvendes til at vedligeholde køen af bestilte opfølgninger. Anvendelsen af Kafka erstatter den tidligere followup-database. I den forbindelse er der brug for at behandle de bestillinger der allerede ligger i followup-databasen, og sætte dem i kø i Kafka. Til dette formål er der udviklet en kommandolinjeapplikation, kafka-migration, som leveres som et docker-image (navn: registry.nspop.dk/components/brs/kafka-migration). Applikationen forbinder til followup-databasen og kafka-serveren, og fungerer som følger:
Applikationen udfører ovenstående procedure, ind til BRS2_TreatmentRelationFollowup-tabellen er tom. I tilfælde af fejl standser applikationen.
Applikationen konfigureres i filerne kafka-migration.properties og log4j.properties. Disse filer volume-mountes på stien /config. Nedenfor dokumenteres indholdet af kafka-migration.properties. Indholdet af filen log4j.properties er standard og forventes ikke at skulle ændres, og en gennemgang af indholdet er derfor udeladt.
Property | Beskrivelse | Default |
---|---|---|
dk.nsi.db.treatment_relation_followup.url | Database URL - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.treatment_relation_followup.driverclass | Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.treatment_relation_followup.user | Database brugernavn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.treatment_relation_followup.pwd | Database adgangskode - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.db.treatment_relation_followup.database | Database navn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} | |
dk.nsi.brs.kafka.topic | Kafka-topic som bestillinger skal publiceres til | |
kafka.producer.client.id | Client-id på den kafka-producer, der ikøsætter bestillinger. | |
kafka.producer.bootstrap.servers | Url til Kafka bootstrap-server. |
I development-setuppet (compose/development/docker-compose.yml) findes et eksempel på, hvordan applikationen sættes op.