Page History
Navitabs | ||||
---|---|---|---|---|
| ||||
Anchor | ||||
---|---|---|---|---|
|
Driftsvejledning
Version 2.0, 2017-03-10
Anchor | ||||
---|---|---|---|---|
|
...
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.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Dette dokument dækker følgende komponenter på NSP og Backoffice:
- NSP: BRS Frontend
- Statusurl: <serverurl>/brs-nsp/status
- Filnavn: brs-frontend-<version>.war
- Behandlingsrelationsservice
- Type: Webservice
- Url: <serverurl>/brs-nsp/service/brs
- Funktionalitet: benyttes af klienter til kontrol af behandlingsrelationer
- Notifikationsservice
- Type: Webservice
- Url: <serverurl>/brs-nsp/service/notification
- Funtionalitet: Benyttes af klienter til at hente notifikationer
- ReplicationJob (tidligere kendt som "GOS")
- Type: Batchjob
- Funktionalitet: overfører opfølgninger til backend
...
Komponenterne og deres funktionalitet ses vist i nedenstående diagram:
SDM4 stamdata importers. Der er i dag 4 registre som importeres og danner evidens-grundlag for visse behandlingsrelationer (henvisningshotellet/Refhost, Landspatientregisteret/LPR, ydelsesregisteret og sikrede registeret).Anchor docs-internal-guid-796e5297-b24e-4ee0-b5 docs-internal-guid-796e5297-b24e-4ee0-b5 - Disse replikeres løbende fra den centrale database til cNSP'ens og dNSP'ernes databaser.
- Service providers (fx FMK og Sundhed.dk) kalder BRS for at registrere en adgang til data. Der angives hvilken person fra hvilken organisation, der har tilgået (eller skal til at tilgå) hvilken patient. Samtidig angives om, og i givet fald hvornår i fremtiden der ønskes opfølgning.
- BRS servicen checker først om der kan etableres tilstrækkelig evidens for en behandlingsrelation ud fra eksisterende evidens kilder.
- Hvis ikke, så registreres opslaget i databasen. Recorden ligger kun midlertidigt her, idet databasen fungerer som en kø.
- ReplicationJob læser periodisk i databasen for at se om der er dukket noget op.
- Nye entries sendes ind til den centrale komponent i Backoffice.
- Det checkes om den nye entry allerede er modtaget før (duplicate check), inden den gemmes.
- BRS FollowupJob finder (og sletter) løbende de entries, hvor det er tid til opfølgning (fx 90 dage efter registrering).
- BRS FollowupJob checker for hver entry om der fra evidens-kilderne kan findes en behandlingsrelation, og i givet fald med hvilken styrke. Hvis der ikke kan findes en tilstrækkelig god evidens på en behandlingsrelation, så registreres en notifikation til service provideren.
- Notifikationer til service providers replikeres til databaserne på NSP'erne.
- Service provider (fx FMK) kalder notifikations-servicen for at hente de genererede notifikationer. Ud fra disse kan den data-ansvarlige for service providerne (fx FMK eller Sundhed.dk) følge op på, om opslagene alligevel var berettigede, fx stikprøvevis.
- Efter en fastsat periode slettes notifikationerne, uagtet om de er hentet af service providerne eller ej.
...
BRS kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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. | 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. | 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 |
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 |
Anchor | ||||
---|---|---|---|---|
|
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.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
...
BRS-overvågningssider returnerer enten:
- HTTP 200 hvis de i øjeblikket kører fint
- HTTP 202 hvis BRS-frontend ikke kan få forbindelse til BRS-backend
- HTTP 500 hvis der er opstået en fejl der kræver indgriben
...
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. |
Ved en fejl på en overvågningsside skrives der til den relevante brs-frontend/brs-backend.log. Alle logs indekseres med Splunk.
...
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:
...
Kilden til dette dokument kan findes på:
{+}https://svn.nspop.dk/svn/trifork/brs/trunk/doc/+
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 |