Automatisk opprettelse av prøver i Inspera

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

Innledning

  • Integrasjonen henter ut vurderingsinformasjon fra FSWS og oppretter (og oppdaterer) prøver i Inspera på bakgrunn av dette.

teknisk dokumentasjon (i Inspera): https://unit.atlassian.net/wiki/spaces/IPM/pages/2657976352

teknisk dokumentasjon (i WISEflow): https://unit.atlassian.net/wiki/spaces/IPM/pages/2677243905

 

Nøkkel info

Initiering av flyt

Poller FSWS hver 6. time for endringer i vurderinger siste 3 dager.

 

Flyt mønster

Halveis synkron

Den delen som leser inn fra FS er en egen prosess og er frakoblet den delen som sender til Inspera. Hver del er synkron for seg.

Bruk av meldingskø

Ja, Kafka

Følgende felter sendes over fra FS-delen og til Inspera-delen:

examInfo prøvedata fra FS

shortName, fsID institusjonsinfo fra IOM sin configDB

insperaInstance spesifiserer hvilken Inspera som berøres

doPOST flagg for å bestemme om det skal skrives til Inspera. For bruk til utvikling.

Open API

Nei

 

IntArk

Kan brukes etter ønske, for å aksessere Inspera gjennom Gravitee. Meldingskø ikke implementert.

Institusjonen bestemmer selv og gir oss beskjed om integrasjonen skal kontakte Inspera-instansen direkte eller om integrasjonen skal gå gjennom Gravitee

Bakgrunn

  • Hver eneste prøve som skal holdes i Inspera må opprettes manuelt i dag. Dette gjøres ved at det for hver prøve hentes ut alle prøver fra FS, og så velges det fra listen. Listen genereres hver gang og dette tar lang tid per prøve, avhengig av antall vurderinger på institusjonen. Dette er enormt tidkrevende for saksbehandler, og denne integrasjonen vil lette dette arbeidet.

Interessenter

  • Bestiller er digital eksamen - tjenesten.

  • Alle FS-institusjoner som bruker Inspera.

Brukerhistorie

  • Vurdering gjøres klar i FS, med kandidater oppmeldt

  • Eksamensansvarlige har fått laget en bruker i Inspera

  • Integrasjonen plukker opp ny prøve fra FS og oppretter i Inspera

  • Eksamensansvarlig logger seg på Inspera, finner prøven opprettet og kan fortsette med populering av oppgavesett, og annet.

  • FS-synken sørger for at prøven holdes synkronisert med kandidater, sensorer og kommisjoner.

Systemer/tjenester

System

Data

Brukt API (endepunkter)

System

Data

Brukt API (endepunkter)

Config-databasen

Finner data (shortName, fsId, insperaInstance, stedkodefilter, startYear) for alle institusjoner som har aktivert AutoPostExam i databasen for gjeldende miljø.

configDB.orgs

Config-databasen

Hvis prosessen var mislykket (success er False), henter den en 'blacklist' for tjenesten for å bestemme om det skal registreres som en Slack-feilmelding i kanalen.

NB: Modulen hjelper utviklere og testere av systemet; sluttbrukeren vil ikke legge merke til det.

configDB.slack-blacklists

FS-Digex

Henter ut en json-liste basert på institutionsnr, datofra, datotil, sistEndret og examSystem over alle vurderinger som har blitt endret siden oppgitt tidspunkt.

GET: /eksamen/liste?institusjonsnr={examSystem}&datofra={datofra}&datotil={datotil}&eksamenssystem=INSPERA&sistEndret={sistEndret}

URL for test: https://fs-test.uio.no/eksamen/liste?…

URL for prod: https://fsws.usit.no/eksamen?liste?…

FS-Digex

Henter full info for en gitt eksamen basert på examSystem og examId.

GET: /eksamen/{examSystem}/{examId}

URL for test: https://fs-test.uio.no/eksamen/{examSystem}/{examId}
URL for prod: https://fsws.usit.no/eksamen/{examSystem}/{examId}

 

LaaS

Registrerer auditInfoMap (se under) i Humio (for å innta og beholde strømmedata)

do Index

Oai-databasen

legger auditInfoMap log (se under) til databasen

oai-addAuditLog

Slack

Sender feilmeldinger (inkludert også auditInfoMap, se under). Det stemmer overens med Config-databasen (configDB.slack-blacklists).

Slack-kanalen (mule-prod)

Inspera

Spør insperaInstance om bruker med idsys:FEIDE userid:brukernavn@domene.no finnes i inspera. Returnerer info om bruker finnes som bruker i Inspera.

GET: /users/external/{idsys}/{userid}

Inspera

Søk i insperaInstance etter prøve med ExternalID (base64 hash som definerer FS-vurdering: <institusjonsnr>||<emnekode>||<versjonskode>||<vurdkombkode>||<årstall>||<vurdtidkode>)

POST: /test/search

BODY (json):
{"query": {
"filters": {
externalId": {ExternalID}
}
}
}
}

 

Inspera

Spør insperaInstance om data for prøve med insperaId. Returnerer id (assesmentRunId)og om prøven er ekstern (tilkoblet FS) (result.externalTestInfo.externalTest)

GET: /test/{insperaId}

 

Inspera

Oppretter ny prøve i insperaInstance koblet til FS

Payload består av generelle prøvedata samt hovedansvarlige som allerede har brukere.

externalTestId <base64hash>, variant <vurdkombkode>, title <emnetittel>, startTime, endTime, duration, externalTest true, externalSystem "FS", authenticationSystem "FEIDE", subjectCode, versionCode, evaluationType <vurderingsform>, timeframeCode <tid.reell>, institution <institusjonsnr>, gradingDueDate, contributors <eksamensansvarlige>

POST: ​/test

Inspera

Oppdaterer prøve funnet på insperaInstance tilkoblet FS

Se over for felter.

POST: /test/{insperaId}​

Tilgangsstyring og logging

  • Integrasjonen logger til Humio med detaljert logging av prosessen.

  • Integrasjonen er knyttet logg-oversikten som vil logge auditInfoMap.

  • Integrasjonen har ikke noe behov for tilgangstyring siden det ikke er noen sluttbruker, alt skjer internt.

auditInfoMap

  • moduleId

  • submodule

  • vurdId

  • decodedVurdId

  • key (består av moduleId og vurdId)

  • errorMessage

  • fsId (institusjonsnummer)

  • orgId (institusjonsakronym)

  • hovedansvarlige (antall hovedansvarlige knyttet relativ hovedansvarlige oversendt fra FS - indikerer om noen må opprettes manuelt).

  • insperaInstance

  • success (boolsk)

  • testId (inspera test id)

  • title (prøvetittel)

Forretningsregler

  • Institusjoner som har skrudd på integrasjonen sjekkes hver 6. time:

  • FS sjekkes etter Inspera-prøver som har en endring de siste 3 dager. 

    • Med Inspera-prøve menes at enten eksamenssystem, sensursystem eller begrunnelsessystem er satt til INSPERA.

    • Med endring menes at DATO_SIST_ENDRET er mindre enn 3 dager siden for minst en av tabellene EMNE, VURDKOMBENHET, VURDERINGSKOMBINASJON, VURDKOMBMELDING, PERSON, EKSAMENSTILPASNING, KOMMISJON, SENSOROPPDRAG for emnet, prøven eller kandidater/sensorer på prøven.

    • Bruker FS-webservicen /eksamen/liste med parametere siden, system, institusjon.

  • For hver vurdering som finnes hentes all info fra FS via FS-webservicen /eksamen/INSPERA/<hashed id>

    • Dersom det er lagt inn en stedkodebegrensning («INSTITUSJON_FAKULTET_INSTITUTT_GRUPPE») filtreres alle vurderinger som ikke tilhører stedkoden vekk (en-til-en match, ingen hierarkisk sjekk). Denne er kun ment i pilotering/testing-fasen og ikke i full produksjon, da det er antatt at hele institusjonen skal følge integrasjonen når testing er godkjent.

    • Alle vurderinger uten kandidater filtreres vekk.

  • For hver vurdering (med kanditer og på rett sted) sjekkes Inspera for om eksamensansvarlig (hovedansvarlig) er registrert som bruker

    • Med eksamensansvarlig menes person som i FS er registrert med rollekode EKSANSV på fakultet/institutt evt emne som emnet tilhører (hierarkisk sjekk i FS).

    • Alle eksamensansvarlige som ikke har bruker i Inspera blir filtrert vekk.

      • Prøver uten eksamensansvarlige opprettes uten hovedansvarlig.

      • Disse må da opprettes og knyttes manuelt i etterkant inne i Inspera.

      • Feilmelding om manglende hovedansvarlige gis og logges.

  • For hver vurdering sjekkes Inspera etter om det eksisterer en prøve fra før i Inspera.

    • Finnes det en prøve sjekkes det om den er frakoblet FS.

      • Frakoblete prøver røres ikke.

    • Prøven opprettes dersom den ikke finnes, samtidig som den kobles opp til FS så den eksisterende Inspera-FS synken kan gå som normalt.

    • Prøven oppdateres dersom den finnes og er koblet til FS.

  • Integrasjonen behandler ikke kandidater, sensorer og kommisjoner ved opprettelse eller oppdatering, dette er det den eksisterende Inspera-FS synken som gjør.

Behandlingstid/responstid og volum

  • Uvisst, ikke satt i bruk enda men antatt totalt noen titalls tusen ved hver semesterstart dersom alle institusjoner er med.

Feilhåndtering, konsekvenser av feil og overordnet risikoanalyse

  • Hva skjer med feil info eller manglende info fra FS?

    • Prøver som er registrert med feil kan få opprettet feil prøve i Inspera, dette skal bli rettet opp ved neste kjøring og også ved senere synkronisering når feilen er rettet i FS.

  • Inneholder meldingene personopplysninger?

    • Ja. Meldingene fra FS inneholder kandidatinfo (navn, brukerid, kontaktinfo - telefonnummer og epost), info om sensorer (navn, personnummer, kontaktinfo) og eksamensansvarlige (navn, kontaktinfo).

  • Viktige feil/situasjoner som må passes ekstra på (som kan ha stor konsekvens).

    • Det verste som kan skje er om noe hender under selve utføringen av prøven (kandidater blir kastet ut, kandidater er registrert med feil eller manglende ekstratid).
      Alt som omhandler kandidater er pt. (sept’22) fjernet fra integrasjonen og håndteres bare av FS-Inspera-synkroniseringen.

Kommentarer