LTI - Egendefinerte parametere

  • Oppdatert

Denne artikkelen inneholder en forklaring på alle egendefinerte parametere (custom parameters) vi støtter for øyeblikket. Noen LMS-er, som Moodle, tillater konfigurering av egendefinerte parametere på både verktøy-konfigurasjonsnivå og på prøvenivå. Andre LMS-er, som Canvas, tillater kun konfigurering på konfigurasjonsnivået.

Hvis en egendefinert parameter defineres på verktøy-konfigurasjonsnivå, vil den gjelde for alle prøver (som startes etter at den er konfigurert). Hvis den er definert på prøvenivå, vil den kun gjelde på prøvenivå. Hvis en egendefinert parameter er definert på konfigurasjonsnivå, kan den ikke endres på prøvenivå.

Slik fungerer egendefinerte parametere

For at LTI-integrasjon med Inspera skal fungere som tiltenkt, kan det kreves ekstra data for at hver institusjon skal kunne tilpasse LTI-integrasjonen til egne behov. Disse ekstra dataene konfigureres ved hjelp av egendefinerte parametere. De sendes til Inspera hver gang en lærer starter verktøyet (launch).

Kun LMS-administrator kan konfigurere egendefinerte parametere på konfigurasjonsnivå. Disse kan endres når som helst og vil påvirke alle fremtidige oppstarter for alle prøver (gamle og nye).

I noen LMS-er kan lærere sette egendefinerte parametere på prøvenivå, og disse vil da kun bli brukt i fremtidige oppstarter av den spesifikke prøven.

Hvis de ikke er satt, er standardverdien for alle egendefinerte parametere "false", som betyr at det kun er nødvendig å konfigurere de egendefinerte parameterne som er relevante for arbeidsflyten ved din institusjon.

Viktige egendefinerte parametere

Det er noen egendefinerte parametere som alltid bør konfigureres for å sikre korrekt funksjonalitet. Disse bør konfigureres på verktøy-konfigurasjonsnivå. Noen av disse er kanskje bare relevante for et spesifikt LMS, men de vil ikke skade arbeidsflyten din. Du kan sjekke hver enkelt for å få en bedre forståelse av hva de gjør.

  • skip_incomplete_members = true (dette forhindrer avbrudd i påmeldingen av bidragsytere/kandidater dersom det oppstår feil)
  • use_template_on_create = true (kun for institusjoner som jobber med maler og bruker et LMS som tillater egendefinerte parametere på prøvenivå)
  • Keep_test_title = true (relevant for institusjoner som bruker D2L).

Du bør også vurdere:

Vanlige oppsett

  1. For å oppnå dette bør du bruke den egendefinerte parameteren:

    • enroll_candidates = true

    Hvis du vil at dette skal skje i alle prøver i alle kurs, legger du den til i verktøy-konfigurasjonen. Hvis du vil at dette bare skal skje i enkelte prøver, må du ikke sette den opp på verktøy-konfigurasjonsnivå, men instruere lærerne om å sette den opp når de oppretter prøven der dette skal gjelde (hvis LMS-et støtter det).

    Ekstra: Hvis du vil at studenter som fjernes fra kurset skal meldes av IA-prøven, bruker du remove_candidates=true. Det er viktig å merke seg at dette vil fjerne alle kandidater som kan ha blitt lagt til på prøven direkte i IA dersom de ikke er lagt til i kurset i LMS-et.

  2. For å oppnå dette bør du bruke den egendefinerte parameteren:

    • enroll_contributors = true

    Hvis du vil at dette skal skje i alle prøver i alle kurs, legger du den til på verktøy-konfigurasjonsnivå. Hvis du vil at dette bare skal skje i enkelte prøver, må du ikke sette den opp på verktøy-konfigurasjonsnivå, men instruere lærerne om å sette den opp når de oppretter prøven der dette skal gjelde (hvis LMS-et støtter det).

    Ekstra: Hvis du vil at lærere som fjernes fra kurset skal fjernes som bidragsytere fra IA-prøven, bruker du remove_contributors=true. Det er viktig å merke seg at dette vil fjerne alle bidragsytere som kan ha blitt lagt til på prøven direkte i IA, dersom de ikke er lagt til som lærere i kurset i LMS-et.

  3. I de fleste tilfeller når man bruker SSO, er den unike identifikatoren for brukere e-postadressen. I så fall bør du legge til konfigurasjonen:

    • username_resolver=BY_EMAIL

    Dersom den unike identifikatoren er en annen, må du identifisere den korrekte identifikatoren og definere den egendefinerte parameteren username_resolver i henhold til dette. For mer informasjon, vennligst sjekk dokumentasjonen for username_resolver under seksjonen for brukersynkronisering.

    Du bør også identifisere den korrekte autentiseringstypen (auth type - f.eks. google, saml, osv.) for brukeridentifisering. Dette vil være den samme som er konfigurert når man setter opp IA-instansen. Etter at du har identifisert den, konfigurerer du den egendefinerte parameteren:

    • lti_authtype=<den samme autentiseringstypen>

    For en liste over tilgjengelige verdier, sjekk seksjonen om denne egendefinerte parameteren i seksjonen for brukersynkronisering.

    Begge disse egendefinerte parameterne må defineres på verktøy-konfigurasjonsnivå.

  4. Ja. Med den egendefinerte parameteren candidateid_resolver.

    For å identifisere den korrekte verdien for parameteren (du kan sjekke de mulige verdiene i seksjonen for administrering av kandidater), må LMS-systemadministrator identifisere LTI-egenskapen som inneholder navnet på kandidaten og/eller definere den egendefinerte candidateid_resolver deretter. De kan deretter kjøre en prøve i feilsøkingsmodus (debug mode) for å se verdiene som sendes til Inspera.

    For eksempel, hvis det er e-postadressen, bør det være:

    • candidateid_resolver=BY_EMAIL

  5. Det kan være tre ulike scenarioer:

    1. Brukeren eksisterer allerede i IA og har minst de påkrevde rollene.
      1. Brukeren forblir uendret i IA.
    2. Brukeren eksisterer allerede i IA, men har ikke de påkrevde rollene.
      1. De påkrevde rollene vil bli lagt til brukeren, og de eksisterende rollene de måtte ha vil bli beholdt. 
    3. Brukeren eksisterer ikke i IA ennå.
      1. En ny bruker opprettes i IA med de påkrevde rollene.

    Dette skjer enten under påmelding av lærer eller når læreren starter prøven gjennom LTI.

    De påkrevde rollene vil avhenge av mappingen mellom rollene i LMS og IA.

    Det er to mappinger:

    • LTI - IA
      • LTI tilbyr enkelte roller (som instructor), og disse rollene blir mappet til rollene i IA.
      • Standardmappingen er instructor i LTI -> Forfatter (Author), Hovedansvarlig (Planner), Sensor (Grader), Hovedvakt (Chief Invigilator) i IA.
      • Hvis en annen mapping er nødvendig, vennligst kontakt vår support- avdeling. IA støtter ikke mapping av underroller.
    • LMS - LTI
      • LMS-administrator må sikre at LMS - LTI-mappingen er satt opp korrekt slik at LTI-rollene deretter mappes til IA.
      • Hvis LTI - IA-mappingen er standard, bør alle lærerroller i LMS mappes til rollen instructor i LTI.
  6. Hvis to eller flere LMS-er er konfigurert mot samme IA-instans, bør det defineres en prefiks som er unik for dette LMS-et. Dette bør konfigureres på verktøy-konfigurasjonsnivå. Denne prefiksen vil bli lagt til som en prefiks på prøve-ID-en for å skille mellom prøver opprettet gjennom ulike LMS-er, og den kan ha hvilken som helst verdi LMS-systemadministratoren velger:
    • arid_prefix=<verdi definert av systemadministrator>
  7. Hvis dette skjer, er det mest sannsynlig fordi LMS-administrator har konfigurert den samme egendefinerte parameteren på verktøy-konfigurasjonsnivå, og den kan da ikke overstyres. Sjekk med dem. Hvis det ikke er tilfelle, kan du bruke den egendefinerte parameteren for feilsøking (debug) for å bekrefte hvilke verdier som sendes til IA. Hvis de riktige verdiene sendes, men resulterer i feil oppførsel, vennligst kontakt vår service desk.

Liste over egendefinerte parametere

Husk at dersom de ikke er konfigurert, vil alle egendefinerte parametere ha standardverdien "false".

Administrering av bidragsytere

enroll_contributors

  • Hvis false, vil ingen bidragsytere (bortsett fra den nåværende brukeren) bli lagt til automatisk på prøven i IA. Men hvis en lærer klikker på lenken til prøven i LMS-et, vil de bli meldt på som bidragsyter uavhengig av denne parameteren.
  • Hvis true, vil brukere som er lagt til som deltakere i kurset automatisk bli lagt til på prøven i IA som bidragsytere.

remove_contributors

  • Hvis false, vil det å fjerne en deltaker fra kurset i LMS-et ikke påvirke bidragsyterne på prøven i IA.
  • Hvis true, dersom en bruker har blitt lagt til som bidragsyter på en prøve i IA, men ikke er (eller ikke lenger er) deltaker i kurset i LMS-et, vil de bli fjernet som bidragsyter.

Administrering av kandidater

enroll_candidates

  • Hvis false, vil ingen kandidater automatisk bli meldt på prøven i IA.
  • Hvis true, vil studentene som er lagt til som deltakere i kurset automatisk meldes på prøven i IA som kandidater.

remove_candidates

  • Hvis false, vil det å fjerne en student fra kursets deltakerliste i LMS-et ikke fjerne de tilsvarende kandidatene fra prøven i IA.
  • Hvis true, dersom en bruker har blitt lagt til som kandidat på en prøve i IA, men ikke er (eller ikke lenger er) deltaker (som student) i kurset i LMS-et, vil de bli fjernet fra kandidatlisten på prøven i IA.

Generell brukeradministrering

skip_incomplete_members (denne bør alltid settes til true)

  • Hvis false, dersom det oppstår en feil ved påmelding av en kandidat eller en bidragsyter, vil resten av kandidatene/bidragsyterne ikke bli påmeldt.
  • Hvis true, dersom det oppstår en feil ved påmelding av en kandidat eller en bidragsyter, vil den brukeren bli hoppet over og påmeldingen vil fortsette.
  • Bør settes på verktøy-konfigurasjonsnivå.

Brukersynkronisering med IA

Som forklart i vår LTI-dokumentasjon, skjer det to ting når en lærer starter en prøve gjennom LMS-et:

  • Brukeren logges inn i IA
  • Brukeren meldes på prøven 

Lærere som ikke skal meldes på prøven i IA bør ikke klikke på lenken til prøven i LMS-et.

For at dette skal skje, er det nødvendig å definere brukernavnet og den eksterne ID-en som skal knyttes til denne brukeren i IA. Dette brukes når man oppretter brukerne i IA (hvis aktuelt) og for å identifisere en allerede opprettet bruker.

Disse brukes også når en bruker ønsker å logge inn direkte i IA (ikke gjennom LMS-et).

Derfor er det viktig å sikre at brukernavn (username) og ekstern ID (external_id) som opprettes når brukeren kommer fra LMS-et, er de samme som brukes når brukeren logger inn i IA direkte.

Følgende egendefinerte parametere bør vurderes for å sikre en sømløs brukeridentifiseringsprosess:

  • username_resolver
  • lti_username_externalid_suffix
  • lti_authtype

Alle disse egendefinerte parameterne bør settes på verktøy-konfigurasjonsnivå.

username_resolver

  • Denne egendefinerte parameteren definerer hvordan brukernavn og ekstern ID for brukerne i Inspera defineres.
  • Hvert brukernavn må være unikt, så username_resolver bør sikre at ingen brukere ender opp med samme brukernavn.
  • Som standard er brukernavnet fornavn og etternavn, og ekstern ID er basert på user_id og oauth_client_key.
  • Dersom standardkonfigurasjonen ikke sikrer at brukernavnet er unikt, må en annen konfigurasjon velges. Alternativer: BY_EMAIL, BY_SOURCEDID, BY_INSPERA_PROPERTY. For mer informasjon om hvilke LMS-felt som brukes, vennligst sjekk tabellen i den utvidbare seksjonen.

  • Følgende tabell forklarer hvilke felt fra hver tjeneste som brukes til å bygge external_id og brukernavnet.

    Verdi for username_resolver Innlogging Medlemskap Ekstern ID og brukernavn
    DEFAULT

    user_id = user_id

    prefiks kommer fra den egendefinerte parameteren lti_username_externalid_suffix 

    given_name = lis_person_name_given

    family_name = lis_person_name_family

    user_id =userId

    given_name = givenName

    Family_name = familyName

    ekstern ID: oauth_client_key + user_id + prefiks

    brukernavn = given_name + family_name
    BY_USERID Samme som DEFAULT Samme som DEFAULT Samme som DEFAULT
    BY_EMAIL email = lis_person_contact_email_primary email = email

    ekstern ID = email

    brukernavn = email
    BY_SOURCEDID source_id = lis_person_sourcedid source_id = sourcedId

    ekstern ID = source_id

    brukernavn = source_id

    BY_INSPERA_PROPERTY

    Dette krever to ekstra egendefinerte parametere

    		 verdi = inspera_property_lti_login verdi = inspera_property_membership

    ekstern ID = verdi

    brukernavn = verdi

    Slik bruker du BY_INSPERA_PROPERTY-verdien for username_resolver:

    • Dette tillater bruk av alle felt fra LTI-innloggings- og medlemskapstjenestene.
    • De egendefinerte parameterne inspera_property_lti_login og inspera_property_membership bør settes til de tilsvarende feltnavnene.

    Eksempel:

    • En bruker ønsker å bruke det egendefinerte feltet “ext_user_username” ved innlogging og “ext_user_username2” i medlemskap (oppdiktede navn). De bør sette de egendefinerte parameterne slik:
      • username_resolver=BY_INSPERA_PROPERTY
      • inspera_property_lti_login=ext_user_username
      • inspera_property_membership=ext_user_username2

lti_username_externalid_suffix

  • Brukt til å definere suffikset for external_id som er nevnt i beskrivelsen av username_resolver. Det vil normalt være noe slikt som «@eksempel.no»

lti_authtype

  • I IA kan vi ha ulike måter å logge inn samme bruker på (GOOGLE, GENERIC_SAML, osv.). Det er en external_id knyttet til hver av disse. Disse kalles internt for auth_type. Hvis det er en spesifikk innlogging, må denne settes opp for å samsvare med denne.
  • Standardverdi er LTI
  • Mulige verdier: 'GENERIC_SAML', 'GOOGLE', ‘OIDC’, ‘SHIBBOLETH’

  • I dette eksempelet er både username_resolver=BY_EMAIL og lti_authtype=LTI satt, ettersom e-post er den unike identifikatoren og oauth-typen er SAML.

    Nødvendige trinn:

    • Logg inn på din Inspera-portal med SSO for å sjekke feltet for externalUserId-mapping i saml-assertion. Det samme feltet må mappes som externalUserId fra Inspera og LMS-et. Bruk en testbruker for å identifisere e-postattributten fra SAML-tokenet. 

    • Hent SAML-responsen for assertion https://{domain}/saml/endpoint/assertion i nettleserens utviklervindu. 

    • Dekod SAML-responsen med et valgfritt SAML-verktøy. Den dekodede versjonen bør ligne på følgende: 

    • Inspera godtar navnet ‘urn:oid:1.3.6.1.4.1.5923.1.1.1.6’ eller det lesbare navnet 'eduPersonPrincipleName' som standard attributtnavn for externalUserId i SAML-responsen. (Referanse for SAML-felt)
    • Hvis eppn (eduPersonPrincipleName) ikke er tilgjengelig i SAML-responsen, må du legge dette til i attributtlisten i SAML-konfigurasjonen. Dette er feltet som vil bli brukt til å mappe brukeren på tvers av begge plattformene – LMS og Inspera.
    • Som standard godtar Inspera eppn som externalUserId. Hvis du ønsker å bruke en annen attributt, må du informere Inspera om dette under SAML-oppsettet. 
    • Hvis vi kan identifisere en attributt i SAML-assertion som inneholder e-postadressen, kan denne kombineres med username_resolver=BY_EMAIL. Dette vil fungere hvis externalUserId er den samme i Inspera og LMS-et. Bruk av eppn med BY_EMAIL fungerer bare hvis eppn inneholder den samme e-postadressen som er registrert i LMS-et.

candidateid_resolver

  • Når en student starter prøven fra LMS-et eller blir påmeldt via den egendefinerte parameteren enroll_candidates, må en kandidat-ID opprettes for å representere studenten på den prøven. En student kan ta flere prøver, men en kandidat-ID må være unik for hver prøve.
  • Denne «resolveren» angir hvordan kandidat-ID-en bygges i Inspera. Som standard vises user_id, men andre verdier kan brukes.
  • Det er viktig å sikre at kandidat-ID-ene er unike. Hvis det finnes to eller flere studenter med samme kandidat-ID, vil bare den første bli meldt på prøven. Alternative verdier: BY_EMAIL, BY_NAME, BY_SOURCEDID, BY_INSPERA_PROPERTY. For mer informasjon, se tabellen i den utvidbare seksjonen.

  • Følgende tabell forklarer hvilke felt fra hver tjeneste som brukes til å bygge kandidat-ID-en (candidate_id).

    Verdi for candidateid_resolver  lti-login-parameter membership-name
    DEFAULT user_id userId
    BY_EMAIL lis_person_contact_email_primary email
    BY_NAME name name
    BY_SOURCEDID lis_person_sourcedid sourcedId
    BY_INSPERA_PROPERTY inspera_property_lti_login inspera_property_membership

    Slik bruker du verdien BY_INSPERA_PROPERTY for candidateid_resolver:

    • Dette tillater bruk av et valgfritt felt fra LTI-innloggings- og medlemskapstjenestene.
    • De egendefinerte parameterne inspera_property_lti_login og inspera_property_membership må settes til de tilsvarende feltnavnene.

    Eksempel:

    • En bruker ønsker å bruke det egendefinerte feltet «cand_id» ved innlogging og «cand_id_memb» i medlemskap (oppdiktede navn). De bør sette de egendefinerte parameterne slik:
      • candidate_id_resolver=BY_INSPERA_PROPERTY
      • inspera_property_lti_login=cand_id
      • inspera_property_membership=cand_id_memb

Skille mellom ulike LMS-er

arid_prefix

  • Hvis to eller flere LMS-er er konfigurert mot samme IA-instans, bør det defineres en prefiks som er unik for dette LMS-et. Dette bør konfigureres på verktøy-konfigurasjonsnivå. Denne prefiksen vil bli lagt til som en prefiks på prøve-ID-en for å skille mellom prøver opprettet gjennom ulike LMS-er.
  • Bør settes på verktøy-konfigurasjonsnivå.

Feilsøking (Debug)

Hvis verktøykonfigurasjonen ikke fungerer som tiltenkt, kan feilsøkingsmodus (debug mode) slås på. Dette gjøres med den egendefinerte parameteren debugview.

debugview

  • Hvis false, fungerer kommunikasjonen mellom LMS-et og IA som normalt.
  • Hvis true, aktiveres feilsøkingsmodus, noe som betyr at brukeren kan se forespørselen som ville blitt sendt fra LMS-et til IA. Når feilsøkingsmodus er på, når ikke forespørselen IA, og vil derfor ikke ha noen innvirkning i IA.

Prøveinformasjon

For LMS-er som tillater at egendefinerte parametere defineres på prøvenivå, er dette parameterne som kan brukes. Det er mulig å definere informasjon om IA-prøven i LMS-et via enkelte egendefinerte parametere.

inspera_test_start_time og inspera_test_end_time

  • Definerer henholdsvis start- og sluttidspunkt for prøven. Disse må være tidsstempler i ISO-format (f.eks. «2023-09-06T21:04+02:00» eller «2023-09-06T19:04Z»).
  • Hvis disse ikke er satt, må de settes i IA før prøven aktiveres.

keep_test_title (denne bør alltid settes til true)

  • Hvis false, vil navnet på prøven i IA bli erstattet med navnet som kommer fra LMS-et.
  • Hvis true, blir ikke navnet på prøven i IA endret. Dette må brukes i tilfeller der LMS-et ikke sender tittelen ved hver oppstart (f.eks. D2L).
  • Bør settes på verktøy-konfigurasjonsnivå.

lti_candidate_extratime

  • Angir ekstratid i minutter for alle kandidater.
  • Standardverdi er 0.

assessment_path_parent

  • Hvis true, vil prøven i IA bli opprettet som et vurderingsforløp (Assessment Path).
  • Hvis en ID sendes, må det være ID-en til vurderingsforløpet som denne prøven skal opprettes under, f.eks. hvis URL-en for å få tilgang til hovedprøven for vurderingsforløpet er https://navn.inspera.com/admin#deliver-test/97539878, så er ID-en 97539878.

lti_test_template

  • Hvis false, er prøven som opprettes i IA ikke basert på en mal.
  • Hvis ID, skal ID-en som sendes være ID-en til malen som prøven skal baseres på, f.eks. hvis URL-en for malen er https://navn.inspera.com/admin#deliver-test/97539878, så er ID-en 97539878.

use_template_on_create (denne bør alltid settes til true for å forhindre at læreren glemmer det når maler brukes)

  • Dette er bare relevant hvis lti_test_template ble brukt. Å definere den for andre prøver har imidlertid ingen innvirkning.
  • Hvis false, vil eventuelle endringer bli overskrevet av mal-verdiene hver gang prøven startes fra LMS-et.
  • Hvis true, brukes mal-verdiene bare når prøven opprettes ved første oppstart.
  • Bør settes på verktøy-konfigurasjonsnivå for å unngå at lærere glemmer det.

Var denne artikkelen nyttig?

0 av 0 syntes dette var nyttig