Vejledning til installation og konfiguration af DDS Registry.
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.3 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.
Læseren forventes at have kendskab til National Sundheds-IT’s platform NSP, samt generelt kendskab til WildFly applikation server, MySQL, samt Ubuntu Linux operativ system.
Dokumentet beskriver ikke forhold der berører konfiguration på DoDi, NSP eller centrale ’NSP-lignende miljøer’ eller etablering og konfiguration af distribution af data fra DoDi til øvrige platforme.
Dokumentet er etableret på baggrund af testinstallation på NIAB (NSP in a box) testserver version 2.35.
Hvor der i teksten er angivet <packing> refereres til topniveaufolderen for release-pakken med kildekode. Folderens navngivning afhænger af versionen på releaset.
Dette dokument er oprettet med udgangspunkt i dokumentet INS0003 Installationsvejledning DDS Registry.docx
Definition | Beskrivelse |
---|---|
DDS | Dokumentdelingsservice |
NSI | National Sundheds-IT |
NSP | Den nationale service platform (inden for sundheds-IT) |
SHAK | Sygehusafdelingsklassifikation |
SOR | Sundhedsvæsenets organisationsregister |
STS | Security Token Service |
DODI | NSI platform til data opsamling og distribution |
SOSI-seal | Et kodebibliotek der stilles til rådighed til implementering af sikkerhed for Web service klienter og service provides |
Alias | Beskrivelse |
---|---|
Driftsvejledning | Driftsvejledning DDS Registry (SSE/11734/OHB/0003) |
Komponenterne er udviklet og testet under WildFly-8.2.0.Final på udviklingsplatformen og mod WildFly 8.2 på NIAB (version 2.35). Service kan deployeres i produktion på WildFly 8.2 applikationsservere.
Applikationsserveren kræver SUN/Oracle Java 6.0.
Der stilles ingen krav til operativsystemet, ud over krav om, at Java er understøttet på operativsystemet.
Ubuntu Linux bruges som operativsystem på NSP’en, men udviklingen af komponenten er foretaget på Windows 7/8, og disse platforme kan ligeledes afvikle komponenterne.
Komponenten er testet mod MySQL version 5.5.21 på Windows 7/8 og testet mod MySQL version 5.5.38 på NIAB (version 1.7.0).
DDS Registry kalder følgende services og skal være godkendt på whiteliste til at kalde disse services. Disse services kan være installeret lokalt på NSP eller eksternt.
Behandlingsrelation (BRS): BRS giver mulighed for at forespørge om en given sundhedsperson har en behandlingsrelation til en given borger. Aktivering af kald er konfigurerbart via properties-filen for DDS Registry.
Samtykkeverifikation: Samtykkeverifikationsservicen kaldes for at filtrere de dokumenter fra, som sundhedspersonen ikke har samtykke til at se. Listen af dokumenter fremsøges i DDS-document registry. Filtreringen er baseret på de positive/negative samtykker borgeren har oprettet.
MinLogRegistration: En sundhedspersons adgang, eller forsøg på adgang, til borgers oplysninger via DDS Registry, registreres i MinLogRegistration-servicen.
Følgende service skal blot kunne tilgås fra DDS Registry, men kræver ikke at DDS Registry er på whiteliste:
DDS-documentregistry: DDS documentregistry indeholder metadata på dokumenter om borgeres sundhedsoplysninger.
DDS Registry foretager udelukkende opslag, samt registrering, af data via andre services.
DDS Registry ressourceforbrug vil afhænge af flere parametre
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 Registry, skal have ’service key’ sat til ’dk.nsi.ddsregistry’.
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: I tabellen documentregistry er der konfiguration af hvilke dokument-indeks, der anvendes af servicen.
Installationspakken indeholder, når genereret, filer, der kan anvendes som skabeloner med henblik på at understøtte:
Installationspakken genereres ud fra byggemiljøet med følgende kommando udført fra folderen <packing>/dds/common:
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.
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 |
Skema oprettes ved afvikling af SQL script fra mysql:
<installationspakke>/createWhitelistSchema.sql |
Data source ændres til at pege på whitelist-skema ved at opdatere filen:
<installationspakke>/whitelist-wildfly-ds.xml |
Test note:
I testkonfiguration kan whitelist-databasen opdateres med SQL insert.
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.
DDS Registry anvender opslag i autorisations register data, der skal være tilgængeligt i stamdata i følgende tabel:
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.
DDS Registry anvender SOR data, der skal være tilgængeligt i stamdata i følgende tabeller:
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 |
Test note:
Note: I test setup skal brugeren stamdatauser/password have læseadgang til SOR tabellerne i stamdata.
Skema oprettes ved afvikling af SQL script fra mysql:
<installationspakke>/createDocumentSourcesSchema.sql <installationspakke>/createDocumentRegistry.sql |
Data source ændres til at pege på documentsource-skema ved at opdatere filen:
<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.
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.
Dette afsnit beskriver deploymentprocessen på WildFly 8.2
Ingen.
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.
<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.
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:
WildFly DDSRegistry modul sættes op ved at kopiere filen:
<packing>/ddsservices/ddsregistry/war/src/test/conf/module.xml |
Til:
/pack/wildfly8/modules/nsi/ddsregistry/config/main |
Konfigurerer opsætning af DDS Registry og hvorledes den benytter sig af eksterne services.
En skabelon af denne fil findes i:
<packing>/ddsservices/ddsregistry/war/src/test/conf/DDSRegistry.sproperties |
Filen redigeres inden den placeres på WildFly i:
/pack/wildfly8/modules/nsi/ddsregistry/config/main |
Yderligere information kan findes i driftsvejledningen.
Konfigurerer logopsætningen for DDS Registry.
En skabelon for log4j konfiguration findes i:
<packing>/ddsservices/ddsregistry/war/src/test/conf/ddsregistry.log4j.properties |
Filen redigeres inden den placeres på WildFly i:
/pack/wildfly8/modules/nsi/ddsregistry/config/main |
DDS bruger en managed executor service til at foretage samtidige kald af eksterne services, hvilket gælder både interne NSP services (minlog, samtykke osv.) og andre registrer.
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.
NSP-util anvendes som en del af servicen og skal konfigureres. Eksempel på konfiguration fil findes i
<packing>/ddsservices/ddsregistry/war/src/test/conf/log4j-nspslalog-ddsregistry.properties <packing>/ddsservices/ddsregistry/war/src/test/conf/nspslalog-ddsregistry.properties |
Filerne redigeres inden den placeres på WildFly i:
/pack/wildfly8/modules/nsi/ddsregistry/config/main |
Yderligere information kan findes i driftsvejledningen.
Adgang til DDS Registry styres på CVR-niveau via konfigurationen i whitelist.whitelist_config tabellen. Se også afsnit 3.1.
Konfigurationsfil til det svar, DDS Registry returnerer ved forespørgsel mod dens DKS-snitflade opsættes ved at kopierere:
<packing>/ddsservices/ddsregistry/war/src/test/conf/dksConfiguration.xml |
til:
/pack/wildfly8/modules/nsi/ddsregistry/config/main |
Komponenten kan genstartes ved ”touch” af war-filen på WildFly. Alternativt skal WildFly genstartes ved at køre kommandoen
/etc/init.d/wildfly8 restart |
DDS Registry kan logge kald til følgende logs: En NSP-SLA-log, en audit-log, en applikations log og en performance log.
I default opsætningen logges der udelukkende fejl til applikationsloggen.
Der er mulighed for at tilkoble en perfomance log, der logger tidsmåling af DDS Registry kald til eksterne services.
nsputil-sla-ddsregistry.log dds-audit.log ddsregistry.log ddsregistry-performance.log |
Kald til DDS Registry, hvor værdispringsreglen anvendes, logges til log filen: ddsregistry-consentoverride.log
ddsregistry-consentoverride.log |
Det er muligt at konfigurere placeringen af filerne, samt hvilket niveau de logger på, ved at redigere i ddsregistry.log4j.properties.
Alle logs er beskrevet i driftsvejledningen.
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.
Fjern service komponenter under WildFly’ deployments/ folder:
ddsregistry.war |
Følgende datasources fjernes fra <wildfly>/standalone/configuration/standalone.xml:
Fjern properties filer under DDSRegistry modules folder:
/pack/wildfly8/modules/nsi/ddsregistry/config/main/ |
Oprydning i MySQL database:
Whiteliste: DELETE FROM whitelist.whitelist_config WHERE service = 'dk.nsi.ddsregistry' |
Fjern eventuelt logfiler – se afsnit 4.5.