...

Vejledning til installation og konfiguration af DDS Repository.
Afsnit 2 indeholder servicekrav til det omliggende miljø, herunder krav til operativsystem og standardapplikationer, som f.eks. applikationsservere, databaseservere, Java og/eller Net versioner mm., angivet på version og service pack niveau.
Afsnittene 3 og 4.2 indeholder information om konfiguration af applikationsserveren og databasen, herunder oprettelse af databaseskemaer.
Afsnit 4 beskriver hvorledes services deployeres, herunder om der er krav om evt. genstart af server eller andre applikationer. Ved opgradering af komponenten beskrives desuden tilstanden, systemet skal være i for at opgraderingen kan finde sted, f.eks. om applikationsserver og/eller databaseserver skal være stoppet.

...

Følgende databasekomponenter er tilknyttet servicen:
whitelist: whitelist der indeholder godkendte CVR numre, som skal have adgang til servicen.Alle CVR-numre i databasen, der skal gælde for DDS Repository, skal have 'service key' sat til 'dk.nsi.ddsrepository'.
autorisation: Anvender stamdata-tabellen autreg, der indeholder CPR-nummer og autorisationsnummer for sundhedspersoner med gyldige og gældende dansk autorisation opført i Sundhedsstyrelsens autorisationsregister.
sor: Mapning mellem SOR-koder og SHAK-koder/ydernumre, som anvendes til opslag i forbindelse med samtykkeverifikationer
documentsources: Mapning mellem angivet OID i udtræk til aktuelt service endpoint for XDS dokument kilde

Generering af installationspakke

Installationspakken indeholder, når genereret, filer, der kan anvendes som skabeloner med henblik på at understøtte:

1. Oprettelse af database-skemaer
2. Konfiguration af datasources til disse database-skemaer

Installationspakken genereres ud fra byggemiljøet med følgende kommando udført fra folderen <packing>/ddsservices:

mvn -Dinstallation-package-folder=<installationspakke> -Pgenerate-install-package initialize

...

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.

INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsrepository', '', 'some-cvr-number-here' );

I testsetup skal brugeren whitelistuser/password have de nødvendige privileges til whitelist databasen.

Oprettelse af adgang til data i autorisationsregister

DDS Repository 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 Repository 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.

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:

/server/ profile/subsystem\[xmlns="urn:jboss:domain:datasources:2.0"\]/datasources

Oprettelse af whitelist skema

Skema oprettes ved afvikling af SQL script fra mysql:

<installationspakke>/createWhitelistSchema.sql

...

Test note:
I testkonfiguration kan whitelistdocumentsource-databasen opdateres med SQL insert.

INSERT INTO whitelist.whitelist_config ( service_key, service_type, cvr ) VALUES ( 'dk.nsi.ddsrepository', '', 'some-cvr-number-here' );

...

Oprettelse af adgang til data i autorisationsregister

DDS Repository 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:
<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 Repository 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:

<installationspakke>/sor-ds.xml

...

Oprettelse af documentsources skema

Skema oprettes ved afvikling af SQL script fra mysql:

<installationspakke>/createDocumentSourcesSchema.sql

...

<installationspakke>/documentsources-ds.xml

...

INSERT INTO `documentsource` (`oid`, `type`, `service_endpoint`, `soap_version`, `timeout`) 
VALUES ('{*}some_unique_id{*}','\[{*}unique_id_type\]{*}','{*}some_endpoint{*}','\[{*}SOAP_version{*}\]',\[{*}timeout{*}\]);

• oid: OID værdien som for den pågældende XDS dokument kilde, som kan være at typen 'repository_unique_id' eller 'home_community_id'
• type: Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier:

[‘repository_unique_id’|’home_community_id’]

• service_endpoint: Angiver URL til XDS dokument kilde
• timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.
• soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:

[’1.1’|’1.2’]

Kombinationen af *oid* og *unique_id_type* skal være unik.
I testsetup skal brugeren dsuser/password have de nødvendige privileges til documentsource databasen.

Deployment på WildFly 8.2

Dette afsnit beskriver deploymentprocessen på WildFly 8.2

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.2.
Folderen <installationspakke> forudsættes genereret og indeholdte filer potentielt tilpasset som beskrevet i afsnit 3.1.

<packing>/ddsservices/ddsrepository/war/target/ddsrepository.war
<installationspakke>/auth-ds.xml
<installationspakke>/whitelist-wildfly-ds.xml
<installationspakke>/sor-ds.xml
<installationspakke>/documentsources-ds.xml

...

`documentsource` (`oid`, `type`, `service_endpoint`, `soap_version`, `timeout`) 
VALUES ('{*}some_unique_id{*}','\[{*}unique_id_type\]{*}','{*}some_endpoint{*}','\[{*}SOAP_version{*}\]',\[{*}timeout{*}\]);

• oid: OID værdien som for den pågældende XDS dokument kilde, som kan være at typen 'repository_unique_id' eller 'home_community_id'
• type: Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier:

[‘repository_unique_id’|’home_community_id’]

• service_endpoint: Angiver URL til XDS dokument kilde
• timeout: Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder.
• soap_version: Angiver XDS dokument kildens SOAP version og den skal have én af følgende værdier:

[’1.1’|’1.2’]

Kombinationen af *oid* og *unique_id_type* skal være unik.
I testsetup skal brugeren dsuser/password have de nødvendige privileges til documentsource databasen.

Deployment

Dette afsnit beskriver hvordan komponenten deployes.

Jenkins

DDS 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

DDS 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:

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].

Konfiguration af managed executor service

DDS bruger en managed executor service til at foretage samtidige kald af eksterne services, hvilket gælder interne NSP services (minlog, samtykke osv.).
DDS bruger sin egen instans af en managed executor service, som opsættes automatisk når docker-imaget bygges

 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 DDSRepository modul sættes op ved at kopiere filen:

<packing>/ddsservices/ddsrepository/war/src/test/conf/module.xml

...

/pack/wildfly8/modules/nsi/ddsrepository/config/main

DDSRepository.properties

Konfigurerer opsætning af DDS Repository og hvorledes den benytter sig af eksterne services.
En skabelon for denne fil findes i:

<packing>/ddsservices/ddsrepository/war/src/test/conf/DDSRepository.properties

...

/pack/wildfly8/modules/nsi/ddsrepository/config/main

...

ddsrepository.log4j.properties

Konfigurerer logopsætningen for DDS Repository.
En skabelon for log4j konfiguration findes i:

<packing>/ddsservices/ddsrepository/war/src/test/conf/ddsrepository.log4j.properties

...

/pack/wildfly8/modules/nsi/ddsrepository/config/main

...

Konfiguration af managed executor service

DDS bruger en managed executor service til at foretage samtidige kald af eksterne services, hvilket gælder interne NSP services (minlog, samtykke osv.).
DDS bruger sin egen instans af en managed executor service, som sættes op ved følgende i standalone.xml i WildFly:

...
<subsystem xmlns="urn:jboss:domain:ee:2.0">
<spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
<concurrent>
<context-services>
<context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
</context-services>
<managed-thread-factories>
<managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="600000" core-threads="5" max-threads="25" keepalive-time="5000" queue-length="10000"/>
<managed-executor-service name="dds" jndi-name="java:jboss/ee/concurrency/executor/dds" context-service="default" hung-task-threshold="600000" core-threads="10" max-threads="1000" keepalive-time="5000" queue-length="100000"/>
</managed-executor-services>
<managed-scheduled-executor-services>
<managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" core-threads="2" keepalive-time="3000"/>
</managed-scheduled-executor-services>
</concurrent>
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" jms-connection-factory="java:jboss/DefaultJMSConnectionFactory" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
</subsystem>
... 

Udsnittet viser en standard WildFly opsætning, hvor det markerede er specifikt for DDS og skal indsættes i standalone.xml. Bemærk at der er flere parametre, hvor der er indsat default værdier, der kan fintunes under drift. For yderligere beskrivelse af parametrene for managed executor services henvises til JBoss dokumentationen (https://docs.jboss.org/author/display/WFLY8/EE+Subsystem+Configuration).
Den markerede managed executor service benyttes både af DDSRegistry og DDSRepository).

Konfiguration af NSP SLA log

NSP-util anvendes som en del af servicen og skal konfigureres. Eksempel på konfiguration fil findes i

<packing>/ddsservices/ddsrepository/war/src/test/conf/log4j-nspslalog-ddsrepository.properties
<packing>/ddsservices/ddsrepository/war/src/test/conf/nspslalog-ddsrepository.properties 

Filen redigeres inden den placeres på WildFly i:

compose/packconfiguration/wildfly8/modules/nsi/ddsrepository/config/main

...

ddsrepository/log4j-nspslalog-ddsrepository.properties
compose/configuration/ddsrepository/nspslalog-ddsrepository.properties 

Whitelisting af services

Adgang til DDS Repository styres på CVR-niveau via konfigurationen i whitelist.whitelist_config tabellen. Se også afsnit 3.1.

...

Konfigurationsfil til det svar, DDS Repository returnerer ved forespørgsel mod dens DKS-snitflade opsættes ved at kopierere:

<packing>/ddsservices/ddsrepository/war/src/test/conf/dksConfiguration.xml

tiltilpasse:

compose/pack/wildfly8/modules/nsi/ddsrepository/config/mainconfiguration/ddsrepository/dksConfiguration.xml

Start/genstart af service

Komponenten kan genstartes ved "touch" af war-filen på WildFly. Alternativt skal WildFly genstartes ved at køre kommandoen

...

DDS Repository startes og stoppes med Docker Compose kommandoer.

Logfiler

DDS Repository kan logge kald til følgende logs: En NSP-SLA-log, en audit-log, en applikations log og en performance log.

nsputil-sla-ddsrepository.log
ddsrepository-audit.log
ddsrepository.log
ddsrepository-performance.log 

...

ddsrepository-consentoverride.log

...

Opgradering af komponenter

Når der kommer opgraderinger til en komponent, vil der medfølge en releasenote, der beskriver hvad opgraderingen består af, samt hvilke handlinger der er nødvendige for at opgradere den deployede komponent.

Afinstallation af servicen

Fjern service komponenter under WildFly' deployments/ folder:

ddsrepository.war

...

performance log.

nsputil-sla-ddsrepository.log
ddsrepository-audit.log
ddsrepository.log
ddsrepository-performance.log 

I default opsætningen logges der udelukkende fejl til applikationsloggen.
Kald til DDS Repository, hvor værdispringsreglen anvendes, logges til log filen: ddsrepository-consentoverride.log

ddsrepository-consentoverride.log

Det er muligt at konfigurere placeringen af filerne, samt hvilket niveau de logger på, ved at redigere i ddsrepository.log4j.properties.
Alle logs er beskrevet i driftsvejledningen.

Opgradering af komponenter

Når der kommer opgraderinger til en komponent, vil der medfølge en releasenote, der beskriver hvad opgraderingen består af, samt hvilke handlinger der er nødvendige for at opgradere den deployede komponent.

Afinstallation af servicen

• AuthDS (OBS! Benyttes af DDSRegistry)
• SORDS (OBS! Kan være anvendt af anden service)
• WhitelistDS (OBS! Kan være anvendt af anden service)
• DocumentSourcesDS (OBS! Benyttes af DDSRegistry)

Fjern properties filer under DDSRepository modules folder:

...

Oprydning i MySQL database:

...