Page History
...
- Forespørgsel på logninger til borger opslag.
- Forespørgsel på logninger til medhjælpslog.
Lookup services findes således i 2 sikkerhedsvarianter
- DGWS (Den Gode WebService) - til sundhedsfaglige personale
- OIOIDWS - til borgeren
Nedenfor vises den overordnede arkitektur.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
En sundhedsfaglig person anvender en løsning som foretager en registrering i MinLog2:
. Data valideres og formateres for at blive afleveret til et Kafka cluster. En eller flere MinLog2 consumere læser fra Kafka og indsætter i databasen.
Borgeren anvender feks. sundhed.dk til at se egen log og det gøres via forespørgsler til Lookup der læser fra databasen.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Lookup services findes i 2 sikkerhedsvarianter
...
Af figuren nedenfor fremgår desuden, at MinLogs registreringsservice udstilles på dNSP'erne (foruden på cNSP). Via Kafka flyttes data til cNSP, og skrives i MinLog2-databasen. Fra cNSP udstilles MinLog2 lookup-services til hhv. borgeropslag og til medhjælpsloggen.
...
Snitflader
MinLog2 løsningen håndterer både MinLog2 og MinLog1 formaterne.
...
Udover MinLog2's egen database, er løsningen afhængig af stamdatamodulets databaser, til berigelse af logdata ved Lookup. Principperne for anvendelse af stamdata fra stamdatamodulet afviges dermed, idet der ikke anvendes enkeltopslags- services eller kopiregisterservices. Dette er dog accepteret i MinLog 2-sammenhæng.
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/cc47730d-040d-4f3f-8024-32441c1e2e6d.html" name="test" height="740" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Komponenter
Løsningen er designet som en web applikation opdelt i følgende struktur jee bestående af henholdsvis lookup og registration applikationerne, consumer, producer og shared.
├── jeeservice
│ ├── lookup
│ │ ├── lookup-core
│ │ ├── lookup-ear
│ │ ├── lookup-idws
│ │ ├── lookup-minlog1-ws
│ │ └── lookup-ws
│ ├── registration
│ │ ├── registration-core
│ │ ├── registration-war
│ │ ├── registration-minlog1-ws
│ │ └── registration-ws
├── shared
│ ├── shared-configuration
│ ├── shared-db
│ ├── shared-domain-api
│ ├── shared-test
│ ├── shared-test-idws
│ └── shared-ws
├── Consumer
└── Producer
...
Service
Er opdelt i lookup og registration. Navnet JEE antyder, at der er tale om en JEE baseret applikation. MinLog er lavet som en web applikation - ikke jee - navnet er bibeholdt af historiske årsager.
Som det fremgår er der flere webservices i modulerne lookup og regstration registration - de deler deres kode i xxxx-core. Modulerne med postfix "-ws" indeholder selve implementeringen af webservicens operationer. Modulerne registration-war og lookup-ear er udelukkende holdere af deployment information samt initialiseringskode til applikationerne.
...
dk.nsi.minlog2.registration.webservice.RegisterServiceImpl implements RegisterservicePort
dk.nsi.minlog2.registration.webservice.RegisterServiceImpl implements Service (Minlog1)
dk.nsi.minlog2.lookupid.LookupidImpl implements LookupidServicePortType
dk.nsi.minlog2.lookup.webservice.LookupServiceImpl implements LookupServicePort dk.nsi.minlog2.lookup.webservice.LookupServiceImpl implements Minlog (Minlog1)
I forbindelse med deployment skal man være opmærksom på at subsystemerne i Jboss Wildfly til logning og webservices er slået fra - for at opnår den fulde kontrol over stakken.
...
For at forhindre at der kan forekomme dublikater ved insert, laves der en SHA256 hash over en række værdier, af databasen.
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/fd898793-0995-4db2-ac58-29d71c50fcf3.html" name="test" height="260" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Ikke funktionelle krav
Sikkerhed
...