Page History

...

Definitioner og forkortelser

...

DKS snitflade

DKS for Lookup- og Lookupidservice på minlog2 findes på følgende url'er.

Følgende properties bruges i DKS til opbygning af endpoint.

# DCC Endpoint
minlog2.endpoint.lookupid=http://test1-cnsp.ekstern-test.nspop.dk:8080/minlog2-lookupid
minlog2.endpoint.lookup=http://test1-cnsp.ekstern-test.nspop.dk:8080/minlog2-lookup

Cleanup snitflade

Det er muligt at starte og se status for cleanup på:

...

SLA log og øvrige konfigurationer (log og systemspecifikke konfigurationer) findes i:

...

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 whitelistingwhitelist-tabellen.

Eksempler:

INSERT INTO whitelistingwhitelist (operation, identification_type, identification, note) VALUES ('lookup_20241101', 'SSN', 'UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6', 'En note');
INSERT INTO whitelistingwhitelist (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:

INSERT INTO whitelistingwhitelist (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:

...