...

Design- og arkitekturbeskrivelse - Migrering

!! Dette afsnit er ikke længere aktuelt men bevares for historikkens skyld. Kildekode, som har med migrering at gøre, er taget ud af NXRG projektet i revision r10379 !!

Migrering af data fra OpenText Registry til NXRG skal sikre, at al data, der ligger i OpenText Registry overføres til NXRG på en måde, så data bevares: Det vil sige, at de data, der kan udsøges gennem NXRGs snitflader svarer 1:1 til det data, der kan udsøges gennem OpenText Registrys snitflader.

...

Da driften kan trække liste over nye/opdaterede data i OpenText Registry (se pkt 1 ovenfor) er det muligt at lave en trinvis migrering. Dette betyder yderligere, at det bliver muligt at komme i gang med migreringen på et tidligere tidspunkt (da det kan foretages uden at der skal meldes servicevinduer ud).

...

Desuden opdateres til tabellen migration_properties under migreringskørslen. Formålet med dette er at holde styr på, hvor langt man er nået med id'erne for association og documententry, sådan at man kan fortsætte herfra ved næste kørsel.

Contents

Status

migration_properties

XML-format

OpenText registry'et eksporterer sine data i et xml-format, som der ind til videre ikke er tilvejebragt noget schema for. Nedenfor kan man se et eksempel på et submissionset og et tilhørende document i dette format.

...

De følgende metrikker foreslås. Det skal afklares, om det kan lade sig gøre at trække disse ud af både xDB og NXRG.

Der er et issue omkring, hvornår valideringen kører, hvis der tikker ny data ind i xDB. Vi antager, at vi kan køre migrering-validering/verifikation-cyklen, uden at det eksisterende OpenText slettejob fjerner data fra xDB (det skal være slået fra). I udtrækket fra xDB er der styr på en skæringsdato, som kan anvendes til at begrænse tælle-queries mod xDB opadtil, hvorfor resultaterne mellem NXRG og xDB ventes at være ens - både efter første migrering og efterfølgende efter deltaerne.

...

Der sammenlignes følgende metrikker for hver kørsel (dvs for hvert cpr nummer)

De to første variable er for at se, at der kommer data retur i det hele taget. Da de øvrige værdier er sammenligniner, som gerne skulle være 0. Men 0 minus 0 er også 0, så det viser ikke om der er dokumenter i svaret.

...

Da OpenText Registry er closed source er det ikke muligt ved kodeinspektion at danne sig et overblik over, hvilke valideringer, der findes i OpenText Registry. Vi har forsøgt at køre Tookit Tests op i mod test1 for enkelte test cases, for at give en ide om, hvorledes denne svarer (se NXRG/SDS Patientindex - Testvejledning).

For en endelig anvendelse af dette forslag, skal prod og test1 open text konfigureres ens (hvis ikke allerede) og samtlige eller udvalgte test køres.

...

Andre env, der kan sættes:

1) Antal records der hermed håndteres er således migration_batchsize x migration_no_of_batches

Driftsvejledning - Migreringsverifikationstool

Som beskrevet i NXRG/SDS Patientindex - Design- og arkitekturbeskrivelse kan der efter en migrering foretages hhv

...

Env, der kan sættes i forbindelse med validering:

Env, der kan sættes i forbindelse med verifikation:

Driftsvejledning - Replaytool

Som beskrevet i NXRG/SDS Patientindex - Design- og arkitekturbeskrivelse kan der inden idriftsættelse køres en række "anvender integrationstest", som er replay af en række "gamle" open text request. Efter kørsel kan response sammenlignes med det svar som i sin tid blev givet af open text.

...

Env, der kan sættes i forbindelse med replay:

Output i result.csv:

Filen kan med fordel åbnes i et regneark, og funktioner som autofilter og pivot tabeller anvendes til vurdering af dens indhold.

...

Env, der skal sættes i forbindelse med kørsel: