Mangler som bør eller må på plass før overgang
- Fikse/tilpasse bruk av SAP-kildesystem og ansattnummer (må/bør) ✓
- Varsle/ko-ordinere bruk av ansattnummer i eksterene systemer (må) ?
- Integrasjon med OrgReg (bør) ?
- Migrasjonsverktøy for DFØ-SAP (må) ?
- Bedre køsystem, oppfølgingssystem mot kilder, for håndtering av feil, forsinkede meldinger, etc... (bør). ?
- Bedre sporing av endringer (bør). ?
Bruk av sap-spesifikke data
Mange integrasjoner og interne prosesser i Cerebrum bruker SAPUiO-spesifike data. Typisk er gjerne at en velger hvem som er ansatt ved å se på tilknytninger fra et enkelt kildesystem, eller at en velger å eksportere ansattdata fra et gitt kildesystem.
Se todo-fixes.html for mer detaljer.
Bruk av ansattnummer i integrasjoner
Flere Cerebrum-integrasjoner benytter seg av ansattnummer som personidentifikator. Vi må varsle og avtale/ko-ordinere hvordan overgang til nye ansattnummer skal foregå.
Endringen lettes noe i og med at gamle ansattnummer vil beholdes i en kort periode etter migrasjon.
Se todo-fixes.html for mer detaljer.
Integrasjon med OrgReg
En integrasjon med OrgReg for oppdatering av OU-treet i Cerebrum bør være på plass. Alternativet er at import av ansatte med tilknytning til utdaterte OU-er vil feile.
Integrasjon med OrgReg må også inkludere migrasjonsverktøy for å hente ut og sette DFØ-intern OU-ID basert på eksisterende stedkoder.
Migrasjonsverktøy for DFØ-SAP
Før overgang til DFØ, må vi ha klart et script for å legge inn DFØ-ansattnummer på alle eksisterende ansatte i Cerebrum.
Bedre køsystem
Før overgang bør vi ha på plass bedre systemer for å håndtere feil.
- Forsinkede meldinger
- En egen intern kø kan liste opp meldinger med (nbf) for senere prosessering.
- Daterte hendelser
- En egen intern kø for kan liste opp datoer hvor endring bør intreffe (uavhengig av melding). Dette gjelder ved oppslag og import av objekter med startdato eller sluttdato i fremtid.
- Feilede hendelser
- En egen intern kø kan holde styr på meldinger som ikke lar seg prosessere. Slike meldingere kan f.eks. re-prosesseres senere, med en eksponentiell backoff.
- Duplikatmeldinger og utdaterte meldinger
- Vi utfører en fullsync av persondata for hver melding, men ofte vil vi få to samtidige meldinger dersom to datafelt på ett og samme objekt sendes ut. Fra Cerebrum sitt ståsted blir da melding nummer å regne som en utdatert duplikatmelding. En egen intern kø kan sikre at vi ikke prosesserer slike utdaterte meldinger.
- Pipeline (gruppering av meldinger)
- En egen intern kø lar oss samle opp og prosessere relaterte endringer samlet.
Spore endringer
Ved batch-import ble det brukt et dato-felt i tilknytningsstatus for å spore om en gitt tilknytning ikke lenger ble vedlikeholdt fra kildesystem. Dette systemet passer ikke like bra ved overgang til hendelsesbasert oppdatering.
Vi bør bytte dette ut med en egen tabell for å holde styr på siste oppdatering fra kildesystem.
En slik oversikt vil være uvurderlig ved feilsøking (hvorfor er ikke dette objektet oppdatert?). CRB-3353
Videre kan et slikt system brukes som en failsafe, hvor vi regelmessig gjør en oppdatering av de sist oppdaterte objektene. CRB-3354
Sette opp ny SAPUiO-import (før jul)
Den re-faktorerte integrasjonen med SAPUiO bør komme i produksjon så tidlig som mulig. Integrasjonen lar oss verifisere at logikk, forsinkede meldinger, etc... fungerer som tiltenkt, uten å måtte ta høyde for endringer i datamodell, og andre komplikasjoner ved overgang til nytt HR- og lønnssystem.
MQ
Ny import trenger egne køer og bindings.
- Husk køer for scheduling av forsinkede meldinger (nbf, tiny_scheduler)
Sette opp ny import
Ny integrasjon bør kjøre i dry-run i en periode for å sikre at det ikke finnes alvorlige feil (import feiler, tjenesten feiler, tjenesten henger seg opp).
Overgang til ny import
Bytte fra gammel (consumer_sap) til ny (hr-import) import-logikk. Etter dette bør vi følge godt med, og fikse eventuelle feil fortløpende. Alle bugfixes må også sjekkes opp mot integrasjon med DFØ-SAP.
Opprydding
Når vi er komfortabel nok med ny import til å si at vi ikke skal rulle tilbake til consumer_sap
- Fjerne gamle køer og bindings
- Fjerne consumer_sap-funksjonalitet
- Fjerne consumer_sap-konfigurasjon
Sette opp DFØ-import (i god tid før overgang)
MQ
Ny import trenger egne køer og bindings.
- Husk køer for scheduling av forsinkede meldinger (nbf, tiny_scheduler) dersom ikke dette har blitt byttet ut med intern kø.
Sette opp ny import
Ny integrasjon bør kjøre i dry-run i en periode for å sikre at det ikke finnes alvorlige feil (import feiler, tjenesten feiler, tjenesten henger seg opp).
Overgang
TODO: Dette må konkretiseres mer i detalj når det nærmer seg.
TODO: I god tid før overgangen, må vi legge inn overstyring av alle bilagslønna som vi får i liste frå SAF. Sjå CRB-3518.
- Før DFØ-SAP taes i bruk, tøm alle DFØ-køer og skru av DFØ-integrasjon.
- TODO: Bør vi ta ein form for backup av gamle data, for å enklare kunne samanlikne i verifiseringa etter overgangen?
- Etter SAPUiO er låst, skru av SAPUiO-integrasjon.
- Etter at DFØ-SAP har tatt over for SAPUIO, må vi få migrasjonsdata fra ADS (kontakt: Tone Morken).
- Kjør migrasjoner/oppdatering av ansatt-ider
- Skru på DFØ-integrasjon (med commit)
- TODO: Vi må verifisere at data er som forventa, så vi får avdekka avvik før det påvirker organisasjonen. Køyre ein fullsynk, i dryrun, og sjå i loggen kva som ville endra seg? Bør til dømes sjekke kor mange som får endra sitt mobilnummer.
TODO: Vi veit at DFØ SAP starter opp med alle ansattdata ferdig registrert, men blant anna brukarnamn og e-postadresser vert etterregistrert og er difor blanke i starten.
Opprydding
- Fjerne SAPUIO-køer
- Fjerne SAPUIO-konfigurajon
- Kjøre opprydding/fjering av SAPUIO-data
- Fjerne SAPUIO-funksjonalitet/import