Versions Compared

Old Version 5

changes.mady.by.user Karl Jacob Maus (Deactivated)

Saved on

compared with

New Version 6

changes.mady.by.user Karl Jacob Maus (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel7
printablefalse

Innledning

  • Integrasjonen henter ut vurderingsinformasjon fra FSWS og oppretter (og oppdaterer) prøver i Inspera 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 Inspera/Wiseflow er en egen prosess og er fra-koblet fra resten. Men den delen som arkiverer går synkront til arkiv-tjenesten

...

Bruk av meldingskø

...

Nei

...

Open API

...

Nei

...

IntArk

...

Ikke brukt

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

  • Hvem er ansvarlig for datakommunikasjonen? Hvem bestilte dette og betaler for at utvekslingenpågår?
    Usikker. BOTT? Faktureres digeks.

Brukerhistorie

  • 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.

  • 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 sensorer og kommisjoner ved opprettelse eller oppdatering, dette er det den eksisterende Inspera-FS synken som gjør.

Systemer/tjenester

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

  • Fra FS (FSWS) via Kafka til Inspera

  • Kø: Kafka

  • Går direkte mot Inspera og FSWS, men kan også gå via Gravitee som gateway mot Inspera dersom institusjonen har ønske om dette.

Data

...

Hvilke data utveksles?  Alle attributter som utveksles?

Samhandlingsmønster

  • Hva driver utvekslingen? Request eller Push

  • Er utvekslingen synkron eller asynkron?

  • synkron polling fra FS (6 timers intervall), pushes (asynkront) til Inspera via kafka-kø mellom FS-request og Inspera-push.

Om involverte API

  • Brukte API endepunkter

...

inspera.no/api/v1/users/external/<IDSYS>/<USERID>

...

GET

...

inspera.no/api/v1/test

...

GET

...

inspera.no/api/v1/test/search

...

POST

...

inspera.no/api/v1/test

...

POST

...

inspera.no/api/v1/test/<TESTID>

...

POST

Tilgangsstyring og logging

...

Hva logges?

...

Table of Contents
minLevel1
maxLevel7
printablefalse

...

Innledning

  • Integrasjonen henter ut vurderingsinformasjon fra FSWS og oppretter (og oppdaterer) prøver i Inspera 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 fra-koblet fra 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

Ja, inspera OpenAPI

IntArk

Kan brukes etter ønske, for å aksessere Inspera gjennom Gravitee

Institusjonen bestemmer selv 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

  • Hvem er ansvarlig for datakommunikasjonen? Hvem bestilte dette og betaler for at utvekslingenpågår?
    Usikker hvor bestilling i sin tid kom fra; BOTT? Kostnader dekkes av digeks.

Brukerhistorie

  • 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.

  • 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 sensorer og kommisjoner ved opprettelse eller oppdatering, dette er det den eksisterende Inspera-FS synken som gjør.

Systemer/tjenester

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

System

Data

Brukt API (endepunkter)

Config-databasen

Finner data for alle institusjoner som har aktivert AutoPostExam i databasen for en gitt orgId

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 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 en indeks org, instance, env, event-name, remote-adr og request-uri i Humio (for å innta og beholde strømmedata)

do Index

Mongo-databasen

Finner alle dokumenter i databasen (orgId, examSys, insperaClientCode, fsEnv, instance, active, begrunnelse, klage, autoEpost og XklageFilter) som samsvarer med aktiv status og aktiv-verdi for Klage- eller Begrunnelse-felt.

Find documents i oai.KlageBegrunnelseEnvs kolleksjonen

Oai-databasen

legger auditInfoMap log til databasen

oai-addAuditLog

Oai-databasen

Henter aktive institusjoner med aktiv klage- og begrunnelse-status som tilsvarer examSystem, org og instance

oai.KlageBegrunnelseEnvs

Oai-databasen

Hvis prosessen var mislykket (success er False), fjerner Kafka melding fra databasen basert på hash verdi

‘Delete Kafka Message By Hash’ i oai.Records

Slack

Sender feilmeldinger (inkludert også data på module-idog submodul, organisasjons shortName og orgId, examSystem, examSysInstance, vurdId, fetchFsListDates, decodedFsTestId og filesToArchive). Det stemmer overens med Config-databasen (configDB.slack-blacklists).

Slack-kanalen (mule-prod)

WISEflow

Returnerer en liste (combinedMainFlowId, purpose, combinedSubFlowIds, variant, state, creationDate, type og flowId) over flyter som samsvarer med spørringsparameteren (sisCode, env og orgShortName).

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

WISEflow

Henter opp grunnleggende informasjon for en gitt flyt som navn, type, start- og sluttdato som kan brukes til å identifisere flyten (basert på contextObjectId (Flow id), org (orgShortName) og env).

GET: /flow/{flowId}

WISEflow

Returnerer grunnleggende informasjon (submissionId, assessorIds, groupId, id, assessorGroupIds og user) om alle deltakere som er tildelt en gitt flowId.

GET: ​/flow​/{flowId}​/participants

Tilgangsstyring og logging

  • Integrasjonen loger til Humio med detaljert logging av prosessen.

  • Integrasjonen er knyttet logg-oversikten som vil logge følgende data:

    • env

    • errorMessage (String)

    • errorCode (Number)

    • examSys

    • flowId

    • hash

    • inputTopic

    • kandidatNr

    • orgId

    • personlopeNr

    • reassessmentFlowId

    • submodule

    • success (boolsk)

    • vurdId (decodedVurdId)

  • Integrasjonen har ikke noe behov for tilgangstyring

Forretningsregler

  • Forretningslogikken i integrasjonen. Feks. Bare dokumenter med status X leses etter Y antall dager osv …

Behandlingstid/responstid og volum

  • Hva er antallet meldinger pr. døgn i denne forbindelsen (Min, Avg, Max)

  • Uvisst, ikke satt i bruk enda men antatt noen titalls tusen ved hver semesterstart.

Feilhåndtering, konsekvenser av feil og overordnet risikoanalyse

  • Hva skjer ved overload i kø?

  • Hva skjer med ufullstendinge meldinger?

  • Inneholder meldingene personopplysninger?

  • Noe om viktige feil/situasjoner som må passes ekstra på (som kan ha stor konsekvens). F.eks : Oppgavene som aldri vil publiseres, eller Oppgaver som ikke skal publiseres, publiseres.

Flytdiagram ?

Kommentarer