/
Det gode batchjob

Det gode batchjob

1. Formål og anvendelsesområde

Denne side beskriver de forretningsmæssige og operationelle krav, der gælder for alle batchjobs i DFDG.

Alle udviklingsteams skal følge disse retningslinjer.

Den tekniske implementering er beskrevet i: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2740617226

Denne side erstatter ikke den tekniske dokumentation, men supplerer den med governance, drift og robusthedskrav.

2. Arkitekturprincip

2.1 Framework-krav

Alle batchjobs i DFDG skal implementeres via Star.Foundation BatchJobs-frameworket.

Det betyder:

  • Batchjobs, der behandler persondata, skal nedarve fra BatchJobFeatureBase<T>

  • GDPR-slettebatchjobs skal nedarve fra GdprBatchJobFeatureBase<T>

  • Logging må ikke implementeres manuelt

  • Fejlhåndtering må ikke implementeres manuelt

  • Overvågning må ikke implementeres manuelt

  • Ensartet navngivning skal følge frameworkets konventioner

Se teknisk dokumentation her: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2740617226

Formålet er at sikre:

  • Ensartet logging

  • Ensartet fejlhåndtering

  • Ensartet overvågning

  • Ensartet exit-kode håndtering

  • Ensartet event-publicering

  • Ensartet navngivning

3. Release og etablering

3.1 Releasepolitik

Nye batchjobs skal releases med Major Release.

Begrundelse:

  • Batchjobs påvirker datamængder og driftsstabilitet

  • Ændringer kan have historiske og juridiske konsekvenser

  • Batchjobs kan have irreversible effekter (fx GDPR-sletning)

4. Argo og Kubernetes (Driftskrav)

Batchjobs i DFDG afvikles via Argo i Kubernetes.

4.1 Oprettelse

Ved oprettelse af et batchjob skal følgende ske:

  1. Forretningsdomænets konsolapplikation til afvikling af batchjobs skal etableres, hvis det ikke allerede findes

  2. Helm chart skal oprettes eller udvides

  3. Schedule skal defineres

  4. Ressourceforbrug (CPU/memory) skal fastsættes

  5. Retry-politik skal defineres

Se: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/4473457644

4.2 Schedule og periodisering

Et batchjob skal:

  • Have tydeligt defineret periodisering

  • Dokumentere forventet kørselsfrekvens

  • Dokumentere forventet datamængde per kørsel

Hvis et batchjob ikke kan køre i en periode (fx pga. release eller nedbrud):

  • Det må ikke stoppe permanent

  • Det må ikke give misvisende resultater

  • Det skal kunne opsamle manglende behandlinger

4.3 Ressourcer og performance

Ved etablering skal følgende vurderes:

  • Forventet køretid

  • Forventet datamængde

  • Database-index behov

  • Timeout-konfiguration

Standard timeout (30 sekunder) må ikke anvendes ukritisk.

Hvis jobbet behandler store datamængder, skal det opdeles i bidder (chunking).

4.4 Exit-koder og logning

Batchjobbet skal returnere:

  • Exit kode 0 → Success (ingen fejl logget)

  • Exit kode > 0 → Fejl

Når batchjobbet nedarver fra BatchJobFeatureBase<T> eller GdprBatchJobFeatureBase<T>, håndteres følgende automatisk af Star.Foundation:

  • Standardiseret logging

  • Strukturering af fejl

  • Registrering i overvågning

  • Exit-kode håndtering

Der må derfor ikke implementeres egen logningsmekanisme.

Overvågning findes her: https://kibana.prod.starcloud.dk/app/dashboards#/view/star-dashboard-batchjob-overview

Se også:

https://starwiki.atlassian.net/wiki/spaces/CITY/pages/25460933

https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2740617226

5. Robusthed og genkørsel

Et batchjob skal kunne genkøres.

Det betyder:

  • Fejlede poster skal kunne opsamles ved næste kørsel

  • Jobbet skal kunne finde elementer, der mangler behandling

  • Jobbet må ikke afhænge af at være kørt kontinuerligt

Hvis der har været nedbrud:

  • Jobbet skal håndtere manglende perioder korrekt

  • Jobbet må ikke generere dobbeltbehandling

  • Jobbet må ikke tabe data

6. Navngivning

Navngivning skal være:

  • Beskrivende

  • Maks 50 karakterer

  • Prefixed med system-indikation (2–4 bogstaver)

System-indikation afhænger af forretningsdomæne:

  • VS-* → forretningsdomænet Visitering og Status

  • BI-* → forretningsdomænet Borgerindsats

GDPR-slettebatchjobs skal yderligere prefix'es med:

  • VS-GDPR-* → forretningsdomænet Visitering og Status

  • BI-GDPR-* → forretningsdomænet Borgerindsats

Prefix håndteres teknisk via Star.Foundation, når de korrekte baseklasser anvendes.

7. Batchjobs der behandler persondata

Batchjobs, der behandler personrelaterede data:

  • skal implementeres via BatchJobFeatureBase<T>

  • må ikke selv håndtere transaktioner

  • må ikke selv håndtere event-publicering

  • må ikke selv håndtere CPR-logning

Når batchjobbet nedarver fra de relevante baseklasser i Star.Foundation, håndteres følgende automatisk:

  • CPR logges korrekt pr. behandlet entitet

  • Events publiceres per entitet

  • Hver entitet behandles i egen transaktion

  • Standardiseret logging og fejlhåndtering anvendes

Se teknisk dokumentation her:

https://starwiki.atlassian.net/wiki/spaces/CITY/pages/2740617226

8. Verificering af nye eller ændrede batchjobs

Følgende skal verificeres:

  • Jobbet kører som scheduleret

  • Argo-status stemmer overens med Kibana

  • Logning stemmer overens med borgeres status

  • Exit-koder håndteres korrekt

9. Nedlæggelse af batchjobs

Ved nedlæggelse:

  1. Batchjob fjernes fra Helm charts

  2. Schedule fjernes fra Argo

  3. Sag oprettes til SF vedr. nedlæggelse

  4. Dokumentation opdateres

Batchjobs må ikke blot “deaktiveres” uden dokumentation.

10. Dokumentation og information til SF

Batchjobbet skal dokumenteres på wiki.

Information om nyt og ændret batchjob sendes til SF i en Topdesk sag, hvor excel filen “Bestilling af nyt batchjob og overvågning” fra https://starwiki.atlassian.net/wiki/spaces/CITY/pages/25460933 skal udfyldes.

Se: https://starwiki.atlassian.net/wiki/spaces/CITY/pages/36765906

Batchjobbet skal dokumenteres med:

  • Formål

  • Schedule

  • Input og output

  • Afhængigheder

  • Fejlhåndtering

  • Kontaktteam

Dokumentationen skal give:

  • Udviklere mulighed for fejlsøgning

  • SF mulighed for overvågning og handling

Dokumentationen skal opdateres ved ændringer i schedule, funktionalitet eller nedlæggelse af batchjobbet.