Page History
...
For Lookup Indeholder domain, JPA klasser til persistering. I Registration er det POJO's.Anchor
Data Access
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.
...
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.
...
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 | ||
|---|---|---|
|
...
|
Løsningen er sikret med IDCard, der enten kan repræsentere en person eller en myndighed. I tilfælde af Lookupid anvendes OIOIDWS.
Ved hver enkelt servicekald verificeres det, at kalderen har den fornødne rolle (myndighed eller medarbejder), og at det medfølgende IDCard overholder levetidskravet til det konkrete kald.
Autentifikationen håndteres af en soap handler, der – hvis autentifikationen er succesfuld – binder IDCard til en threadlocal.
...
| Anchor | ||||
|---|---|---|---|---|
|
Der logges med brug af NSPUtils biblioteket: Et filter opretter en log entitet, der senere beriges med messageID fra Medcom headeren.
SLAloggen gemmes i en tekstfil, og dens udseende kan konfigureres.
...
...
| Anchor | ||
|---|---|---|
|
...
|
Ved alle kald registreres
...
Auditloggen gemmes i en tekstfil, og dens udseende kan konfigureres.Anchor