Introduktion

Her gives en kort beskrivelse af dataflow mellem register og Datafordeleren samt de tekniske valideringer der gennemføres som en del af flowet. Efterfølgende beskrives flow fra Datafordeler til anvender.

Datafordeleren gennemfører ikke nogen forretningsmæssig validering af data. Dette omfatter også at der ikke er nogen validering af bitemporale attributter, ud over at de indholdsmæssigt skal overholde det aftalte date-time format.


Sideinformation




Dataflow fra register til anvender

Det samlede flow er illustreret i nedenstående figur


Beskrivelse af flow for data fra register → Datafordeler → anvender, herunder implementerede kontrol/validerings-mekanismer mellem register og Datafordeler 




Register

Registre udtrækker ændringer fra registres database og skriver disse til en opdateringspakke der sendes til Datafordeleren.

Hver ændring der sendes til Datafordeleren markeres som en af følgende:

  • Update: Angiver at det er en eksisterende instans på Datafordeleren der skal opdateres. Vil typisk være lig med en række i Datafordelerens database.
    Det bemærkes her, at ved opdatering af bitemporale objekter sker der både en ”Update” og en "Insert”. Dvs ”Update” af eksisterende række hvor registreringtil sættes og ”Insert” af en ny række med de nye dataværdier.
  • Insert: Angiver at der skal indsættes en ny instans i Datafordelerens database. Vil typisk være lig med en ny række.
  • Delete: Angiver at en eksisterende instans på Datafordeleren skal slettes. Dette gøres som en softdelete, som er en Datafordelerfunktionailtet, hvor en række markeres som slettet og ikke længere kan ses eller tilgås af anvendere i tjenester. 

Når alle ændringer der skal sendes til Datafordeleren er udtrukket, samles disse i en opdateringspakke. Hver opdateringspakke tildeles et sekvensnummer, dvs. et nummer fra en fortløbende nummerserie der er aftalt mellem Register og Datafordeleren. Det er gennem sekvensnummer at Register angiver hvilken rækkefølge opdateringspakker indlæses på Datafordeleren.

Afslutningsvis sendes opdateringspakke til Datafordeleren. Teknisk sker dette gennem en SOAP eller SFTP-snitflade udstillet af Datafordeleren. På snitfladen anvendes altid XML.

Kort opsummeret sker følgende, jf. ovenstående:

  1. Register udtrækker ændringer og angiver type på dataændring
  2. Register genererer opdateringspakke med næste sekvensnummer
  3. Register sender opdateringspakke til Datafordeleren

Når Datafordeleren har modtaget en opdateringspakke indlæses data først i Master Load databasen og ved succesfuld indlæsning, kopieres data til Master Publish-databasen. Det er fra Master Publish-databasen at tjenester udstillet på Datafordeleren henter data.

Totalindlæsninger håndteres principielt på samme måde, dog med den forskel at alle data slettes fysisk i tabellerne både i Master Load og Master Publish databaserne, hvorved alle data håndteres som Insert. 





Indlæsningsflow for Datafordeleren


Når Datafordeleren har modtaget en opdateringspakke, gennemføres følgende før og under indlæsning af data i Master Load.

  1. Datafordeleren registrerer opdateringspakken som klar til indlæsning og flytter til arbejdsfolder
  2. Opdateringspakkens sekvensnummer valideres (er det næste pakke der skal indlæses)
  3. Der gennemføres skemavalidering af hele opdateringspakken
  4. Datafordeleren starter en transaktion, der favner følgende
    1. Master Load-databasen opdateres med data fra opdateringspakke. Hver række påføres et Datafordeler opdateringstidspunkt
    2. Kontrol af enkeltopdateringer (gælder ikke alle registre) 
      1. Ændringstype ”Insert”: Hvis der allerede findes en række, fejler indlæsning
      2. Ændringstype ”Update”: Hvis række ikke findes, dvs. der ikke kan gennemføres en opdatering fejler indlæsning
      3. Ændringstype ”Delete”: Hvis række ikke findes fejler indlæsning (soft-delete)
    3. Korrektion af fejl
      1. Fejl løses typisk ved at opdateringspakken tilrettes af register og fremsendes på ny med samme sekvensnummer (bemærk af andre opdateringer med nyere sekvensnummer afventer genfremsendelse af opdateringspakke)
      2. Registre kan også vælge at anvende en funktionalitet i Datafordeleren, der kaldes Upserts, hvorved af en række fejlscenarier håndteres af Datafordeleren under indlæsning. Upsert har følgende funktionalitet:
        1. Insert-fejl. Situationer hvor række findes i forvejen og insert derfor fejler, håndteres ved at Insert konverteres til en opdatering (Update)
        2. Update-fejl: Situationer hvor der forsøges opdateret en række der ikke findes, håndteres ved at opdateringen konverteres til en oprettelse (Insert)
    4. Når alle data er indlæst i Master Load-databasen, kopierer data til Master Publish-databasen
    5. Indlæsningsjob markeres færdig
    6. Sekvensnummer inkrementeres så næste opdateringspakke kan indlæses
  5. Transaktionen sluttes og alle ændringer commites i databaserne