Innhold
Bakgrunn
Prosjektet BOTT-ØL innfører nytt system for økonomi og lønn ved BOTT-universitetene, og UiO er blant universitetene som skal ta i bruk den valgte løsningen fra DFØ.
Overgangen til nytt system innebærer at Cerebrum må hente data om organisassjonskart, ansatte og ansettelsesroller fra DFØ-SAP sine systemer fra og med produksjonssettingsdatoen, som er satt til 2020-01-01.
Advarsel
Dette dokumentet er work in progress.
Dagens integrasjon
Dagens integrasjon mellom SAPUiO og Cerebrum er delt i:
- Fullsynk fra SAPUiO til Cerebrum
- Fullsynk fra SAPUiO til Cerebrum, i form av en sap2bas.xml-fil. Oppdatert fil hentes hver time (TODO: men hvor ofte genereres ny SAP?) og fungerer som en cache for SAP.
- Fullsynk fra Cerebrum til SAPUiO.
- Fullsynk fra Cerebrum til SAPUiO, i form av en bas2sap.csv-fil. Filen bygges tre ganger i døgnet (natt, morgen, ettermiddag).
- INTARK-integrasjon
- INTARK-integrasjon for ansatt-data og ansatt-roller, i form av en tjeneste som lytter etter meldinger fra SAP og oppdaterer Cerebrum (eller publiserer meldinger til en egen kø for senere prosessering). Hver melding fører til en full oppdatering av persondata for en ansatt i Cerebrum.
Merk at ``sap2bas.xml`` benyttes i flere steg etter henting. Filen inneholder typisk mer detaljert informasjon om ansatte enn hva som importeres i Cerebrum. Det viktigste som ikke importeres, og som gjerne sap2bas.xml må benyttes til er ansettelsesroller. I Cerebrum vil samlingen av alle roller reduseres til tilknytninger. Rolle til tilknytning er ikke en-til-en. En blir derfor nødt til å slå opp i SAP/sap2bas.xml for å se mer detaljer om ansettelser (start- og sluttdato, mg/mug, stillingsprosent, permisjon, stillingskode, tittel).
Fullsynk til Cerebrum
Filen som benyttes i fullsynk, sap2bas.xml benyttes i flere steg videre. Primært brukes den kanskje til OU-import, men flere eksporter og vedlikeholdsscript ser også på denne filen for å få et innblikk i SAP-data.
- CRISTIN
OU-struktur går direkte fra sap2bas.xml til Cristin-eksport.
Rolleinformasjon fra sap2bas benyttes også for å skille mellom ulike typer ansettelser, både for å filtrere ut personer (bl.a. på mg/mug), og for å kreve samtykke for ikke-vitenskapelige ansatte.
Notat
Dette erstattes av en ny CRISTIN-integrasjon, som må være klar før overgang til DFØ-SAP.
- LDAP
sap2bas.xml brukes for å generere stillingstitler for ansatte med delte stillinger.
Cerebrum tar kun vare på en stillingstittel per person - dette er stillingstittel for det som er hovedstilling ved import fra SAP. Enkelte ansatte har imidlertid delte stillinger hvor stillingstittel er ulik per ansettelse. En workaround som har blitt brukt er derfor å lage en LDIF-fil som supplerer org.ldif med stillingstittel per ansettelsesrolle direkte fra sap2bas.xml.
Notat
BNT/WEB/GPL (Vortex) skal ta seg av problemstillingen med delte stillinger. Det blir derfor ikke behov for å videreføre ordningen med delte stillinger i LDAP.
TODO: Diskuter problemet
DFØ-SAP har ikke stillingstitler på engelsk. Vi vil kun få norsk tittel, dette påvirker primært LDAP-eksport (Feide).
De eksisterende UH-integrasjonene med DFØ-SAP benytter et kodeverk i Cerebrum for å finne stillingstittel ut fra stillingskode. En potensiell løsning vil kanskje være å implementere dette på en bedre måte, slik at Cerebrum har et felles kodeverk for stillingstitler.
- Slutte å tilby stillingstittel på flere språk?
- Implementere kodeverk med tittel på ulike språk?
TODO: Hvis kodeverk skal implementeres
Så bør vi avklare en del ting:
- Stemmer stillingstitlene fra SAPUiO/DFØ-SAP med lønnsplanheftet i HTA? Hva er riktig kilde for stillingstitler?
- Bruker UiO (eller andre) stillingskoder utenfor lønnsplanheftet?
- Hvor kommer de engelske stillingstitlene fra?
- Medfak
sap2bas.xml brukes ved eksport av ansatt-informasjon til systemer hos medisinsk faktultet.
Det opprettes en CSV-fil per faktultet, med en rad per ansettelsesrolle. Dette inkluderer stillingskode, stillingsprosent og annen informasjon som ikke lagres i Cerebrum, men suppleres med informasjon om OU, person, og brukerkonto fra Cerebrum.
Notat
Informasjonen benyttes i et eget system for å vedlikeholde e-postlister. Medisinsk Fakultet v/Per Grøttum er alt i gang med å se på alternativ løsning for å få data fra DFØ-SAP og Cerebrum gjennom IntArk.
Notat
Per Grøttum og drift@medisin.uio.no vart varsla om nedlegginga seinast 9. oktober 2020. Vi kan med andre ord la vere å vidareføre desse, med mindre medfak seier frå.
- OU-import
sap2bas.xml brukes for å gjøre fullsynk av organisasjonstre. Årsaken til at OU batch-importeres fra fil er flerdelt:
- OU-import er relativt generell (støtter import fra FS-data, UiT bygger en sap2bas-kompatibel eksport av OU-data).
- Det er ikke blitt prioritert å gjøres noe med.
- Det er komplisert å endre på OU-er - OU-treet må være konsistent, og helst et tre uten flere røtter. (hva skjer f.eks. med under-OU-er hvis en OU slettes?)
Notat
OrgReg kjem til å ta over som kjeldesystem for organisasjonsinformasjon rundt 1. desember 2020. Integrasjon av OU-data håndteres utenfor DFØ-SAP. Vi kan derfor anta at OU-er allerede skal eksistere i Cerebrummed idenfikator fra DFØ-SAP.
- Ansattgrupper
sap2bas.xml brukes for å oppdatere ansattgruppene uio-tils og uio-ans. Må se på sap-data for å bl.a. identifisere midlertidig ansatte.
uio-ans - alle som er ansatte akkurat nå (HOVEDSTILLING, BISTILLING, enkelte GJEST)
uio-tils - alle som er BILAG akkurat nå, eller har hatt BILAG siste 180 dager.
Advarsel
TODO: Bug
Det er en feil i update_employee_groups.py, brukekontoer som er expired meldes ikke ut. Dette skaper ikke direkte problem, disse medlemmene blir ikke med i eksporter/ansees ikke som medlemmer, og vil eventuelt blir meldt ut dersom brukerkonto blir "re-aktivert"
Se CRB-3176
TODO: Avklare innhold
- uio-tils
- Er det forskjell mellom uio-ans og meta-ansatt-900000? Hva er i så fall forskjellen? Bør det være forskjell?
Notat
Løysast truleg av CRB-3327, som går over til å bruke meta-ansatt-900000.
- Printerkvote
bas2sap.xml brukes for å identifisere brukere som skal ha fritak fra utskriftskvote.
Kvotereglementet er implementert noe a-la:
- Alle som er studenter er i utgangspunktet omfattet av kvotereglement.
- Alle som (i tillegg) er fast ansatt (++?) er ikke omfattet av kvotereglementet.
- Alle som har en hvitlistet gjesterolle fra SAP (cereconf.PQUOTA_ROLLER_FRITAK), er fritatt fra kvotebegrensninger.
- Personer kan være markert med kopiavgift-fritak i FS (betfritak).
quota_update.py kan gi enhver mareritt.
TODO: Kan dette forenkles? Trenger vi å skille mellom fritak og unntak?
TODO: Avklare bruk
Er det behov for å skille mellom unntak og fritak?
TODO: Diskutere løsning
Notat
Oppretta sak for vidare arbeid: CRB-3333.
Notat
Utskrift-drift bekrefter at dei ikkje lenger vil trenge info om fritak frå utskriftskvoter frå Cerebrum - https://rt.uio.no/Ticket/Display.html?id=4093259 - og kan tilpasse seg så vi kan fjerne dette seinast 1. mai 2020.
- Kortsystem
sap2bas.xml brukes for å identifisere ansatte?
Informasjon fra SAP brukes for å finne alle ansatte med ansettelsesroller, men gjør ingen filtrering på start-/sluttdato eller rolletype. Roller som er 100% permisjon utelates.
Notat
Tjenesten er blitt erstattet med en ny integrasjon, Cerebrum-eksporten er blitt fjernet.
Meldingsbasert integrasjon av persondata
Den eksisterende meldingbaserte integrasjonen mellom SAPUiO og Cerebrum sørger for oppretting, oppdatering og fjering av persondata i Cerebrum.
Integrasjonen kan generaliseres med:
- Identifisere
Steg 1 vil være å identifisere den ansatte:
Dette innebærer å hente ut ansattnummer fra melding, slå opp ansatt i SAP for å hente ut andre person-identifikatorer (fnr, passnummer), for så å søke opp person-objekt i Cerebrum. Her brukes alle identifikatorer fra alle kildesystemer, for å eventuelt oppdage duplikater, og for å unngå at det lages nye duplikater.
Her vil en også måtte identifisere med andre potensielle identifikatorer, som f.eks. navn og fødselsdato, dersom det skal implementeres en form for varsling for personer som ser ut til å allerede finnes.
- Filtrere
En har identifisert hvorvidt person finnes i Cerebrum. Steg 2 vil være å filtrere bort ansatte som ikke lenger hører hjemme i Cerebrum. Dette gjøres ved å sjekke ansettelsesroller i SAP - det er nemlig dette som bestemmer om den ansatte skal overføres til Cerebrum. Ut fra dette kan vi danne et beslutningsgrunnlag for hva som skal utføres videre:
- Ansatt i SAP, ikke i Cerebrum: opprette og oppdatere person-objekt
- Ansatt i SAP, finnes i Cerebrum: oppdatere person-objekt
- Ikke ansatt i SAP, finnes i Cerebrum: avvikle/fjerne personinformasjon fra SAP
- Ikke ansatt i SAP, ikke i Cerebrum: ignorere - her er det ikke noe å gjøre
Disse oppgavene kan videre beskrives som:
- Opprette person-objekt
En enkel oppgave - det eneste vi må passe på er at personobjekt opprettes og får en ekstern identifikator i en og samme database-transaksjon. Dette for å unngå at det opprettes person-objekter uten noen form for identifikator som gjør at vi finner det igjen senere.
Ved oppretting vil en også måtte sette en fødselsdato og kjønn.
- Oppdatere person-objekt
Hoved-bolken av arbeidet som utføres av SAP-integrasjonen er å oppdatere persondata og tilknytninger i Cerebrum basert på kildedata. Oppgaven kan deles inn i flere steg:
- Mappe og oppdatere basisinformasjon (fødselsdato, kjønn)
- Mappe og oppdatere person-identifikatorer (ansattnummer, fnr, passnummer)
- Mappe og oppdatere tilknytninger basert på ansettelsesroller og gjesteroller
- Oppdatere navn
- Mappe og oppdatere adresser (postadresse, besøksadresse, privatadresse)
- Mappe og oppdatere kontaktinformasjon (telefonnummer, e-postadresse)
- Oppdatere stillingstittel
- Oppdatere andre ting (f.eks. reservasjon mot visning i kataloger, account_type i de tilfellene hvor dette kan gjøres uten manuelt inngrep)
Med "mappe" menes å filtrere og oversette typer og verdier fra SAP-sk til Cerebrum-sk. F.eks. vil kjønn representeres som "Mann"/"Kvinne" i SAP, mens det i Cerberum er konstant-objekter med andre verdier.
TODO: Hva er kildesystem for fødselsdato, kjønn hvis SAP og FS er uenige? Hvordan er dette i dag?
- Fjerne personinformasjon
Dersom en ansatt "forsvinner" fra kildesystem (ikke lenger har en aktiv ansettelse), vil vi måtte fjerne personinformasjon som kommer fra dette systemet.
Dette involverer fjerning av all informasjon vi er i stand til å oppdatere fra kildesystem (i oppgavene for å opprette/oppdatere person-objekt) - med unntak av person-identifikatorer (enn så lenge vi har hjemmel for dette - for å kunne gjenopprette brukerkonto).
I tillegg finnes det opprydding av bl.a. account_type i de tilfellene hvor dette er trygt å gjøre.
- Ignorere
- Dersom person-objekt ikke finnes i Cerebrum og heller ikke skal eksistere her, så vil det ikke være grunn for å utføre noen videre oppgave.
Ny integrasjon
Ny integrasjon med DFØ-SAP vil bestå utelukkende i meldinger og API. Alle endringer vil bli publisert til en INTARK-exchange, og Cerebrum vil kunne abbonnere på disse i egne meldingskøer. Ved prosessering vil Cerebrum bli nødt til å slå opp informasjon i API-er.
Endringer
- Organisasjonstre
Organisasjonsenheter og kostnadssteder er helt adskilt i DFØ-SAP.
TODO: Betyr dette at organisasjonstreet endres ved overgang til DFØ-SAP? Dette er i utgangspunktet ikke et problem for Cerebrum-integrasjonen, men kan ha innvikning på andre systemer som Cerebrum eksporterer data til.
TODO: Vil dette påvirke fakultet/institutt/gruppe fra FS?
- Ingen stedkoder
Organisasjonsenheter vil ikke ha stedkoder i DFØ-SAP.
Dette betyr at organisasjonsenheter må identifiseres på andre måter enn med stedkoder. Det vil i utganspunktet ikke være noe problem å koble OU fra DFØ-SAP til OU i Cerebrum ved hjelp av andre indentifikatorer, så lenge alle relevante OU-er i Cerebrum også har disse identifikatorene.
Et større problem er at Cerebrum i stor grad forventer at alle OU-er har stedkode i mange importer, eksporter, samt i en del forretningslogikk. Flere mottakssystemer av Cerebrum-data forventer også et organisasjonshierarki med stedkoder.
Dette kan delvis løses ved å fortsette å tildele stedkoder til OU-er (f.eks. i Cerebrum) mens stedkodebruken gradvis avvikles, og integrasjoner flyttes ut av Cerebrum.
- OU-navn
I SAPUiO finnes det tre navnetyper, på to språk som er i bruk i Cerebrum:
- Akronym (f.eks. USITINT)
- Kortnavn (f.eks. Ingegrasjon og elektronisk identitet)
- Fullt navn (f.eks. Seksjon for integrasjon og elektronisk identitet)
Disse navnene finnes på norsk og engelsk.
DFØ-SAP ser ut til å ha støtte for to typer navn, og kun på ett språk
- orgKortnavn (begrenset til 11 tegn)
- navn
TODO: Her finnes imidlertid også en type (f.eks "AVD") som kanskje kunne blitt brukt for å generere et fullt navn fra kortnavn?
Ved overgang til DFØ-SAP må dette løses på annet vis.
- Stillingstittel
I SAPUiO får man ut stillingstittel for hver stilling på norsk og engelsk. Stillingstittel for hovedstilling taes vare på og brukes i Cerebrum på begge språk.
DFØ-SAP ser ut til å kun tilby stillingstittel på ett språk.
- Manglende reservasjon
I SAPUiO registrerer den ansatte selv eventuelt behov for reservasjon fra katalogtjenester. Dette brukes av Cerebrum for å f.eks. markere person-objekt/bruker-objekt i LDAP slik at objektet ikke er offentlig tilgjengelig.
Notat
Dette skal allerede være implementert av DFØ. Trolig et eget attributt på den ansatte? Laga CRB-3331 for å ta oss av det.
- Endret kodeverk for stillinger og roller
Informasjons om ansettelser og andre roller i DFØ-SAP vil ikke stemme overens med kodeverket i Cerebrum. Vi må (i samarbeid med HR? BOTT-ØL?) utarbeide en oversikt over:
- Hvilke koder som er i bruk fra SAPUiO, og hvordan vi skal finne tilsvarende informasjon i DFØ-SAP.
- Hvilke eventuelle nye koder som finnes i DFØ-SAP, og hvordan disse skal håndteres.
Andre utfordringer og uklarheter
- DFØ-løsning er ikke klar
- Hvordan vil løsningen faktisk se ut? Dokumentasjon på API og meldinger/meldingsformat.
- Utkast til begrenset API
- Utkastet av API som finnes i dag virker noe begrenset. Ingen endepunkter for utlisting (det sies at dette skal finnes, men med begrenset tilgjengelighet), mye mindre informasjon per objekt, noen litt pussige relasjoner (f.eks. assignments/roles er ikke under person)
- Ukonsistent API
- Ulike datoformat på dato-felter
- Numeriske verdier som tekststreng (f.esk. "stillingsprosent")
- Enkelte verdier er egne objekt (annenId, stillKat), mens andre flates ut med prefix (privatPost*).
- camelCase og snake_case, sluttdato vs. endretDato
Dette er eksempler på ting som gjør at undertegnede lurer på om det er andre, udokumenterte pussigheter. Hva er verdien av "privatTlfUtland" dersom en person ikke har noe slikt telefonnummer registrert? Er det mulig å være registrert uten å ha en ansettelse? Hva skjer med "startdato" og MG da? Hva om man ikke har privat postadresse eller evt. bruker postboks? Hva skjer da med f.eks. "privatPostnr"
- Dato-informasjon
Hvordan vil sammenhengen mellom start- og sluttdato i API og meldinger være?
Slik undertegnede har forstått vil det gjerne sendes melding om at en stilling er opprettet med startdato i fremtiden, men stillingen vil ikke være synlig i API nettopp fordi startdato ikke har blitt nådd.
Løsningsforslag
Dagens import av personer og personroller kan i første omgang beholdes mer eller mindre slik som den er. Den må selvsagt skrives om en del for å håndtere datastrukturer, endepunkt og formattering - men vi vil ha omtrent samme funksjonalitet.
De største utfordringene vil være knyttet til endringer i OU/Stedkode, samt mangelen av en sap2bas.xml for eksporter som sammenstiller informasjon fra SAP, FS og Cerebrum.
Import av OU-er
Ut av boksen vil vi ikke bli kvitt behovet for stedkoder -- det er mye funksjonalitet knyttet til disse identifikatorene, både i Cerebrum, systemer som Cerebrum eksporterer data til, samt systemer som indirekte kobler Cerebrum-data og egne data.
Vi er derfor avhengige at OU-er løses uavhengig av HR-data. Inntil videre antaes det at et eget system for OU-data, stedkoder og OU-navn vil eksistere, og at en integrasjon mellom dette systemet og Cerebrum implementeres, slik at det vil være mulig å koble DFØ sine interne OU-identifikatorer mot eksisterende OU-objekter i Cerebrum.
Skulle dette vise seg å ikke være oppnåelig, vil vi måtte komme opp med en alternativ løsning. Dette kan for eksempel være å vedlikeholde OU-data manuelt inntil videre:
- OU må opprettes manuelt i Cerebrum, lenkes mot SAP-identifikator og tildeles stedkode.
- Bofh-kommandoer (evt. annet grensesnitt) for manuelt vedlikehold av stedkode-data implementeres.
- Varsel dersom SAP melder om endring på OU som ikke finnes i Cerebrum, eller får informasjon om roller på en OU som ikke finnes i Cerebrum.
Bruk av sap2bas.xml
Bruk av sap2bas.xml må avvikles helt. Problemstillinger og løsningsforslag rundt dette er oppsummert under hvert enkelt bruksområde i fullsynk til Cerebrum.
Ansattgrupper
Gruppene uio-tils og uio-ans kan være utfordrende å avvikle. De har eksistert lenge, og er sannsynligvis brukt i utstrakt grad.
Det vil imidlertid være en smal sak å lage en erstatning som bygger disse gruppene basert på informasjon som allerede finnes i Cerebrum.
Vi kan basere oss på contrib/create_flattened_group.py (eller lage tilsvarende script) som kan lage:
- Utflatet versjon av en annen gruppe (meta-ansatt-900000)
- med navnemapping (meta-ansatt-900000 > uio-tils)
- og oversette person-medlem til primærbruker
Denne endringen er delvis gjort ifb. med avklaring, bør vurdere manglende enhetlig definisjon av primærbruker. Må også vurdere ulikhetene mellom innhold i meta-ansatt-900000 og uio-tils. Dersom disse to gruppene skal være ulike, bør det undersøkes hva kriteriene for medlemsskap skal være og lage et script som finner de korrekte medlemmene.
Notat
Dette er jobba med i https://jira.usit.uio.no/browse/CRB-3327
Refaktorering av sap-consumer
SAP-consumer bør refaktoreres - dette for å:
Omstrukturere dagens SAP-consumer i ulike "layers":
Hente relevante data om person
Oversette til mellomformat (felles datastruktur for SAPUiO og DFØ-SAP)
Oppdatere person i Cerebrum med mellomformat - vil nå fungere likt for begge kildesystem
Implementere eventuell ny funksjonalitet
- Implementere en form for callbacks for eventuelle utvidelser? F.eks. lagre informasjon om printerkvote-unntak?
- Lage tester for funksjonalitet
- Bygge en HR-import hvor forretningslogikk blir separert ut fra kommunikasjon med HR-system og databasemodell i Cerebrum. Dette vil gjøre det mulig å bytte ut en komponent (les: uthenting av informasjon fra HR-system).
- Bygge en modularisert HR-import hvor hver enkelt komponent kan testes. Dette vil la oss bl.a. sammenligne implementasjoner for SAPUiO/DFØ-SAP.
- Minimere endringer og potensielle feil ved overgang til DFØ-SAP - en overgang som allerede er stor.
- Bygge en tjeneste som på sikt lar seg utvides for bruk av andre partnere som benytter seg av DFØ-SAP, og kanskje til og med andre kildesystemer.
Den overordnede ideen er å bygge en SAP-consumer som også fungerer litt likere andre meldingsbaserte mikrotjenester ved UiO.
- En generisk consumer som leser inn hva som skal gjøres fra konfigurasjon:
- Hva lytter vi til? Hvilken MQ, hvilken kø, evt. bindings?
- Hva gjør vi med meldinger? Hvilke meldinger skal håndteres av hvilken oppgaveimplementasjon?
- Hvordan skal feil håndteres?
- Oppgaver for å håndtere selve endringen. I tilfellet sap-consumer har vi i utgangspunktet kun en oppgave inntil videre: oppdatere ansatt
- Selve oppgave-implementasjonen vil tilsvare handle_person.
Oppgaveimplementasjon bør også restruktureres for å bedre støtte ulike kildesystemer, og dermed gjøre overgangen til DFØ-SAP enklere. Ved å dele forretningslogikken opp i ulike lag:
- Hente relevante data om person
- Oversette til mellomformat (felles datastruktur for SAPUiO og DFØ-SAP)
- Oppdatere person i Cerebrum med mellomformat - vil nå fungere likt for begge kildesystem
- Implementere eventuell ny funksjonalitet i form av callbacks.
En slik organisering vil gjøre integrasjonen testbar, slik at vi kan verifisere at både gammel og ny integrasjon fungerer likt.
Implementasjon av integrasjon med DFØ-SAP
Dersom sap-consumer refaktoreres vil en eventuell integrasjon med DFØ-SAP kun bestå i å implementere nye kompatibilitetslag:
- Implementere klient for å snakke med API
- Implementere oversetting av meldinger
- Implementere oversetting av data API-ene til DFØ-SAP til Cerebrum-data.
TODO: Avklare oversetting
Ansettelse til tilknytning - hvilke ansettelser finnes? Er det mer en tekadm/vitenskapelig? Får vi ett definitivt svar fra DFØ-SAP per ansettelse?
Rolle til tilknytning - finnes tilsvarende i DFØ-SAP?
- 'INNKJØPER', co.affiliation_tilknyttet_innkjoper
- 'EF-FORSKER', co.affiliation_tilknyttet_ekst_forsker
- 'EMERITUS', co.affiliation_tilknyttet_emeritus
- 'BILAGSLØNN', co.affiliation_tilknyttet_bilag
- 'GJ-FORSKER', co.affiliation_tilknyttet_gjesteforsker
- 'ASSOSIERT', co.affiliation_tilknyttet_assosiert_person
- 'EF-STIP', co.affiliation_tilknyttet_ekst_stip
- 'GRP-LÆRER', co.affiliation_tilknyttet_grlaerer
- 'EKST-KONS', co.affiliation_tilknyttet_ekst_partner
- 'PCVAKT', co.affiliation_tilknyttet_pcvakt
- 'EKST-PART', co.affiliation_tilknyttet_ekst_partner
- 'KOMITEMEDLEM', co.affiliation_tilknyttet_komitemedlem
- 'STEDOPPLYS', None
- 'POLS-ANSAT', None
Notat
Joakim spurde prosjektet om detaljar 10.10.2020 - Til Sindre, Anders, Kolstad og cerebrum-core.
Overgang
Cerebrum benytter i utgangspunktet ansattnummer fra SAP for å gjøre kobling mellom SAP og Cerebrum ved oppdatering av person, eller fnr/passnummer ved oppretting.
Det antas at ansattnummer som er tildelt ved UiO ikke kommer til å benyttes videre hos DFØ, men at alle ansatte vil få nye ansattnummer. Dette må gjerne håndteres på et vis. Hvordan vil migrasjon fra SAPUiO til DFØ-SAP foregå? Vil det være mulig å få ut en kobling fra dette migrasjonsarbeidet?
Det vil imidlertid fungere å la dette gå seg til over tid, men det å benytte utelukkende fnr/passnummer for å koble personer fører ofte til feil og dobbeltregistreringer da disse gjerne endres eller feilregistreres, mens ansattnummer er konstant enn så lenge vi har en kobling mellom SAP og Cerebrum.