Page History
...
Design mål og beslutninger
Design mål
The system must be designed in alignment with the goals and priorities stated in Table 1. The priority of each goal is indicated with a score of 1 to 5 where 5 indicates the highest priority.
Systemet skal designes i overensstemmelse med de mål og prioriteter, der er angivet i tabel 1. Prioriteten for hvert mål er angivet med en score på 1 til 5, hvor 5 angiver den højeste prioritet.
| Mål | Prioritet | Kommentar |
|---|---|---|
Korrekthed | 5 | Den overordnede funktionalitet vedrører patientsikkerhed og er underlagt en omfattende juridisk ramme, som det er vigtigt at overholde |
| Pålidelighed | 2 | Hvis systemet ikke kan udføre sin opgave, skal fejlen videresendes. |
| Anvendelighed | 1 | Der er ingen brugergrænseflade. |
Sikkerhed | 4 | Systemet håndterer patient data. |
| Ydelse | 3 | De specifikke ydelseskrav er ikke kendt, da systemets belastning er ukendt, men ydeevne er blevet prioriteret, da systemet kaldes fra en del anvendersystemer og systemets ydelse vil derfor påvirke de kalende systemer. |
| Vedligeholdelse | 4 | Løsningen vil helt sikkert blive genstand for yderligere udvikling. Omkostningerne ved dette skal holdes lave. |
Fleksibilitet | 1 | Løsningen består af webservices. Dette resulterer i den nødvendige fleksibilitet i det samlede system. De enkelte services behøver ikke at være fleksible. |
Testbarhed | 3 | Løsningen skal kunne testes gennem automatiske tests, da der ikke er nogen brugergrænseflade. |
Portabilitet | 1 | De grundlæggende teknologiske beslutninger er taget på forhånd. |
Genbrugelighed | 2 | Komponenterne skal bruges gennem delegering - ikke ved genbrug af kode. |
Interoperabilitet | ||
| Goal | Priority | Comment |
Correctness | 5 | The overall functionality concerns patient safety and is subject to an extensive legal framework that is important to obey |
Reliability | 2 | If the system cannot performs its task, the error must be forwarded. |
Usability | 1 | No user interface |
Security | 4 | The system handles patient data |
Performance | 3 | The specific performance requirements are not known as the strain of the system is unknown, but performance has been prioritized, as the system is part of calls to other systems |
Maintainability | 4 | The solution will certainly be subject to further development. The cost of this must be kept low |
Flexibility | 1 | The solution consists of Web services. This results in the necessary flexibility in the overall system. The individual services do not have to be flexible. |
Testability | 3 | The solution has to be testable through automatic tests, as there is no user interface. |
Portability | 1 | The fundamental technology decisions has been made. |
Reusability | 2 | The components must be used through delegation – not by code reuse. |
Interoperability | 2 | The desired interoperability is obtained through Web service interfaces |
Table Tabel 1: Design goals and their mutual importancemål og deres indbyrdes prioritering
Design
...
beslutninger
Dette afsnit indeholder vigtige designbeslutninger og deres begrundelse. Hvis det er relevant, præsenteres afviste designs også med begrundelsen for deres afvisning.
Belslutning angående logning
Fejlr og debug logging er implementeret via log4j der er konfigureret for hvert service. Der laves en logfil pr. service.
I denne log registreres exceptions og stacktraces. Hvis konfigurationen er indstillet til 'debug'-niveau, logges der også flowID ved ind- / udgang af servicemetoderne.
Debuglog er blevet implementeret for at lette fejlfinding, således at flowID (og følgelig en besked) kan spores mellem serviceopkald
This section holds significant design decisions and their rationale. If relevant, rejected designs are also presented with the rationale for their rejection.
Decision regarding logging
Error and debug logging is implemented using log4j that is configured for each individual service. As a rule, one log file is created per service.
In this log, exceptions and stack traces for possible errors are logged. If the configuration is set to ’debug’-level, a trace of flowID on entry/exit of the service methods is additionally logged.
The debug logging has been implemented to facilitate troubleshooting, such that a flowID (and consequently a message) can be traced between service calls.
Service Level Agreement (SLA) logging is supported with the aid of the (SLA) logging functionality in NSPUtil.
The SLA-logging logs all calls to the two services and consists among other things of:
Time of call, name of the invoked method, temporal length of call, ID of the message that is processed.
Audit logging also takes place through log4j, for the category ”audit”. Audit logging must log
logning håndteres via SLALOgning i NSPUtil biblioteket.
SLA-logging logger alle kald til de to service og består blandt andet af:
Tidspunkt, navn på den kaldte metode, eksekveringstids samt message ID.
Audit logging sker også via log4j via kategorien ”audit”. Audit logging skal logge
Tid Time (zulu time)
User-Bruger ID
Type of use
The citizen
Company registration number of calling system
SessionID from IDWS Security Context (messageID)
Type of use refers to the method call.
...
Metodekald
borgeren
Anvender systems CVR nummer
SessionID fra IDWS sikkerhedskontekst (messageID)
Beslutning angående konfiguration
The service configuration is performed in two (three for the administration service) different properties files that must be deployed on the Web server somewhere in the application’s classpath.
Servicekonfigurationen udføres i to (tre for MinSpærring Administration) forskellige property filer, der leveres som en del af docker setup.
Changes in the configuration should prompt a reboot of the service, as the configuration is loaded and verified on start-up of the individual services.
For a description of what must be set-up in the configuration, see [Driftsvejledning].
Application configuration
The application is configured in the files ConsentAdministration.properties and ConsentVerification.properties.
All configuration of security and service setup is provided in these files.
Additionally, the location of the log configuration file and the service client configuration is provided.
In this way it is possible to configure logging and client setup independently of the service, e.g. on re-use of the log configuration between services.
Service client configuration
The consent administration service must be able to communicate with the Min Log’-service and the configuration of the service client that is used must also be performed in a configuration file.
The location of this file is provided in the application configuration.
Ændringer i konfigurationen skal medføre en genstart af den container som servicen den kører i da konfiguration indlæses ved opstart.
For beskrivelse af konfigurationen se MinSpærring - Driftsvejledning.
Applikations konfiguration
Applikationen er konfigureret i filerne ConsentAdministration.properties og ConsentVerification.properties.
Al konfiguration af sikkerhed og serviceopsætning findes i disse filer.
Derudover angives placeringen af logkonfigurationsfilen og serviceklientkonfigurationen.
På denne måde er det muligt at konfigurere logning og klientopsætning uafhængigt af tjenesten, f.eks. om genbrug af logkonfigurationen mellem services.
Service klient konfiguration
MinSpærring Administration service skal være i stand til at kommunikere med Min Log'-tjenesten, og konfigurationen af den anvendte serviceklient skal også udføres i en konfigurationsfil.
Placeringen af denne fil findes i applikationskonfigurationen.
Log configurationLog konfiguration
In the log configuration file, error and debug log configuration is provided by stating a provided by stating a log4j-logger property with the name log4j.logger.dk.nsi.
I logkonfigurationsfilen leveres konfiguration af error og debug ved at angive en log4j-logger property with the name med navnet log4j.logger.dk.nsi.
Database configurationkonfiguration
Both consent services must be provided with a data source with the name ’ConsentServiceDS’ that has access to the consent database described in [Data Model].
Begge MinSpærring services skal forsynes med en datasource med navnet 'ConsentServiceDS', der har adgang til den database der er beskrevet i MinSpærring - Data Model.
Both services must have access to a data source with the name ’WhitelistDS’ that is used by whitelist validation of calling systems.
All data sources must support distributed transactions (xa-datasource)Begge tjenester skal have adgang til en datasource med navnet 'WhitelistDS', der bruges af whitelist af anvendersystemer.
Decision concerning Web services
...