Arkivering av godkjenningsaker

Owned by babak.tavassoli
Last updated: Feb 23, 2024
2 min read

Innledning

Dette er en integrasjon for arkivering av godkjennings-saker fra Flyt til arkiv-systemet. Flyt initierer arkivering av dokumenter basert på visse hendelser initiert av bruker. For mer detaljer, se lenken “Arkivering detaljer fra Flyt”.
Flyt sender da dokumentene i form av json til vår interne Gravitee-API.

Generell info om Flyt: https://www.fellesstudentsystem.no/brukersider/brukerdok/flyt/

Arkivering detaljer fra Flyt: https://www.fellesstudentsystem.no/brukersider/brukerdok/flyt/dok/05-arkivering.html

Lenke til integrasjonen: https://unit.atlassian.net/wiki/spaces/IPM/pages/85491936

Nøkkel info

initierering av flyt

bruker-initiert, basert på hendelser i Flyt.

 

Flyt møsnter

synkron, message/event

Tykk json som inneholder all metadata og dokumentene som skal arkiveres

Bruk av meldingskø

Nei

 

Open API

Nei

 

IntArk

Nei

Bruker Gravitee, men ikke som del av intArk

Oversikt

 

Bakgrunn

Flyt er en saksbehandling system for håndtering av godkjenningssaker. Den inneholder kommunikasjon mellom studenter, saksbehandlere og professorer. Disse må arkiveres i en godkjent arkiv-system.

Interessenter

Dette er en leveranse til både Arkiv og Digital-eksamen. Kostandene deles derfor mellom disse 2.

Arkiv har produsert og bestemt den såkalte mappinsdokument som definerer hvordan oppgavene skal arkiveres i arkiv-systemet.

Brukerhistorie

  •  

Systemer/tjenester

  • Detaljert liste av alle innvolverte systemer/tjenester Hva utveksler data? Fra hvor / Til hvor?

    Tabellen under tar for seg BARE systemer i integrasjonsdelen, som starter med å motta meldingen (json-filen) fra Flyt.

System

Data

Brukt API (endepunkter)

System

Data

Brukt API (endepunkter)

Config-databasen

Henter orgId med fsId (fsInst)

configDB.orgs

Amazon S3

Overfører arkiverte filer (localFileName og fileName) til S3 bucket(fs-arkiv eller fs-studentsync)

upload file

Public360

Json-fil med all metadata nødvendig for arkivering. Se https://unit.atlassian.net/wiki/spaces/IPM/pages/173735939/p360-arkiv for detaljer

/arkiver

Documaster

https://unit.atlassian.net/wiki/spaces/IPM/pages/2759688223

Tilgangsstyring og logging

  • Integrasjonen logger til Humio med detaljert logging av prosessen.

  • Integrasjonen er knyttet logg-oversikten som lar brukerne se status på overføringer.

  • Ingen tilgangstyring er nødvendig

Forretningsregler

  • Se for detaljer

Behandlingstid/responstid og volum

  • Behandlingstid/responstid: ca. 1s

  • Frekvens: HTTPS-‘listener’ repeterbar fillagerstrøm for datastrømmestrategi

  • Volum (målt: Aug 25, 2022 ): gj.sn. ca. 10k hits daglig

Feilhåndtering, konsekvenser av feil og overordnet risikoanalyse

Generelt vil status og dermed eventuelle feil være synlig og tilgjengelig for institusjonen via logg-oversikten. Det er også utarbeidet mulighet for at enkelt personer ved institusjonen kan melde seg på for mottak av feilmeldinger på epost daglig.

Videre har vi overvåkning av loggene via Humio for å fange opp feil-situasjoner utenfor institusjonens virkeområde, som f.eks. utilgjengelige API endepunkter og bugs i koden.

 

  • Hva skjer ved overload i kø?

    • Siden overføringen er synkron, vil overføringen feile på Flyt sin side. De registrerer det og sender dokumentene igjen seinere.

  • Hva skjer med ufullstendige meldinger?

    • De vil det feile og siden overføringen er synkron, vil overføringen feile på Flyt sin side. De registrerer det og sender dokumentene igjen seinere.

  • Inneholder meldingene personopplysninger?

    • Ja

  • Noe om viktige feil/situasjoner som må passes ekstra på (som kan ha stor konsekvens) :

    • Arkivering av data fra en institusjon, skjer i en annen institusjon (blanding av arkiv-destinasjonen)

    • At filene blir korrupte

    • Systemet løper løpsk og lager mange saker/dokumenter og dermed roter til arkiv-systemet.

Kommentarer