Versions Compared

Old Version 62

changes.mady.by.user Rasmus H. Thygesen

Saved on

compared with

New Version Current

changes.mady.by.user Thomas Klemmensen

Saved on

Key

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

...

  • NSP: BRS Frontend
    • Statusurl: <serverurl>/brs-nsp/status
    • Filnavn: brs-frontend-<version>.war
    • Behandlingsrelationsservice
      • Type: Webservice
      • Url:
        • <serverurl>/brs-nsp/service/brs
        • <serverurl>/brs-nsp/service/20250301/brs
      • DKS-config:
        • <serverurl>/brs-nsp/service/brs/dksconfig
        • <serverurl>/brs-nsp/service/20250301/brs/dksconfig
      • Funktionalitet: benyttes af klienter til kontrol af behandlingsrelationer
    • Notifikationsservice
      • Type: Webservice
      • Url:
        • <serverurl>/brs-nsp/service/notification
        • <serverurl>/brs-nsp/service/notification20210921
      • DKS-config:
        • <serverurl>/brs-nsp/service/notification/dksconfig
        • <serverurl>/brs-nsp/service/notification20210921/dksconfig
      • Funtionalitet: Benyttes af klienter til at hente notifikationer
    • ReplicationJob (tidligere kendt som "GOS")
      • Type: Batchjob
      • Funktionalitet: overfører opfølgninger til backend

...

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.
Bruges mysqldb kræves det at databasen eksisterer inden services startes.

hsqldb

dk.nsi.auth.whitelistservice.type

Hvilken whitelistservice bruges der. Kan enten være "property" eller "database"
Bruges property vil følgende properties blive benyttet "dk.nsi.auth.brs.cvr.list", "dk.nsi.auth.create.type.cvr.list" og "dk.nsi.auth.query.type.cvr.list" disse properties beskrives nedenfor. Er værdien "database" skal data indsættes i whitelist:config tabellen som beskrevet i næste afsnit.

property

dk.nsi.auth.create.type.cvr.list

Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property"
Her angives en kommasepareret liste af cvr numre som har lov til at oprette nye opfølgninger. Hver indgang i listen består af <CVR>:<Opfølgningstype>, hvor opfølgningstype kan være "BRS" for behandlingsrelationer og "CPRSUBSCRIPTION" for opfølgninger på CPR numre
Eksempler kan være følgende:
55832218:BRS,12345678:CPRSUBSCRIPTION

<tom>

dk.nsi.auth.query.type.type.cvr.list

Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property"
Her angives en kommasepareret liste af cvr numre som har lov til at kalde notifikationsservicen, og hente notifikationer på opfølgninger for det pågældende CVR nummer og opfølgningstype. Hver indgang i listen består af <CVR>:<Opfølgningstype> som beskrevet for "dk.nsi.auth.create.type.cvr.list"
Eksempler kan ligeledes være følgende:
55832218:BRS,12345678:CPRSUBSCRIPTION

<tom>

dk.nsi.auth.brs.cvr.list

Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property"
Her angives en kommasepareret liste af cvr numre som har lov til at kalde behandlingsrelationsservicen. Hver indgang i listen består af et CVR nummer, eksempler kan ligeledes være følgende:
12345678,87654321


dk.nsi.db.{navn}.url

Database URL - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
jdbc:mysql://cnsp-db01/


dk.nsi.db.{navn}.driverclass

Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
com.mysql.jdbc.Driver


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.
Eksempel: 10 0/5 * * * *

olderThanDays

Fjern alarmer som er ældre end denne værdi.

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.
Værdien defineres i dage og sammenlignes med en relations sluttid hvor imellem der bør være en opdatering fra AssignedDoctor. Hvis ikke, gives en E-relation, ellers en D-relation

10

dk.nsi.relation.refhost.update.frequency

Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge.
Værdien defineres i dage og sammenlignes med en relations sluttid hvor imellem der bør være en opdatering fra REFHOST. Hvis ikke, gives en E-relation, ellers en D-relation

2

dk.nsi.relation.ssr.update.frequency

Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge.
Værdien defineres i dage og sammenlignes med en relations sluttid hvor imellem der bør være en opdatering fra SSR. Hvis ikke, gives en E-relation, ellers en D-relation

62

dk.nsi.app.nameAngiver navnet på applikationen. Bruges til at oprette SlaLogInput, som bruges til SLA logninger i facaden mod SORES.Behandlingsrelationsservice
dk.nsi.app.shortNameAngiver 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.connectionsMaksimalt samtidigt antal kald til SORES200
dk.nsi.brs.sor.default.max.connections.per.routeMaksimalt samtidigt antal kald til samme SORES-operation.20
kafkadk.topicnsi.dkdcc.nsiendpoint.brsnotificationNavn på Angiver det topicendpoint, som opfølgningsbestillinger skal sendes til og hentes fra.followup-topic
kafka.consumer.client.idId der anvendes af Kafka consumere i løsningen.brs-backend-consumer
kafka.producer.client.idId der anvendes af Kafka producere i løsningen.brs-backend-producer / brs-frontend-producer
kafka.consumer.group.idGroup-id der anvendes af Kafka consumere i løsningen.BRS_GROUP_ID
kafka.producer.bootstrap.serversUrl til Kafka bootstrap-server.kafka:9092
kafka.consumer.enable.auto.commitOm der skal anvendes auto-commit i kafka-consumere.false
kafka.consumer.auto.offset.resetOffset der resettes til, f.eks. hvis en consumer ikke har committed sit offset.earliest
kafka.consumer.max.poll.recordsMaksimalt 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
DCC'en skal kalde. Dette kommer til at fremgå af den XML, der returneres i /dksconfig
dk.nsi.dcc.endpoint.notification20210921Angiver det endpoint, som DCC'en skal kalde. Dette kommer til at fremgå af den XML, der returneres i /dksconfig
dk.nsi.dcc.endpoint.brsAngiver det endpoint, som DCC'en skal kalde. Dette kommer til at fremgå af den XML, der returneres i /dksconfig
dk.nsi.dcc.endpoint.brs20250301Angiver det endpoint, som DCC'en skal kalde. Dette kommer til at fremgå af den XML, der returneres i /dksconfig
kafka.topic.dk.nsi.brsNavn på det topic, som opfølgningsbestillinger skal sendes til og hentes fra.followup-topic
kafka.consumer.client.idId der anvendes af Kafka consumere i løsningen.brs-backend-consumer
kafka.producer.client.idId der anvendes af Kafka producere i løsningen.brs-backend-producer / brs-frontend-producer
kafka.consumer.group.idGroup-id der anvendes af Kafka consumere i løsningen.BRS_GROUP_ID
kafka.producer.bootstrap.serversUrl til Kafka bootstrap-server.kafka:9092
kafka.consumer.enable.auto.commitOm der skal anvendes auto-commit i kafka-consumere.false
kafka.consumer.auto.offset.resetOffset der resettes til, f.eks. hvis en consumer ikke har committed sit offset.earliest
kafka.consumer.max.poll.recordsMaksimalt 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.bytesMaksimalt antal bytes kafka.consumer.max.partition.fetch.bytesMaksimalt 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.bytesMaksimalt 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.timeoutMaksimale antal millisekunder Kafka consumeren skal foretage poll inden den timer ud.1000
kafka.consumer.max.wait.millisMaksimale antal millisekunder Kafka consumeren venter hvis der kommer flere kald ind end der er Followup objekter i pool'en.1000
kafka.consumer.max.pool.sizeMaksimale antal Followup objekter i pool'en.20
kafka.consumer.max.recordsMaksimale antal beskeder Kafka consumeren kan processere ad gangen.50
kafka.consumer.max.processing.timeDen maksimale tid Kafka consumeren må bruge på at behandle beskeder fra consumeren. Angives som en "Duration".PT10000S
dk.nsi.followupjob.processingIterationsAntal iterationer som follow up jobbet skal køre før det stopper.50
dk.nsi.notificationcleanupjob.delay Køre jobbet med et fast interval i millisekunder
300000
dk.nsi.followupjob.delay Køre jobbet med et fast interval i millisekunder1000


Følgende databaser kan refereres via {navnFø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.

...

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.

...

brs-

...

audit.log

brs-backend.

...

Audit logninger af flyt fra Followup til Notifikationer, hvilket sker når der ikke er fundet en behandlingsrelation inden en given tidsperiode.
Logninger sker på samme måde, som almindelige applikationslogninger og bruger derfor ikke Audit-api.


Ved en fejl på en overvågningsside skrives der til den relevante brs-frontend/brs-backend.log. Alle logs indekseres med Splunk.

Logning af Evidens tjek

Det forventes at driften opsamler alle logninger fra dk.

...

Logning af Evidens tjek

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.

...

Code Block
languagejs
collapsetrue
{
	"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
		}
	}
}": {
			"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
		}
	}
}


Audit logning - Fra Followup til Notikationer

Auditlogning foretages igennem intern klasse, dk.nsi.brs.audit.BrsAuditLogger, hvis logninger bliver skrevet i filen brs-audit.log.

Dette er konfigureret i filen:  /compose/configuration/backend/brs-backend-log4j.xml

Følgende oplysninger logges fra BrsAudtLogger:

KontekstNøgleInformation
AlarmactualRelationsAktuelle forbindelser
FollowupquerableCvrCVR nummer der skal have adgang til en eventuel efterfølgende notifikation. 
FollowuptimeLimitUdløbstidspunkt for opfølgningen efter hvilket der skal oprettes en notifikation, hvis de angivne kriterier ikke er opfyldt
FollowupacceptableRelationsEn liste af acceptable relationer
TreatmentRelationRelayerDatadoctorOrganisationIdentifierOrganisationen inden for hvilken relationen skal findes
TreatmentRelationRelayerDatahospitalOrganisationIdentifierOrganisationen inden for hvilken relationen skal findes
TreatmentRelationRelayerDataeanOrganisationen inden for hvilken relationen skal findes
TreatmentRelationRelayerDatasorIdentifierOrganisationen inden for hvilken relationen skal findes
TreatmentRelationRelayerDatarelationLookupStartStarttidspunkt for hvilket behandleren har foretaget opslaget.
TreatmentRelationRelayerDatarelationLookupEndSluttidspunkt for hvilket behandleren har foretaget opslaget.

Eksempel på auditlogningen:

Code Block
languageshell
timestamp="2025-10-29 08:44:46,001" threadId="pool-14-thread-1" priority="INFO" category="dk.nsi.brs.audit.BrsAuditLogger" message="{"organisation":{"doctorOrganisationIdentifier":null,"hospitalOrganisationIdentifier":null,"ean":null,"sorIdentifier":11000011},"querableCvr":"33257872","timeLimit":"2016-01-01T00:00:00+01:00","acceptableRelations":["C"],"actualRelations":["E"],"relationLookupStart":"2010-01-01T00:00:00+01:00","relationLookupEnd":"2015-01-01T00:00:00+01:00"}"
timestamp="2025-10-29 08:45:15,379" threadId="pool-14-thread-1" priority="INFO" category="dk.nsi.brs.audit.BrsAuditLogger" message="{"organisation":{"doctorOrganisationIdentifier":null,"hospitalOrganisationIdentifier":"123456","ean":null,"sorIdentifier":null},"querableCvr":"33257872","timeLimit":"2016-01-01T00:00:00+01:00","acceptableRelations":["C"],"actualRelations":["D"],"relationLookupStart":"2025-01-01T00:00:00+01:00","relationLookupEnd":"2026-01-01T00:00:00+01:00"}"
timestamp="2025-10-29 08:45:45,966" threadId="pool-14-thread-1" priority="INFO" category="dk.nsi.brs.audit.BrsAuditLogger" message="{"organisation":{"doctorOrganisationIdentifier":null,"hospitalOrganisationIdentifier":null,"ean":null,"sorIdentifier":12345678},"querableCvr":"33257872","timeLimit":"2016-01-01T00:00:00+01:00","acceptableRelations":["C"],"actualRelations":["E"],"relationLookupStart":"2025-01-01T00:00:00+01:00","relationLookupEnd":"2026-01-01T00:00:00+01:00"}"


Anchor
_Toc477260968
_Toc477260968
Konfiguration af overvågning

...

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}
Eksempel kan ligeledes være følgende:
jdbc:mysql://cnsp-db01/


dk.nsi.db.treatment_relation_followup.driverclass

Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
com.mysql.jdbc.Driver


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.


...