| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
| Inc drawio | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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:
|
Open API | Ja, inspera OpenAPI | |
IntArk | Kan brukes etter ønske, for å aksessere Inspera gjennom Gravitee | Institusjonen bestemmer selv og gir oss beskjed om integrasjonen skal kontakte Inspera-instansen direkte eller om integrasjonen skal gå gjennom Gravitee |
...
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
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.
...
System | Data | Brukt API (endepunkter) |
|---|---|---|
Config-databasen | Finner data ( | configDB.orgs |
Config-databasen | Hvis prosessen var mislykket ( 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å | 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å | GET: /eksamen/{examSystem}/{examId} URL for test: https://fs-test.uio.no/eksamen/{examSystem}/{examId} |
LaaS | Registrerer en indeks | do Index |
Oai-databasen | legger auditInfoMap log til databasen | oai-addAuditLog |
|
|
|
Slack | Sender feilmeldinger (inkludert også data på | Slack-kanalen (mule-prod) |
Inspera | Spør | GET: /users/external/{idsys}/{userid} |
Inspera | Søk i | POST: /test/search
|
Inspera | Spør | GET: /test/{insperaId} |
Inspera | Oppretter ny prøve i Payload består av generelle prøvedata samt hovedansvarlige som allerede har brukere.
| POST: /test |
Inspera | Oppdaterer prøve funnet på 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 følgende data:
env
errorMessage (String)
errorCode (Number)
flowId
hash
inputTopic
orgId
submodule
success (boolsk)
vurdId (decodedVurdId)
Integrasjonen har ikke noe behov for tilgangstyring
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.
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.
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 totalt noen titalls tusen ved hver semesterstart dersom alle institusjoner er med.
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.