Teknisen toteutuksen Q & A

Peppi:

• Ei vielä selvillä, "kevään puolella" tässä vaiheessa aikamääreenä
• Mika täsmentää Pepin kehitysprojektin aikataulua
• Ei tiedossa tässä vaiheessa pilottitarpeita, mahdollisesti tulossa (mikäli tulee, käsitellään näissä palavereissa)
• Update 18.11.2019
  • Pepin riken kehityspaketti ykköstä ollaan parhaillaan testaamassa 2.0-versiota vasten

Primus/Wilma

• Käynnissä toimittajan kanssa suunnittelu toteutusmallista; pisimmällä ollaan Savonian tarjonnan esittämisestä muille
• Keväällä jossakin vaiheessa tavoiteaikataulu alustavasti
• Update 18.11.2019:
  • keskustelu käynnissä edelleen toimittajan kanssa; tehty konkreettinen ehdotus ja avainkysymys on, miten opiskelijalle näytetään laaja tarjonta ja mahdollisesti tehdään suodatuksia

Sisu

• Ensi vuoden syksyllä kälikehitys alkamassa, mahdollisesti jo sitä ennen rajapinnoista tietojen ulos ottaminen
• Täsmentyy vähitellen, mahdollisesti joidenkin tietojoukkojen (suoritukset esim.) osalta aiemmin 

RIPA

• Vähintään kuukausi ennen tuotantokäytön alkua oltava tieto tuotantoon siirtymisestä, ts. jos halutaan rajattua käyttöönottoa, siitäkin tieto hyvissä ajoin

Kuinka paljon ennen versioiden julkaisua ekosysteemeillä tulisi olla tieto tulevista muutoksista?

Versiointikäytännöistä dokumentti Versionumeroinnin kuvaus

Jos rikkovia muutoksia, viikon varoaika

Nyt 2.0 -versio on tulossa ja siinä mukavia rikkovia muutoksia.

Sovittiin, että hakufiltteröinti tehdään alkaneessa sprintissä kärkeen ja sisällytetään 2.0 -versioon - päivitetään heti valmistumisen jälkeen

Sovittiin, että päätös toteutustavasta valmistellaan kokouksen ulkopuolella. Katsotaan mm. yleisten konventioiden näkökulmasta, huomioidaan toteutuksen työmäärä tässä casessa ja mahdollisesti eskalaation näkökulmasta.

Päätös asap.

Sami:

"Lyhyen selvityksen perusteella tästä ei ole yhtä oikeaa hyvää käytäntöä, vaan tämä liittyy tapauskohtaisesti käytettyyn ohjelmointikirjastoon. Perustelut: projektissa on jo käytetty toteutuksessa tiettyä, yhden käytännön muotoista tapaa, Ripan päähän muutoksen laajuus olisi arvioituna verrattain suuri koskien kaikkia localizedstring-käsittelyja,  Pepin osalta arvioitu muutos oli suuruusluokaltaan rajallinen. -> pitäydytään nyt tehdyssä ratkaisussa."

Tiedossa ei ole, että muissa ekosysteemeissä olisi pohdittu tätä käyttötapausta.

Sami: 

Tässä voisi soveltaa sitä, että opintosuoritusten siirtoon on oma vaihtoehtoinen reititystyyppinsä, jossa ei käytetä opiskelijan rekisteröintipyynnön tietoja. Tämä on ajateltu sitä varten, että vaikka koko prosessia ei pystyttäisi aluksi tukemaan ilmoittautumisesta lähtien, niin suoritusten siirron automatisointi toisi silti hyötyjä. Vastaanottavassa päässä suorituksen kohdentaminen voi järjestelmästä riippuen vaatia jonkin toimenpiteen. Tuossa casessa ilmoittautuminen ei siis tapahtuisi palveluväylän kautta, ja jos opiskelija haluaa suorituksen viralliseksi, tuo prosessi tapahtuu järjestävässä korkeakoulussa. Tässä yhteydessä muodostettavaan opiskeluoikeuteen olisi tärkeä saada kotikorkeakoulun tieto, jonka perusteella suoritustiedon voisi välittää. Tämä voisi siis toimia nyt toteutetulla mallilla ihan ok.


Käydään läpi kokouksessa tikettien tavoite ja toteutusmahdollisuudet

Keskustelu

• Todettiin, että toiminnallisesti olisi hyödyllistä pystyä hakemaan samaan aikaan sekä opintokokonaisuuksien, -jaksojen että toteutusten tietoja
• Tarjontatiedot ja toteutustiedot ovat eri indekseissä, mikä tarkoittaa sitä, että ensin haetaan tarjonta ja sitten toteutukset 
• Mahdollista olisi toimia niin, että viedään vain hakua kiinnostavat toteutuksen kentät tarjontaindeksiin
• Edellyttää tiketin 365 tarkempaa määrittelyä, jotta tiedetään toteutusten relevantit kentät
• Työmäärällisesti muutos arviolta noin 3 - 4 htp
• Kokouksessa todettiin, että tämä olisi järkevä kehityssuunta
• Lauri juttelee Samin kanssa, onko ok lähteä muuttamaan. Jos ok
  • määritellään muutostarve
  • toteutetaan

Varmistetaan, onko määrittely ymmärretty oikein

• Ks. edellinen kohta

Pepillä ja Sisulla ei tarvetta studyElementIdentifierCode:lle, onko Primus/Wilmalla? 

• Ei ole tarvetta
• Arvioidaan muutostarvetta ja -vaihetta, kun kevään resurssitilanne selviää → Lauri R tekee tiketin

Onko Peppi-kehityksen kannalta tarpeellista saada kuinka paljon ennen stagingin päivitystä siitä tieto? Jos kriittistä, sovitaan päivitysmallista (esim: 1 pv ennen), jos ei, Gofore päivittää aina, kun sopiva hetki oman työn kannalta

Sovittiin seuraavasti:

• Maanantaina sprintin päättyessä uusi version vanhaan testiympäristöön noin klo 15.00
• Keskiviikkona päivitetään staging klo 12.00, jos ei ongelmia päivittämisen osalta 
• Muutetaan mallia tarvittaessa kokemusten mukaan

CourseUnitRealisation

• Toteutuksen skeemassa ei ole paikkaa toteutuksen nimelle

StudyElementReferences (CourseUnit OR AssessmentItem)

• Onko tämä joku luettelo opintojakson koodeista mitä toteutuksella voidaan suorittaa?

Kyllä. viittaus joko opintojakson tunnisteeseen tai arvioinninkohteen tunnisteeseen.

Miten opiskelija lyö lukkoon ilmoittautumisen yhteydessä että minkä opintojakson opiskelija suorittaa tämän toteutuksen yhteydessä jos vaihtoehtoja on useita (jotenkin olisi helpompaa että voisi suorittaa vain tietyn opintojakson aina eikä valintaa)

Ilmoittautumisen yhteydessä tämä valinta tulisi tehdä. Kun asiaa lähestytään siten, että esitettäisiin opintojakson ja sen toteutuksen tiedot yhdessä, tämä olisi ehkä yksinkertaisinta ratkaista. Jos opiskelijan hakunäkymässä haetaan tietoa toteutuksista, jolloin nämä viittaukset ovat lisätietoina, tässä voisi käyttää ensisijaisen opintojakson tietoa.

groupSelections

• Vaatii tarkan määrityksen miten tulee toimia eri tilanteissa (pitäisi olla ”yhteinen” käli eri järjestelmissä jotta tuon toiminnon monipuolisuus menisi aina samalla tavalla eri järjestelmissä)

Tätä on hyvä tarkentaa, on keskitetyn palvelun osalta toteutuksessa loppukeväällä.

questionSets

• Miten tämä pitäisi mallintaa koska meillä ei tällaisia ole mutta toisaalta tuo tieto pitäisi pystyä viemään sellaiseen korkeakouluun jolla tuo on käytössä. Ts. sama haaste kuin tuossa ensimmäisessä. Meillä ei ole siis tällä hetkellä tietomallia tällaisen tiedon käsittelyä/tallentamista varten..

Tätä on hyvä tarkentaa, on keskitetyn palvelun osalta toteutuksessa loppukeväällä.

Pitäisikö kansallisessa Rike-palvelussa (esim. verkoston luonnin yhteydessä) olla joku pakollinen linkki tai palvelussa tehtävä muotoiltava teksti (kieleistetty), johon laitetaan korkeakoulun info ja joka voidaan nostaa aina opintojen haun yhteyteen (kun opiskelija hakee opintojaksoja/toteutuksia). Tuo info siis kertoisi opiskelijalle

• Ennen ilmoittautumista
  • Ehkä jotain tietoa verkostosta
  • Kohdekorkeakoulun yhteystiedot
  • Linkit mistä voin katsoa opinnon (toteutuksen) opetusjärjestelyt etukäteen, esim. linkki lukkarikoneeeseen
• Ilmoittautumisen jälkeen
  • Miten saan tunnukset kohdekorkeakoulun järjestelmiin yms…

Kuulostaa järkevältä asialta, täytyy selvittää mikä olisi luontevin kohta tuolle tiedolle tai onko jokin olemassaoleva organisaation kuvaukseen liittyvä kenttä soveltuva tähän.

Täytyykö Pepin kysellä tietoja suoraan ES indeksistä ES:n käyttämällä notaatiolla? Vai tuleeko JSON/REST-rajapinnat

Onko heittää aikatauluarvioita milloin RIKE:n tarjoamat REST rajapinnat ovat saatavilla swagger muodossa? 

Onko verkoston id kenttä sama kuin vanhan määrityksen "yksilöivätunniste (OID)"?

Vastaavasti organisationId:ssa on varmaankin listattu verkoston organisaatioiden OIDit?

Tilanne, jossa opintojakson toteutus julkaistu kansalliseen rike-palveluun, mutta siihen liittyvää äitiopintoa (opintojakso) ei ole julkaistu kanalliseen palveluun.

• Voidaanko esim. Pepin päästä (jos halutaan julkaista vain toteutus) viedä mukana myös opintojakson tiedot vaikka itse opintojaksoa ei ole julkaistu rike-verkostoon? Ts. Rike-opiskelijan käyttöliittymään voisi hakea kansallisesta palvelusta opintojakson tiedot toteutuksen perusteella vaikka itse opintojaksoa ei olisi julkaistu.
• Jääkö kerran julkaistun opintojakson tiedot pysyvästi rike-palveluun? Esim. jos vanhennamme verkoston opintojaksolta niin ”vanhoille” opiskelijoille jää saataviksi edelleen opintojakson tiedot mm. käyttöliittymiin (saman tyyppinen case kun tuo missä toteutus on julkaistu mutta opintojakso ei).