1. Indhold
2. Indledning
Dette dokument beskriver, hvordan MinLog2-løsningen bygges og hvad de forskellige moduler indeholder.
Dokumentet kan med fordel læses sammen med dokumentet "arkitektur_design" for overordnet forståelse. Desuden henvises der undervejs til "testvejledning" og "installationsvejledning".
2.1. Læsevejledning
Læseren forventes at have kendskab til National Sundheds-IT's platform NSP, samt generelt kendskab til WildFly applikation server, MariaDB og java.
2.2. Dokumenthistorik
|
Version |
Dato |
Ansvarlig |
Beskrivelse |
| 1.2 | 20-09-2018 | Openminds | Yderligere specifikation i forbindelse med borgerservice |
|
1.1 |
12-12-2017 |
Openminds |
Ny borgerservice |
|
1.0 |
15-06-2017 |
Openminds |
|
2.3. Definitioner og forkortelser
|
Definition |
Beskrivelse |
|
NSP |
Den nationale service platform (inden for sundheds-IT) |
3. Forudsætninger
Udover java (JDK 1.8) og WildFly, så kræver MinLog2 to databaser for at kunne afvikles lokalt
- MinLog2
- Stamdata
4. Byg
MinLog2 er et standard maven projekt og bygges med
|
mvn clean install |
Helt som det er standard fører det til et byg af alle moduler, herunder war-filer som indeholder den kode, der skal deployes.
Maven kan afvikles i de respektive foldere. Som en del af bygget afvikles alle unit-tests. Der er ingen af disse unit-tests, der har afhængigheder til netværk, database eller lignende.
5. Moduler
Der findes to undermoduler under service:
├── lookup
├── registration
5.1. Lookup
Dette modul håndterer opslag udstillet som webservice og der er overvågningservices til rådighed.
Webservicen er beskrevet i en wsdl fil (contract first) og på baggrund af denne dannes java klasser med CXF.
5.2. Lookup-idws
Dette modul håndterer opslag udstillet som webservice og der er overvågningservices til rådighed.
Webservicen er beskrevet i en wsdl fil (contract first) og på baggrund af denne dannes java klasser med CXF. Vær opmærksom på at sikkerhed på denne service er defineret vha. WS-Policy.
5.2.1. Core
Databasekonfiguration er angivet i en persistence unit, der peger på datasource.
Indeholder service (forretningskode) og domain delene.
5.2.2. WS
Indeholder webservice implementeringen.
5.2.3. War
Artifaktet som kan deployes til Wildfly. Find war-filen i target/.
Databasekonfiguration er angivet i en persistence unit, der peger på datasource.
5.3. Shared
Shared ligger i roden af projektet. Den indeholder komponenter, der på den ene eller anden måde er delt mellem registration, lookup og consumer.
Nedenfor beskrives indholdet af de enkelte komponenter.
5.3.1. Shared-configuration
Dette modul gør det muligt at få dannet de filer, der skal være på Wildfly serveren. Indeholder primært filer til opsætning af logning og datasources.
Folderen src/main/environments indeholder miljøspecifik konfiguration af disse filer.
Ved at udpege en af disse, når man bygger, kan man på den måde få danne konfigurationsfiler til et givet miljø.
Eksempel:
|
Byg til test |
Tilret /src/main/environments/test.properties
|
Ønsker man at føje yderligere miljøer til, skal man blot lave en propertyfil hørende til miljøet og udpege den i pom.xml.
De genererede filer kan efterfølgende findes i target/classes.
Dokumentet installationsvejledning indeholder yderligere information om brugen af disse.
5.3.2. Shared-ws
Fælles kode til blandt andet håndtering af sikkerhed, audit, SLA logning og en del utility klasser.
5.3.3. shared-db
Fælles kode til skrivning af log entries til database.
5.3.4. shared-domain-api
Objekter, der udveksles via Kafka.
5.3.5. Shared-test
Dette modul har to formål
- Benyttes til afvikling af integrationtests
- Indeholder kode til dannelse af IDCard (wsse header), dels kode til dannelse og eksekvering af webservicerequests.
Anvendelsen af dette er beskrevet i dokumentet "testvejledning".
5.3.6. Shared-test-idws
Som shared-test anvendes dette modul delse i forbindelse med afviklingen af integrationtests, dels til generering af klient kode og eksekvering af webservicerequests.
Anvendelsen af dette er beskrevet i dokumentet "testvejledning".