Automatisk opprettelse av prøver i WISEflow (under arbeid)

Owned by Karl Jacob Maus (Deactivated)
Last updated: Oct 24, 2024 by babak.tavassoli
5 min read

Innledning

  • Integrasjonen henter ut vurderingsinformasjon fra FSWS og oppretter prøver i WISEflow på bakgrunn av dette.

 

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 WISEflow. Hver del er synkron for seg.

Bruk av meldingskø

Ja, Kafka

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

examInfo prøvedata fra FS

shortName, fsID institusjonsinfo fra IOM sin configDB

examInstance spesifiserer hvilken WISEflow som berøres

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

Open API

Nei

 

IntArk

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

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

Bakgrunn

  • Hver eneste prøve som skal holdes i WISEflow må opprettes manuelt i dag. Dette er en tidkrevende prosess for saksbehandler, og denne integrasjonen vil lette dette arbeidet.

Interessenter

  • Bestiller er digital eksamen - tjenesten.

  • Alle FS-institusjoner som bruker WISEflow.

Brukerhistorie

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

  • Eksamensansvarlige har fått laget en bruker i WISEflow

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

  • Eksamensansvarlig logger seg på WISEFLOW, 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, examInstance, stedkodefilter, startYear, maler) 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=WISEFLOW&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}

 

FS-API

Henter ut merknadsfelt fra vurderingsenheter for å kunne matche med WISEflow:flowkode for mal, eller også flowtype. Input-parametre er institusjonsnr, emnekode, versjonskode, vurdkombkode, årstid, terminkode

GET: /vurderingsenheter

FS-API

Henter ut merknadsfelt fra vurderingskombinasjoner for å kunne matche med WISEflow:flowkode for mal, eller også flowtype. Input-parametre er institusjonsnr, emnekode, versjonskode, vurdkombkode

GET: /vurderingskombinasjoner

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)

WISEflow

Spør examInstance om bruker med idsys:FEIDE orgId:brukernavn@domene.no finnes i WISEflow (eksamensansvarlig FS:EKSANSV). Returnerer WISEflow:userId om bruker finnes som bruker i WISEflow.

GET: /user/eduPrincipalName/{orgId}

WISEflow

Spør examInstance etter integrationId for kobling til FS.

GET: /license/sis/clients

WISEflow

Søk i examInstance etter prøve med externalID (base64 hash som definerer FS-vurdering: <institusjonsnr>||<emnekode>||<versjonskode>||<vurdkombkode>||<årstall>||<vurdtidkode>). Returnerer tomt json-array dersom det ikke finnes noen flow med den id.

GET: /license/sis/flows/{externalID}

WISEflow

Oppretter ny prøve i examInstance

Payload består av FS metadata samt wiseflow-brukerinfo til EKSANSV og flowtype fra merknadsfelt.

POST: ​/license/create/flow

{ "title": {FS:Emnetittel}, "subTitle": {FS:Emnekode}, "type": {FLOWtype}, "managers": [ {WISEflow:userId} ] }

 

WISEflow

Oppretter ny prøve i examInstance fra kopi av mal med id flowId.

Payload består av FS metadata samt wiseflow-brukerinfo og diverse boolske config.settings som bestemmer hva som skal over (varierer med flowtypen til flowId.

POST: ​/flows/{flowId}/copy

{ "title": {FS:Emnetittel}, "subTitle": {FS:Emnekode}, "managerUserIds": [ {WISEflow:userId} ], "configuration": { <CONFIGURATION SETTINGS> } }

 

WISEflow

Knytter WISEflow prøve flowId til FS prøve med prøvedata decodedExternalID (Klartekst-streng som definerer FS prøve <institusjonsnr>||<emnekode>||<versjonskode>||<vurdkombkode>||<årstall>||<vurdtidkode>) og klargjør for nattlig eller manuell synkronisering. Returnerer tomt med statuskode 204 dersom alt er ok, feilmelding ellers.

POST: /flow/{flowId}/source/add

{ "sourceCode": {decodedExternalID}, "integrationId": {integrationId}, "useSisMetaData": true, "useSisDates": true }

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)

  • examSysInstance (hvilket WISEflow-miljø som er brukt, dev, test, prod)

  • success (boolsk)

  • flowId (WISEflow test id)

  • title (prøvetittel)

Forretningsregler

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

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

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

    • 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/WISEFLOW/<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 hentes det ut merknadsfelt som skal krysssjekkes med en mal-mapping som er hentet ut fra configDb.

  • For hver vurdering (med kanditer og på rett sted og med gyldig flowtype hentet i merknadsfelt) sjekkes WISEflow 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).

      • Prøver uten eksamensansvarlige kan ikke opprettes.

      • Eksamensansvarlig må da opprettes inne i WISEflow så neste kjøring kan opprette prøve.

      • Feilmelding om manglende eksamensansvarlig gis og logges.

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

    • Finnes det en prøve røres den ikke.

    • Prøven opprettes dersom den ikke finnes

    • Deretter kobles den opp til FS så den eksisterende WISEflow-FS synken kan gå som normalt.

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

    • Synkronisering mellom WISEflow og FS skjer nattlig eller ved manuell trigging.

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 WISEflow, 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 info om eksamensansvarlige (navn, kontaktinfo).

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

    • Det verste som kan skje er om prøve blir opprettet på bakgrunn av feil mal (for eksempel ved feilregistrering i configDb-basen vår).

    • Andre feil, som feil ved utføring av selve eksamen, er naturligvis alvorlig men skal ikke være på grunn av denne integrasjonen.

Kommentarer