...

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

Anchor
_Toc326916714 _Toc326916714

Anchor
_Toc405782831 _Toc405782831

Anchor
_Toc477260959 _Toc477260959

Formål

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
_Toc326916715 _Toc326916715

Anchor
_Toc477260960 _Toc477260960

Komponenter og funktionalitet

Dette dokument dækker følgende komponenter på NSP og Backoffice:

...

1. Anchor
   docs-internal-guid-796e5297-b24e-4ee0-b5 docs-internal-guid-796e5297-b24e-4ee0-b5

   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).
2. Disse replikeres løbende fra den centrale database til cNSP'ens og dNSP'ernes databaser.
3. 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.
4. BRS servicen checker først om der kan etableres tilstrækkelig evidens for en behandlingsrelation ud fra eksisterende evidens kilder.
5. Hvis ikke, så registreres opslaget i databasen. Recorden ligger kun midlertidigt her, idet databasen fungerer som en kø.
6. ReplicationJob læser periodisk i databasen for at se om der er dukket noget op.
7. Nye entries sendes ind til den centrale komponent i Backoffice.
8. Det checkes om den nye entry allerede er modtaget før (duplicate check), inden den gemmes.
9. BRS FollowupJob finder (og sletter) løbende de entries, hvor det er tid til opfølgning (fx 90 dage efter registrering).
10. 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.
11. Notifikationer til service providers replikeres til databaserne på NSP'erne.
12. 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.
13. Efter en fastsat periode slettes notifikationerne, uagtet om de er hentet af service providerne eller ej.

Anchor
_Toc326916716 _Toc326916716

Anchor
_Toc477260961 _Toc477260961

Daglig drift

BRS kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.

Anchor
_Toc326916720 _Toc326916720

Anchor
_Toc477260962 _Toc477260962

Konfiguration

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.

...

Anchor
_Toc477260963 _Toc477260963

Tilføjelse af CVR-numre og typer

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
_Toc326916721 _Toc326916721

Anchor
_Toc477260964 _Toc477260964

Overvågning

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

Anchor
_Toc326916723 _Toc326916723

Anchor
_Toc477260965 _Toc477260965

Fortolkning af HTML overvågningsside

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.

Anchor
_Toc326916724 _Toc326916724

Anchor
_Toc477260966 _Toc477260966

Overvågningstyper

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.

Anchor
_Toc326916725 _Toc326916725

Anchor
_Toc477260967 _Toc477260967

Logfiler og fortolkning af disse

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.

...

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

Anchor
_Toc477260968 _Toc477260968

Konfiguration af overvågning

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.

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

...

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

• Hvis status-siden giver HTTP 500 bør man checke den tilsvarende brs-frontend/brs-backend.log, som typisk vil indeholde en mere detaljeret fejlmeddelelse end status-siden (stacktrace osv).
• Ved problemer med indlæsning af brs-frontend/brs-backend.properties bør man verificere at filen ligger korrekt i configuration/ biblioteket. Vær opmærksom på at filen ikke læses hvis den ikke er til stede ved opstart af Wildfly.
• Kontroller altid præcist hvilke jobs og services der er nede. Hvis BRS-backend er nede vil det også give sig udslag i warning på BRS-frontend, som i så fald ikke kan sende data videre. I den situation hjælper det ikke at genstarte BRS-frontend. Hvor ofte jobs køres kan konfigureres i property-filerne.
• En service eller et job kan genstartes ved at kalde touch på den tilsvarende war-fil. I yderste konsekvens kan Wildfly genstartes ved at bruge /etc/init.d/wildfly8 restart.

Anchor
_Toc326916727 _Toc326916727

Anchor
_Toc477260971 _Toc477260971

Krav til backup m.m.

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.

Anchor
_Toc263424147 _Toc263424147

Anchor
_Toc326916728 _Toc326916728

Anchor
_Toc477260972 _Toc477260972

Ændringslog

Kilden til dette dokument kan findes på:
{+}https://svn.nspop.dk/svn/trifork/brs/trunk/doc/+

...