Gå til innhold

Kildesystemer — ERS og Mimir⚓︎

Kai leser saksdata fra et kjede av oppstrøms-systemer. Å forstå hvordan disse oppfører seg — særlig hvor ofte data endrer seg — avgjør hvordan Kai henter og synkroniserer dem.

flowchart LR
    ERS[(ERS<br/>kildesystem · sannhetskilde)] -- full DB-dump, 1×/døgn --> ETL[Mimir ETL]
    ETL -- bygger --> GOLD[(production.gold.*<br/>analytiske tabeller)]
    GOLD -- Databricks SQL · statement-polling --> KAI[Kai]

ERS — kildesystemet⚓︎

ERS er Enovas saksbehandlingssystem og sannhetskilden for saker, søknader og vurderinger. Kai snakker ikke direkte med ERS — ERS ligger oppstrøms for dataplattformen.

  • Eierskap: ERS er en egen bounded context Kai ikke eier. Kai konsumerer en nedstrøms, read-only kopi.
  • Oppdatering: ERS dumper hele databasen sin én gang i døgnet. Det finnes ikke noe spørrbart live-API mot ERS for Kai.

Mimir — dataplattformen⚓︎

Mimir er Enovas dataplattform på Databricks. En ETL-pipeline bygger analytiske gold-tabeller fra ERS-dumpen.

  • Tabeller: production.gold.ers_* (saksdata) og production.gold.masterdata_* (referansedata, bl.a. virkemidler). Disse gold-tabellene er ERS-kontekstens publiserte språk.
  • Tilgang: Databricks SQL Warehouse via Statements API. Spørringer er asynkrone — kjør statement, poll status til SUCCEEDED, les resultat (mønsteret i MimirCaseLookupAdapter).
  • Autentisering: DefaultAzureCredential → Databricks-token.
  • Skjemareferanse: hver gold-tabell/kolonne er dokumentert i søsterrepoet enova/mimir (discovery/out/ers.md, discovery/out/masterdata.md). Slå opp eksakte kolonnenavn/-typer der.

Den viktige konsekvensen: data er statisk gjennom døgnet⚓︎

Én dump per døgn → gold er immutabel resten av døgnet

ERS dumper 1×/døgn. Mimirs ETL bygger gold-tabellene fra dumpen tidlig på morgenen. Etter at ETL-en er ferdig, endrer gold-tabellene seg ikke før neste døgns dump. Å spørre Mimir flere ganger samme dag gir identiske data.

Dette styrer integrasjonsdesignet:

  • Én synk per døgn er nok, kjørt etter at ETL-en er ferdig. Hyppigere henting gir samme data.
  • Ingen verdi i intra-dag-polling. En ny sak kan ikke dukke opp før neste døgns dump — det finnes ingen «fersk» sak å oppdage i mellomtiden.
  • Freshness-guard: synken bør lese dumpens dato i gold og hoppe over + varsle hvis den ikke er nyere enn forrige synk — aldri halv-ingester en stale eller midt-i-oppdatering-dump.
  • Frosne vs. ferske felter er et ikke-problem. Felter som er hendelsestidspunkt (f.eks. SøknadsDato) er uforanderlige ved kilden; å re-synke dem skriver samme verdi. Felter som endrer seg (status, innstilt/vedtatt beløp, vurderinger) vil vi uansett ha ferske. Ingen kolonne er samtidig «vil-fryse» og «endrer-seg-oppstrøms».

Relaterte beslutninger⚓︎

  • ADR-014 — SøknadsDato fra Mimir som matche-dato for tidsversjonering.
  • ADR-011 — Postgres som lager for den replikerte kopien.