/
Arkivering av godkjenningsaker

Arkivering av godkjenningsaker

Owned by babak.tavassoli
Last updated: Jan 06, 2025
3 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: Arkivering av klage og godkjennings saker

 

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ø

Ja;

MeldingQ (Sikt egen melding-kø system basert på MongoDb, i.e. DocumentDb)

Meldingssystemet publiserer til to forskjellige destinasjoner for arkivering:

  1. Godkjenningsaker og klagesaker for UiT og NTNU sendes via en applikasjon (fs-ephorte) som arkiverer dem i Ephorte.

  1. For andre universiteter sendes de samme godkjenningsaker og klagesaker til en annen kø, som leder til en annen app (p360-fs-student) for videre behandling og arkivering.

Systemet sikrer dermed riktig distribusjon basert på institusjon.

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://sikt.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

Behandlingstid/responstid og volum

  • Behandlingstid/responstid: ca. 4s

  • Frekvens: Det meldingssystemet kjører uten forsinkelse på meldingskøen – lytteren til køen tar meldinger én etter én og starter behandlingen umiddelbart

  • Volum (målt fra Dec 1, 2024 til Dec 31, 2024): gj.sn. ca. 4k 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ø?

    • Det skjer ikke da-køene kun har én parallell forbruker ('queue-listener');

  • 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

  • Inneholder meldingene sensitive personopplysninger?

    • ifølge definisjonen på sensitive personopplysninger hos Sikt (Sikt Personvernhåndbok) kan vi konstatere at det ikke forekommer behandling eller overføring av slike data i MuleSoft-plattformen.

  • 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

Related content