Arkivering av E-skjema fra SAP/DFØ (IOM-266)

Owned by babak.tavassoli
Last updated: Aug 11, 2023
2 min read

 

Innledning og Bakgrunn

Dette er en integrasjon for automatisk arkivering av E-skjema fra SAP/DFØ. Det er fastslått at flere av e-skjemaene i DFØ-løsningen som medfører arkivplikt, heriblant søknader om permisjon med innvirkning på pensjonsopptjening, oppsigelser og sidegjøremål (sistnevnte kun sidegjøremål som kommer i konflikt med den ansattes tilsettingsforhold, og dermed utløser saksbehandling).

DFØ har per dags dato bare API for ansattPersmosjoner. Det er derfor foreløpig er det bare arkivering av ansattPermisjoner som inngår i denne integrasjonen.

Integrasjon dokumentasjon: https://unit.atlassian.net/wiki/spaces/IPM/pages/2610790419

Nøkkel info

Initiesering av flyt

Melding via Meldingskø fra DFØ og IntArk

 

Flyt møsnter

Halvein-Asynkron

Når melding om ny ansattPermisjon søknad kommer inn, settes prosessen i gang med henting av data og starte arkivering.
Kommunikasjonen mot P360-arkiv modulen er derimot synkront

Bruk av meldingskø

DFØ og IntArk-meldingskø

Bare for mottakk av webhook-meldinger fra Inspera

Open API

Nei

 

IntArk

Brukt

 DFØ sine API og meldingskø må være satt opp via IntArk

Interessenter

Dette er en integrasjon bestilt av arbeids-utvalget til Dokumentasjonsforvaltning.

Brukerhistorie

  • Ansatt går inn på DFØ sin web-portal og søker om permisjon. Når søknaden har fått ferdig-status i SAP, vil det automatisk opprettes en sak med tilhørende søknad som innkommende dokument. Tilordnet saksbehandler kan kan starte saksbehandlingen og fullføre saken manuelt.

Systemer/tjenester

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

  • Tabellen under tar for seg BARE

System

Data

Brukt API (endepunkter)

System

Data

Brukt API (endepunkter)

SAP/DFØ via Gravitee

 

/v1/ansattePermisjoner

SAP/DFØ via Gravitee

 

/v2/ansatte/:id

SAP/DFØ via Gravitee

 

/v1/eskjemaLogg

P360-arkiv

 

/arkiver

 

 

 

Tilgangsstyring og logging

  • Integrasjonen loger til Humio med detaljert logging av prosessen.

  • Integrasjonen har ikke noe behov for tilgangstyring

Forretningsregler

Behandlingstid/responstid og volum

  • Integrasjonen ikke tatt til bruker nå; ingen data!

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 og sending til Slack, 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ø?

    • Eventuelle problemer med køene vil være utenfor vår ansvarsområde. Vi er bare mottakere av meldinger.

  • Hva skjer med ufullstendige meldinger?

    • De vil feile og det vil vi få beskjed om via Slack og/eller oppdage i loggene og kan ta aksjon basert på det.

  • Inneholder meldingene personopplysninger?

    • Meldingene er svært tynne og inneholder bare Id’er.

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

    • Søknadene ikke arkiveres (miste meldinger)

    • Søknadene arkiveres med feil info. (feiltolking eller feil logikk)

Kommentarer