Komponenter

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.

Konfiguration

Servicekonfiguration

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:

log4j konfiguration

Log4j konfiguration findes i samme wildfly modul som servicekonfigurationen

Se yderligere opsætning i installationsvejledningen.

Overvågning

NXRG udstiller en overvågningsside, som findes i listen af komponenter i afsnit 2.

5.1. Fortolkning af HTML overvågningsside

NXRG-overvågningssiden returnerer enten:

• HTTP 200, hvis servicen i øjeblikket kører fint.
• HTTP 203, hvis der er opstået en fejl der kræver indgriben.

5.2. Overvågningstyper

Det overvåges om der kan opnås forbindelse til databasen.

Eksempler på status-sider

200 OK

TODO

203 Non-authoritative Information

TODO

Forretningslogning

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)

Logning for ITI-42

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.

Logning for ITI-18

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

Logning for ITI-57

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.

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

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:

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

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

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, der kan sættes i forbindelse med verifikation:

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

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:

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.

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

Cleanup job

Cleanup job sletter DocumentEntries og tilhørende objekter fra NXRG databasen som er ældre end en specificeret dato.

Servicekonfiguration

Cleanup jobbet har følgende properties der kan sættes:

Brug af service

Servicen udstiller to HTTP endpoints:

• /cleanup/status
• /cleanup/start

som kan interageres med eks. med curl

curl http://localhost:8060/nxrg/cleanup/status

Logning

Cleanup job logger på standardout vha. log4j. Jobbet vil ved kørsel udskrive følgende INFO statements ud:

Konfigurationsparametre:

• delete.after.days = x (evt. default hvis ikke sat)
  
• delete.type.code = x (evt. default hvis ikke sat)
  
• delete.output.dir = x (evt. default hvis ikke sat)

Søgning:

• Searching for documents to delete of type: 39289-4 created before: Tue Aug 13 14:39:15 CEST 2019
  
• Found documents to delete: 33

Sletning

• Successfully deleted documents: 33
  

Output

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:

• deleted-ddMMyyyyHHmm-repositoryId.txt

Hvor "ddMMyyyyHHmm" svarer til det tidspunkt, hvor jobbet blev startet, og repositoryId er OID på det repository der skal slettes dokumenter i.