Page History
...
| Table of Contents | ||
|---|---|---|
|
Introduktion
Formål
Registry Deletion Job (RegJob) foretager en XDSCleanup-servicen foretager sletning af dokumentmetadata og dokumenter fra et Aftale Registry. NXRG og OpenXDS.
Formålet med dette dokument er at beskrive systemarkitekturen for RegJobXDSCleanup.
Læsevejledning
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af RegJobXDSCleanup.
Dokumenthistorik
Version | Dato | Ansvarlig | Beskrivelse |
0. |
1 |
25. |
02. |
2022 | KvalitetsIT | Initiel udgave | |
0.2 | 10.10.2022 | KvalitetsIT | SDS-5785 |
Introduktion til
...
XDSCleanup
Overblik over løsningen
...
XDSCleanup-servicen giver mulighed for
...
at slette dokumentmetadata fra NXRG-registry'et, og efterfølgende slette de tilsvarende dokumenter i Opentext-repository'et. Servicens sammenhæng med andre relevante komponenter er vist i nedenstående diagram.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Diagrammet viser to databaser: Metadata, som er den database der vedligeholdes og ejes af NXRG, og Dokumenter, som er den database der vedligeholdes og ejes af OpenXDS. Som det fremgår af diagrammet, fungerer XDSCleanup ved at læse/skrive direkte i disse databaser, og altså ikke gennem ITI-snitfladerne.
XDSCleanup sletter også dokumenter baseret på afdøde personer. Derfor indgår SDM databasen også i løsningen. Der læses alene fra denne database.
Løsningsdesign
XDSCleanup er implementeret på NSP-platformen, og udstiller et antal servlets som kaldes af driften. Detaljer om disse snitflader findes i driftsvejledningen. Meningen er at oprydningssnitfladen kaldes med jævne mellemrum, hvilket vil udvælge et antal dokumenter til sletning, og derefter slette dem.
Der skrives til applikationsloggen, hvad der bliver slettet. Det er dokumenteret i større detalje i driftsvejledningen hvad der logges.
Asynkronitet
Implementationen følger husreglerne for baggrundsjobs og er sikker overfor samtidige kald.
Løsningen for alle oprydningsjobs er en in-memory stak, hvorpå der løbende bliver påfyldt operationer. Operationer bliver altid lagt på stakken i tilfældig rækkefølge.
Følgende afsnit beskriver hvordan stakken af operationer opbygges i hver af de tre oprydningsjobs.
registry-timebased-cleanup
Der benyttes tre typer af operationer.
| Operation | Beskrivelse |
|---|---|
| Default operation | Benyttes til at fylde nye operationer på stakken, når stakken er tom. For hver konfigureret dokumenttype, oprettes en typebasered operation for denne type |
| Typebaseret operation | Givet en dokumenttype og tilhørende konfiguration, hentes id'er på alle matchende dokumenter i NXRG databasen Opretter en mængde batch oprydningsjobs, hver med et konfigurerbart antal af disse dokument id'er. |
| Batch oprydningsjob | Givet en liste af dokument id'er, slet dokumenterne fra NXRG |
registry-status90-cleanup
Der benyttes fire typer af operationer.
| Operation | Beskrivelse |
|---|---|
| Default operation | Benyttes til at fylde operationer på stakken, når stakken er tom. For hvert af tallene 00-99, oprettes en prefix baseret operation |
| Prefix baseret operation | Givet et tal mellem 00 og 99, hentes alle borger id'er fra NXRG, som starter med disse cifre. Opretter en mængde borger id baseret operationer, hver med et konfigurerbart antal af disse borger id'er |
| Borger id baseret operation | Givet en liste af borger id'er, tages de id'er der tilhører afdøde (status 90) borgere. Henter id'er på dokumenter i NXRG databasen for disse borger id'er. Opretter en mængde batch oprydningsjobs, hver med et konfigurerbart antal af disse dokument id'er. |
| Batch oprydningsjob | Givet en liste af dokument id'er, slet dokumenterne fra NXRG |
repository-cleanup
Der benyttes to typer af operationer.
| Operation | Beskrivelse |
|---|---|
| Default operation | Benyttes til at fylde operationer på stakken, når stakken er tom. Henter id'er på alle slettede dokumenter fra NXRG, som endnu ikke er slettet i OpenXDS Opretter en mængde batch oprydningsjobs, hver med et konfigurerbart antal af disse dokument id'er. |
| Batch oprydningsjob | Givet en liste af dokument id'er, slet dokumenterne fra OpenXDS |
deprecated-document-entries
Der benyttes to typer af operationer.
| Operation | Beskrivelse |
|---|---|
| Default operation | Benyttes til at fylde operationer på stakken, når stakken er tom. For hver konfigureret type kode, oprettes for alle dage i et år oprettes en prefix baseret operation. Der oprettes (med 2 konfigurerede typekoder) 2*12x31 prefix baserede operationer og prefixet har formen "DDMM". Dvs. for 7. november har den værdien "0711". |
| Prefix baseret operation | Henter deprecated document entries ud der er mere end x dage gamle og opretter en mængde batch oprydningsjobs, med et konfigurerbart antal af disse. Hver prefix baseret operation indeholder kun patientId'er hvor de første 4 tal er identisk med det prefix operationen er oprettet med. Operationen respekterer den medsendte typekode. De x antal dage er en konfigurerbar parameter. Opretter en mængde borger id baseret operationer, hver med et konfigurerbart antal af disse borger id'er. |
| Batch oprydningsjob | Givet en liste af dokument id'er, slet dokumenterne fra NXRG |
dangling-submissionsets
Der benyttes to typer af operationer.
| Operation | Beskrivelse |
|---|---|
| Default operation | Benyttes til at fylde nye operationer på stakken, når stakken er tom. For alle kombinationer af 3 karakters string med tegnene 0-9 og a-f oprettes en prefix baseret operation. Dette giver totalt 4096 kombinationer. |
| Prefix baseret operation | Henter submissionsets ud, der ikke er knyttet til en association, og der oprettes en mængde batch oprydningsjobs, med et konfigurerbart antal af disse. Hver prefix baseret operation indholder kun entryuuid'er hvor de prefix er "urn:uuid" + de 3 karakterer prefix operationen er oprettet med. |
| Batch oprydningsjob | Givet en liste af submissionsets id'er, slet submissionsets fra NXRG |
Afkobling af sletning i registry og repository
Sletning i registry og repository foregår i seperate servlets, som kan køres uafhængigt af hinanden.
Sletning af dokumentmetadata i NXRG vil dog altid ske før sletning af dokumenterne i OpenXDS.
Når dokumentmetadata er slettet i NXRG, bliver dette skrevet til tabellen deleted_documententries, som udgør en log over slettede metadata. Sletningen fra OpenXDS foregår med udgangspunkt i tabellen deleted_documententries. Denne tabel vedligeholdes af NXRG, men tabellens indhold er for overblikkets skyld gengivet nedenfor.
Tabellen indeholder følgende attributter:
| Attributnavn | Datatype | Indhold |
|---|---|---|
| id | int(11) | Primary key. |
| entryuuid | varchar(64) | EntryUuid på slettet DocumentEntry. |
| uniqueid | varchar(64) | UniqueId på slettet DocumentEntry |
| deletion_status | varchar(64) | Status på sletningen. Kan være DELETED_FROM_REGISTRY eller DELETION_FROM_REPOSITORY_FAILED. |
| deletion_attempts | int(11) | Antal gange hvor sletning fra repository er gået galt. |
| creation_time | datetime(6) | Tidspunkt for indsættelse af rækken. |
Hver række i tabellen svarer til et slettet DocumentEntry. Ved indsættelse af en række bliver deletion_status sat til DELETED_FROM_REGISTRY, hvilket indikerer at dokumentet er slettet fra registry'et, men endnu ikke fra repository'et.
En kørsel af repository slettejobbet vil hente alle rækker ud af tabellen og forsøge at slette en delmængde af disse fra OpenXDS. Hvis sletningen går godt, slettes rækkerne fra tabellen, og sletningen af disse dokumenter er færdig. Hvis sletningen mislykkes, sættes deletion_status til DELETION_FROM_REPOSITORY_FAILED, og deletion_attempts tælles én op.
deletion_attempts kolonnen vedligeholdes for at skabe overblik, og benyttes udelukkende af health endpointet.
Konfiguration af sletninger
XDSCleanup-servicen konfigureres med et antal oprydningskriterier , som beskriver hvilke dokumenter der skal slettes hvornår. Et oprydningskriterium består af en dokumenttype og en dokumentalder i måneder. Ved kørsel bliver der for hver specifikation udvalgt et antal dokumenter, som har den angivne type, og er ældre end den maksimale alder. Herefter slettes disse dokumenter.
Det er muligt at konfigurere sletning af dokumenter hørende til personer med status 90 (=døde). I opsætningen kan man angive hvor lang tid dokumenterne for disse personer skal gemmes.
Herudover er det muligt at konfigurere antallet af sletninger der skal foretages ved hver kørsel.
Beregning af dokumentalder
Alderen for et dokument beregnes ved først at kigge på attributten deletetrigger_time som er et felt, der vedligeholdes i databasen og er en funktion: COALESCE(servicestarttime, creation_time). CreationTime er en påkrævet attribut, men det er serviceStartTime ikke. Hvis dokumentets alder er større end det konfigurerede antal måneder, så slettes dokumentet.
Data der slettes i NXRG og OpenXDS
I NXRG slettes data i følgende tabeller:
- documententries - her slettes de indgange, der er udvalgt ud fra dokumenttype og alder samt for afdøde personer.
- associations - her slettes de indgange, der refererer til et DocumentEntry der skal slettes.
- submissionsets - her slettes de submissionsets, der ville have været tomme efter sletning fra documententries.
Der slettes desuden data fra de såkaldte 'content'-tabeller, som indeholder en xml-repræsentation af ovenstående objekter, samt fra tabellerne documententry_author, documententry_confidentialtycode, documententry_eventcode og documententry_referenceid.
NB: Der slettes pt. ikke documententries, som er relateret til de slettede documententries gennem associations-tabellen. Med relateret objekt menes f.eks. et dokument, som er en tilføjelse til et andet dokument (gennem en APPEND-association), et dokument som er en erstatning for et andet dokument (gennem en REPLACE-association), osv. Disse dokumenter vil dog blive slettet på et andet tidspunkt, såfremt XDSCleanup-servicen konfigureres til det.
I OpenXDS slettes data i følgende tabeller:
- repository - her slettes dokumenter med uniqueid, der matcher et slettet documententry i NXRG.
Fejlhåndtering
Som tidligere beskrevet bliver slettede metadata vedligeholdt i en særlig tabel, deleted_documententries. Sletning af metadata fungerer ved først at udvælge et datasæt til sletning (dokumenter, associations og submissionsets), og derefter slette datasættet og markere sletningen som udført i deleted_documententries-tabellen. Sletningen og slettemarkeringen udføres i en transaktion, således at der er konsistens i hvad der er slettet, og hvad der er markeret som slettet.
Sletning fra OpenXDS foregår ved at hente et batch af slettede dokumentmetadata fra deleted_documententries-tabellen, slette dem fra openxds, og derefter slette rækkerne fra deleted_documententries-tabellen. Bemærk at der her indgår to databaser, så det er ikke tilstrækkeligt at udføre hele operationen i en transaktion. Hvis sletningen i repository'et mislykkes, så markeres sletningen som fejlet.
Programmet er et java-program, som køres fra kommando-linjen (hvor det læser konfiguration ind fra en property-fil) og outputter de dokument-ID´er der er blevet slettet i en eller flere filer, på en sådan måde at disse filer kan anvendes som output for Repository Deletion Job.
Fremsøgningen af hvilke dokumenter der skal slettes foretages med et XQuery på XDB (da der ikke findes ITI-snitflader der understøtter den ønskede søgning) hvorimod selve sletningen foretages vha. snitfladen ITI-62, for at sørge for at data forbliver konsistente
Designbeslutninger
I dette afsnit fastholdes væsentlige design beslutninger samt deres rationale. Hvis relevant, fastholdes også designs, som er afvist samt rationalet herfor.
Anvendelse af XDB Query til fremsøgning af dokumenter der skal slettes
For at finde de dokumenter der skal slettes, anvendes et håndskrevent XDB Query, som ikke vil kunne anvendes til et vilkårligt XDS Registry, men er skræddersyet OpenText´s XDB database. Dette er fordi der ikke findes ITI-snitflader til søgning på tværs af hele databasen. Performance af et sådan XDB Query er ikke særligt hurtigt, men det er muligt at angive at Query kun læser fra databasen, for at undgå problematikker med låsning.
Anvendelse af ITI-62 snitflade til sletning af dokumenter
Der anvendes snitfladen ITI-62 RemoveObjectsRequest til at slette dokumenter, for at efterlade data i en konsistent tilstand. Denne snitflade sørger for at validere at alle referencer slettes korrekt. Dette betyder også, at vi forud for at slette et dokument (DocumentEntry) skal foretage et ITI-18 GetAssociationsQuery for at hente id´er på alle "Association" og "SubmissionSet" objekter tilknyttet et dokument, da man også skal angive at disse skal slettes. Der bliver oprettet "SubmissionSet" og "Association" (af typen "HasEntry", "Replaces" og "UpdateAvailabilityStatus") objekter når aftaler oprettes, opdateres, og slettes (deprecates).
Opdeling af sletning i "Registry Deletion Job" og "Repository Deletion Job" frem for et enkelt job
Et registry kan indeholde dokumenter fra flere repositories, hvoraf nogle af dem ikke nødvendigvis benytter en XDB Database (Koden i "Repository Deletion Job" er meget XDB-specifik), så derfor er jobbet delt op i disse to separate jobs.
Håndtering af opdaterede aftaler
I situationen hvor en aftale (herefter kaldet ORIGINAL) opdateres, bliver der lavet en ny aftale (herefter kaldet REPLACEMENT), og ORIGINAL bliver deprecated, og der bliver dannet en REPLACE association mellem REPLACEMENT og ORIGINAL. REPLACEMENT og ORIGINAL kan have forskellige serviceStartTime, hvilket vil sige at der kan være situationer hvor kun een bliver slettet af Registry Deletion Job. Alle de forskellige kombinationer er testet (se XDSCleanupXDSCleanup - Testvejledning ) og vi mener RegJob opfører sig korrekt og efterlader aftalen i en gyldig, korrekt tilstand.
Afgørelse af hvornår en aftale er for gammel
For at afgøre hvorvidt en aftale er for gammel (og derved skal udtages til sletning) kigges på attributen "serviceStartTime". Denne er dog ikke en obligatorisk attribute, så i de tilfælde hvor denne ikke findes, kigges der i stedet på "creationTime"
Øvrige designbeslutninger
Statisk konfiguration i property-fil
Hvilken XDS og XDB man kører op imod forventes at være statisk, denne fil skal placeres et fast sted relativt til hvor jobbet køres fra.
Beslutning vedr. javaprogram
Programmet skulle både kunne foretage et query i en XDB og foretage ITI-kald, der findes java-biblioteket til begge disse formål, som vi har erfaring med at bruge, derfor virkede der oplagt at lave det som et javaprogram,