Page History
| Anchor | ||
|---|---|---|
|
...
|
...
| Anchor | ||
|---|---|---|
|
...
|
| Anchor | ||||
|---|---|---|---|---|
|
Minlog 2
Design og arkitektur
Indledning
Dokumenthistorik
Formål
Overblik
Snitflader
Komponenter
Webservice
Sikkerhed
Statuskomponent
Forretningslag
Databasedesign
Caching
Ikke funktionelle krav
Sikkerhed
SLA logning
Audit logning
| Anchor | ||||
|---|---|---|---|---|
|
...
Indledning
| Anchor |
|---|
...
|
...
|
Version | Dato | Ansvarlig | Beskrivelse |
1.1 | 12-12-2017 | Openminds | Ny borgerservice |
1.0 | 14-06-2017 | Openminds |
...
...
| Anchor | ||||
|---|---|---|---|---|
|
Dette dokument giver et overblik over MinLog2 applikationerne med fokus på design og arkitektur.
Dokumentet giver et overblik over løsningens snitflader samt den interne struktur. Desuden indeholder det en beskrivelse af håndtering af ikke funktionelle krav.Anchor
| Anchor | ||||
|---|---|---|---|---|
|
...
Overblik
MinLog2 er delt i to applikationer, Registration og Lookup.
Registration tilbyder services til.
...
- Forespørgsel på logninger til borger opslag.
- Forespørgsel på logninger til medhjælpslog.
Forretningsdata persisteres i en relationel database.
Lookup services findes i 2 sikkerhedsvarianter
- DGWS
- OIOIDWS
...
| Anchor | ||||
|---|---|---|---|---|
|
Løsningen har en ekstern snitflade, der udstiller de ovenfor nævnte services som webservices.
Der er ikke afhængigheder til andre services, men til komponenter til håndtering af autentifikation (SEAL) og SLA logning (NSPUtils).
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.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
En servlet, der fortælle hvilken version af løsningen, der er den aktuelle.
| Anchor | ||||
|---|---|---|---|---|
|
...
Indeholder logikken til insert af data fra Registration samt forespørgsel fra Lookup.
Registration, gør udelukkende brug af JPA til at håndtere forbindelsen til databasen. Alt insert sker via standard preparedStatements. Dette er gjort med henblik på af holde JPA ude af domain pakken, da direkte insert i databasen, fra servicen, er en midlertidig løsning.
Lookup, bruger JPA dels til forbindelsen, men også mapning til domain. Dog er alle queries defineret som rå SQL, i koden, således at intet bliver autogeneret. Dette er gjort for at imødekomme tidligere erfaringer på platformen, om at autogeneret SQL fra JPA kan blive unødig kompleks og forringe performance.
Afhængigheder mellem komponenter.
| Anchor | ||||
|---|---|---|---|---|
|
Log events, består af to dele. En source og en destination. Destination indeholder alt information om logningen, mens source er kaldekæden gennem systemerne. Se Løsningsbeskrivelsen for nærmere beskrivelse. Disse gemmes i hver sin tabel
| Anchor | ||||
|---|---|---|---|---|
|
For at forhindre at der kan forekomme dublikater ved insert, laves der en SHA256 hash over en række værdier, af databasen.
| Anchor | ||||
|---|---|---|---|---|
|
I MinLog2-Lookup er der en feature der kan opdele logninger i en række forskellige grupper. Det er et krav at der er mulighed for at bruge paginering ved disse grupper. Det giver problemer da grupperne nødvendigvis skal dannes på baggrund af hele søge resultatet og ikke blot over en delmængde. Hvis det skulle være muligt er man nød til at søge hele resultatet frem hver gang der forespørges på en ny side.
For at imødekomme begge krav, er der anvendt caching(ehcache) i Lookup. Når data er blevet grupperet bliver det cached. Der anvendes en nøgle generet ud fra de forskellige parametere i forespørgselen.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...