Page History
Table of Contents
Introduktion
Indholdet i dette dokument stammer fra det oprindelige NXRG Design- og arkitekturbeskrivelse samt Driftvejledning, og vedrører migrerings delen af NXRG. Fra da data skulle flyttes fra openText til NXRG databasen.
Dette er gemt for historikken skyld. I det oprindelige dokumenter, er der en reference heri.
Kildekode, som har med migrering at gøre, er taget ud af NXRG projektet i revision r10379.
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.
Den interne datarepræsentation vil ændre sig fra OpenText Registry til NXRG, men det logiske data skal bevares.
Valg af migreringsstrategi
Der har i forbindelsen med migreringen været arbejdet med nedenstående diagram for at komme frem til en migreringsstrategi.
Diagrammet viser de forskellige niveauer, som data kan eksporteres henholdsvis importeres på. De forskellige muligheder er blevet diskuteret på workshops, og fravalg og tilvalg er dokumenteret på diagrammet.
Konklusionen på analysearbejdet er således, at:
- Data eksporteres fra OpenText Registry på xDB niveau: Driften kan trække en liste over alle objekter i xDB og hvornår disse senest er ændret. Listen kan anvendes til at lave eksport af de (ændrede) objekter til en relationel database (MariaDB).
- Data importeres i NXRG fra kommandolinje tool: Importen af data skal operere på den relationelle migreringsdatabase, som blev nævnt under eksport. Ved at køre et kommandolinje tool er det muligt at transformere data i migreringsdatabasen til SQL scripts under hensyntagen til NXRGs datamodel. Disse scripts kan derefter (bulk) indlæses i NXRGs database (også MariaDB)
Der har været et ønske om at kunne lave løbende (delta)migreringer af OpenText data til NXRG. Dette ønske bunder i, at der i produktion i dag er ca 11 mio XDS objekter (submissionsets med associations samt document entries) i OpenText Registry databasen.
Selv med et effektitivt migreringstool, så vil det tage tid (< 5 dage) at migrere al data. Hvis en migreringsstrategi kræver et servicevindue, så vil dokumentdeling på NSP være utilgængeligt i flere dage, hvilket er blevet vurderet til problematisk.
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).
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Migreringsprocessen er markeret med blå i diagrammet ovenfor. Det er tanken at bevare Migreringsdatabasen efterfølgende som en backup for OpenText Registry data. Når licensen udløber for xDB databasen, så vil migreringsdatabasen være masterdata (i tilfælde af, at man skulle opdage fejl i import til NXRG efterfølgende).
Der skal laves verifikation af migreringsprocessen - både en kvantitativ verifikation og en kvalitativ verifikation. Denne del af processen er beskrevet nedenfor.
Tabelformat for migreringsdata
Dataene fra OpenText registry'et i en MariaDB-database, som deles mellem eksport- og import-jobbet. Databasen indeholder to tabeller, contents og status. Tabellernes indhold beskrives nedenfor. Man kan hente et eksempel-datasæt på
Jira | ||||||
---|---|---|---|---|---|---|
|
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
Feltnavn | Datatype | Indhold |
---|---|---|
PID | bigint(20) | Unik nøgle. |
RowModified | timestamp | Angivelse af, hvornår rækken sidst er opdateret. |
DocID | varchar(255) | Id på dokument. |
content | mediumblob | XML-repræsentation af dokumentet (kan være enten submissionset eller document). |
Status
Feltnavn | Datatype | Indhold |
---|---|---|
PID | bigint(20) | Unik nøgle. |
RowModified | timestamp | Angivelse af, hvornår rækkken sidst er opdateret. |
DocID | varchar(255) | Id på dokument. Refererer til DocID-kolonnen i contents-tabellen. |
DocDate | timestamp | Angivelse af, hvornår dokumentet er oprettet. |
DocExportState | int(11) | Status-felt, der bruges til at angive om et dokument er blevet eksporteret eller ej. Kan antage følgende værdier: 0 (NotReady), 1 (Ready), 2 (Migrating), 100 (Migrated). |
DocImportState | int(11) | Status-felt, der bruges til at angive om et dokument er blevet importeret eller ej. Kan antage følgende værdier: 0 (NotReady), 1 (Ready), 2 (Migrating), 100 (Migrated). |
migration_properties
Feltnavn | Datatype | Indhold |
---|---|---|
Id | int(11) | Unik nøgle. |
finish_time | datetime | Angivelse af, hvornår migreringskørslen afsluttede |
current_association_id | int(11) | Angivelse af, hvor langt man nåede i række af id på associations i NXRG databasen |
current_documententry_id | int(11) | Angiver hvor langt man nåede i række af id på documententry i NXRG databasen |
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.
Code Block |
---|
<?xml version="1.0"?>
<submissionSet id="urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045">
<xds:submissionSet xmlns:xds="http://www.openehealth.org/ipf/xds">
<entryUuid>urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045</entryUuid>
<logicalUuid>urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045</logicalUuid>
<version>
<versionName>1</versionName>
</version>
<uniqueId>7020798514690154282.7024117544796833076.1568187071790</uniqueId>
<patientId extension="2606481234" root="1.2.208.176.1.2"/>
<availabilityStatus>Approved</availabilityStatus>
<title language="en-US">769a1dbf-2c73-4cca-98b9-9c045231f309</title>
<limitedMetadata>false</limitedMetadata>
<sourceId>7020798514690154282.7024117544796833076.1568187071790</sourceId>
<submissionTime>2013-02-17T08:15:00Z</submissionTime>
<author>
<authorPerson>
<id/>
<name>
<given>M</given>
<family>Madsen</family>
</name>
</authorPerson>
<authorInstitution>
<idNumber>77668685</idNumber>
<assigningAuthority universalId="1.2.208.176.1.2" universalIdType="ISO"/>
<name>Odense Universitetshospital, Odense</name>
</authorInstitution>
</author>
<contentTypeCode code="NscContentType" codeSystemName="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" displayName="NscContentType"/>
</xds:submissionSet>
<xds:associations xmlns:xds="http://www.openehealth.org/ipf/xds">
<xds:association>
<entryUuid>urn:uuid:1b1d1134-c1d9-4a88-add6-3d580aadfed7</entryUuid>
<sourceUuid>urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045</sourceUuid>
<targetUuid>urn:uuid:5e6ac9ef-4633-46ea-96b1-786a948e7bb6</targetUuid>
<associationType>HasMember</associationType>
<label>Original</label>
<originalStatus>Approved</originalStatus>
<newStatus>Approved</newStatus>
<availabilityStatus>Approved</availabilityStatus>
</xds:association>
</xds:associations>
</submissionSet> |
Code Block |
---|
<?xml version="1.0"?>
<document id="urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906">
<xds:documentEntry xmlns:xds="http://www.openehealth.org/ipf/xds">
<entryUuid>urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906</entryUuid>
<logicalUuid>urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906</logicalUuid>
<version>
<versionName>1</versionName>
</version>
<uniqueId>437f8b60-9563-11e3-a5e2-0800200c7020^1.2.208.184</uniqueId>
<patientId extension="2606481234" root="1.2.208.176.1.2"/>
<availabilityStatus>Approved</availabilityStatus>
<title language="en-US">Hjemmemonitorering for 2606481234</title>
<limitedMetadata>false</limitedMetadata>
<sourcePatientId extension="2606481234" root="1.2.208.176.1.2"/>
<sourcePatientInfo>
<name>
<given>Janus</given>
<family>Berggren</family>
</name>
<gender>M</gender>
<birthTime>1948-06-26T00:00:00Z</birthTime>
</sourcePatientInfo>
<creationTime>2013-02-17T08:15:00Z</creationTime>
<author>
<authorPerson>
<id/>
<name>
<given>M</given>
<family>Madsen</family>
</name>
</authorPerson>
<authorInstitution>
<idNumber>77668685</idNumber>
<assigningAuthority universalId="1.2.208.176.1.2" universalIdType="ISO"/>
<name>Odense Universitetshospital, Odense</name>
</authorInstitution>
</author>
<legalAuthenticator>
<id/>
<name>
<given>Lars</given>
<family>Olsen</family>
</name>
</legalAuthenticator>
<serviceStartTime>2013-02-11T08:11:00Z</serviceStartTime>
<serviceStopTime>2013-02-16T10:14:00Z</serviceStopTime>
<classCode code="001" codeSystemName="1.2.208.184.100.9" displayName="Clinical report"/>
<confidentialityCode code="N" codeSystemName="2.16.840.1.113883.5.25" displayName="N"/>
<eventCode code="NPU03011" codeSystemName="1.2.208.176.2.1" displayName="O2 sat.;Hb(aB)"/>
<eventCode code="MCS88016" codeSystemName="1.2.208.184.100.8" displayName="FVC"/>
<formatCode code="urn:ad:dk:medcom:appointmentsummary:full" codeSystemName="1.2.208.184.100.10" displayName="DK Appointment Summary Document schema"/>
<healthcareFacilityTypeCode code="550621000005101" codeSystemName="2.16.840.1.113883.6.96" displayName="hjemmesygepleje"/>
<languageCode>da-DK</languageCode>
<practiceSettingCode code="419192003" codeSystemName="2.16.840.1.113883.6.96" displayName="intern medicin"/>
<typeCode code="53576-5" codeSystemName="2.16.840.1.113883.6.1" displayName="Personal Health Monitoring Report"/>
<repositoryUniqueId>1.2.208.176.43210.8.10.11</repositoryUniqueId>
<mimeType>text/xml</mimeType>
<size>27302</size>
<hash>da39a3ee5e6b4b0d3255bfef95601890afd80709</hash>
<type>stable</type>
</xds:documentEntry>
</document>
|
Overordnet struktur
Migreringen består af to faser:
- Overførsel af data fra opentext-databasen til SQL scripts.
- Indlæsning af SQL scripts i nxrg-databasen.
Denne stuktur er valgt af følgende grunde:
- Mulighed for at få den endelige indlæsning til at køre hurtigt.
- Mulighed for håndtering af deltaer: Hvis f.eks. et allerede konverteret DocumentEntry bliver deprecated, så skal migreringen kunne håndtere dette.
Fase 1 er implementeret som en java kommandolinje-applikation. Fase 2 består af indlæsning af genererede scripts i navngivne rækkefølge.
Findinds i løbet af migreringsprocessen
uniqueIds er ikke unikke på SubmissionSets fra opentext-databasen
Det er blevet fundet, at der optræder dubletter i uniqueid på submissionsets i data trukket ud fra test1 (se detaljer på
Jira | ||||||
---|---|---|---|---|---|---|
|
- Tillader migrering af ikke unikke unique-ids for submissionsets
- Fortsat kræver at submissionsets modtaget gennem ITI-42, ITI-57 og ITI-62 har et unikt unique id.
Det er ikke helt klart, om de sammenfaldende id'er er en egenskab, som udelukkende begrænser sig til testsystemet. Følgende SQL kan fremfinde de række, hvor der er problemer med ikke-unikke uniqueids:
Code Block | ||||
---|---|---|---|---|
| ||||
select * from submissionsets where migration_uniqueid_fix > 0; |
Hvis problemet ikke eksisterer i produktion, så kan kolonnen 'migration_uniqueid_fix' fjernes efterfølgende (de testdata på testsystemerne, der giver problemer kan så enten slettes eller id'et kan opdateres til noget andet).
Fase 1
Migreringen fra OpenText til SQL script foregår ved at behandle hver række i status-tabellen i opentext-databasen, og gøre følgende:
- Validere at xml-strukturen ser ud som forventet.
- Parse xml-strukturen, og mappe den til objekter i Openehealth core-modellen.
- Serialisere objekterne og gemme dem som SQL scripts
Fejl logges til senere analyse. Efter endt behandling skrives til DocImportState-feltet i opentext-databasen, om behandlingen lykkedes eller ej. Der skrives ligeledes til migration_properties.
Fase 2
Indlæsning af SQL script i NXRG databasen, gøres vha "source <file>".
Eventuelle fejl vil blive sendt til konsollen og kan læses heri.
Verifikation/validering af migreringen
I forbindelse med migreringen vil det give mening at definere et sæt af validerings- og verifikationsmekanismer, som vil kunne øge tilliden til, at migreringen er forløbet korrekt. I de kommende afsnit beskrives de validerings- og verifikationsmekanismer, som anvendes i NXRG migreringen.
Det er tanken, at verifikation kan køres både efter initiel load og efterfølgende efter hver deltamigrering, så vi får løbende overblik overblik over korrektheden.
Valideringen for NXRG samt verifikation kører fra en docker container. Se Driftvejledning for detaljer om faktisk kørsel og output format.
Validering
Efter migreringen er tilendebragt kan der trækkes en række metrikker ud af hhv xDB og NXRGs mariadb baserede databasesetup.
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.
Nr | Beskrivelse af validering | NXRG | xDB |
---|---|---|---|
1 | Antal documententries i alt | OK | |
2 | Antal documententries fordelt på type (stable/on-demand) | OK | |
3 | Antal documententries fordelt på status | OK | |
4 | Antal documententries fordelt på typecode | OK | |
4.5 | Antal documententries fordelt på version | OK | |
5 | Antal forskellige patient-id'er for documententries (id, OID/idtype) | OK | |
5.1 | Trække lister ud af patient-id'er for documententries | OK | |
5.2 | Antal documententries, som ikke har en association | OK | |
6 | Antal submissionsets i alt | OK | |
7 | Antal forskellige patient-id'er for submissionsets | OK | |
7.1 | Trække lister ud af patient-id'er for submissionset | OK | |
7.2 | Antal submissionsets, som ikke har en association | OK | |
8 | Antal associations i alt | OK | |
9 | Antal forskellige patient-id'er for associations | OK | |
9.1 | Trække lister ud af patient-id'er for associations | OK | |
9.2 | Antal associations som ikke har documentEntries, submissionsets eller folders | OK | NA |
9.3 | Antal associations som peger på forskellige patient-id'er i source og target | OK | |
9.3 | Antal associations som peger på folders eller associations | OK | |
99 | Antal anvendte patientid assigningauthorityid og assigningauthoritytype | OK | |
100 | Udtræk af top-100 cpr numre for documententries (dem med flest), tælle docentries også | OK |
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.
Vi forventer at antallene i 7, 9 og 5 er ens.
Yderligere burde summen over tallene i hhv 2, 3, 4, 4.5 summerere til 1.
9.2 forventes af være 0, tjekkes for at sikre ugyldige associations 9.3 forventesl igeledes at være 0. 99 forventes at være en.
Verifikation
Udover valideringskontrollerne beskrevet ovenfor giver det mening, at det undersøges, om NXRG svarer "det samme" som OpenText registry givet at de mødes af de samme input (søgninger).
Det foreslås derfor, at der foretages en ITI-18 søgning (søger på alle documententries på en række af cprnumre). Der kan tages udgangspunkt i det, der allerede er udviklet i NXRG i forbindelse med integrationstesten.
Verifikationstoolet laver den samme forespørgsel mod NXRG hhv OpenText Registry og sammenligner derefter svaret på følgende måde:
- Antallet af documententries og disses id'er skal være ens, hvis den samme query udføres mod NXRG og OpenText Registry
- De enkelte documententries i de to responses skal være ens (men der er ikke krav til, at de kommer ud i samme rækkefølge).
Der kan opstå et issue som i validering i forhold til nye data, der tikker ind. Så verifikationen skal indeholde nok detaljer i diff'en, så vi efterfølgende kan udersøge om diff'en er resultat af nye data.
Der sammenlignes følgende metrikker for hver kørsel (dvs for hvert cpr nummer)
Beskrivelse af verifikation |
---|
Antal document entries i NXRG |
Antal document entries i OpenText |
Forskel i antal mellem NXRG og OpenText for document entries |
Forskel i antal mellem NXRG og OpenText for dokumenter |
Forskel i antal mellem NXRG og OpenText for associationer |
Forskel i antalmellem NXRG og OpenText for foldere |
Forskel i antal mellem NXRG og OpenText ror submissionsets |
Forskel i antal mellem NXRG og OpenText for referencer |
Forskel i antal mellem NXRG og OpenText for fejl |
Forskel mellem NXRG og OpenText for status |
For document entries: hver document entry konverteres til en XML streng og sammenlignes, hvis forskellig skrives entryuuid til en liste |
For document entries: findes et entryuuid kun i NXRG skrives det til en liste |
For document entries: findes et entryuudi kun i OpenText skrives det til en liste |
Alle kald og svar logges |
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.
Ved sammenligning af document entries i ovenstående anvendes entryuuid som nøgle.
Design- og arkitekturbeskrivelse - Idriftsættelse af NXRG
I forbindelse med risikovurderingen af NXRG er blandt andet identificeret følgende to overordnede risici i forhold til idriftsættelsen af NXRG:
- Fejl i migrering af data fra xDB til NXRG database
- Ændringer i snitflader dvs forskelle i de konkrete implemenationer af ITI-XX services i hhv OpenText og NXRG
I forhold til punkt 1, så har vi i projektet tidligere identificeret dette, og skitseret mitigeringsforslag (se afsnit om Migrering ovenfor).
Punkt 2 handler om, at NXRG skal kunne svare sammenligneligt [med OpenText Registry] på requests fra anvenderne (via samarbejdende NSP services) efter idriftsættelsen. Dette betyder, at et request, der rammer NXRG skal give nogenlunde samme response, som hvis det havde ramt OpenText Registry.
Snitfladerne er velbeskrevne i specifikationerne, og der anvendes samme versioner (Netic må kunne se dette???) af openehealth library i NXRG, som der anvendes i OpenText. Som beskrevet i afsnittet om Validering ovenfor, så er det muligt både på OpenText og på NXRG at disable/enable validering af requests og responses for de enkelte ITI-XX services. Dog vil der sikkert være andre forretningsregler i OpenText, som ikke kan overstyres på denne måde. F.eks. kan vi konstatere, at det ikke er muligt at foretage en ITI-18 søgning uden at angive patientid, mens det er muligt at søge uden at angive statuskode, hvis validering af requests er disablet.
Indtil videre har vi identificeret følgende forslag til mitigeringstrategier i forhold til risikoen for utilsigtede snitfladeændringer i forbindelse med idriftsættelsen af NXRG:
- Overblik over forskelle ved afvikling af XDS Toolkit mod OpenText Registry
- Parallel drift (i produktion) af NXRG og OpenText registry
- Afvikling af "anvender integrationstest"
- Hurtig udrulning af NXRG på test1
De forskellige strategier kan implementeres uafhængigt og i supplemenet til hinanden. De enkelte punkter gennemgås nedenfor.
Overblik over forskelle på NXRG og OpenText Registry gennem afvikling af IHE Toolkit tests
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 - 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.
Parallel drift
I dette forslag går vi efter hurtigt at sætte NXRG i drift. Idriftsættelsen skal ske efter initiel (+ evt delta) migrering af data (dvs. midt november).
Når migreringen er tilendebragt, så burde datagrundlaget for NXRG og OpenText Registry være ens. De to registries burde derfor kunne svare nogenlunde sammenligneligt i efterfølgende requests.
Der udvikles derfor en "xds-registry-duplexer", der er i stand til at sende alle indkommende requests til det "nationale registry" til begge bagvedliggende registries.
Duplexeren venter på at begge registries (OpenText og NXRG) svarer og laver en "sammenligning" af svarene (som minimum om det er gået godt eller ej).
Forskelle i svarene logges og det ene svar (det giver mening at anvende OpenText Registry i en periode) sendes tilbage til den kaldende part.
Fordele: Længere vindue, hvor forskelle kan indentifieres (i prod) og rettes op uden at genere anvendene
Ulemper: Kompleks løsning, der kræver både udvikling (KIT/Arosii?) og idriftsættelse (Netic) af duplexeren samt opfølgning på, hvordan det så går. Fare for at introducere problemer i drift med duplexeren (svartider/fejl/opsætning)
Anvendertests
I stedet for "live" at sende requests til både OpenText og NXRG som foreslået i forgående afsnit, kan requests og responses opsamles ved processering af OpenText i produktion og afspilles mod en NXRG efterfølgende.
Igen kan svar sammenlignes (det skal defineres, hvad sammenligningen går ud på).
Fordele: Griber ikke ind i nuværende drift, simplere løsning at implementere (dog skal de defineres, hvordan "anvender tests" skal afvikles: Skal det være en anonymiseret udgave, som KIT skal køre som en del af udviklingen eller skal det være et "testtool", som kan afvikles af Arosii/Netic mod en NXRG i produktion (evt. efter migrering)?
Ulemper: Hvornår er udsnittet af tests "godt nok"? Muligvis en masse opgaver (manuelle?), opfølgning og koordinering.
Hurtig udrulning af NXRG på Test1
I dette forslag håber vi, at de requests, der rammer OpenText registry i NSP miljøet Test1 er sammenlignelige med dem, der senere rammer produktion.
Ved at rulle NXRG på test1 og lade anvenderne gå i gang med at bruge det nye registry, så bliver forskelle måske opdaget hurtigere.
Fordele: Kan bare lægges på. Ikke så farligt, da det "bare" er test.
Ulemper: Hvordan identificerer vi problemer og følger op? Hvad gør anvenderne, hvis det ikke virker? Måske rammes test1 også i dag af en masse skrald, som vi ikke skal kunne håndtere?
Driftsvejledning - Migreringstool
Migreringstoolet læser opentext data fra en Mariadb og producerer opdateringsscripts til indlæsning i NXRG databasen.
Migreringstoolet leveres som et Docker image og containeren kan startes som følger
Code Block |
---|
docker run --env migrationpath=/migrationoutput/ --volume /mymachine/output/run1:/migrationoutput registry.nspop.dk/components/nxrg-migration:snapshot |
Migreringstoolet output'er SQL scripts. Outputsti til scripts kan sættes med en env variabel som vist ovenfor og volume mount til hostmaskinen som vist ovenfor.
Andre env, der kan sættes:
ENV | Beskrivelse | Eksempel | Bemærkninger |
---|---|---|---|
opentext_data_url | URL til databasen med opentext data | jdbc:mysql://localhost:3307/opentext | |
opentext_data_user | Bruger til opentext databasen | opentext | |
opentext_data_pass | Password for bruger | opentext | |
migrationfilesize | Antal inserts statements per migreringsfil | 100000 | Migrering filen prefixes med løbenummer per fil: Eksempel: 11_submissionset_20211020_150541_002.sql |
migration_batchsize | Antal records fra Open Text databasen der læses ad gangen *1 | 1000 | |
migration_no_of_batches | Antal batches der skal håndteres i een kørsel, default er 0 som betyder alle batches *1 | 1000 | Migrering filen prefixes med tidsstempel per kørsel: Eksempel: 11_submissionset_20211020_150541_002.sql Alle filer i samme kørsel vil have samme tidsstempel. Tidstemplet kan ses i log data. |
1) Antal records der hermed håndteres er således migration_batchsize x migration_no_of_batches
Driftsvejledning - Migreringsverifikationstool
Som beskrevet i NXRG - Design- og arkitekturbeskrivelse kan der efter en migrering foretages hhv
- validering
- verifikation
Disse to processer er implementeret som en del af NXRG og kan afvikles med følgende kommando
Code Block |
---|
docker run --env filepath=/migrationvalidation/ --volume /mymachine/migrationvalidation/run1:/migrationvalidation registry.nspop.dk/components/nxrg-migration-verification:snapshot validation
docker run --env filepath=/migrationverification/ --volume /mymachine/migrationverification/run1:/migrationverification registry.nspop.dk/components/nxrg-migration-verification:snapshot verification |
validation - lave sql'er mod NXRG database:
- output'er lister med CPR numre i angivet sti
- cprAssociations.txt
- cprDocumententries.txt
- cprSubmissionset.txt
- cprTop100.txt
- output'er resultater til std out samt en fil i den angivet sti
- result.txt
verification - laver ITI-18 kald mod NXRG og Open Text registry:
- indlæser liste med CPR numre til anvendelse i kald fra angivet sti
- cpr.txt (på samme format som cprDocumententries.txt eller cprTop100.txt (output af validation kan anvendes med omdøbning af fil til cpr.txt))
- output'er sammenligninger til std out samt to filer i den angivet sti
- result.txt
- resultCount.csv - mulighed for hurtigere søgning på forskelle ved at åbne som regneark og anvende funktioner heri
- output'er request og response kald indhold
- 0101010304_nxrg_request.txt
- 0101010304_nxrg_response.txt
- 0101010304_opentext_request.txt
- 0101010304_opentext_response.txt
- etc
Sti'er kan sættes med en env variabel som vist ovenfor og volume mount til hostmaskinen som vist ovenfor.
Env, der kan sættes i forbindelse med validering:
ENV | Beskrivelse | Eksempel |
---|---|---|
nxrg_data_url | URL til databasen med NXRG data | jdbc:mysql://localhost:3307/nxrg |
nxrg_data_user | Bruger til NXRG databasen | nxrg |
nxrg_data_pass | Password for bruger | nxrg |
Env, der kan sættes i forbindelse med verifikation:
ENV | Beskrivelse | Eksempel |
---|---|---|
nxrg_iti18_url | url til NXRG iti-18 snitflade | https://nxrg.nspnxrg.medcom.dk/nxrg/iti18 |
opentext_iti18_url | url til OpenText iti-18 snitflade | https://test1-cnsp.ekstern-test.nspop.dk:8443/registry/services/xds-iti18 |
Driftsvejledning - Replaytool
Som beskrevet i NXRG - 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.
Disse er implementeret som en del af NXRG og kan afvikles med følgende kommando
Code Block |
---|
docker run --network=host --env filepath=/replay/ --env replay_file=/replay/logs --volume /mymachine/migrationvalidation/run1:/replay registry.nspop.dk/components/nxrg-migration-verification:snapshot replay |
replay - laver en række kald mod NXRG og vurderer resultatet i forhold til tidligere resultat. Desuden laver den en output fil, som indeholder information om forventet og faktisk rasultat, som man kan bruge til at vurdere forskellene ud fra.
- filePath skal pege ned den folder, hvor output af kørslen skal placeres.
- result.txt: alle id'er og om det gik godt eller eller ej
- result.csv: resultatet med flere detaljer (se nedenfor)
- replay_file skal pege på de request/ response som skal genspilles
- skal være en specifik fil eller et bibliotek med filer, hvor request og response er
- format skal være som filen testlog18.txt, der findes i NXRG projektet under modulet nxrg-migration-verification i resources
Env, der kan sættes i forbindelse med replay:
ENV | Beskrivelse | Eksempel |
---|---|---|
nxrg_iti18_url | url til NXRG iti-18 snitflade | http://localhost:8060/nxrg/iti18 |
nxrg_iti57_url | url til NXRG iti-57 snitflade | http://localhost:8060/nxrg/iti57 |
nxrg_iti42_url | url til NXRG iti-42 snitflade | http://localhost:8060/nxrg/iti42 |
nxrg_iti61_url | url til NXRG iti-61 snitflade | http://localhost:8060/nxrg/iti61 |
Output i result.csv:
Kolonne | Beskrivelse | Note |
---|---|---|
Id | Request og response id fra filen | |
Operation | Hvilken type kald det, eks iti57 | |
Resultat | Gik det overordnet godt eller ej | Der er en række kombinationer af svar fra kaldende, som vurderes at være ok. F.eks. når NXRG ikke kan finde et specifik dokument i forbindelse med en replace. Dette er implementeret i klassen StatusCodeCombination, hvor kombinationer kan læses for nu. |
Note | Lidt information omkring en vurdering af Resultat | |
KaldStatusEns | Er ForventetKaldStatus og FaktiskKaldStatus ens? | |
FejlkodeAntalEns | Er ForventetFejlkodeAntal og FaktiskFejlkodeAntal ens? FejlKodeAntal er de antal fejl, som er blevet returnernet. | ForventetFejlkodeAntal og FaktiskFejlkodeAntal bør være 0 eller 1 for hver linie, ellers kan FejlkodeListeEns, samt kolonnerne med ForventetFejl* og FaktiskFejl* være ikke fyldesgørende. |
FejlkodeListeEns | Er FejlkodeListeForventet og FejlkodeListeFaktisk ens? (sammenlignet en til en hvis flere) | |
ForventetFejlkode1 ForventetFejlContext1 ForventetFejlLocation1 ForventetFejlSeverity1 | Fejl 1 i det oprindelige svar, hvis nogen | |
FaktiskFejlkode1 FaktiskFejlContext1 FaktiskFejlLocation1 FaktiskFejlSeverity1 | Fejl 1 i det faktisk NXRG svar, hvis nogen | |
HsuidheaderMed | Er hsuidheaderen med i kaldet? | Blev på et tidspunkt brugt til at vurdere om eventuelle forskelle skyldtes denne |
Filen kan med fordel åbnes i et regneark, og funktioner som autofilter og pivot tabeller anvendes til vurdering af dens indhold.
Ved vurdering af resultat:
- Resultat kolonnen bør være "OK"
- ForventetFejlkodeAntal og FaktiskFejlkodeAntal bør kun indeholde værdien 0 eller 1 (se ovenfor)
- Kig på Operation, ForventetFejl* og FaktiskFejl* og vurder
Driftsvejledning - Datareperationstool
For at reparere på forkerte data er der lavet et reperationstool.
Code Block |
---|
docker run --network=host --env cpr_file=/input/cprinput.txt --env nxrg_data_url=jdbc:mysql://localhost:3307/nxrg --env nxrg_data_user=nxrg --env nxrg_data_pass=nxrg --volume /mymachine/cprinput.txt:/input/cprinput.txt registry.nspop.dk/components/nxrg-migration-verification:snapshot repair
|
Env, der skal sættes i forbindelse med kørsel:
ENV | Beskrivelse | Eksempel |
---|---|---|
nxrg_data_url | URL til databasen med NXRG data | jdbc:mysql://localhost:3307/nxrg |
nxrg_data_user | Bruger til NXRG databasen | nxrg |
nxrg_data_pass | Password for bruger | nxrg |
cpr_file | Inputfil med cprnumre, der skal fixes | /input/cprinput.txt |