Afgrænsning af epic
| Afgræsning |
|---|
Som a-kasse og kommune, vil jeg gerne have styr på hvem der har ansvaret for de lediges kontaktforløb. |
| Acceptkriterier |
|
|
|---|
| Nr. | Beskrivelse | Relevant for |
| 935.4.1 |
| |
|
|
|
|
|
|
| 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
| Jira Legacy |
|---|
| server | System JIRA |
|---|
| columns | summary,varslingstype,varslingsnote,eksterne snitflader,interne snitflader,project |
|---|
| maximumIssues | 100 |
|---|
| jqlQuery | issuetype = Varsling AND linkedIssue in (DS-289,JOB-38105) ORDER BY summary, Varslingstype, "Eksterne snitflader", "Interne Snitflader" |
|---|
| serverId | 479d1618-4a6f-3f88-8ee1-04c6b02c448a |
|---|
|
Beskrivelse af epic
Denne epic er en fortsættelse af arbejdet i 935.3 LAB - A-kasse forsøg
Samtaleafholdelse med borger
A-kassen skal kunne indkalde, afholde og registrere såvel jobsamtale (InterviewType id 7) som Fælles Jobsamtale (InterviewType id 19).
A-kassen opretter indkaldelser med BookingService hvor der generelt (¤Afklaring: eller kun for forløbsdeltagere) åbnes op for at samtaletyperne id 7 og 19 for a-kasser.
Jobcentret får WSRM på alle bookinger for egne borgere, og er således orienterede om bookingen.
¤UNDER AFKLARING: Det forventes at man ved fælles jobsamtaler registrerer deltagelse ved at opdatere BookingParticipantCollection, der laves en ny metode, UpdateBookingParticipantCollection til dette. Registreringer af fravalg af deltagelse i fællesmøder udgår, og de tilhørende valideringer ligeså.
¤Afklaring: På indkaldelse kan man under BookingParticipant.ContactDetails registrere det hvis deltagere ikke deltager fysisk ( eller BookingParticipant kan udvides med en InterviewContactType så man kan sætte deltagelsestype til Personlig kontakt/Telefon/.../Videokonference).
Samtaleafholdelse registreres med PersonRegistrationService hvor den nuværende mulighed for at registrere CV- og rådighedssamtaler under forudsætning af at borger har været dagpengemodtager på samtaleafholdelsesdatoen, udvides med jobsamtaler og fælles jobsamtaler.
Når samtaleafholdelse registreres anvendes InterviewParticipant.InterviewParticipantContactType til at indikere om man har deltaget fysisk (id 1 - Personlig kontakt), pr video (id 8) eller lignende.
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.
- 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
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.