| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
Innledning
Grovt om hva denne integrasjonen er fra hvor / Til hvor?
Bakgrunn
Litt om grunnen til integrasjonen. Hva for en behov dekkes av integrasjonen.
Interessenter
Hvem er ansvarlig for datakommunikasjonen? Hvem bestilte dette og betaler for at utvekslingenpågår?Målet med denne integrasjonen er å få en effektiv og automatisk opprettelse av bruker-kontotoer i bibliotek-systemet for alle studentene som skal ha tilgang. (For ansatte er det foreløpig institusjonene selv som håndtere).
Det er også opprettet en egen grensesnitt (API) for institusjonene selv å kunne provisjonere brukere: Alma user proxy API
| Inc drawio | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Bakgrunn
Rett etter at studenter registreres, skal de få bruker på bibliotek-systemet. Kilden av dataene er FS.
Interessenter
Interessent og oppdragsgiver her er Bibliotek-tjenesten.
Brukerhistorie (gjerne sekvensdiagram) ?
Hvis vi har noenStudent A er registrert i FS. Noen minutter etterpå skal vedkommende kunne logge seg inn på bibliotek-systemet.
Systemer/tjenester og involverte API
Innvolverte tjenester
...
Detaljert liste av alle innvolverte systemer/tjenester Hva utveksler data? Fra hvor / Til hvor?
Hvilken kø-mekanisme brukes evt.?
Om Int-ark komponenter er brukt og eventuelt hvilke deler
Data
Hvilke data utveksles? Alle attributter som utveksles?
Samhandlingsmønster
Hva driver utvekslingen? Request eller Push
Er utvekslingen synkron eller asynkron?
Om involverte API
Brukte API endepunkter
Tilgangsstyring og logging
Hva logges?
Eventuelle 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, Maxog API:
ALMA
FS (Det nye Graphql APIet)
Følgende roller/tilgager til FS sin GraphQl kreves for denne integrasjonen:
STUDENTDATA_LES1
STUDENT_STUDIERETT_LES1
STUDENTDATA_HENDELSER_LES1
STUDENT_STUDENTKORT_HENDELSER_LES1
STUDENT_STUDIERETT_HENDELSER_LES1
STUDENT_VURDERINGSMELDING_HENDELSER_LES1
STUDENT_SEMESTERREGISTRERING_HENDELSER_LES1
STUDIEELEMENTER_LES1
STUDIEELEMENTER_LES2
Data og Dataflyt
| Inc drawio | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Samhandlingsmønster
Integrasjonen er basert på student-hendelser i det nye FS-GraphQL APIet. Jobben kjører med jevne mellomrom og fanger opp alle relevante student-endringer.
Forretningsregler
Hvis studenten viser seg å ha en ansatt-konto, hoppes det over.
Institusjonene har en ganske stor konfigurerings mulighet som vil bestemme hvilke studenter og hvilke data om dem skal overføres.
Behandlingstid/responstid og volum
Ikke tilgjengelig ennå (under utvikling)
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.
...
Opprettelse av brukere ved feil institusjon :
Feil i koden som fører til endring/deaktivering av mange studenter:
Tilgang til personer som ikke skal ha tilgang:
Miste hendelser: