Innhold
- Tidspunkt: Torsdag 3. oktober 2013 10:00-15:00
- Tilstades frå UAIT: jokim, rodseth
- Tilstades frå eSAK: Lena, Astrid
1 Agenda
Mål for dagen: Å få ein felles forståelse frå begge partar, og bli enige om kva som skal synkroniserast. Dette så UAIT kan lage løysingsforslag og er forberedt til arbeidsmøtet med Evry.
Vi vil også trenge å søke om IS-midlar, som har ein kort frist, så vi treng fortgang i dette.
2 Intro
- Må søke om IS-midlar for utvikling frå Evry. Fristen går ut 15. oktober, altså før arbeidsmøtet med Evry.
- Johannes Paulsen skulle snakke med Julie om søknad om midlar for EIS-prosjektet.
- ePhorte-løysinga UiO bruker er lik med UiB, mens andre har gått over til Software Innovation.
eSAK viste fram ePhorte og gav ein introduksjon til korleis det ser ut og oppfører seg.
Vi gjekk vidare inn i detaljane i kva som skal synkast og ikkje, og vurderte kvar enkelt del.
3 Entitetar
Vi diskuterte dei ulike "entitetane" som er relevante for synken, for å sjå om dei trengde å synkast eller ikkje.
Merk at ein sletter aldri i ePhorte, ein kan berre sette entitetar som "utgått", ved å sette ein til-dato, eller deaktivere.
3.1 Enhetar
Er mismatch mellom stedkode (som er "enhetsforkortelse" i ePhorte), og "kode" (som er forkortelse, td. OPA-ESAK). Ein har då ei mapping mellom desse.
Det er uvisst kvifor stedkoden ligg som enhetsforkortelse i ePhorte, og ikkje som "kode", sidan det er ein identifikator og forkortelsar ikkje treng å vere unike. Det var kanskje ein grunn til det, og eSAK ønsker å ikkje gjere noko med dette, då dei ikkje veit kva konsekvensar det har.
Har ikkje hatt synk av enhetar til no, då den gamle synken ikkje støtta dette. Har gjort dette manuelt i dag. Får e-post frå SAPUiO om endringar.
I dag, ved omorganiseringar (og når tilsette slutter/flytter?) vert gamle roller stengde samme dag. Skaper jobb for arkivledelsen, då folk må skynde seg og flytte saker over til ny enhet før den lukkast.
Er det ein mulighet å la vere med å fjerne roller før etter ei stund? Arkiv var usikker, då det skaper andre utfordringar. Vart diskutert ulike løysingar her, til dømes å ikkje stenge enheter og/eller roller før etter ei stund - dette skaper utfordringar med til dømes utsending av brev til riktig enhet, og avsendaradresser - arkivarar kan begynne å saksbehandle på feil stad. Er også andre problem med ryddingar, når det er feil.
Virker som at det er bedre at enhetar vert handtert manuelt, som i dag.
Kodane som brukast i ePhorte er akronym som registrerast i SAPUiO. Det er desse vi då bruker vidare. SAP har ei liste over stedkodar og akronyma. Arkiv har likevel gjort endringar i kodane for å bl.a. unngå duplisering, og til dømes ved omorganiseringar - USIT har td. blitt USIT3 etter omorganiseringa 1. januar 2013.
Bruker stedkoder i automatikken i dag, sjølv om dei ligg på feil stad.
"Nyttårsproblemet" skaper arbeid, men det er ikkje det største problemet.
Vi bør likevel diskutere med Evry-konsulenten om dette, om det er mulige og enkle løysingar for dette, men den midlertidige konklusjonen er å ikkje synke enhetar.
3.2 Arkivdel
"Arkiv" er "UiO", som har fleire arkivdelar under detta, til dømes "Personal". Dette er heilt uavhengig av enhetar (kostnadsstader).
Det er ulike reglar for dei forskjellige arkivdelane.
Journalenhet er knytta til ein arkivdel.
Snakka om at var feil i systemet (usikkert om problemet låg i Cerebrum, ePhorte eller ein kombinasjon) - journalenhet er registrert på enhet, men burde vore på personrolle - ein person skulle eigentleg kunne vore registrert på fleire journalenheter og bestemt dette sjølv etter kva sak ein jobber med.
Skulle vore mulig å registrere fleire journalenhetar for ein person, så dei kan registrere på fleire journalenheter. Det samme gjeld også arkivdelane.
Lena testa i ePhorte under møtet, og kunne endre journalenhet på ein av rollene sine, men det hadde visstnok ingen konsekvensar (ho hadde testa dette tidlegare) fordi journalenheten som er knytta enheten som rolla hennar er knytta til overstyrer dette. Det er difor berre enhetar sine journalenheter som vert i praksis brukt, om eg forstod dette riktig.
Snakka om at dette med journalenheter fungerer ikkje. Dei kan difor ikkje bruke journalenheter i dag.
3.3 Personar
Personar skal per def alltid ha ei rolle, så alle med roller skal overførast. Personar utan roller får ikkje tilgang til ePhorte, så det er ikkje noko poeng i å overføre slike personar til ePhorte. Det virka likevel ikkje som skadeleg å overføre personar som ikkje har roller, men det er unødvendig.
Vi oppretter personar, men vi deaktiverer ikkje personen. Deaktivering gjerast i dag ved å sette ein til-dato på standardrolla. Dette fungerer ikkje alltid i praksis. eSAK viste døme på nokre brukarar som ikkje var stengde sjølv om dei har slutta.
Synken skal ikkje sjå på registreringar frå FS, personar skal alltid komme frå SAPUiO. Fagpersonar skal til dømes ignorerast med mindre dei også kjem frå SAPUiO.
eSAK registrerer ingen manuelle personar i ePhorte - har ikkje ein gang tilgang til dette. Det betyr at Cerebrum kan rydde utan komplikasjonar.
Diskuterte tilsatt-gruppene. Alle frå SAP som er i Feide skal ha tilgang, inkludert assosierte personer (gjester). Det er nokre grupper, som "ekstern konsulent" som ikkje skal ha tilgang automatisk, men eSAK kan legge dei til manuelt gjennom bofhd. Dei ønsker å videreføre dagens ordning.
Såg kjapt på dokumentet Assosierte brukere/gjester i SAPUiO <http://www.uio.no/for-ansatte/arbeidsstotte/personal/lonnsadmin/personal-og-lonnssystem/asosierte-brukere.html>.
3.4 Personroller
jokim informerte om prosjektet og ønsket om å innføre roller i SAP som også kan brukast i andre system. eSAK har ikkje vore borti der, men trur i første runde ikkje at det er mulig å få deira roller inn i SAPUiO, fordi det er altfor mange ulike roller for ePhorte, som ikkje har samme betydning som i bl.a. SAPUiO. Til dømes berre har dei ei rolle for å vise ein ekstra venstremeny. Måtte i så fall registrere nokre roller i SAPUiO og meir "lokale" roller i ePhorte. Dette er uansett fram i tid.
Standardrolla di bestemmer inngangsrolla di i ePhorte. Er den stengd får du ikkje logga på ePhorte.
I dag vert ein person berre automatisk registrert med ei rolle saksbehandler (SB) på ein enhet ein er tilknytta i SAPUiO. Kan vere ønskeleg å få ei slik rolle på alle enhetar ein er registrert på i SAPUiO, og ikkje berre ein av dei, som det visstnok er i dag. Arkiv var positive til dette. Er det likevel eit problem i samanheng slik som for omorganiseringar? Nei, ifølge Astrid.
Kan vere eit alternativ å lukke alle roller og ikkje berre standardrolla når ein slutter. Dette for å løyse problemet med at standardrolla ikkje vert lukka. UAIT kjem tilbake til dette i løysingsforslaget.
Vart diskutert kor mykje av roller som skal styrast i Cerebrum og ePhorte. Standard saksbehandlerroller MÅ inn frå Cerebrum, men er usikker på dei andre rollene.
Det er ønskeleg å sende feilmeldingar når roller ikkje er registrert på ein enhet som er Arkivsted i SAPUiO. Automatikken kan fortsette med dagens implementasjon og hoppe eitt hakk opp i organisasjonshierarkiet og bruke den enheten dersom det er ein arkivstad, men berre eitt hakk.
Roller kan stengast automatisk, men må kunne gjenopnast att, eller personar kan få ny rolle til stengde enheter. Dette kan komplisere automatikken, men er visstnok allereie implementert i dag. Dette vart fiksa av jazz etter 1. januar 2011 (omorganiseringa av MedFak), men usikker på om det var i 2011 eller 2012, mest truleg "rett før" mars 2012. UAIT må sjå på stenging av rollene og korleis det gjerast i dag, så kan ikkje konkludere på dette i dag.
Arkiv betaler lisens per person. Det er difor veldig ønskeleg å stenge rollene til dei som ikkje lenger er aktive.
3.5 Tilgangskoder
Endrer tilgangskoder i massevis, og har masse kodar per person! Bruker masse tid på dette i ePhorte, spesielt ved omorganiseringar.
Einaste automatikken som er ønskeleg er å legge til XX på personen sjølv (så personen får sjå sin eigen post). I Cerebrum er dette allereie implementert, men knytta til ein gamal tilgangskode AR.
Snakka om problemet med at ein fekk over 50000 tilgangskoder, som webservicen til ePhorte ikkje takla. Løysinga var at ein måtte slå av denne synken og registrere alle kodane manuelt i ePhorte. Lene meinte det var mykje enklare å registrere tilgangskodar i bofh, var mykje kjappare å gjere det der. I ePhorte tek det veldig lang tid å berre få registrert ein av kodane.
Dersom vi skal innføre tilgangskodar frå Cerebrum igjen krever det at synken må gå kjappare enn berre ein gang i døgnet som i dag. Elles må eSAK registrere tilgangskodane både i bofh og ePhorte, då arkivarar treng å jobbe i dag og ikkje i morgon.
Tilgangskodar skal ikkje stengast automatisk!
4 Oppsummering
Nemnde synkroniseringsalternativa vi hadde:
EIS henter data frå AD. Dette går ikkje, då må vi ha altfor mykje data inn der, som er ein stor jobb.
EIS henter data frå LDAP. Dette kan gå, men krever at vi legg inn meir data i LDAP, til dømes tilgangskodar og roller. Det er mulig, men er usikker på om det er ønskeleg å gå den vegen.
At vi snakker med EIS direkte. Ut frå det vi har sett på av dokumentasjon, fraråder UAIT at Cerebrum snakker direkte med denne. Det krever både kompetanse og innsikt i ePhorte, og vi står i fare for å ødelegge heile ePhorte-instansen sidan vi har tilgang til veldig mykje av databasen.
At Evry utvikler ein webservice mellom oss og EIS, som Cerebrum snakker med. Dette var Evry sitt forslag frå forrige møte, og er framleis aktuelt.
At vi lager ein webservice som Evry utvikler integrasjon mot. Vi gir då tilgang til ein webservice med relevant informasjon frå Cerebrum, som Evry lager ein synk mot og oppdaterer ePhorte gjennom EIS.
Alexander var mest positiv til denne løysinga, bl.a. for å kunne gjenbruke webservicen for andre integrasjonar seinare.
Evry nemnde ikkje dette som eit alternativ på forrige møte, så vi må høyre om det er eit reelt alternativ for dei, og få ei estimering på kva det vil koste.
Det er i hovudsak dei to siste alternativa som er aktuelle for UAIT sin del.
4.1 Vidare arbeid
Vi må få sendt inn IS-søknad kjapt! Fristen er 15. oktober.
jokim og rodseth lager dokument med aktuelle løysingsforslag og begrunnelsar neste onsdag. Tek også kontakt med Evry-konsulenten for å få ei kjapp estimering frå si side. Sender dette vidare til eSAK, Julie og Johannes, så Julie og Johannes kan sende inn søknad om IS-midlar.