Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Indholdsfortegnelse
Afgrænsning af epic
| Afgrænsning | ||
|---|---|---|
Som CPO ønsker jeg følgende af mig godkendte acceptkriterier indfriet | ||
| Acceptkriterier | ||
| Nr. | Beskrivelse | Relevant for |
| 838.13.1 | Sletning af ikke anvendt service | Jobnet |
| 838.13.2 | Implementer visning af tilmeldehistorik for borger i Jobnet | Jobnet |
| Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
|---|---|---|---|---|---|
| Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | ||
Oversigt over berørte webservices
Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):
Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)
Beskrivelse af epic
838.13.1 Sletning af ikke anvendt service
Jævnfør intern varsling fra DFDG:
(DS-1940 - UnemploymentEnrollmentService (version 6 og 7).CreateJobnetAccount DONE
er Jobnet gjort opmærksom på, at metode CreateJobnetAccount slettes fra version 6 og version 7 i 20-2. Jobnet anvender version 7, men anvender ikke metoden CreateJobnetAccount på denne. Metoden viser sig dog at være refereret på UnemploymentEnrollmentService(V4), der ligger død i jobnetkoden. Dette er teknisk gæld og referencer til UnemploymentEnrollmentService(v4) slettes derfor i /wiki/spaces/ISB/pages/1829668148.
838.13.2 Visning af tilmeldehistorik for borger på Jobnet
Ved overgangen fra de tidligere rest services til Soap services på Jobnet historik, havde Jobnet ikke data til at vise borgers til- og afmeldinger. I en periode prøvede man at vise data fra PHS, men mængden af data modsvarede et registerudskrift og var for overvældende for borgerne og det blev vurderet, at Jobnet ikke skulle filtrere i disse. Dette gav anledning til borgerhendelser og i stedet blev historikens ledighedsstatusser sat i bero:
En manuscriptsag (https://manuscript.star.dk/f/cases/153724/) blev oprettet med henblik på at finde en bedre løsning, men ingen services fra DFDG har kunne levere samme information som den tidligere REST service kunne. Den løsning der implementeres i /wiki/spaces/ISB/pages/1997308096 tilnærmer sig den oprindelige løsning, men har dog ikke en visning af hvem der står bag til-/afmelding. Den information fremgår ikke af enrollment collectionen på PSS v20, fra hvilken til- og afmeldinger af borger nu hentes:
Data der vises er: hvad borger er tilmeldt som (dagpengemodtager, kontanthjælpsmodtager osv), hvilken dato til- og evt. afmelding er sket, samt tilmeldegraden (fuldt ledig, delvis ledig mv.).
Der vises data for en 3 årig periode. Konkret vises tilmeldinger hvor afmelding endnu ikke er sket (dvs. aktuelle ledighedsperiode) eller tilmeldinger, hvor afmelding er sket inden for seneste tre år (hvorved noget af ledighedsperioden altså har været inden for de tre seneste år).
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 |
|---|---|---|
* 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
- Eventuelle behov for reduktion af teknisk gæld skal afdækkes
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.