Dette dokument dækker følgende komponenter på NSP:
NSP XDS Registry
Type: Webservice
Filnavn: nxrg.war
Url: <serverurl>/nxrg
Servicecheckurl: <serverurl>/nxrg/status
Versionurl: <serverurl>/nxrg/health returnerer en json struktur med denne
Migreringskomponenten, der migrerer opentext data til SQL scripts til indlæsning i nxrg databasen.
Grundlæggende konfiguration foregår ved redigering i filen nxrg.properties, der placeres i følgende WildFly modul:
/pack/wildfly/modules/sds/nxrg/configuration/main/
Moduldefinitionen er at finde i sourcekoden til nxrg under:
/compose/configuration/module.xml
I filen skal følgende properties være definerede:
Property | Beskrivelse |
---|---|
datasource.jndi.name | JNDI navnet på den datasource der giver adgang til NXRG databasen. |
liquibase.changelog.file | Angiver den changelog fil som liquibase skal anvende. Property er ikke krævet. Hvis der skal afvikles integrationstest mod det miljø der installeres skal denne sættes til liquibase-changelog-test.xml. Denne kan også sættes via en environmentvariabel i formen liquibase_changelog_file. |
nxrg.allowed.mimetype | Tilladt MimeType på DocumentEntries i requests til ITI-42, ITI-57 og ITI-61. |
iti18.request.validation.enabled | Angiver om der skal foretages openehealth-validering af requestet. Default: true. |
iti18.response.validation.enabled | Angiver om der skal foretages openehealth-validering af responset. Default: true. |
iti42.request.validation.enabled | Angiver om der skal foretages openehealth-validering af requestet. Default: true. |
iti42.response.validation.enabled | Angiver om der skal foretages openehealth-validering af responset. Default: true. |
iti57.request.validation.enabled | Angiver om der skal foretages openehealth-validering af requestet. Default: true. |
iti57.response.validation.enabled | Angiver om der skal foretages openehealth-validering af responset. Default: true. |
iti61.request.validation.enabled | Angiver om der skal foretages openehealth-validering af requestet. Default: true. |
iti61.response.validation.enabled | Angiver om der skal foretages openehealth-validering af responset. Default: true. |
Log4j konfiguration findes i samme wildfly modul som servicekonfigurationen
Se yderligere opsætning i installationsvejledningen.
NXRG udstiller en overvågningsside, som findes i listen af komponenter i afsnit 2.
NXRG-overvågningssiden returnerer enten:
Det overvåges om der kan opnås forbindelse til databasen.
TODO
TODO
NXRG laver forretningslogninger ved hvert kald af de udbudte ITI-services. I det følgende gennemgåes formaterne for hver service.
Alle forretningslogninger ender i en dedikeret logfil nxrg-itiusage.log.
Loglinjen er formatteret som json og alle logninger har følgende indgange:
timestamp: Tidsstempel for loghændelsen
threadId: Trådens navn (hvor iti-servicen blev udført)
category: Hvilken ITI service beskriver linjen?
status: Returstatusværdi for den pågældende service rapporteres i status, mens eventuelle fejl angives i en liste errors.
priority: Loglinjens prioritet (er INFO for forretningslogninger)
Succesfuldt kald til service iti-42 giver anledning til en logningslinje på følgende format:
{ "timestamp":"25 Jun 2021 11:58:15,468", "threadId":"default task-1", "priority":"INFO", "category":"ITI-42", "status":{ "errors":null, "status":"OK" }, "submissionSet":{ "uniqueId":"5321688553302212937.6611016525576425327.1624615095422" }, "documentEntries":[ { "entryUUid":"urn:uuid:608ce70e-db4b-4ced-98d6-58cdbba16a14", "replacesEntryUuid":null } ] } |
Iti-42 logninger har følgende egenskaber:
submissionSet: Identifikation (uniqueId) af det submissionset, der indeholder informationen i iti-42 kaldet.
documentEntries: En liste af entryUUid'er, der oprettes. Hvis en documentEntry i kaldet giver anledning til replace på en anden documentEntry, så angives dette uuid i egenskaben replacesEntryUuid.
Succesfuldt kald til service iti-18 giver anledning til en logningslinje på følgende format:
{ "timestamp":"25 Jun 2021 12:50:40,929", "threadId":"default task-1", "priority":"INFO", "category":"ITI-18", "status":{ "errors":null, "status":"OK" }, "queryType":"urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d", "returnType":"LeafClass", "numberOfResults":5 } |
Iti-18 logninger har følgende egenskaber:
queryType: Identifikation typen af query.
returnType: Definerer, hvilken type af objekter, der returneres fra servicen
numberOfResults: Antallet af documententries i svaret
Succesfuldt kald til service iti-57 giver anledning til en logningslinje på følgende format:
{ "timestamp":"11 Aug 2021 13:41:07,202", "threadId":"default task-1", "priority":"INFO", "category":"ITI-57", "status":{ "status":"OK", "errors":null }, "updateOperationName":"UpdateDocumentEntryAvailabilityStatus", "updatedObjectUuid":"urn:uuid:7a2bf9c1-3603-46fe-9b22-4d25e4c01192" } |
Iti-57 logninger har følgende egenskaber:
updateOperationName: Typen af opdatering
updatedObjectUuid: UUID der er opdateret.
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
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
Som beskrevet i NXRG - Design- og arkitekturbeskrivelse kan der efter en migrering foretages hhv
Disse to processer er implementeret som en del af NXRG og kan afvikles med følgende kommando
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:
verification - laver ITI-18 kald mod NXRG og Open Text registry:
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 |
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
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.
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 1 for hver linie, ellers kan FejlkodeListeEns, samt kolonner med fejlkoder 1 () 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:
Cleanup job sletter DocumentEntries og tilhørende objekter fra NXRG databasen som er ældre end en specificeret dato.
Cleanup jobbet har følgende properties der kan sættes:
Property | Beskrivelse | Default hvis ikke sat |
---|---|---|
delete.after.days | Hvor gamle dokumenter i Registry skal være, før de slettes | 2 år |
delete.type.code | Type Code på de dokumenter der slettes (Her er aftale = "39289-4") | 39289-4 |
delete.output.dir | Directory hvor output filer placeret | /cleanup-output |
Servicen udstiller to HTTP endpoints:
som kan interageres med eks. med curl
curl http://localhost:8060/nxrg/cleanup/status |
Cleanup job logger på standardout vha. log4j. Jobbet vil ved kørsel udskrive følgende INFO statements ud:
Konfigurationsparametre:
Søgning:
Sletning
Efter kørsel af jobbet vil der blive placeret filer i det konfigurerede output bibliotek svarende til dokumenter der skal slettes i XDS repository. Der genereres een fil pr Repository der skal slettes dokumenter i.
Navngivningen på filen/filerne vil være:
Hvor "ddMMyyyyHHmm" svarer til det tidspunkt, hvor jobbet blev startet, og repositoryId er OID på det repository der skal slettes dokumenter i.