Komponenter
Dette dokument dækker følgende komponenter på NSP:
Dokumentregistrerings- og oprettelsesservice
Type: Webservice
Filnavn: dros.war
Url: <serverurl>/dros
Servicecheckurl: <serverurl>/drs/status
Versionurl: <serverurl>/dros/health returnerer en json struktur med denne
Konfiguration
Servicekonfiguration
Grundlæggende konfiguration foregår ved redigering i filen dros.properties, der placeres i følgende WildFly modul:
/pack/wildfly8/modules/sds/dros/configuration/main/
Moduldefinitionen er at finde i sourcekoden til dros under:
/dros-war/etc/modules/sds/dros/configuration/main/module.xml
I filen skal følgende properties være definerede:
Property | Beskrivelse |
dros.url.prefix | URL prefix der indsættes i wsdl'er og bruges af dks-servlet. |
| dros.app.name | Anvendes af dks-servlet |
iti41.service.endpoint | Endpoint på ITI41-backend. |
| iti41.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
| iti41.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
| iti42.service.endpoint | Endpoint på ITI42-backend. |
| iti42.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
| iti42.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
iti57.service.endpoint | Endpoint på ITI57-backend. |
| iti57.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
| iti57.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
| iti61.service.endpoint | Endpoint på ITI61-backend. |
| iti61.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
| iti61.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
dros.backend.failure.threshold | Tærskel for, hvor mange gang i træk et kald til en backend må fejle, før denne backend betragtes som 'død' af status-siden. |
| dros.backend.failure.interval.minutes | Angiver antal minutter hvorefter fejlkald 'forældes'. Dermed er det kun fejlkald, der er nyere end dette, der medregnes, når det vurderes om backenden fejler. |
| cprexists.validationlevel | Valideringsniveau for CPR validering Eksempel: WARNING, REJECT, OFF |
| cprexists.url | URL for CPR exist service Eksempel: http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-cprexists |
| cprexists.maxTotalConnections | Konfiguration af client pool til kald af CPRExists service Default: 200 |
| cprexists.defaultMaxConnectionsPerRoute | Konfiguration af client pool til kald af CPRExists service Default: 20 |
| handled.type.codes | Angiver en liste af, hvilke type codes DROS håndterer. Er listen tom (property findes, men ingen værdi efter =) accepteres alle type codes. Eksempel på liste: 39289-4,39290-2,53576-5,52460-3,81215-6 Default: tom liste |
log4j konfiguration
Log4j konfiguration findes i samme wildfly modul som servicekonfigurationen
Se yderligere opsætning i installationsvejledningen.
Overvågning
DROS udstiller en overvågningsside, som findes i listen af komponenter i afsnit 2.
Fortolkning af HTML overvågningsside
DROS-overvågningssiden returnerer enten:
- HTTP 200, hvis servicen i øjeblikket kører fint.
- HTTP 203, hvis der er opstået en fejl der kræver indgriben.
- HTTP 500, hvis der er opstået en fejl der kræver indgriben.
Overvågningstyper
Det overvåges for hver backend, om kaldene til backenden går galt. Det kan konfigureres, hvor mange kald i træk der må gå galt, før en backend betragtes som 'død'.
Eksempler på status-sider
200 OK
200 OK
---------------------------------------
STATUS
ITI41 backend : "0/50 fejl" ITI42 backend : "0/50 fejl" ITI57 backend : "0/50 fejl" ITI61 backend : "0/50 fejl" CprExistsServiceClient : "0/50 fejl"
Whitelisting Database : "ok"
Det fremgår for hver backend, om kaldene til den går godt eller ej.
203 Non-authoritative Information
203 Non-authoritative Information
---------------------------------------
STATUS
ITI41 backend : "0/50 fejl" ITI42 backend : "0/50 fejl" ITI57 backend : "0/50 fejl" ITI61 backend : "0/50 fejl" CprExistsServiceClient : "55/50 fejl"
Whitelisting Database : "ok"
Hvis kaldene til cprexists backend ikke kan udføres, så returneres statuskode 203 (indenfor failure threshold, som kan sættes op som en konfigurationsparameter).
500 Internal Server Error
500 Internal Server Error
---------------------------------------
STATUS
ITI41 backend : "0/50 fejl" ITI42 backend : "0/50 fejl" ITI57 backend : "55/50 fejl" ITI61 backend : "0/50 fejl" CprExistsServiceClient : "0/50 fejl"
Whitelisting Database : "ok"
Hvis kaldene til een af ITI backends ikke kan udføres, så returneres statuskode 500 (indenfor failure threshold, som kan sættes op som en konfigurationsparameter).
Det samme gælder, hvis der ikke kan oprettes forbindelse til databasen (ingen failure threshold).
Auditlogning
Hvert servicekald medfører en ny indgang i auditloggen, som er udfyldt som følger:
* Component: DROS/<operation>, hvor <operation> er navnet på den operation der kaldes, f.eks. ProvideAndRegisterDocumentSetB.
* Context: Udfyldes med DocumentId. Hvis requestet indeholder flere dokumenter, oprettes en context for hvert dokument.
For hver context skrives følgende informationer
| Felt | Type | Indhold |
|---|---|---|
| DocumentId | RegularPersonalInformation | DokumentId'et. |
| DocumentType | RegularPersonalInformation | Dokumentets TypeCode |
| CitizenId | RegularPersonalInformation | PatientId, som dokumentet omhandler. |
| FormatCode | RegularPersonalInformation | FormatCode |
| SubmissionSet | RegularPersonalInformation | UniqueId fra SubmissionSet i request. |
| AssociationSourceId | RegularPersonalInformation | SourceId fra association, hvis dokumentet er enten source eller target på association. |
| AssociationTargetId | RegularPersonalInformation | TargetId fra association, hvis dokumentet er enten source eller target på association. |
| AssociationType | RegularPersonalInformation | AssociationType fra association, hvis dokumentet er enten source eller target på association. Den fulde URI logges. |
| AuthorInstitutionAssigningAuthority | RegularPersonalInformation | AssigningAuthority fra authorInstitution for dokumentet. |
| AuthorInstitutionId | RegularPersonalInformation | Id fra authorInstitution for dokumentet |
Nedenfor ses eksempler fra auditloggen ved kald af de forskellige snitflader.
Hvis CPR validering kører i WARNING mode, så vil ugyldige (ifølge CPRExits service) CPR numre give anledning til en linje i auditloggen. Logninger af denne type ser således ud:
Hvis XDS validering kører i WARNING-mode, så vil eventuelle valideringsfejl blive skrevet til auditloggen. Dette ser ud som vist nedenfor:
Valideringsfejlene logges under contexten '5313439413729618055.1497722748872510081.1633347017540', som er entryuuid på requestets SubmissionSet. Dette er valgt, fordi valideringslibrary'et pt. ikke giver mulighed for relatere de individuelle dokumenter til deres valideringsfejl.
Logning når fejl
Hvis servicesvaret indeholder fejl, logges de på følgende måde. Hvis et RequestId mangler, genereres et nyt RequestId.
Følgende er et eksempel på et ITI-42 kald med, fejl.
Whitelisting af anvendere
De enkelte anvendere skal whitelistes til at bruge DROS. Der findes en tabel whitelist til dette formål.
Det er heri muligt at angive enten et CVR nummer eller oces3 UUID. Sidstnævnte whitelister et specifikt certifikat.
Organisationens CVR nummer whitelistes ved følgende SQL:
|
Certifikatets UUID id whitelistes ved følgende SQL:
|
Note feltet kan f.eks. anvendes til at referere en supportsag eller lignende for sporingshensyn. Det er ikke obligatorisk som de øvrige felter.