XDSCleanup-servicen foretager sletning af dokumentmetadata og dokumenter fra NXRG og OpenXDS.
Formålet med dette dokument er at beskrive systemarkitekturen for XDSCleanup.
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af XDSCleanup.
Version | Dato | Ansvarlig | Beskrivelse |
0.1 | 25.02.2022 | KvalitetsIT | Initiel udgave |
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.
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 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.
Sletningen foregår i to trin: Først slettes dokumentmetadata i NXRG, og derefter slettes selve dokumentet i OpenXDS. De to skridt kan i princippet foregå på forskellige tidspunkter. Når dokumentemetadata er slettet i NXRG, bliver dette skrevet til en tabel over slettede metadata, hvorefter sletningen fra OpenXDS foregår med udgangspunkt i tabellen over slettede metadata.
TODO: Beskriv mere detaljeret sammenhængen mellem de to skridt via deleted_documententries-tabellen.
XDSCleanup-servicen konfigureres med et 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.
Alderen for et dokument beregnes ved først at kigge på attributten ServiceStartTime, og hvis denne ikke findes, så i stedet på CreationTime, som er en påkrævet attribut. Hvis dokumentets alder er større end det konfigurerede antal måneder, så slettes dokumentet.
I NXRG slettes data i følgende tabeller:
Der slettes desuden data fra de såkaldte 'content'-tabeller, som indeholder en xml-repræsentation af ovenstående objekter, samt fra et antal tabeller, som indeholder documententry-attributter med multiplicitet >1.
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 dkumenter vil dog blive slettet på et andet tidspunkt, såfremt XDSCleanup-servicen konfigureres til det.
I OpenXDS slettes data i følgende tabeller:
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 slettet datasættet og markere sletningen som udført i og markere det som slettet i deleted
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.
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).
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.
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.
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"
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.
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,