Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Indholdsfortegnelse
Afgrænsning af epic
| Afgræsning | ||
|---|---|---|
Som STAR PO og som STAR arkitekt vil jeg have overholdt arkitekturpattern om indførelse af PersonId og udfasning af PersonStatusService til fordel for "slanke" statusServices, som er domænespecifikke, og har a-kasse filtrering som i PersonStatusService | ||
| Acceptkriterier | ||
| Nr. | Beskrivelse | Relevant for |
| 935.2.1 | PersonId indføres på registrerede (afholdte) samtaler | DFDG, BI |
| 935.2.2 | InterviewService.GetPersonInterview oprettes med henblik på, at der er en fuld get-metode på registrerede afholdte samtaler, så PersonStatusService er udfasbar ift. PersonInterviewInfo | DFDG |
| 935.2.3 | Der laves en generisk model for filtrering af status- og get-metoder med henblik på vedligeholdbar kode, forenklet test og sikring af korrekt filtrering på alle de nye status- og get-metoder | DFDG |
| Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
|---|---|---|---|---|---|
| Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | ||
| Ingen kriterier for eksterne i denne epic | |||||
Oversigt over berørte webservices
Beskrivelse af epic
Ny InterviewService (version 1) med fuld IntervewInfo
Der etableres ny InterviewService (Version 1) med metoden GetPersonInterviewInfo med feltsæt, der svarer til PersonInterviewInfo i PersonStatusService.
Wiki opdateres.
Der lægges a-kasse-filtrering på InterviewInfo, jf. tilsvarende "PSS-filtrering"
Der lægges filtrering på output op InterviewService.GetPersonInterviewInfo, der svarer til filtreringen, der var på PersonStatusService tidligere ift. a-kasserne.
Der er sammen med D&S arkitekt fundet en model for generisk filtrering i ---statusServices og ---Getmetoder
Der anvendes PersonId ved samtaleregistrering
Alle tabeller og SP'er, der har dependency til tabellen, rettes, inkl GDPR.
Der indføres PersonId på fact- og historiktabellerne for samtaleregistrering
Eksisterende data konverteres. Check performance/tid for konvertering og opdel evt. konverteringen i mindre bidder.
Oversigten på WIKI (DFDG PersonId) opdateres.
BI og SF orienteres om at der omlægges til PersonId
Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:
- DFDG
- Services
- WSRMer
- Kodelister
- PersonStatusService (PSS)
- PersonHistoryService (PHS)
- LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
- Jobnet
- VITAS
- JobKon
- JobAG
- BI integrationsplatform
- Alle områder
- Nye batchjobs
- Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon)
- Dataløft
- Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.
- Nye batchjobs
- Kommunalt sagsbehandlingssystem
- A-kasse sagsbehandlingssystem
- Kommunalt bookingsystem
- JobcenterPlanner (JCP)
- WorkForcePlanner (WFP)
- Kommunalt ydelsessystem
Særlige krav til test
| Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
|---|---|---|
| Hent/læs (gamle) registrerede afholdte samtaler | PersonStatusService - se via opslag i LSS, om afholdte samtaler fortsat kan vises | Knud |
| Registrér en ny samtale (via LSS/Datakanon) | PersonRegistrationService.CreatePersonInterview - tjek at samtalen kan registreres. Tjek at samtalen kan hentes via opslag med PersonStatusService og med den nye service. | Knud |
* Batchjobs
- bør testes både med delta og fuldt load,
- bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
- bør testes i samarbejde med teams som har afhængigheder
- kørselstid, særligt hvis det er en del af NightlyBatch
Konsekvenser for drift/idriftsættelse
I forbindelse med idriftsættelse:
- Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres
- skal der køres konvertering
- Skal der køres databasescripts for opdatering af tabeller i databasen
Efter idriftsættelse:
Arkitektur- og implementeringsnoter
Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:
- Nye dataområder
- Nye snitflader
- Nye komponenter
- Nye miljøer
- Nye teknologier
- Nye aftagertyper
- Eller afvigelser fra principperne
Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.