Genopbyg medarbejderprojektioner
Genberegner pr.-medarbejder-projektioner fra bunden. Bruges når en læsemodel ser ud til at være ude af synk med de underliggende hændelser.
Hvad er en projektion?
Appen for-beregner flere læsemodeller pr. medarbejder — de data som UI’et læser, når du åbner en side. Hver projektion bygges ud fra hændelser (fraværsanmodninger, timeseddel-afleveringer, vilkårsændringer…) og holdes i synk, efterhånden som nye hændelser ankommer. Hvis en projektion driver (efter en dårlig migration, en manuel datafix eller en deploy med en bug), bringer en genopbygning fra hændelserne den tilbage til en kendt god tilstand.
Projektioner dette job genopbygger
| Projektion | Hvad den understøtter |
|---|---|
| Medarbejdersøgning | Medarbejderkartoteket og søgefeltet |
| Ansættelsesperioder | Hver medarbejders opløste nuværende og historiske vilkår |
| Fraværsprojektion | Planlagt, aktivt og forbrugt fravær pr. medarbejder |
| Tidsbank-saldo | Kontosaldi pr. medarbejder |
| Tilskrivningsprognose | Prognoser for kommende tilskrivninger |
| Timeseddel-ugeprojektion | Pr.-uge timeseddel-aggregater |
| Timeseddel-opgørelser | Hver medarbejders ventende/klare/afleverede opgørelser |
| Politik-aktivitet | Opløst aktivitet pr. fraværspolitik pr. medarbejder |
| Godkendelsesindbakke | Lederens “skal godkendes”-liste |
| Notifikations-brugervisning | Notifikations-feedet pr. bruger |
Sådan virker det
- Indlæser scope — som standard hver medarbejder i arbejdsområdet
- For hver medarbejder kører hver builder — de fleste builders afspiller blot de relevante hændelser gennem de samme handlers, der bruges i produktion
- For nogle projektioner kører en anden runde — f.eks. IsManager-flaget, der afhænger af at hver direct-report-række er afgjort
Parametre
| Parameter | Beskrivelse |
|---|---|
| Projektion | Den projektion der skal genopbygges. Standard er all. At vælge én projektion afgrænser arbejdet — nyttigt når du ved hvilken læsemodel der er forkert |
| Medarbejder-ID | Valgfri. Genopbyg kun denne medarbejders projektioner |
| Enheds-ID | Valgfri. Genopbyg hver medarbejder i denne enhed og dens efterkommere. Ignoreres når Medarbejder-ID er angivet |
Når scopet er begrænset (én medarbejder eller én enhed), springes post-rebuild-all-trinnet over — det forudsætter at hver medarbejder netop er blevet opdateret.
Jobresultater
| Metrik | Beskrivelse |
|---|---|
projection | Målet der blev genopbygget (all eller en specifik nøgle) |
scope | all, employee:<id>, eller org_unit:<id> |
success_count | Medarbejdere genopbygget uden fejl |
error_count | Medarbejdere hvor genopbygningen fejlede (se kørselsdetaljer for pr.-medarbejder-fejlene) |
Hvornår skal det køres
- Efter import af data fra et andet system
- Efter at have rettet en fejlbehæftet hændelse med en migration
- Når én enkelt medarbejders UI ser forkert ud (brug Medarbejder-ID til at afgrænse til én)
- Efter en hændelsesrapport der nævner én af projektionerne ved navn
Auto-trigger ved backfill
Når workeren starter op og finder en registreret projektion helt tom, mens medarbejdere eksisterer, planlægger den dette job automatisk. Det er et drifts-sikkerhedsnet for friske deployments og gendannede backups.
Fejlfinding
| Problem | Løsning |
|---|---|
| Kørslen tager lang tid | At genopbygge alle projektioner for hver medarbejder er den dyreste mulighed. Afgræns til én projektion eller én enhed, når du ved hvad du forsøger at rette |
| Fejl på nogle få medarbejdere | Åbn jobkørselsdetaljerne for at se pr.-medarbejder-fejlene. Ofte er det en forældet reference til en slettet entitet, der kan rettes med en målrettet redigering, hvorefter den ene medarbejder genopbygges |
| Projektion ser stadig forkert ud efter genopbygning | Genopbygningen afspiller hændelser gennem live-handlerne. Hvis handleren selv har en fejl, vil genopbygning ikke rette det — eskalér til udviklerne |