Registry Deletion Job (RegJob) foretager en sletning af dokumenter fra et Aftale Registry.
Formålet med dette dokument er at beskrive systemarkitekturen for RegJob.
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i anvendelsen af RegJob.
Version | Dato | Ansvarlig | Beskrivelse |
0.8 | 09.01.201 | KvalitetsIT | Initiel udgave |
Programmet giver mulighed for sletning af dokumenter fra et XDS Repository - dokumenter som opfylder der kriterie at de er 2 år gamle, og har en given type (i dette tilfælde aftaler).
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
I dette afsnit fastholdes væsentlige design beslutninger samt deres rationale. Hvis relevant, fastholdes også designs, som er afvist samt rationalet herfor.
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 RegJob - 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,