Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Page Properties | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Indholdsfortegnelse
Table of Contents | ||
---|---|---|
|
Afgrænsning af epic
Afgrænsning | ||
---|---|---|
Som borger vil jeg have flere muligheder for selvbooking i kraft af at det er muligt i flere systemer | ||
Acceptkriterier | ||
Nr. | Beskrivelse | Relevant for |
905.3.1 | Det er muligt at selvbooke møder til afholdelse i jobcenter på andre systemer end Jobnet | DFDG |
905.3.2 | Selvbookede møder i a-kassen registreres som selvbookede i DFDG | DFDG |
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
---|---|---|---|---|---|
Acceptkriterie 905.3.1 | Acceptkriterie 905.3.2 | Acceptkriterie <nr.> | Acceptkriterie <nr.> | ||
A-kasser: Møder som medlemmer har booket i a-kassens selvbooking-løsning fremstår som selvbookede ved indberettelse af aftalen til DFDG. | X | ||||
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)
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Beskrivelse af epic
Indtil LAB har det i lovgrundlaget for borgers selvbook af samtaler til afholdelse i Jobcenterregi været defineret at det skulle foregå på Jobnet.
Det bliver der lavet om på med LAB, så det bliver muligt at indberette borgers selvbookede aftaler som selvbookede i eksempelvis lokale plannersystemer eller apps.
I vid udstrækning løses dette ved at DFDG modtager aftaler (bookings) i BookingService hvor feltet SelfBooked indikerer at aftalen er selvbooket af borger.
¤Afklaring Afholdte møder som er selvbookede indberettes ligeledes som selvbookede (dette vil kræve at vi opdaterer snitfladen, feltet findes ikke idag).
Bookingsystemet skal sikre at borger ikke får tilbudt jobsamtaler eller rådighedssamtaler hvis borger allerede har en fremtidig samtale af en af disse to typer. Fejl: ¤eksisterende bookingservice-fejl.
Borgers accept af booking
Aftaler med denne påtegning vil som alle andre blive udstillet til borger på Jobnet. De forventes at have BookingAccepted = true (borger har accepteret bookingen) og BookingAcceptedTime sat. I modsat fald vil man få fejl: ¤fejl afklares.
Ansvar for udstiller af brugergrænsesnitflade ift. overholdelse af frist til selvbook med henblik på samtaleforløbets kadence af samtaler
I de tilfælde hvor borger har en frist til selvbooking vil det i et vist omfang påhvile det system som stiller brugersnitflade til rådighed for borgeren at sikre at borger ikke får mulighed for at booke til afholdelse senere end 7 dage efter den udstedte frist.
¤Afklaring For at hjælpe med dette validerer DFDG på aftaler der kommer ind i BookingServices.CreateBooking med SelfBooking sat true. Disse må ikke ligge til afholdelse mere end 7 dage efter frist. Manglende overholdelse giver fejlen: ¤ afklares
Straksbooking
Straksbooking er begrebet for at en borger har haft en frist til selvbooking, men ikke har booket indenfor fristen, som dermed nu er overskredet.
¤Afklaring Det forventes at når en borger er straksbookingramt (dvs. har en frist for selvbooking som er overskredet, og ikke har et fremtidigt møde af den samtaletype der er frist til):
A) Henvises borger til at booke på Jobnet fordi han har overskredet sin frist og der dermed er strengere krav til booking, eller
B) Borger får udstillet 10 tider til selvbooking indenfor de nærmeste 7 dage, og i videst mulige omfang får al opmærksomhed henledt på booking af den samtaletype der er frist for.
Hvis borger er straksbookingramt må afholdelsesdato ikke ligge mere end 7 dage ud i fremtiden, og bookingen må ikke være borger-aflysbar og ikke borger-ombookbar. ¤Afklaring Fejl: ¤ afklares.
For UpdateBooking kan flaget være "gammelt", fra oprettelsen - altså at en sagsbehandler ombooker en aftale som borger oprindeligt har booket. Vi vil ikke validere på dette, da vi så skal kræve at alle systemer som indberetter bookings nulstiller SelfBooked ved hver opdatering, det er ikke ønsket.
Metadata og indikation af bookingens ophav
Behovet for at genkende hvilket system der har initieret en booking er størst i WSRM sammenhæng, med henblik på at identificere hvilke WSRM'er der er bekræftelse af bookings oprettede i eget system, og hvilke der de facto genererer en opgave.
I BookingWsrmMessageService.GetBookings medtages RequestUserMetadata fra oprettelsen af en booking.
I PersonStatusService har man BookingOriginator med OrganisationCode og OrganisationType som ved selvbooking fra Jobnet er henholdsvis Cv nummer og Star (id 5).
¤Løsningsmodel til afklaring: Ved oprettelse af en booking (DFDGs sikkerhedsmodel) skal borgers CPR nummer fremstå sammen med indikation af det Jobcenter han er tilknyttet.
Øvrig funktionalitet der ændres i tilknytning til bookninger
Huskeservicebeskeder sendes med udgangspunkt i at det er borger selv der har booket.
Der rettes på valideringen så der ikke længere valideres på at ombooknings- og afbookningsdeadline skal være i fremtiden på BookingService.UpdateBooking og ExternalBookingService.RescheduleBooking. Valideringen forbliver aktiv CreateBooking situationen.
¤Afklaringer
Løsningsstørrelse: Løsningen kunne også laves med en separat metode (som dog vil ligne den nuværende meget, så det giver en arkitekturmæssigt uønsket vedligeholdsopgaver). Det vil være en del dyrere, men vil give mulighed for at validere målrettet.
Man kunne også udvide med flere felter, så man kan se om den oprindeligt er selvbooket, samt om den seneste handling (ved ombooking) er foretaget af borger eller sagsbehandler.
"Straksbookingramt" er ikke udstillet som felt, det kan man overveje om det bør være i denne sammenhæng.
Koordinering med Jobcenter Planner plannersystemer om genkendelse af selvbookede bookings fra øvrige systemer. Det er ikke helt parallelt til den kendte skiftesporssituation, for der har man adskildelse pr jobcenter.
Skal der laves regler om, om man som KSS/Jobcenter må have både plannersystem og anden selvbookingløsning?
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.