Skip to content

Commit

Permalink
Add doc
Browse files Browse the repository at this point in the history
  • Loading branch information
@jacob-meidell
jacob-meidell committed Oct 5, 2023
1 parent 63fd3e6 commit 95d4c33
Show file tree
Hide file tree
Showing 2 changed files with 135 additions and 50 deletions.
179 changes: 132 additions & 47 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,56 +1,141 @@
# omsorgsopptjening-bestem-pensjonsopptjening
Skal sammenstille grunnlag og avgjøre hvem som får omsorgsopptjening

Sammenstiller grunnlagsdata for barnetrygd og hjelpestønad og avgjør om omsorgsopptjening kan godskrives automatisk.

## Bakgrunn

Applikasjonen er en erstatter for prosesseringsløpet som tidligere ble utført av

* [BPEN032 Importer barnetrygdsvedtak og hjelpestønadsvedtak](https://confluence.adeo.no/pages/viewpage.action?pageId=280294000)
* [BPEN030 Godskriv omsorgspoeng fra barnetrygd og send brev](https://confluence.adeo.no/display/PEN/BPEN030+-+Godskriv+omsorgspoeng+fra+barnetrygd+og+send+brev)

Alle funksjonelle behandlingsregler (implisitt og eksplisitt) fra de nevnte batchene er forsøkt bevart så godt det lar
seg gjøre.

## Arkitektur

[Overordnet arkitektur omsorgsopptjening](https://confluence.adeo.no/x/Gl_qHg)

## Statistikk oppgaver og brev fra BPEN030
Noen tall som forteller oss litt om hvilken størrelsesorden vi kan/bør forvente.
### Oppgaver opprettet
#### Flere omsorgsytere med like mye omsorg i fødselsår
* 2022: 86
* 2021: 94
* 2020: 101
* 2019: 131
* 2018: 133

#### Flere omsorgsytere med like mye omsorg utenfor fødselsår
* 2022: 1924
* 2021: 1173
* 2020: 1120
* 2019: 1121
* 2018: 950

#### Kunne ikke håndteres av batch
* 2022: 19
* 2021: 61
* 2020: 9
* 2019: 9
* 2018: 8

### Brev sendt
* 2022: 2979
* 2021: 2778
* 2020: 2645
* 2019: 2720
* 2018: 2732
## Intern arkitektur

Applikasjonen er delt inn i følgende distinkte steg som opererer uavhenging av hverandre:

1. Les grunnlagsdtata fra kafka og persister
2. Behandle grunnlagsdata, herunder
1. Berikelse
2. Vilkårsvurdering
3. Avgjøre om oppgave skal opprettes
4. Avgjøre om brev skal sendes
5. Avgjøre om omsorgsopptjening skal godskrives
3. Opprette oppgaver
4. Bestille brevutsending
5. Godskrive omsorgsopptjening

```mermaid
erDiagram
CUSTOMER }|..|{ DELIVERY-ADDRESS : has
CUSTOMER ||--o{ ORDER : places
CUSTOMER ||--o{ INVOICE : "liable for"
DELIVERY-ADDRESS ||--o{ ORDER : receives
INVOICE ||--|{ ORDER : covers
ORDER ||--|{ ORDER-ITEM : includes
PRODUCT-CATEGORY ||--|{ PRODUCT : contains
PRODUCT ||--o{ ORDER-ITEM : "ordered in"
flowchart
subgraph applikasjonsarkitektur
database[(Database)]
subgraph ekstern
pdl[PDL]
popp[POPP]
pen[PEN]
oppgave[OPPGAVE]
end
subgraph 1. Les grunnlagsdata fra kafka og persister
thread1[kafka-listener-thread]
thread1 --> prosessering1
subgraph prosessering1
k1[topic pensjonsopptjening-omsorgsopptjening]
app1[omsorgsopptjening-bestem-pensjonsopptjening]
app1 -->|leser| k1
app1 --->|lagrer| database
end
end
subgraph 2. Behandle grunnlagsdata
thread2[prosesser-persongrunnlag-melding-thread]
thread2 --> prosessering2
subgraph prosessering2
hent[hent uprosessert grunnlag]-->berik[berik datagrunnlag]
berik --->|POST:/graphql| pdl
vv[vilkårsvurder]
berik --> vv
vv --> o{opprett oppgave}
o --->|ja| database
vv --> b{send brev}
b ---> |ja| database
vv --> g{godskriv opptjening}
g ---> |ja| database
vv ---> |lagrer| database
end
end
subgraph 3. Opprette oppgaver
thread3[prosesser-oppgave-thread]
thread3 --> prosessering3
subgraph prosessering3
hento[hent uprossesert oppgave]
henta[hent aktør]
bestemsak[bestem sak]
opprett[opprett oppgave]
hento-->henta
henta--->|POST:/graphql|pdl
bestemsak--->|POST:/api/bestemsak/v1|pen
henta-->bestemsak
opprett--->|POST:/api/v1/oppgaver|oppgave
bestemsak-->opprett
opprett--->database
end
end
subgraph 4. Bestille brevutsending
thread4[prosesser-brev-thread]
thread4 --> prosessering4
subgraph prosessering4
hentb[hent uprossesert brev]
henta4[hent aktør]
bestemsak4[bestem sak]
opprett4[bestill brev]
hentb-->henta4
henta4--->|POST:/graphql|pdl
bestemsak4--->|POST:/api/bestemsak/v1|pen
henta4-->bestemsak4
opprett4--->|POST:/api/bestillbrev/todo|pen
bestemsak4-->opprett4
opprett4--->database
end
end
subgraph 5. Godskrive omsorgsopptjening
thread5[prosesser-godskriv-opptjening-thread]
thread5 --> prosessering5
subgraph prosessering5
hentg[hent uprossesert godskriving]
henta5[hent behandling]
opprett5[godskriv opptjening]
hentg-->henta5
henta5--->database
henta5-->opprett5
opprett5--->|POST:/api/omsorg|popp
opprett5--->database
end
end
end
```
### Felles for alle steg
#### Transaksjonshåndtering

```mermaid
graph TD;
A-->B;
A-->C;
B-->D;
C-->D;
```
Prosesseringen av hvert steg er designet for å understøtte følgende:

* Muliggjøre oppdatering av status når feil oppstår
* Oppnås ved å gjennomføre prosesseringen og feilhåndteringen i to separate transaksjoner. Siden både vellykket prosessering og feilhåndtering forsøker å oppdatere den samme statustabellen er det nødvendig at transaksjonen for prosessering får committet eller rullet tilbake før feilhåndteringen gjennomføres - noe annet kan ende med deadlock.
* Muliggjøre distribuert prosessering på tvers av flere podder
* Spørringen som henter rader for prosessering vil låse raden som velges ut for varigheten av transaksjonen. Spørringen vil også hoppe over eventuelle rader som allrered er låst, slik at andre podder ikke vil plukke opp samme rad. Kombinasjonen av disse to er årsaken til at prosesseringen og feilhåndteringen kjøres som egne transaksjoner innenfor levetiden til transaksjonen som hentet raden. Merk at det er viktig at hver av transaksjonene oppretter en ny transaksjon `PROPAGATION_REQUIRES_NEW`.
* I størst mulig grad holde datatabasen i synk med resultatet fra eksterne kall

#### Feilhåndtering

Dersom det oppstår feil under prosesseringen (exception kastes) vil statusen for den aktuelle raden som prosesseres
oppdateres, og den aktuelle raden vil havne i karantene for videre prosessering (for å unngå at feil
blokkerer prosesseringen av andre rader). Etter at karantenetiden er utløpt, vil raden forsøkes på nytt x
antall ganger opp til et maksimum - når maksimum er nådd uten at raden er prosessert ferdig, vil statusen settes til `Feilet`
og det vil være behov for manuell intervensjon.
6 changes: 3 additions & 3 deletions ...l/OmsorgsarbeidMeldingProcessingThread.kt → .../PersongrunnlagMeldingProcessingThread.kt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ import org.springframework.stereotype.Component

@Component
@Profile("dev-gcp", "prod-gcp", "kafkaIntegrationTest")
class OmsorgsarbeidMeldingProcessingThread(
class PersongrunnlagMeldingProcessingThread(
private val handler: PersongrunnlagMeldingService,
private val unleash: Unleash,
private val metrics: MicrometerMetrics
Expand All @@ -23,8 +23,8 @@ class OmsorgsarbeidMeldingProcessingThread(

@PostConstruct
fun init() {
val name = "prosesser-omsorgsarbeid-melding-thread"
log.info("Starting new thread:$name to process omsorgsarbeid")
val name = "prosesser-persongrunnlag-melding-thread"
log.info("Starting new thread:$name to process persongrunnlag")
Thread(this, name).start()
}

Expand Down

0 comments on commit 95d4c33

Please sign in to comment.