1005.17.24 Konverteringsbeslutningslog for Joblog

Siden bruges til dokumentation af beslutninger vedrørende konvertering af Joblog-data fra Classic DFDG til Jobsearch.

 

ID

Spørgsmål

Beslutning

Dato

ID

Spørgsmål

Beslutning

Dato

1

Konverteringen gennemføres til SIT-testmiljøerne i 2024-3? Jobsearch flyttes til SIT i 2024-4.

Søby: Indikativt, konvertering gennemføres på Kyndryl og så taxa i prod (backup/restore).

TEMA! Løftes med STAR

2024-06-21

2

Mapningsdokument kurant? Opdateres hvornår?

Modtaget.

 

3

Historik? Der er en kolonne i CoreEntryHistory, ChangeTypeId, der ikke medtages til det nye domæne.

LSS’en viser den seneste version (også når der alene er data i historik-tabellen) af en log med historik, dog ikke rækker med ChangeTypeId=3, slettet. Se eksempel nedenfor. I den konverterede fact-tabel er der ingen CUD-kolonne, så hvordan ved man om Jobloggen er slettet (slettemarkeret) af borgeren/andre? Samme observation i alle sattelitterne. 3’ere optræder kun i Document og CoreEntry

DeletedDateTIme i metadata, rækken skal i history.

2024-06-21

4

Dokumenter? Hvad med de fysiske dokumenter i DocumentRepository?Taxamodel. Se også spm 1.

Etableret.

2024-06-21

5

Index-tabeller - skal de konverteres (ikke temporale)? Tabellerne får data fra batchjobbet DFDG-JL-JoblogFullIndexBuilder

Beslutning: skal ikke konverteres

21/6-2024

6

UnemploymentFundBranchCode opdateres i ExternalData.UnemployementFund

BI opdaterer tabellen.

2024-06-21

7

MetadataJSON i version 1? Vi plejer at konvertere i Version 0.

Vi sætter version 0

21/6-2024

8

OptionalColumnsRemoved? Data om GDPR-sletninger?

Som jeg forstår det er slettereglen 6 år, men som eksemplet nedenfor viser, så indeholder History-tabellen ældre rækker (med slettet indhold), der vises i LSS’en.

Næppe relevant.

2024-06-21

9

Som datamodellen er implementeret kan fact-tabellen kun holde den seneste version af en joblog med identifier som PK. Er dette korrekt? LSS’en viser versioner af Joblogs.

Seneste version i fact, resten i historik

2024-06-21

10

Tekstlængde, comment, reduktion? “Måske”?

?

2024-06-21

11

t15, ikke t11. Problem med deploy i t15.

 

2024-06-21

12

I må meget gerne tage stilling til hvad der skal gøres med konvertering af metadata for dokumenter, der er slettet i DocumentRepository, men hvor der evt stadig er referencer i metadata. Daniel har været med til rehab, måske skal det være på samme måde?

 

 

13

RowValidFrom og RowValidFrom konstrueres.

Se nedenfor.

 

 

14

Dokumenter markeret som slettede af brugeren i DocumentHistory med StatusTypeIdentifier=2 får slettet referencen til CoreEntry. Logikken er at dokumentets metadata skrives til History med type=1 og derefter oprettes en række i History med Type=2 og ellers ingen metadata på rækken.

I lyset af findings omkring brugen af type 2 og 3 i StatusTypeIdentifier betyder det at History løbes igennem for sletninger og arver metadata fra rækken med type=1, hvis den findes i History ved konvertering. Da rækken er slettet fra fact-tabellen mister vi CreatedDate, da både type 1 og type 2 får slettet datoerne fra fact-tabellen, når de skrives til History. 2 og 3 konverteres ikke fra Fact-tabellen.

1 konverteres fra Fact. Få nye registreringer er uden fysiske dokumenter, men det skyldes nok et batchjob, der sletter på dato. Konverteres.

1 og 2 konverteres fra History. 2 kun hvis der findes en korresponderende 1’er, ellers kan rækken ikke knyttes til en borger.

 

15

Document.DeletedDate er senest anvendt i 2019 med FileIdentifier “00000000-0000-0000-0000-000000000000” og er <> NULL på 103 rækker. Seneste opdatering med valid FileIdentifier er fra 2016. Kolonnen konverteres, men bruges den?

 

 

16

StatusTypeIdentifier. Kun værdien 1, der benyttes i fact siden 2020. 1, 2 i History. 3 kun i fact, men ikke siden 2020

Se ID 14 og ID17 for værdien 3.

 

17

Documents fact-tabellen indeholder 19 mio. rækker, hvor det fysiske dokument alle er slettet. Gamle slettemarkerede rækker fra før 1/7 2020 med type=3,

Hvis konvertering - flyttes til historik?

 

18

Usikkerhed omkring dokumenthåndtering i STAR. BI pauser med udvikling og test indtil vi hører nærmere.

 

 

19

JobSearch.ExternalData.Enrollment har CreatedDateTime og UpdatedDateTime som not null. Det har kilden ikke. Skal vi sætte de to kolonner til getdate() hvis de er null i kilden?

@Thomas Søby Ingwersen (Visma) ?

2024-08-28

20

JobSearch.ExternalData.Enrollment og JobSearch.ExternalData.Absence loades med værdier fra fact-delen i VisiteringOgStatus, og ikke noget fra History-delen.

 

2024-08-28

21

Kan I undvære isLatest i JobSearch.ExternalData.Enrollment?

 

2024-08-28

Spørgsmål 3

Nedenstående borger har alene Joblog-rækker i CoreEntryHistory.

15334353 bærer oplysningen om sletningen, der vises på den oprindelige version, 15334120.

 

Joblog_LSS_HistoryOnly.jpg

 

Joblog_CoreEntryHistory.jpg

Spørgsmål 13

Der er flere problemstillinger for RowValidFrom og RowValidTo med udgangspunkt i de originale datakilder.

CreatedDate er ikke fastholdt i historiske versioner, men fastholdes på fact-rækken.

Når rækker blev opdateret, så opdaterede man Fact-rækken først og skrev derefter rækken til History, men med Timestamps. Det vil sige at UpdatedDate er ældre på rækken i fact-tabellen end på den række, der blev skrevet til historik-tabellen. From og To bygges som følger:

UpdatedDate vælges som RowValidFrom på Fact-rækken og RowValidTo på den seneste række i History. Dermed overskriver vi UpdatedDate på den seneste række i History.

Dette sætter sig ned igennem versionerne til den ældste, der får sat RowValidFrom som CreatedDate

Se nedenfor:

Created

Updated

ChangeId

RowValidFrom

RowValidTo

2019-03-10 08:34:25.4133333

2019-04-01 08:16:18.3066667

Fact

2019-04-01 08:16:18.3066667

9999-12-31 23:59:59.9999999

2019-03-10 08:34:25.4133333

2019-04-01 08:16:18.3364495

Opdateret History

2019-03-11 10:07:14.8598133

2019-04-01 08:16:18.3066667

2019-03-10 08:34:25.4133333

2019-03-11 10:07:14.8598133

Opdateret History

2019-03-10 08:34:25.8190942

2019-03-11 10:07:14.8598133

2019-03-10 08:34:25.4133333

2019-03-10 08:34:25.8190942

Oprettet History

2019-03-10 08:34:25.4133333

2019-03-10 08:34:25.8190942

For slettede rækker uden rækker i Fact-tabellen slette-markeres rækken i MetadataJSON og rækkerne i History-tabellen dateres som følger.

Created

Updated

 

 

 

RowFrom

RowTo

NULL

2022-12-30 11:07:24.0340325

 

Slettet History

 

2022-12-30 11:07:24.0340325

2022-12-30 11:07:24.0340325

NULL

2022-12-05 13:27:25.7194658

 

Oprettet History

 

2022-12-05 13:27:25.7194658

2022-12-30 11:07:24.0340325