Versions Compared

Key

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

...

Al konfiguration på hhv. NSP og Backoffice foregår ved redigering i hhv. brs-frontend.properties og brs-backend.properties, 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.
Bruges mysqldb kræves det at databasen eksisterer inden services startes.

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"
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.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.
Eksempel: 15/30 * * * * *


dk.nsi.replicationjob.wsdlurl

Bruges af ReplicationJob til at replikere opfølgninger til backendens replication service.
Dette er URL'en til WSDLen, f.eks:
https://<host:port>/brs-backend/service/replication?wsdl


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


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.

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


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


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

...

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.

brs-frontend-audit.log

brs-frontend.war, audit-logning af requests

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.

...

Anchor
__RefHeading___Toc1113_4855908941
__RefHeading___Toc1113_4855908941
Anchor
_Toc477260969
_Toc477260969
Eksempler på status-sider


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):

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:

Anchor
_Toc326916726
_Toc326916726
Anchor
_Toc477260970
_Toc477260970
Standard fejlsøgning

...