Page History
...
Der findes pt 2 implementationer af kald til PersonInformation. Den oprindelige CprExist og den senere PersonInformation.
CprExist
Gennem kald til PersonInformation Service foretages validering af CPR nummer. CPR valideringen kan køre i følgende tre modes:
- OFF: Der foretages ikke yderligere verifikation af CPRnummeret udover simpel validering af længde. PersonInformation kaldes ikke
- WARNING: PersonInformation service kaldes. Hvis denne service svarer, at CPR nummeret ikke findes, eller er inaktivt, så audit logges denne information.
- REJECT: PersonInformation service kaldes. Svaret fra denne er en hård validering dvs. kaldet til ODR fejler, hvis PersonInformation service ikke kender CPR nummeret eller det er inaktivt.
PersonInformation Service benyttes ligeledes til validering af alder. Denne validering foretages altid.
PersonInformation
...
Digital Post
...
Gliffy Diagram displayName ODR-Design v3 name ODR-Design v3 pagePin 10
| displayName | ODR-Design v3 |
|---|---|
| name | ODR-Design v3 |
| pagePin | 10 |
I guide til udviklere findes der diagrammeret diagram, som kan hjælpe med at forstå den konkret konkrete implementation af forretningslogikken til notifikationsjobbet herunder status opdateringen.
Datamodel
Forretningsservice
Da det kun er borgeren selv der har adgang til at oprette og ændre i vedkommendes organdonorregistrering, kan datamodellen for servicen realiseres relativt simpelt, idet at det ikke er nødvendigt at lagre information omkring hvem der har oprettet / opdateret data.
...
v2_person_simplified er et view der anvendes til at slå op i cpr-stamdata (cpr-registry)
Operations
Afsendelse af notifikationer gør brug af 2 database tabeller, for at kunne holde styr på, hvilken dag, der er håndteret samt, hvilke personer, der har fået tilsendt post på dagen. De detaljerede schema for disse er:
NotificationDate
| FeltNavn | Optional | Unik nøgle | Datatype | Beskrivelse |
| NotificationDatePID | Nej | Ja | INT(11) | Tabellen unikke nøgle, auto inc |
| Status | Nej | Nej | VARCHAR(50) | Angiver hvilken status den aktuelle dato den enkelte har i flowet at få sine notifkationer sent Kan indholde værdierne: Pending, InProgress, Sent, Completed, Error, Locked Se iøvrigt se figur i guide til udviklere. |
| LatestDate | Nej | Ja | Date | Den dato som behandles. Notifikationsjobbet indsætter en ny dato, når det er kørt færdigt på den gamle. |
| CreatedDateTime | Nej | Nej | DATETIME | Sættes automatisk når recorden oprettes |
| ModifiedDateTime | Nej | Nej | DATETIME | Opdateres automatisk når recorden opdateres |
NotificationPerson
| FeltNavn | Optional | Unik nøgle | Datatype | Beskrivelse |
| NotificationPersonPID | Nej | Ja | INT(11) | Tabellen unikke nøgle, auto inc |
| NotificationDatePID | Nej | Nej | INT(11) | Fremmednøgle til NatificationDate |
| Status | Nej | Nej | VARCHAR(50) | Angiver hvilken status den enkelte record har i flowet at blive sent Kan indholde værdierne: Pending, InProgress, Sent, Completed, Error Se iøvrigt se figur i guide til udviklere. |
| Type | Nej | Ja | VARCHAR(50) | Unik nøgle sammen med PersonIdentifier |
| PersonIdentifier | Nej | Ja | VARCHAR(30) | Unik nøgle sammen med Type |
| SentAtDateTime | Nej | Nej | DATETIME | Angiver det tidspunkt notifikationen er forsøgt sendt med digital post |
| ErrorMessage | Nej | Nej | VARCHAR(2000) | Hvis der kom en fejl tilbage ved afsendelse af digital post gemmes den her. Status sættes samtidig til Error |
| CreatedDateTime | Nej | Nej | DATETIME | Sættes automatisk når recorden oprettes |
| ModifiedDateTime | Nej | Nej | DATETIME | Opdateres automatisk når recorden opdateres |
Baggrundsjob (Slettejob m.m)
...