Analyse av overgang til ny Henvendelse og Dialogstyring

[gtcno]

tldr: stor oppgave

Team Søknad har en ny Henvendelse og Dialogstyring verdikjede. De vil at vi skal migrere til denne verdikjeden.

VI må finne ut hvordan denne verdikjeden brukes i dag. Denne analysen skal brukes som et hjelpemiddel til å bestemme om vi skal

a) Migrere til ny verdikjede b) Forke og overta den gamle verdikjeden c) Lage noe eget.

[Bendreas]

Nyttige lenker: https://confluence.adeo.no/display/TDP/3.9.1+Dagpenger+ut+av+henvendelse+og+dialogstyring https://confluence.adeo.no/display/TS/Veien+videre+for+felleskomponentene+Henvendelse+og+dialogstyring# https://confluence.adeo.no/display/TS/Dialogstyring https://confluence.adeo.no/display/TS/Henvendelse#

https://github.com/navikt/dagpenger/issues/646

[Bendreas]

Alternativer

Forke henvendelse og dialogstyring

pros:

• short term: trenger ikke gjøre noe.

cons:

• long term: masse avhengigheter: gsak, sak og behandling, dokumentmottak, modia, dokument etc.
• vi har ingen foreløpig plan på å komme oss ut av driten, flashbacks fra søknadsdialog/server.

Dette virker foreløpig som en dårlig løsning, med tanke på kortsiktigheten. Vil ikke ende opp med ny case av søknadsdialog.

Kopiere det som er gjort og jobbe sammen med de for å løse de få tingene som gjenstår

pros:

• vi får innsikt i hvordan ting fungerer nå, til når vi en dag må forvalte selv

cons:

• jobber sammen om dette.

Skjønner ikke helt hva dette innebærer? Minner om punktet nedenfor, men mtp. at det står kopiere det som er gjort virker det som at vi skal forke den midlertidige løsningen, noe som virker lite gjennomtenkt.

Midlertidig benytte samme nye løpet som er laget nå

pros:

• ingen implementeringskostnad

cons:

• de forventer da at vi deler på forvaltning av nytt løp.

Lage noe eget

pros:

• slippe å forholde seg til hele greiene

cons:

• masse jobb (må lage selv, koordinere med andre)

Andre bemerkninger:

• Vi vet enda ikke når de skal skru av henvendelse og dialogstyring
• Vi trenger mer informasjon

[kmriise]

Hør med digisos (de har skrevet seg ut av faktum-modellen)?

Opprett behandlingsId + faktumstruktur i selve sendsoknad fremfor å la henvendelse gjøre det. Mellomlagring osv må håndteres ett annet sted også

Hvordan skal man løse gjenoppta søknad? (Fortsette på en mellomlagret søknad) -> trengs å vises på dittnav at det er påbegynte søknader

Hvordan skal man løse ettersendelse? (Sende inn vedlegg på en allerede innsendt søknad) -> trengs å vises på dittnav at det er innsendte søknader, kunne se hvilke vedlegg som mangler, hvilke vedlegg som er sendt inn, endre vedlegg som er sendt inn, kunne legge til ekstra vedlegg som ikke kreves

arkiveringsløp?

[kmriise]

Håndterer per nå at brukere laster opp flere filer per vedlegg. Kan kresje sendsoknad-biten når det blir kjempestore filer som konsolideres per vedlegg.

[kmriise]

bruker starter søknad -> soknadsdialog -> henvendelse oppretter faktumstruktur og behovsid og mellomlagrer dittnav viser dagpengesøknader -> Saksoversikt -> henvendelse (metadata om søknad)

alternativ -> skrive om frontend til react, fjerne faktumstrukturen, lage logikk for verifisering av spørsmålene selv, sende svar tilbake til backend i blob. (Hvordan gjør vi det med migreringer og bakoverkompabilitet?)

[kmriise]

tldr: stor oppgave

[kmriise]

Må uansett gjøre om soknadsdialog sin backend om til å opprette id og faktumstruktur, uansett hvilken løsning vi går for. Dette krever i tillegg til at vi sender inn metadata til henvendelse slik at mittnav og mine saker vil fortsatt fungere

[kmriise]

søknadsteamet som laget kontantstøtte fra scratch (gikk over til foreldrepenger) gjorde det ganske greit, få litt erfaringer fra dem?

Vi må ha: Lagring Logikk for innsending Logikk for å hente mellomlagrede søknader Logikk for å sende inn vedlegg på innsendte søknader (hvor lenge kan man ettersende? når kan man ettersende?) Logikk for å lagre søknader Logikk for å hente ut lagrede søknader

[kmriise]

Henvendelse / dialogstyring: Planen var å slå av sommer 2021, går nok ikke pga covid og kobling til dialogstyring når teamsoknad er ut av henvendelse har dagpenger største koblingen til henvendelse. innen 2022 vil ikke teamsoknad drive vedlikehold av henvendelse da de etter planen vil ha skrevet seg ut

[kmriise]

Hvordan bli kvitt de 11 konsumentene av henvendelse? Ønsker at dagpenger har dataene hos seg selv/sender som en strøm selv.

dittnav saksbehandlere?

[kmriise]

Grunnen til at det lagres i henvendelse er et tidligere sikkerhetskrav som ikke lenger er gyldig. Er derfor ingen grunn til å ikke lagre/opprette søknadsid og faktumstruktur på egenhånd i soknad-server

[kmriise]

Anbefaling Sturle: bli kvitt mellomlagring/opprettelse av søknadsid fra henvendelse, og gjør dette i soknad-server deretter skriv om hele dritten og koble seg vekk fra faktumstrukturen. -> finn en måte å la avhengige konsumenter både få vite om og hente ut informasjon direkte fra oss.

[kmriise]

Konklusjon møte internt dagpenger: Me to Everyone (10:41 AM) Soknadsdialog vil leve lengre enn henvendelse slik det ser ut nå Lage to bets: overta heiv/dialogstyring, lage nye komponenter Finne ut hva henvendelse/dialogstyring gjør Me to Everyone (10:42 AM) Finne ut hva som er viktig for soknadsdialogen å gjøre, hva som trengs av andre systemer i nav