Page History
...
Læseren forventes at have kendskab til National Sundheds-IT's platform NSP, samt generelt kendskab til WildFly applikation server, MariaDB og java.
Dokumenthistorik
...
Version
...
Dato
...
Ansvarlig
...
Beskrivelse
...
1.3
...
28-10-2017
...
Openminds
...
Beskrivelse af organisation job
...
1.2
...
Openminds
...
Beskrivelse af clean up job
...
1.1
...
26-06-2017
...
Openminds
...
Nærmere specificering af Logning
...
1.0
...
09-06-2017
...
Openminds
Definitioner og forkortelser
Definition | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
...
http://<server>:<port>/minlog2-lookup/monitor http http://<server>:<port>/minlog2-lookupid/monitorhttp://<server>:<port>/minlog1-lookup/monitor |
som svarer HTTP OK tilbage, hvis alt fungerer. Dette kald verificerer services samt databaseadgang.
...
http://<server>:<port>/minlog2-lookup/monitor?details http http://<server>:<port>/minlog2-lookupid/monitor?detailshttp://<server>:<port>/minlog1-lookup/monitor?details |
Denne viser status for eventuelle services og databaseadgange.
...
http://<server>:<port>/minlog2-lookup/version http http://<server>:<port>/minlog2-lookupid/version http://<server>:<port>/minlog1-lookup/version |
Der er intet krav om at versionerne skal "følges" ad – således kan eksempelvis "Registration 2.0.1 godt fungere sammen med Lookup 2.5.1. Det bør tilstræbes at versionerne er det samme.
...
http://<server>:<port>/minlog2-lookup/LookupService?wsdl http http://<server>:<port>/minlog2-lookupid/LookupidService?wsdl |
DKS snitflade
DKS for Lookup- og Lookupidservice på minlog2 findes på følgende url'er.
http://<server>:<port>/minlog2-lookup/dksconfig http://<server>:<port>/minlog2-lookup/20241101/dksconfig http://<server>:<port>/minlog2-lookup/20250312/dksconfig |
http://<server>:<port>/minlog2-lookupid/dksconfig http://<server>:<port>/minlog2-lookupid/20241101/dksconfig http://<server>:<port>/minlog2-lookupid/20250312/dksconfig |
Følgende properties bruges i DKS til opbygning af endpoint.
# DCC Endpoint |
Cleanup snitflade
Det er muligt at starte og se status for cleanup på:
http://<server>:<port>/minlog2-lookup/cleanup/start http://<server>:<port>/minlog1minlog2-lookup/cleanup/LookupService?wsdlstatus |
Funktionalitet
Servicene stiller metoder til rådighed til at fremsøge cpr relaterede hændelser.
...
<jboss>/standalone/deployments/minlog2-ds.xml |
SLA log og øvrige konfigurationer (log og systemspecifikke konfigurationer) findes i:
...
Se i øvrigt installationsvejledningen.
Whitelisting
For at et anvender kan kalde en bestemt lookup-snitflade, skal de whitelistes først. Dette gøres enten på deres CVR-nummer eller via et certifikats SSN som indsættes i whitelist-tabellen.
Eksempler:
| Code Block | ||
|---|---|---|
| ||
INSERT INTO whitelist (operation, identification_type, identification, note) VALUES ('lookup_20241101', 'SSN', 'UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6', 'En note');
INSERT INTO whitelist (operation, identification_type, identification, note) VALUES ('lookupid_20241101', 'CVR', '33257872', 'En note'); |
Operationen der whitelistes på, er altid en bestemt version af en operation. Herunder er de lookup-operationer der pt. kan whitelistes til:
- lookup
- lookup_20241101
- lookup_20250312
- lookupid
- lookupid_20241101
- lookupid_20250312
Der er derudover også behov for at whitelisting til opslag, hvor en borger laver opslag på vegne af en anden borger i rollen som "værge". Til det skal det kaldene certifikat whitelistes til, at man må komme ind som værge af den vej (i praksis kun FMK).
Operationen hedder:
claimWardRelation
Og et eksempel på en whitelistning af denne:
| Code Block | ||
|---|---|---|
| ||
INSERT INTO whitelist (operation, identification_type, identification) VALUES ('claimWardRelation', 'SSN', 'UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6'); |
Ved whitelistning af claimWardRelation, er det kun muligt at angive "identification_type" som "SSN".
Cleanup job
Servicens slettejob, står for at slette logentries i databasen.
Det bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af slettejob i flere-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.
Driften vedligeholder en cron, som kalder slettejobbets url i et fast mønster vha. curl.
Følgende parametre til styring af slettejobbet kan ændres i application.properties for MinLog2:
days.to.remain.persisted=730
cleanupjob.runtime.max=25000
sql.delete.batch.size=10000
sleep.after.batch=2000
Alle rækker som er ældre end days.to.remain.persisted (her 2x365) fra dags dato slettes med en limit på sql.delete.batch.size (her 10000). Efter hvert batch tjekkes den samlede tid for den aktuelle afvikling, og hvis der er gået mere tid end angivet i cleanupjob.runtime.max (her 4 minutter), så afsluttes aktuelle afvikling.
Derved sørger cleanupjob.runtime.max for at begrænse udførselstiden for slettejobbet, for at undgå at ramme HTTP timeout.
Kommando til kald af slettejob:
curl <server>/minlog2-lookup/cleanup/start
Status for seneste cleanup kan ses på:
http://<server>:<port>/minlog2-lookup/cleanup/status
Batch job
Lookup applikationen indeholder følgende batchjob:
...