Page History
...
documentsources: I tabellen documentregistry er der konfiguration af hvilke dokument-indeks, der anvendes af servicen.
Generering af installationspakke
Installationspakken indeholder, når genereret, filer, der kan anvendes som skabeloner med henblik på at understøtte:
- Oprettelse af database-skemaer
- Konfiguration af datasources til disse database-skemaer
Installationspakken genereres ud fra byggemiljøet med følgende kommando udført fra folderen <packing>/dds/common:
Code Block |
---|
mvn -Dinstallation-package-folder=<installationspakke> -Pgenerate-install-package initialize |
Derved kopieres sql-scripts og konfigurationsfiler til folderen udpeget som <installationspakke>. Disse filer kan anvendes som skabeloner og tilpasses som beskrevet i det efterfølgende.
Installation af datasource
Alle datasource filer nævnt i afsnittene fra 3.3 og efter, bør ikke deployeres i deployments folderen på WildFly, da dette vil føre til manglende kontrol fra WildFly Administration Console.
Indholdet af datasource filerne bør kopieres ind i standalone.xml under:
Code Block |
---|
/server/ profile/subsystem[xmlns="urn:jboss:domain:datasources:2.0"]/datasources |
Oprettelse af whitelist skema
Skema oprettes ved afvikling af SQL script fra mysql:
Code Block |
---|
<installationspakke>/createWhitelistSchema.sql |
Data source ændres til at pege på whitelist-skema ved at opdatere filen:
Code Block |
---|
<installationspakke>/whitelist-wildfly-ds.xml |
Test note:
I folderen compose/database ligger sql-scripts, som kan anvendes til at initialisere disse databaser. Script-filerne er præfikset med et løbenummer, som angiver den rækkefølge de skal køres i. Bemærk at nogle scripts indsætter testdata, disse må udelukkende anvendes i testmiljøer.
Oprettelse af whitelist
I testkonfiguration kan whitelist-databasen opdateres med SQL insert.
Code Block |
---|
INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsregistry', '', 'some-cvr-number-here' ); |
I testsetup skal brugeren whitelistuser/password have de nødvendige privilegier til whitelist databasen.
Oprettelse af adgang til data i autorisationsregister
DDS Registry anvender opslag i autorisations register data, der skal være tilgængeligt i stamdata i følgende tabel:
- autreg
Test note:
I testsetup skal brugeren stamdatauser/password have læse adgang til autreg tabellen i stamdata.
Oprettelse af adgang til SOR-registerdata
DDS Registry anvender SOR data, der skal være tilgængeligt i stamdata i følgende tabeller:
- SORRelationer
- SORYderSHAKRelationer
Indlæsning og synkronisering af SOR databasen sker fra central NSP komponent.
Test note:
Note: I test setup skal brugeren stamdatauser/password have læseadgang til SOR tabellerne i stamdata.
Oprettelse af documentsources skema
Brugeren identificeret i data source-filen (dsuser/password) skal have de nødvendige privileges til documentsource databasen.
Documentsource-databasens documentregistry-tabel opdateres med SQL insert for configuration af et lokalt dokument-indeksI testkonfiguration kan whitelist-databasen opdateres med SQL insert.
Code Block |
---|
INSERT INTO whitelistdocumentsource.whitelist_configdocumentregistry (documentregistryserviceurl, service_keydocumentregistryfriendlyname, service_typedocumentregistryservicenamespace, cvrdocumentregistrylocal, documentregistryservicename) VALUES ( 'dk.nsi.ddsregistry' http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls', 'DDS', 'some-cvr-number-here' ); |
I testsetup skal brugeren whitelistuser/password have de nødvendige privilegier til whitelist databasen.
Oprettelse af adgang til data i autorisationsregister
DDS Registry anvender opslag i autorisations register data, der skal være tilgængeligt i stamdata i følgende tabel:
- autreg
Data source ændres til at pege på stamdata skema ved at opdatere filen:
Code Block |
---|
<installationspakke>/auth-ds.xml |
Test note:
I testsetup skal brugeren stamdatauser/password have læse adgang til autreg tabellen i stamdata.
Oprettelse af adgang til SOR-registerdata
DDS Registry anvender SOR data, der skal være tilgængeligt i stamdata i følgende tabeller:
- SORRelationer
- SORYderSHAKRelationer
Indlæsning og synkronisering af SOR databasen sker fra central NSP komponent.
Data source ændres til at pege på stamdata skema ved at opdatere filen:
Code Block |
---|
<installationspakke>/sor-ds.xml |
Test note:
Note: I test setup skal brugeren stamdatauser/password have læseadgang til SOR tabellerne i stamdata.
Oprettelse af documentsources skema
Skema oprettes ved afvikling af SQL script fra mysql:
Code Block |
---|
<installationspakke>/createDocumentSourcesSchema.sql
<installationspakke>/createDocumentRegistry.sql |
Data source ændres til at pege på documentsource-skema ved at opdatere filen:
Code Block |
---|
<installationspakke>/documentsources-ds.xml |
Brugeren identificeret i data source-filen (dsuser/password) skal have de nødvendige privileges til documentsource databasen.
Documentsource-databasens documentregistry-tabel opdateres med SQL insert for configuration af et lokalt dokument-indeks.
Code Block |
---|
INSERT INTO documentsource.documentregistry (documentregistryserviceurl, documentregistryfriendlyname, documentregistryservicenamespace, documentregistrylocal, documentregistryservicename) VALUES (' http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls', 'DDS', 'urn:ihe:iti:xds-b:2007', true, '300000', true, 'DocumentRegistry_Service'); |
Adressen for indeksets webservice-endpoint er her givet ved http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls, hvilket skal tilpasses konkret placering. Se [Driftsvejledning] for betydning af øvrige kolonner.
Deployment på WildFly 8.2
Dette afsnit beskriver deploymentprocessen på WildFly 8.2
Tilpasning af applikationsserver
Ingen.
Deployment af komponenter
OBS! Inden opstart af WildFly skal det sikres at properties og modul filer til servicen ligger i de applikationsspecifikke modul foldere på WildFly. Se afsnit 4.3.
Folderen <installationspakke> forudsættes genereret og indeholdte filer potentielt tilpasset som beskrevet i afsnit 3.1.
Code Block |
---|
<packing>/ddsservices/ddsregistry/war/target/ddsregistry.war
<installationspakke>/auth-ds.xml
<installationspakke>/whitelist-wildfly-ds.xml
<installationspakke>/sor-ds.xml
<installationspakke>/documentsources-ds.xml |
Konfiguration af adgang til stamdata-databasen sker i auth-ds.xml, adgang til whitelist-databasen i whitelist-wildfly-ds.xml, adgang til SOR-databasen i sor-ds.xml, mens adgang til Data sources konfigureres i documentsources-ds.xml. Se afsnit 3.2 for installation af datasources.
Servicekomponenter der skal deployes til WildFly, skal kopieres til mappen ”deployments”. Hvis WildFly kører normalt starter den selv komponenten op. Er dette ikke tilfældet skal WildFly genstartes – se afsnit 4.3.7.
Yderligere information vil findes i driftsvejledningen.
Konfiguration af komponenterne
Al konfiguration foregår ved redigering af de relevante properties filer i deres modul folder under WildFly modules. Ved konfigurationsændringer bør servicen/WildFly genstartes.
Indholdet af de enkelte konfigurationsfiler, er beskrevet og forklaret i [Driftsvejledning].
Følgende filer kan tilpasses:
Deployment af Modul
WildFly DDSRegistry modul sættes op ved at kopiere filen:
Code Block |
---|
<packing>/ddsservices/ddsregistry/war/src/test/conf/module.xml |
Til:
...
urn:ihe:iti:xds-b:2007', true, '300000', true, 'DocumentRegistry_Service'); |
Adressen for indeksets webservice-endpoint er her givet ved http://host:57774/csp/public/hsbus/HS.IHE.XDSb.Registry.Services.cls, hvilket skal tilpasses konkret placering. Se [Driftsvejledning] for betydning af øvrige kolonner.
Deployment
Dette afsnit beskriver hvordan komponenten deplloyes.
Jenkins
BRS bygges med NSP's Jenkins server via følgende jobs:
- DDS_build - Bygger koden (sker automatisk ved commits)
- DDS_push_snapshot - Pusher det nyeste snapshot image til NSP Docker Registry
NSP er selv ansvarlige for at pushe release versioner af DDS til NSP Docker Registry gennem Jenkins.
Docker
BRS består af to docker images som pushes til NSP Docker Registry under navnene:
registry.nspop.dk/components/dds/ddsregistry:snapshot
registry.nspop.dk/components/dds/ddsrepository:snapshot
Docker-compose
DDS leveres samtidig som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/svn/components/dds/trunk/compose.
For release x.y.z af BivWSP findes Docker Compose filerne i folderen https://svn.nspop.dk/svn/components/dds/tags/release-x.y.z/compose
Compose folderen indeholder 5 underfoldere:
configuration | Her ligger alle de konfigurationsfiler som det forventes af driften tilretter til det anvendte miljø. |
database | Her ville alle de databasefiler som det forventes at driften lægger på en NSP database ligge, hvis der var nogen |
development | Her ligger en Docker Compose fil til brug for udvikling. Se Guide til Udviklere. |
test | Her ligger en Docker Compose fil der kan starte DDS i en standalone test konfiguration. |
release | Her ligger den Docker Compose fil som det forventes driften anvender på både test og produktionsmiljøerne. |
Konfiguration af datasources
Under configuration/datasources findes en række datasources, som volume-mappes ind i komponenten. Disse skal konfigureres inden opstart.
Konfiguration af adgang til stamdata-databasen sker i auth-ds.xml, adgang til whitelist-databasen i whitelist-wildfly-ds.xml, adgang til SOR-databasen i sor-ds.xml, adgang til CRA-databasen i crasts-ds.xml, mens adgang til Data sources konfigureres i documentsources-ds.xml.
Konfiguration af properties
Al konfiguration foregår ved redigering af de relevante properties filer, som ligger under compose/configuration. Disse filer volume-mappes ind i komponenten. Ved konfigurationsændringer bør servicen genstartes.
Indholdet af de enkelte konfigurationsfiler, er beskrevet og forklaret i [Driftsvejledning].
DDSRegistry.properties
Konfigurerer opsætning af DDS Registry og hvorledes den benytter sig af eksterne services.
...